From owner-ietf-openpgp@mail.imc.org Tue Aug 6 07:30:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05385 for ; Tue, 6 Aug 2002 07:30:36 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g76BFel18363 for ietf-openpgp-bks; Tue, 6 Aug 2002 04:15:40 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76BFcw18359 for ; Tue, 6 Aug 2002 04:15:39 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04053; Tue, 6 Aug 2002 07:14:25 -0400 (EDT) Message-Id: <200208061114.HAA04053@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: namedropper@ops.ietf.org, ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-josefsson-cert-openpgp-00.txt Date: Tue, 06 Aug 2002 07:14:25 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OpenPGP data in the CERT RR Author(s) : S. Josefsson Filename : draft-josefsson-cert-openpgp-00.txt Pages : 9 Date : 05-Aug-02 This draft describes the decisions made in one pair of applications [4][5] that respectively serves and retrieve OpenPGP [3] Certificates and Revocation Signatures using the CERT Resources Record [2]. The intent is to provide a discussion on the kind of general updates needed to the CERT specification, and some suggested specific updates for the OpenPGP sub-type. It is offered in the hope that this specification, together with similar efforts for other applications, can be reviewed when designing a generic solution or guidelines for storing application keying material in the Domain Name System (DNS), should it ever happen. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-josefsson-cert-openpgp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-josefsson-cert-openpgp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-josefsson-cert-openpgp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-josefsson-cert-openpgp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132652.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openpgp@mail.imc.org Mon Aug 12 07:32:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16939 for ; Mon, 12 Aug 2002 07:32:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CBLum26091 for ietf-openpgp-bks; Mon, 12 Aug 2002 04:21:56 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CBLtw26087 for ; Mon, 12 Aug 2002 04:21:55 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16270; Mon, 12 Aug 2002 07:20:38 -0400 (EDT) Message-Id: <200208121120.HAA16270@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Date: Mon, 12 Aug 2002 07:20:37 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : OpenPGP Message Format Author(s) : J. Callas, L. Donnerhacke, H. Finney, R. Thayer Filename : draft-ietf-openpgp-rfc2440bis-06.txt Pages : 71 Date : 09-Aug-02 This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-rfc2440bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020809153523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-rfc2440bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020809153523.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openpgp@mail.imc.org Mon Aug 12 10:15:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23453 for ; Mon, 12 Aug 2002 10:15:05 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7CE7Ss04928 for ietf-openpgp-bks; Mon, 12 Aug 2002 07:07:28 -0700 (PDT) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CE7Rw04924 for ; Mon, 12 Aug 2002 07:07:27 -0700 (PDT) Received: from rusfw by Mail.CERT.Uni-Stuttgart.DE with local (Exim 4.04) id 17eFqx-0002oG-00 for ietf-openpgp@imc.org; Mon, 12 Aug 2002 16:07:27 +0200 To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt References: <200208121120.HAA16270@ietf.org> From: Florian Weimer Date: Mon, 12 Aug 2002 16:07:27 +0200 In-Reply-To: <200208121120.HAA16270@ietf.org> (Internet-Drafts@ietf.org's message of "Mon, 12 Aug 2002 07:20:37 -0400") Message-ID: <87eld41880.fsf@CERT.Uni-Stuttgart.DE> Lines: 15 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (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: | Revoking a self-signature or allowing it to expire has a defined | semantic meaning. IMHO, the draft does not specify the semantics of expiration in a way which would warrant such statement. I don't believe we can agree on a specific set of expiration semantics even in the limited circle of this WG. BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html) is definitely worth a read. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Mon Aug 12 13:31:28 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01544 for ; Mon, 12 Aug 2002 13:31:28 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7CHNTb16654 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:23:29 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CHNSw16650 for ; Mon, 12 Aug 2002 10:23:28 -0700 (PDT) Received: from [63.73.97.182] (63.73.97.182) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Mon, 12 Aug 2002 10:23:17 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 12 Aug 2002 10:23:26 -0700 Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt From: Jon Callas To: Florian Weimer , OpenPGP Message-ID: In-Reply-To: <87eld41880.fsf@CERT.Uni-Stuttgart.DE> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8/12/02 7:07 AM, "Florian Weimer" wrote: > IMHO, the draft does not specify the semantics of expiration in a way > which would warrant such statement. I don't believe we can agree on a > specific set of expiration semantics even in the limited circle of > this WG. > > BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html) > is definitely worth a read. That particular change was correcting a typo in the previous draft. It has nothing to do with the new paper. Jon From owner-ietf-openpgp@mail.imc.org Mon Aug 12 13:32:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01622 for ; Mon, 12 Aug 2002 13:32:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CHQDU16829 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:26:13 -0700 (PDT) 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 g7CHQAw16824 for ; Mon, 12 Aug 2002 10:26:10 -0700 (PDT) Date: Mon, 12 Aug 2002 10:26:10 -0700 (PDT) Message-Id: <200208121726.g7CHQAw16824@above.proper.com> Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17eK6M-0005WR-00; Mon, 12 Aug 2002 20:39:38 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17eJ0v-0004hM-00; Mon, 12 Aug 2002 19:29:57 +0200 X-From-Line: nobody Mon Aug 12 19:29:15 2002 To: Florian Weimer Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt References: <200208121120.HAA16270@ietf.org> <87eld41880.fsf@CERT.Uni-Stuttgart.DE> From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH In-Reply-To: <87eld41880.fsf@CERT.Uni-Stuttgart.DE> (Florian Weimer's message of "Mon, 12 Aug 2002 16:07:27 +0200") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 20 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 12 Aug 2002 16:07:27 +0200, Florian Weimer said: > IMHO, the draft does not specify the semantics of expiration in a way > which would warrant such statement. I don't believe we can agree on a > specific set of expiration semantics even in the limited circle of PNX (PGP is not X.509) ;-) > BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html) > is definitely worth a read. And the reason why Jon released the draft and sharped the MDC wording. I see no more problem with the draft. How lets try again to kick off the the interop tests. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Mon Aug 12 13:35:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01703 for ; Mon, 12 Aug 2002 13:35:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CHSfQ16863 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:28:41 -0700 (PDT) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CHSew16859 for ; Mon, 12 Aug 2002 10:28:40 -0700 (PDT) Received: from rusfw by Mail.CERT.Uni-Stuttgart.DE with local (Exim 4.04) id 17eIzh-0006SA-00; Mon, 12 Aug 2002 19:28:41 +0200 To: Jon Callas Cc: OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt References: From: Florian Weimer Date: Mon, 12 Aug 2002 19:28:41 +0200 In-Reply-To: (Jon Callas's message of "Mon, 12 Aug 2002 10:23:26 -0700") Message-ID: <871y94yoja.fsf@CERT.Uni-Stuttgart.DE> Lines: 23 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (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: Jon Callas writes: > On 8/12/02 7:07 AM, "Florian Weimer" wrote: > >> IMHO, the draft does not specify the semantics of expiration in a way >> which would warrant such statement. I don't believe we can agree on a >> specific set of expiration semantics even in the limited circle of >> this WG. >> >> BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html) >> is definitely worth a read. > > That particular change was correcting a typo in the previous draft. It has > nothing to do with the new paper. Oh, I didn't want to imply *that* (hence "BTW"). I still think that the change is misleading. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 From owner-ietf-openpgp@mail.imc.org Mon Aug 12 13:55:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02787 for ; Mon, 12 Aug 2002 13:55:02 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7CHleH17451 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:47:40 -0700 (PDT) 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 g7CHlcw17447 for ; Mon, 12 Aug 2002 10:47:39 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7CHlPW02535 for ietf-openpgp@imc.org; Mon, 12 Aug 2002 13:47:25 -0400 Date: Mon, 12 Aug 2002 13:47:25 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Message-ID: <20020812174725.GC2319@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200208121120.HAA16270@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208121120.HAA16270@ietf.org> 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 (21% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I noticed the "notary signature" specification was not present. I thought we had sufficiently specified how that would work? David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From owner-ietf-openpgp@mail.imc.org Mon Aug 12 14:02:44 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03225 for ; Mon, 12 Aug 2002 14:02:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CHtTD18364 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:55:29 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CHtRw18360 for ; Mon, 12 Aug 2002 10:55:27 -0700 (PDT) Received: by thetis.deor.org (Postfix, from userid 500) id 0FE9345022; Mon, 12 Aug 2002 10:55:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id F0DE548023; Mon, 12 Aug 2002 10:55:27 -0700 (PDT) Date: Mon, 12 Aug 2002 10:55:27 -0700 (PDT) From: Len Sassaman X-Sender: To: OpenPGP , Werner Koch Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt In-Reply-To: <200208121726.g7CHQAw16824@above.proper.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 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 Mon, 12 Aug 2002, Werner Koch wrote: > I see no more problem with the draft. How lets try again to kick off > the the interop tests. I think that it would be nice to have the NAI X.509 packets documented. Having quasi-offical data formats that implimentors need to deal with, but are not documented, sounds like a bad idea to me. (Though, if it belongs in a seperate Internet Draft, I have no problem with that. But there should be some place to go other than the PGP source for this information.) --Len. From owner-ietf-openpgp@mail.imc.org Mon Aug 12 14:43:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05381 for ; Mon, 12 Aug 2002 14:43:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CIZCV22772 for ietf-openpgp-bks; Mon, 12 Aug 2002 11:35:12 -0700 (PDT) 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 g7CIZBw22766 for ; Mon, 12 Aug 2002 11:35:11 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7CIZ8D03310 for ietf-openpgp@imc.org; Mon, 12 Aug 2002 14:35:08 -0400 Date: Mon, 12 Aug 2002 14:35:08 -0400 From: David Shaw To: OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Message-ID: <20020812183508.GD2319@akamai.com> Mail-Followup-To: OpenPGP References: <200208121726.g7CHQAw16824@above.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 (21% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 12, 2002 at 10:55:27AM -0700, Len Sassaman wrote: > > On Mon, 12 Aug 2002, Werner Koch wrote: > > > I see no more problem with the draft. How lets try again to kick off > > the the interop tests. > > I think that it would be nice to have the NAI X.509 packets documented. > Having quasi-offical data formats that implimentors need to deal with, but > are not documented, sounds like a bad idea to me. (Though, if it belongs > in a seperate Internet Draft, I have no problem with that. But there > should be some place to go other than the PGP source for this > information.) Speaking about the X.509 signatures, I wonder if they are strictly compliant with this draft. 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket and a timestamp subpacket, and that those subpackets are both hashed (as per the "two or more" language in section 5.2.3, and section 5.2.4.1. Subpacket Hints). The X.509 sigs don't have an issuer subpacket at all. If this reading is incorrect, it may be good to clarify things a bit. I suppose it could be argued that since the X.509 sigs are made with an experimental public key algorithm (100), the signature format does not necessarily follow. Come to think, both PGP and GnuPG create v4 signatures with a hashed timestamp, and an unhashed issuer. Are they compliant? ;) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From owner-ietf-openpgp@mail.imc.org Mon Aug 12 16:21:29 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09902 for ; Mon, 12 Aug 2002 16:21:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CKBrk26293 for ietf-openpgp-bks; Mon, 12 Aug 2002 13:11:53 -0700 (PDT) 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 g7CKBkw26284 for ; Mon, 12 Aug 2002 13:11:51 -0700 (PDT) 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 PAA14006 for ; Mon, 12 Aug 2002 15:58:59 -0400 (EDT) Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id QAA17982 for ; Mon, 12 Aug 2002 16:11:42 -0400 (EDT) Message-ID: <002001c2423c$5aa79bc0$f0c12609@transarc.ibm.com> From: "Michael Young" To: "OpenPGP" References: <200208121726.g7CHQAw16824@above.proper.com> <20020812183508.GD2319@akamai.com> Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Date: Mon, 12 Aug 2002 16:10:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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" > 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket ... > Come to think, both PGP and GnuPG create v4 signatures with a hashed > timestamp, and an unhashed issuer. Are they compliant? ;) I don't think that the specification should require either. It would be fair to note that many implementations will be unable (or unwilling) to interpret a signature without these things. But even if the issuer remains a MUST, it certainly doesn't need to be in the hashed material. As it stands, the specification doesn't say so exactly -- it merely suggests that they should be the first two subpackets, which is silly if the timestamp is hashed but the issuer is not. I would just excise the suggestion entirely. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPVgWJVMkvpTT8vCGEQLEMwCfUnZsYv6w/jQVYjBttwFWq7Y8by4AnRAY L1gn2QkotnPczcBtgFwcLJ/4 =tzg2 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Aug 12 17:11:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11622 for ; Mon, 12 Aug 2002 17:11:23 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CL2Rt29676 for ietf-openpgp-bks; Mon, 12 Aug 2002 14:02:27 -0700 (PDT) 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 g7CL2Qw29672 for ; Mon, 12 Aug 2002 14:02:26 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7CL2Nj05405 for ietf-openpgp@imc.org; Mon, 12 Aug 2002 17:02:23 -0400 Date: Mon, 12 Aug 2002 17:02:23 -0400 From: David Shaw To: OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Message-ID: <20020812210223.GA5163@akamai.com> Mail-Followup-To: OpenPGP References: <200208121726.g7CHQAw16824@above.proper.com> <20020812183508.GD2319@akamai.com> <002001c2423c$5aa79bc0$f0c12609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002001c2423c$5aa79bc0$f0c12609@transarc.ibm.com> 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 (22% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 12, 2002 at 04:10:48PM -0400, Michael Young wrote: > From: "David Shaw" > > 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket > ... > > Come to think, both PGP and GnuPG create v4 signatures with a hashed > > timestamp, and an unhashed issuer. Are they compliant? ;) > > I don't think that the specification should require either. It would be > fair to note that many implementations will be unable (or unwilling) to > interpret a signature without these things. > > But even if the issuer remains a MUST, it certainly doesn't need > to be in the hashed material. As it stands, the specification doesn't > say so exactly -- it merely suggests that they should be the first two > subpackets, which is silly if the timestamp is hashed but the issuer > is not. I would just excise the suggestion entirely. 2440bis does say (well, imply) that they are both hashed. In section 5.2.3. ("Version 4 Signature Packet Format"), it says that the hashed section is made up of "two or more" subpackets, and the unhashed section is made up of "zero or more" subpackets. Given the language elsewhere, I assume that these two hashed subpackets are the required issuer and timestamp. I agree with you though - I think that a signature should not require any subpacket to be present (SHOULD perhaps, but not MUST). David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From owner-ietf-openpgp@mail.imc.org Mon Aug 12 23:02:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19156 for ; Mon, 12 Aug 2002 23:02:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7D2pcW13721 for ietf-openpgp-bks; Mon, 12 Aug 2002 19:51:38 -0700 (PDT) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7D2paw13717 for ; Mon, 12 Aug 2002 19:51:36 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA14483 for ; Tue, 13 Aug 2002 11:51:39 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA19352 for ; Tue, 13 Aug 2002 11:51:38 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA10577 for ; Tue, 13 Aug 2002 11:51:38 +0900 (JST) Date: Tue, 13 Aug 2002 11:54:14 +0900 (JST) Message-Id: <20020813.115414.46613679.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Fw: Secret Key Packet Formats From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 3.0.60 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Aug_13_11:54:15_2002_891)--" Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----Next_Part(Tue_Aug_13_11:54:15_2002_891)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I sent the following message for 05.txt in June. But 06.txt does not include my suggestions. To reminder, I post the message gain. I hope my suggestions will be included in 07.txt. --Kazu ----Next_Part(Tue_Aug_13_11:54:15_2002_891)-- Content-Type: Message/Rfc822 Content-Disposition: inline Date: Thu, 27 Jun 2002 19:25:57 +0900 (JST) Message-Id: <20020627.192557.125129914.kazu@iijlab.net> To: ietf-openpgp@imc.org Cc: stefan@epy.co.at Subject: Secret Key Packet Formats From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I have several comments on Section 5.5.3 (Secret Key Packet Formats) of 2440bis-05. > - [Optional] If secret data is encrypted, Initial Vector (IV) of > the same length as the cipher's block size. The following might be more easy to understand. - [Optional] If secret data is encrypted(string-to-key usage octet was not 0), 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. If string-to-key usage octet was 0, this field is not encrypted. So, this should be: - Plain or encrypted multi-precision integers comprising the secret key data. These algorithm-specific fields are as described below. > - If the string-to-key usage octet was 255, then a two-octet > checksum of the plaintext of the algorithm-specific portion (sum > of all octets, mod 65536). If the string-to-key usage octet was > 254, then a 20-octet SHA-1 hash of the plaintext of the > algorithm-specific portion. This checksum or hash is encrypted > together with the algorithm-specific fields. This does not corver the other values than 254 and 255. According to RFC 2440, a two-octet checksum is necessary for the other values. > The 16-bit checksum that follows the algorithm-specific portion is > the algebraic sum, mod 65536, of the plaintext of all the > algorithm-specific octets (including MPI prefix and data). With V3 > keys, the checksum is stored in the clear. With V4 keys, the > checksum is encrypted like the algorithm-specific data. This value > is used to check that the passphrase was correct. However, this > checksum is deprecated; an implementation SHOULD NOT use it, but > should rather use the SHA-1 hash denoted with a usage octet of 254. > The reason for this is that there are some attacks on the private > key that can undetectably modify the secret key. Using a SHA-1 hash > prevents this. "16-bit checksum" should be "two-octet checksum". This paragraph should cover V2. Actually, old PGP commands produce Secret Key Packet with V2. Combination of string-to-key usage octet and format version is unclear. 2440bis-05 is read like: V3 V4 0 254 encrypted sha1 hash encrypted sha1 hash 255 clear checksum encrypted checksum others But I think this matrix should be: V2/V3 V4 0 clear checksum clear checksum 254 clear checksum encrypted sha1 hash 255 clear checksum encrypted checksum others clear checksum encrypted checksum If this is correct, I hope improvement of this section will be made in the next draft. Thanks. --Kazu ----Next_Part(Tue_Aug_13_11:54:15_2002_891)---- From owner-ietf-openpgp@mail.imc.org Tue Aug 13 02:25:52 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02505 for ; Tue, 13 Aug 2002 02:25:52 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7D6EhP20963 for ietf-openpgp-bks; Mon, 12 Aug 2002 23:14:43 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7D6Egw20955 for ; Mon, 12 Aug 2002 23:14:42 -0700 (PDT) Received: from [63.73.97.182] (63.73.97.182) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Mon, 12 Aug 2002 23:14:45 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 12 Aug 2002 23:14:49 -0700 Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt From: Jon Callas To: Len Sassaman , OpenPGP Message-ID: In-Reply-To: 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 > I think that it would be nice to have the NAI X.509 packets documented. > Having quasi-offical data formats that implimentors need to deal with, but > are not documented, sounds like a bad idea to me. (Though, if it belongs > in a seperate Internet Draft, I have no problem with that. But there > should be some place to go other than the PGP source for this > information.) It would be nice, but we have to get the owners of that code base to be willing to document it, or have someone else do it. I presume there's consensus that this is a good idea, as there are no further comments? I want to get soon a new RFC number, so let's look at what there is to finish up. * I've completely spaced on the notary signatures, apparently, so I'll get those in soon. * I'll look at signature subpackets, and if the spec needs changes to jibe with reality, I'll do it. MUSTs changed to SHOULDs, right? Anything else? Jon From owner-ietf-openpgp@mail.imc.org Tue Aug 13 07:34:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08057 for ; Tue, 13 Aug 2002 07:34:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7DBQGg29087 for ietf-openpgp-bks; Tue, 13 Aug 2002 04:26:16 -0700 (PDT) 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 g7DBQDw29083 for ; Tue, 13 Aug 2002 04:26:14 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17eaxi-0002Ak-00; Tue, 13 Aug 2002 14:39:50 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17eZrF-0000kH-00; Tue, 13 Aug 2002 13:29:05 +0200 To: Jon Callas Cc: Len Sassaman , OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt References: From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH Date: Tue, 13 Aug 2002 13:29:05 +0200 In-Reply-To: (Jon Callas's message of "Mon, 12 Aug 2002 23:14:49 -0700") Message-ID: <87wuqvgfpa.fsf@alberti.gnupg.de> Lines: 22 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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 Mon, 12 Aug 2002 23:14:49 -0700, Jon Callas said: > It would be nice, but we have to get the owners of that code base to be > willing to document it, or have someone else do it. I presume there's > consensus that this is a good idea, as there are no further comments? I think it is far easier to allow PGP keys for TLS (there is a specification and at least one implementation) than to intermix the two protocol and raise the complexity even more. Afaik, Peter Gutmann is working on a proposal on how to use X.509 keys with PGP. > * I'll look at signature subpackets, and if the spec needs changes to jibe > with reality, I'll do it. MUSTs changed to SHOULDs, right? Yes. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Tue Aug 13 18:01:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22898 for ; Tue, 13 Aug 2002 18:01:07 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7DLqpr06166 for ietf-openpgp-bks; Tue, 13 Aug 2002 14:52:51 -0700 (PDT) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7DLqnw06160 for ; Tue, 13 Aug 2002 14:52:49 -0700 (PDT) Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtp (Exim 4.05) id 17ejae-00027g-00 for ietf-openpgp@imc.org; Tue, 13 Aug 2002 23:52:36 +0200 Received: from a57de.pppool.de ([213.6.87.222] helo=daredevil) by mx3.freenet.de with esmtp (Exim 4.05 #1) id 17ejae-0000sc-00 for ietf-openpgp@imc.org; Tue, 13 Aug 2002 23:52:36 +0200 Received: from twoaday by daredevil with local (Exim 3.35 #1 (Debian)) id 17ejga-0005I5-00 for ; Tue, 13 Aug 2002 23:58:44 +0200 Date: Tue, 13 Aug 2002 23:58:44 +0200 From: Timo Schulz To: ietf-openpgp@imc.org Subject: Primary subkey subpacket Message-ID: <20020813215844.GA20328@daredevil.joesixpack.net> Reply-To: twoaday@freakmail.de Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-KeyID: BF3DF9B4 X-PGP-Request: lynx -source http://www.winpt.org/twoaday.asc User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! Recently I stumbled over a problems with multiple subkeys. I know PGP doesn't let the user choose the key at all and GPG uses the newest key by default. What about a "primary subkey" subpacket which is placed on the self signature to force the implementation to use a special subkey. The format should be similar to the "primary user id" packet. Timo From owner-ietf-openpgp@mail.imc.org Tue Aug 13 18:39:58 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24197 for ; Tue, 13 Aug 2002 18:39:58 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7DMXfh07658 for ietf-openpgp-bks; Tue, 13 Aug 2002 15:33:41 -0700 (PDT) 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 g7DMXew07654 for ; Tue, 13 Aug 2002 15:33:40 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7DMXcZ14869 for ietf-openpgp@imc.org; Tue, 13 Aug 2002 18:33:38 -0400 Date: Tue, 13 Aug 2002 18:33:38 -0400 From: David Shaw To: OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Message-ID: <20020813223338.GM744@akamai.com> Mail-Followup-To: OpenPGP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 (30% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 12, 2002 at 11:14:49PM -0700, Jon Callas wrote: > > > I think that it would be nice to have the NAI X.509 packets documented. > > Having quasi-offical data formats that implimentors need to deal with, but > > are not documented, sounds like a bad idea to me. (Though, if it belongs > > in a seperate Internet Draft, I have no problem with that. But there > > should be some place to go other than the PGP source for this > > information.) > > It would be nice, but we have to get the owners of that code base to be > willing to document it, or have someone else do it. I presume there's > consensus that this is a good idea, as there are no further comments? To a certain extent these are already documented in the draft. The X.509 signature subpackets are in the "private or experimental" range (they use 100), and the signatures are also issued using public key algorithm 100, also experimental. It would be nice to see the format fully documented, though if it were widely adopted, it would result in one of the experimental values effectively losing its experimental status. > I want to get soon a new RFC number, so let's look at what there is to > finish up. > > * I've completely spaced on the notary signatures, apparently, so I'll get > those in soon. I've started roughing out some code for this (based on the discussion a few weeks ago) so we can have some implementation experience for this and the "revocation target" subpackets. Could you post the notary signature draft language when you put it together? > * I'll look at signature subpackets, and if the spec needs changes to jibe > with reality, I'll do it. MUSTs changed to SHOULDs, right? Yes, and the "two or more" subpacket requirement for the hashed section should probably be "zero or more". David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From owner-ietf-openpgp@mail.imc.org Tue Aug 13 18:41:22 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24260 for ; Tue, 13 Aug 2002 18:41:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7DMa6o07718 for ietf-openpgp-bks; Tue, 13 Aug 2002 15:36:06 -0700 (PDT) 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 g7DMa4w07714 for ; Tue, 13 Aug 2002 15:36:04 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7DMa2L14907 for ietf-openpgp@imc.org; Tue, 13 Aug 2002 18:36:02 -0400 Date: Tue, 13 Aug 2002 18:36:02 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket Message-ID: <20020813223602.GN744@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020813215844.GA20328@daredevil.joesixpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020813215844.GA20328@daredevil.joesixpack.net> 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 (30% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 13, 2002 at 11:58:44PM +0200, Timo Schulz wrote: > Recently I stumbled over a problems with multiple subkeys. I know > PGP doesn't let the user choose the key at all and GPG uses the > newest key by default. What about a "primary subkey" subpacket > which is placed on the self signature to force the implementation > to use a special subkey. The format should be similar to the > "primary user id" packet. This is interesting. You'd have to tie it to the key flags subpacket somehow, as the notion of "primary" is different for different key types (primary signing subkey, primary encrypting subkey, etc.) It could even be a bit set in the key flags subpacket itself. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From owner-ietf-openpgp@mail.imc.org Wed Aug 14 03:20:15 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29136 for ; Wed, 14 Aug 2002 03:20:15 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7E7CCC07125 for ietf-openpgp-bks; Wed, 14 Aug 2002 00:12:12 -0700 (PDT) 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 g7E7C9w07111 for ; Wed, 14 Aug 2002 00:12:09 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17etTd-0000so-00; Wed, 14 Aug 2002 10:26:01 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17esMq-0002rr-00; Wed, 14 Aug 2002 09:14:56 +0200 To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket References: <20020813215844.GA20328@daredevil.joesixpack.net> From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH Date: Wed, 14 Aug 2002 09:14:56 +0200 In-Reply-To: <20020813215844.GA20328@daredevil.joesixpack.net> (Timo Schulz's message of "Tue, 13 Aug 2002 23:58:44 +0200") Message-ID: <877kithpxr.fsf@alberti.gnupg.de> Lines: 19 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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 Tue, 13 Aug 2002 23:58:44 +0200, Timo Schulz said: > Recently I stumbled over a problems with multiple subkeys. I know > PGP doesn't let the user choose the key at all and GPG uses the > newest key by default. What about a "primary subkey" subpacket I don't think this is needed. If a subkey is published a sending implementation may choose any of the valid subkeys for encryption. Although not specified in OpenPGP, it should select the newest one as long as it has no creation date in the future. Having such a default subkey flag would inhibit automatic key rollover. If we really want to specify handling of subkeys we should first discuss Ian Brown's suggestions for PFS. Shalom-Salam, Werner From owner-ietf-openpgp@mail.imc.org Wed Aug 14 03:53:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29632 for ; Wed, 14 Aug 2002 03:53:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7E7j6l11072 for ietf-openpgp-bks; Wed, 14 Aug 2002 00:45:06 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7E7j5w11068 for ; Wed, 14 Aug 2002 00:45:05 -0700 (PDT) Received: from async148-1.nas.onetel.net.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Wed, 14 Aug 2002 08:44:47 +0100 From: Ian Brown To: ietf-openpgp Subject: RE: Primary subkey subpacket Date: Wed, 14 Aug 2002 08:44:56 +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) In-Reply-To: <877kithpxr.fsf@alberti.gnupg.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Werner Koch wrote: > Having such a default subkey flag would inhibit automatic key > rollover. If we really want to specify handling of subkeys we should > first discuss Ian Brown's suggestions for PFS. (and Adam Back and Ben Laurie's. They're at http://www.cs.ucl.ac.uk/staff/I.Brown/draft-brown-pgp-pfs-03.txt, although the draft has expired.) Briefly, we suggested that for perfect forward secrecy, the subkey closest to its expiration date should be used. This is because the owner can wipe that subkey soonest, reducing the possibility that an attacker with a copy of the message ciphertext will then be able to get the subkey required to decrypt it. The draft's progress has stalled as the IESG liked the idea and suggested we go for standards track rather than informational publication; but I think they are waiting from some positive response from the working group on that. Do people think it's worth pursuing, either as informational or standards track? John Noerenberg thought it might be useful to split the document into a small standards track document defining the subkey flags we suggest (or even incorporate that into the rfc2440-bis draft, although we're likely too late for that now) along with a longer informational draft on using the protocol features for PFS. But we weren't sure if this more convoluted route was more useful. Any thoughts? Thanks, Ian From owner-ietf-openpgp@mail.imc.org Wed Aug 14 08:43:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07111 for ; Wed, 14 Aug 2002 08:43:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7ECX7Q11353 for ietf-openpgp-bks; Wed, 14 Aug 2002 05:33:07 -0700 (PDT) Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7ECX4w11347 for ; Wed, 14 Aug 2002 05:33:05 -0700 (PDT) Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Wed, 14 Aug 2002 14:27:53 0200 Message-ID: <3D5A4CC9.DDE9E3BF@saiknes.lv> Date: Wed, 14 Aug 2002 14:27:53 +0200 From: disastry@saiknes.lv 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: Primary subkey subpacket 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 Timo Schulz wrote: > Recently I stumbled over a problems with multiple subkeys. I know > PGP doesn't let the user choose the key at all and GPG uses the > newest key by default. What about a "primary subkey" subpacket > which is placed on the self signature to force the implementation > to use a special subkey. The format should be similar to the > "primary user id" packet. where do you want to place it? in subkey binding sig? that would be odd.. because this means creating another binding sig (when making new subkey(s)), and OpenPGP does not allow multiple binding sigs (unlike userid self sig), and then keyserver problems, etc.. I think it may be better to put this in userid self sig (this would allow different subkeys for different userids), but then format can't be like "primary user id" (5.2.3.19.) subpacket, it can be like Issuer (5.2.3.5.) or even better like Revocation key (5.2.3.15.) subpacket __ Disastry http://disastry.dhs.org/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPVowpzBaTVEuJQxkEQMe1wCfUxOwO6zizzYmI40Gfl4pRxU4oK8AoNH8 /Zbj9VsWRMLt5Y/OOPPcUnw+ =c2b8 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Aug 14 10:48:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11843 for ; Wed, 14 Aug 2002 10:48:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EEej920752 for ietf-openpgp-bks; Wed, 14 Aug 2002 07:40:45 -0700 (PDT) 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 g7EEeiw20746 for ; Wed, 14 Aug 2002 07:40:44 -0700 (PDT) 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 g7EEfJO24386 for ; Wed, 14 Aug 2002 10:41:19 -0400 (EDT) To: OpenPGP Subject: Anybody know details about Schneier's "flaw"? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 14 Aug 2002 09:40:39 -0500 X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 08/14/2002 10:40:42 AM, Serialize complete at 08/14/2002 10:40:42 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0050A08D86256C15_=" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multipart message in MIME format. --=_alternative 0050A08D86256C15_= Content-Type: text/plain; charset="us-ascii" In http://netscape.com.com/2100-1105-949506.html?type=pt there is a vague mention of a problem: Schneier released information Monday about a separate flaw in the PGP (Pretty Good Privacy) program that is freely available and used to encrypt messages sent over the Internet. Schneier and Jonathan Katz of the University of Maryland at College Park found a way an attacker could intercept a PGP encrypted message, modify it without decrypting it, dupe the user into sending it back, and retrieve the original message Does anybody know more about this? Can a minor improvement to the new -bis draft fix it? --John --=_alternative 0050A08D86256C15_= Content-Type: text/html; charset="us-ascii"
In http://netscape.com.com/2100-1105-949506.html?type=pt there is a vague mention of a problem:


Schneier released information Monday about a separate flaw in the PGP (Pretty Good Privacy) program that is freely available and used to encrypt messages sent over the Internet.

Schneier and Jonathan Katz of the University of Maryland at College Park found a way an attacker could intercept a PGP encrypted message, modify it without decrypting it, dupe the user into sending it back, and retrieve the original message




Does anybody know more about this?  Can a minor improvement to the new -bis draft fix it?

--John
--=_alternative 0050A08D86256C15_=-- From owner-ietf-openpgp@mail.imc.org Wed Aug 14 10:59:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12350 for ; Wed, 14 Aug 2002 10:59:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EEsLj21526 for ietf-openpgp-bks; Wed, 14 Aug 2002 07:54:21 -0700 (PDT) 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 g7EEsJw21518 for ; Wed, 14 Aug 2002 07:54:19 -0700 (PDT) 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 KAA20795; Wed, 14 Aug 2002 10:54:20 -0400 (EDT) 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 KAA11766; Wed, 14 Aug 2002 10:50:22 -0400 (EDT) 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 KAA25798; Wed, 14 Aug 2002 10:50:21 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA02544; Wed, 14 Aug 2002 10:50:21 -0400 (EDT) To: john.dlugosz@kodak.com Cc: OpenPGP Subject: Re: Anybody know details about Schneier's "flaw"? References: From: Derek Atkins Date: 14 Aug 2002 10:50:21 -0400 In-Reply-To: Message-ID: Lines: 17 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: john.dlugosz@kodak.com writes: > Does anybody know more about this? Can a minor improvement to the new > -bis draft fix it? a) this only works if you do NOT compress your messages before you encrypt. b) this only works if you do NOT sign the message AND you do NOT use an MDC > --John -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Wed Aug 14 12:32:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15904 for ; Wed, 14 Aug 2002 12:32:18 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EGNgw26657 for ietf-openpgp-bks; Wed, 14 Aug 2002 09:23:42 -0700 (PDT) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7EGNew26647 for ; Wed, 14 Aug 2002 09:23:40 -0700 (PDT) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtp (Exim 4.05) id 17f0vt-0004Q2-00 for ietf-openpgp@imc.org; Wed, 14 Aug 2002 18:23:41 +0200 Received: from a5f9e.pppool.de ([213.6.95.158] helo=daredevil) by mx2.freenet.de with esmtp (Exim 4.05 #1) id 17f0vt-000480-00 for ietf-openpgp@imc.org; Wed, 14 Aug 2002 18:23:41 +0200 Received: from twoaday by daredevil with local (Exim 3.35 #1 (Debian)) id 17f11F-0000D0-00 for ; Wed, 14 Aug 2002 18:29:13 +0200 Date: Wed, 14 Aug 2002 18:29:13 +0200 From: Timo Schulz To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket Message-ID: <20020814162913.GA786@daredevil.joesixpack.net> Reply-To: twoaday@freakmail.de Mail-Followup-To: ietf-openpgp@imc.org References: <3D5A4CC9.DDE9E3BF@saiknes.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5A4CC9.DDE9E3BF@saiknes.lv> X-PGP-KeyID: BF3DF9B4 X-PGP-Request: lynx -source http://www.winpt.org/twoaday.asc User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed Aug 14 2002; 14:27, disastry@saiknes.lv wrote: > > which is placed on the self signature to force the implementation ^^^^^^^^^^^^^^ [snip] > where do you want to place it? In the self signature. > I think it may be better to put this in userid self sig > (this would allow different subkeys for different userids), > but then format can't be like "primary user id" (5.2.3.19.) subpacket, Yes, I see this is a problem. The easiest solution would be to put it in a signature which is part of the public key to have a non-ambiguous assignment. Timo From owner-ietf-openpgp@mail.imc.org Wed Aug 14 12:40:56 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16148 for ; Wed, 14 Aug 2002 12:40:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EGYQT28207 for ietf-openpgp-bks; Wed, 14 Aug 2002 09:34:26 -0700 (PDT) Received: from yancey.pkiclue.com ([209.172.115.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7EGYOw28200 for ; Wed, 14 Aug 2002 09:34:24 -0700 (PDT) Received: from ferg237.pkiclue.com (IDENT:root@[127.0.0.1]) by yancey.pkiclue.com (8.9.3/8.9.3) with ESMTP id JAA10802 for ; Wed, 14 Aug 2002 09:33:59 -0700 Message-Id: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> X-Sender: pkiclue@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 14 Aug 2002 09:34:03 -0700 To: ietf-openpgp@imc.org From: Rodney Thayer Subject: Re: Anybody know details about Schneier's "flaw"? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think it's got too many odd things in it to require compression. Basically it's a "if you let yourself get social engineered then your crypto can be used against you" attack. At 10:50 AM 8/14/2002 -0400, Derek Atkins wrote: >john.dlugosz@kodak.com writes: > > > Does anybody know more about this? Can a minor improvement to the new > > -bis draft fix it? > >a) this only works if you do NOT compress your messages before you encrypt. >b) this only works if you do NOT sign the message AND you do NOT use an MDC > > > --John From owner-ietf-openpgp@mail.imc.org Wed Aug 14 12:57:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16849 for ; Wed, 14 Aug 2002 12:57:24 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7EGpoj29495 for ietf-openpgp-bks; Wed, 14 Aug 2002 09:51:50 -0700 (PDT) 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 g7EGpnw29489 for ; Wed, 14 Aug 2002 09:51:49 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA12421; Wed, 14 Aug 2002 12:51:50 -0400 (EDT) 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 MAA14125; Wed, 14 Aug 2002 12:51:49 -0400 (EDT) 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 MAA26160; Wed, 14 Aug 2002 12:51:48 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA02753; Wed, 14 Aug 2002 12:51:48 -0400 (EDT) To: Rodney Thayer Cc: ietf-openpgp@imc.org From: Derek Atkins Subject: Re: Anybody know details about Schneier's "flaw"? References: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> Date: 14 Aug 2002 12:51:48 -0400 In-Reply-To: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> Message-ID: Lines: 14 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: Rodney Thayer writes: > I think it's got too many odd things in it to require compression. Indeed.. As I said (perhaps incoherently), the attack only works if you DO NOT compress. If you compress the message then there is no way to XOR against the message. -derek -- Derek Atkins Computer and Internet Security Consultant derek@ihtfp.com www.ihtfp.com From owner-ietf-openpgp@mail.imc.org Wed Aug 14 13:12:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17563 for ; Wed, 14 Aug 2002 13:12:31 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EH5wk00145 for ietf-openpgp-bks; Wed, 14 Aug 2002 10:05:58 -0700 (PDT) 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 g7EH5vw00141 for ; Wed, 14 Aug 2002 10:05:57 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7EH5rr05964 for ietf-openpgp@imc.org; Wed, 14 Aug 2002 13:05:53 -0400 Date: Wed, 14 Aug 2002 13:05:53 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket Message-ID: <20020814170553.GE682@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020813215844.GA20328@daredevil.joesixpack.net> <877kithpxr.fsf@alberti.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877kithpxr.fsf@alberti.gnupg.de> 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 (40% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 14, 2002 at 09:14:56AM +0200, Werner Koch wrote: > > On Tue, 13 Aug 2002 23:58:44 +0200, Timo Schulz said: > > > Recently I stumbled over a problems with multiple subkeys. I know > > PGP doesn't let the user choose the key at all and GPG uses the > > newest key by default. What about a "primary subkey" subpacket > > I don't think this is needed. If a subkey is published a sending > implementation may choose any of the valid subkeys for encryption. > Although not specified in OpenPGP, it should select the newest one as > long as it has no creation date in the future. I imagine a primary subkey flag as more of a tie-breaker. If an implementation wanted to ignore the flag (whether for PFS or other reasons), that would be fine. If the implementation did not care, or could not reach a decision, the primary subkey would be chosen. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From owner-ietf-openpgp@mail.imc.org Wed Aug 14 17:12:37 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25200 for ; Wed, 14 Aug 2002 17:12:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EKuvn14708 for ietf-openpgp-bks; Wed, 14 Aug 2002 13:56:57 -0700 (PDT) Received: from mail.epost.de (web.epost.de [193.28.100.164] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7EKutw14704 for ; Wed, 14 Aug 2002 13:56:55 -0700 (PDT) Received: from dirichlet.mathematik.uni-bielefeld.de (80.130.173.9) by mail.epost.de (5.5.056) (authenticated as Marc.Mutz@epost.de) id 3D59336300019931; Wed, 14 Aug 2002 22:55:22 +0200 From: Marc Mutz Organization: KDE To: john.dlugosz@kodak.com, OpenPGP Subject: Re: Anybody know details about Schneier's "flaw"? Date: Wed, 14 Aug 2002 22:42:09 +0200 User-Agent: KMail/1.4.6 References: In-Reply-To: X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200208142242.10470@sendmail.mutz.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7EKuuw14705 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 14 August 2002 16:40, john.dlugosz@kodak.com wrote: > In http://netscape.com.com/2100-1105-949506.html?type=pt there is a > vague mention of a problem: > Does anybody know more about this? Can a minor improvement to the > new -bis draft fix it? Do you mean this: www.counterpane.com/pgp-attack.html or something else? Marc - -- Mutig warf sich die kleine Überwachungskamera zwischen Täter Opfer! --Rena Tangens / FoeBuD e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9WsCh3oWD+L2/6DgRAqVFAJ9z9m/5tla4yV5lGeMmJOdrEnJMWACg+hNj 5mx4M2stDrwzlOfbUK4ncw4= =WEJd -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Aug 14 17:38:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25676 for ; Wed, 14 Aug 2002 17:38:06 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7ELRFX15925 for ietf-openpgp-bks; Wed, 14 Aug 2002 14:27:15 -0700 (PDT) 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 g7ELRDw15921 for ; Wed, 14 Aug 2002 14:27:13 -0700 (PDT) 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 g7ELRkO00135; Wed, 14 Aug 2002 17:27:46 -0400 (EDT) To: warlord@mit.edu Cc: OpenPGP Subject: Re: Anybody know details about Schneier's "flaw"? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 14 Aug 2002 16:27:08 -0500 X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 08/14/2002 05:27:11 PM, Serialize complete at 08/14/2002 05:27:11 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0075D77A86256C15_=" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multipart message in MIME format. --=_alternative 0075D77A86256C15_= Content-Type: text/plain; charset="us-ascii" According to the link posted by someone else, (www.counterpane.com/pgp-attack.html), "We also recommend changes in the OpenPGP standard [3 ]to educe the effectiveness of ou attacks in these settings." Are the people activly working on the -bis draft aware of this? --John --=_alternative 0075D77A86256C15_= Content-Type: text/html; charset="us-ascii"
According to the link posted by someone else, (www.counterpane.com/pgp-attack.html), "We also recommend changes in the OpenPGP standard [3 ]to educe the effectiveness of ou attacks in these settings."

Are the people activly working on the -bis draft aware of this?

--John
--=_alternative 0075D77A86256C15_=-- From owner-ietf-openpgp@mail.imc.org Thu Aug 15 02:29:09 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14814 for ; Thu, 15 Aug 2002 02:29:08 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7F6KLr14151 for ietf-openpgp-bks; Wed, 14 Aug 2002 23:20:21 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7F6KKw14144 for ; Wed, 14 Aug 2002 23:20:20 -0700 (PDT) Received: from [63.73.97.184] (63.73.97.184) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Wed, 14 Aug 2002 23:20:14 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 14 Aug 2002 23:20:20 -0700 Subject: Re: Anybody know details about Schneier's "flaw"? From: Jon Callas To: , CC: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8/14/02 2:27 PM, "john.dlugosz@kodak.com" wrote: > According to the link posted by someone else, > (www.counterpane.com/pgp-attack.html), "We also recommend changes in the > OpenPGP standard [3 ]to educe the > effectiveness of ou attacks in these settings." > > Are the people activly working on the -bis draft aware of this? Yes, we are aware of it. We released bis-06 on Monday with language in it to address this. We were advised about this a month ago, and have had quite a good email conversation with the authors about it. The text that is in there is some talk in the sections on compression, which say that a decompression error should be considered to be a security problem, not a data problem (in other words, don't typically let the user have the damaged plaintext), and some language that recommends encouraging people to use MDCs. There is also a relatively long section in Security Considerations. Take a look, I think you'll like it. Jon From owner-ietf-openpgp@mail.imc.org Thu Aug 15 03:59:13 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16476 for ; Thu, 15 Aug 2002 03:59:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7F7or626622 for ietf-openpgp-bks; Thu, 15 Aug 2002 00:50:53 -0700 (PDT) Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7F7oqw26614 for ; Thu, 15 Aug 2002 00:50:52 -0700 (PDT) Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Thu, 15 Aug 2002 09:50:35 0200 Message-ID: <3D5B5D4B.34F675FE@saiknes.lv> Date: Thu, 15 Aug 2002 09:50:35 +0200 From: disastry@saiknes.lv 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: Primary subkey subpacket 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 Timo Schulz wrote: > On Wed Aug 14 2002; 14:27, disastry@saiknes.lv wrote: > > > > which is placed on the self signature to force the implementation > ^^^^^^^^^^^^^^ > [snip] > > where do you want to place it? > > In the self signature. in which self signature?: 5.2.3.3. Notes on Self-Signatures A self-signature is a binding signature made by the key the signature refers to. There are three types of self-signatures, the certification signatures (types 0x10-0x13), the direct-key signature (type 0x1f), and the subkey binding signature (type 0x18). For __ Disastry http://disastry.dhs.org/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPVtBCTBaTVEuJQxkEQPWmACgq6ZCbzgNeOoTsGEMqYgOcFclKr0AoNMP lRySaU0dgUZqgoHFSKI77btA =383/ -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Aug 15 03:59:33 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16496 for ; Thu, 15 Aug 2002 03:59:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7F7pc726777 for ietf-openpgp-bks; Thu, 15 Aug 2002 00:51:38 -0700 (PDT) Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7F7pbw26768 for ; Thu, 15 Aug 2002 00:51:37 -0700 (PDT) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.5/8.12.1) with ESMTP id g7F7pZ1O015624 for ; Thu, 15 Aug 2002 09:51:35 +0200 Received: (from news@localhost) by branwen.iks-jena.de (8.12.5/8.12.1/Submit) id g7F7pZT7015623 for ietf-openpgp@imc.org; Thu, 15 Aug 2002 09:51:35 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Anybody know details about Schneier's "flaw"? Date: Thu, 15 Aug 2002 07:51:35 +0000 (UTC) Organization: IKS GmbH Jena Lines: 9 Message-ID: References: NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1029397895 15611 217.17.192.37 (15 Aug 2002 07:51:35 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Thu, 15 Aug 2002 07:51:35 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Jon Callas wrote: >The text that is in there is some talk in the sections on compression, which >say that a decompression error should be considered to be a security >problem, not a data problem (in other words, don't typically let the user >have the damaged plaintext), and some language that recommends encouraging >people to use MDCs. There is also a relatively long section in Security >Considerations. Take a look, I think you'll like it. Fine. I don't support Schneiers Claim to withdraw 'uncompressed'-compression. From owner-ietf-openpgp@mail.imc.org Thu Aug 15 06:19:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19734 for ; Thu, 15 Aug 2002 06:19:45 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7FAAj313565 for ietf-openpgp-bks; Thu, 15 Aug 2002 03:10:45 -0700 (PDT) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7FAAhw13560 for ; Thu, 15 Aug 2002 03:10:43 -0700 (PDT) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtp (Exim 4.05) id 17fHaU-0004R0-00 for ietf-openpgp@imc.org; Thu, 15 Aug 2002 12:10:42 +0200 Received: from a62b6.pppool.de ([213.6.98.182] helo=daredevil) by mx2.freenet.de with esmtp (Exim 4.05 #1) id 17fHaU-0002Fh-00 for ietf-openpgp@imc.org; Thu, 15 Aug 2002 12:10:42 +0200 Received: from twoaday by daredevil with local (Exim 3.35 #1 (Debian)) id 17fHPp-0000Df-00 for ; Thu, 15 Aug 2002 11:59:41 +0200 Date: Thu, 15 Aug 2002 11:59:41 +0200 From: Timo Schulz To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket Message-ID: <20020815095941.GB828@daredevil.joesixpack.net> Reply-To: twoaday@freakmail.de Mail-Followup-To: ietf-openpgp@imc.org References: <3D5B5D4B.34F675FE@saiknes.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5B5D4B.34F675FE@saiknes.lv> X-PGP-KeyID: BF3DF9B4 X-PGP-Request: lynx -source http://www.winpt.org/twoaday.asc User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu Aug 15 2002; 09:50, disastry@saiknes.lv wrote: > in which self signature?: > > 5.2.3.3. Notes on Self-Signatures [snip] Yes, I'm aware we can't use the self signature but this packet would need a central place because otherwise it would no make sense. The best idea is somewhere in a signature which carries the public key because there is only one public key and this would be central. Timo From owner-ietf-openpgp@mail.imc.org Thu Aug 15 21:04:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21921 for ; Thu, 15 Aug 2002 21:04:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7G0qNB06575 for ietf-openpgp-bks; Thu, 15 Aug 2002 17:52:23 -0700 (PDT) Received: from yancey.pkiclue.com (IDENT:root@[209.172.115.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7G0qLw06568 for ; Thu, 15 Aug 2002 17:52:21 -0700 (PDT) Received: from ferg237.pkiclue.com (IDENT:root@[127.0.0.1]) by yancey.pkiclue.com (8.9.3/8.9.3) with ESMTP id RAA11428; Thu, 15 Aug 2002 17:52:01 -0700 Message-Id: <5.1.1.6.2.20020815174759.02572e28@127.0.0.1> X-Sender: pkiclue@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 15 Aug 2002 17:49:00 -0700 To: Derek Atkins From: Rodney Thayer Subject: Re: Anybody know details about Schneier's "flaw"? Cc: ietf-openpgp@imc.org In-Reply-To: References: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020814093305.01451338@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: my point was, requiring implementors to do compression sucks, in my opinion. this attack is insufficient justification. the attack is a social engineering attack. forcing implementors to add onerous code to defend against it is not a good idea. At 12:51 PM 8/14/2002 -0400, Derek Atkins wrote: >Rodney Thayer writes: > > > I think it's got too many odd things in it to require compression. > >Indeed.. As I said (perhaps incoherently), the attack only works if >you DO NOT compress. If you compress the message then there is no way >to XOR against the message. From owner-ietf-openpgp@mail.imc.org Thu Aug 15 22:23:46 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA23535 for ; Thu, 15 Aug 2002 22:23:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7G2DgK09582 for ietf-openpgp-bks; Thu, 15 Aug 2002 19:13:42 -0700 (PDT) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7G2Dew09576 for ; Thu, 15 Aug 2002 19:13:42 -0700 (PDT) Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 17fWcQ-002R4M-00; Fri, 16 Aug 2002 03:13:42 +0100 Date: Fri, 16 Aug 2002 03:13:42 +0100 From: Adam Back To: Rodney Thayer Cc: Derek Atkins , ietf-openpgp@imc.org Subject: Re: Anybody know details about Schneier's "flaw"? Message-ID: <20020816031342.A599725@exeter.ac.uk> References: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020815174759.02572e28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: <5.1.1.6.2.20020815174759.02572e28@127.0.0.1>; from rodney@tillerman.to on Thu, Aug 15, 2002 at 05:49:00PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree. Increasing use of MDC is a better more direct solution. (It's also a more robust solution -- how long until someone manages to propogate the attack through compression -- it's not as if compression were designed to prevent it.) Also the attack for those who haven't read the paper is really low-tech. They're just observing that if you can ask someone to decrypt a message you can use that to decrypt related messages. So you intentionally garble a message, and hope the user sends you the garbled plaintext back to you to ask what went wrong. The rest falls out of the fact that if you garble a few bits of a ciphertext most of the plaintext will still be intact. So it's related to the earlier observation that unless a message is signed you can undetectably (to PGP) garble it's contents. This also was hard to do if the message was compressed. This was the motivation for the MDC. Adam On Thu, Aug 15, 2002 at 05:49:00PM -0700, Rodney Thayer wrote: > > my point was, requiring implementors to do compression sucks, > in my opinion. this attack is insufficient justification. > > the attack is a social engineering attack. forcing implementors > to add onerous code to defend against it is not a good idea. > > At 12:51 PM 8/14/2002 -0400, Derek Atkins wrote: > > >Rodney Thayer writes: > > > > > I think it's got too many odd things in it to require compression. > > > >Indeed.. As I said (perhaps incoherently), the attack only works if > >you DO NOT compress. If you compress the message then there is no way > >to XOR against the message. > From owner-ietf-openpgp@mail.imc.org Sat Aug 17 08:56:18 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24895 for ; Sat, 17 Aug 2002 08:56:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7HCgkt19328 for ietf-openpgp-bks; Sat, 17 Aug 2002 05:42:46 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7HCgjw19322 for ; Sat, 17 Aug 2002 05:42:46 -0700 (PDT) Received: from p4 ([12.224.48.160]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020817124231.IDUW1746.rwcrmhc51.attbi.com@p4> for ; Sat, 17 Aug 2002 12:42:31 +0000 Message-Id: <3.0.5.32.20020817054229.0229a930@localhost> X-Sender: cme@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 17 Aug 2002 05:42:29 -0700 To: ietf-openpgp@imc.org From: Carl Ellison Subject: Re: Anybody know details about Schneier's "flaw"? In-Reply-To: <20020816031342.A599725@exeter.ac.uk> References: <5.1.1.6.2.20020815174759.02572e28@127.0.0.1> <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020815174759.02572e28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 03:13 AM 8/16/2002 +0100, Adam Back wrote: >Also the attack for those who haven't read the paper is really >low-tech. They're just observing that if you can ask someone to >decrypt a message you can use that to decrypt related messages. So >you intentionally garble a message, and hope the user sends you the >garbled plaintext back to you to ask what went wrong. The rest >falls out of the fact that if you garble a few bits of a ciphertext >most of the plaintext will still be intact. Y'know, there's an even simpler attack with the same premise. You intercept an encrypted e-mail from Alice to Bob. You take the mail body out of the message and send that body to Bob under your e-mail address (or under some address you control that Bob might mistake for Alice's, which would be even better). Bob decrypts the message and replies to it, including the original message body by default. The mistake here, on Bob's part, is to reply to a message without paying attention to the e-mail address being used -- rather than replying to a message with quoted garbage rather than just saying "that was garbage -- send again". - Carl -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPV5EtHPxfjyW5ytxEQI12ACg3NB4hVzj9Og2VB0dpz6CNtdv9IUAniTD AK7BRrNff1maSKf+z/RzYkcV =nq3Z -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://world.std.com/~cme | | PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ From owner-ietf-openpgp@mail.imc.org Mon Aug 19 06:01:05 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26802 for ; Mon, 19 Aug 2002 06:01:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7J9niR13625 for ietf-openpgp-bks; Mon, 19 Aug 2002 02:49:44 -0700 (PDT) Received: from mail.glueckkanja.com (mail.glueckkanja.com [62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7J9ngw13614 for ; Mon, 19 Aug 2002 02:49:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Anybody know details about Schneier's "flaw"? Date: Mon, 19 Aug 2002 11:49:23 +0200 Message-ID: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> Thread-Topic: Re: Anybody know details about Schneier's "flaw"? thread-index: AcJF7a2ecgkqG9KoQWeAfHbfGnfZMgBdonGAAABUb2A= From: "Dominikus Scherkl" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7J9niw13621 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit > Y'know, there's an even simpler attack with the same premise. You > intercept an encrypted e-mail from Alice to Bob. You take the mail > body out of the message and send that body to Bob under your e-mail > address (or under some address you control that Bob might mistake for > Alice's, which would be even better). Bob decrypts the message and > replies to it, including the original message body by default. > > The mistake here, on Bob's part, is to reply to a message without > paying attention to the e-mail address being used The Flaw I see (on the whole attack) is: Why should anybody relpy cleartext to an encrypted messge? especialy if it contains (even parts) of the encrypted message? And if anybody does, why he's using encryption at all?!? If a reply is sent at all, it should be encrypted, so an interceptor has the same problem with the reply - he needs to break the key. And if it's the sender himself who want's to cheat him, he knows the message content very well, so what does he want to gain?!? The whole attack looks very suspicious to me... -- Dominikus Scherkl dominikus.scherkl@glueckkanja.com From owner-ietf-openpgp@mail.imc.org Mon Aug 19 07:37:25 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28548 for ; Mon, 19 Aug 2002 07:37:25 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7JBU0F19339 for ietf-openpgp-bks; Mon, 19 Aug 2002 04:30:00 -0700 (PDT) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JBTvw19333 for ; Mon, 19 Aug 2002 04:29:58 -0700 (PDT) Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g7JBTX8W008198; Mon, 19 Aug 2002 23:29:33 +1200 Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA214939; Mon, 19 Aug 2002 23:29:30 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Date: Mon, 19 Aug 2002 23:29:30 +1200 (NZST) Message-ID: <200208191129.XAA214939@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Dominikus.Scherkl@glueckkanja.com, ietf-openpgp@imc.org Subject: Re: Anybody know details about Schneier's "flaw"? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Dominikus Scherkl" writes: >The whole attack looks very suspicious to me... On the grand scale of things, it has curiosity value, but not much more. There are a pile of other attacks which fall into the same class, e.g. concern over the Bleichenbacher attack on SSL being used against S/MIME email (come to think of it, that one never came up on open-pgp). My thoughts on this at the time, which also apply to this attack, were: -- Snip -- [...] this attack requires that an attacker send you around a million pieces of CMS encrypted email with attached receipt requests, that you respond with a million receipts indicating to the attacker the exact details of why the decrypt failed, that you reuse the same per-message key for each of those million messages. Now maybe I'm being a bit optimistic here, but I do think that claiming this is a weakness is a pretty silly. First of all you need to assume that an attacker can somehow send you a million pieces of email without you noticing and without it getting stopped by spam blockers. Your own software then has to try to decrypt each of the one million pieces of email, find that it can't, and send out a receipt to the sender containing an indication of exactly how the decryption failed (this isn't possible even if you wanted to do it, although who knows what the Receipt Notification WG have been working on recently). Finally, the whole attack only works if you reuse cryptovariables. This is why the CERT advisory on this problem specifically points out "This vulnerability does not affect S/MIME or SET". As a security threat, I'd say this rates somewhere down with "Router hit by meteorite", "Computer trampled by stampeding water buffalo", "Hard drive kidnapped by space aliens", and similar stuff. Sure, it is in theory possible, if you try really, really hard and are willing to bend over backwards to cooperate with an attacker, to allow this kind of attack to occur. [...] You're more likely to get someone's key by asking them for it (I've seen this happen a number of times, in some cases without even needing to ask for it, by people who assume that "PKCS #12 == certificate" and send out their "certificate" for others to use) than by using this kind of attack. Just because it's (theoretically) possible to break into Fort Knox with a can opener doesn't mean that Kentucky is going to start screening people at the border for possession of said item. -- Snip -- A better way of putting that last sentence is given in one of my favourite computing quotes, by Chris Strachey: "The fact that it's possible to push a pea up a mountain with your nose doesn't mean that this is a sensible way of getting it there". Peter. From owner-ietf-openpgp@mail.imc.org Mon Aug 19 07:40:11 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28614 for ; Mon, 19 Aug 2002 07:40:11 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7JBYxT19637 for ietf-openpgp-bks; Mon, 19 Aug 2002 04:34:59 -0700 (PDT) Received: from atlas.acter.ch ([212.126.160.108]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JBYww19632 for ; Mon, 19 Aug 2002 04:34:58 -0700 (PDT) Received: by atlas.acter.ch (Postfix, from userid 1047) id 09E0021A0; Mon, 19 Aug 2002 13:34:46 +0200 (CEST) Subject: Re: Anybody know details about Schneier's "flaw"? From: "Adrian 'Dagurashibanipal' von Bidder" To: ietf-openpgp@imc.org In-Reply-To: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> References: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1G2tKlk5KHHHBs/KYBUY" X-Mailer: Ximian Evolution 1.0.8 Date: 19 Aug 2002 13:34:46 +0200 Message-Id: <1029756886.31083.125.camel@atlas> Mime-Version: 1.0 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-1G2tKlk5KHHHBs/KYBUY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [please leave attribution in when replying] On Mon, 2002-08-19 at 11:49, Dominikus Scherkl wrote: > > The mistake here, on Bob's part, is to reply to a message without > > paying attention to the e-mail address being used [...] > The whole attack looks very suspicious to me... I guess the correct 'solution' to prevent the 'attack' would be to file bug reports with gpg-aware mail clients that do not at least display a warning when replying to/forwarding an originally encrypted message unencrypted. cheers -- vbi --=20 secure email with gpg http://fortytwo.ch/gpg --=-1G2tKlk5KHHHBs/KYBUY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9YNfWwj49sl5Lcx8RAnajAJ9wWptZqJMBxC19txdY/uiR7HG5zACfSu6O AO6zbRoorgWA8jpKKWm8jRU= =v06T -----END PGP SIGNATURE----- --=-1G2tKlk5KHHHBs/KYBUY-- From owner-ietf-openpgp@mail.imc.org Mon Aug 19 08:05:19 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29276 for ; Mon, 19 Aug 2002 08:05:19 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7JBu4a20631 for ietf-openpgp-bks; Mon, 19 Aug 2002 04:56:04 -0700 (PDT) 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 g7JBu2w20624 for ; Mon, 19 Aug 2002 04:56:02 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17gmJ9-0000Ca-00; Mon, 19 Aug 2002 15:10:59 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17glBe-0004W6-00; Mon, 19 Aug 2002 13:59:10 +0200 To: "Dominikus Scherkl" Cc: Subject: Re: Anybody know details about Schneier's "flaw"? References: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH Date: Mon, 19 Aug 2002 13:59:10 +0200 In-Reply-To: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> ("Dominikus Scherkl"'s message of "Mon, 19 Aug 2002 11:49:23 +0200") Message-ID: <87wuqnf4a9.fsf@alberti.gnupg.de> Lines: 35 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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 Mon, 19 Aug 2002 11:49:23 +0200, Dominikus Scherkl said: > Why should anybody relpy cleartext to an encrypted messge? > especialy if it contains (even parts) of the encrypted message? You will often notice plaintext message like "I could not decrypt your message - please use key 0x12345678" or "Where do I find your key". So it is not unlikely to see a message "Hey, your encrypted mail was garbled, please send it again. Here is the problematic line..". Most users don't know about the cryptograhic issues involved in sending parts of the plaintext back. A good MUA should protect against that but well a user can always override it. > If a reply is sent at all, it should be encrypted, so an interceptor > has the same problem with the reply - he needs to break the key. I am probably not the only one with this problem: Try to get my key from a keyserver - it is probably not usable because the subkeys are all garbled (Most people don't look at the mail header X-Request-PGP to find out the canonical way to get my key). So it is very likely to get a plaintext response; users are thus used to that and they can't imagine what serious consequences a reply with a very short and after all unreadable quote should have. All over the place OpenPGP is rightfully very paranoid and thus it makes sense to do what we can to avoid shoot-your-self-in-the-foot traps. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Mon Aug 19 09:01:34 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00634 for ; Mon, 19 Aug 2002 09:01:34 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7JCsJe23307 for ietf-openpgp-bks; Mon, 19 Aug 2002 05:54:19 -0700 (PDT) Received: from atlas.acter.ch ([212.126.160.108]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JCsIw23303 for ; Mon, 19 Aug 2002 05:54:18 -0700 (PDT) Received: by atlas.acter.ch (Postfix, from userid 1047) id DDC81C3B0; Mon, 19 Aug 2002 14:54:18 +0200 (CEST) Subject: Re: Anybody know details about Schneier's "flaw"? From: "Adrian 'Dagurashibanipal' von Bidder" To: ietf-openpgp@imc.org In-Reply-To: <200208191129.XAA214939@ruru.cs.auckland.ac.nz> References: <200208191129.XAA214939@ruru.cs.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c6HIAhDluoStiSC+MQqb" X-Mailer: Ximian Evolution 1.0.8 Date: 19 Aug 2002 14:54:18 +0200 Message-Id: <1029761658.29620.7.camel@atlas> Mime-Version: 1.0 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-c6HIAhDluoStiSC+MQqb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-08-19 at 13:29, Peter Gutmann wrote: >=20 > "Dominikus Scherkl" writes: >=20 > >The whole attack looks very suspicious to me... >=20 > On the grand scale of things, it has curiosity value, but not much more. = There [...] > As a security threat, I'd say this rates somewhere down with "Router hi= t by > meteorite", "Computer trampled by stampeding water buffalo", "Hard driv= e > kidnapped by space aliens", and similar stuff. >=20 > Sure, it is in theory possible, if you try really, really hard and are wi= lling > to bend over backwards to cooperate with an attacker, to allow this kind = of > attack to occur. [...] You're more likely to get someone's key by askin= g them As I've said in my other mail it's really a problem of some mailreaders being unclear. For example, evolution does not display any indication that the displayed message was encrypted. (You have to enter the passphrase the first time you look at an encrypted msg, but I usually tell it to store the passphrase for the session, causing it to auto-decrypt any further messages. In other words: on technical grounds, I absolutely agree with you. BUT with bad UIs in some mailreaders, and with the experience that users generally are more stupid than anyone would believe, this type of attack is very realistic. Bot, and here I'm sure that your opinion is the same, this discussion is not really on-topic on a technical mailing list...=20 cheers -- vbi --=20 secure email with gpg http://fortytwo.ch/gpg --=-c6HIAhDluoStiSC+MQqb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9YOp6wj49sl5Lcx8RAgpsAJwMA13QNVeYpVHm6iSU8TszXv2KTQCfVybq OpxFxs7p3+3d+mkYE0mzVDY= =p5IP -----END PGP SIGNATURE----- --=-c6HIAhDluoStiSC+MQqb-- From owner-ietf-openpgp@mail.imc.org Mon Aug 19 13:59:14 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11228 for ; Mon, 19 Aug 2002 13:59:14 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7JHqcs14181 for ietf-openpgp-bks; Mon, 19 Aug 2002 10:52:38 -0700 (PDT) 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 g7JHqbn14177 for ; Mon, 19 Aug 2002 10:52:37 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7JHqXr09314 for ietf-openpgp@imc.org; Mon, 19 Aug 2002 13:52:33 -0400 Date: Mon, 19 Aug 2002 13:52:33 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Notary signature implementation notes Message-ID: <20020819175233.GA9174@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline 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 Gibbous (90% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks, I recently roughed in some support for notary signatures in GnuPG. Here are some samples. The first attachment is the file the original signature was issued on. The second attachment is a detached signature on that file. The third attachment is a v4 0x50 signature on that signature, and the final attachment is a v3 0x50. All of these signatures were issued by key 0xD8B2D20C, currently on a friendly keyserver near you. I used the canonicalization rules Hal Finney suggested in http://www.imc.org/ietf-openpgp/mail-archive/msg04021.html except I used the constant 0x88 rather than 0x84 for the canonical CTB. I believe 0x84 was a typo since that would be a CTB for a session key packet. It was suggested that notary signatures always contain a signature target subpacket. After implementing notary signatures, I'm not sure how useful this would be given the current signature target subpacket. To create the subpacket, the notary needs to have the public key of the signer of the original signature in order to get the raw hash out of the original signature. That harms somewhat the nice feature of a notary signature that the notary does not need to know anything about the original document and its signer. One possible solution to this is to define the signature target subpacket as a canonical hash of the original signature rather than as the actual hash from the original signature. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=foo notary --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="foo.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.92 (GNU/Linux) iD8DBQE9YSjw+Tjeu9iy0gwRAknBAKCF7OW5ZRND7FQVUYZNy9wAsf+DrQCgiyFX PVJq/nmQhobwoId4iSzoBA0= =6eYH -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="v4.sig" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.92 (GNU/Linux) iEYEUBECAAYFAj1hKz4ACgkQ+Tjeu9iy0gy4WACgkWr3mwBNMANoe0z+p6wNC9B4 tqgAn1Kj0u7HodpPVUmgxQl+ny3gulXg =Zxfb -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="v3.sig" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.92 (GNU/Linux) iD8DBVA9YS5K+Tjeu9iy0gwRAq9uAJ9mpkSRKH//iekU6qxO9/69XXhAwQCgmxZ4 LX6smbOeKxHzX2XG/aOtQw8= =F5Ir -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- From owner-ietf-openpgp@mail.imc.org Mon Aug 19 14:44:03 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12432 for ; Mon, 19 Aug 2002 14:44:03 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7JIceN16514 for ietf-openpgp-bks; Mon, 19 Aug 2002 11:38:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JIcdn16510 for ; Mon, 19 Aug 2002 11:38:39 -0700 (PDT) Received: (from bcn@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7JIcgO15291; Mon, 19 Aug 2002 11:38:42 -0700 (PDT) Date: Mon, 19 Aug 2002 11:38:42 -0700 (PDT) Message-Id: <200208191838.g7JIcgO15291@boreas.isi.edu> From: Clifford Neuman To: ietf-openpgp@imc.org Subject: CFP - Symposium on Network & Distributed Systems Security Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Internet Society's (ISOC) annual Symposium on Network and Distributed System Security (NDSS) brings together innovative and forward thinking members of the Internet community including leading-edge security researchers and implementers, globally-recognized security-technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. If you are working on new and practical approaches to security problems that are endemic to network and distributed systems, we invite you to participate in NDSS'03 by submitting one or more technical papers and/or panel proposals. Submission details may be found at: http://www.isoc.org/isoc/conferences/ndss/03/cfp.shtml NDSS'03 will again be held for three days in San Diego, California in February, 2003. One day of tutorials will be followed by two days of technical sessions including refereed papers, invited talks, and panel discussions and debates. Please be aware that the NDSS'03 cut off date for paper and panel submission is August 30, 2002. All accepted papers will be published in The NDSS Proceedings by the Internet Society. There will also be an Outstanding Paper Award presented at the Symposium to the author(s). Submitted papers should not have been previously published or be submitted simultaneously to a journal or to another symposium or workshop with a published proceedings. Please consider joining us at NDSS'03. We look forward to hearing from you! Clifford Neuman, Information Sciences Institute, University of Southern California General Chair, NDSS'03 Virgil Gligor, University of Maryland Michael Reiter, Carnegie Mellon University Program Chairs, NDSS'03 From owner-ietf-openpgp@mail.imc.org Mon Aug 19 16:21:02 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14831 for ; Mon, 19 Aug 2002 16:21:01 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7JKDsL22828 for ietf-openpgp-bks; Mon, 19 Aug 2002 13:13:54 -0700 (PDT) Received: from mailout.zetnet.co.uk (mail@new-tonge.zetnet.co.uk [194.247.47.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JKDrn22822 for ; Mon, 19 Aug 2002 13:13:53 -0700 (PDT) Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk ident=root) by mailout.zetnet.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 17gsuQ-0002gt-00 for ; Mon, 19 Aug 2002 21:13:54 +0100 Received: from zetnet.co.uk (bts-0481.dialup.zetnet.co.uk [194.247.49.225]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g7JKDg832138 for ; Mon, 19 Aug 2002 21:13:42 +0100 Message-ID: <3D613AA3.85971B28@zetnet.co.uk> Date: Mon, 19 Aug 2002 18:36:19 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Anybody know details about Schneier's "flaw"? References: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> 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----- Dominikus Scherkl wrote: > Carl Ellison wrote: > > Y'know, there's an even simpler attack with the same premise. You > > intercept an encrypted e-mail from Alice to Bob. You take the mail > > body out of the message and send that body to Bob under your e-mail > > address (or under some address you control that Bob might mistake for > > Alice's, which would be even better). Bob decrypts the message and > > replies to it, including the original message body by default. In that case Bob sees the original message, and at least has the possibility of noting that it is not consistent with the reply-to address. If he sees garbage, that could be consistent with any reply-to address, unless Bob knows about this attack. This is all part of the same problem that has been pointed out before in the context of signing: the message content and the headers (including the reply-to address and hence the public key to be used to encrypt replies), are not treated as a unit cryptographically. > > The mistake here, on Bob's part, is to reply to a message without > > paying attention to the e-mail address being used > > The Flaw I see (on the whole attack) is: > Why should anybody reply cleartext to an encrypted message? The attack does not depend on the victim replying in cleartext. If the message is encrypted, it would be encrypted to the attacker's key. Peter Gutmann wrote: > On the grand scale of things, it has curiosity value, but not much more. There > are a pile of other attacks which fall into the same class, e.g. concern over > the Bleichenbacher attack on SSL being used against S/MIME email (come to think > of it, that one never came up on open-pgp). My thoughts on this at the time, > which also apply to this attack, were: > > -- Snip -- > > [...] this attack requires that an attacker send you around a million pieces > of CMS encrypted email with attached receipt requests, that you respond with > a million receipts indicating to the attacker the exact details of why the > decrypt failed, that you reuse the same per-message key for each of those > million messages. What on earth does this attack have to do with sending millions of messages? It requires one message, and is considerably more plausible than applying the Bleichenbacher attack to email (or would be, if it is wasn't prevented in practice by compression). - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPWE6izkCAxeYt5gVAQH7sAf6AklABDur8W+Aoq6FAMlSwprTkS9/ds6d jFk8vNqlF2RYQApMGmGCSBcoayNS4o9WwYBP0hIEaqv/9jTcZXHGnz11IoUoFbR8 fQIQEh5egiGeqyt43n1kojWEptA1MHN5VNBC+WeYMV0sJYvqiSM61NjIHJMUV94Y 3ueWpee4drXCYgjVRMH8PhXj1IoqIyhzzPtzaQ46s0hVaZcQIOE6vVuSqAwyXLmr qW52cjRZ8wIJjA5I4PPQcW8/IXSMcMvAkFLeG5HFcl9COmC+wRqJVgzhq6Q2du+8 qqLHAs23g/FsKIckBNaWeU0DSkIp0oZcxCcOjsAB3JFLkMiInhUE5w== =gZJl -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Aug 19 22:20:57 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20847 for ; Mon, 19 Aug 2002 22:20:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7K29e709945 for ietf-openpgp-bks; Mon, 19 Aug 2002 19:09:40 -0700 (PDT) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7K29b209938 for ; Mon, 19 Aug 2002 19:09:38 -0700 (PDT) Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g7K29Z8W026274; Tue, 20 Aug 2002 14:09:35 +1200 Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA259250; Tue, 20 Aug 2002 14:09:34 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Date: Tue, 20 Aug 2002 14:09:34 +1200 (NZST) Message-ID: <200208200209.OAA259250@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: david.hopwood@zetnet.co.uk, ietf-openpgp@imc.org Subject: Re: Anybody know details about Schneier's "flaw"? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Hopwood writes: >What on earth does this attack have to do with sending millions of messages? The point was that, like the Bleichenbacher attack on email, there are a large list of far more serious problems to worry about than something like this. However, as someone else has pointed out, this isn't the right forum to discuss them. Shall we take it to cypherpunks perhaps? Peter. From owner-ietf-openpgp@mail.imc.org Tue Aug 20 17:53:43 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28585 for ; Tue, 20 Aug 2002 17:53:43 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7KLhVY00931 for ietf-openpgp-bks; Tue, 20 Aug 2002 14:43:31 -0700 (PDT) Received: from hotmail.com (oe15.law3.hotmail.com [209.185.240.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7KLhT200927 for ; Tue, 20 Aug 2002 14:43:29 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Aug 2002 14:42:28 -0700 X-Originating-IP: [207.127.12.210] From: "vedaal" To: Subject: possible new type of pgp plaintext attack ? Date: Tue, 20 Aug 2002 17:40:15 -0400 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: 20 Aug 2002 21:42:28.0973 (UTC) FILETIME=[7B3BB1D0:01C24892] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit atfer reading the paper on the pgp reply/plaintext attack, was wondering if there might be an additional way to mount a different type of plaintext attack, which is independent of the recipient's reply: consider: Alice pgp encrypts a message to Bob, and by default, simultaneously to herself. Alice can use gnupg to obtain the session key for the message, by decrypting the default encrypted message to her own key. The session key, can now be used as a known plaintext, the packet of the session key encrypted to Bob's public key, is the ciphertext, and Bob's [ private key + passphrase hash ] the unknown, that is sought. now, if we assume that: (a) Alice can use a watered-down implementation of pgp that does not use 'salt' and (b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt to Bob's key {like using an 'experimental algo' in gnupg, but finding/making one that is easily cracked, or trivial to begin with} then, is it possible for Alice to retrieve Bob's [private key + passphrase hash], which could then be used to decrypt other messages encrypted to Bob's key ? TIA, vedaal From owner-ietf-openpgp@mail.imc.org Wed Aug 21 10:47:38 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11813 for ; Wed, 21 Aug 2002 10:47:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7LEc2L16048 for ietf-openpgp-bks; Wed, 21 Aug 2002 07:38:02 -0700 (PDT) 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 g7LEc0216037; Wed, 21 Aug 2002 07:38:01 -0700 (PDT) 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 g7LEcTQ13615; Wed, 21 Aug 2002 10:38:29 -0400 (EDT) To: vedaal@hotmail.com Cc: ietf-openpgp@imc.org, owner-ietf-openpgp@mail.imc.org Subject: Re: possible new type of pgp plaintext attack ? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 21 Aug 2002 09:37:52 -0500 X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 08/21/2002 10:37:50 AM, Serialize complete at 08/21/2002 10:37:50 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00505F1086256C1C_=" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multipart message in MIME format. --=_alternative 00505F1086256C1C_= Content-Type: text/plain; charset="us-ascii" No need to go through all the gyrations, since Bob's public key is public and known to her. She can perform chosen plaintext attack on the key all she wants, with specialized tools and hardware. No need to only use known session keys for whole messages encrypted by PGP; just run RSA or DSA yourself on any chosen material. It is a fundimental requirement that a public key algorithm be able to withstand such an attack. The existance of a "weak block" would imply that the function is not one-way after all. --John "vedaal" Sent by: owner-ietf-openpgp@mail.imc.org 08-20-2002 04:40 PM To: cc: Subject: possible new type of pgp plaintext attack ? atfer reading the paper on the pgp reply/plaintext attack, was wondering if there might be an additional way to mount a different type of plaintext attack, which is independent of the recipient's reply: consider: Alice pgp encrypts a message to Bob, and by default, simultaneously to herself. Alice can use gnupg to obtain the session key for the message, by decrypting the default encrypted message to her own key. The session key, can now be used as a known plaintext, the packet of the session key encrypted to Bob's public key, is the ciphertext, and Bob's [ private key + passphrase hash ] the unknown, that is sought. now, if we assume that: (a) Alice can use a watered-down implementation of pgp that does not use 'salt' and (b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt to Bob's key {like using an 'experimental algo' in gnupg, but finding/making one that is easily cracked, or trivial to begin with} then, is it possible for Alice to retrieve Bob's [private key + passphrase hash], which could then be used to decrypt other messages encrypted to Bob's key ? TIA, vedaal --=_alternative 00505F1086256C1C_= Content-Type: text/html; charset="us-ascii"
No need to go through all the gyrations, since Bob's public key is public and known to her.  She can perform chosen plaintext attack on the key all she wants, with specialized tools and hardware.  No need to only use known session keys for whole messages encrypted by PGP; just run RSA or DSA yourself on any chosen material.

It is a fundimental requirement that a public key algorithm be able to withstand such an attack.  The existance of a "weak block" would imply that the function is not one-way after all.

--John





"vedaal" <vedaal@hotmail.com>
Sent by: owner-ietf-openpgp@mail.imc.org

08-20-2002 04:40 PM

       
        To:        <ietf-openpgp@imc.org>
        cc:        
        Subject:        possible new type of pgp plaintext attack ?




atfer reading the paper on the pgp reply/plaintext attack,  was wondering if
there might be an additional way to mount a different type of plaintext
attack,
which is independent of the recipient's reply:
consider:
Alice pgp encrypts a message to Bob, and by default, simultaneously to
herself.
Alice can use gnupg to obtain the session key for the message, by
decrypting the default encrypted message to her own key.
The session key, can now be used as a known plaintext,
the packet of the session key encrypted to Bob's public key, is the
ciphertext,
and Bob's [ private key + passphrase hash ] the unknown, that is sought.

now,
if we assume that:
(a) Alice can use a watered-down implementation of pgp that does not use
'salt'
and
(b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt to
Bob's key
{like using an 'experimental algo' in gnupg, but finding/making one that is
easily cracked, or trivial to begin with}
then,
is it possible for Alice to retrieve Bob's [private key + passphrase hash],
which could then be used to decrypt  other messages encrypted to Bob's key ?

TIA,
vedaal












--=_alternative 00505F1086256C1C_=-- From owner-ietf-openpgp@mail.imc.org Thu Aug 22 12:44:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02146 for ; Thu, 22 Aug 2002 12:44:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7MGW3u09823 for ietf-openpgp-bks; Thu, 22 Aug 2002 09:32:03 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7MGW1209819 for ; Thu, 22 Aug 2002 09:32:01 -0700 (PDT) Received: by thetis.deor.org (Postfix, from userid 500) id 5D69745029; Thu, 22 Aug 2002 09:32:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 3CAA048023 for ; Thu, 22 Aug 2002 09:32:00 -0700 (PDT) Date: Wed, 21 Aug 2002 22:43:19 -0700 (PDT) From: Len Sassaman X-Sender: To: OpenPGP Subject: Re: Question about MDC Packets Message-ID: X-AIM: Elom777 X-icq: 10735603 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 Mon, 22 Jul 2002, Jon Callas wrote: > Do you know anything about who is going to be decrypting it? Do you have > some reasonable expectation they can understand it? If so, then yes. > > There is nothing wrong with an implementation being somewhat weasely. If you > make the guess that if someone wants to use AES, then the target is modern > enough to understand an MDC, you'd probably be right. You could even > convincingly harumph if someone does *not* use an MDC but went to the > trouble to do AES. Okay, hear me harumph. We're in the process of adding AES and MDC support to Mixmaster. I need to decide whether to we want to go the "be liberal... but conservative" route and only use MDC if specified in the features subpacket, or the more secure route, and use MDC whenever a key lists prefs 7 through 10 (presumably, we could do this even if we weren't actually choosing those ciphers for encryption, i.e. if CAST5 was listed first). I'd prefer to do it in the latter fashion, but... I just read over the source code for Hushmail's OpenPGP features. It appears that they were working off of RFC2440-bis2, and therefore didn't know anything about the MDC packets. Hushmail keys are generated with symmetric cipher prefs "9 8 7 3". Consequently, Hushmail users cannot decrypt messages encrypted with AES using the MDC packet. An example key is attached at the bottom of this email. It would be unfortunate to have more compatibility problems between implementations of OpenPGP. Would it be unreasonable to state in the spec that implementations supporting ciphers other than 0 through 4 SHOULD be able to handle the MDC packets (perhaps in the paragraph in 5.13 which mentions AES and Twofish currently)? This would place the burden of maintaining compatibility on the side of the less secure implementation. --Len. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Hush 2.1 mQGiBD1kYTwRBACmS12GxIjVhkhLV/V+42S6RgcJWUyBsx0cIQJ0b6wBiKCODrjMXkqL jeoKRj+CH3ZMKNpjyQMz/iUik93YHMKpfZ7tmZcx+08jvHI01xM83N6dAORA/nc7ZIsj +AUHAiHOopKFOIg8MdBkaqZr9jMSZ5qZeKknm1c2ctifGPWpnQCgwANjll5Dj7tv/E1d vCMn2dB1nQUEAJC4A/bdjL23jMdPfaYv6c8dV0LwRzDp25RltF6aKKXDRhsezxpjFray RDr5WSh9A0M6AGnCMSfN4cQHTI7EiTHYVKztwfwjriedDR4m5EOLG3fIeo+89BDvjI0R TLsCXoCfmJBJkZzHvXYn/23AjuoomPD54abjp9hzWA5Jt2AaA/98vK8hWby93JzgG4kz NSGpiVssB2irMWsR9992cTvdjUbTasTFT9snUgETKBEgyAuYEOoC/gXagSe7Ito5o4/v nvO7o+/AKPmGMA49ETW+lK3z4Ed2L7p96qBVisc8Ug/zbauVTnuvmdFiee2/Y88SUjQJ mnkP4k0+6vOwBKZvwsJhBB8RAgAhBQI9ZGE8AgcBFwyAEYpgZW/CY0uc2qKnPHoC+ecn TLYpAAoJEBen9nyD3MdaIeQAn1a1yCdMeLhSlqjEXZtJlwNT9nxIAJ44VZxfhVWs1KbK 9Ov9fF18q4B8gbQVbWRjLXRlc3RAaHVzaG1haWwuY29twlkEExECABkFAj1kYTwFCQHh M4AFCwkIBwMCFQIDFgEAAAoJEBen9nyD3MdaeTAAn3ejME+kaVxKdSd5Cx9KZoM/ryzG AJ4j/L6f1t7tL/4eiyyqpqtHX6UXncJsBBMRAgAsBQI9ZGE9AxYBAAUbAAAAABscSHVz aCBDb21tdW5pY2F0aW9uIERFTU8gQ0EACgkQegL55ydMtikvKACeIH1FpdKVH5/un1Nr v26ObkWPH7EAn1hm9SKWtyPEN2q0sj/znMOmASUHuQINBD1kYTwQCAD2Qle3CH8IF3Ki utapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfU odNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kj wEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnI Byl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7AAICB/4mK26O lB/hsdZzk7mqwfh4dU6JJYR1zWcLUys8HtCr9Ou/oN5vdJfsPyFUllg60jj9lAE935TR t67U/Nt666B1IqjWtOPyN/HGxZrIyd91YG4m5K/UvP1vmrc7AH/LhLYrSN+tLtIsW9yx teMlPkKJc8+8LueKK/0f+vDCRiEP4G0MAG64KZWh2/wVYcJckLCety6qlQm7Z3Ckym2H qosyRA7KtGBy7pNvw1Q5niSNSoWI8QOKme8f0QZ62ZxrvYk49zLSMRlW5iSNZOxYnWZA lo4vFX5yugT3I2pBRBj3RC5pfJJjK3iemePC2NaIOA3nZSb2ZhLm/i4ZiD90YdO4wkwE GBECAAwFAj1kYTwFCQHhM4AACgkQF6f2fIPcx1omigCgl5/aYzHDQ1BWlkXI6LpiQs2N sykAnjaYqw9axQLzJci/PNQTnjvvyfXc =sHIm -----END PGP PUBLIC KEY BLOCK----- From owner-ietf-openpgp@mail.imc.org Thu Aug 22 13:40:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03950 for ; Thu, 22 Aug 2002 13:40:10 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7MHWO512803 for ietf-openpgp-bks; Thu, 22 Aug 2002 10:32:24 -0700 (PDT) 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 g7MHWM212797 for ; Thu, 22 Aug 2002 10:32:23 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7MHWE402708 for ietf-openpgp@imc.org; Thu, 22 Aug 2002 13:32:14 -0400 Date: Thu, 22 Aug 2002 13:32:14 -0400 From: David Shaw To: OpenPGP Subject: Re: Question about MDC Packets Message-ID: <20020822173214.GG725@akamai.com> Mail-Followup-To: OpenPGP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 21, 2002 at 10:43:19PM -0700, Len Sassaman wrote: > We're in the process of adding AES and MDC support to Mixmaster. I need to > decide whether to we want to go the "be liberal... but conservative" route > and only use MDC if specified in the features subpacket, or the more > secure route, and use MDC whenever a key lists prefs 7 through 10 > (presumably, we could do this even if we weren't actually choosing those > ciphers for encryption, i.e. if CAST5 was listed first). I'd prefer to do > it in the latter fashion, but... > > I just read over the source code for Hushmail's OpenPGP features. It > appears that they were working off of RFC2440-bis2, and therefore didn't > know anything about the MDC packets. Hushmail keys are generated with > symmetric cipher prefs "9 8 7 3". Consequently, Hushmail users cannot > decrypt messages encrypted with AES using the MDC packet. An example key > is attached at the bottom of this email. > > It would be unfortunate to have more compatibility problems between > implementations of OpenPGP. Would it be unreasonable to state in the spec > that implementations supporting ciphers other than 0 through 4 SHOULD be > able to handle the MDC packets (perhaps in the paragraph in 5.13 which > mentions AES and Twofish currently)? Seems to me that the draft already states that *all* implementations SHOULD be able to handle MDC packets, regardless of cipher ("An implementation SHOULD prefer this to the older Symmetrically Encrypted Data Packet when possible."). The question is really what to do to determine when it is "possible". ;) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson From owner-ietf-openpgp@mail.imc.org Thu Aug 22 14:30:22 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05693 for ; Thu, 22 Aug 2002 14:30:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7MINOD16586 for ietf-openpgp-bks; Thu, 22 Aug 2002 11:23:24 -0700 (PDT) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7MINN216581 for ; Thu, 22 Aug 2002 11:23:23 -0700 (PDT) Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 17hwbx-002wiv-00; Thu, 22 Aug 2002 19:23:13 +0100 Date: Thu, 22 Aug 2002 19:23:13 +0100 From: Adam Back To: OpenPGP Cc: Adam Back Subject: Re: Question about MDC Packets Message-ID: <20020822192313.A1103939@exeter.ac.uk> References: <20020822173214.GG725@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: <20020822173214.GG725@akamai.com>; from dshaw@jabberwocky.com on Thu, Aug 22, 2002 at 01:32:14PM -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Wasn't this discussed at some point in the past and the suggestion made that all 128 bit block ciphers use MDC as they were introduced at roughly the same time. That leaves the hushmail problem. But due to their software architecture presumably forced software upgrades are easy. (Just publish new java code, the fact that the cached code is more recent on the server takes care of the rest.) Any other implementations ignoring this rule? I'm guessing this discussed rule never made it into the spec. (We have a general issue with over laxness on compatibility issues -- as long as it's possible in theory to interoperate, the concencus in the past has seemed to be to stop there.) All implementations MUST use MDC with > 64 bit block cipher algorithms (such as AES). Adam On Thu, Aug 22, 2002 at 01:32:14PM -0400, David Shaw wrote: > Seems to me that the draft already states that *all* implementations > SHOULD be able to handle MDC packets, regardless of cipher ("An > implementation SHOULD prefer this to the older Symmetrically Encrypted > Data Packet when possible."). > > The question is really what to do to determine when it is > "possible". ;) From owner-ietf-openpgp@mail.imc.org Sat Aug 24 18:17:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18775 for ; Sat, 24 Aug 2002 18:17:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7OM5Rr23495 for ietf-openpgp-bks; Sat, 24 Aug 2002 15:05:27 -0700 (PDT) Received: from mail.hal-pc.org (mail.hal-pc.org [206.180.145.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7OM5Q223491 for ; Sat, 24 Aug 2002 15:05:26 -0700 (PDT) Received: from [24.167.56.11] (HELO stonewall) by mail.hal-pc.org (CommuniGate Pro SMTP 3.5.9) with SMTP id 18270920 for ietf-openpgp@imc.org; Sat, 24 Aug 2002 17:05:04 -0500 Received: by stonewall (sSMTP sendmail emulation); Sat, 24 Aug 2002 22:05:06 +0000 From: "Brian M. Carlson" Date: Sat, 24 Aug 2002 22:05:06 +0000 To: ietf-openpgp@imc.org Subject: RFC: DSA key lengths; Elgamal type 16 v. type 20 Message-ID: <20020824220506.GC12225@stonewall> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: Linux stonewall 2.4.18-k7 Content-Conversion: prohibited X-Request-PGP: http://decoy.wox.org/~bmc/openpgp/pub560553e7.asc Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --ZmUaFz6apKcXQszQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to nitpick for a second. Section 12.6 states, "Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use." Actually, it is DSS (the *standard*), not DSA (the *algorithm*) that is limited to 1024 bits. I'd like to suggest that we replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024 bits." This way, we can maintain backwards compatibility and compliance with DSS, while providing adequate security for people who really want it. Might I point out that IEEE P1363 allows for DSA keys longer than 1024 bits, so there is precedent in the cryptographic community. I'd also like to suggest that we deprecate Elgamal type 16 in favor of Elgamal type 20 combined with key flags. This is exactly what we did with RSA types 2 and 3. It encourages implementations to implement key flags, and it will lessen the usage of an encrypt-only type. It still allows implementations to maintain backwards compatibility, because it does not remove the type altogether. --=20 Brian M. Carlson 0x560553= E7 I will make you shorter by the head. -- Elizabeth I --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.90 (GNU/Linux) Comment: Ubi libertas, ibi patria. iQFKBAEBAwA0BQI9aAMQLRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT57klCACsFCUeKOjNiI0oAPJtsrYvvpcd 3F1Y1HS+qu2mNPWZhzkTHn5z945Hlqdf7Y23HwdqSytaqVxebLmQeUBtssYXMft2 +Cs0XZTa2FCkCxhPIQzss+t8p6gJnIZGfP3t02PvPJ/mYdNGYLk9I4Vq3F5lnk2E L/inkqOYJQGFv2EVdTzNk6BcT1DtVDt6z1vlLC6qKMEzws6xFwT26WlZHzRqtiaa GC8Z5YH5W+tlXeXm4gAhuMchQjbLgV5JW0m8yjHtqc4cQZDf8WnHdIpoYzMS2gQc XVCg0TpNylOaMKqEsYJ9U/cPGtZ+0+6KAoZu9POFWVsRtgjSaIy2p5T3a82e =a1D1 -----END PGP SIGNATURE----- Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex --ZmUaFz6apKcXQszQ-- From owner-ietf-openpgp@mail.imc.org Sun Aug 25 03:00:40 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04981 for ; Sun, 25 Aug 2002 03:00:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7P6sLd17590 for ietf-openpgp-bks; Sat, 24 Aug 2002 23:54:21 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7P6sJ217585 for ; Sat, 24 Aug 2002 23:54:19 -0700 (PDT) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Sat, 24 Aug 2002 23:54:11 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sat, 24 Aug 2002 23:47:39 -0700 Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 From: Jon Callas To: "Brian M. Carlson" , OpenPGP Message-ID: In-Reply-To: <20020824220506.GC12225@stonewall> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8/24/02 3:05 PM, "Brian M. Carlson" wrote: > I'd like to nitpick for a second. Section 12.6 states, "Note that present > DSA is limited to a maximum of 1024 bit keys, which are recommended for > long-term use." Actually, it is DSS (the *standard*), not DSA (the > *algorithm*) that is limited to 1024 bits. I'd like to suggest that we > replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024 > bits." This way, we can maintain backwards compatibility and compliance > with DSS, while providing adequate security for people who really want > it. Might I point out that IEEE P1363 allows for DSA keys longer than > 1024 bits, so there is precedent in the cryptographic community. > So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash algorithm does P1363 use with longer keys? What semantics does it have to go with it? > I'd also like to suggest that we deprecate Elgamal type 16 in favor of > Elgamal type 20 combined with key flags. This is exactly what we did with > RSA types 2 and 3. It encourages implementations to implement key flags, > and it will lessen the usage of an encrypt-only type. It still allows > implementations to maintain backwards compatibility, because it does not > remove the type altogether. Well, there are people who believe that Elgamal signatures should be deprecated, and were a mistake to put in the standard to begin with. I think it's better to leave it as it is and let gentle persons continue to disagree. Jon From owner-ietf-openpgp@mail.imc.org Sun Aug 25 08:46:49 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08705 for ; Sun, 25 Aug 2002 08:46:48 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7PCboD11746 for ietf-openpgp-bks; Sun, 25 Aug 2002 05:37:50 -0700 (PDT) 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 g7PCbl211734 for ; Sun, 25 Aug 2002 05:37:47 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17ixqA-0001hS-00; Sun, 25 Aug 2002 15:54:06 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17iwhp-0000cV-00; Sun, 25 Aug 2002 14:41:25 +0200 To: OpenPGP Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 References: From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH Date: Sun, 25 Aug 2002 14:41:25 +0200 In-Reply-To: (Jon Callas's message of "Sat, 24 Aug 2002 23:47:39 -0700") Message-ID: <87bs7r156y.fsf@alberti.gnupg.de> Lines: 27 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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 Sat, 24 Aug 2002 23:47:39 -0700, Jon Callas said: > Well, there are people who believe that Elgamal signatures should be > deprecated, and were a mistake to put in the standard to begin with. I think FWIW, the reason I implemented ElGamal for signature and encryption in GnuPG was simply the fact that at I initially was not aware of the PGP 5 data format and there used to be claims that DSA may lead to similar patent problems as we had with RSA. > it's better to leave it as it is and let gentle persons continue to > disagree. I agree with Jon. There are only 28 type 20 keys on the keyservers and I see see no reason to promote the use of this type. I'd like to remove it from GnuPG but some folks more or less convinced me that type 20 support should stay in GnuPG (in expert mode). Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Mon Aug 26 08:54:04 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07568 for ; Mon, 26 Aug 2002 08:54:03 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7QBHG023613 for ietf-openpgp-bks; Mon, 26 Aug 2002 04:17:16 -0700 (PDT) Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7QBHE223607 for ; Mon, 26 Aug 2002 04:17:15 -0700 (PDT) Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Mon, 26 Aug 2002 13:11:58 0200 Message-ID: <3D6A0CFE.B5941F78@saiknes.lv> Date: Mon, 26 Aug 2002 13:11:58 +0200 From: disastry@saiknes.lv 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: RFC: DSA key lengths; Elgamal type 16 v. type 20 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 Brian M. Carlson wrote: > I'd like to nitpick for a second. Section 12.6 states, "Note that present > DSA is limited to a maximum of 1024 bit keys, which are recommended for > long-term use." Actually, it is DSS (the *standard*), not DSA (the > *algorithm*) that is limited to 1024 bits. I'd like to suggest that we > replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024 > bits." This way, we can maintain backwards compatibility and compliance > with DSS, while providing adequate security for people who really want > it. Might I point out that IEEE P1363 allows for DSA keys longer than > 1024 bits, so there is precedent in the cryptographic community. there is precedent before that: PGP5.5.3 can use up to 2048 bit DSA keys, but can not generate them. PGP5.5.3ckt can use and generate up to 2048 bit DSA keys. PGP6.5.8ckt can only use 'em. __ Disastry http://disastry.dhs.org/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPWnwxzBaTVEuJQxkEQOgnACg7VFNSR9CZV1x4w43hTW79t0LdbQAn2ad XG9yy4r9EVZ2NwO0B5q0qCNe =dX42 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Aug 26 17:12:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22558 for ; Mon, 26 Aug 2002 17:12:38 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7QKuAF10650 for ietf-openpgp-bks; Mon, 26 Aug 2002 13:56:10 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7QKu8210644 for ; Mon, 26 Aug 2002 13:56:08 -0700 (PDT) Received: by thetis.deor.org (Postfix, from userid 500) id BE62C4501B; Mon, 26 Aug 2002 13:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id AAE7D48023; Mon, 26 Aug 2002 13:56:07 -0700 (PDT) Date: Mon, 26 Aug 2002 13:56:07 -0700 (PDT) From: Len Sassaman X-Sender: To: Jon Callas Cc: "Brian M. Carlson" , OpenPGP Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 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 Sat, 24 Aug 2002, Jon Callas wrote: > So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash > algorithm does P1363 use with longer keys? What semantics does it have to go > with it? P1363 doesn't seem to be linked off of the IEEE site anymore. Does anyone have a copy they can mirror? I think Brian is right, though. While DSS (in FIPS 186 and ANSI X9.30) mandates SHA-1 and limits p to 1024 bits, OpenPGP is specifying DSA, not DSS. I understand DSA to be limited to 1024 bits when using a 160 bit hash. Using a larger hash would allow for larger key sizes. There has been some speculation that a revised DSS may be specified by NIST using the new larger SHA hashes. Should we anticipate this and add the new SHAs (at least SHA-512) to the spec? FWIW, I believe that one of the "ckt" unofficial builds of PGP used larger DSA keys with "double width SHA1". (I'm surprised, actually, that RFC 2440 even specifies double-width SHA1, since it's my understanding that most cryptographers are skeptical that double-width SHA1 is any better than single-width SHA1 for DSA.) Shouldn't wide SHA1 be deprecated in favor of one of the newer NIST SHAs? --Len. From owner-ietf-openpgp@mail.imc.org Mon Aug 26 18:44:27 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA24661 for ; Mon, 26 Aug 2002 18:44:26 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g7QMZEF13195 for ietf-openpgp-bks; Mon, 26 Aug 2002 15:35:14 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7QMZC213190 for ; Mon, 26 Aug 2002 15:35:12 -0700 (PDT) Received: from [192.168.3.193] (64.3.143.66) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for ; Mon, 26 Aug 2002 15:35:03 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 26 Aug 2002 15:35:11 -0700 Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 From: Jon Callas To: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 8/26/02 1:56 PM, "Len Sassaman" wrote: > I think Brian is right, though. While DSS (in FIPS 186 and ANSI X9.30) > mandates SHA-1 and limits p to 1024 bits, OpenPGP is specifying DSA, not > DSS. > I think quibbling over the differences between DSS and DSA is as productive as quibbling over the differences between DES and DEA. I have heard it asserted that 3DES should actually be called 3DEA because the process of tripling is violates the standard. Whatever. We all know what it means. We need to figure out what the smart thing to do is, and if I need to edit an S into an A or vice-versa, it's trivial to do that. However, I want to quit tweaking and get a new RFC number on it. > I understand DSA to be limited to 1024 bits when using a 160 bit hash. > Using a larger hash would allow for larger key sizes. There has been some > speculation that a revised DSS may be specified by NIST using the new > larger SHA hashes. Should we anticipate this and add the new SHAs (at > least SHA-512) to the spec? > We anticipated this as of bis03, August 2000. All the wide SHAs are there. > FWIW, I believe that one of the "ckt" unofficial builds of PGP used larger > DSA keys with "double width SHA1". (I'm surprised, actually, that RFC 2440 > even specifies double-width SHA1, since it's my understanding that most > cryptographers are skeptical that double-width SHA1 is any better than > single-width SHA1 for DSA.) Shouldn't wide SHA1 be deprecated in favor of > one of the newer NIST SHAs? The double-wide SHA work was done pre-2440. It was done pre-me. As I remember what I was told, it was experimental work done by Colin Plumb and Derek Atkins, but maybe Hal Finney was involved. In any event, the present language says, "Reserved for double-width SHA (experimental, obviated)." I am happy to change that to say merely "Reserved" lest someone get the idea it is useful. There are also no OIDs for DWSHA. Jon From owner-ietf-openpgp@mail.imc.org Mon Aug 26 21:34:53 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28071 for ; Mon, 26 Aug 2002 21:34:52 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7R1OaT18638 for ietf-openpgp-bks; Mon, 26 Aug 2002 18:24:36 -0700 (PDT) Received: from mail.hal-pc.org (mail.hal-pc.org [206.180.145.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7R1OZ218633 for ; Mon, 26 Aug 2002 18:24:35 -0700 (PDT) Received: from [24.167.56.11] (HELO stonewall) by mail.hal-pc.org (CommuniGate Pro SMTP 3.5.9) with SMTP id 18431584; Mon, 26 Aug 2002 20:24:37 -0500 Received: by stonewall (sSMTP sendmail emulation); Tue, 27 Aug 2002 01:24:40 +0000 From: "Brian M. Carlson" Date: Tue, 27 Aug 2002 01:24:40 +0000 To: Jon Callas Cc: OpenPGP Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 Message-ID: <20020827012440.GA4124@stonewall> References: <20020824220506.GC12225@stonewall> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: Linux stonewall 2.4.18-k7 Content-Conversion: prohibited X-Request-PGP: http://decoy.wox.org/~bmc/openpgp/pub560553e7.asc Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 24, 2002 at 11:47:39PM -0700, Jon Callas wrote: >=20 > On 8/24/02 3:05 PM, "Brian M. Carlson" wrote: >=20 > > I'd like to nitpick for a second. Section 12.6 states, "Note that prese= nt > > DSA is limited to a maximum of 1024 bit keys, which are recommended for > > long-term use." Actually, it is DSS (the *standard*), not DSA (the > > *algorithm*) that is limited to 1024 bits. I'd like to suggest that we > > replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024 > > bits." This way, we can maintain backwards compatibility and compliance > > with DSS, while providing adequate security for people who really want > > it. Might I point out that IEEE P1363 allows for DSA keys longer than > > 1024 bits, so there is precedent in the cryptographic community. > >=20 >=20 > So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash > algorithm does P1363 use with longer keys? What semantics does it have to= go > with it? I believe it uses SHA1, because it keeps the size of q the same. You will have to subscribe to the mailing list to get the password to fetch the document. Mailing List: http://grouper.ieee.org/groups/1363/WorkingGroup/maillist.html If it doesn't exist anymore, you can email me and ask for it. =20 > > I'd also like to suggest that we deprecate Elgamal type 16 in favor of > > Elgamal type 20 combined with key flags. This is exactly what we did wi= th > > RSA types 2 and 3. It encourages implementations to implement key flags, > > and it will lessen the usage of an encrypt-only type. It still allows > > implementations to maintain backwards compatibility, because it does not > > remove the type altogether. >=20 > Well, there are people who believe that Elgamal signatures should be > deprecated, and were a mistake to put in the standard to begin with. I th= ink > it's better to leave it as it is and let gentle persons continue to > disagree. My point is not that we enforce the use of Elgamal signatures, but that we encourage the use of key flags to signal the purpose of the key. I think sign-only/encrypt-only keys are broken. If someone wants to create a type 20 key with key flags packet that says it is for encryption only, then that person should not be required to create that key (rather, subkey) with the strict additional conditions for signatures. I also think implementations should accept such keys as they currently accept type 16 keys (PGP does not, I think). As an additional benefit, if some implementations just happen to accept Elgamal signatures, well, ok. --=20 Brian M. Carlson 0x560553= E7 Now hatred is by far the longest pleasure; Men love in haste, but they detest at leisure. -- George Gordon, Lord Byron, "Don Juan" --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.90 (GNU/Linux) Comment: Ubi libertas, ibi patria. iQFKBAEBAwA0BQI9atTXLRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT5y8tB/9REG5WlPfYPixjvSzEkWWopTdH +HxoRPUAgMcXBRduyMorXxh6droy0rOiPB3y1glr2A67zELpTRL0WKQSVQl/IMZJ O2uQMmfAkZ5m+iN2YMsNvKcRAQLm5iQ2Z1RdfFUwJ+ct12dLZLBrUtsRV+ObK9fH XVsVgachBOQx8jyXT7dPEZErHaMdCpQLZVjIZinJMEbX9NLOFWjeGP39yP76qi1L lY32CdbF17kmMJr5sm9Xdcc+jPOx1/NtMLgmk6EQq2WrNLz3YXDOrFDRcRXfuYPt +juD11VQODNOz8I1YRoEbGbrj7WIDgOaJfb7jsTE1n6k7oF0XzmevMPlroRH =juUL -----END PGP SIGNATURE----- Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex --a8Wt8u1KmwUX3Y2C-- From owner-ietf-openpgp@mail.imc.org Tue Aug 27 20:11:21 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18173 for ; Tue, 27 Aug 2002 20:11:21 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7S02IM06668 for ietf-openpgp-bks; Tue, 27 Aug 2002 17:02:18 -0700 (PDT) Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RNcH205470; Tue, 27 Aug 2002 16:38:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 27 Aug 2002 16:38:17 -0700 To: (many IETF mailing lists) From: Paul Hoffman / IMC Subject: Nomcom call for volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forwarded for Phil Roberts : The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. From subs-reminder@imc.org Sat Aug 31 18:20:24 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14155 for ; Sat, 31 Aug 2002 18:20:23 -0400 (EDT) From: subs-reminder@imc.org Received: by above.proper.com (8.11.6/8.11.3) id g7VMLqk22374; Sat, 31 Aug 2002 15:21:52 -0700 (PDT) Date: Sat, 31 Aug 2002 15:21:52 -0700 (PDT) Message-Id: <200208312221.g7VMLqk22374@above.proper.com> To: openpgp-archive@ietf.org Subject: [[485343800]] Subscription to ietf-openpgp for openpgp-archive@lists.ietf.org Greetings. This message is a periodic reminder that openpgp-archive@lists.ietf.org is subscribed to the ietf-openpgp mailing list. There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openpgp mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openpgp-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "openpgp-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7S02IM06668 for ietf-openpgp-bks; Tue, 27 Aug 2002 17:02:18 -0700 (PDT) Received: from [165.227.249.18] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7RNcH205470; Tue, 27 Aug 2002 16:38:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: phoffman@mail.imc.org Message-Id: Date: Tue, 27 Aug 2002 16:38:17 -0700 To: (many IETF mailing lists) From: Paul Hoffman / IMC Subject: Nomcom call for volunteers Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forwarded for Phil Roberts : The members of the IESG and IAB and the IETF chair are selected by a nominations committee made up of volunteers from the IETF community. The nominations committee is now in the process of being formed and volunteers are being accepted until Sep 6. Please see (http://www.ietf.org/nomcom/msg19765.html) for information if you are interested in volunteering to be on the nominations committee. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7R1OaT18638 for ietf-openpgp-bks; Mon, 26 Aug 2002 18:24:36 -0700 (PDT) Received: from mail.hal-pc.org (mail.hal-pc.org [206.180.145.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7R1OZ218633 for ; Mon, 26 Aug 2002 18:24:35 -0700 (PDT) Received: from [24.167.56.11] (HELO stonewall) by mail.hal-pc.org (CommuniGate Pro SMTP 3.5.9) with SMTP id 18431584; Mon, 26 Aug 2002 20:24:37 -0500 Received: by stonewall (sSMTP sendmail emulation); Tue, 27 Aug 2002 01:24:40 +0000 From: "Brian M. Carlson" Date: Tue, 27 Aug 2002 01:24:40 +0000 To: Jon Callas Cc: OpenPGP Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 Message-ID: <20020827012440.GA4124@stonewall> References: <20020824220506.GC12225@stonewall> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-Operating-System: Linux stonewall 2.4.18-k7 Content-Conversion: prohibited X-Request-PGP: http://decoy.wox.org/~bmc/openpgp/pub560553e7.asc Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 24, 2002 at 11:47:39PM -0700, Jon Callas wrote: >=20 > On 8/24/02 3:05 PM, "Brian M. Carlson" wrote: >=20 > > I'd like to nitpick for a second. Section 12.6 states, "Note that prese= nt > > DSA is limited to a maximum of 1024 bit keys, which are recommended for > > long-term use." Actually, it is DSS (the *standard*), not DSA (the > > *algorithm*) that is limited to 1024 bits. I'd like to suggest that we > > replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024 > > bits." This way, we can maintain backwards compatibility and compliance > > with DSS, while providing adequate security for people who really want > > it. Might I point out that IEEE P1363 allows for DSA keys longer than > > 1024 bits, so there is precedent in the cryptographic community. > >=20 >=20 > So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash > algorithm does P1363 use with longer keys? What semantics does it have to= go > with it? I believe it uses SHA1, because it keeps the size of q the same. You will have to subscribe to the mailing list to get the password to fetch the document. Mailing List: http://grouper.ieee.org/groups/1363/WorkingGroup/maillist.html If it doesn't exist anymore, you can email me and ask for it. =20 > > I'd also like to suggest that we deprecate Elgamal type 16 in favor of > > Elgamal type 20 combined with key flags. This is exactly what we did wi= th > > RSA types 2 and 3. It encourages implementations to implement key flags, > > and it will lessen the usage of an encrypt-only type. It still allows > > implementations to maintain backwards compatibility, because it does not > > remove the type altogether. >=20 > Well, there are people who believe that Elgamal signatures should be > deprecated, and were a mistake to put in the standard to begin with. I th= ink > it's better to leave it as it is and let gentle persons continue to > disagree. My point is not that we enforce the use of Elgamal signatures, but that we encourage the use of key flags to signal the purpose of the key. I think sign-only/encrypt-only keys are broken. If someone wants to create a type 20 key with key flags packet that says it is for encryption only, then that person should not be required to create that key (rather, subkey) with the strict additional conditions for signatures. I also think implementations should accept such keys as they currently accept type 16 keys (PGP does not, I think). As an additional benefit, if some implementations just happen to accept Elgamal signatures, well, ok. --=20 Brian M. Carlson 0x560553= E7 Now hatred is by far the longest pleasure; Men love in haste, but they detest at leisure. -- George Gordon, Lord Byron, "Don Juan" --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.90 (GNU/Linux) Comment: Ubi libertas, ibi patria. iQFKBAEBAwA0BQI9atTXLRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT5y8tB/9REG5WlPfYPixjvSzEkWWopTdH +HxoRPUAgMcXBRduyMorXxh6droy0rOiPB3y1glr2A67zELpTRL0WKQSVQl/IMZJ O2uQMmfAkZ5m+iN2YMsNvKcRAQLm5iQ2Z1RdfFUwJ+ct12dLZLBrUtsRV+ObK9fH XVsVgachBOQx8jyXT7dPEZErHaMdCpQLZVjIZinJMEbX9NLOFWjeGP39yP76qi1L lY32CdbF17kmMJr5sm9Xdcc+jPOx1/NtMLgmk6EQq2WrNLz3YXDOrFDRcRXfuYPt +juD11VQODNOz8I1YRoEbGbrj7WIDgOaJfb7jsTE1n6k7oF0XzmevMPlroRH =juUL -----END PGP SIGNATURE----- Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex --a8Wt8u1KmwUX3Y2C-- Received: by above.proper.com (8.11.6/8.11.3) id g7QMZEF13195 for ietf-openpgp-bks; Mon, 26 Aug 2002 15:35:14 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7QMZC213190 for ; Mon, 26 Aug 2002 15:35:12 -0700 (PDT) Received: from [192.168.3.193] (64.3.143.66) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2) for ; Mon, 26 Aug 2002 15:35:03 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 26 Aug 2002 15:35:11 -0700 Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 From: Jon Callas To: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 8/26/02 1:56 PM, "Len Sassaman" wrote: > I think Brian is right, though. While DSS (in FIPS 186 and ANSI X9.30) > mandates SHA-1 and limits p to 1024 bits, OpenPGP is specifying DSA, not > DSS. > I think quibbling over the differences between DSS and DSA is as productive as quibbling over the differences between DES and DEA. I have heard it asserted that 3DES should actually be called 3DEA because the process of tripling is violates the standard. Whatever. We all know what it means. We need to figure out what the smart thing to do is, and if I need to edit an S into an A or vice-versa, it's trivial to do that. However, I want to quit tweaking and get a new RFC number on it. > I understand DSA to be limited to 1024 bits when using a 160 bit hash. > Using a larger hash would allow for larger key sizes. There has been some > speculation that a revised DSS may be specified by NIST using the new > larger SHA hashes. Should we anticipate this and add the new SHAs (at > least SHA-512) to the spec? > We anticipated this as of bis03, August 2000. All the wide SHAs are there. > FWIW, I believe that one of the "ckt" unofficial builds of PGP used larger > DSA keys with "double width SHA1". (I'm surprised, actually, that RFC 2440 > even specifies double-width SHA1, since it's my understanding that most > cryptographers are skeptical that double-width SHA1 is any better than > single-width SHA1 for DSA.) Shouldn't wide SHA1 be deprecated in favor of > one of the newer NIST SHAs? The double-wide SHA work was done pre-2440. It was done pre-me. As I remember what I was told, it was experimental work done by Colin Plumb and Derek Atkins, but maybe Hal Finney was involved. In any event, the present language says, "Reserved for double-width SHA (experimental, obviated)." I am happy to change that to say merely "Reserved" lest someone get the idea it is useful. There are also no OIDs for DWSHA. Jon Received: by above.proper.com (8.11.6/8.11.3) id g7QKuAF10650 for ietf-openpgp-bks; Mon, 26 Aug 2002 13:56:10 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7QKu8210644 for ; Mon, 26 Aug 2002 13:56:08 -0700 (PDT) Received: by thetis.deor.org (Postfix, from userid 500) id BE62C4501B; Mon, 26 Aug 2002 13:56:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id AAE7D48023; Mon, 26 Aug 2002 13:56:07 -0700 (PDT) Date: Mon, 26 Aug 2002 13:56:07 -0700 (PDT) From: Len Sassaman X-Sender: To: Jon Callas Cc: "Brian M. Carlson" , OpenPGP Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 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 Sat, 24 Aug 2002, Jon Callas wrote: > So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash > algorithm does P1363 use with longer keys? What semantics does it have to go > with it? P1363 doesn't seem to be linked off of the IEEE site anymore. Does anyone have a copy they can mirror? I think Brian is right, though. While DSS (in FIPS 186 and ANSI X9.30) mandates SHA-1 and limits p to 1024 bits, OpenPGP is specifying DSA, not DSS. I understand DSA to be limited to 1024 bits when using a 160 bit hash. Using a larger hash would allow for larger key sizes. There has been some speculation that a revised DSS may be specified by NIST using the new larger SHA hashes. Should we anticipate this and add the new SHAs (at least SHA-512) to the spec? FWIW, I believe that one of the "ckt" unofficial builds of PGP used larger DSA keys with "double width SHA1". (I'm surprised, actually, that RFC 2440 even specifies double-width SHA1, since it's my understanding that most cryptographers are skeptical that double-width SHA1 is any better than single-width SHA1 for DSA.) Shouldn't wide SHA1 be deprecated in favor of one of the newer NIST SHAs? --Len. Received: by above.proper.com (8.11.6/8.11.3) id g7QBHG023613 for ietf-openpgp-bks; Mon, 26 Aug 2002 04:17:16 -0700 (PDT) Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7QBHE223607 for ; Mon, 26 Aug 2002 04:17:15 -0700 (PDT) Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Mon, 26 Aug 2002 13:11:58 0200 Message-ID: <3D6A0CFE.B5941F78@saiknes.lv> Date: Mon, 26 Aug 2002 13:11:58 +0200 From: disastry@saiknes.lv 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: RFC: DSA key lengths; Elgamal type 16 v. type 20 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 Brian M. Carlson wrote: > I'd like to nitpick for a second. Section 12.6 states, "Note that present > DSA is limited to a maximum of 1024 bit keys, which are recommended for > long-term use." Actually, it is DSS (the *standard*), not DSA (the > *algorithm*) that is limited to 1024 bits. I'd like to suggest that we > replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024 > bits." This way, we can maintain backwards compatibility and compliance > with DSS, while providing adequate security for people who really want > it. Might I point out that IEEE P1363 allows for DSA keys longer than > 1024 bits, so there is precedent in the cryptographic community. there is precedent before that: PGP5.5.3 can use up to 2048 bit DSA keys, but can not generate them. PGP5.5.3ckt can use and generate up to 2048 bit DSA keys. PGP6.5.8ckt can only use 'em. __ Disastry http://disastry.dhs.org/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPWnwxzBaTVEuJQxkEQOgnACg7VFNSR9CZV1x4w43hTW79t0LdbQAn2ad XG9yy4r9EVZ2NwO0B5q0qCNe =dX42 -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g7PCboD11746 for ietf-openpgp-bks; Sun, 25 Aug 2002 05:37:50 -0700 (PDT) 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 g7PCbl211734 for ; Sun, 25 Aug 2002 05:37:47 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17ixqA-0001hS-00; Sun, 25 Aug 2002 15:54:06 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17iwhp-0000cV-00; Sun, 25 Aug 2002 14:41:25 +0200 To: OpenPGP Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 References: From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH Date: Sun, 25 Aug 2002 14:41:25 +0200 In-Reply-To: (Jon Callas's message of "Sat, 24 Aug 2002 23:47:39 -0700") Message-ID: <87bs7r156y.fsf@alberti.gnupg.de> Lines: 27 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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 Sat, 24 Aug 2002 23:47:39 -0700, Jon Callas said: > Well, there are people who believe that Elgamal signatures should be > deprecated, and were a mistake to put in the standard to begin with. I think FWIW, the reason I implemented ElGamal for signature and encryption in GnuPG was simply the fact that at I initially was not aware of the PGP 5 data format and there used to be claims that DSA may lead to similar patent problems as we had with RSA. > it's better to leave it as it is and let gentle persons continue to > disagree. I agree with Jon. There are only 28 type 20 keys on the keyservers and I see see no reason to promote the use of this type. I'd like to remove it from GnuPG but some folks more or less convinced me that type 20 support should stay in GnuPG (in expert mode). Salam-Shalom, Werner Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7P6sLd17590 for ietf-openpgp-bks; Sat, 24 Aug 2002 23:54:21 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7P6sJ217585 for ; Sat, 24 Aug 2002 23:54:19 -0700 (PDT) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Sat, 24 Aug 2002 23:54:11 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sat, 24 Aug 2002 23:47:39 -0700 Subject: Re: RFC: DSA key lengths; Elgamal type 16 v. type 20 From: Jon Callas To: "Brian M. Carlson" , OpenPGP Message-ID: In-Reply-To: <20020824220506.GC12225@stonewall> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 8/24/02 3:05 PM, "Brian M. Carlson" wrote: > I'd like to nitpick for a second. Section 12.6 states, "Note that present > DSA is limited to a maximum of 1024 bit keys, which are recommended for > long-term use." Actually, it is DSS (the *standard*), not DSA (the > *algorithm*) that is limited to 1024 bits. I'd like to suggest that we > replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024 > bits." This way, we can maintain backwards compatibility and compliance > with DSS, while providing adequate security for people who really want > it. Might I point out that IEEE P1363 allows for DSA keys longer than > 1024 bits, so there is precedent in the cryptographic community. > So far as I know, DSS or DSA, or whatever, mandates SHA-1. What hash algorithm does P1363 use with longer keys? What semantics does it have to go with it? > I'd also like to suggest that we deprecate Elgamal type 16 in favor of > Elgamal type 20 combined with key flags. This is exactly what we did with > RSA types 2 and 3. It encourages implementations to implement key flags, > and it will lessen the usage of an encrypt-only type. It still allows > implementations to maintain backwards compatibility, because it does not > remove the type altogether. Well, there are people who believe that Elgamal signatures should be deprecated, and were a mistake to put in the standard to begin with. I think it's better to leave it as it is and let gentle persons continue to disagree. Jon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7OM5Rr23495 for ietf-openpgp-bks; Sat, 24 Aug 2002 15:05:27 -0700 (PDT) Received: from mail.hal-pc.org (mail.hal-pc.org [206.180.145.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7OM5Q223491 for ; Sat, 24 Aug 2002 15:05:26 -0700 (PDT) Received: from [24.167.56.11] (HELO stonewall) by mail.hal-pc.org (CommuniGate Pro SMTP 3.5.9) with SMTP id 18270920 for ietf-openpgp@imc.org; Sat, 24 Aug 2002 17:05:04 -0500 Received: by stonewall (sSMTP sendmail emulation); Sat, 24 Aug 2002 22:05:06 +0000 From: "Brian M. Carlson" Date: Sat, 24 Aug 2002 22:05:06 +0000 To: ietf-openpgp@imc.org Subject: RFC: DSA key lengths; Elgamal type 16 v. type 20 Message-ID: <20020824220506.GC12225@stonewall> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="ZmUaFz6apKcXQszQ" Content-Disposition: inline User-Agent: Mutt/1.4i X-Operating-System: Linux stonewall 2.4.18-k7 Content-Conversion: prohibited X-Request-PGP: http://decoy.wox.org/~bmc/openpgp/pub560553e7.asc Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --ZmUaFz6apKcXQszQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable I'd like to nitpick for a second. Section 12.6 states, "Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use." Actually, it is DSS (the *standard*), not DSA (the *algorithm*) that is limited to 1024 bits. I'd like to suggest that we replace that sentence with, "DSA keys SHOULD NOT exceed a size of 1024 bits." This way, we can maintain backwards compatibility and compliance with DSS, while providing adequate security for people who really want it. Might I point out that IEEE P1363 allows for DSA keys longer than 1024 bits, so there is precedent in the cryptographic community. I'd also like to suggest that we deprecate Elgamal type 16 in favor of Elgamal type 20 combined with key flags. This is exactly what we did with RSA types 2 and 3. It encourages implementations to implement key flags, and it will lessen the usage of an encrypt-only type. It still allows implementations to maintain backwards compatibility, because it does not remove the type altogether. --=20 Brian M. Carlson 0x560553= E7 I will make you shorter by the head. -- Elizabeth I --ZmUaFz6apKcXQszQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.90 (GNU/Linux) Comment: Ubi libertas, ibi patria. iQFKBAEBAwA0BQI9aAMQLRpodHRwOi8vZGVjb3kud294Lm9yZy9+Ym1jL29wZW5w Z3AvcG9saWN5LnRleAAKCRDlkf/JVgVT57klCACsFCUeKOjNiI0oAPJtsrYvvpcd 3F1Y1HS+qu2mNPWZhzkTHn5z945Hlqdf7Y23HwdqSytaqVxebLmQeUBtssYXMft2 +Cs0XZTa2FCkCxhPIQzss+t8p6gJnIZGfP3t02PvPJ/mYdNGYLk9I4Vq3F5lnk2E L/inkqOYJQGFv2EVdTzNk6BcT1DtVDt6z1vlLC6qKMEzws6xFwT26WlZHzRqtiaa GC8Z5YH5W+tlXeXm4gAhuMchQjbLgV5JW0m8yjHtqc4cQZDf8WnHdIpoYzMS2gQc XVCg0TpNylOaMKqEsYJ9U/cPGtZ+0+6KAoZu9POFWVsRtgjSaIy2p5T3a82e =a1D1 -----END PGP SIGNATURE----- Signature policy: http://decoy.wox.org/~bmc/openpgp/policy.tex --ZmUaFz6apKcXQszQ-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7MINOD16586 for ietf-openpgp-bks; Thu, 22 Aug 2002 11:23:24 -0700 (PDT) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7MINN216581 for ; Thu, 22 Aug 2002 11:23:23 -0700 (PDT) Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 17hwbx-002wiv-00; Thu, 22 Aug 2002 19:23:13 +0100 Date: Thu, 22 Aug 2002 19:23:13 +0100 From: Adam Back To: OpenPGP Cc: Adam Back Subject: Re: Question about MDC Packets Message-ID: <20020822192313.A1103939@exeter.ac.uk> References: <20020822173214.GG725@akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: <20020822173214.GG725@akamai.com>; from dshaw@jabberwocky.com on Thu, Aug 22, 2002 at 01:32:14PM -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Wasn't this discussed at some point in the past and the suggestion made that all 128 bit block ciphers use MDC as they were introduced at roughly the same time. That leaves the hushmail problem. But due to their software architecture presumably forced software upgrades are easy. (Just publish new java code, the fact that the cached code is more recent on the server takes care of the rest.) Any other implementations ignoring this rule? I'm guessing this discussed rule never made it into the spec. (We have a general issue with over laxness on compatibility issues -- as long as it's possible in theory to interoperate, the concencus in the past has seemed to be to stop there.) All implementations MUST use MDC with > 64 bit block cipher algorithms (such as AES). Adam On Thu, Aug 22, 2002 at 01:32:14PM -0400, David Shaw wrote: > Seems to me that the draft already states that *all* implementations > SHOULD be able to handle MDC packets, regardless of cipher ("An > implementation SHOULD prefer this to the older Symmetrically Encrypted > Data Packet when possible."). > > The question is really what to do to determine when it is > "possible". ;) Received: by above.proper.com (8.11.6/8.11.3) id g7MHWO512803 for ietf-openpgp-bks; Thu, 22 Aug 2002 10:32:24 -0700 (PDT) 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 g7MHWM212797 for ; Thu, 22 Aug 2002 10:32:23 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7MHWE402708 for ietf-openpgp@imc.org; Thu, 22 Aug 2002 13:32:14 -0400 Date: Thu, 22 Aug 2002 13:32:14 -0400 From: David Shaw To: OpenPGP Subject: Re: Question about MDC Packets Message-ID: <20020822173214.GG725@akamai.com> Mail-Followup-To: OpenPGP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 21, 2002 at 10:43:19PM -0700, Len Sassaman wrote: > We're in the process of adding AES and MDC support to Mixmaster. I need to > decide whether to we want to go the "be liberal... but conservative" route > and only use MDC if specified in the features subpacket, or the more > secure route, and use MDC whenever a key lists prefs 7 through 10 > (presumably, we could do this even if we weren't actually choosing those > ciphers for encryption, i.e. if CAST5 was listed first). I'd prefer to do > it in the latter fashion, but... > > I just read over the source code for Hushmail's OpenPGP features. It > appears that they were working off of RFC2440-bis2, and therefore didn't > know anything about the MDC packets. Hushmail keys are generated with > symmetric cipher prefs "9 8 7 3". Consequently, Hushmail users cannot > decrypt messages encrypted with AES using the MDC packet. An example key > is attached at the bottom of this email. > > It would be unfortunate to have more compatibility problems between > implementations of OpenPGP. Would it be unreasonable to state in the spec > that implementations supporting ciphers other than 0 through 4 SHOULD be > able to handle the MDC packets (perhaps in the paragraph in 5.13 which > mentions AES and Twofish currently)? Seems to me that the draft already states that *all* implementations SHOULD be able to handle MDC packets, regardless of cipher ("An implementation SHOULD prefer this to the older Symmetrically Encrypted Data Packet when possible."). The question is really what to do to determine when it is "possible". ;) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7MGW3u09823 for ietf-openpgp-bks; Thu, 22 Aug 2002 09:32:03 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7MGW1209819 for ; Thu, 22 Aug 2002 09:32:01 -0700 (PDT) Received: by thetis.deor.org (Postfix, from userid 500) id 5D69745029; Thu, 22 Aug 2002 09:32:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 3CAA048023 for ; Thu, 22 Aug 2002 09:32:00 -0700 (PDT) Date: Wed, 21 Aug 2002 22:43:19 -0700 (PDT) From: Len Sassaman X-Sender: To: OpenPGP Subject: Re: Question about MDC Packets Message-ID: X-AIM: Elom777 X-icq: 10735603 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 Mon, 22 Jul 2002, Jon Callas wrote: > Do you know anything about who is going to be decrypting it? Do you have > some reasonable expectation they can understand it? If so, then yes. > > There is nothing wrong with an implementation being somewhat weasely. If you > make the guess that if someone wants to use AES, then the target is modern > enough to understand an MDC, you'd probably be right. You could even > convincingly harumph if someone does *not* use an MDC but went to the > trouble to do AES. Okay, hear me harumph. We're in the process of adding AES and MDC support to Mixmaster. I need to decide whether to we want to go the "be liberal... but conservative" route and only use MDC if specified in the features subpacket, or the more secure route, and use MDC whenever a key lists prefs 7 through 10 (presumably, we could do this even if we weren't actually choosing those ciphers for encryption, i.e. if CAST5 was listed first). I'd prefer to do it in the latter fashion, but... I just read over the source code for Hushmail's OpenPGP features. It appears that they were working off of RFC2440-bis2, and therefore didn't know anything about the MDC packets. Hushmail keys are generated with symmetric cipher prefs "9 8 7 3". Consequently, Hushmail users cannot decrypt messages encrypted with AES using the MDC packet. An example key is attached at the bottom of this email. It would be unfortunate to have more compatibility problems between implementations of OpenPGP. Would it be unreasonable to state in the spec that implementations supporting ciphers other than 0 through 4 SHOULD be able to handle the MDC packets (perhaps in the paragraph in 5.13 which mentions AES and Twofish currently)? This would place the burden of maintaining compatibility on the side of the less secure implementation. --Len. -----BEGIN PGP PUBLIC KEY BLOCK----- Version: Hush 2.1 mQGiBD1kYTwRBACmS12GxIjVhkhLV/V+42S6RgcJWUyBsx0cIQJ0b6wBiKCODrjMXkqL jeoKRj+CH3ZMKNpjyQMz/iUik93YHMKpfZ7tmZcx+08jvHI01xM83N6dAORA/nc7ZIsj +AUHAiHOopKFOIg8MdBkaqZr9jMSZ5qZeKknm1c2ctifGPWpnQCgwANjll5Dj7tv/E1d vCMn2dB1nQUEAJC4A/bdjL23jMdPfaYv6c8dV0LwRzDp25RltF6aKKXDRhsezxpjFray RDr5WSh9A0M6AGnCMSfN4cQHTI7EiTHYVKztwfwjriedDR4m5EOLG3fIeo+89BDvjI0R TLsCXoCfmJBJkZzHvXYn/23AjuoomPD54abjp9hzWA5Jt2AaA/98vK8hWby93JzgG4kz NSGpiVssB2irMWsR9992cTvdjUbTasTFT9snUgETKBEgyAuYEOoC/gXagSe7Ito5o4/v nvO7o+/AKPmGMA49ETW+lK3z4Ed2L7p96qBVisc8Ug/zbauVTnuvmdFiee2/Y88SUjQJ mnkP4k0+6vOwBKZvwsJhBB8RAgAhBQI9ZGE8AgcBFwyAEYpgZW/CY0uc2qKnPHoC+ecn TLYpAAoJEBen9nyD3MdaIeQAn1a1yCdMeLhSlqjEXZtJlwNT9nxIAJ44VZxfhVWs1KbK 9Ov9fF18q4B8gbQVbWRjLXRlc3RAaHVzaG1haWwuY29twlkEExECABkFAj1kYTwFCQHh M4AFCwkIBwMCFQIDFgEAAAoJEBen9nyD3MdaeTAAn3ejME+kaVxKdSd5Cx9KZoM/ryzG AJ4j/L6f1t7tL/4eiyyqpqtHX6UXncJsBBMRAgAsBQI9ZGE9AxYBAAUbAAAAABscSHVz aCBDb21tdW5pY2F0aW9uIERFTU8gQ0EACgkQegL55ydMtikvKACeIH1FpdKVH5/un1Nr v26ObkWPH7EAn1hm9SKWtyPEN2q0sj/znMOmASUHuQINBD1kYTwQCAD2Qle3CH8IF3Ki utapQvMF6PlTETlPtvFuuUs4INoBp1ajFOmPQFXz0AfGy0OplK33TGSGSfgMg71l6RfU odNQ+PVZX9x2Uk89PY3bzpnhV5JZzf24rnRPxfx2vIPFRzBhznzJZv8V+bv9kV7HAarT W56NoKVyOtQa8L9GAFgr5fSI/VhOSdvNILSd5JEHNmszbDgNRR0PfIizHHxbLY7288kj wEPwpVsYjY67VYy4XTjTNP18F1dDox0YbN4zISy1Kv884bEpQBgRjXyEpwpy1obEAxnI Byl6ypUM2Zafq9AKUJsCRtMIPWakXUGfnHy9iUsiGSa6q6Jew1XpMgs7AAICB/4mK26O lB/hsdZzk7mqwfh4dU6JJYR1zWcLUys8HtCr9Ou/oN5vdJfsPyFUllg60jj9lAE935TR t67U/Nt666B1IqjWtOPyN/HGxZrIyd91YG4m5K/UvP1vmrc7AH/LhLYrSN+tLtIsW9yx teMlPkKJc8+8LueKK/0f+vDCRiEP4G0MAG64KZWh2/wVYcJckLCety6qlQm7Z3Ckym2H qosyRA7KtGBy7pNvw1Q5niSNSoWI8QOKme8f0QZ62ZxrvYk49zLSMRlW5iSNZOxYnWZA lo4vFX5yugT3I2pBRBj3RC5pfJJjK3iemePC2NaIOA3nZSb2ZhLm/i4ZiD90YdO4wkwE GBECAAwFAj1kYTwFCQHhM4AACgkQF6f2fIPcx1omigCgl5/aYzHDQ1BWlkXI6LpiQs2N sykAnjaYqw9axQLzJci/PNQTnjvvyfXc =sHIm -----END PGP PUBLIC KEY BLOCK----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7LEc2L16048 for ietf-openpgp-bks; Wed, 21 Aug 2002 07:38:02 -0700 (PDT) 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 g7LEc0216037; Wed, 21 Aug 2002 07:38:01 -0700 (PDT) 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 g7LEcTQ13615; Wed, 21 Aug 2002 10:38:29 -0400 (EDT) To: vedaal@hotmail.com Cc: ietf-openpgp@imc.org, owner-ietf-openpgp@mail.imc.org Subject: Re: possible new type of pgp plaintext attack ? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 21 Aug 2002 09:37:52 -0500 X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 08/21/2002 10:37:50 AM, Serialize complete at 08/21/2002 10:37:50 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 00505F1086256C1C_=" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multipart message in MIME format. --=_alternative 00505F1086256C1C_= Content-Type: text/plain; charset="us-ascii" No need to go through all the gyrations, since Bob's public key is public and known to her. She can perform chosen plaintext attack on the key all she wants, with specialized tools and hardware. No need to only use known session keys for whole messages encrypted by PGP; just run RSA or DSA yourself on any chosen material. It is a fundimental requirement that a public key algorithm be able to withstand such an attack. The existance of a "weak block" would imply that the function is not one-way after all. --John "vedaal" Sent by: owner-ietf-openpgp@mail.imc.org 08-20-2002 04:40 PM To: cc: Subject: possible new type of pgp plaintext attack ? atfer reading the paper on the pgp reply/plaintext attack, was wondering if there might be an additional way to mount a different type of plaintext attack, which is independent of the recipient's reply: consider: Alice pgp encrypts a message to Bob, and by default, simultaneously to herself. Alice can use gnupg to obtain the session key for the message, by decrypting the default encrypted message to her own key. The session key, can now be used as a known plaintext, the packet of the session key encrypted to Bob's public key, is the ciphertext, and Bob's [ private key + passphrase hash ] the unknown, that is sought. now, if we assume that: (a) Alice can use a watered-down implementation of pgp that does not use 'salt' and (b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt to Bob's key {like using an 'experimental algo' in gnupg, but finding/making one that is easily cracked, or trivial to begin with} then, is it possible for Alice to retrieve Bob's [private key + passphrase hash], which could then be used to decrypt other messages encrypted to Bob's key ? TIA, vedaal --=_alternative 00505F1086256C1C_= Content-Type: text/html; charset="us-ascii"
No need to go through all the gyrations, since Bob's public key is public and known to her.  She can perform chosen plaintext attack on the key all she wants, with specialized tools and hardware.  No need to only use known session keys for whole messages encrypted by PGP; just run RSA or DSA yourself on any chosen material.

It is a fundimental requirement that a public key algorithm be able to withstand such an attack.  The existance of a "weak block" would imply that the function is not one-way after all.

--John





"vedaal" <vedaal@hotmail.com>
Sent by: owner-ietf-openpgp@mail.imc.org

08-20-2002 04:40 PM

       
        To:        <ietf-openpgp@imc.org>
        cc:        
        Subject:        possible new type of pgp plaintext attack ?




atfer reading the paper on the pgp reply/plaintext attack,  was wondering if
there might be an additional way to mount a different type of plaintext
attack,
which is independent of the recipient's reply:
consider:
Alice pgp encrypts a message to Bob, and by default, simultaneously to
herself.
Alice can use gnupg to obtain the session key for the message, by
decrypting the default encrypted message to her own key.
The session key, can now be used as a known plaintext,
the packet of the session key encrypted to Bob's public key, is the
ciphertext,
and Bob's [ private key + passphrase hash ] the unknown, that is sought.

now,
if we assume that:
(a) Alice can use a watered-down implementation of pgp that does not use
'salt'
and
(b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt to
Bob's key
{like using an 'experimental algo' in gnupg, but finding/making one that is
easily cracked, or trivial to begin with}
then,
is it possible for Alice to retrieve Bob's [private key + passphrase hash],
which could then be used to decrypt  other messages encrypted to Bob's key ?

TIA,
vedaal












--=_alternative 00505F1086256C1C_=-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7KLhVY00931 for ietf-openpgp-bks; Tue, 20 Aug 2002 14:43:31 -0700 (PDT) Received: from hotmail.com (oe15.law3.hotmail.com [209.185.240.119]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7KLhT200927 for ; Tue, 20 Aug 2002 14:43:29 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 20 Aug 2002 14:42:28 -0700 X-Originating-IP: [207.127.12.210] From: "vedaal" To: Subject: possible new type of pgp plaintext attack ? Date: Tue, 20 Aug 2002 17:40:15 -0400 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: 20 Aug 2002 21:42:28.0973 (UTC) FILETIME=[7B3BB1D0:01C24892] Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: atfer reading the paper on the pgp reply/plaintext attack, was wondering if there might be an additional way to mount a different type of plaintext attack, which is independent of the recipient's reply: consider: Alice pgp encrypts a message to Bob, and by default, simultaneously to herself. Alice can use gnupg to obtain the session key for the message, by decrypting the default encrypted message to her own key. The session key, can now be used as a known plaintext, the packet of the session key encrypted to Bob's public key, is the ciphertext, and Bob's [ private key + passphrase hash ] the unknown, that is sought. now, if we assume that: (a) Alice can use a watered-down implementation of pgp that does not use 'salt' and (b) Alice can intentionally use a flawed 'crackable' algorithm to encrypt to Bob's key {like using an 'experimental algo' in gnupg, but finding/making one that is easily cracked, or trivial to begin with} then, is it possible for Alice to retrieve Bob's [private key + passphrase hash], which could then be used to decrypt other messages encrypted to Bob's key ? TIA, vedaal Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7K29e709945 for ietf-openpgp-bks; Mon, 19 Aug 2002 19:09:40 -0700 (PDT) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7K29b209938 for ; Mon, 19 Aug 2002 19:09:38 -0700 (PDT) Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g7K29Z8W026274; Tue, 20 Aug 2002 14:09:35 +1200 Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA259250; Tue, 20 Aug 2002 14:09:34 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Date: Tue, 20 Aug 2002 14:09:34 +1200 (NZST) Message-ID: <200208200209.OAA259250@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: david.hopwood@zetnet.co.uk, ietf-openpgp@imc.org Subject: Re: Anybody know details about Schneier's "flaw"? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Hopwood writes: >What on earth does this attack have to do with sending millions of messages? The point was that, like the Bleichenbacher attack on email, there are a large list of far more serious problems to worry about than something like this. However, as someone else has pointed out, this isn't the right forum to discuss them. Shall we take it to cypherpunks perhaps? Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7JKDsL22828 for ietf-openpgp-bks; Mon, 19 Aug 2002 13:13:54 -0700 (PDT) Received: from mailout.zetnet.co.uk (mail@new-tonge.zetnet.co.uk [194.247.47.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JKDrn22822 for ; Mon, 19 Aug 2002 13:13:53 -0700 (PDT) Received: from irwell.zetnet.co.uk ([194.247.47.48] helo=zetnet.co.uk ident=root) by mailout.zetnet.co.uk with esmtp (Exim 3.35 #1 (Debian)) id 17gsuQ-0002gt-00 for ; Mon, 19 Aug 2002 21:13:54 +0100 Received: from zetnet.co.uk (bts-0481.dialup.zetnet.co.uk [194.247.49.225]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g7JKDg832138 for ; Mon, 19 Aug 2002 21:13:42 +0100 Message-ID: <3D613AA3.85971B28@zetnet.co.uk> Date: Mon, 19 Aug 2002 18:36:19 +0000 From: David Hopwood X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Anybody know details about Schneier's "flaw"? References: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> 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----- Dominikus Scherkl wrote: > Carl Ellison wrote: > > Y'know, there's an even simpler attack with the same premise. You > > intercept an encrypted e-mail from Alice to Bob. You take the mail > > body out of the message and send that body to Bob under your e-mail > > address (or under some address you control that Bob might mistake for > > Alice's, which would be even better). Bob decrypts the message and > > replies to it, including the original message body by default. In that case Bob sees the original message, and at least has the possibility of noting that it is not consistent with the reply-to address. If he sees garbage, that could be consistent with any reply-to address, unless Bob knows about this attack. This is all part of the same problem that has been pointed out before in the context of signing: the message content and the headers (including the reply-to address and hence the public key to be used to encrypt replies), are not treated as a unit cryptographically. > > The mistake here, on Bob's part, is to reply to a message without > > paying attention to the e-mail address being used > > The Flaw I see (on the whole attack) is: > Why should anybody reply cleartext to an encrypted message? The attack does not depend on the victim replying in cleartext. If the message is encrypted, it would be encrypted to the attacker's key. Peter Gutmann wrote: > On the grand scale of things, it has curiosity value, but not much more. There > are a pile of other attacks which fall into the same class, e.g. concern over > the Bleichenbacher attack on SSL being used against S/MIME email (come to think > of it, that one never came up on open-pgp). My thoughts on this at the time, > which also apply to this attack, were: > > -- Snip -- > > [...] this attack requires that an attacker send you around a million pieces > of CMS encrypted email with attached receipt requests, that you respond with > a million receipts indicating to the attacker the exact details of why the > decrypt failed, that you reuse the same per-message key for each of those > million messages. What on earth does this attack have to do with sending millions of messages? It requires one message, and is considerably more plausible than applying the Bleichenbacher attack to email (or would be, if it is wasn't prevented in practice by compression). - -- David Hopwood Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/ RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5 0F 69 8C D4 FA 66 15 01 Nothing in this message is intended to be legally binding. If I revoke a public key but refuse to specify why, it is because the private key has been seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBPWE6izkCAxeYt5gVAQH7sAf6AklABDur8W+Aoq6FAMlSwprTkS9/ds6d jFk8vNqlF2RYQApMGmGCSBcoayNS4o9WwYBP0hIEaqv/9jTcZXHGnz11IoUoFbR8 fQIQEh5egiGeqyt43n1kojWEptA1MHN5VNBC+WeYMV0sJYvqiSM61NjIHJMUV94Y 3ueWpee4drXCYgjVRMH8PhXj1IoqIyhzzPtzaQ46s0hVaZcQIOE6vVuSqAwyXLmr qW52cjRZ8wIJjA5I4PPQcW8/IXSMcMvAkFLeG5HFcl9COmC+wRqJVgzhq6Q2du+8 qqLHAs23g/FsKIckBNaWeU0DSkIp0oZcxCcOjsAB3JFLkMiInhUE5w== =gZJl -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g7JIceN16514 for ietf-openpgp-bks; Mon, 19 Aug 2002 11:38:40 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JIcdn16510 for ; Mon, 19 Aug 2002 11:38:39 -0700 (PDT) Received: (from bcn@localhost) by boreas.isi.edu (8.11.6/8.11.2) id g7JIcgO15291; Mon, 19 Aug 2002 11:38:42 -0700 (PDT) Date: Mon, 19 Aug 2002 11:38:42 -0700 (PDT) Message-Id: <200208191838.g7JIcgO15291@boreas.isi.edu> From: Clifford Neuman To: ietf-openpgp@imc.org Subject: CFP - Symposium on Network & Distributed Systems Security Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The Internet Society's (ISOC) annual Symposium on Network and Distributed System Security (NDSS) brings together innovative and forward thinking members of the Internet community including leading-edge security researchers and implementers, globally-recognized security-technology experts, and users from both the private and public sectors who design, develop, exploit, and deploy the technologies that define network and distributed system security. If you are working on new and practical approaches to security problems that are endemic to network and distributed systems, we invite you to participate in NDSS'03 by submitting one or more technical papers and/or panel proposals. Submission details may be found at: http://www.isoc.org/isoc/conferences/ndss/03/cfp.shtml NDSS'03 will again be held for three days in San Diego, California in February, 2003. One day of tutorials will be followed by two days of technical sessions including refereed papers, invited talks, and panel discussions and debates. Please be aware that the NDSS'03 cut off date for paper and panel submission is August 30, 2002. All accepted papers will be published in The NDSS Proceedings by the Internet Society. There will also be an Outstanding Paper Award presented at the Symposium to the author(s). Submitted papers should not have been previously published or be submitted simultaneously to a journal or to another symposium or workshop with a published proceedings. Please consider joining us at NDSS'03. We look forward to hearing from you! Clifford Neuman, Information Sciences Institute, University of Southern California General Chair, NDSS'03 Virgil Gligor, University of Maryland Michael Reiter, Carnegie Mellon University Program Chairs, NDSS'03 Received: by above.proper.com (8.11.6/8.11.3) id g7JHqcs14181 for ietf-openpgp-bks; Mon, 19 Aug 2002 10:52:38 -0700 (PDT) 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 g7JHqbn14177 for ; Mon, 19 Aug 2002 10:52:37 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7JHqXr09314 for ietf-openpgp@imc.org; Mon, 19 Aug 2002 13:52:33 -0400 Date: Mon, 19 Aug 2002 13:52:33 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Notary signature implementation notes Message-ID: <20020819175233.GA9174@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="6c2NcOVqGQ03X4Wi" Content-Disposition: inline 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 Gibbous (90% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi folks, I recently roughed in some support for notary signatures in GnuPG. Here are some samples. The first attachment is the file the original signature was issued on. The second attachment is a detached signature on that file. The third attachment is a v4 0x50 signature on that signature, and the final attachment is a v3 0x50. All of these signatures were issued by key 0xD8B2D20C, currently on a friendly keyserver near you. I used the canonicalization rules Hal Finney suggested in http://www.imc.org/ietf-openpgp/mail-archive/msg04021.html except I used the constant 0x88 rather than 0x84 for the canonical CTB. I believe 0x84 was a typo since that would be a CTB for a session key packet. It was suggested that notary signatures always contain a signature target subpacket. After implementing notary signatures, I'm not sure how useful this would be given the current signature target subpacket. To create the subpacket, the notary needs to have the public key of the signer of the original signature in order to get the raw hash out of the original signature. That harms somewhat the nice feature of a notary signature that the notary does not need to know anything about the original document and its signer. One possible solution to this is to define the signature target subpacket as a canonical hash of the original signature rather than as the actual hash from the original signature. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=foo notary --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="foo.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.92 (GNU/Linux) iD8DBQE9YSjw+Tjeu9iy0gwRAknBAKCF7OW5ZRND7FQVUYZNy9wAsf+DrQCgiyFX PVJq/nmQhobwoId4iSzoBA0= =6eYH -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="v4.sig" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.92 (GNU/Linux) iEYEUBECAAYFAj1hKz4ACgkQ+Tjeu9iy0gy4WACgkWr3mwBNMANoe0z+p6wNC9B4 tqgAn1Kj0u7HodpPVUmgxQl+ny3gulXg =Zxfb -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="v3.sig" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.1.92 (GNU/Linux) iD8DBVA9YS5K+Tjeu9iy0gwRAq9uAJ9mpkSRKH//iekU6qxO9/69XXhAwQCgmxZ4 LX6smbOeKxHzX2XG/aOtQw8= =F5Ir -----END PGP SIGNATURE----- --6c2NcOVqGQ03X4Wi-- Received: by above.proper.com (8.11.6/8.11.3) id g7JCsJe23307 for ietf-openpgp-bks; Mon, 19 Aug 2002 05:54:19 -0700 (PDT) Received: from atlas.acter.ch ([212.126.160.108]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JCsIw23303 for ; Mon, 19 Aug 2002 05:54:18 -0700 (PDT) Received: by atlas.acter.ch (Postfix, from userid 1047) id DDC81C3B0; Mon, 19 Aug 2002 14:54:18 +0200 (CEST) Subject: Re: Anybody know details about Schneier's "flaw"? From: "Adrian 'Dagurashibanipal' von Bidder" To: ietf-openpgp@imc.org In-Reply-To: <200208191129.XAA214939@ruru.cs.auckland.ac.nz> References: <200208191129.XAA214939@ruru.cs.auckland.ac.nz> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-c6HIAhDluoStiSC+MQqb" X-Mailer: Ximian Evolution 1.0.8 Date: 19 Aug 2002 14:54:18 +0200 Message-Id: <1029761658.29620.7.camel@atlas> Mime-Version: 1.0 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-c6HIAhDluoStiSC+MQqb Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Mon, 2002-08-19 at 13:29, Peter Gutmann wrote: >=20 > "Dominikus Scherkl" writes: >=20 > >The whole attack looks very suspicious to me... >=20 > On the grand scale of things, it has curiosity value, but not much more. = There [...] > As a security threat, I'd say this rates somewhere down with "Router hi= t by > meteorite", "Computer trampled by stampeding water buffalo", "Hard driv= e > kidnapped by space aliens", and similar stuff. >=20 > Sure, it is in theory possible, if you try really, really hard and are wi= lling > to bend over backwards to cooperate with an attacker, to allow this kind = of > attack to occur. [...] You're more likely to get someone's key by askin= g them As I've said in my other mail it's really a problem of some mailreaders being unclear. For example, evolution does not display any indication that the displayed message was encrypted. (You have to enter the passphrase the first time you look at an encrypted msg, but I usually tell it to store the passphrase for the session, causing it to auto-decrypt any further messages. In other words: on technical grounds, I absolutely agree with you. BUT with bad UIs in some mailreaders, and with the experience that users generally are more stupid than anyone would believe, this type of attack is very realistic. Bot, and here I'm sure that your opinion is the same, this discussion is not really on-topic on a technical mailing list...=20 cheers -- vbi --=20 secure email with gpg http://fortytwo.ch/gpg --=-c6HIAhDluoStiSC+MQqb Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9YOp6wj49sl5Lcx8RAgpsAJwMA13QNVeYpVHm6iSU8TszXv2KTQCfVybq OpxFxs7p3+3d+mkYE0mzVDY= =p5IP -----END PGP SIGNATURE----- --=-c6HIAhDluoStiSC+MQqb-- Received: by above.proper.com (8.11.6/8.11.3) id g7JBu4a20631 for ietf-openpgp-bks; Mon, 19 Aug 2002 04:56:04 -0700 (PDT) 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 g7JBu2w20624 for ; Mon, 19 Aug 2002 04:56:02 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17gmJ9-0000Ca-00; Mon, 19 Aug 2002 15:10:59 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17glBe-0004W6-00; Mon, 19 Aug 2002 13:59:10 +0200 To: "Dominikus Scherkl" Cc: Subject: Re: Anybody know details about Schneier's "flaw"? References: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH Date: Mon, 19 Aug 2002 13:59:10 +0200 In-Reply-To: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> ("Dominikus Scherkl"'s message of "Mon, 19 Aug 2002 11:49:23 +0200") Message-ID: <87wuqnf4a9.fsf@alberti.gnupg.de> Lines: 35 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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 Mon, 19 Aug 2002 11:49:23 +0200, Dominikus Scherkl said: > Why should anybody relpy cleartext to an encrypted messge? > especialy if it contains (even parts) of the encrypted message? You will often notice plaintext message like "I could not decrypt your message - please use key 0x12345678" or "Where do I find your key". So it is not unlikely to see a message "Hey, your encrypted mail was garbled, please send it again. Here is the problematic line..". Most users don't know about the cryptograhic issues involved in sending parts of the plaintext back. A good MUA should protect against that but well a user can always override it. > If a reply is sent at all, it should be encrypted, so an interceptor > has the same problem with the reply - he needs to break the key. I am probably not the only one with this problem: Try to get my key from a keyserver - it is probably not usable because the subkeys are all garbled (Most people don't look at the mail header X-Request-PGP to find out the canonical way to get my key). So it is very likely to get a plaintext response; users are thus used to that and they can't imagine what serious consequences a reply with a very short and after all unreadable quote should have. All over the place OpenPGP is rightfully very paranoid and thus it makes sense to do what we can to avoid shoot-your-self-in-the-foot traps. Salam-Shalom, Werner Received: by above.proper.com (8.11.6/8.11.3) id g7JBYxT19637 for ietf-openpgp-bks; Mon, 19 Aug 2002 04:34:59 -0700 (PDT) Received: from atlas.acter.ch ([212.126.160.108]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JBYww19632 for ; Mon, 19 Aug 2002 04:34:58 -0700 (PDT) Received: by atlas.acter.ch (Postfix, from userid 1047) id 09E0021A0; Mon, 19 Aug 2002 13:34:46 +0200 (CEST) Subject: Re: Anybody know details about Schneier's "flaw"? From: "Adrian 'Dagurashibanipal' von Bidder" To: ietf-openpgp@imc.org In-Reply-To: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> References: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1G2tKlk5KHHHBs/KYBUY" X-Mailer: Ximian Evolution 1.0.8 Date: 19 Aug 2002 13:34:46 +0200 Message-Id: <1029756886.31083.125.camel@atlas> Mime-Version: 1.0 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-1G2tKlk5KHHHBs/KYBUY Content-Type: text/plain Content-Transfer-Encoding: quoted-printable [please leave attribution in when replying] On Mon, 2002-08-19 at 11:49, Dominikus Scherkl wrote: > > The mistake here, on Bob's part, is to reply to a message without > > paying attention to the e-mail address being used [...] > The whole attack looks very suspicious to me... I guess the correct 'solution' to prevent the 'attack' would be to file bug reports with gpg-aware mail clients that do not at least display a warning when replying to/forwarding an originally encrypted message unencrypted. cheers -- vbi --=20 secure email with gpg http://fortytwo.ch/gpg --=-1G2tKlk5KHHHBs/KYBUY Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQA9YNfWwj49sl5Lcx8RAnajAJ9wWptZqJMBxC19txdY/uiR7HG5zACfSu6O AO6zbRoorgWA8jpKKWm8jRU= =v06T -----END PGP SIGNATURE----- --=-1G2tKlk5KHHHBs/KYBUY-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7JBU0F19339 for ietf-openpgp-bks; Mon, 19 Aug 2002 04:30:00 -0700 (PDT) Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7JBTvw19333 for ; Mon, 19 Aug 2002 04:29:58 -0700 (PDT) Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.4/8.12.4) with ESMTP id g7JBTX8W008198; Mon, 19 Aug 2002 23:29:33 +1200 Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA214939; Mon, 19 Aug 2002 23:29:30 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Date: Mon, 19 Aug 2002 23:29:30 +1200 (NZST) Message-ID: <200208191129.XAA214939@ruru.cs.auckland.ac.nz> From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Dominikus.Scherkl@glueckkanja.com, ietf-openpgp@imc.org Subject: Re: Anybody know details about Schneier's "flaw"? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "Dominikus Scherkl" writes: >The whole attack looks very suspicious to me... On the grand scale of things, it has curiosity value, but not much more. There are a pile of other attacks which fall into the same class, e.g. concern over the Bleichenbacher attack on SSL being used against S/MIME email (come to think of it, that one never came up on open-pgp). My thoughts on this at the time, which also apply to this attack, were: -- Snip -- [...] this attack requires that an attacker send you around a million pieces of CMS encrypted email with attached receipt requests, that you respond with a million receipts indicating to the attacker the exact details of why the decrypt failed, that you reuse the same per-message key for each of those million messages. Now maybe I'm being a bit optimistic here, but I do think that claiming this is a weakness is a pretty silly. First of all you need to assume that an attacker can somehow send you a million pieces of email without you noticing and without it getting stopped by spam blockers. Your own software then has to try to decrypt each of the one million pieces of email, find that it can't, and send out a receipt to the sender containing an indication of exactly how the decryption failed (this isn't possible even if you wanted to do it, although who knows what the Receipt Notification WG have been working on recently). Finally, the whole attack only works if you reuse cryptovariables. This is why the CERT advisory on this problem specifically points out "This vulnerability does not affect S/MIME or SET". As a security threat, I'd say this rates somewhere down with "Router hit by meteorite", "Computer trampled by stampeding water buffalo", "Hard drive kidnapped by space aliens", and similar stuff. Sure, it is in theory possible, if you try really, really hard and are willing to bend over backwards to cooperate with an attacker, to allow this kind of attack to occur. [...] You're more likely to get someone's key by asking them for it (I've seen this happen a number of times, in some cases without even needing to ask for it, by people who assume that "PKCS #12 == certificate" and send out their "certificate" for others to use) than by using this kind of attack. Just because it's (theoretically) possible to break into Fort Knox with a can opener doesn't mean that Kentucky is going to start screening people at the border for possession of said item. -- Snip -- A better way of putting that last sentence is given in one of my favourite computing quotes, by Chris Strachey: "The fact that it's possible to push a pea up a mountain with your nose doesn't mean that this is a sensible way of getting it there". Peter. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7J9niR13625 for ietf-openpgp-bks; Mon, 19 Aug 2002 02:49:44 -0700 (PDT) Received: from mail.glueckkanja.com (mail.glueckkanja.com [62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7J9ngw13614 for ; Mon, 19 Aug 2002 02:49:43 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: Anybody know details about Schneier's "flaw"? Date: Mon, 19 Aug 2002 11:49:23 +0200 Message-ID: <2F89C141B5B67645BB56C0385375788231C5B0@guk1d002.glueckkanja.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: Anybody know details about Schneier's "flaw"? thread-index: AcJF7a2ecgkqG9KoQWeAfHbfGnfZMgBdonGAAABUb2A= From: "Dominikus Scherkl" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7J9niw13621 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Y'know, there's an even simpler attack with the same premise. You > intercept an encrypted e-mail from Alice to Bob. You take the mail > body out of the message and send that body to Bob under your e-mail > address (or under some address you control that Bob might mistake for > Alice's, which would be even better). Bob decrypts the message and > replies to it, including the original message body by default. > > The mistake here, on Bob's part, is to reply to a message without > paying attention to the e-mail address being used The Flaw I see (on the whole attack) is: Why should anybody relpy cleartext to an encrypted messge? especialy if it contains (even parts) of the encrypted message? And if anybody does, why he's using encryption at all?!? If a reply is sent at all, it should be encrypted, so an interceptor has the same problem with the reply - he needs to break the key. And if it's the sender himself who want's to cheat him, he knows the message content very well, so what does he want to gain?!? The whole attack looks very suspicious to me... -- Dominikus Scherkl dominikus.scherkl@glueckkanja.com Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7HCgkt19328 for ietf-openpgp-bks; Sat, 17 Aug 2002 05:42:46 -0700 (PDT) Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7HCgjw19322 for ; Sat, 17 Aug 2002 05:42:46 -0700 (PDT) Received: from p4 ([12.224.48.160]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020817124231.IDUW1746.rwcrmhc51.attbi.com@p4> for ; Sat, 17 Aug 2002 12:42:31 +0000 Message-Id: <3.0.5.32.20020817054229.0229a930@localhost> X-Sender: cme@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Sat, 17 Aug 2002 05:42:29 -0700 To: ietf-openpgp@imc.org From: Carl Ellison Subject: Re: Anybody know details about Schneier's "flaw"? In-Reply-To: <20020816031342.A599725@exeter.ac.uk> References: <5.1.1.6.2.20020815174759.02572e28@127.0.0.1> <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020815174759.02572e28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 03:13 AM 8/16/2002 +0100, Adam Back wrote: >Also the attack for those who haven't read the paper is really >low-tech. They're just observing that if you can ask someone to >decrypt a message you can use that to decrypt related messages. So >you intentionally garble a message, and hope the user sends you the >garbled plaintext back to you to ask what went wrong. The rest >falls out of the fact that if you garble a few bits of a ciphertext >most of the plaintext will still be intact. Y'know, there's an even simpler attack with the same premise. You intercept an encrypted e-mail from Alice to Bob. You take the mail body out of the message and send that body to Bob under your e-mail address (or under some address you control that Bob might mistake for Alice's, which would be even better). Bob decrypts the message and replies to it, including the original message body by default. The mistake here, on Bob's part, is to reply to a message without paying attention to the e-mail address being used -- rather than replying to a message with quoted garbage rather than just saying "that was garbage -- send again". - Carl -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBPV5EtHPxfjyW5ytxEQI12ACg3NB4hVzj9Og2VB0dpz6CNtdv9IUAniTD AK7BRrNff1maSKf+z/RzYkcV =nq3Z -----END PGP SIGNATURE----- +------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://world.std.com/~cme | | PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7G2DgK09582 for ietf-openpgp-bks; Thu, 15 Aug 2002 19:13:42 -0700 (PDT) Received: from mercury.ex.ac.uk (mercury.ex.ac.uk [144.173.6.26]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7G2Dew09576 for ; Thu, 15 Aug 2002 19:13:42 -0700 (PDT) Received: from cronus ([144.173.6.20] helo=cronus.ex.ac.uk) by mercury.ex.ac.uk with esmtp (Exim 3.33 #1) id 17fWcQ-002R4M-00; Fri, 16 Aug 2002 03:13:42 +0100 Date: Fri, 16 Aug 2002 03:13:42 +0100 From: Adam Back To: Rodney Thayer Cc: Derek Atkins , ietf-openpgp@imc.org Subject: Re: Anybody know details about Schneier's "flaw"? Message-ID: <20020816031342.A599725@exeter.ac.uk> References: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020815174759.02572e28@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.2i In-Reply-To: <5.1.1.6.2.20020815174759.02572e28@127.0.0.1>; from rodney@tillerman.to on Thu, Aug 15, 2002 at 05:49:00PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree. Increasing use of MDC is a better more direct solution. (It's also a more robust solution -- how long until someone manages to propogate the attack through compression -- it's not as if compression were designed to prevent it.) Also the attack for those who haven't read the paper is really low-tech. They're just observing that if you can ask someone to decrypt a message you can use that to decrypt related messages. So you intentionally garble a message, and hope the user sends you the garbled plaintext back to you to ask what went wrong. The rest falls out of the fact that if you garble a few bits of a ciphertext most of the plaintext will still be intact. So it's related to the earlier observation that unless a message is signed you can undetectably (to PGP) garble it's contents. This also was hard to do if the message was compressed. This was the motivation for the MDC. Adam On Thu, Aug 15, 2002 at 05:49:00PM -0700, Rodney Thayer wrote: > > my point was, requiring implementors to do compression sucks, > in my opinion. this attack is insufficient justification. > > the attack is a social engineering attack. forcing implementors > to add onerous code to defend against it is not a good idea. > > At 12:51 PM 8/14/2002 -0400, Derek Atkins wrote: > > >Rodney Thayer writes: > > > > > I think it's got too many odd things in it to require compression. > > > >Indeed.. As I said (perhaps incoherently), the attack only works if > >you DO NOT compress. If you compress the message then there is no way > >to XOR against the message. > Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7G0qNB06575 for ietf-openpgp-bks; Thu, 15 Aug 2002 17:52:23 -0700 (PDT) Received: from yancey.pkiclue.com (IDENT:root@[209.172.115.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7G0qLw06568 for ; Thu, 15 Aug 2002 17:52:21 -0700 (PDT) Received: from ferg237.pkiclue.com (IDENT:root@[127.0.0.1]) by yancey.pkiclue.com (8.9.3/8.9.3) with ESMTP id RAA11428; Thu, 15 Aug 2002 17:52:01 -0700 Message-Id: <5.1.1.6.2.20020815174759.02572e28@127.0.0.1> X-Sender: pkiclue@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Thu, 15 Aug 2002 17:49:00 -0700 To: Derek Atkins From: Rodney Thayer Subject: Re: Anybody know details about Schneier's "flaw"? Cc: ietf-openpgp@imc.org In-Reply-To: References: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> <5.1.1.6.2.20020814093305.01451338@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: my point was, requiring implementors to do compression sucks, in my opinion. this attack is insufficient justification. the attack is a social engineering attack. forcing implementors to add onerous code to defend against it is not a good idea. At 12:51 PM 8/14/2002 -0400, Derek Atkins wrote: >Rodney Thayer writes: > > > I think it's got too many odd things in it to require compression. > >Indeed.. As I said (perhaps incoherently), the attack only works if >you DO NOT compress. If you compress the message then there is no way >to XOR against the message. Received: by above.proper.com (8.11.6/8.11.3) id g7FAAj313565 for ietf-openpgp-bks; Thu, 15 Aug 2002 03:10:45 -0700 (PDT) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7FAAhw13560 for ; Thu, 15 Aug 2002 03:10:43 -0700 (PDT) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtp (Exim 4.05) id 17fHaU-0004R0-00 for ietf-openpgp@imc.org; Thu, 15 Aug 2002 12:10:42 +0200 Received: from a62b6.pppool.de ([213.6.98.182] helo=daredevil) by mx2.freenet.de with esmtp (Exim 4.05 #1) id 17fHaU-0002Fh-00 for ietf-openpgp@imc.org; Thu, 15 Aug 2002 12:10:42 +0200 Received: from twoaday by daredevil with local (Exim 3.35 #1 (Debian)) id 17fHPp-0000Df-00 for ; Thu, 15 Aug 2002 11:59:41 +0200 Date: Thu, 15 Aug 2002 11:59:41 +0200 From: Timo Schulz To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket Message-ID: <20020815095941.GB828@daredevil.joesixpack.net> Reply-To: twoaday@freakmail.de Mail-Followup-To: ietf-openpgp@imc.org References: <3D5B5D4B.34F675FE@saiknes.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5B5D4B.34F675FE@saiknes.lv> X-PGP-KeyID: BF3DF9B4 X-PGP-Request: lynx -source http://www.winpt.org/twoaday.asc User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu Aug 15 2002; 09:50, disastry@saiknes.lv wrote: > in which self signature?: > > 5.2.3.3. Notes on Self-Signatures [snip] Yes, I'm aware we can't use the self signature but this packet would need a central place because otherwise it would no make sense. The best idea is somewhere in a signature which carries the public key because there is only one public key and this would be central. Timo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7F7pc726777 for ietf-openpgp-bks; Thu, 15 Aug 2002 00:51:38 -0700 (PDT) Received: from branwen.iks-jena.de (root@branwen.iks-jena.de [217.17.192.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7F7pbw26768 for ; Thu, 15 Aug 2002 00:51:37 -0700 (PDT) Received: from branwen.iks-jena.de (localhost [127.0.0.1]) by branwen.iks-jena.de (8.12.5/8.12.1) with ESMTP id g7F7pZ1O015624 for ; Thu, 15 Aug 2002 09:51:35 +0200 Received: (from news@localhost) by branwen.iks-jena.de (8.12.5/8.12.1/Submit) id g7F7pZT7015623 for ietf-openpgp@imc.org; Thu, 15 Aug 2002 09:51:35 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Anybody know details about Schneier's "flaw"? Date: Thu, 15 Aug 2002 07:51:35 +0000 (UTC) Organization: IKS GmbH Jena Lines: 9 Message-ID: References: NNTP-Posting-Host: taranis.iks-jena.de X-Trace: branwen.iks-jena.de 1029397895 15611 217.17.192.37 (15 Aug 2002 07:51:35 GMT) X-Complaints-To: usenet@iks-jena.de NNTP-Posting-Date: Thu, 15 Aug 2002 07:51:35 +0000 (UTC) User-Agent: slrn/0.9.6.3 (Linux) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Jon Callas wrote: >The text that is in there is some talk in the sections on compression, which >say that a decompression error should be considered to be a security >problem, not a data problem (in other words, don't typically let the user >have the damaged plaintext), and some language that recommends encouraging >people to use MDCs. There is also a relatively long section in Security >Considerations. Take a look, I think you'll like it. Fine. I don't support Schneiers Claim to withdraw 'uncompressed'-compression. Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7F7or626622 for ietf-openpgp-bks; Thu, 15 Aug 2002 00:50:53 -0700 (PDT) Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7F7oqw26614 for ; Thu, 15 Aug 2002 00:50:52 -0700 (PDT) Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Thu, 15 Aug 2002 09:50:35 0200 Message-ID: <3D5B5D4B.34F675FE@saiknes.lv> Date: Thu, 15 Aug 2002 09:50:35 +0200 From: disastry@saiknes.lv 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: Primary subkey subpacket 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 Timo Schulz wrote: > On Wed Aug 14 2002; 14:27, disastry@saiknes.lv wrote: > > > > which is placed on the self signature to force the implementation > ^^^^^^^^^^^^^^ > [snip] > > where do you want to place it? > > In the self signature. in which self signature?: 5.2.3.3. Notes on Self-Signatures A self-signature is a binding signature made by the key the signature refers to. There are three types of self-signatures, the certification signatures (types 0x10-0x13), the direct-key signature (type 0x1f), and the subkey binding signature (type 0x18). For __ Disastry http://disastry.dhs.org/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPVtBCTBaTVEuJQxkEQPWmACgq6ZCbzgNeOoTsGEMqYgOcFclKr0AoNMP lRySaU0dgUZqgoHFSKI77btA =383/ -----END PGP SIGNATURE----- Received: by above.proper.com (8.11.6/8.11.3) id g7F6KLr14151 for ietf-openpgp-bks; Wed, 14 Aug 2002 23:20:21 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7F6KKw14144 for ; Wed, 14 Aug 2002 23:20:20 -0700 (PDT) Received: from [63.73.97.184] (63.73.97.184) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Wed, 14 Aug 2002 23:20:14 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 14 Aug 2002 23:20:20 -0700 Subject: Re: Anybody know details about Schneier's "flaw"? From: Jon Callas To: , CC: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 8/14/02 2:27 PM, "john.dlugosz@kodak.com" wrote: > According to the link posted by someone else, > (www.counterpane.com/pgp-attack.html), "We also recommend changes in the > OpenPGP standard [3 ]to educe the > effectiveness of ou attacks in these settings." > > Are the people activly working on the -bis draft aware of this? Yes, we are aware of it. We released bis-06 on Monday with language in it to address this. We were advised about this a month ago, and have had quite a good email conversation with the authors about it. The text that is in there is some talk in the sections on compression, which say that a decompression error should be considered to be a security problem, not a data problem (in other words, don't typically let the user have the damaged plaintext), and some language that recommends encouraging people to use MDCs. There is also a relatively long section in Security Considerations. Take a look, I think you'll like it. Jon Received: by above.proper.com (8.11.6/8.11.3) id g7ELRFX15925 for ietf-openpgp-bks; Wed, 14 Aug 2002 14:27:15 -0700 (PDT) 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 g7ELRDw15921 for ; Wed, 14 Aug 2002 14:27:13 -0700 (PDT) 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 g7ELRkO00135; Wed, 14 Aug 2002 17:27:46 -0400 (EDT) To: warlord@mit.edu Cc: OpenPGP Subject: Re: Anybody know details about Schneier's "flaw"? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 14 Aug 2002 16:27:08 -0500 X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 08/14/2002 05:27:11 PM, Serialize complete at 08/14/2002 05:27:11 PM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0075D77A86256C15_=" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multipart message in MIME format. --=_alternative 0075D77A86256C15_= Content-Type: text/plain; charset="us-ascii" According to the link posted by someone else, (www.counterpane.com/pgp-attack.html), "We also recommend changes in the OpenPGP standard [3 ]to educe the effectiveness of ou attacks in these settings." Are the people activly working on the -bis draft aware of this? --John --=_alternative 0075D77A86256C15_= Content-Type: text/html; charset="us-ascii"
According to the link posted by someone else, (www.counterpane.com/pgp-attack.html), "We also recommend changes in the OpenPGP standard [3 ]to educe the effectiveness of ou attacks in these settings."

Are the people activly working on the -bis draft aware of this?

--John
--=_alternative 0075D77A86256C15_=-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EKuvn14708 for ietf-openpgp-bks; Wed, 14 Aug 2002 13:56:57 -0700 (PDT) Received: from mail.epost.de (web.epost.de [193.28.100.164] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7EKutw14704 for ; Wed, 14 Aug 2002 13:56:55 -0700 (PDT) Received: from dirichlet.mathematik.uni-bielefeld.de (80.130.173.9) by mail.epost.de (5.5.056) (authenticated as Marc.Mutz@epost.de) id 3D59336300019931; Wed, 14 Aug 2002 22:55:22 +0200 From: Marc Mutz Organization: KDE To: john.dlugosz@kodak.com, OpenPGP Subject: Re: Anybody know details about Schneier's "flaw"? Date: Wed, 14 Aug 2002 22:42:09 +0200 User-Agent: KMail/1.4.6 References: In-Reply-To: X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200208142242.10470@sendmail.mutz.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g7EKuuw14705 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 14 August 2002 16:40, john.dlugosz@kodak.com wrote: > In http://netscape.com.com/2100-1105-949506.html?type=pt there is a > vague mention of a problem: > Does anybody know more about this? Can a minor improvement to the > new -bis draft fix it? Do you mean this: www.counterpane.com/pgp-attack.html or something else? Marc - -- Mutig warf sich die kleine Überwachungskamera zwischen Täter Opfer! --Rena Tangens / FoeBuD e.V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9WsCh3oWD+L2/6DgRAqVFAJ9z9m/5tla4yV5lGeMmJOdrEnJMWACg+hNj 5mx4M2stDrwzlOfbUK4ncw4= =WEJd -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EH5wk00145 for ietf-openpgp-bks; Wed, 14 Aug 2002 10:05:58 -0700 (PDT) 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 g7EH5vw00141 for ; Wed, 14 Aug 2002 10:05:57 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7EH5rr05964 for ietf-openpgp@imc.org; Wed, 14 Aug 2002 13:05:53 -0400 Date: Wed, 14 Aug 2002 13:05:53 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket Message-ID: <20020814170553.GE682@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020813215844.GA20328@daredevil.joesixpack.net> <877kithpxr.fsf@alberti.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877kithpxr.fsf@alberti.gnupg.de> 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 (40% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Aug 14, 2002 at 09:14:56AM +0200, Werner Koch wrote: > > On Tue, 13 Aug 2002 23:58:44 +0200, Timo Schulz said: > > > Recently I stumbled over a problems with multiple subkeys. I know > > PGP doesn't let the user choose the key at all and GPG uses the > > newest key by default. What about a "primary subkey" subpacket > > I don't think this is needed. If a subkey is published a sending > implementation may choose any of the valid subkeys for encryption. > Although not specified in OpenPGP, it should select the newest one as > long as it has no creation date in the future. I imagine a primary subkey flag as more of a tie-breaker. If an implementation wanted to ignore the flag (whether for PFS or other reasons), that would be fine. If the implementation did not care, or could not reach a decision, the primary subkey would be chosen. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson Received: by above.proper.com (8.11.6/8.11.3) id g7EGpoj29495 for ietf-openpgp-bks; Wed, 14 Aug 2002 09:51:50 -0700 (PDT) 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 g7EGpnw29489 for ; Wed, 14 Aug 2002 09:51:49 -0700 (PDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA12421; Wed, 14 Aug 2002 12:51:50 -0400 (EDT) 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 MAA14125; Wed, 14 Aug 2002 12:51:49 -0400 (EDT) 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 MAA26160; Wed, 14 Aug 2002 12:51:48 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA02753; Wed, 14 Aug 2002 12:51:48 -0400 (EDT) To: Rodney Thayer Cc: ietf-openpgp@imc.org From: Derek Atkins Subject: Re: Anybody know details about Schneier's "flaw"? References: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> Date: 14 Aug 2002 12:51:48 -0400 In-Reply-To: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> Message-ID: Lines: 14 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: Rodney Thayer writes: > I think it's got too many odd things in it to require compression. Indeed.. As I said (perhaps incoherently), the attack only works if you DO NOT compress. If you compress the message then there is no way to XOR against the message. -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 g7EGYQT28207 for ietf-openpgp-bks; Wed, 14 Aug 2002 09:34:26 -0700 (PDT) Received: from yancey.pkiclue.com ([209.172.115.117]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7EGYOw28200 for ; Wed, 14 Aug 2002 09:34:24 -0700 (PDT) Received: from ferg237.pkiclue.com (IDENT:root@[127.0.0.1]) by yancey.pkiclue.com (8.9.3/8.9.3) with ESMTP id JAA10802 for ; Wed, 14 Aug 2002 09:33:59 -0700 Message-Id: <5.1.1.6.2.20020814093305.01451338@127.0.0.1> X-Sender: pkiclue@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 14 Aug 2002 09:34:03 -0700 To: ietf-openpgp@imc.org From: Rodney Thayer Subject: Re: Anybody know details about Schneier's "flaw"? In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think it's got too many odd things in it to require compression. Basically it's a "if you let yourself get social engineered then your crypto can be used against you" attack. At 10:50 AM 8/14/2002 -0400, Derek Atkins wrote: >john.dlugosz@kodak.com writes: > > > Does anybody know more about this? Can a minor improvement to the new > > -bis draft fix it? > >a) this only works if you do NOT compress your messages before you encrypt. >b) this only works if you do NOT sign the message AND you do NOT use an MDC > > > --John Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EGNgw26657 for ietf-openpgp-bks; Wed, 14 Aug 2002 09:23:42 -0700 (PDT) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7EGNew26647 for ; Wed, 14 Aug 2002 09:23:40 -0700 (PDT) Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout0.freenet.de with esmtp (Exim 4.05) id 17f0vt-0004Q2-00 for ietf-openpgp@imc.org; Wed, 14 Aug 2002 18:23:41 +0200 Received: from a5f9e.pppool.de ([213.6.95.158] helo=daredevil) by mx2.freenet.de with esmtp (Exim 4.05 #1) id 17f0vt-000480-00 for ietf-openpgp@imc.org; Wed, 14 Aug 2002 18:23:41 +0200 Received: from twoaday by daredevil with local (Exim 3.35 #1 (Debian)) id 17f11F-0000D0-00 for ; Wed, 14 Aug 2002 18:29:13 +0200 Date: Wed, 14 Aug 2002 18:29:13 +0200 From: Timo Schulz To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket Message-ID: <20020814162913.GA786@daredevil.joesixpack.net> Reply-To: twoaday@freakmail.de Mail-Followup-To: ietf-openpgp@imc.org References: <3D5A4CC9.DDE9E3BF@saiknes.lv> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D5A4CC9.DDE9E3BF@saiknes.lv> X-PGP-KeyID: BF3DF9B4 X-PGP-Request: lynx -source http://www.winpt.org/twoaday.asc User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed Aug 14 2002; 14:27, disastry@saiknes.lv wrote: > > which is placed on the self signature to force the implementation ^^^^^^^^^^^^^^ [snip] > where do you want to place it? In the self signature. > I think it may be better to put this in userid self sig > (this would allow different subkeys for different userids), > but then format can't be like "primary user id" (5.2.3.19.) subpacket, Yes, I see this is a problem. The easiest solution would be to put it in a signature which is part of the public key to have a non-ambiguous assignment. Timo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EEsLj21526 for ietf-openpgp-bks; Wed, 14 Aug 2002 07:54:21 -0700 (PDT) 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 g7EEsJw21518 for ; Wed, 14 Aug 2002 07:54:19 -0700 (PDT) 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 KAA20795; Wed, 14 Aug 2002 10:54:20 -0400 (EDT) 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 KAA11766; Wed, 14 Aug 2002 10:50:22 -0400 (EDT) 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 KAA25798; Wed, 14 Aug 2002 10:50:21 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA02544; Wed, 14 Aug 2002 10:50:21 -0400 (EDT) To: john.dlugosz@kodak.com Cc: OpenPGP Subject: Re: Anybody know details about Schneier's "flaw"? References: From: Derek Atkins Date: 14 Aug 2002 10:50:21 -0400 In-Reply-To: Message-ID: Lines: 17 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: john.dlugosz@kodak.com writes: > Does anybody know more about this? Can a minor improvement to the new > -bis draft fix it? a) this only works if you do NOT compress your messages before you encrypt. b) this only works if you do NOT sign the message AND you do NOT use an MDC > --John -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7EEej920752 for ietf-openpgp-bks; Wed, 14 Aug 2002 07:40:45 -0700 (PDT) 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 g7EEeiw20746 for ; Wed, 14 Aug 2002 07:40:44 -0700 (PDT) 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 g7EEfJO24386 for ; Wed, 14 Aug 2002 10:41:19 -0400 (EDT) To: OpenPGP Subject: Anybody know details about Schneier's "flaw"? X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: From: john.dlugosz@kodak.com Date: Wed, 14 Aug 2002 09:40:39 -0500 X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 08/14/2002 10:40:42 AM, Serialize complete at 08/14/2002 10:40:42 AM MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 0050A08D86256C15_=" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multipart message in MIME format. --=_alternative 0050A08D86256C15_= Content-Type: text/plain; charset="us-ascii" In http://netscape.com.com/2100-1105-949506.html?type=pt there is a vague mention of a problem: Schneier released information Monday about a separate flaw in the PGP (Pretty Good Privacy) program that is freely available and used to encrypt messages sent over the Internet. Schneier and Jonathan Katz of the University of Maryland at College Park found a way an attacker could intercept a PGP encrypted message, modify it without decrypting it, dupe the user into sending it back, and retrieve the original message Does anybody know more about this? Can a minor improvement to the new -bis draft fix it? --John --=_alternative 0050A08D86256C15_= Content-Type: text/html; charset="us-ascii"
In http://netscape.com.com/2100-1105-949506.html?type=pt there is a vague mention of a problem:


Schneier released information Monday about a separate flaw in the PGP (Pretty Good Privacy) program that is freely available and used to encrypt messages sent over the Internet.

Schneier and Jonathan Katz of the University of Maryland at College Park found a way an attacker could intercept a PGP encrypted message, modify it without decrypting it, dupe the user into sending it back, and retrieve the original message




Does anybody know more about this?  Can a minor improvement to the new -bis draft fix it?

--John
--=_alternative 0050A08D86256C15_=-- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7ECX7Q11353 for ietf-openpgp-bks; Wed, 14 Aug 2002 05:33:07 -0700 (PDT) Received: from hackserv.saiknes.lv (hackserv.klinkmann.lv [195.2.103.8]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7ECX4w11347 for ; Wed, 14 Aug 2002 05:33:05 -0700 (PDT) Received: from saiknes.lv (unverified [195.2.103.8]) by hackserv.saiknes.lv (SMTPRCV 0.45) with SMTP id ; Wed, 14 Aug 2002 14:27:53 0200 Message-ID: <3D5A4CC9.DDE9E3BF@saiknes.lv> Date: Wed, 14 Aug 2002 14:27:53 +0200 From: disastry@saiknes.lv 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: Primary subkey subpacket 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 Timo Schulz wrote: > Recently I stumbled over a problems with multiple subkeys. I know > PGP doesn't let the user choose the key at all and GPG uses the > newest key by default. What about a "primary subkey" subpacket > which is placed on the self signature to force the implementation > to use a special subkey. The format should be similar to the > "primary user id" packet. where do you want to place it? in subkey binding sig? that would be odd.. because this means creating another binding sig (when making new subkey(s)), and OpenPGP does not allow multiple binding sigs (unlike userid self sig), and then keyserver problems, etc.. I think it may be better to put this in userid self sig (this would allow different subkeys for different userids), but then format can't be like "primary user id" (5.2.3.19.) subpacket, it can be like Issuer (5.2.3.5.) or even better like Revocation key (5.2.3.15.) subpacket __ Disastry http://disastry.dhs.org/ -----BEGIN PGP SIGNATURE----- Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1 iQA/AwUBPVowpzBaTVEuJQxkEQMe1wCfUxOwO6zizzYmI40Gfl4pRxU4oK8AoNH8 /Zbj9VsWRMLt5Y/OOPPcUnw+ =c2b8 -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7E7j6l11072 for ietf-openpgp-bks; Wed, 14 Aug 2002 00:45:06 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by above.proper.com (8.11.6/8.11.3) with SMTP id g7E7j5w11068 for ; Wed, 14 Aug 2002 00:45:05 -0700 (PDT) Received: from async148-1.nas.onetel.net.uk by bells.cs.ucl.ac.uk with UK SMTP id ; Wed, 14 Aug 2002 08:44:47 +0100 From: Ian Brown To: ietf-openpgp Subject: RE: Primary subkey subpacket Date: Wed, 14 Aug 2002 08:44:56 +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) In-Reply-To: <877kithpxr.fsf@alberti.gnupg.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch wrote: > Having such a default subkey flag would inhibit automatic key > rollover. If we really want to specify handling of subkeys we should > first discuss Ian Brown's suggestions for PFS. (and Adam Back and Ben Laurie's. They're at http://www.cs.ucl.ac.uk/staff/I.Brown/draft-brown-pgp-pfs-03.txt, although the draft has expired.) Briefly, we suggested that for perfect forward secrecy, the subkey closest to its expiration date should be used. This is because the owner can wipe that subkey soonest, reducing the possibility that an attacker with a copy of the message ciphertext will then be able to get the subkey required to decrypt it. The draft's progress has stalled as the IESG liked the idea and suggested we go for standards track rather than informational publication; but I think they are waiting from some positive response from the working group on that. Do people think it's worth pursuing, either as informational or standards track? John Noerenberg thought it might be useful to split the document into a small standards track document defining the subkey flags we suggest (or even incorporate that into the rfc2440-bis draft, although we're likely too late for that now) along with a longer informational draft on using the protocol features for PFS. But we weren't sure if this more convoluted route was more useful. Any thoughts? Thanks, Ian Received: by above.proper.com (8.11.6/8.11.3) id g7E7CCC07125 for ietf-openpgp-bks; Wed, 14 Aug 2002 00:12:12 -0700 (PDT) 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 g7E7C9w07111 for ; Wed, 14 Aug 2002 00:12:09 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17etTd-0000so-00; Wed, 14 Aug 2002 10:26:01 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17esMq-0002rr-00; Wed, 14 Aug 2002 09:14:56 +0200 To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket References: <20020813215844.GA20328@daredevil.joesixpack.net> From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH Date: Wed, 14 Aug 2002 09:14:56 +0200 In-Reply-To: <20020813215844.GA20328@daredevil.joesixpack.net> (Timo Schulz's message of "Tue, 13 Aug 2002 23:58:44 +0200") Message-ID: <877kithpxr.fsf@alberti.gnupg.de> Lines: 19 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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 Tue, 13 Aug 2002 23:58:44 +0200, Timo Schulz said: > Recently I stumbled over a problems with multiple subkeys. I know > PGP doesn't let the user choose the key at all and GPG uses the > newest key by default. What about a "primary subkey" subpacket I don't think this is needed. If a subkey is published a sending implementation may choose any of the valid subkeys for encryption. Although not specified in OpenPGP, it should select the newest one as long as it has no creation date in the future. Having such a default subkey flag would inhibit automatic key rollover. If we really want to specify handling of subkeys we should first discuss Ian Brown's suggestions for PFS. Shalom-Salam, Werner Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7DMa6o07718 for ietf-openpgp-bks; Tue, 13 Aug 2002 15:36:06 -0700 (PDT) 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 g7DMa4w07714 for ; Tue, 13 Aug 2002 15:36:04 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7DMa2L14907 for ietf-openpgp@imc.org; Tue, 13 Aug 2002 18:36:02 -0400 Date: Tue, 13 Aug 2002 18:36:02 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Primary subkey subpacket Message-ID: <20020813223602.GN744@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20020813215844.GA20328@daredevil.joesixpack.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020813215844.GA20328@daredevil.joesixpack.net> 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 (30% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Aug 13, 2002 at 11:58:44PM +0200, Timo Schulz wrote: > Recently I stumbled over a problems with multiple subkeys. I know > PGP doesn't let the user choose the key at all and GPG uses the > newest key by default. What about a "primary subkey" subpacket > which is placed on the self signature to force the implementation > to use a special subkey. The format should be similar to the > "primary user id" packet. This is interesting. You'd have to tie it to the key flags subpacket somehow, as the notion of "primary" is different for different key types (primary signing subkey, primary encrypting subkey, etc.) It could even be a bit set in the key flags subpacket itself. David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson Received: by above.proper.com (8.11.6/8.11.3) id g7DMXfh07658 for ietf-openpgp-bks; Tue, 13 Aug 2002 15:33:41 -0700 (PDT) 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 g7DMXew07654 for ; Tue, 13 Aug 2002 15:33:40 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7DMXcZ14869 for ietf-openpgp@imc.org; Tue, 13 Aug 2002 18:33:38 -0400 Date: Tue, 13 Aug 2002 18:33:38 -0400 From: David Shaw To: OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Message-ID: <20020813223338.GM744@akamai.com> Mail-Followup-To: OpenPGP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 (30% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 12, 2002 at 11:14:49PM -0700, Jon Callas wrote: > > > I think that it would be nice to have the NAI X.509 packets documented. > > Having quasi-offical data formats that implimentors need to deal with, but > > are not documented, sounds like a bad idea to me. (Though, if it belongs > > in a seperate Internet Draft, I have no problem with that. But there > > should be some place to go other than the PGP source for this > > information.) > > It would be nice, but we have to get the owners of that code base to be > willing to document it, or have someone else do it. I presume there's > consensus that this is a good idea, as there are no further comments? To a certain extent these are already documented in the draft. The X.509 signature subpackets are in the "private or experimental" range (they use 100), and the signatures are also issued using public key algorithm 100, also experimental. It would be nice to see the format fully documented, though if it were widely adopted, it would result in one of the experimental values effectively losing its experimental status. > I want to get soon a new RFC number, so let's look at what there is to > finish up. > > * I've completely spaced on the notary signatures, apparently, so I'll get > those in soon. I've started roughing out some code for this (based on the discussion a few weeks ago) so we can have some implementation experience for this and the "revocation target" subpackets. Could you post the notary signature draft language when you put it together? > * I'll look at signature subpackets, and if the spec needs changes to jibe > with reality, I'll do it. MUSTs changed to SHOULDs, right? Yes, and the "two or more" subpacket requirement for the hashed section should probably be "zero or more". David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson Received: by above.proper.com (8.11.6/8.11.3) id g7DLqpr06166 for ietf-openpgp-bks; Tue, 13 Aug 2002 14:52:51 -0700 (PDT) Received: from mout0.freenet.de (mout0.freenet.de [194.97.50.131]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7DLqnw06160 for ; Tue, 13 Aug 2002 14:52:49 -0700 (PDT) Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtp (Exim 4.05) id 17ejae-00027g-00 for ietf-openpgp@imc.org; Tue, 13 Aug 2002 23:52:36 +0200 Received: from a57de.pppool.de ([213.6.87.222] helo=daredevil) by mx3.freenet.de with esmtp (Exim 4.05 #1) id 17ejae-0000sc-00 for ietf-openpgp@imc.org; Tue, 13 Aug 2002 23:52:36 +0200 Received: from twoaday by daredevil with local (Exim 3.35 #1 (Debian)) id 17ejga-0005I5-00 for ; Tue, 13 Aug 2002 23:58:44 +0200 Date: Tue, 13 Aug 2002 23:58:44 +0200 From: Timo Schulz To: ietf-openpgp@imc.org Subject: Primary subkey subpacket Message-ID: <20020813215844.GA20328@daredevil.joesixpack.net> Reply-To: twoaday@freakmail.de Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-KeyID: BF3DF9B4 X-PGP-Request: lynx -source http://www.winpt.org/twoaday.asc User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi! Recently I stumbled over a problems with multiple subkeys. I know PGP doesn't let the user choose the key at all and GPG uses the newest key by default. What about a "primary subkey" subpacket which is placed on the self signature to force the implementation to use a special subkey. The format should be similar to the "primary user id" packet. Timo Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7DBQGg29087 for ietf-openpgp-bks; Tue, 13 Aug 2002 04:26:16 -0700 (PDT) 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 g7DBQDw29083 for ; Tue, 13 Aug 2002 04:26:14 -0700 (PDT) Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17eaxi-0002Ak-00; Tue, 13 Aug 2002 14:39:50 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17eZrF-0000kH-00; Tue, 13 Aug 2002 13:29:05 +0200 To: Jon Callas Cc: Len Sassaman , OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt References: From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH Date: Tue, 13 Aug 2002 13:29:05 +0200 In-Reply-To: (Jon Callas's message of "Mon, 12 Aug 2002 23:14:49 -0700") Message-ID: <87wuqvgfpa.fsf@alberti.gnupg.de> Lines: 22 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) 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 Mon, 12 Aug 2002 23:14:49 -0700, Jon Callas said: > It would be nice, but we have to get the owners of that code base to be > willing to document it, or have someone else do it. I presume there's > consensus that this is a good idea, as there are no further comments? I think it is far easier to allow PGP keys for TLS (there is a specification and at least one implementation) than to intermix the two protocol and raise the complexity even more. Afaik, Peter Gutmann is working on a proposal on how to use X.509 keys with PGP. > * I'll look at signature subpackets, and if the spec needs changes to jibe > with reality, I'll do it. MUSTs changed to SHOULDs, right? Yes. Salam-Shalom, Werner Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7D6EhP20963 for ietf-openpgp-bks; Mon, 12 Aug 2002 23:14:43 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7D6Egw20955 for ; Mon, 12 Aug 2002 23:14:42 -0700 (PDT) Received: from [63.73.97.182] (63.73.97.182) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Mon, 12 Aug 2002 23:14:45 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 12 Aug 2002 23:14:49 -0700 Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt From: Jon Callas To: Len Sassaman , OpenPGP Message-ID: In-Reply-To: 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: > I think that it would be nice to have the NAI X.509 packets documented. > Having quasi-offical data formats that implimentors need to deal with, but > are not documented, sounds like a bad idea to me. (Though, if it belongs > in a seperate Internet Draft, I have no problem with that. But there > should be some place to go other than the PGP source for this > information.) It would be nice, but we have to get the owners of that code base to be willing to document it, or have someone else do it. I presume there's consensus that this is a good idea, as there are no further comments? I want to get soon a new RFC number, so let's look at what there is to finish up. * I've completely spaced on the notary signatures, apparently, so I'll get those in soon. * I'll look at signature subpackets, and if the spec needs changes to jibe with reality, I'll do it. MUSTs changed to SHOULDs, right? Anything else? Jon Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7D2pcW13721 for ietf-openpgp-bks; Mon, 12 Aug 2002 19:51:38 -0700 (PDT) Received: from mgo.iij.ad.jp (root@mgo.iij.ad.jp [202.232.15.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7D2paw13717 for ; Mon, 12 Aug 2002 19:51:36 -0700 (PDT) Received: from ns.iij.ad.jp ([192.168.2.111]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id LAA14483 for ; Tue, 13 Aug 2002 11:51:39 +0900 (JST) Received: from fs.iij.ad.jp (root@fs.iij.ad.jp [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA19352 for ; Tue, 13 Aug 2002 11:51:38 +0900 (JST) Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id LAA10577 for ; Tue, 13 Aug 2002 11:51:38 +0900 (JST) Date: Tue, 13 Aug 2002 11:54:14 +0900 (JST) Message-Id: <20020813.115414.46613679.kazu@iijlab.net> To: ietf-openpgp@imc.org Subject: Fw: Secret Key Packet Formats From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 3.0.60 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Tue_Aug_13_11:54:15_2002_891)--" Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----Next_Part(Tue_Aug_13_11:54:15_2002_891)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I sent the following message for 05.txt in June. But 06.txt does not include my suggestions. To reminder, I post the message gain. I hope my suggestions will be included in 07.txt. --Kazu ----Next_Part(Tue_Aug_13_11:54:15_2002_891)-- Content-Type: Message/Rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Date: Thu, 27 Jun 2002 19:25:57 +0900 (JST) Message-Id: <20020627.192557.125129914.kazu@iijlab.net> To: ietf-openpgp@imc.org Cc: stefan@epy.co.at Subject: Secret Key Packet Formats From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) X-Mailer: Mew version 3.0.55 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello all, I have several comments on Section 5.5.3 (Secret Key Packet Formats) of 2440bis-05. > - [Optional] If secret data is encrypted, Initial Vector (IV) of > the same length as the cipher's block size. The following might be more easy to understand. - [Optional] If secret data is encrypted(string-to-key usage octet was not 0), 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. If string-to-key usage octet was 0, this field is not encrypted. So, this should be: - Plain or encrypted multi-precision integers comprising the secret key data. These algorithm-specific fields are as described below. > - If the string-to-key usage octet was 255, then a two-octet > checksum of the plaintext of the algorithm-specific portion (sum > of all octets, mod 65536). If the string-to-key usage octet was > 254, then a 20-octet SHA-1 hash of the plaintext of the > algorithm-specific portion. This checksum or hash is encrypted > together with the algorithm-specific fields. This does not corver the other values than 254 and 255. According to RFC 2440, a two-octet checksum is necessary for the other values. > The 16-bit checksum that follows the algorithm-specific portion is > the algebraic sum, mod 65536, of the plaintext of all the > algorithm-specific octets (including MPI prefix and data). With V3 > keys, the checksum is stored in the clear. With V4 keys, the > checksum is encrypted like the algorithm-specific data. This value > is used to check that the passphrase was correct. However, this > checksum is deprecated; an implementation SHOULD NOT use it, but > should rather use the SHA-1 hash denoted with a usage octet of 254. > The reason for this is that there are some attacks on the private > key that can undetectably modify the secret key. Using a SHA-1 hash > prevents this. "16-bit checksum" should be "two-octet checksum". This paragraph should cover V2. Actually, old PGP commands produce Secret Key Packet with V2. Combination of string-to-key usage octet and format version is unclear. 2440bis-05 is read like: V3 V4 0 254 encrypted sha1 hash encrypted sha1 hash 255 clear checksum encrypted checksum others But I think this matrix should be: V2/V3 V4 0 clear checksum clear checksum 254 clear checksum encrypted sha1 hash 255 clear checksum encrypted checksum others clear checksum encrypted checksum If this is correct, I hope improvement of this section will be made in the next draft. Thanks. --Kazu ----Next_Part(Tue_Aug_13_11:54:15_2002_891)---- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CL2Rt29676 for ietf-openpgp-bks; Mon, 12 Aug 2002 14:02:27 -0700 (PDT) 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 g7CL2Qw29672 for ; Mon, 12 Aug 2002 14:02:26 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7CL2Nj05405 for ietf-openpgp@imc.org; Mon, 12 Aug 2002 17:02:23 -0400 Date: Mon, 12 Aug 2002 17:02:23 -0400 From: David Shaw To: OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Message-ID: <20020812210223.GA5163@akamai.com> Mail-Followup-To: OpenPGP References: <200208121726.g7CHQAw16824@above.proper.com> <20020812183508.GD2319@akamai.com> <002001c2423c$5aa79bc0$f0c12609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002001c2423c$5aa79bc0$f0c12609@transarc.ibm.com> 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 (22% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 12, 2002 at 04:10:48PM -0400, Michael Young wrote: > From: "David Shaw" > > 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket > ... > > Come to think, both PGP and GnuPG create v4 signatures with a hashed > > timestamp, and an unhashed issuer. Are they compliant? ;) > > I don't think that the specification should require either. It would be > fair to note that many implementations will be unable (or unwilling) to > interpret a signature without these things. > > But even if the issuer remains a MUST, it certainly doesn't need > to be in the hashed material. As it stands, the specification doesn't > say so exactly -- it merely suggests that they should be the first two > subpackets, which is silly if the timestamp is hashed but the issuer > is not. I would just excise the suggestion entirely. 2440bis does say (well, imply) that they are both hashed. In section 5.2.3. ("Version 4 Signature Packet Format"), it says that the hashed section is made up of "two or more" subpackets, and the unhashed section is made up of "zero or more" subpackets. Given the language elsewhere, I assume that these two hashed subpackets are the required issuer and timestamp. I agree with you though - I think that a signature should not require any subpacket to be present (SHOULD perhaps, but not MUST). David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CKBrk26293 for ietf-openpgp-bks; Mon, 12 Aug 2002 13:11:53 -0700 (PDT) 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 g7CKBkw26284 for ; Mon, 12 Aug 2002 13:11:51 -0700 (PDT) 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 PAA14006 for ; Mon, 12 Aug 2002 15:58:59 -0400 (EDT) Received: from mwyoung (dhcp-193-40.transarc.ibm.com [9.38.193.240]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id QAA17982 for ; Mon, 12 Aug 2002 16:11:42 -0400 (EDT) Message-ID: <002001c2423c$5aa79bc0$f0c12609@transarc.ibm.com> From: "Michael Young" To: "OpenPGP" References: <200208121726.g7CHQAw16824@above.proper.com> <20020812183508.GD2319@akamai.com> Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Date: Mon, 12 Aug 2002 16:10:48 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 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" > 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket ... > Come to think, both PGP and GnuPG create v4 signatures with a hashed > timestamp, and an unhashed issuer. Are they compliant? ;) I don't think that the specification should require either. It would be fair to note that many implementations will be unable (or unwilling) to interpret a signature without these things. But even if the issuer remains a MUST, it certainly doesn't need to be in the hashed material. As it stands, the specification doesn't say so exactly -- it merely suggests that they should be the first two subpackets, which is silly if the timestamp is hashed but the issuer is not. I would just excise the suggestion entirely. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPVgWJVMkvpTT8vCGEQLEMwCfUnZsYv6w/jQVYjBttwFWq7Y8by4AnRAY L1gn2QkotnPczcBtgFwcLJ/4 =tzg2 -----END PGP SIGNATURE----- Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CIZCV22772 for ietf-openpgp-bks; Mon, 12 Aug 2002 11:35:12 -0700 (PDT) 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 g7CIZBw22766 for ; Mon, 12 Aug 2002 11:35:11 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7CIZ8D03310 for ietf-openpgp@imc.org; Mon, 12 Aug 2002 14:35:08 -0400 Date: Mon, 12 Aug 2002 14:35:08 -0400 From: David Shaw To: OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Message-ID: <20020812183508.GD2319@akamai.com> Mail-Followup-To: OpenPGP References: <200208121726.g7CHQAw16824@above.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 (21% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Aug 12, 2002 at 10:55:27AM -0700, Len Sassaman wrote: > > On Mon, 12 Aug 2002, Werner Koch wrote: > > > I see no more problem with the draft. How lets try again to kick off > > the the interop tests. > > I think that it would be nice to have the NAI X.509 packets documented. > Having quasi-offical data formats that implimentors need to deal with, but > are not documented, sounds like a bad idea to me. (Though, if it belongs > in a seperate Internet Draft, I have no problem with that. But there > should be some place to go other than the PGP source for this > information.) Speaking about the X.509 signatures, I wonder if they are strictly compliant with this draft. 2440bis seems to say that v4 signatures require (MUST) an issuer subpacket and a timestamp subpacket, and that those subpackets are both hashed (as per the "two or more" language in section 5.2.3, and section 5.2.4.1. Subpacket Hints). The X.509 sigs don't have an issuer subpacket at all. If this reading is incorrect, it may be good to clarify things a bit. I suppose it could be argued that since the X.509 sigs are made with an experimental public key algorithm (100), the signature format does not necessarily follow. Come to think, both PGP and GnuPG create v4 signatures with a hashed timestamp, and an unhashed issuer. Are they compliant? ;) David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CHtTD18364 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:55:29 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CHtRw18360 for ; Mon, 12 Aug 2002 10:55:27 -0700 (PDT) Received: by thetis.deor.org (Postfix, from userid 500) id 0FE9345022; Mon, 12 Aug 2002 10:55:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id F0DE548023; Mon, 12 Aug 2002 10:55:27 -0700 (PDT) Date: Mon, 12 Aug 2002 10:55:27 -0700 (PDT) From: Len Sassaman X-Sender: To: OpenPGP , Werner Koch Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt In-Reply-To: <200208121726.g7CHQAw16824@above.proper.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 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 Mon, 12 Aug 2002, Werner Koch wrote: > I see no more problem with the draft. How lets try again to kick off > the the interop tests. I think that it would be nice to have the NAI X.509 packets documented. Having quasi-offical data formats that implimentors need to deal with, but are not documented, sounds like a bad idea to me. (Though, if it belongs in a seperate Internet Draft, I have no problem with that. But there should be some place to go other than the PGP source for this information.) --Len. Received: by above.proper.com (8.11.6/8.11.3) id g7CHleH17451 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:47:40 -0700 (PDT) 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 g7CHlcw17447 for ; Mon, 12 Aug 2002 10:47:39 -0700 (PDT) Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g7CHlPW02535 for ietf-openpgp@imc.org; Mon, 12 Aug 2002 13:47:25 -0400 Date: Mon, 12 Aug 2002 13:47:25 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Message-ID: <20020812174725.GC2319@akamai.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200208121120.HAA16270@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200208121120.HAA16270@ietf.org> 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 (21% of Full) User-Agent: Mutt/1.5.1i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I noticed the "notary signature" specification was not present. I thought we had sufficiently specified how that would work? David -- David Shaw | dshaw@jabberwocky.com | WWW http://www.jabberwocky.com/ +---------------------------------------------------------------------------+ "There are two major products that come out of Berkeley: LSD and UNIX. We don't believe this to be a coincidence." - Jeremy S. Anderson Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CHSfQ16863 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:28:41 -0700 (PDT) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CHSew16859 for ; Mon, 12 Aug 2002 10:28:40 -0700 (PDT) Received: from rusfw by Mail.CERT.Uni-Stuttgart.DE with local (Exim 4.04) id 17eIzh-0006SA-00; Mon, 12 Aug 2002 19:28:41 +0200 To: Jon Callas Cc: OpenPGP Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt References: From: Florian Weimer Date: Mon, 12 Aug 2002 19:28:41 +0200 In-Reply-To: (Jon Callas's message of "Mon, 12 Aug 2002 10:23:26 -0700") Message-ID: <871y94yoja.fsf@CERT.Uni-Stuttgart.DE> Lines: 23 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (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: Jon Callas writes: > On 8/12/02 7:07 AM, "Florian Weimer" wrote: > >> IMHO, the draft does not specify the semantics of expiration in a way >> which would warrant such statement. I don't believe we can agree on a >> specific set of expiration semantics even in the limited circle of >> this WG. >> >> BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html) >> is definitely worth a read. > > That particular change was correcting a typo in the previous draft. It has > nothing to do with the new paper. Oh, I didn't want to imply *that* (hence "BTW"). I still think that the change is misleading. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CHQDU16829 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:26:13 -0700 (PDT) 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 g7CHQAw16824 for ; Mon, 12 Aug 2002 10:26:10 -0700 (PDT) Date: Mon, 12 Aug 2002 10:26:10 -0700 (PDT) Message-Id: <200208121726.g7CHQAw16824@above.proper.com> Received: from uucp by kasiski.gnupg.de with local-rmail (Exim 3.32 #1 (Debian)) id 17eK6M-0005WR-00; Mon, 12 Aug 2002 20:39:38 +0200 Received: from wk by alberti.gnupg.de with local (Exim 3.35 #1 (Debian)) id 17eJ0v-0004hM-00; Mon, 12 Aug 2002 19:29:57 +0200 X-From-Line: nobody Mon Aug 12 19:29:15 2002 To: Florian Weimer Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt References: <200208121120.HAA16270@ietf.org> <87eld41880.fsf@CERT.Uni-Stuttgart.DE> From: Werner Koch X-PGP-KeyID: 621CC013 X-Request-PGP: finger://wk@g10code.com X-FSFE-Motto: Omnis enim res, quae dando non deficit, dum habetur et non datur, nondum habetur, quomodo habenda est. X-FSFE-Info: http://fsfeurope.org Organisation: g10 Code GmbH In-Reply-To: <87eld41880.fsf@CERT.Uni-Stuttgart.DE> (Florian Weimer's message of "Mon, 12 Aug 2002 16:07:27 +0200") User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 20 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 12 Aug 2002 16:07:27 +0200, Florian Weimer said: > IMHO, the draft does not specify the semantics of expiration in a way > which would warrant such statement. I don't believe we can agree on a > specific set of expiration semantics even in the limited circle of PNX (PGP is not X.509) ;-) > BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html) > is definitely worth a read. And the reason why Jon released the draft and sharped the MDC wording. I see no more problem with the draft. How lets try again to kick off the the interop tests. Salam-Shalom, Werner Received: by above.proper.com (8.11.6/8.11.3) id g7CHNTb16654 for ietf-openpgp-bks; Mon, 12 Aug 2002 10:23:29 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CHNSw16650 for ; Mon, 12 Aug 2002 10:23:28 -0700 (PDT) Received: from [63.73.97.182] (63.73.97.182) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Mon, 12 Aug 2002 10:23:17 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 12 Aug 2002 10:23:26 -0700 Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt From: Jon Callas To: Florian Weimer , OpenPGP Message-ID: In-Reply-To: <87eld41880.fsf@CERT.Uni-Stuttgart.DE> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 8/12/02 7:07 AM, "Florian Weimer" wrote: > IMHO, the draft does not specify the semantics of expiration in a way > which would warrant such statement. I don't believe we can agree on a > specific set of expiration semantics even in the limited circle of > this WG. > > BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html) > is definitely worth a read. That particular change was correcting a typo in the previous draft. It has nothing to do with the new paper. Jon Received: by above.proper.com (8.11.6/8.11.3) id g7CE7Ss04928 for ietf-openpgp-bks; Mon, 12 Aug 2002 07:07:28 -0700 (PDT) Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CE7Rw04924 for ; Mon, 12 Aug 2002 07:07:27 -0700 (PDT) Received: from rusfw by Mail.CERT.Uni-Stuttgart.DE with local (Exim 4.04) id 17eFqx-0002oG-00 for ietf-openpgp@imc.org; Mon, 12 Aug 2002 16:07:27 +0200 To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt References: <200208121120.HAA16270@ietf.org> From: Florian Weimer Date: Mon, 12 Aug 2002 16:07:27 +0200 In-Reply-To: <200208121120.HAA16270@ietf.org> (Internet-Drafts@ietf.org's message of "Mon, 12 Aug 2002 07:20:37 -0400") Message-ID: <87eld41880.fsf@CERT.Uni-Stuttgart.DE> Lines: 15 User-Agent: Gnus/5.090007 (Oort Gnus v0.07) Emacs/21.2 (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: | Revoking a self-signature or allowing it to expire has a defined | semantic meaning. IMHO, the draft does not specify the semantics of expiration in a way which would warrant such statement. I don't believe we can agree on a specific set of expiration semantics even in the limited circle of this WG. BTW, the referenced paper (http://www.counterpane.com/pgp-attack.html) is definitely worth a read. -- Florian Weimer Weimer@CERT.Uni-Stuttgart.DE University of Stuttgart http://CERT.Uni-Stuttgart.DE/people/fw/ RUS-CERT fax +49-711-685-5898 Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g7CBLum26091 for ietf-openpgp-bks; Mon, 12 Aug 2002 04:21:56 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g7CBLtw26087 for ; Mon, 12 Aug 2002 04:21:55 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16270; Mon, 12 Aug 2002 07:20:38 -0400 (EDT) Message-Id: <200208121120.HAA16270@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-rfc2440bis-06.txt Date: Mon, 12 Aug 2002 07:20:37 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : OpenPGP Message Format Author(s) : J. Callas, L. Donnerhacke, H. Finney, R. Thayer Filename : draft-ietf-openpgp-rfc2440bis-06.txt Pages : 71 Date : 09-Aug-02 This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-rfc2440bis-06.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020809153523.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-rfc2440bis-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020809153523.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by above.proper.com (8.11.6/8.11.3) id g76BFel18363 for ietf-openpgp-bks; Tue, 6 Aug 2002 04:15:40 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g76BFcw18359 for ; Tue, 6 Aug 2002 04:15:39 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04053; Tue, 6 Aug 2002 07:14:25 -0400 (EDT) Message-Id: <200208061114.HAA04053@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: namedropper@ops.ietf.org, ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-josefsson-cert-openpgp-00.txt Date: Tue, 06 Aug 2002 07:14:25 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : OpenPGP data in the CERT RR Author(s) : S. Josefsson Filename : draft-josefsson-cert-openpgp-00.txt Pages : 9 Date : 05-Aug-02 This draft describes the decisions made in one pair of applications [4][5] that respectively serves and retrieve OpenPGP [3] Certificates and Revocation Signatures using the CERT Resources Record [2]. The intent is to provide a discussion on the kind of general updates needed to the CERT specification, and some suggested specific updates for the OpenPGP sub-type. It is offered in the hope that this specification, together with similar efforts for other applications, can be reviewed when designing a generic solution or guidelines for storing application keying material in the Domain Name System (DNS), should it ever happen. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-josefsson-cert-openpgp-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-josefsson-cert-openpgp-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-josefsson-cert-openpgp-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020805132652.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-josefsson-cert-openpgp-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-josefsson-cert-openpgp-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020805132652.I-D@ietf.org> --OtherAccess-- --NextPart--