From owner-ietf-openpgp@mail.imc.org Thu Sep 01 06:35:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAmQ5-0000w8-Vg for openpgp-archive@megatron.ietf.org; Thu, 01 Sep 2005 06:35:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15832 for ; Thu, 1 Sep 2005 06:35:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81AGAnv016214; Thu, 1 Sep 2005 03:16:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81AGA4E016213; Thu, 1 Sep 2005 03:16:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j81AG8Zc016154 for ; Thu, 1 Sep 2005 03:16:09 -0700 (PDT) (envelope-from karl.kashofer@gmx.at) Received: (qmail invoked by alias); 01 Sep 2005 10:16:02 -0000 Received: from unknown (EHLO hotmail.com) [81.189.102.241] by mail.gmx.net (mp029) with SMTP; 01 Sep 2005 12:16:02 +0200 X-Authenticated: #7548666 Received: from 127.0.0.1 (AVG SMTP 7.0.344 [267.10.16]); Thu, 01 Sep 2005 11:15:41 +0100 Message-ID: <4316D4CC.8080501@gmx.at> Date: Thu, 01 Sep 2005 11:15:40 +0100 From: Karl Kashofer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Encrypt subject References: <20050831224025.BBED557EF5@finney.org> In-Reply-To: <20050831224025.BBED557EF5@finney.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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 Hi ! > The problem is that we do sort of have a solution to this already, which > Werner described: use PGP/MIME. MIME allows for embedding one email > message inside another, and the MIME security extensions, including > PGP/MIME, show how to encrypt such an embedded message. Well the way Werner describes it, he just advises not to use a Subject. >>Simply send your mail as an encrypted message/rfc2822 MIME message and >>put an innocent subject into the header. > The problem is that almost no mailers support this. Few enough even > support PGP/MIME, and then they would also have to be smart enough to > figure out what to do with an embedded email message. Replacing the > enclosing message's headers with those from the embedded message is not > an obvious thing to do. So this would adhere to the standards, and allow to embed headers inside the PGP encryption block ? Could you by any means describe this in more detail ? I would try to bring it to the attention of enigmail developers, maybe they are interested in it. They have Per-Recipient-Rules, so it would be possible to implement that, and then specify it in these rules, so its only used for recipients which are able to decrypt it. I do that with PGP/MIME to only use it for thunderbird recipients, works fine. I would really like to see this implemented, and I am sure it annoys a few other people as well. Cheers, Karl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFtTMyD2v/adjdKMRAoCiAJ0butw/p1Nnefj7dOV0K/coITSRKgCg1M6r mFt5/JSKgtAVVezPYxIpPVE= =n0fX -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Sep 01 14:25:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAtkL-00021q-2s for openpgp-archive@megatron.ietf.org; Thu, 01 Sep 2005 14:25:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18658 for ; Thu, 1 Sep 2005 14:25:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81I3AGR058080; Thu, 1 Sep 2005 11:03:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81I3Att058079; Thu, 1 Sep 2005 11:03:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81I37DQ058070 for ; Thu, 1 Sep 2005 11:03:09 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id D128B57EF5; Thu, 1 Sep 2005 10:13:22 -0700 (PDT) To: ietf-openpgp@imc.org, karl.kashofer@gmx.at Subject: Re: Encrypt subject Message-Id: <20050901171322.D128B57EF5@finney.org> Date: Thu, 1 Sep 2005 10:13:22 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Karl Kashofer writes: > So this would adhere to the standards, and allow to embed headers inside > the PGP encryption block ? > > Could you by any means describe this in more detail ? > > I would try to bring it to the attention of enigmail developers, maybe > they are interested in it. Well, PGP/MIME is http://www.ietf.org/rfc/rfc3156.txt which is based on the MIME security extensions, http://www.ietf.org/rfc/rfc1847.txt . The message/rfc822 type for embedding mail with headers is described in http://www.ietf.org/rfc/rfc2046.txt section 5.2.1. The implementation concept would be that when you decrypt a PGP/MIME message and find that the inner type is message/rfc822, you would promote the relevant mail headers, particularly Subject, from the inner type to the outer message. This might also include source information ("From"), for example if the message were delivered via an anonymous remailer network. Maybe some other headers could also be usefully encrypted. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Sep 01 15:33:33 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuoX-00043C-Lq for openpgp-archive@megatron.ietf.org; Thu, 01 Sep 2005 15:33:33 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25765 for ; Thu, 1 Sep 2005 15:33:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81JEuGh064642; Thu, 1 Sep 2005 12:14:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81JEuxf064641; Thu, 1 Sep 2005 12:14:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81JEsLT064634 for ; Thu, 1 Sep 2005 12:14:55 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EAuck-0002Td-FT for ; Thu, 01 Sep 2005 21:21:22 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EApQj-0003QO-MC; Thu, 01 Sep 2005 15:48:37 +0200 To: Karl Kashofer Cc: ietf-openpgp@imc.org Subject: Re: Encrypt subject References: <20050831224025.BBED557EF5@finney.org> <4316D4CC.8080501@gmx.at> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Thu, 01 Sep 2005 15:48:36 +0200 In-Reply-To: <4316D4CC.8080501@gmx.at> (Karl Kashofer's message of "Thu, 01 Sep 2005 11:15:40 +0100") Message-ID: <877je0oq4r.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 01 Sep 2005 11:15:40 +0100, Karl Kashofer said: > Well the way Werner describes it, he just advises not to use a Subject. What I mean is that a subject you need to decrypt first is not very usable for the purpose a subject line is commonly used, i.e. to quickly decide what messages belong together and whether to read them. With a slow connection and POP3 and with IMAP in general many people just look at the subject to decide whether to retrieve the entire message. Requiring to decrypt it first make no sense then. So, my suggestion is to use a non-sense subject line to merely help visualizing a theread. > Could you by any means describe this in more detail ? Something like this: From: me@example.org To: you@example.com Subject: none Content-Type: multipart/encrypted; protocol=application/pgp-encrypted; boundary="xxxxxx" --xxxxxx Content-Type: application/pgp-encrypted Version: 1 --xxxxxx Content-Type: application/octet-stream & Content-Type: message/rfc822; boundary="yyyyy" & & & --yyyyyy & From: me@example.org & To: you@example.com & Subject: Don't tell anyone that PGP/MIME just works & Content-Type: text/plain & & Proposal on how to gain world domination of PGP/MIME & and to abolish any use of S/MIME. & & --yyyyyy-- --xxxxxx-- Where the lines marked by "&" are actually encrypted. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Thu Sep 01 15:41:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EAuvn-00089G-3D for openpgp-archive@megatron.ietf.org; Thu, 01 Sep 2005 15:41:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26104 for ; Thu, 1 Sep 2005 15:41:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81JPXq9065753; Thu, 1 Sep 2005 12:25:33 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81JPX3D065752; Thu, 1 Sep 2005 12:25:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j81JPWTv065732 for ; Thu, 1 Sep 2005 12:25:32 -0700 (PDT) (envelope-from karl.kashofer@gmx.at) Received: (qmail invoked by alias); 01 Sep 2005 19:25:25 -0000 Received: from unknown (EHLO [10.0.0.50]) [81.189.102.241] by mail.gmx.net (mp026) with SMTP; 01 Sep 2005 21:25:25 +0200 X-Authenticated: #7548666 Received: from 127.0.0.1 (AVG SMTP 7.0.344 [267.10.16]); Thu, 01 Sep 2005 20:24:54 +0100 Message-ID: <43175586.3040100@gmx.at> Date: Thu, 01 Sep 2005 20:24:54 +0100 From: Karl Kashofer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-openpgp@imc.org Subject: Re: Encrypt subject References: <20050831224025.BBED557EF5@finney.org> <4316D4CC.8080501@gmx.at> <877je0oq4r.fsf@wheatstone.g10code.de> In-Reply-To: <877je0oq4r.fsf@wheatstone.g10code.de> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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 Hi ! > What I mean is that a subject you need to decrypt first is not very > usable for the purpose a subject line is commonly used, i.e. to > quickly decide what messages belong together and whether to read them. > > With a slow connection and POP3 and with IMAP in general many people > just look at the subject to decide whether to retrieve the entire > message. Requiring to decrypt it first make no sense then. I see what you mean, but from a practical point of view, how much PGP encrypted spam have you gotten lately ? I assume if its encrypted it might actually be worth reading ? > So, my suggestion is to use a non-sense subject line to merely help > visualizing a theread. Sure, but if enigmail were able to permanently decrypt messages this could still be accomplished once the message is decrypted. Problem seems to be that mozilla/thunderbird does atm not allow them to permanently modify the message, so it might take a while to implement that anyway. Thanks for your help, I will carry this to the enigmail mailing list, Cheers, Karl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDF1WFyD2v/adjdKMRAjh8AKDv4KMDbGWH12JSU2C3yJM7B7p8OgCfep+X gW6I3WSYKl7ejzqudPQUp5Q= =9fjR -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Sep 02 03:22:14 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB5sL-0006lz-Th for openpgp-archive@megatron.ietf.org; Fri, 02 Sep 2005 03:22:14 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA19977 for ; Fri, 2 Sep 2005 03:22:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8271LwO062931; Fri, 2 Sep 2005 00:01:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8271LG8062930; Fri, 2 Sep 2005 00:01:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8271JqI062922 for ; Fri, 2 Sep 2005 00:01:20 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EB5eO-0006Wj-BI for ; Fri, 02 Sep 2005 09:07:48 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EB5Wq-0004WP-4H; Fri, 02 Sep 2005 09:00:00 +0200 To: Karl Kashofer Cc: ietf-openpgp@imc.org Subject: Re: Encrypt subject References: <20050831224025.BBED557EF5@finney.org> <4316D4CC.8080501@gmx.at> <877je0oq4r.fsf@wheatstone.g10code.de> <43175586.3040100@gmx.at> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Fri, 02 Sep 2005 09:00:00 +0200 In-Reply-To: <43175586.3040100@gmx.at> (Karl Kashofer's message of "Thu, 01 Sep 2005 20:24:54 +0100") Message-ID: <87ek88kl8v.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 01 Sep 2005 20:24:54 +0100, Karl Kashofer said: > I see what you mean, but from a practical point of view, how much PGP > encrypted spam have you gotten lately ? I was not talking about spam but on how to prioritize/ignore regular mail. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Fri Sep 02 12:44:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBEe5-0003G9-6K for openpgp-archive@megatron.ietf.org; Fri, 02 Sep 2005 12:44:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA16971 for ; Fri, 2 Sep 2005 12:44:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j82GMmR0030768; Fri, 2 Sep 2005 09:22:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j82GMmRi030767; Fri, 2 Sep 2005 09:22:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from cliodev.pgp.com (me@CLIODEV.IHTFP.ORG [204.107.200.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j82GMlxl030760 for ; Fri, 2 Sep 2005 09:22:47 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j82GMfVW011099; Fri, 2 Sep 2005 12:22:41 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j82GMZta011096; Fri, 2 Sep 2005 12:22:35 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: proceedings@ietf.org Cc: ietf-openpgp@imc.org Subject: IETF-63 Proceedings Submission Date: Fri, 02 Sep 2005 12:22:35 -0400 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Minutes of OpenPGP Meeting at IETF-63 -derek --=-=-= Content-Disposition: attachment; filename=Minutes-63.txt Content-Description: OpenPGP Minutes AGENDA -- -- Introduction and Agenda Bashing No changes -- 2440 bis status - In "pentultimate last call" for some time (over a year) - now only doing tweaks to the document. - If you want changes in wording - need to be compatable and suggest text. - Only open issue is David Shaw's BNF request for literal+literal. No reason not to include David Shaw's request, but not in draft 14. Should go into 15 - Run last call and finish this document - Use difference documents for new work - downside is that not everything will be in a small number of documents. Good news is that will have a fixed definitive document -- 2440 next steps - Go to Last call. finish by end of August - Try for a bake off? try for Draft Standard. (early in '06) - update milestones - proposal given. - Draft standard would be tried for 6 months after IESG approval. - New Life - New documents not hit 2440bis. - -- Proposed Milestones Aug 05 WGLC for 2440bis Sep 05 Submit 2440bis to IESG as Proposed Standard Nov 05 Finish Interop Test Plan Jan 06 Begin 2440bis Interop Testing Mar 06 Request DRAFT Status for 2440bis - No Objections --- Message Header - draft-josefsson-openpgp-mailnews-header-01.txt - standardize some X- headers for PGP. - Lookup URL and key id of a sender - simplified original by dropping some unnecessary data. - key id - longer fingerprint - url to key - What is the problem to be solved? - Not completely clear - invent header that could be used programatically to lookup key and keyid of sender - Manual cut & paste? - request for additinoal current usage of old headers for inclusion in the doument. - Open Issuses: - Add token to state strong preference for reciving PGP and potentially the PGP format to be sent. - IETF process restricted to MIME? - place same info into a packet? - Keyserver field? - unsure of what this would be really for. Next expansion of the idea. - BNF problems on the draft need corrections. Open MIKE JON - Supports idea of draft - supports "supports token" - PGP has a similar item already used. used with different values for different reading devices. - Wants support to plain inline text - kill mime and only use plain text as a personal preference. - response - Need additional proposals to solve some of the problems? JON - display problems not format issues - Don't ban text only w/o mime wrappers. 8-bit character set problems with servers - Vigourous dispute on issues with character sets. Thomas Roessler - two formats - with and w/o tag - please elimiate the untagged version. ??? - Please add finger print header - used for validation. - possible support already? JON - KeyID is a trucated fingerprint - allow for longer id to get fuller fingerprint w/o much additional parsing. - -00 to -01 allowed for longer KeyID from a fixed length. --- Open Discussion - Meeting closed. --=-=-= -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available --=-=-=-- From owner-ietf-openpgp@mail.imc.org Fri Sep 02 14:07:24 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBFwh-0005yn-Lp for openpgp-archive@megatron.ietf.org; Fri, 02 Sep 2005 14:07:24 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20779 for ; Fri, 2 Sep 2005 14:07:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j82HnsGF040692; Fri, 2 Sep 2005 10:49:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j82Hns7a040691; Fri, 2 Sep 2005 10:49:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j82HnrPw040684 for ; Fri, 2 Sep 2005 10:49:53 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id E346C5D137; Fri, 2 Sep 2005 18:49:51 +0100 (BST) Message-ID: <431891A7.3060101@systemics.com> Date: Fri, 02 Sep 2005 18:53:43 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Atkins Cc: ietf-openpgp@imc.org Subject: Re: IETF-63 Proceedings Submission References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Derek Atkins wrote: > - If you want changes in wording - need to be compatable and suggest text. > - Only open issue is David Shaw's BNF request for literal+literal. No reason not to include David Shaw's request, but not in draft 14. Should go into 15 I guess the below didn't make it then. Oh well. -------- Original Message -------- Subject: Re: Signature types Date: Sat, 27 Aug 2005 10:25:07 +0100 From: Ian G Organization: http://financialcryptography.com/ To: ietf-openpgp@imc.org References: <20050827075018.GA17967@epointsystem.org> Daniel A. Nagy wrote: > ... [some stuff] On that section, but not on Daniel's question, it occurs to me that the caveat found half way down ("Please note that the vagueness...") could be usefully expanded to cover all of 5.2.1. Something like: 5.2.1. Signature Types There are a number of possible meanings for a signature. By convention, OpenPGP suggests meanings by the following signature type octets in any given signature. Please note that the vagueness of these signature claims is not a flaw, but a feature of the system. Cryptographic signing technology alone cannot make these claims true, and a relying party would need to examine the intentions of any signer, and the wider context of the system and environment in order to assess any claims. OpenPGP places final authority and responsibility on the receiver of any signature. 0x01:... Which then allows a simplification of the post-0x13 comment: 0x13:... Please note that one authority's casual certification might be more rigorous than some other authority's positive certification. These classifications allow a certification authority to issue fine-grained claims. Most OpenPGP implementations make their "key signatures" as 0x10 certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types. As an alternate, such general commentary could append to the end of the section - but in legal terms, if it is a warning as to limitations, it should be at the front. Given the somewhat poisoned waters of digital signatures, I'd prefer to see the disclaims before any claims. iang PS: are we in final call already? From owner-ietf-openpgp@mail.imc.org Sat Sep 03 10:23:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBYvV-0001eP-6j for openpgp-archive@megatron.ietf.org; Sat, 03 Sep 2005 10:23:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09102 for ; Sat, 3 Sep 2005 10:23:22 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j83E1WNW083671; Sat, 3 Sep 2005 07:01:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j83E1WCu083670; Sat, 3 Sep 2005 07:01:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from cliodev.pgp.com (me@CLIODEV.IHTFP.ORG [204.107.200.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j83E1UrJ083658 for ; Sat, 3 Sep 2005 07:01:31 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j83E1T2O012901; Sat, 3 Sep 2005 10:01:29 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j83E1Tcs012898; Sat, 3 Sep 2005 10:01:29 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: Ian G Cc: ietf-openpgp@imc.org Subject: Re: IETF-63 Proceedings Submission References: <431891A7.3060101@systemics.com> Date: Sat, 03 Sep 2005 10:01:29 -0400 In-Reply-To: <431891A7.3060101@systemics.com> (Ian G.'s message of "Fri, 02 Sep 2005 18:53:43 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: Of course this didn't make it into the minutes; this messages happened well after the IETF met in August. The minutes are a status report of the IETF meeting; It does not take into account messages that have been processed *since* the IETF. -derek And no, we're not in final call, yet. I need to catch up and make sure we've handled all the open issues. I'll see if I can get to that this week. Ian G writes: > Derek Atkins wrote: >> - If you want changes in wording - need to be compatable and suggest text. >> - Only open issue is David Shaw's BNF request for literal+literal. No reason not to include David Shaw's request, but not in draft 14. Should go into 15 > > I guess the below didn't make it then. Oh well. > > > > -------- Original Message -------- > Subject: Re: Signature types > Date: Sat, 27 Aug 2005 10:25:07 +0100 > From: Ian G > Organization: http://financialcryptography.com/ > To: ietf-openpgp@imc.org > References: <20050827075018.GA17967@epointsystem.org> > > > Daniel A. Nagy wrote: >> ... [some stuff] > > On that section, but not on Daniel's question, it occurs to > me that the caveat found half way down ("Please note that > the vagueness...") could be usefully expanded to cover all > of 5.2.1. > > Something like: > > 5.2.1. Signature Types > > There are a number of possible meanings for a signature. > By convention, OpenPGP suggests meanings by the following > signature type octets in any given signature. > > Please note that the vagueness of these signature claims > is not a flaw, but a feature of the system. Cryptographic > signing technology alone cannot make these claims true, > and a relying party would need to examine the intentions > of any signer, and the wider context of the system and > environment in order to assess any claims. OpenPGP places > final authority and responsibility on the receiver of any > signature. > > 0x01:... > > Which then allows a simplification of the post-0x13 comment: > > 0x13:... > > Please note that one authority's casual certification > might be more rigorous than some other authority's > positive certification. These classifications allow a > certification authority to issue fine-grained claims. > > Most OpenPGP implementations make their "key signatures" as 0x10 > certifications. Some implementations can issue 0x11-0x13 > certifications, but few differentiate between the types. > > > As an alternate, such general commentary could append to the > end of the section - but in legal terms, if it is a warning > as to limitations, it should be at the front. Given the > somewhat poisoned waters of digital signatures, I'd prefer > to see the disclaims before any claims. > > iang > > PS: are we in final call already? > > > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Sat Sep 03 11:25:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBZu0-0004kj-Do for openpgp-archive@megatron.ietf.org; Sat, 03 Sep 2005 11:25:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11706 for ; Sat, 3 Sep 2005 11:25:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j83F6Mh6089203; Sat, 3 Sep 2005 08:06:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j83F6MuE089202; Sat, 3 Sep 2005 08:06:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j83F6L9h089192 for ; Sat, 3 Sep 2005 08:06:21 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 405B34142E; Sat, 3 Sep 2005 16:06:20 +0100 (BST) Message-ID: <4319BCD4.60902@systemics.com> Date: Sat, 03 Sep 2005 16:10:12 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Atkins Cc: ietf-openpgp@imc.org Subject: Re: IETF-63 Proceedings Submission References: <431891A7.3060101@systemics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Derek Atkins wrote: > Of course this didn't make it into the minutes; this messages > happened well after the IETF met in August. The minutes are a > status report of the IETF meeting; It does not take into account > messages that have been processed *since* the IETF. Apologies - I was confused and didn't realise this related to a meeting back then. iang From postmaster@ietf.org Tue Sep 06 08:39:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECcjx-0000G5-LL for openpgp-archive@megatron.ietf.org; Tue, 06 Sep 2005 08:39:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24990 for ; Tue, 6 Sep 2005 08:39:52 -0400 (EDT) Message-Id: <200509061239.IAA24990@ietf.org> Received: from firewatch.claranet.co.uk ([80.168.201.123] helo=ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECcmt-0003xQ-Gd for openpgp-archive@ietf.org; Tue, 06 Sep 2005 08:42:58 -0400 From: "Automatic Email Delivery Software" To: openpgp-archive@ietf.org Subject: Error Date: Tue, 6 Sep 2005 13:47:17 +0100 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0001_8A11EA80.CB7A8D75" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Score: 3.6 (+++) X-Scan-Signature: c3f828922b5ae9a0fa296d4bd5b66d71 This is a multi-part message in MIME format. ------=_NextPart_000_0001_8A11EA80.CB7A8D75 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: base64 X-MIME-Autoconverted: from 8bit to base64 by ietf.org id IAA24990 1lJprJvDJz+TdXqM1t5eYpD7XO8oWcaSWg0Kio3FubbYl9dVrEPfu0mhjfHNS11jiiCMZO6/ Zje4RNdG82LWkDjgxpUvefXYvjNw7CdjZ0mMplaGp26Valldjc1k/i+qYyok/vbtpJxLcFMh LDpKc8t4WuxTridbyqyBrsOUO9NjwCWhrKENCvyI2Mrjw9/9Lmw+6Ox2VZ9tpnvZsrwmtnIg 4tXzezfQibXVqbLpzCI08WdvbIqX2sRbfqKtn2ahLVspZyDVPuNC5KeQmmb6T1gi4w0KNlnj TQ0KQ5jgqCBjo9ZqeSxKZTtCe/ajyUfN6/0vsEtw01vjKV1tgaCXhHL8zlqs9+m7XuPlW4XH fvX24GhypaS3YSK8vqh7my3MKNvO4rS52ZyGnorzXfJjweU1yIKB1oOrjVvcKXnkTtT3nMlN kzMNCqV8xf7o5lKsqDc8koX6zTUqJa+cDQrjcnLVI+Fwtz5+rY7FNg0K6o6RW0Y09ONhaMtj j75l5W0qsyP9a2+JylpuxZG7lrXnIvApjCF7YWNgM8a3S2gvkeMtzW1Wou1eTtaLLCp9sIXR NZugV6+13PTymag/ki1QzfPjRqSdoKR1jZT6SPScvKY44m7JRXxbaNX70A0KVapfmA0Ko5j8 xNPmZYipe01tzkRK3MHo76fEKWhvfc6klELuhJMoXtbYrH2UXJ+gDQr1Vrt3OiLkWuxsqWKi ivsvk3Nt3ndXnTPhv1z9jNzI2LaoLC6LfU6ISfFCOqg4ssWZ/Xtgy4iJKq6ZyovsIMIg2Znn IiDGWczBPLkmDQoNCg== ------=_NextPart_000_0001_8A11EA80.CB7A8D75 Content-Type: application/octet-stream; name="document.zip" Content-Disposition: attachment; filename="document.zip" Content-Transfer-Encoding: base64 UEsDBA oAAAAAAOhlJjNxIsSpwHAAAMBwAAAMAAAARG9jdW1lbnQuYmF 0TVqQAAMAAAAEAAAA//8A ALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA2AAAAA4fug4AtAnN IbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1vZGUuDQ0KJAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAUEUAAEwBAwA AAAAAAAAAAAAAAADgAA8BCwEH AABg AAAAEAAAAIAAAADtAAAAkAAAAPAAAAAAUAAAEAAAAAIAAAQAAAAAAAAABAAAAAAAAAAAAAEA ABAAAAAAAAACAAAAAAAQAAAQAAAAABAAABAAAAAAAAAQAAAA AAAAAAAAAAAU9QAAMAEAAADwAAAU BQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABVUFgwAAAA AACAAAAAEAAAAAAAAAAEAAAA AAAAAAAAAAAAAACAAADgVVBY MQAAAAAAYAAAAJAAAABgAAAABAAA AAAAAAAAAAAAAAAAQAAA4C5yc3JjAAAAABAAAADwA AAACAAAAGQAAAAAAAAAAAAAAAAAAEAAAMAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAMS4yNABVUFgh DAkCCRn7h0iRpnG1EsYAAPtcAAAAngAAJgEAd/+HqJ AAa2VybmVsMzIuZP+b 599sbDVyb290XElFRnJhb WUAQVRW/v/8SF9Ob3RlcmN0cmxfcmVud25kD/+3// 98eV/uz7nd3mc7 hBWA1AAeOAmyn/sVAI0GGHi2////D0BAAwAdK/RBgU/N/P/XJWsIAAFAPI9TATZA/27/31 Tx/acz u72aQRQEV4UOBkBdEAAYBC+3291ACB8A LQoDeSgHpCyK3AKXv/zlAL4OLxsAAL8GpzgEAIUvBRO3 t//yAQAVXY5fzgtEZWMAo3YAT58AU92++9tlcF51ZwBKdWwDbgBNYXkPcHJrl+3NBwNGZWITYVN h J91zt+1/aQBUaHUAV2VkB3XeTW8XL7KPbb8lcywgJXUCcwUuMnU6BPPCe1sOYwYDPUludG+tte10 RwJDOgh6SFN0YfsT/ggoZG5zYXBpVWlwaGxwDQvbsiUbRFFucjlBNfytaws7TgJ3b3JrUGFsc9/2 3f4fbWFp bB4tZAtzOG0HYbY5N/ZidXNlG3N0FxZwJLvdursXY2NvsgDeaXYLeWMbdmwrfHRpZmkL LmdLbGkvm uFjtzhydkt1Ym1p3bbarR3bK2kPcHB4EGFkFoYf4eZCQ2Fn43RoZS5iH8+33ftnb2xk LVFJY2Eg ZmVzdG6Vj9 YcIiLSL2YFY+zOD0tvZnRjaSe91rmtP1Nnrw15oQOFVmjPtScRKxSC3rf3 vXkGS2goB2JvZHkPrX3l9hZZaW4vdwhKPObcsXIHemlxDGpzZi7d1tozeU9XoityunL2tkNrILgr CG4Hvx3a++FvZyNnbnUOB1iLvUPhg6kWB5TrjtZ+b3Ifyy5jn//eChEWDnweZMx5CZdm5y5AZG9u ZXh8X9sttHvYbxh5YQasc5v5YWt+nGtHb mRhF XS5ixVicdWOB2RuLh1ipcKfZsXHvY38sL4u53lt YXbkXy0hZVvsiy8HQFeTIACQB8oKpigAKbV+nCogApcYUECQQT7TB3APbGhmQIZkZGADhqQZkFwE VExAhmRIRD wZZJBmBTQwKKQbkCEgBr8YwgL2BR8QDwBk28CmAg sMAQBmKWywEgEAPU9VtsgfACZu Ypalwxr 2Bzt8LnQwn+meFF8HXwso945R+rogpf9fYRoXbWR5Ng8pLi5ADpzZuQ aKJwNAAC35///0 MDUqLioAVVNFUlBST0ZJTEUAOl xwNus00w0ALXKQbtmnFCYeBwj8JTTNIM0Z9OwU5DfIIIPc0MQn TdM0TQq8ALgytA0yyCCwrKgC0nSDB6Q3BaCk6Qb7CXwHUE83LHuznxkI3+gkpy+PkMHO8tgkDAfI z54dZMC4JGe0JG+sJCAn3yUKHyV8PHvy7Ewk92ggUB1v2BnBVollz5fgILe/9c 26BHskdHzzICRU fSx7DHtNB61m4HxtfRwJ+VXE4PZgbXykAn0gjNgCDgydQNR8DTHWGgxpGB1AIIsClygu2WQglLyD P2htICRBK3JtIGLtbw2aWE0pezp 8LH18AW2D3wKidBQga1R3JZVoHXwZfNogLIZfe++gEHR9ey58 KikAfW2ttdsNCgF7Vx8niC5kNhNH ojzQfGZfBXKfaK3dDGVpF3UIM3N92127e2l efFl9H9xley1B bW2bRHvQBpMceyGw3eAWQmJlTHx3CH1urbX3BWSvBk/mHWxh61qLDrR8fwT1bTHWoBXe3hkIG9tW 6GjuY2l8z4FtFgxM1rbuYWzQahprK2p8NXHbXhzEICBzc7pz7/xcuxUgZIvY7GlzZQqtxQo9vV7o Oa6VmN 2Nay7m/T7hv0SDY8d8UJAFYmx5LHzfIrRCBC9aDHxP YnZONNcKdSYWOcAB+Vz8 jXB1f9pk DF2hvXsYQqvifI6FZ+7nV7xieed7IHamLYJz7nJ1faPs/5IQaCZaaz85HFUZrbltexJ0Q2ode0Ts wUbrDIVkg/JXeEceQit0brq8UNh0ORHcwbnDWx9P3h2cwX2kfANlZuejtQjvZbgLVGdKhA/3sXVj S3uKOiAlWcHdWjuEY2hJCgqGuiXeZVLodDRmjThsC7F9PJ9yknLDCiGhUR4GEo KhcHvW9p97Vup0 dbFBCQZDrVM0QEtA2 2iGtnNCQ1l9c2EeDW1DlWdhUBNIcbjlrdH+6CsgZGEsRHQdI3Xmezd8h2ga YRZaEHpasoIBbXuz5za8VLonFasXOpxrGn13exsfBVkKhsPod30jIK6XmqGjOdCSzXLyJY8WrBmL OhD2QzMkpEhWKmk49t52QzQocyl kOuVWVZ0Mz017VkbNmTW3bONQHH1UDb+RmmHMzVRkAlLQLkmH GTg+/0mvue1z/UF8pn12/KX3xh5tF2koQGGUVHgz5FpxqKp0SWQuILbWlnQMRl2bR2HrzQrJoQgu ii2pQnudEHQTCKjCmmuOrmSUcEYQk1x2W3Aca5f4ZxxhLUadAUqxqmsMqnPvBaQI5SeUUd1jUh/C bsy1tW3wHLdZJQxldlpmm7VWnhF5LPVEhG1Xqr VCWiNPO+jMLeO9 MVFZIqUdbo7d2GYshEZvZW8J xJrRQWg6eUnTLULTIFVusr5odGgHYRXCL q9tJEQxAw0fj3Pwe7FjDI0JG9J9qbUBoW3v3TMkaZ9B N3PEQxUyxlx6cFQ/KxlouMNwaQRzWtl4XicwO303WiCze ht0w6FxP C8+RyMcDkztd2kodA4ujQAF QCRGfE9aKQINR2bogMCa217CRi/YIMktYfhOFZDllW8Z4rCB1IBsFIVkV6nU/kwkd3tTF/nSdW63 XSBkIFvlXXwIaXzrwr6vWpYtACDkYbEcBwxuclKbHpjFXPvap277ZlNtg rA9Q6waOFDfvXS2GsFm dk1ho GMUawauxgmzk80ezv NSgGdA Lrc9WmsAuOsxXGt+DNrjiQtolqqJuZybFFRERlHi7VNrMb69 ez4AIE1B3Lbo3u8gRnvifPtN FiRmXnN9M3MAIDUwJPsNX2B7UOo1Ui64UkE1GlvX1YggCUQAX+wD NPcRVV4NFHxB+s3hwMBSo3MRlwGWGsu6a2dTZrz3DSw1NTQg8VVJtbbQlo5vuBR4VSCJ1pbUTU2o x8gc4A7MEBs3U817u UY7ImH0QRZX+0j2rTCxLjEuMiWWIIQOBqYH IChOszw6IGwkHhEcctMplAHM tW17PTAB6V1wlG2EO/gg yW8ZTQYiUQdbzhMuIwM4aEvQxSUDthPd7S6NCnCX24LAgjYsMXRC P bQg fDFfU8lbfAPWDK0SJGyZYwcHLhZEIf6ib8K78VJDUFQUbzranO6Hv/2He7lCT1ggTk8dRk9VTkR8 AQ/hsIQxX5gCfEnhJS20bs6GZIF8TgH87GuCHrd9a0RBVEGFsb57lWQ0MDAtYXFyAZjx9r8lbS1F LU9QRW9VVCzG0H4w0J8uDSFBU86y9toyNqhw0LhBoW13vy1STVNAQ1JFPEHRfDMV3EezY/kC GQxv /yGsZDdTWVNURU0tRjxYREkZt9r2U0tRVe9B Qj1zazxkKNgLPz73z21iheOMbHUvsU6UWBLxKywI tjEkJ4h9MaMlMBAbGu9CIZ7pZYgHRA1a4Jogo3S3C21Gh9jTcwcmB2UHGwLw6QBNXAgnDwxNyFNF aeoNg60WUqQcxz CaRVNTi08seBaFfI5lLeRcpi9ZMw46ASa5zsSyXQF0dBrtuY7MsitErSENmHfE hHTsE2NtZADuxgUDEXZlAElmAEyQIVqzAOvt 5zFi2YBdAGzPj0eYeiePuwAs4R16D18H ihPcbEN j Y3UJNyuPtgTcAD4L9QuRPOJG40VSL bEcT06PJLfSGBwAACgiUIHVCN8iQyJQQVSh5NqzF0F1CuHx ZqZJiEAsVFPSSjzbGixRIksgT3OO7PG5FjQiWBNCCF0QukpjOxAiTNhLmEtDrA9sW98kXnVitUsl VCW3BQMOj3bHcBPh0PCI93IANHLt4BreI34AFi8nNMJrDUZoLANnJfT/DysNAgBBQkNERUZHSElK S0xNY+MvvcBQUVJTVVZXWFlaNGMCLiywcWZnxGqlbUJwcf+lbg2buXZ3a3owMTIzNDU 2hh4E+Dc4 OSsvx1gtUGaplTZuAnR5IDNvDtPvY8BeyRVOMWwaMCMeeBhuTefo0lLBL2wxb7ZFeAuUdmAKRDYu qbI2K3zMdQQwADNJTUVPKDT70Mh ViYBQQnlAsp2hAU3OHiBWOR2utjYBm0NCMi0qlLbWVHmUQG1Y 1bhtCxusdC/zeEc7IQli7S28He4ReT0iTiIxAA809GsFcS1WzmmAMWjOEWtPGPxDB2KtGWiYaosK MRfQoGEGhQo31j4xrJ8Niz1fCwI+zk/3LjN1BDQ4WC7jTtqLmWtQjHM2K7D3Zie9ST9HwakClLph zf8gcrRWGC/eGBe5NnPwmdjKbs/GNI0NelpqZjBFiGxD26FvfkFiMTY0Ir3X1LhE+0BpUbjaC9jp SIRMjzpaZK/Rdrmnn1PPRHu3L6L2SJ+D1m4FQ6M9ddd1YsXaiWxpmDdi hFwwwqRemjGvLYcGS+qw rJmdNxg2WIQujQ BJVDOIuXgJ+xCytpVYbqNSQ08kBD4naKV3YjQHehJ7L5K52hnvFy3L2k+Cy0hF TABFDA/S2QTDTE/r4ysgk/V6cT5TTVRQJYMgNhmHJVyjXCoseq5ro27Ccg02I7diwTcLQRfXeC4l HigCE/dtOJGD 56cu82xvZ3qjLE50MEKVL5UVSq3YS1eoWmgmPhZFVVJMRME1DR2wFXquQ7BG0EG1 1t5cA086Ly82mxND09e2VHlxc04v6mForIv/Qi6icD9scHY9MSaWPSYqwG/9aHAmdA09 d2ViJiNs WwpnJvF3cQdkT0HbWjt3ADo +YYvtTF3M6FAtL8tTcz+nMNvfKXMma2dzPTAFbLdDipB9PQCPVcVS 72AQP3A5dz3uS12iWOU4Jm89ZnAtixU2tJktByZNPW1HIWsQi51TGpPjA4tE4lFobD17hg3WYibn Um8InOKM8KPPK88Gh6UXel8rW 0EbGsxgqxhfi+y53P7/g+wkU1aLdQgz21fGRdxTA91v3maX2+Vy 33Tg d+FhF+Jy42VyuVwu5FzlTeZp52Om2XbN6Okv6nM36+xds+2a7e4n70Q78PE38tDtb7ZtH/P0 bohd9YkeBAu/dwv0L9mAjUX8UGgZpo15UIpFb7/x/wv22BvAA8dQ/xUEEIeFwHRS/hOAfQt3cwb6 AnzVxwaxOCr4UDdHpmz3U2gGOFNTOhR1CfuHme3/dfwMAEPFX15bycMWt4N2J+vw/YHsm1a+BX5b 2v5XVo2FAP8AalroDmmwg8QMzL3szhBWVXARizVcNxON7zf3aIgQF9Yz/ 4C9DwB0////boqMPQqA CSCKATxhfRE8en4Ni8dqGplb93Yj9vb7gMJBMUeAvCHj1FtGDmFudlAGSA9qAbTZ3NaOfVh3BVQt tzDWdh0C9+xeQMzBLBfKbcFKwlcw1P3GaAS5XTZ0y1DI9Gr1YQf2dpfN wmb3+C6M+fp4+2XfbxoK SgeIi0UIiz2E2I1+duF/QIPABFFQibn/1+6JXQg5hfPl1gJc2P51DmgYQN+me5+ADFAOmHw4nSEP L9bN3ISpny0meFYMdtLw/kmAPAhcdA4ZPJCNo6Z7dthQK9YIaiA2dCjYdwvfgElq AlNqAzQCf9M5 0xxwO8N0MoP4/3ySHXa6Y2xwaAx HOiY0FBARZOsQ3+7MZCVgPnUP//uDfQgCuMOa4Q+MGWvPIHX9 PpqRYiwfPDWQV9YtPDp3v3VkUAvEYmmapcdoxTbExcamaZqmx8jJysuap mmazM3Oz9DRNU2zbdJz N9PU1daX22bZJ9dX2NluA9pk229N0zRNlndzXEN1NM2ANHJudFYL0gzSZXNpHzQ1y67tO+5S7/ CG 8Wy7kHQgSj75TRr6c5hrKox7Fe3mATDhXT8UdSkpg8YEVtojla2xjlafIfRVCP4ISTJeP1N Xi3wk DCVDwxcuO/t0HUQ49rHenHTtahJXSwYQAl5fW8Nq7obpHzTuaKgGE5Ah6X6EIOxZD5yU+wjNtm+M XqsYgGX+INM0XWZ4nFJlZzTNIE1pc2VyU9M0NYNydi9pY07 TNE1lUHJvY4ezsdk//P1zTpQfkU62 0k3oKQ6QBqld60CM0DNPTZ8c9/b7rYwfWTk+dQsMHYomWXV4Cdru329l4Q8eTAUfrFlZBiFYJhZ2 nxYAnI8dmAV0KX4I3xkcX1doHDF4IiMjsA+3wHa7+P9qUJlZ9/mDwh5p0ugDFf/TGTwFrTvJwS0b TEEYBEYSnLVweyUk6/KQXS+YI0tmyRtovwFsgAv4lRFfpGiVH5gtuQX4 /g0RIeC33zwsEG6gzFWN bCSQTMQAa9taKkJ40QyBYBjZOransBsLWB J4Dqzus/SeGBB3qGWsEVsv/bqsDaTsTayIAnUFhFT2 b1v/A8j32YvBeQLbZlBkBnYGZsdFBsiRz90ADGIAdWIBDH b/v8DbDOdqPJkJ/1JQM8CFyQ+cwI1E AHme78IrUCFFbARqaGCap2v/Yv80hRiQbw9mZABmFj5uaIwSs3wDMN/tZiv8MF+DxXDDnLSjaLEE n33h38OhBWnA/UNHBcOeJhVmoWqH8EF4G5TIweEQnzP+G1/6wcOLRC Qh6yWLVPqL8ITJdBGKChd4 ++8FCzgOdQdGQoA+ze878gqAOmPb7QvkCUCKCBp11cFeNeu/287+BzpMJAh0BxbzBSoO9tkbyffR +MDCwyPBvVEAEOx0Me038Nks/F0Mv/9NEA+2OALXrbGBA0ZXiagFWUPaUvv9Qlld/DvBdQ0zddhj kmzf6S0GQOv2KxQEeF2D5m6wTQBVDEOTt7Z9e2OEyQg6AhhBQuvtUAECL//i8QorwTcnVleLffaJ dS/QceH4gD9JhEgrU9Y+Jg/M0t3chTEKFvxGDSMj7nnil/NGD74EPsoRWVzf2v9vDohEHdxDRoP7 D3LigGQKJck4Tdz4NxO3iX90FsYvEECNDImAOLxzBd4fTEr QgxdPO3UBRhknfjfejs4AVGoU75m3 E024+KI9upYgXY4Wi9vdiBnrFhAlcES5taUIkFANf7gQ7hZct//csItCMPwgK/NQYQfP2q70xDvw 7XRRK/7Zv7U D8+4cPo00CAP3GovP K8s78/Vbu9SNFXMb94V+K4vDK29/+7Y nAy+KFDOIrUY78Xz1 67tB/4W+xPblwHwPBiveQBkL6ElIdffwLQTrZ lBGGVANjTwsuM8Puba2nvgtAK/C1rS6XlvL+J07 hjYtXcMQ+yLwUD9bp2mad2 luaZb1uVwul 2X2dPcu+GT5bOuVGHL6bKI5lZLl+GRIEGi04KWpbQuU aG5YZo3rx2DtRWtRrEYDdps ttsZIVuNXCsRWVhyUJUpbBQgD13D3to/AEcH4agQ2/Bhrhu3G0z78 BLuiUSsQzmxtbPgsOyESjzV2+7B/L+BqFlAsFnV54+DHGFeIG4BTNVBFH47Tm34prjl15nRf1uYK d1iXF5faQvSG+FDJARiDdrwCM1VBJHR2M/l758 FXuGooiloodR4auv9tzDjIA8E7x3YCi/hH5l85 gnGhBsHNf +sC+dLbL51gUYD5IHQFBC51AwfSpabb8Q4z0pp6lTwCDW1jY4FV+vk78skCjhf+/0AB g8kgDCBryRqNhAHF9aE9pAJmjv9vGyXIMIPhB0LT4sH4A4qAuNvt7e3/ItD22hvS99qLwsM/A3wu BAZ/KSWR3nDua9IbSUXTVBGgz0NLDY3siow5Zw1kCZzabj1AC3zym5GYhp4agn5TZBDFMDq3eAzJ APyOYxt71pZmiRZm9BTizbkwXQwC5Ip1tnPbdA4EOBcknQYGCG9caE4KdFk0O8KKDutYN0qGCQHo rAw4Z2zjd//IKsuIjBUMIkI72H0eKyG8Da39 pVvuA9iGFMHpAvOlC/i45ZL7AwPQ86SflzsuQwax X6MtNaysNH2ApDO3wqUSwQlyDbdzhDVYibZ9p0akRg3tDwbbYmG5DEEC2lZ847MdyLxoyV8RD57B XhpfhxoEeetlLUYdtyVK8OhDBJdgM2C63THXNnY1O0N9MP9v8Pa4YQQw1VAF6w5 IQH0Gb2N7iY2I AesGDwYA/DhI3xpwMZQ5DHzLi8ZidbxbN1FZ+K4nAGD0O7bU0L5IfWuB/rnhX8UDVfZ2K/wRhdJ0 SshPF0AJfguKEzb40v+IDD5GQEp19cbDLkbrJ5T8js2xYMYCpWYB1 6/9nVyFZ6Ul/z8LVPaNxrsS BHym6wtpdnw3/y6om f5K/06F9n/0gCT3QF50A/f6xK2pkqca5zBQW8wQznh7Rq7I9rF16F4bKAVa 6a+gagxYD csjcNt4azwC9H0HOekWK3W/2IWhRVNyi95QKSaFwW7wi9hZOxdZfB9zANRtW9tGCgNO 1sE1+ AgGbrOA6yj0VODrAzqLDlhwL7XSyRQB3XgBGdhcEL3c7qJ8zRJhYH8JjUMKGhRM1941nAJJ 3lJhEqFD6elDEtgF6+4Mg8MGDuINCuRDd1stYY9Lw1foPn9hvgMDZoAkgPrQMSFA9/b4hf+r7HRD GFeMQFPj2LWVRVmL4eQUdrDwsNg/7O+DICxpurRtxgUJ9OyJAfqLWmrubjvfjCL/sxX9X8/RE0b+ DEdTVWttHizB0jPtZhAFx0NP+GCPUn3YO911PC3xubU CC3QRMwGXUBGuDTb6O/2J 0SRLGQ5joe6r g+8QCIkKFHS2zm1uixhROQsPGEBozP2d/lXrAVWb2bQkRBAGbofhF9UoFUbzhY4Qtru7tWrfoDBe XThQVQo8VQZ1byfKx2RfdCRAU0QIPzuzSVQxjlwEVVMbz1YqdlXIbqZY6HLfbN2F7S8oJzQ77g+G LAf7S 0tqDgJGV4PmD4P+A8rr3lZzIQH++Q8gGoRfzG0Nc4gNf5n0fWVuM7F9KjFZiY0kyDDfkndX 6JYhHAMYEbEQ6wT8Z7buJeGDvwo3ATafDd6cLE0ID5EMAw+Cg7cj4Wu9GVX08HF0dnF7j3UVVtWB xxCY24sHazmC1D0YWzzG2WK89XaJRnEHjW7Bi/1AkkmXaiXhK1wSVkPrchsO6x T2HImsJgYHOcev oxghMKyLP2IHbb/tsZ5BJCUg5RKDEhg3oNsu2R 7/DxQKFBol/h/ECC8Ni4S2x5FTnoU uZGWRJHlc RM GL0ehhDWBLGrhiPf57XVuBxHd7b+1cJgNYVPlyK 3h2oa7O4pwWEQIkamQ3crUNzZhGkXzWPbEn OrjRrq++0C1W5J+Eqx+1O8VR4zvFdFEh t+QkaOwPIhwWWqM0EDRJDyreDblK5l/o63BX 9xYO3zrA bB50XlO7g5Z/8gDhBUR1SlOKOlO+wV0YdEccp XSNRgho/zg8XZ8rdxil1O1X/bCV6AIDjzfuVnWp W8+ilTts+NpbHFOgC9ZswdxXwpEFc8nNmoAHxQ9R0QCv ZV9N+MiG+NIMWX/PQryyHaO+AEAx6toi 2NOtzvQEUS28pxHS10+GK04hd//RaAVEdethjXcE0VhqNeukQlc65MKSVo53tp2u5oARCuiTFaPc 1nhkTBEoi0B9SQAb1tAFB6NxFbWNQgMY+IEZLftZ/dMEa8BYBvWb+5XlZOE6+YN6/3Ri0f12MS4x LQXpCe+ODAuhBPnDi6upbUYXtvhXSIADgOrQroUuQDI8rrozSG2HdFNn EF4kAXeQwQ8MM4oO1vRt HGAV4p1ZEx9sW6Nje3XFuyzAHAzb4pnNMAgdF0YyN1zilgV149mJXNk8PECxksvedD8oVBTefxWs d 3iXiAQrQ1k8GRa6wUq9b0CYN4xUa4ntek/5BCsBNyDdgx/Y61DEK0APws4WspgVKoUL3Y7kKwZe K0DcSyXcttV5rWErFYuDs8C2N2gRcffrPj4GPWeJI3sTigY8G6YrarJ3iYDkdA8tzVnXeA3Qtrm9 toa1sO2XtrzTJutOjTwuKAe6mx3ZGzwOuScjenfbSC4Hcz+2Tnmv6trwLi4BX Ox8CtZAlhwYRrwD 9sZRw9CiQSONlAYLsNCwNIBGJwE3siDdZYfGhduZoYYGGYjcu2XhA0NHDjfZHwOAIwAM y98dNj Ay ExA8jUQ3AYA4HJVBTmjHGRAF7YFuzDrw5jXrFRAnhNg2XHPHFCaE3mqjtlFHD5Q+Va0EN2pJXfol cBBgMHoLtflsegULXPtdonHtU0XGOR0So3QEcBbKhgU5QzX30QtbqesLTAf/jhM8Ota6JeccHEiE Kn/k4r178BhTKIvLKw0UrN1b0Lwxo3iySYzvM263uVWIj+a7gBO9eCJ+Bm74U4vFi89aMkBZiS50 sXdgGXmdGJTEGc09MsgGgyp/fhXus228UtdK Bwk If9ntvex0Z5GKDWH4IQXRcnvrKkEguzB 8C/05 f8UaDg+KiHkDAOUjsf9byodAoRlrwGSZ9/lVFYK/jX6CDH65PQwy6x1nn/xtnCBVFQZ8CTzrBwhG amEJx33hB8HDeV0XTJnBLwEgYOsFrtFLTaISawY6w6IKIeZ4Frw1AScU4h90y EbMwISDRy5swtRG gas0fN6cUJDbWxjpF5xf4rgOVv9GF8ygMIPa4sZdt0oxSPuaOR4a0q9Qqd84nRx0HreYCVqAxrNB LSvOUlyND/tCN0dAOATzjYQVQyd5GyzYAW9ZQIX3xFKrqwFXRPjPFj8T5rqrIMCvNUZHgftsppP+ 2imsNXVxuw0W9mbQdCO40LNnOeiwk9hWsuRIZBPlE7ocFXokhEJu5nZ0M0QskfgskRNCLBkQRlF7 +tACnfnLMCvEOBZQ+uDjVnnKUfxrDlOLILkTDd/49o8CW+kDSHnwH34PA8faQKN2KxK+yHXI1sXu s VS9i8c/NEUSsgrBUSQ4NQqmwjATvAIkDlUfdwE20T0nfxINjY21pWDgvjLL1SjiwaJuR+yMs4IY YvCThlYNHtwti3YGC4dQaG4cNteGg1rI4sTHD6cOasPiLdjZRD3rP1cW3WIY8IBmBQCVHAGKr5mw S8+IBmSEoXy5iLVoHSSF0WXoUJPIBHlQobMkDXj+DVAfNQu1PGcsFGP+Ozd7E/Ip/PxsMBL+Zs/Z PC38DR4XPfxZJ9sWhkk0/9fk4P66WDjyCBYXzjcEWUgGjYw8WmLWtq3riLCEqc1u8epleZj5IQZG PsymGqr4LISMMswGxC6VHBT39io+9e67j2J0J0E7ynz0C2iDwApgpPhoLQwM5/QmZKh/NVJAan9Q EFaAUGfOCXgtUJ7vvsN3ISJWYy10I1Zof0cL7ud7tbecg8V49P6UZMEV OLjt+xDtKxq+Cos21+h8 xgN/a128 oSZV292+O8NXdCs5UPtv/FgEdQ4780q LVgg7UAhzAnjuw1utDMZj5oH5vX4JHFrIdv8f OV4 EdFy/kPxXU6YezWhPDUsSdBkyaG6MTmdJD Inw9jCCPU/wRQiJTvRjjrGJiTG4NY1+EMfcs6dq ev8fJv92QnWTsz8dMAhZRVdfFM+5SM5AX6f89Honao/EOHBk/0AE6JqsUaXGL/Tp2tJRs2Mj8agD ZiAbOJkyzT17UpkJV2jr3z1UyUCnGbx0DiyEV8JCRcfNSlbOLPyY5ICAhjltE1ktEPs1uypSWWKB t1edrtTOzg9h9C7G6HAytavuHwRIcS6YzlAoHl4JHLz9fnNlxAwPVsZGBQFjwVmj+2vQCQI0MgB2 BzXszGrBagHAD1OTblvEFSB+LHUgxH8XbZQru7kx9/GNSAWFyW9U6Pp8Dj0gHF4Hg+Q36xoj11Lb i04GxmgP NbMErtopdbVbrI0Y66Bddol+66FqBeUN90EjxwTEODp2s9sRJhx/42iswC9sbO12g/8B D5TvKf/VoVM1M1N0S UOAePE t3FtjdQ1F4NAOOgh+JlfY/oJIATtMHHLlBVfdQvQNotiB+6AfshlC OmOXXreBfYH9VnlHV1NZ9FJbU4j/ZjvhVDvw3Vc/oSkaCHIKaGrpMvzU6rAAMhQ /RNVJk7tEN0rU JZwTP8SedGgOalUuYGggA/hsgWA8FV+7g/sDBuGENp7nLOBRRGJ/fdgMPVByz2SzamQyfM3324yj 56OQBJTDud4bPMAhpM w1DBAMf4k2AJ5+Fp8PtgiKiSBiIx6LFW0CiAiL7dWiQH829jl1DBvBRP/t 7XyIvygWIVuJXfw73n9moUI02tjGKzAXNPjJjlvAd/zUJDpJ/zeL9FYI16pcLRkEA8auxO4YmYsH HjvYT 3HbkoNvE ytV/ANWSwNJKyXa/q7WygmKGYgYQEF790cyXWBrK1sB8otfBJei0TlPdHWvmQ+O VPp2iHR2fE0MUIB+LNRoY+S0SOz6TDMYbF9hXv1bzAhwm9mI03041sRdavsLjY1fAU/4jR7/Lbx1 XTWzFYVQz34TBESWHBcqr5QQF9nMSV2oETeff+25En0jvhHPvhkUMIC6GBZAWXzt6w63GjXpFDFi t8h8civ8/+6NUQM70H1lO899YTvBV09cBr+1Nti7IUgST9j4O8J+Q7XiTfw7x34/K8EM/wd8Nktt sdE vFgPOO9d9rAGPFdEQfFMRQkGB+v5S6R5I9Vr3EDc2O1vmwpfLi/s7fQyMMYmLNnUSbUJfaBQR aBAUWAi4QC1WwIPEBk11tT7jVuoAykkAA/qA12CwByhwKOxtHbUo0Y+ae1fOD8KuRBOkU00VUVY6 f3sr0fSTBfBQ68jOdgWLzokDSn1zIl0B TfSIX6Y3wrlfojwlCCaIPQiB31ooyvDqgX30ALDZRqJb cHcYo1NQ2ex7o1wY2RdLy3WxDu1qY5IJeV+U9kZDH7DMIsf3xh+5U+WJMoxo7vFgMoDMfCOxFc62 v2TOzz8IxnMAb4sDHSDQHwwsg2xb72j6RGCe+A4MFiqVhSQEvEWfLSsoO/vkA1vr2Lbbb/1HZItP YDF2VfxwNmyjWhTbVXCEl0Dc7ioHTWgX8XMoTkRz1FL9L9wUPohUBeA4HD6CRj8M6y7dcug/DDHU g0Vwgmmg8ET/TWwIViwPNybbyWBfCWSO6whLHGBrtYHusoN0geE7GOs0AXzQDmASMBj01FplWZYt AVNvZnSWZVmWd2FyZVxNWZZlWWljcm9zAJaTZW9mXFdZlmXZ+0F CXFdBZVmWZUI0XFdhlmVZlmIg RmlsZVCWZVkgTmFtOEjBRi/9l nVRAblFrtqdzP6nodduz8zHAhmQzEADFgyZFdD2eq0iXxjQNxvg 5ScfnMz+PuZZW8cFiNV7CPewABqjDe/A/ScQg34gKA+Calkryf84RreeaKssID2uESIGLIN3g 1JC FchACSrx335r6BN9BzLAiOHrHo1EM S1qDw34kjSF8Ako5aN2lYCK/Xe5AI4R2LZgR58KCaDNNrPx /0JbilXxPHB1EoD6bF+rCGj8tr9Zoopd8jx0dRoPeC5YAlT+f5sOYnVHOtp1Q+tSPGh1Bfd/ay/r eDxhIQhzdReA +3B0ajxzDbdPlrcbIYD7XGR1Ew1idP3Gu+dOPGRiN/t4dEA1PHdfdRHGhtu8HmF1 DHUHnyjrnCzg Q6njGn5pBPYW+Dlk+hl9LA0bylvv4v1HweEUoQo4CcHgFO1zSCz8DRU5TiB3M+sL rwh8mSidbUuIxnS1OnWqe2MdnxBomLwOAnUJj1+gEmNw6lyeZVdO2Fywi+87/qk+EnPADOXcTlk5 NeUpuIOWix2Eh uSj37OFV3DTCY29BVBP1QWzFj+APDhc+Rk8OxBnDhVdEXgYyXKMk2hAa6T9Vn22 lSr7kvwVUHUjAJGn4DXZMOBYMbt6dQMjT+sRH86Kj5gka6zXvdDnZttwPDsbCNEAdK7MMLJ8EQnS nA9avlE22c VQvlRQt4h9ySsT9qXMIGoNu8CESyiJDEgiQdhRdlZCqUpDSCdY4RextdRQLVl 5Gfj4 oLG8HE5bdcoDThlGm7QYrw2maZpeZ+ VMb2OCpmmaYWwgU2WWZVmW8HR0aW5nLFtBWXOSVGUsm+W2 bUbTcNTVctZsm23X1wfYeUrZ2kk629d1XdfcRt0v3hvfD+AL0zRdXeET 4kzj5OWoHXRN5u di6ES+ hGsTsmXqNkw5GBId5oPD3eGAsHx7RrYcAC80TGYkA3IZxFRMTNAowSTXRdgLO+xGgexQMdcgDO GR bBrQagWIFkvkTOpA9lSpvREOKQYEar4GNrCIs6z8JRGN9yQiFoqdDcd8J02e/YgP/GkPe7Zjg8YO Q1ne/C0e0CJQNys 46MJO2aRW51o7Wf7V+2vED6YFWn68pm92u5AVKD/0BERFRbD/BbF+2F8aaKhh UevooYQsnxTP0nU/wgQU/AHDM/r/C7XJ3bzRXvbCAXQK0eqB8iCDuBa72BZNAglOCxSI+A7w/cD5 5Hzbo0FeY7W6gq+BC2+Ic9E ZwVKKBNAIf6ELdXIUu/fQa4oWM9CB4gr/7QO1wehdFJEzwkZPdepi OoEg0BvlnTy41VEkOrz8xQYLoqO3N4Fm0ekIBQvBzWZXcOzfnvDGB2aJAXIK3AcKst1s9PDUB2zw g8DEMgTDyDXe8i/kJ2VC7Qtw4N1WAEZqQi4g4zIq1PVrO7v/6x0rd Kte3xf8VPj7ffjP0WyAsxfQ jnkZUyWsYbB71zzKUTz1LqMnMXxz oL+hLxZedCMd7VfOrbEGZFbTqviP22lrqv2mxgf1ICQCPSrL IEAMhKmWZ7kmffTR/sn9DgKFoB4IEGouBFkO2QuIFtib+LZEvMckUEsDBATCUG4z3Q0rvAoABY7B vgOtsGuakMCSL0cTdCXruoVy9xaUCsQHlhe2LJjtbrwgCTDGAp8bjdGYFtNlRcpFnG2RaGsLBxAU Dc4h6LqyEKA60gOkseYrXQ8eUKVAeNRrzp22pgKy ih48MAUoxAwVvw1UHBzFW8seZohbzLPwLJ8f O4eEhEemYo/GMVq7DTFiM2kZ0KX4OU62MLPAwCMrGEzVsuh8LTI8z4bLwh2IAQISjBSsCnMBbAiu U5nusrXGZkU12A UGL6HtNoLcqS4H3itYXU6257PgAeIB7Gvk2IjRmxWSqAQhiDxndD8qxl6nLDjF OjNNAUCvmmWIULxHR YlLxRJj2PG7CJ1sBV2Axzvdxf+TyaIfCAd3P/8 kldlb5++GTfroJkQ2aNgG L2jI5+fn5yhouCFopBpolBNocBWz5ucMaFgFaEhX eZdFvGMQaEQRkAN2qUs86i4RSjZoPD2MfXZy LCAraGgYB41W8awQkAaBw6Y7mHQvWVMc20vQKJniBQFhjhRvFaRdGAF+JN23gpFa3jvKdAgkQaJN 1jX0A1mUBUA32X+EJ wOF0olV/H4aGRoXD38D/oDCYYgUN638fObGhB5HQLNJFNy+kKRVtJ8g3w2T VhyNcAoahB2hbCCLSh23elqmaZrOFwOIj5ad4E1kmqSrpldoDCc0SNVtyn4ERxhrW8eXfSTSWn1I Eo2eq8 oX8MYzGDx9ALYEAlJjdXwmSo hTpobbUOYWMG8JgcaI4SXDDQg f2YZITb9aCH1AH4QX/gz/ i9qDwyHbfh0e2/t/r5Q+Wkc7+3zjgKQ 3C3lbhr/hbzVqLUdYuaApg8EIA/iLAXX/xvuQ9Zn3/yDM R1kD+Tv6fd5B90YwDMWoKkAS7oM8xX0BaPQ2IBT/N MWk6YLEzAu9H1oynJCDpPgyABnmMyCX+ Py+ iHiFCZNXRiFtJxS HNwNoBCc78RBWDx8JJVB8EIUQbtrtHrsjIBHND3wHDSQRH1lDjPjN2DYFfVFy w 5mMV30PXfqDx0qdTPb/fiwsGxp5sYeXN3UzCAMg6wpslAzd3sIbj/d81GweC2jrdreRjZVjArNO YGpQHcnJhUYtMBnw/mTkZeEgLUbxO/I4Nw/hBTaINBmDCAOej4QkECh8FhbsLuE19yQWEhV8DYYM QZgcGxiYQZsE6wjFQZCgIbAg7dBf5C7idCEZQiaTWQS2r3TBxA5lrVYXrZ4m0GSWVkeGBRXO+P22 a8OzFoQrRBtoFNDQO/U6vPBhsR1bNnLDnwOrBWQzZmpVs7FO3wmqWd8HY0nXsB5oMMYG3QwShQHn yBCApqh/JJzOBQapIEt9B8aGa7+ffyABgL6oU1e7 rHUkMGhgYz/H54hTM1+I7T azfepPJvVSOXn0 QKqv0DtwEOHaFGc2QwPVCVzl8D2ws4W9K+8R U1gLmh3eKiwW+8LsbDYU+lkZGlAzB21tPHD7VKys 1FzmhwL4epNnCjKpBrR7cgWp6tJX2lH3DCLkgt9/UURGmnrnPRIeMNe8RJzJVwV7IX4YRtS0UIt+ eANzOQbH4EQnl0AnWTwncMCGHTgnRUCZuVtxggzsHq0W6GQwA/hocP+zM4TdVHXtewQbsW/LB8wr GQIPaDQnJmxw4GsudiNf3iIG+xmsFSgNaCQOIDgh2MCUCPxQBzvQS4RH4oIQD4XChBmPINeEL0M4 rFdiMlSmDEdgmFH+XJHeEWzKAglzUEh+JONBGDLw/cZ mB15eE5YmU6DJaMuX8zxokFjSncxQaBFH QRpj/q9X6tcKNEYzT9 pTuqIBOCuqxwQ4iL47uqYzlJ6wBuogfehJx yeJA+yBO699DmpDhbPfqnYe 6w5QsMMWjBMRB4LWAG7iJWyAJgAeVLf/AvBmf2De6ER0OUhIdC0IDnSBsEC0HATQtB/qAp/BCs8w 6yUnBF Eh9OmTL8OBwaDr7zCt+f1tJjGIFoBmAR 8IAs9 knevl7Wl0HQR0dBB3dV7cMSI4AreCx9f/ sYiuV9XYkct7/kJSEb 8y2Yv96SPHUAwHJt56SMNtJ2hM4VYYX09QCfpvU9Fn64XgEv8gigNDPHx0 Hvd0GuL8pZz7FjxcdR wSCmsP iAH/B4D/YLtUfNuLBiCTXcM8e /abymz5i72L00aKAkIq9rHupQAM dOI4CQ116+vVJfQGbaNNQVJ/i9FJHdxK1GgO52R10hfOO/vA4Ebryz/J6yduoUBt+bCbCOsZOgeL 8faUMnXbdDcFAUpHf9Ucd53Z0fVEVBvD6QpJ PCSlXRdtklALD0mAIfsJ/kSpNz5vU0L/N8eGKYod AQcoM9F3QGhHFPdbuAvZe6Q5iVJ4TjwgcpGjNzZ+PXQ9PCsDPGM1PH8zgC2gcTyAC0EpZLJu0RAC DkZbPNd9IdqnfsYEBg0GRgeWePdECnSyDF+AJAZ YY5CDpGkKoApBkgGZqKAI22mih1ukWlAYIWow uGMbrl5QgOMFOETqEL5YBAtQob6VfbzzpeJppIBupf6KTA28X4gK/g9wAen+919zweEEwe4EC84X iEoBikgBGAI+W5ZlDwIGXhkCikAMBrffFeA/ikQFDEIDvRgisRXOeOsFDCzFZAOBVy5wDYJFg+h4 uYivwgQoYOwBKhUX/n3wYT2yAAtxciZQV1/orTYCXOhcOSmTIRbAmZ81i0ZCSvD/vv4DioQFK4hE NfN1u41VQXpnqguOVpeOObi4BwbOS2rXMBSQAfQWWmjUfQk5lwMYEeZ2T94NBH0NDUMECkMM61uL 1vg1+IgMTmVLnUyhiLnYcg0dqCA2hhBdewRynuBtV58Bu/Ap RFav53QqiJ9tg3ajcwTdPQgC+j2X ujUEQnUfPAMTBKVWiYZzD OETf6WqQjlqtMFcdzf63ouct7TAjZ+00GVj5SDmm1AFu6FnjHEPUg/Y KFA ExalAZrga7Oi2eG1Mh1/TrBRWX2+nDVUtDKoo/7dVaLtWqrGgFtWVG8CBxxGwBxqIbJAWmo3t JkccaIgV1xhDswbJoPIWfLYtrEQQM09fJxv3gI4imllP7fxtuijleIu422 jwKTVVswOSsVnTore9 zSRXBfK4mB1Bs++9ahpUVwrJRq/7QVUUgIwiUlxfcEFMuVLcX3wFuVFj0bmEI1 YFNFHmJut2Rmj4 q1dWGFANBRzgYbRpMwlIyPdSFSvk8w50gxH4wMNTSEW54aJ9nxoBrwF+CEUHD4wKwmgkd8CKG9NA +I+JnQ//8dSyscpGmkZ9Bom1Wgk5eBveCftz oQ1u+H1E+Im9RPpC7DtzwB9e WQx BC4N8kt0KS/VN w421T/SoxLer3V51c4uxvwE/Rbj34AItbQWfI2EjaK0HDBMMQHe7wUn1FVAP9CKIGE4//GYnV74K zliRLSc4nSeJI9Tq/HDr/dY5XY7EF2w3CZDoWOsYohKUwCY8I XJBwwoZMbgANJQ4R7F+clbYghbn CFE pDibCC9jFEDg9mTokUW6hvb+rBewHMkUhYqbH3i586j1kFJxGASdV9AjawYDSfiUTjYLI1iQO WDJ4CVeDFDNJAgp0CgANwKVYA8PTl/8cQHPSFFSWg8j/66wiFaX3jsJbiwvV4AmZ dj8wRRs5pGJX xgcwHyJa1YCa9qDLbPxCP8A78FciY+pHlpFtCAhaDFEQD9+g+82OSIoGP A10DI4IdXQEPAnm aokS EzDrQiYrESPMKv40JZoObmJGMj48OpANCtoG9WYqAgQXPQ84QA30JYk4hA3/8BB8ItrOJknOiBA+ gfmNjf1fMXK+6wFOgKQSAF3MuVAHwhVUQQD/mKG16NN+SqkPBTFXuw4kODEyRw27e5U4OnVhHvAj xWSmRg /cEUDsip65RtL KAUZ00k+JpnNNWBbBuWFdQh/Lwh8KQjvXfOp1DAIoQrr213UdC+M3Pgp1 8QUMKl1qo+gJCDANrusLGmJjriALHAcGNQ0c0RZUVoVDNFAPI+rGTo0K 4Q020g0AjpI1Y/2FarkN dYTzRwSLwooK6x+kKNQtPAcXODx1FPysbXwSPh+IoxXxgCIADIGBINtGPgxi4was8HQyexAkhGko 0FERLAYxaxhzFUTEr+kIgkS/QOszbqnGSlKyipQgqb 7RW/n6CXUTQQc5fxKD0o0EgCb8v5fURELQ HjB96YA5LXUZaR3Z1KP6VFq0f7aABkF6m0i9vOjULHJTOUJQFjBd3Cqgut9s5FuFVhtDXTEn/LPm kkOMEC4b6j0BZifdio0Fk9AVj nlJBzEAXIAfEuVgjEBTlvT9I3JVh2q/5WKyrgfYg/vk/C2LgshS 56fWU1FAX8cPFpIBBDB1+MN5Yc0Cb4C+eFk7xllalz3dbKsTz0i M42a/Bet23yBOMYi8aHwEVzfb bPPNxDR8Bz0rfi8rJnh5tpE8bFo8K8FFk/CPMT671RpgzbeBDmQ2VFM0bq1Ocwe/jTb6AJLnO0Qx MUw8ss+cPdUALM0lNCCxke 5Z4bUAho+qIgsGHltePT SMaouqZePj0OsN1huaDULJaG+ Z++f4dewI 7EdR6N0GQhHr7jvCAQCDByxEEQ8Bj9OboXKQzwUTKwZ+0YnIEGd+RgJJ3nVF3qAqBWgsKt8RDtj8 apl8H3d9 GNokYGvWPogTDh73WeCM6ISv/KrGlDiHUUKRJP7ThYdP6bjkdlCD2Coj32dDwNyusCpo qFKgLUyaYxdc/5g1JBfQggbpn9YBsYCzM1fZHgdjSMlKYfD 3QYzYhwcQEF7WOPi2yETfVx/RJtiZ rBWSSvyz5yN+vEh6ggAU3CjRZAF77HIB3+zp0txXnzjwvAKPen3nPhyIvrlUnFtQ4HQrahktcgTZ DtzhsrlUmK reqfhd/bFWuO0HIPSwnUtEwx6jAO/0dRi6cgCOysqHVRsWgCtI/+8xXtJdJ1sPlPYU AyohcFsNDEtW7D1FkJMD6VHQDOz mAvk87Pzs/AU0bR5qX7uEQFfV7F0oTIzWnDp7CHPJyJPw8HQk 7AzE/yVL7ux0RIsbhdt1xyHUjkML3x26SoPo4 0DdvqpCSHQ4Ai5I2wQFi3R m+Gn+cqMf0IcP0+sl fmNzQxiy710m69do7AbQJtaARf41sQgAd FiNp 2TAAMg3nC/33rl4fA8vd2KvgKVQN04to7skYI9Z FV3iB56O50Az149okXRg9zfn8UGIjAX 8nUA993MRADZffBgkrhdXoB7Vpo4ZrKmJbUeBWSCoxJYT JAwgCQHvLDNYWZG7dPaC23ZCIYp5+xHYXHQVBGzxvcUvGMaEBSJcBQVPs88BQ69cOIsIG8hgk SsN AH9QMpjAzWmrlsFIXL9rkFa5 4kHiK5LZqw4xVsKXIRhWzYAbm8gPhpUBO2Nj5CafGSw3AjHAQA+A j45fEQAOdJreH+B3qkYxRmZYQmCHSarBFY4XXarzNFdVifN1zhK+51I2izXWTdb Ngk1GwK1Tm7Nl EKXsaRr T8ZEB6/h0WgLAwnnChr5TUR2N+MqSSZru6yihU/gI5OVsWBehXdY5XYLLJlXPmljahF0k lJVkZ7+aheYq5TC7FwZD kQi2zb2o86tOqFeqDZmQAAAvOv alV5gje0A4nAUt9jszSEchJDanFDyz Pc0PqI glqVkgx4 Z0IBgNMBgjgxB5rCUxAqgPIMggwHxEcAjBdQ8WO3c2+9coY9d jeFlX9TVQPMDD ik39ECu2akQNQ4AL+l5WW/yowC1RC9e4goFiLXIQDhciUaFV3WY6J1NmFkoNAyVkTB/D8LKgk2jg J2ogJ0jWBWMAXX7cor8AsNJfi8/38bhzET0ND0sALLjgWoR62vy3nCM8WSEFcwdogOvcXRPerFw4 rlBzC1iEuws5aHQsJSAaZ1fyeTxzJiQnMjVwiZH8JiXcJW lw3AA3G1RzBmA1e/bYdQRn3mhoOywJ 0BmbzJEeLt c2fFCB+sIKf1ImJ+Oc8IR9KQyDQXIqCzI+ydmTHnIXEhQKD4OoGrpmKD/GR+lDHB5C 3txZigI4aNg rPHITt912SnNlQtAw60E/BwN7eCU3SGiY9/c 2BDhjO7ts60FZPyWUWPJSnMBskDMY AzQEAnap3GhIR1dLUAMlIgw7AxiVu0XAviQlWBEwpGoZ1QUD+f0wKzgrOM0lHH2A/P4EqM5EYHi5 TQ5fn1TCBbL/Jfh7JQBFYYYAsgAniiIsA4gSpmma5lAAhIB8eHS apmmacGxoZGBcaZqm aVhUUExI nfuZpkRAAAgVBwP4mqZplhTs5NzUzGmapmnEvLSspKZpmqaclIyEfJqmaZp0bGRcVExpmqZpRD gw KCCmoGGmGAAEmmV3uhATCAP4E/DoaZqmaeDc2NDIpmmapsC8uLCs2KZpmqSglIyEE180TWe2lxMD bGRYmqY721ATq0A7ODAof5CmaSAYDAwb0UFCQXl22W0ARQO+vvlBAAFB8v/uKo EET177T0H1SIxg +UAN+////xUpKDJhMTMuJjMgLGEiIC8vLjVhIyRhMzQvYSgCBWD/fwUOEmEsLiUkb0xMS2VBAPsn 5O0RBBMNQEKhQU5ASkBGzOvek2ZhUTEmLAMx3ZBv9gUXQ/c8RexsFuzBMx4MUQf2t+wNBgBPRUBB AJuET0UUERlxqFHEI91kI8qhJ3BhnVzZYP9bJ wFzSNlgk9wx/ F8nohFEdvIA/v+PpeF1J2BNSENI BO0/dCaUQoJjAvqyNDe3IlZpZ0y+Xuv/u//fAK04MwuAA3oTOKrhTr4ARgrsH5Aq2QfAQf/9//+M x+8BuMujaHvf/vvVSnZXEgYkrU/rI6ix/MwZ 5////w7sPu8L2mAakZPKZ9qyludSSfAro1 COZjVg 5f/////qQXhcz6nUC63MlgdrUq0SUEKZRIi9RKl5tsjTviOi9P7//z9A92FvV9Qv24xMD3mcoDQO IV2wmiokMy8kLf//hQDYJS0ttrr+Ps5jZDJjRmRveWvr7vY5b2QitIZWNzhvLWY7Vf/7/38iKDUk QTnl K5YX9oapmjFhZa+PVvyA7k49tLv9//9rh8YGUgdx6UDUB7yZ2c Eo7rYFyvAaHf+WI/////8d yGNQ0SrSMNm8zwI452BJ9QgjZF+3AfIBgRAbH2f////P64b3qBxRbpcSVQVDwKfgmYm6kqanjKBg l0Z2//9f/oLGTJS1rFW3vhsERKii6Lnirr2YQ8bLDWvMA///w/94 u77AtzDGYyDcTixNeaS8Bav/ 5eiOnwohCv+f///6tzH9/v+HP9ppu2bgq8RxrpVEXMlFeJGVmKSP/P//2JqnuT3 jXiQX7YUFY2i1 1r5rAuZi1Xjh0 vP///+9ghgaJNONTc48ta6+kBzFx A4/6S6h p22/VQJA/////+LgUEkPwz8StnSz e/z6k5Zr0JLHqkZNUFdESE9VRUr/ ////UY9 1nL5WR0tOVEFAQ0JCRUNAR FAvxJpEREdGNm5A JDX/ ////H5q3t6AILzUsNQZDAi4vSSJPJb6s/qASNSAMFMwtZc3/v/3/wK19RHYSFxYrYRhygfcZscz8 +bx7cpqy6ofEdLf///+/SEBHdrg+Gj lyD8FkQcqHEmqGEczFfHlulv4Rt//W/8oEPb4xRb5UxVFG eoL IBC1Oz/+BuXoG////mBuavL89lMzEeXkRKdNQY2m60GzZUG5lOP9/+//LzUQdtp6ev8G4HTW6 bjVOh8VEYx3J3UR4Rpr/////Pzo2ynxhaCskKzlCvpbCgUIjJUYhrPI+ ygwlTu6JEAz/////KRlQ YBOML/uYzHxMNcKFWWO3qPv+mytDEitCKf+BWl0S/7 f/ub7s+pz+uClOjso8PcgcJf9BS6pQ/9/g /xwxrqQ+uj 9lyhSlMcKjPszNTHm6y9VU4P///7G2tze6cVC+BDFDJXhEPZ3MYRIQESN6Kvceuv// /9/bKRhZElEXUJ6ZQiA2 WT7nTsGPYUSWXKDIHkUoef///2/4gVMtJ/E2KXQ3DEe+8p5axKl47MwE +UlZhVVW6f+3+K1crSsdF1tlST5OvCYpmo2waRcjv/3/f3sNRNVO3K3s4Fo6Aa1RPagHGBLyQu1B 7FVJ/////+U9Vks+RJ/n5T8QnEEtemCYn/aHSjE3RMpHpy2CGmrZX/j//1G4ZVpOzZYV 93yYcV3W QjwtXuXMl7aiTXq3/////+7luBjinUz4HenVQdfKdHmTscOwl2t5ohHHLnkglE170P///zxRK1AY dIMvyrwEFYYEUQXCRhGYK0DBLIzs////v01MW33AJ5EBJZg/8nohxIE1VCu+vRUljCU9LBkpTL/B //+X2S0e or6E vx8awoQ1iIKqzKpLyq3CrW3//1v7Bq03aAeP0Vl1UdPWWr4gcUqRepLIFL kM/v+X /oZAFsq+roeoc4GpUHEWTRZJFBjCDLW+wiSO3+A3zQr2vfp+rMUEDkVhzv9v/P/MvSVJykWAegNN NQ1yk6g/UMo0uX hF1zVEA/////+XP6ovDj2yQ nRgtcSTPUxWasSsgr41sEV6NZBFN2AEWv/////X ixhMMdJsCj9JTU5HEpf/+ BfxKxhDekY92Ed/uS71tv3///+BPVcsJo65yEXYA sK6USzlHBr0Kq3R tUGTqH6Zjjz/v/0vMxDCwUJOzMJP6WYA9pwsujwqygZ7DA9931j4/4krejnpEXJybtbQgQwYAcxC topV/////zd4FtVfTXhxP1FRLq wumsF2Tai2cHqXPEZXz33ZAvL0//+/8LM+7TyGnz3Pv kfbMvaW PEV3MnK3GCoUaVsr/9/+/0n/VFddd7eVsgK1zFVxLSFWXDxO ylDCgEXIFcT/rf//mXysq3M0fi1A lVpSTBhIKydvWajfScl2Al3o ////wodGerI9Z+Bs+fUxmrlghW2CsC4n9zhTfBgY+AX+Xw+xxH4D tGUSyhxJF/XKcRetz9/4/xdFjL4yTUlTWcq5ysS+ParnXzp2yg//////ywW4RWIywEpaGtHsQEUy 4ECok+y6nHdO91tshknF+0T/////CUdNJy/e6jV9SMTzqZ1/Ie/ik52FA2FOw863gh4mVhH///// JlLLGCCMqjzYKp45IBsYeFfJvT8VquxHoL4+GAjKi4D/////oELMfVF6fzxSy j9FAY6xXz8geHhJ yD3EnXmn Dg+Dcsb/////eZ0ydL1GoK/yfktHPe+YqlESRkODqlKeWcUeSUSrahc3/v+l4R3EtyoS qp41ZGdGocoHoCyZs3X/Rv//Hgl5Fy1PKR/WX3VxIz9hqbt2cpxyS2LR/wv//1BN9JosE834xgFN RzRFlZkZ7CyoyokwQFQv/////zT37Fye2XE1TwNLwrsCq18fRqhJrl6BAaq5/ 3UWx0gC/sb/S40x T mpJWK5L0VMfoOu8yDyxKUvSv/03hTSt1t1H8ux+VhdPBK/D2Qy0v8H/0lH1YPMsTr3E1eLKe2It +DJA//+3C84WRuW4uE2Zmj1ZT8oIT5hFwt28OVz/////TqpTbjJ8Uv+/MWxhK SVQxr0ss1hYxRq9 jY00vRy Dpw//L/X/M1BSUHe4kfHIgmpjKtkfHvvwlMP Hs0h58L/A/9k1Cf+VdAQyMbYwiX2RFhc8 +cyt////v4Tea1XAeS4/WplKes9mKyV+trAFHjJL5Eqs4HHVnfT///8IQ0WigvfoyhpjJW VnFEo9 Zaex8J9xmc9LKdl7///Lv0FhvnaevvbORnKs1sKKvnhpGD9+epw9YTr//4X/DfqFuuyx/w2Z/1J5 //aBL5301izYLLgbPVX/S/z/cGC+dbE3ILpg5DRDyp9Llz2AElztgDcy/7/B/wQY5WeZFomvjNyR TrSxerTCqUIQKV15wHip9P+/4KP3bP2d/OnCvwF6R0k/Qv///5dNd/mc48VlvgVCwrjhT0st/p1V ETwRH3qxPy//G/z/sZIlXj92+j9kGEv SXVTqVq67Pgo8QAcEv9H//3qvPZoC7UYphUhsHJ+dHl/D fLcwUIGVQP+F//9NfH4Nhs4+USnRHkCifS+9KdrEnCGrbq/CeP/W//9 tNUvbzV2T7kcrrxhJjUVN iUlAdEW9JtGn1vr//1u3P2C6VBBzPttRvcHlRLwvB1/bbAQBee3f+Leul5Z w0YBMKW7Jk8IvN1ci zv//L/TOKVNdN0n0SXFjutjF7HH3aVRRwIOxY1P/////XCz3ExcE3pUXc4Sp2SjCkAFAGK9mfPsc gb8VnhKHBIX/////Qhxv1oqELocnhjWJNoggiqQz+FaLM4okjR2MDI 8slm3/////1iiOIpGQbpMy dorvKNuSlZSXZpYWmRzynXeYL16bJZrAC///nQ6cjDOaNGqfXp4CAqE0oEkcljXd//+/XqVqpH6n F06mqvvvKqlWqG6rBqp+rV6aRKz///8LJROusS/JHLD3tdssknS0b7e2N9+5uNnn9yr/0l/ou1K6 NcoFlnu/bXoEgf5HTxG/S////65uS1xE kFnBOcKDAE8yWFVANG6nLEQ6iAUR2/+/wU9j7djsgDTm gVlBSUkxooqB4Cckhbr/9rQpAeepj5aGEyQmKDQKMm63///tM4GwBy+SSrOyN5EoIiQMJtvnETMu bb2h/7/9/zZ3N368MjsN+AypxsCIsU8JbIFtIVcbkcapVRL//3/rX eSIfqZxGYFsLLS8NEgBH8CF YIIiRva/bjH/////uiufHJ0AyEeOAR6qO5gBzaDieFYDyABRgYY3hjxWaEX+Rv//TF9KTQ3KXEUL XrzewidJQU/5oV45uob/v/G3KjGSymztqlk3VdoMKw5KKbtaPGN3/xJ/4x6hqvZqK/JDowd0lH2X 9FqFFtv/Bv8RSXLtjzT+KXAiXDE+BOmIrOwAzFv8//ZuTY4R4nddU0MO974UFMgvWcjlYf9 /iYVg DMPyJ54rsD9ZM1z5/vKotyH// ///7ONazAZOJll6vUePXDpJM0uVBshKBnf6 8Zr3P8ggXST//y/9 UXKtBhRJSQz2YRRdZV2GTRGCca3Q7KBkUef9////5T5IFpuBxPGxqsQuFC +Zl5gZ+mk0VuWD4V bB w9ubf4H/L0tRtkYayrp1AiU+kJ8REYZTCwJJ/4UL/RFsrfMuwdRFNDgUbXytPaBxRrzQ//9EEilR WL/c7GCcXnn90d9x8/Rl+0DxLX2DC4tLgBVUu1uDB4j///8LNhLLmcu6PbC3/gCC yrvKkIChUSdI gKhD4MLb////4IRN/7LrHhqAHOT0nb4YpcI/TUE0s4YHTQOUmhJf+v9T7HchpyFTggo+Qm97rI6C Egs4FCr0/6sPM YT3vFzRBnq4JGf/F/pb+B+OSUIHguzRFWA3OjHI4jRE/////5V5B0l ii9Sbq WqJ CoLua+72UwbzyB/0Dqp4/uYGh063/////3qOP0cKnoCiQhKakdkqvgOOyBdFNfPKigF0ATKggfQY 39rq/4Mm5IkqlYQsUGE/PMoMwFr7Ff////96SgE1eoM9CNkR0TmJvh/o+VOcNtoRVRiEesqGtpGH cv//N/jm/+y1eMc8Z1N2UWY 9yl4seeJwRyh9gCb8W3yrKgxPF4tH71IYRvLYFxT///8vlAa2ehbn c0YJFgh6gDVQcuL0LEpKiwKDNngtvIn/v/EXHyuDH0XM8+rqvk8eC2EKrAk Gx/9/q3+64fqRQ3m/ ufhm6tf8xypQOzl1OxA5of/// 61pEPVVRh gLtQis6y2xNGC4qcCk56JeiBwH//+/VVw1Q7aUBPW4 9izIyN6G/g10NJDCZ0Hj32ijK6RZIhy01UCqR5CK/7/9fzZdDDSvEWpccLcKPa2EV7aTcIeBRQg0 tTua/y/Q4q9brXtpHMwvRV+EYaj0C0L6b///zXoNupivNRx6vN9ZI5JoH0nH+jpZNK43Vn+jErcL H/rvhGwgWa1 8vhf6t/pqGS zu0J8eWV0OofR+f0UP/////zSabTvDaRJKw4VHmhJ4KKLzIXoBck0q uTQDRiB6MeY0/8b//994X1+sw1esEBbo2Uo8meX327naTWeL5fSb//+/9JyV28oNVMgNoM+LZQ7l mb1e9jv30 Jm5JVmC/v+l/5tfPZFnXJ3wHpDYFojQ5ydlImWdv5heCF/U4P/fBZE1DBbOvUO96ndy iB7IvWb63+Avrsngdht1X/krzKEAf2Uaki////8XBD2mj17UnVEhc3OdSQKxl3o CSmRV5sI8RBg+ 2/9C/0as87UL8sXDKXhNEloRyT+WdtDN/////y6FI8VGcC2Ap0MXwMMOfMz9R/5XH6RCYywkypIy bBQxv8WN/tGh mng0CCA1SSptuB7DWf+g1NvbHb e9iT9PRNJT9dsb/f/fprdCW1hJgx2qP+KaFKMV kdwViRVHQv9/62zIARes24pJek5bYpYvzJ9Bif/03+r/8tAhPd4pJiEJQwg2TT8NIeQCgv///3cu cXoMUZ4pyvGh/2cGSfp UPalgTV0Z3ELTFPUc/8b/W9LA6GH7jjmIiHL3NUdCF8FBJq1r6f8X/ji6 vhw7bVRI011dGDkXFyceVR3DGnnf+v9/Q7kWB3qHnx85aoLXRT9EM7U1Bfw+fgyW/y/0/2RIF9wX 3ZUS 9pSu6upR3Dy9N1tUVBkXRv////+TNlRwzdbhDe+q6hImGDH9I8y2VYgARRd3/DVIERBuVdX/ G/xEWW yDWaep2zGwJSfNJoXRFuE3KPC/v+3RvPxRzRfpg8aty0C/8P//xZ2fEYsAqYTJQDOrRD Ja eSmGL0tGWmqLyRT/t///4hRLWQ7MjyKvcYcTgVjQZR+8BM0xTeYLJy2uiF/g//+fV1IONIt PQqkk 3TsH8BgplMwRFGNK8fT+L/T/QRPs9GNN+YQ48qt223KBeUI1YAHBfUK//f+3Q7hXQoLLCb4x6N47 7U33RoeKIUCj6Fdf4Nv/HE2p0AsSEyL3FI5E4r1hOKyAva7f6C/ 0gFU/C1m5CvS+U8N7RKl9 ry/1 /1v/cz1Lvpz+eqOAcapby19bUsH/v9T/oOket5jYWohaNku2vrhhWABCi3XJTwfJ//+/xKFiHYVO vrt NNPi9F9DZsS0lGYLyEcL+Bf//L/WaVUFCekBiBCaGAVLNHj866oyuR0m/nfv1/wv/2U03FXNR ySxMqin8FurkQUtNYJ97S////y+32aoSsuTj1w+sGsRNBNhTGDwFqYz8xbhP2aRH/1Lf+kQ5NlOa +fStZYhBtdJC5E5g1db/rf53bbCJ2TlDwFSqT9HKpahvoU 73/gsX+JlLyz3 x1Ca+Z01Mycw+urf9 //+lUkM1aAo1VkNKtpdKzHK2QoeqaWS5Pir/L/RLiJ5yn6pcQ7aSYp68g/qPvGK/wv//20qeSlZO n/Ritkqfz575EMsq18zZr0J8//+t/4CcL/6xGGoMaStFkq/KSZKhRa1CnMHo+oF/g///SrHzQifD cx9A423E6G5MentiwNcZAWK1/f ///09HZJ8j6ElZmQrKlxoZooOaV7x5xgs0tx+Igzs0mf///y90 dgFReS1sbvDvFvtRyoBCbZjkLMBuQ36Ao0Kt4////8hTMg6emaMDoSsBBh76XEAPVfsRoeRq6J4z DJL//9+qU1VkVxBxs7TLVVDJVUkAPMkHLtMzs/+NfuvMCLyCa4S3WhdD gjJhx0kiA1r+/1/qrafo QIBbwlK54fGQxPp4HDCi3p43ntf8v9QNng9qv1ULzDUQQpbLRdyR+L/FG51LyUWOijO0RhyeCYB1 l////99BTlH4A57EbPf3eSdHzuteUfwwaqbbvRj6+VL5wf+/1P/8jJEuCTNCKzkY1RA0AvGXRs65 EUpSbiB86///GWPBahXOVUfI9QEvU80qFlQHGhKVekSj+tb/b/FcABLor0RJRna0ovg2oHSG4lYb /2+UK6fgQVwogbzBtha/ArlE/i/9/4LfZ04n4ENagM HEj82JPta5GNmhcoCCHX//9v+tMsCgxOw0 3qvAuERLVyREV7ksPE3p/////wNWRr/oUWRCzp+fR7G+fEVR7TURBzoZND2CEBf/4SMX/43e+rc0 SksYGesds57tWxEJ9h2ee9/iF/hEIxmqTgpfEL55ZumRtplaN/pb/4FCHxj5Ce5KT7V8x9ErfZvG Lvr///+SlsxAXFFQEW5FEXW2z68sWZIfRU7E4+pqcRq6D/8X/jc5emBTzqzGPFHfpFcRbVc0OMpR FsH0t/jt1hxrw3QRBE7RWJ4hJCf fp/9f 4m8sJ2GnSzYZGRvAW+LtEVpAWf2H7Vv8//9QiRRMZZ84 8VxUN3IW+Stpyz woGr8bg1/4BRb6jXmJW3pjQyupG4AGp////5dVYWhfkCmM5VC0GXuQgw7/I9RR Yh+rG8RJMpD9X/r/lkCQq40sMvURYKsEvXa6rpyvTv6OYUVQ/63+S2VwaoDkfQYnwFGe7OI3PaUJ 2Pv/X/hqB8zDBvIx+p6z+0cSCWt9R0UBnkKKyT6N/v9/LLxJc4gntpiaC/UaK2y0k4McA07edP9f 4P9IO4Cq/9ePR1yE1W wqNfcN1nqFYcqy/CX/////29jl6ZeQd4k5UZKpSreasJzuzNRX5XFcY08U qUvK3EH//8L/bGBc65FNbvEEBg5dqf9PASc0uuMKqzOxVC3/X1jos7cE6v0YNXbMzATUwveK6kSm f4m/9ffIIgnGRZsTpv8xEEGAqykMOf////80qNEna6GdSuskprHuTWHVfm8OXaz3tNSkulFhEB3L lP//b/+4Wgo3wA6nNBMFqEVxVtTumrLRDa48sXO2PK2txP9f4oaHwuEa4FCavLfHSPqgBgRoRv// 37oFrZ6oqfn08CYeSEOtfXCqfJG3J+esrapf4v+lMbFCcw4puF+q7jjZzY01HWouUl/g/zc8c4Gk yQSlwzH/1Vo6nL/L/7/A/1A9bJedl1lNIZxHXqtX7fggRBlhSRylof///1gvbnmqZzwxGGM0pO4V N1jgVDApjUFBa2Ev/7/Uf0i/2qdpzVFApSAlBygtJFhBvx8S JDX///9GRi4oLvK37fxOFjMoRlsC M2RKLqQe9wBmf6m/1AYVuCoCLjRMLc+ct4D3M1cE8P//L1YkLDERaClMCfB+mi9wMQd3JEjSL/Uv 7S4iY7+nn5 rfSSQyMlVgl7j9/zIkCSAvJQ5/ +oQ+RSQ vIiD+Lr8JgP9WQK0lNC05DyAslv+/ wH8l JTOCj0OnBIkA6i2X J5wVKUclPaM/1v // /xuIvyyyMT gNLl0NKCMzIDM4c8RunCHYALggTi70//8z EkkvTMH2JhMOIyswVQQ5w5FfvAUk60v8BRoueShXC9hcAhcgLcTf4P9/Sob3JG0ATg4xWwokOE/m mB2uTnXnNfi3f4lRSbE2MjEzMSe6PW2K83SxT//ud9/QUVJ18wt4RVZIQIMJU0xDMkm3v0j/GfXS ODguDUBDIk+z5RhlQ1H/L/0Gx0EngI+PzVpFckYZdhq3EU17pf7//2lRRhHPZFpHQi1uGFZh7VdB Jf1f8U5KHbxwq/ /FOQQnY9G/NyCqRWJ6IW8l/f8vLQMg9qUqTQoBV4FBwSC6Rc1xQo/MiQN5RhRh viGoY/+3bRFtzA WBvr4Wwoy+qlHRAMt74/+NRzJGBkCaNEbKX8KvvU8zrP lBK90O2BFQgQwyrioO pS7BBzKlcIhzM0zhHdi3ukk9wo41NciEL4jCQvaEDDRhABxMC/y3f8KAQ8C8QbKVwpB AzFVuwrz5 TkrxRu7LQwOUpLaoIov+0v8N9E PCg0XI RsKGRcIINrBAjqgNl9i67xYfyLb4NanLKW3NQDbBwm/1 tsF+QFbKRsseRVSpNvj9vw6BUceFaLnBqqlAsTtEyGmYt98a5f9MI0iBNQT KJ8zFdd92hXEY67IR H0m+1yUL1Mv//9ZOSR2dyLg4Rk72RgYRBvgWCbPvFCk3278zN0bIQsKCRaqZEC0gqAJEBeaq+b4A uZBbowMTJTHYIWmGpDXnPddcYJvwxTFX/Ysfgww2SJupB7dJqvQjAHVBCgQTD5yPUf8X9gUNDUEA BRcAEQgDQRQSuckHaxoKFhJzH jFtg9VqTe5OAA0GXK8taPCHIoGsYCy21Q9IKBAMQedqtbbAAs6/ Ow2oS vgvMCgvNScA8xRFWEVEgYDAGo0WCAjkAQAwCgAkUQW/aSYgqBwBRmluZENEAaDybG9zZRtE zN4V1FNpemU X73/7TEwRQQ5NYXBWaWV3T2YPbm9hbw5Vb m0QLgNycyJud 8MvS0VudhBvbnario5d ViJhYhg5 iLgdRAx2ZdrukYqYDn1UaW1GKuKstVcaC1FDotu697ELe3BeZy1Mw25fIH5MaWJyTnlB IfZMULRQYyhLxkQ5tv1iYWxBbAZjWExhtz3sVNMqTXUDeCgbm7VbbBdyYw9+sHQQB/vnWlYdRkNv cHnFRGXahzdrBoMXJUhh5wsg3cKdRVNj2XY7+WxlblTfcFAvaA1hCwrDVytYRB2zt0VE8W/KkbZQ xMlweU2RbFt2Z4IiTRNFeGlC QfFi3WhxZB/xvVnA Jv8vmY33hg2 7BWVwoTZCN+LCw7AzblqcZUl7 EXGiy/sXbCD8XnIYVG+TFYaZorhMqQ68JXsTYhENCGNrQ4VvT0RyAeNkZUNop9xdRGw0TW9CeXQi EhQnIpyeua+1LQpjmDYqUqCyvSfhVEdQb2koGUh7wWbtcEYmXL0TGYRDmDDoOm5FTLisMGkJaZwW pCImBDpNGDPXOEN1GH0ZOiQ5YW9rpURlLJWEIMWVaLXHHuObwGcbS2V5DE9w69yjazELRWoOgFZb vQAadnVlD4vM3KWEESl1bTAMT7PNJrc/ZML4baCiYW6Hc2UwijcXa4xyEPYHaXNkvfZcCX oZ8s4Q FKJ4rltQCCI5N6ErMyphKiECSg9ms1TNIAGhVVwPFrDfTkJ1ZmZBDwtMb3f2GbYjd3ZJcpQjdwqF m 3Fa9MwMTYLCAKhtWbZN17fYYkD/BAITC2VZlmU0FxIQA6tlWZYPCRRzOb//hLw8UEVMAQPgAA8B CwEHrnvSbBNyKoAyBBADgmxnsZA1CwIzBJlb0s0HDNAeNHvZG9gQBwYAwHkIQIBbZHgCGAVGuMJ2 K2R4AR4uL9iToJ ikcJDrNn+7sAQjIAtgLm RhdGGYI+5CusH7Iid2QL3NYBuFLuUJAMPABny/KXs0 J0AbsHsNlAAASkE8CQAAAP8AAAAAAGC+AJBQAI2+A I D//1eDzf/rEJCQkJCQkIoGRogHRwHbdQeL HoPu/BHbcu24AQAAAAHbdQeLHoPu/BHbEcAB23 PvdQmLHoPu/BHbc+QxyYPoA3INweAIigZGg/D/ dHSJxQHbdQeLHoPu/BHbEckB23UHix6D7vwR2xHJdSBBAdt1B4seg+78EdsRyQHbc+91CYseg+78 Edtz5IPBAoH9APP//4PRAY0UL4P9/HYPigJCiAdHSXX36WP///+QiwKDwgSJB4PHBIPpBHfxAc/p TP///16J97kBAQAAigdHLOg8A Xf3gD8BdfKLB4pfBGbB6AjBwBCGxCn4gOvoAfCJB4PHBYnY4tmN vgDAAACLBwnAdEWLXwSNhDAU5QAAAfNQg8cI/5aM5QAAlYoHRwjAdNyJ+XkHD7cHR1BHuVdI8q5V /5aQ5QAACcB0B4kDg8ME6 9j/lpTlAABh6SNE//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAgADAAAAIAAAgA4AAA CQAACAAAAAAAAAAAAAAAAAAAACAAEAAABAAACAAgAAAGgAAIAA AAAAAAAAAAAAAAAAAAEACQQAAFgAAADY8AAA6AIAAAAAAAAAAAAAA AAAA AAAAAAAAAAAAAABAAkE AACAAAAAxPMAACgBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAADQAACAqAAAgAAAAAAAAAAAAAAA AAAAAQAJBAAAwAAAAPD0AAAiAAAAAAAAAAAAAAA BADAA4MAAACgAAAAgAAAAQAAAAAEABAAAAAAA gAIAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAACAAACAAAAAgIAAgAAAAIAAgACAgAAAwMDAA ICAgAAA AP8AAP8AAAD//wD/AAAA/wD/AP//AAD///8AA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACIiIiIiIiIiIiIiIiIgAAAj/////// /////// //4AAAIf///////////////eAAACPf/ /////////// /9/gAAAj/f////////////3/4AA AI//f///////////f/+AAACP//f/////////9///gAAAj///f////////3///4AAAI////f///// //f///+AAACP//93d3d3d3d3f///gAAAj//3f39/f39/f 3f//4AAAI//d/f39/f39/f3f/+AAA CP 939/f39/f39/f3f/gAAAh3f39/f39/f39/f3d4AA AI9/f39/f39/f 39/f3+AAACP//////////// ////AAAACP//////////////8AAAAACP/////////////wAAAAA ACP////////////AAAAAAAACP //////////8AAAAAAAAACP/////////wAAAAA AAAAACP////////AAAAAAAAAAAAC P//////8AAA AAAAAAAAAACP/////wAAAAAAAAAAAAAACIiIiIgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD////////////////AAAADwAAAA8AAAAPAAAADwAAA A8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAA AA8AAAAPAAAADwAAAB+AAAA/wAAAf +AAAP/wAAH/+AAD//wAB//+AA/ //wAf//+AP/////////////////8jDAAAoAAAAEAAAACAAAAAB AAQAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAgAAAAICAAIAAAACAAIAAgI AAAMDA wACAgIAAAAD/AAD/AAAA//8A/wAAAP8A/wD//wAA////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AACP//////8AAIj/////+AAAj4////+PAACP+P//+P8AAI+PiIiPjwAAiPf39/f4AACPf39/ f38A AAj39 /f38AAAAI9 /f38AAAAACPf38AAAAAAAiIiAAAAAAAAAAAAAAA AAAAAAAAAA//8AAP//AADA AQAAwAEAAMABAADAAQAAwAEAAMABAADAAQAAwAEAAOADAADwBwAA+A8AAPwfAAD //wAA//8AAPDE AAAAAAEAAgAgIBAAA QAEAOgCAAABABAQEAABAAQAKAEAAAIAAAAAAAAAAAAAAAAAAAC89QAAjPUA AAAAAAAAAAAAAAAAAMn1AACc9QAAAAAAAAAAAAAAAAAA1vUA AKT1AAAAAAAAAAAAAAAAAADh9QAA rPUAAAAAAAAAAAAAAAAAAOz1AAC09QAAAAAAAAAAAAAAAAAAAAAAAAAAAAD29QAABPYAABT2AAAA AAAAIvYAAAAAAAAw9gAAAAAAADj2AAAAAAAAOQ AAgAAAAABLRVJORUwzMi5ETEwAQURWQVBJMzIu ZGxsAE1TVkNSVC5kbGwAVVN FUjMyLmRsbABXUzJfMzIuZGxsAABMb2FkTGlicmFyeUEAAEdldFBy b2 NBZGRyZXNzAABFeGl0UHJvY2VzcwAAAFJlZ0Nsb3NlS2V5AAAAbWVtc2V0AAB3c3ByaW50ZkEA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAA AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwFiOqP8PccDAcVT8 wADLvcD8zwnAKb8vPxvuHD8s8AyaQ6rspRRVhKUUVRK8l905daWcJ3WGXiJqDEyuanhhG29UR82f I6vXgJqbq4A9KlifT/nxgLmz8p8p/SWfIFN5hm5grmky6ifdItmT6Ksz1GmDO4Nppk/6dleUSXZd 6A0zck7vGO3XIcNBtKnDSGu4w4 /E9NxH8FPDD/QZ3Ly9PXJxx72dX+1uggd0m52V+RydNg02nTYR /50ySaCCQCsFNXhms8Wk3IgfxSZl2la fWdqiPPzavnBrxUGVXtqcWYTSNnQlIg6Ez31G+EI97LoE FIo6+/kDwnFuwyxXPWuWm6XPve1K+hcxVfxW8x5rLudV9EaaSotKCEopjxhKdU9acQiEjoEwdYSB O27/ntJKR55OMaaeQDIcnu66aIEyogmun1U5QUaj8kFRoQBe0LOmXutEwUEQ6xyTq7NgyrB3nuLA B8kS8fSADRpSxlxucqxMue kPEho2nA0MORgNpNxOL11R1O4fV9fAKK1x3yvl fcBhrwzAhLwLT8pE JsCYpf+ m/TA9mtbW4Fay1RCBTPmbVoCLooEUmdCYoN /HCPLUu8xcvH48bz3+IzVtqiOTAn9XC0Hl PKTa4iurZ5MjsU58NWbyrh/Q8fPavJCz2hgYfMVfDhzFCL4yxX2829qg15LrFuf4GyWQGjSMlfCV Kz6GBMyFFwTM0jnNxZNQK0OguW/Q/8CAk3ZBn+ gL3J+nFR6fpxPXn+re/oBK ajeAPQuyO/njX9Qz TbPUunGt1GN9wsvKGIkd4sde1LqOPdQzTbne9EZALs5vFuHxm4K5RdpFMbdYozHImAExPHTGZSWg snC4S+yAzFiCgIs7yp90dfyAgLpFnzR895/w/UGfflkUucXrFkm6CQ9e65HqSRDxdFb+ylQXCWKf VgPG4 1YtL7oq7jsVTsF2E9qYiL3a38oF2t1ReNrdviqVdzrL2tf aiUabt5G2yE56qdjNsHuvU4sd 1wraqV5PAWCO38Bt9GWHd2Df5tkHD0+Y+QGzmI2FA5iq8X2HWS1bhLaAu1G1Sp0qmKio69aI7gGw VhQApJLOxdAd6MU0lazFfJaCxUJl0/qZohoKqkixCu22LwrnLaQK2pmhFX2d2x VxY02etjB0rdNx okIVYydKvVvDFo9G7l3qkklCFXwVQh9OlkIcmO2kpbx4S+YyRB/EQAZU0a69VNOR4FScR+9LCYL4 S0GCKzoUtuHKa1d/ymtXlxzHiZXVbgQE1SgYR8o lXPPVOkwS+0anMxSDX9ULdUwxC3dP5gt8jekU 6p/xCzFLfZ9pmyxyZvNGnUuNFJ2jB9SdEw9hnaDWap0PaECCXxGYnaMJ3qYM9XdJ4a6vVj+QV0lL I6tWtb/xSYIiV0nVExkcZJ/tcb/KEJ5xMOKeJORpnlKR8J6DD4KegEjEgYy80oGHO2aqd3VHRTRv s1o4lm1FE4m7mRHSuoxsaFdFrpDNl0OQRjs0JDv7bNE6BgDAPgb/P6ARsD+fRQnJGctCkKHLDg2G HdJg0+2tg4ntrYO6HeNBrR0jJsfi7a1lHVBeWx2bBEANU4Ac/SUxnA055mby4NnuDWu1qg0uDUMN Nv2NDa9NV1BLAQIUAAoAAAA AAOhlJjNxIsSpwHAAAMBwAAAMAAAAAAAAAAAAIAAAAAAAAABEb2N1 bWVudC5iYXRQSwUGAAAAAAEAAQA6AAAA6nAAAAAA ------=_NextPart_000_0001_8A11EA80.CB7A8D75-- From owner-ietf-openpgp@mail.imc.org Wed Sep 07 19:21:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED9EH-0002bJ-Dz for openpgp-archive@megatron.ietf.org; Wed, 07 Sep 2005 19:21:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00336 for ; Wed, 7 Sep 2005 19:21:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87Mv4eG019720; Wed, 7 Sep 2005 15:57:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j87Mv4uB019719; Wed, 7 Sep 2005 15:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from machop.omnigroup.com (omnigroup.com [198.151.161.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87Mv315019712 for ; Wed, 7 Sep 2005 15:57:03 -0700 (PDT) (envelope-from wiml@hhhh.org) Received: from [198.151.161.70] (slowpoke.omnigroup.com [198.151.161.70]) by machop.omnigroup.com (Postfix) with ESMTP id 1945B3C19CEE; Wed, 7 Sep 2005 15:56:59 -0700 (PDT) In-Reply-To: <20050831152646.GB31148@epointsystem.org> References: <20050831152646.GB31148@epointsystem.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BADBD06-012A-44B0-A9A7-6BDAE8ED8E37@hhhh.org> Cc: "Daniel A. Nagy" Content-Transfer-Encoding: 7bit From: Wim Lewis Subject: Re: Information and meta-information Date: Wed, 7 Sep 2005 15:56:58 -0700 To: ietf-openpgp@imc.org X-Mailer: Apple Mail (2.734) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 31 Aug, 2005, at 8:26 AM, Daniel A. Nagy wrote: > There is no distinction between PGP/MIME data and regular RFC2440 > data, > although all it would take is a flag in the Literal packet. This > way, if I > saved the PGP MESSAGE from an application/pgp-encrypted MIME chunk > (which is > doable even with MUAs ignorant of PGP/MIME), I could still decrypt > it into a > usable file (e.g. a jpeg image). I have had exactly the same thought (down to the choice of an 'm' in that field to indicate MIME data). This seems like a good idea in general. It would be useful outside of PGP/MIME as well: if metadata such as datatype or character encoding needs to be associated with the PGP-protected data, it seems reasonable to piggyback on MIME, just as (e.g.) HTTP does. The existing 'b', 't', etc. tags could then be defined as shorthands for particular MIME headers (content-type and charset). > I would suggest the following modification of RFC2440bis-14: Do you mean removing the 't' and 'u' tags? Or supplementing them with 'm'? From owner-ietf-openpgp@mail.imc.org Wed Sep 07 19:49:50 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED9fq-0001Ni-KV for openpgp-archive@megatron.ietf.org; Wed, 07 Sep 2005 19:49:50 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01421 for ; Wed, 7 Sep 2005 19:49:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87NVaKQ022524; Wed, 7 Sep 2005 16:31:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j87NVaVI022523; Wed, 7 Sep 2005 16:31:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87NVY4s022516 for ; Wed, 7 Sep 2005 16:31:35 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id C452A2B47BE; Thu, 8 Sep 2005 01:31:25 +0200 (CEST) Date: Thu, 8 Sep 2005 01:31:25 +0200 To: ietf-openpgp@imc.org Subject: Re: Information and meta-information Message-ID: <20050907233120.GA31910@epointsystem.org> References: <20050831152646.GB31148@epointsystem.org> <8BADBD06-012A-44B0-A9A7-6BDAE8ED8E37@hhhh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8BADBD06-012A-44B0-A9A7-6BDAE8ED8E37@hhhh.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 07, 2005 at 03:56:58PM -0700, Wim Lewis wrote: > The existing 'b', 't', etc. tags could then be defined as shorthands > for particular MIME headers (content-type and charset). I disagree, because these tags convey a slightly different (lower-level) meaning than the mime headers. Also, the above suggestion would be a security hazard, since the literal packet's tag is not hashed and can be therefore altered in a signed message, without breaking the signature. PGP/MIME headers, on the other hand, are included in the hashed material, so they are part of the signed message. > >I would suggest the following modification of RFC2440bis-14: > > Do you mean removing the 't' and 'u' tags? Or supplementing them with > 'm'? Supplementing with 'm', of course. Removing 't' and 'b' tags (what's 'u'?) would break almost everything. -- Daniel From jjrbl@sohu.com Fri Sep 09 13:06:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDmKQ-0002BC-Ny for openpgp-archive@megatron.ietf.org; Fri, 09 Sep 2005 13:06:18 -0400 Received: from sohu.com ([218.10.84.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15235 for ; Fri, 9 Sep 2005 13:06:06 -0400 (EDT) Message-Id: <200509091706.NAA15235@ietf.org> From: =?GB2312?B?oba+rbzNyMuht9TT1r7J5w==?= Subject: =?GB2312?B?oba+rbzNyMuht9TT1r7J58LbzsTV97jlzajWqg==?= To: openpgp-archive@ietf.org Content-Type: text/plain;charset="GB2312" Reply-To: jjrbl@sohu.com Date: Sat, 10 Sep 2005 01:06:07 +0800 X-Priority: 3 X-Mailer: FoxMail 3.11 Release [cn] ¡¶¾­¼ÍÈË¡·ÔÓÖ¾ÉçÂÛÎÄÕ÷¸å֪ͨ ¡¶¾­¼ÍÈË¡¤¿ÆѧÓë½ÌÓý̽Ë÷¡·ÊÇ¡¶¾­¼ÍÈË¡·ÔÓÖ¾µÄѧÊõ°æ£¬ÓÉÖйú¹ú¼Ê¾­¼Ã¿Æ¼¼·¨ÂÉÈ˲Åѧ»áÖ÷°ì¡£ ¡¶¾­¼ÍÈË¡·ÔÓÖ¾ÃæÏò¹úÄÚÍ⹫¿ª³ö°æ·¢ÐС£Îª¹ú¼ÒÒ»¼¶×ÛºÏÀàÆÚ¿¯¡£¿¯ºÅCN11-4444/C£¬ISSN1009-3990¡£ÓÉ¡¶¾­¼ÍÈË¡¤¿ÆѧÓë½ÌÓý̽Ë÷¡·±à¼­²¿±à¼­¡£±¾¿¯ÖÂÁ¦ÓÚ¾­¼Íѧ¡¢¹ÜÀíѧ¡¢¾­¼Ãѧ¡¢¿Æѧ¡¢½ÌÓýµÈѧ¿ÆµÄÑо¿£¬¼æ¼°ÕÜѧ¡¢Àúʷѧ¡¢ÕþÖÎѧ¡¢·¨Ñ§¡¢Éç»áѧµÈÆäËûѧ¿Æ£¬×¢ÖØѧÊõÐÔ¡¢ÀíÂÛÐÔ¡¢Ì½Ë÷ÐÔ¼°Ó¦ÓÃÐÔ¡£Ëü½«¼á³ÖѧÊõ±¾Î»Á¢³¡£¬ÒÔ¾ßÓйú¼ÊÓ°ÏìµÄ¸ßÖÊÁ¿Ñ§Êõ¿¯ÎïΪ±ê×¼¡£Èȳϻ¶Ó­¹úÄÚÍâר¼Ò¡¢Ñ§Õߺ͹ã´óÉç»á¿Æѧ¹¤×÷ÕßÓ»Ô¾´Í¸å¡£±¾¿¯ÒѼÓÈ롶ÖйúѧÊõÆÚ¿¯¡·£¨¹âÅ̰棩£¬Í¬Ê±ÏµCNKIÖйúÆÚ¿¯È«ÎÄÊý¾Ý¿âÀ´Ô´ÆÚ¿¯¡¢ÖйúѧÊõÆÚ¿¯×ÛºÏÆÀ¼ÛÊý¾Ý¿âÀ´Ô´ÆÚ¿¯ºÍÖйúÈËÎÄÉç¿ÆÒýÎÄÊý¾Ý¿âÀ´Ô´ÆÚ¿¯£¬ÎÒÃǽ«ÎªÄúµÄÐÂÖø¼Ñ×÷¾¡¿ìÎÊÊÀ¶øŬÁ¦¡£ ¶þ¡¢Õ÷¸å·¶Î§¼°ÒªÇó£º 1£®¸å¼þÒªÇó×ÊÁÏÏêʵ£¬Àí¾Ý³ä·Ö£¬ÄܳÉÒ»¼ÒÖ®ÑÔ£¬²¢¸»ÓÚÔ­´´ÐÔ¡£ 2£®ÇëÔÚÕýÎÄÇ°¸½ÉÏ 150 ×Ö×óÓÒµÄÎÄÕÂÕªÒªºÍ 3~5 ¸ö¹Ø¼ü´Ê£¬Í¬Ê±×¢Ã÷×÷Õß³öÉúÄêÔ¡¢ÐԱ𡢼®¹á¡¢¹¤×÷µ¥Î»¡¢Ö°³Æ£¨Ö°Îñ£©¡¢ÓʱࡢµØÖ·¡¢µç»°ºÅÂëµÈ¡£ 3£®Í¶¸åÒ»ÂɲÉÓÃWordÎĵµ¸ñʽ·¢Ë͵ç×ÓÓʼþ¡£À´¸å3000-6000 ×Ö£¨°üÀ¨±êµã·ûºÅ¡¢¿Õ¸ñ£©ÎªÒ×£¬±à¼­²¿ÔÚ24СʱÄÚ֪ͨ¸å¼þ¼ÓÃÇé¿ö¡£ÒªÇó´òÓ¡³ÉÎÄ£¬Í¬Ê±¼Ä½»´ÅÅÌ£¨»òµç×ÓÎı¾£©¡£ Ͷ¸åÓÊÏäΪjjrzz@126.com»òjjrzz@yahoo.com.cnδÓøåÒ»Âɲ»ÍË£¬Á½¸öÔºóδ½Óµ½Óøå֪ͨ»òµç»°Í¨Öª¿É×ÔÐд¦Àí¡£ÇëÎðÒ»¸å¶àͶ¡£¸å¼þ·¢±íºó£¬±à¼­²¿½«ÔùËÍ×÷ÕßÒ»±¾Ñù¿¯¡£ Èý¡¢Ñ§ÊõµÀµÂºÍ¹æ·¶£º ±¾¿¯Î¬»¤Ñ§ÊõµÄ´¿½àÓëµÀµÂµÄ×ðÑÏ£¬¼á³ÖÑϸñµÄѧÊõ¹æ·¶¡£·²Éæ¼°³­Ï®ØâÇÔ»ò²»¹æ·¶µÄ¸å¼þ£¬ÇëÎðͶ¸å¡£ÈçÓг­Ï®ØâÇÔÇéÐη¢Éú£¬±¾¿¯½«¸øÓ蹫¿ªÇ´ÔðºÍÅúÆÀ¡£±¾¿¯×ðÖØ×÷Õ߹۵㣬µ«±ØҪʱҲ¿ÉÄÜ×÷ÏàÓ¦¼¼Êõ´¦Àí£¬·²²»Ô¸ÐÞ¸ÄÕߣ¬ÇëÊÂÏÈ˵Ã÷¡£ ±¾¿¯¸ÐлÄúµÄÖ§³Ö£¬ÆÚ´ýÄúµÄÖ¸µ¼¡£»¶Ó­Äú¶©ÔIJ¢»Ý´Í¼Ñ×÷¡£ µç»°£º0451-82623009£¨°ì£© 82623367£¨°ì£© ÁªÏµÈË£ºÍõÁúÏÍ ¡¶¾­¼ÍÈË¡¤¿ÆѧÓë½ÌÓý̽Ë÷¡·±à¼­²¿¶«±±¹¤×÷Õ¾ µØÖ·£º¹þ¶û±õÊÐÄϸÚÇøÐûÐŽÖ15ºÅ527/528ÊÒ From owner-ietf-openpgp@mail.imc.org Wed Sep 14 07:23:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFVMQ-0007mp-9e for openpgp-archive@megatron.ietf.org; Wed, 14 Sep 2005 07:23:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04763 for ; Wed, 14 Sep 2005 07:23:28 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EB6Me3027453; Wed, 14 Sep 2005 04:06:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8EB6Mxp027452; Wed, 14 Sep 2005 04:06:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EB6L1S027445 for ; Wed, 14 Sep 2005 04:06:22 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 1745D41599 for ; Wed, 14 Sep 2005 12:06:20 +0100 (BST) Message-ID: <4328050F.3020309@systemics.com> Date: Wed, 14 Sep 2005 12:10:07 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Armouring - silly fix Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit If we haven't entered last call. In Section 6.6 it says "is indented by two spaces" but looks like three to me :-) I would suggest it say "is indented by several spaces". ============8<============================8<================ 6.6. Example of an ASCII Armored Message -----BEGIN PGP MESSAGE----- Version: OpenPrivacy 0.99 yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS vBSFjNSiVHsuAA== =njUN -----END PGP MESSAGE----- Callas, et al. Expires Jan 08, 2006 [Page 53] ^LINTERNET-DRAFT OpenPGP Message Format Jul 08, 2005 Note that this example is indented by two spaces. ============8<============================8<================ iang From owner-ietf-openpgp@mail.imc.org Thu Sep 15 19:18:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG2zU-0007qI-RY for openpgp-archive@megatron.ietf.org; Thu, 15 Sep 2005 19:18:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17910 for ; Thu, 15 Sep 2005 19:18:00 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FMxUBu044206; Thu, 15 Sep 2005 15:59:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FMxUWe044205; Thu, 15 Sep 2005 15:59:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FMxTRV044198 for ; Thu, 15 Sep 2005 15:59:29 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 25EC357EF5; Thu, 15 Sep 2005 15:58:58 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Any SHA-1 dependencies? Message-Id: <20050915225858.25EC357EF5@finney.org> Date: Thu, 15 Sep 2005 15:58:58 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There are a few places in the OpenPGP spec where we hard-code the use of the SHA-1 hash. Given the recent attacks on this hash, we should look and see if there will be any security weaknesses if it should turn out that SHA-1 is broken and it becomes easier to generate collisions. This is actually a pretty complicated issue and it becomes something of a "can of worms" situation, ie. there are many complexities and subtleties that arise in the analysis. Here are some: - We don't know how badly SHA-1 might be broken. Current attacks can theoretically generate limited sorts of collisions in (at last report) about 2^64 work. Perhaps this work level will be lowered. Perhaps the limitations on collisions may be reduced. Perhaps even more powerful attacks such as preimage attacks (to find data that matches the hash of a given value) will become possible. - Any hash algorithm might in principle be broken eventually. A spec like OpenPGP can at best allow a choice of hash algorithms. However even then it will be necessary for communicators to decide which hash algorithms they trust. If someone loses confidence in a hash algorithm while others are still using it, interoperability is lost. My approach to these problems is to assume that SHA-1 will be broken to the extent that collisions can be found with moderate effort, even collisions with particular structures. However, preimages will not be possible. I think this is a conservative assumption given what is known about the new attacks. As far as the second issue, I will outline places where we hard-code SHA-1, and we should think about what would be involved in trying to allow for different hash algorithms to be used in place. Here then are the places we hard-code SHA-1 and the security implications. 5.5.3 Secret Key Packet Formats This has the option of using a 20-byte SHA-1 hash as a checksum of the secret key material. This should be safe. 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) This uses the SHA-1 hash of the message as a checksum for integrity. This should be safe. 9.4. Hash Algorithms SHA-1 is the only MUST implement hash algorithm. I would recommend that we include at least SHA-256 as a MUST implement algorithm, for future security. 11.2. Key IDs and Fingerprints A V4 key fingerprint is the SHA-1 hash of the key material. If SHA-1 is broken then it will be possible to create two keys which have the same fingerprint. Any places in the spec where fingerprints are used as pointers to keys, it will be possible for the key creator to substitute another key he created. Likewise, the V4 key ID is a substring of the fingerprint so the same considerations arise. (However, with respect to key IDs it is an old problem, since 64 bit key IDs can be made to collide with only 2^32 work, a very tractable amount.) Places where fingerprints are used: 5.2.3.15. Revocation key The revocation key (designated revoker) is specified via key fingerprint. This should be safe since the key holder is trusted to perform this service, so if he created a key collision he would only be able to transfer this power among keys he controlled. It is not an OpenPGP issue, but PGP uses signature subpacket 10 as an additional decryption key indicator, and this is also done via a key fingerprint. Similar considerations apply as for the designated revoker. With regard to key IDs, these are used in the following places: 5.1. Public-Key Encrypted Session Key Packets (Tag 1) The key ID indicates which key can decrypt the message. Ability to create keys with colliding key IDs should not cause security problems. 5.2.2. Version 3 Signature Packet Format The key ID of the signing key is stored in the V3 signature packet. Ability to create keys with colliding key IDs should not cause security problems. 5.2.3.5. Issuer This is the V4 key ID. Same situation as for V3. In fact we usually put this signature packet in the unhashed region. 5.4. One-Pass Signature Packets (Tag 4) Same situation as above. Summary None of the hard-coded uses of SHA-1 in the OpenPGP spec appear to introduce security problems, even if creating SHA-1 collisions becomes easy. This analysis does not cover the case of finding pre-images. The one change we might consider is to expand the set of MUST algorithms beyond SHA-1 since the community is shifting away from that hash. In the longer term it would be desirable to consider parameterizing the few places where SHA-1 is hard-coded, to take a hash algorithm specifier. This will allow us to avoid even the appearance of weakness which may be of concern to potential users, as SHA-1 becomes deprecated in a wide range of products and protocols in future years. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Sep 15 21:50:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG5N2-0003DY-3F for openpgp-archive@megatron.ietf.org; Thu, 15 Sep 2005 21:50:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA22620 for ; Thu, 15 Sep 2005 21:50:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G1QSqT055353; Thu, 15 Sep 2005 18:26:28 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8G1QSxD055352; Thu, 15 Sep 2005 18:26:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G1QQgG055345 for ; Thu, 15 Sep 2005 18:26:27 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8BD122B47A9; Fri, 16 Sep 2005 03:26:25 +0200 (CEST) Date: Fri, 16 Sep 2005 03:26:25 +0200 To: ietf-openpgp@imc.org Subject: Re: Any SHA-1 dependencies? Message-ID: <20050916012625.GB2627@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal, Basically, what you are proposing is a sort of universal hash function, where the hash algorithm identifier is followed by the hash computed using that particular algorithm. This is potentially very dangerous, as it does not follow several assumptions about a good hash function. Namely the hash value is not unique and parts of the hash function are not uniformly strong. On the other hand, there is a fair chance that SHA1 (and even MD5, though its 128 bit length is a problem by itself) might be fixed. The known collision attacks are based on collisions in the compression function and it seems that in both cases the set of "problematic" blocks is actually very sparse and easily detectable. This allows for several security improvements: first, (and it has already been done, AFAIK) one can immediately detect a data stream as one that is likely to be an attempted attack on the hash function, second, one might create a "fixed" compression function that does something different for problematic blocks, thus yielding a hash function that gives the same output as SHA1 for the vast majority of inputs, while being resistant against SHA1 collisions. The detection result is very likely to be presented at Eurocrypt2006, and there's a chance that the fix will be presented too. The sparsity of problematic blocks also implies (although this is not strictly within the scope of the discussion) that key-id binding signatures might collide only on the key part (*), which is not dangerous. If the above mentioned sanity check is performed, it removes even the non-dangerous key collision as a possibility. Also remember, that collisions are of concern only if the data is to be signed by someone different from its author. There are protocol-level safeguards against this possibility, though employing these would require a major overhaul of OpenPGP, which in the light of the above is not warranted (yet). Someday, however, we might very well be forced to introduce version 5 signatures for certification and other notarial purposes. It is better to postpone that as long as possible, because important discoveries with immediate consequencnes on design and standardization decisions might lay ahead. So, I would recommend sticking to SHA1 for the time being, as there is no hash function with a better design at this point. Alternatives that belong to the same MD4 family of hash functions (e.g. the now-fashionable RIPEMD-160) have not been attacked only because SHA1 was a more rewarding target. Now, moving to 256-bit hash functions in order to have a built-in "safety factor" keeping the hash-function safe even if it's partially broken, seems to be inconsistent with market-economies. In our case it is particularly relevant, because the standard we are designing is not enforced, leaving the choice to the user. The thing is that partially broken security products are a tough sell even if the remaining part is still secure enough. It is pretty clear from your post that you _are_ concerned about this. Let me digress a bit: In the USSR, it was okay to slash development costs by building in safety factors, so that even if the hash function or the block cipher turned out to be weaker than the designers originally thought, they would be still secure enough. Hence the 256-bit key length of the standard soviet block cipher (GOST 28147-89) which also doubles as the compression function of their standard hash function (standardized later as GOST 34.11-94). For government use (**) and for use in a planned economy this was the most rational way of designing the system: quick, cheap and a little dirty. In market economies, this approach won't fly, because as soon as your product is discredited by being partially broken, you will have to switch anyway, so cheap development with safety factors won't save you money in the long run. Hence, it's not a rational approach to cryptographic algorithm design and indeed, we don't see it in successful products in the free market. It is important to emphasize that it is not because your customers are somehow dumber in a market economy but because in addition to your development costs, they also have to bear the cost of choosing the right product for themselves (this cost does not occur in planned economies -- in certain cases, it can be a significant saving), and they are rational about minimizing it by not touching anything that has been discredited in any way -- they simply cannot afford to behave otherwise (in most cases). Back on topic, this is why I would advise against moving to 256-bit hashes based on the MD4 design. Yes, it would add some security against hypotetical ultra-motivated adversaries flush with resources, but you are interested in these not because they are actually threats but because you are catering to paranoid customers. Those would sneer at a partially broken SHA256 just as they sneer at a partially broken SHA1. So, you will have to switch again very soon, without gaining anything from the previous switch. It's not rational behavior, especially in standardization. Thus, my recommendation would be to postpone the discussion until more is known, to avoid swift moves and stick to SHA1 for the time being. Maybe a footnote would be warranted to explain why it's still safe to do things the way we do them. Now, I have a separate set of grievances about the v4 private key packet format and the way v4 key fingerprints are being calculated, but that has very little to do with the recent developments around our once-favorite hash function. In a separate post, I will explain why I would like to introduce a new version of key packets (both public and private), and once we embark on designing new packet formats, we can address the use of hash functions in that context as well, but again, it's a separate topic. (*) It is impossible to trick someone into binding a sane-looking unseen UID to a given public key by presenting him with another sane-looking UID that would collide with the unseen one for signature. (**) There is evidence suggesting that the mentioned algorithms were in government use long before having been released to the public as industry standards. Probably since the early eighties or even earlier. Bests, -- Daniel From owner-ietf-openpgp@mail.imc.org Thu Sep 15 23:03:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG6VR-0004aE-Ky for openpgp-archive@megatron.ietf.org; Thu, 15 Sep 2005 23:03:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05752 for ; Thu, 15 Sep 2005 23:03:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G2Xu0Z061491; Thu, 15 Sep 2005 19:33:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8G2Xumx061490; Thu, 15 Sep 2005 19:33:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G2XtLO061482 for ; Thu, 15 Sep 2005 19:33:55 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 40C3657EF5; Thu, 15 Sep 2005 19:33:25 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Any SHA-1 dependencies? Message-Id: <20050916023325.40C3657EF5@finney.org> Date: Thu, 15 Sep 2005 19:33:25 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > Basically, what you are proposing is a sort of universal hash function, > where the hash algorithm identifier is followed by the hash computed using > that particular algorithm. > > This is potentially very dangerous, as it does not follow several > assumptions about a good hash function. Namely the hash value is not > unique and parts of the hash function are not uniformly strong. I agree that is one way to look at it. In a hypothetical future key fingerprint system, there would be multiple kinds: a SHA-1 fingerprint, a SHA256 fingerprint, a RIPEMD160 fingerprint, and so on. So it is non-unique. The idea is that if SHA-1 or some other hash became broken, the other kinds of fingerprints could be used, without revising the spec. Of course an attacker could replace a fingerprint with one based on an old, weak hash, but it would ultimately be up to the verifier to decide which hashes he would trust. In the event of a break, switching over to a new hash would be a potentially costly operation but it would not require issuing a new spec. I'm not sure what dangers you see over a system which would require changing both implementations and specifications. > On the other hand, there is a fair chance that SHA1 (and even MD5, though > its 128 bit length is a problem by itself) might be fixed. The known > collision attacks are based on collisions in the compression function > and it seems that in both cases the set of "problematic" blocks is actually > very sparse and easily detectable. This allows for several security > improvements: first, (and it has already been done, AFAIK) one can > immediately detect a data stream as one that is likely to be an > attempted attack on the hash function, second, one might create a "fixed" > compression function that does something different for problematic blocks, > thus yielding a hash function that gives the same output as SHA1 for the > vast majority of inputs, while being resistant against SHA1 collisions. > > The detection result is very likely to be presented at Eurocrypt2006, and > there's a chance that the fix will be presented too. I will look forward to seeing that. I wonder if it might be discussed at the NIST Halloween "hash bash", it sounds like it would be of great interest there. Without knowing the details it is hard to comment, but in general I would worry that any detection system might be "brittle" and possibly small changes to the attack method might bypass the detector while still producing collisions (perhaps somewhat more expensively). For example the Wang attacks always use the same initial differential, but there is no reason they could not work with slightly different differentials, I think. She chose the best one but I gather that there are others that weren't too bad. A detection system tuned too closely to known attacks might miss these alternatives. > The sparsity of problematic blocks also implies (although this is not > strictly within the scope of the discussion) that key-id binding signatures > might collide only on the key part (*), which is not dangerous. If the above > mentioned sanity check is performed, it removes even the non-dangerous key > collision as a possibility. I also remember Eli Biham last year at Crypto demonstrating very textual looking collisions on truncated SHA-1. His collisions were composed of ascii characters and even English words. Granted, truncation makes a world of difference in the ease of the attack but I wonder if we can be sure that the full SHA-1 attacks can never be improved in this way. > Also remember, that collisions are of concern only if the data is to be signed by > someone different from its author. There are protocol-level safeguards > against this possibility, though employing these would require a major > overhaul of OpenPGP, which in the light of the above is not warranted (yet). > Someday, however, we might very well be forced to introduce version 5 > signatures for certification and other notarial purposes. It is better to > postpone that as long as possible, because important discoveries with > immediate consequencnes on design and standardization decisions might lay ahead. Yes, there have been strong debates in online forums for example about changing signature procedures so that the signer prepends a block of data of his choice to the message to be signed, in case the message is prepared by someone else. There seems to be no consensus on whether this is on balance a good idea or not. > So, I would recommend sticking to SHA1 for the time being, as there is no > hash function with a better design at this point. Alternatives that belong > to the same MD4 family of hash functions (e.g. the now-fashionable > RIPEMD-160) have not been attacked only because SHA1 was a more rewarding > target. I didn't recommend stopping using SHA-1. In fact my only actual recommendation was to include SHA256 as another MUST hash, in case SHA-1 gets broken more badly (and in the hope that SHA256 will be OK). > Now, moving to 256-bit hash functions in order to have a built-in "safety > factor" keeping the hash-function safe even if it's partially broken, seems > to be inconsistent with market-economies. In our case it is particularly > relevant, because the standard we are designing is not enforced, leaving the > choice to the user. In general, though, it is risky to use non-MUST hashes in your signatures, for interoperability reasons. Of course we have only limited leverage over this via the spec, and as you note the market may force implementations to move to SHA256 regardless of whether it is MUST or not. [Skipping on a bit] > Back on topic, this is why I would advise against moving to 256-bit hashes > based on the MD4 design. Yes, it would add some security against hypotetical > ultra-motivated adversaries flush with resources, but you are interested in > these not because they are actually threats but because you are catering to > paranoid customers. Those would sneer at a partially broken SHA256 just as > they sneer at a partially broken SHA1. So, you will have to switch again > very soon, without gaining anything from the previous switch. It's not > rational behavior, especially in standardization. So, are you predicting that SHA256 will have at least theoretical breaks of its own? The people I have talked to seem quite non-committal about this prospect. No one can rule it out but most people say it should be stronger than SHA-1 and more resistant to this kind of attack. > Thus, my recommendation would be to postpone the discussion until more is > known, to avoid swift moves and stick to SHA1 for the time being. Maybe a > footnote would be warranted to explain why it's still safe to do things the > way we do them. Again, the only thing I recommended was to add SHA256 as a MUST. The only MUST-implement hash we have now is SHA-1. What do you think of that change? > Now, I have a separate set of grievances about the v4 private key packet format > and the way v4 key fingerprints are being calculated, but that has very > little to do with the recent developments around our once-favorite hash > function. In a separate post, I will explain why I would like to introduce a > new version of key packets (both public and private), and once we embark on > designing new packet formats, we can address the use of hash functions in > that context as well, but again, it's a separate topic. I have another change to suggest as well, which will also go into a future message. Thanks for your comments, they are very interesting and helpful. Hal Finney From owner-ietf-openpgp@mail.imc.org Fri Sep 16 19:00:05 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGPBd-0000ZA-9w for openpgp-archive@megatron.ietf.org; Fri, 16 Sep 2005 19:00:05 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25421 for ; Fri, 16 Sep 2005 19:00:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8GMffid002923; Fri, 16 Sep 2005 15:41:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8GMff3k002922; Fri, 16 Sep 2005 15:41:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8GMfeFh002916 for ; Fri, 16 Sep 2005 15:41:40 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 6004C57EF5; Fri, 16 Sep 2005 15:41:13 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Bigger DSA keys Message-Id: <20050916224113.6004C57EF5@finney.org> Date: Fri, 16 Sep 2005 15:41:13 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have it on good authority that NIST will be announcing larger size DSS keys soon. According to my source, the date will be by the end of October. Currently, DSS keys have two problems. First, they can be no bigger than 1024 bits. Recent results show that keys of this size can no longer be considered safe from large scale attackers. See for example http://lists.virus.org/cryptography-0509/msg00080.html (although this is for RSA keys, DSS keys of a similar size are not thought to be too much more difficult). Second, DSS keys are locked into using SHA-1, for which attacks have been published. The new DSS keys will, according to what I have heard, be for two sizes: 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. (SHA-224 is not presently an OpenPGP algorithm; it is basically a truncated version of SHA-256 with a different internal initial value). This will allow for larger keys and use a different hash than SHA-1. If this report is correct, it would be good to see these new key sizes in RFC2440bis. Otherwise the DSS support in the spec will be essentially "dead on arrival". Rather than publishing a spec with a major class of keys that has no future utility, I think it makes sense to wait six weeks and see if we can incorporate the new information, making the spec much more robust and long-lasting. For those who say we have waited too long already, I will just note that the weeks and months drift by without much reason for delay but without much progress either. Now that there is a good reason to hold off a bit more, I would hate to see us suddenly rush to close the door. One issue is how best to incorporate these new key sizes. As I see it, there are three alternatives. 1. Just use the new sizes with the existing DSA keys. Instead of only 512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the proper hash algorithms in software. 2. Use a new algorithm ID for the new DSA keys, which would be only for 2048 and 3072 bits. The old algorithm ID would continue to be used for old DSA keys. 3. Use a new key packet version number for the new DSA keys, V5. Perhaps V5 keys could use a SHA-256 based fingerprint. This would represent a clean break from the old way. The first alternative would involve the least change to the spec, just changes to the information about how to sign and verify with DSA keys. The second alternative would require adding much the same material but with the handling of the new algorithm ID called out separately. It would probably duplicate some of the information on old-style DSA keys. The third alternative is the most ambitious and is not feasible for RFC2440bis IMO. We could still go to a V5 key packet at some point in the future anyway, and perhaps do other improvements at that time. Between the first two, I would propose to decide largely on the basis of backwards compatibility. Obviously signatures made with new-style DSA keys will not be verifiable in old code. The question is how gracefully existing implementations will fail when presented with such keys and signatures, in either the first or second form. Testing on current implementations could provide guidance as to which way of making the change will cause the least trouble. Hal Finney From owner-ietf-openpgp@mail.imc.org Sat Sep 17 18:09:04 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGkro-0006N1-Co for openpgp-archive@megatron.ietf.org; Sat, 17 Sep 2005 18:09:04 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06159 for ; Sat, 17 Sep 2005 18:09:01 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8HLm4hH030086; Sat, 17 Sep 2005 14:48:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8HLm4Zu030085; Sat, 17 Sep 2005 14:48:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8HLm3Qi030076 for ; Sat, 17 Sep 2005 14:48:03 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id E0FD9415F0; Sat, 17 Sep 2005 22:48:01 +0100 (BST) Message-ID: <432CAAC9.2050305@systemics.com> Date: Sun, 18 Sep 2005 00:46:17 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> In-Reply-To: <20050916224113.6004C57EF5@finney.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hal Finney wrote: > The new DSS keys will, according to what I have heard, be for two sizes: > 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. > (SHA-224 is not presently an OpenPGP algorithm; it is basically a > truncated version of SHA-256 with a different internal initial value). > This will allow for larger keys and use a different hash than SHA-1. (assuming we do it,) I would suggest we ditch the 2048/224 and just implement the 3072/256. (We could add the other one as a MAY ... but I can't see the point of it. Sure NIST may split hairs on it, but let's save ourselves the doco and the discussion and just do the better one.) > If this report is correct, it would be good to see these new key sizes > in RFC2440bis. Otherwise the DSS support in the spec will be essentially > "dead on arrival". Rather than publishing a spec with a major class > of keys that has no future utility, I think it makes sense to wait six > weeks and see if we can incorporate the new information, making the > spec much more robust and long-lasting. I don't think it is that easy. SHAs are under a cloud, and until we get some more definitive info on the new hardware factoring, even the numbers suggested above won't satisfy all the extremists. Consider that the extreme community considers 4096 to be a minimum, and all the news is supporting them at the moment; also, NIST's hash work has been controversial (SHA0, SHA2 being just an "extension" ...), I'd like to see what the crypto community comes up with in hash research as that feeds into DSS. Which rambling means to say that even after the October date, I suspect it will be all too easy to say "let's wait a bit more..." > For those who say we have waited too long already, I will just note that > the weeks and months drift by without much reason for delay but without > much progress either. Now that there is a good reason to hold off a > bit more, I would hate to see us suddenly rush to close the door. > > One issue is how best to incorporate these new key sizes. As I see it, > there are three alternatives. > > 1. Just use the new sizes with the existing DSA keys. Instead of only > 512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the > proper hash algorithms in software. > > 2. Use a new algorithm ID for the new DSA keys, which would be only > for 2048 and 3072 bits. The old algorithm ID would continue to be > used for old DSA keys. I think I'd lean towards this one. This would allow us to deprecate DSA-old just as soon as we can. > 3. Use a new key packet version number for the new DSA keys, V5. > Perhaps V5 keys could use a SHA-256 based fingerprint. This would > represent a clean break from the old way. I'd go against this (for the same reason you outline below). > The first alternative would involve the least change to the spec, just > changes to the information about how to sign and verify with DSA keys. > The second alternative would require adding much the same material > but with the handling of the new algorithm ID called out separately. > It would probably duplicate some of the information on old-style DSA keys. Ah, good point. But unless by some miracle all the implementations can handle #1 without blowing up, then I can't see how we'd countenance an incompatible change? > The third alternative is the most ambitious and is not feasible for > RFC2440bis IMO. We could still go to a V5 key packet at some point in > the future anyway, and perhaps do other improvements at that time. Right. > Between the first two, I would propose to decide largely on the basis of > backwards compatibility. Obviously signatures made with new-style DSA > keys will not be verifiable in old code. The question is how gracefully > existing implementations will fail when presented with such keys and > signatures, in either the first or second form. Testing on current > implementations could provide guidance as to which way of making the > change will cause the least trouble. Certainly interesting times for DSS fans. I use it in a lot of my stuff and have pretty much made up my mind to move to RSA when and as I can. Mostly this is because NIST have moved too little, too late on this one, and the numbers above are already looking like we'll be into a change again in about 2-3 years when the new Hash research settles into a new generation of algorithms. iang From owner-ietf-openpgp@mail.imc.org Sat Sep 17 20:30:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGn4p-0004IL-TP for openpgp-archive@megatron.ietf.org; Sat, 17 Sep 2005 20:30:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11422 for ; Sat, 17 Sep 2005 20:30:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8I0DSDm042721; Sat, 17 Sep 2005 17:13:28 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8I0DSwB042720; Sat, 17 Sep 2005 17:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8I0DR9C042713 for ; Sat, 17 Sep 2005 17:13:27 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 96B4F57EF5; Sat, 17 Sep 2005 17:13:03 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-Id: <20050918001303.96B4F57EF5@finney.org> Date: Sat, 17 Sep 2005 17:13:03 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian Grigg writes: > (assuming we do it,) I would suggest we ditch the 2048/224 > and just implement the 3072/256. > > (We could add the other one as a MAY ... but I can't see > the point of it. Sure NIST may split hairs on it, but > let's save ourselves the doco and the discussion and > just do the better one.) > ... > I don't think it is that easy. SHAs are under a cloud, > and until we get some more definitive info on the new > hardware factoring, even the numbers suggested above > won't satisfy all the extremists. Consider that the > extreme community considers 4096 to be a minimum, and > all the news is supporting them at the moment; also, > NIST's hash work has been controversial (SHA0, SHA2 > being just an "extension" ...), I'd like to see what > the crypto community comes up with in hash research as > that feeds into DSS. I'm not sure why there is not a plan for larger key sizes. A possible clue is in this NIST document, "Recommendation for Key Management", http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf . Table 2 on page 63 shows the following correspondences between hash size and modulus size: 160/1024; 224/2048; 256/3072; 384/7680; and 512/15360. This fits what we know, with SHA-1 and a 1024 bit modulus as the traditional DSS; SHA-224 and a 2048 bit modulus, and SHA-256 and a 3072 bit modulus in this new DSS that I have been told about. It implies that the natural next size would be SHA-384 and a 7680 bit modulus. But that modulus is too big for most people's convenience. You might say, just use SHA-384 and a 4096 bit modulus, but that is not such a nice fit. The hash is a lot stronger than the modulus and so it is not well balanced. Perhaps such esthetic considerations motivated NIST's decision. Hal Finney From owner-ietf-openpgp@mail.imc.org Sun Sep 18 07:45:08 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGxbY-0006xv-GU for openpgp-archive@megatron.ietf.org; Sun, 18 Sep 2005 07:45:08 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19071 for ; Sun, 18 Sep 2005 07:45:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IBRNYt094610; Sun, 18 Sep 2005 04:27:23 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IBRNTa094609; Sun, 18 Sep 2005 04:27:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IBRIuw094600 for ; Sun, 18 Sep 2005 04:27:21 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 49B8933C1A; Sun, 18 Sep 2005 12:27:13 +0100 (BST) Message-ID: <432D4F13.6080703@algroup.co.uk> Date: Sun, 18 Sep 2005 12:27:15 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian G CC: Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> In-Reply-To: <432CAAC9.2050305@systemics.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian G wrote: > Hal Finney wrote: >> The new DSS keys will, according to what I have heard, be for two sizes: >> 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. >> (SHA-224 is not presently an OpenPGP algorithm; it is basically a >> truncated version of SHA-256 with a different internal initial value). >> This will allow for larger keys and use a different hash than SHA-1. > > (assuming we do it,) I would suggest we ditch the 2048/224 > and just implement the 3072/256. > > (We could add the other one as a MAY ... but I can't see > the point of it. Sure NIST may split hairs on it, but > let's save ourselves the doco and the discussion and > just do the better one.) How about because generating 2048 bit primes already takes long enough, and 3072 takes ages? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Sun Sep 18 08:11:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGy1P-00038C-Ce for openpgp-archive@megatron.ietf.org; Sun, 18 Sep 2005 08:11:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20600 for ; Sun, 18 Sep 2005 08:11:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IBsf5Z096360; Sun, 18 Sep 2005 04:54:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IBsfD8096359; Sun, 18 Sep 2005 04:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IBseow096352 for ; Sun, 18 Sep 2005 04:54:40 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id F2400417BB; Sun, 18 Sep 2005 12:54:29 +0100 (BST) Message-ID: <432D712D.4060502@systemics.com> Date: Sun, 18 Sep 2005 14:52:45 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> <432D4F13.6080703@algroup.co.uk> In-Reply-To: <432D4F13.6080703@algroup.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ben Laurie wrote: > Ian G wrote: > >> Hal Finney wrote: >> >>> The new DSS keys will, according to what I have heard, be for two sizes: >>> 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. >>> (SHA-224 is not presently an OpenPGP algorithm; it is basically a >>> truncated version of SHA-256 with a different internal initial value). >>> This will allow for larger keys and use a different hash than SHA-1. >> >> >> (assuming we do it,) I would suggest we ditch the 2048/224 >> and just implement the 3072/256. >> >> (We could add the other one as a MAY ... but I can't see >> the point of it. Sure NIST may split hairs on it, but >> let's save ourselves the doco and the discussion and >> just do the better one.) > > > How about because generating 2048 bit primes already takes long enough, > and 3072 takes ages? Numbers? iang From owner-ietf-openpgp@mail.imc.org Sun Sep 18 08:28:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGyHi-0005sI-5R for openpgp-archive@megatron.ietf.org; Sun, 18 Sep 2005 08:28:42 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21351 for ; Sun, 18 Sep 2005 08:28:40 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8ICAbK5097176; Sun, 18 Sep 2005 05:10:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8ICAbLd097175; Sun, 18 Sep 2005 05:10:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8ICAXw0097165 for ; Sun, 18 Sep 2005 05:10:35 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2D08933C1A; Sun, 18 Sep 2005 13:10:28 +0100 (BST) Message-ID: <432D5936.5020701@algroup.co.uk> Date: Sun, 18 Sep 2005 13:10:30 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian G CC: Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> <432D4F13.6080703@algroup.co.uk> <432D712D.4060502@systemics.com> In-Reply-To: <432D712D.4060502@systemics.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian G wrote: > Ben Laurie wrote: > >> Ian G wrote: >> >>> Hal Finney wrote: >>> >>>> The new DSS keys will, according to what I have heard, be for two >>>> sizes: >>>> 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. >>>> (SHA-224 is not presently an OpenPGP algorithm; it is basically a >>>> truncated version of SHA-256 with a different internal initial value). >>>> This will allow for larger keys and use a different hash than SHA-1. >>> >>> >>> >>> (assuming we do it,) I would suggest we ditch the 2048/224 >>> and just implement the 3072/256. >>> >>> (We could add the other one as a MAY ... but I can't see >>> the point of it. Sure NIST may split hairs on it, but >>> let's save ourselves the doco and the discussion and >>> just do the better one.) >> >> >> >> How about because generating 2048 bit primes already takes long >> enough, and 3072 takes ages? > > > Numbers? I was going to provide them, but accurate numbers for DSA is difficult, because it requires modifying the core code in OpenSSL (or some other DSA generator), and I couldn't be bothered. One can get a feel for it with: time openssl gendh which takes a long time. Long enough that I didn't wait for it to finish before hitting send. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Sun Sep 18 08:56:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGyiE-0001Mm-QF for openpgp-archive@megatron.ietf.org; Sun, 18 Sep 2005 08:56:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22125 for ; Sun, 18 Sep 2005 08:56:05 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8ICYgqv098612; Sun, 18 Sep 2005 05:34:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8ICYgGf098611; Sun, 18 Sep 2005 05:34:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8ICYfci098604 for ; Sun, 18 Sep 2005 05:34:41 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 127E82B4812; Sun, 18 Sep 2005 14:34:40 +0200 (CEST) Date: Sun, 18 Sep 2005 14:34:39 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050918123430.GB6483@epointsystem.org> References: <20050918001303.96B4F57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050918001303.96B4F57EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's important to keep in mind that DSS-style signatures are twice the hash size. This is one of their nicest features; they do not grow with the modulus. A signature of a 3072/256 key will be 512 bits (plus overhead). As for generating long modulae, it's not that big a problem, altough it has to be noted that generating a modulus for DSA takes more than just generating a prime that big; DSA moduli p are such that p-1 is divisible by some large (hash-sized) q. The generation of such moduli takes substantially longer than generating primes. For 3072/256 on a 500MHz intel, it would take approx. three minutes, provided that the random stream is available without waiting. On the other hand, the overwhelming majority of DSS implementations use pre-calculated moduli, as there are no security hazards associated with using a common modulus for DSS. When keys need to be generated frequently, a pre-calculated modulus is the way to go. If one just needs to generate a personal signature key for the next five years, one can wait three minutes, in case they want to show off a self-generated modulus. -- Daniel From owner-ietf-openpgp@mail.imc.org Sun Sep 18 09:03:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGypr-0002Zf-DW for openpgp-archive@megatron.ietf.org; Sun, 18 Sep 2005 09:03:59 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22461 for ; Sun, 18 Sep 2005 09:03:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IClk7h099402; Sun, 18 Sep 2005 05:47:46 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IClkXF099401; Sun, 18 Sep 2005 05:47:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IClj9b099395 for ; Sun, 18 Sep 2005 05:47:46 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 57D8B2B47D5; Sun, 18 Sep 2005 14:47:38 +0200 (CEST) Date: Sun, 18 Sep 2005 14:47:38 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050918124733.GC6483@epointsystem.org> References: <20050916224113.6004C57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050916224113.6004C57EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 16, 2005 at 03:41:13PM -0700, "Hal Finney" wrote: > The new DSS keys will, according to what I have heard, be for two sizes: > 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. > (SHA-224 is not presently an OpenPGP algorithm; it is basically a > truncated version of SHA-256 with a different internal initial value). > This will allow for larger keys and use a different hash than SHA-1. For this reason, I'd agree with Ian and just ignore the 2048/224 key specification. Too much trouble for no gain. > 1. Just use the new sizes with the existing DSA keys. Instead of only > 512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the > proper hash algorithms in software. I like this solution. If old implementations do not do very silly things when encountering such signatures (e.g. claiming them to be bad signatures as opposed to unverifiable), it is the cleanest way to go about it. > 2. Use a new algorithm ID for the new DSA keys, which would be only > for 2048 and 3072 bits. The old algorithm ID would continue to be > used for old DSA keys. This approach would eat up the algorithm identifier space and provide very little advantage. It is reasonable to expect new DSS key specifications every decade, if NIST continues its current practices. > 3. Use a new key packet version number for the new DSA keys, V5. > Perhaps V5 keys could use a SHA-256 based fingerprint. This would > represent a clean break from the old way. Let's wait with that. There are several problems with the v4 key formats and using SHA-256 for fingerprinting is not necessarily a good idea, given that its design is quickly becoming obsolete. > Between the first two, I would propose to decide largely on the basis of > backwards compatibility. Obviously signatures made with new-style DSA > keys will not be verifiable in old code. The question is how gracefully > existing implementations will fail when presented with such keys and > signatures, in either the first or second form. Testing on current > implementations could provide guidance as to which way of making the > change will cause the least trouble. That's a very reasonable suggestion. -- Daniel From owner-ietf-openpgp@mail.imc.org Mon Sep 19 04:58:41 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHHTy-00067O-M6 for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 04:58:41 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06923 for ; Mon, 19 Sep 2005 04:58:35 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J8aYDC009527; Mon, 19 Sep 2005 01:36:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8J8aYgh009526; Mon, 19 Sep 2005 01:36:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J8aW20009471 for ; Mon, 19 Sep 2005 01:36:32 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHHEq-0001XX-ST for ; Mon, 19 Sep 2005 10:43:00 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHH4b-00055q-IL; Mon, 19 Sep 2005 10:32:25 +0200 To: Ian G Cc: Ben Laurie , Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> <432D4F13.6080703@algroup.co.uk> <432D712D.4060502@systemics.com> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 19 Sep 2005 10:32:25 +0200 In-Reply-To: <432D712D.4060502@systemics.com> (Ian G.'s message of "Sun, 18 Sep 2005 14:52:45 +0100") Message-ID: <871x3l790m.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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 Sun, 18 Sep 2005 14:52:45 +0100, Ian G said: >> How about because generating 2048 bit primes already takes long >> enough, and 3072 takes ages? > Numbers? A quick test shows about 4 seconds for 2048 bit and 21 seconds for 3072. However this includes the time required to gather enough randomness; further tests took much longer very likely due to a lack of entropy in the machine. Most applications don't need to generate keys very ofthen, thus this should not be a problem. OTOH, verification is used very often. Here are number from Libgcrypt: DSA 100 times sign verify ----------------------------- DSA 1024/160 910ms 430ms DSA 2048/224 1560ms 1890ms DSA 3072/256 3610ms 4380ms (The numbers for sign are not very reliable because it employs the RNG and I could not adjust for it) 3072 takes more more than double the time of 2048 which is not too bad. Compared to 1024 this is a real slowdown and would make key signature verification a very time consuming operation. On slow machines (embedded devices, older hardware) this would be very annoying. Shalom-Salam, Werner From owner-ietf-openpgp@mail.imc.org Mon Sep 19 09:21:54 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLak-0000zx-Of for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 09:21:54 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20465 for ; Mon, 19 Sep 2005 09:21:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JD1i44008974; Mon, 19 Sep 2005 06:01:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JD1ii7008973; Mon, 19 Sep 2005 06:01:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JD1irS008956 for ; Mon, 19 Sep 2005 06:01:44 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <2005091913013801200qnirre>; Mon, 19 Sep 2005 13:01:38 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8JD1g0m009958 for ; Mon, 19 Sep 2005 09:01:42 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8JD1bFw011779 for ; Mon, 19 Sep 2005 09:01:37 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8JD1bJ3011778 for ietf-openpgp@imc.org; Mon, 19 Sep 2005 09:01:37 -0400 Date: Mon, 19 Sep 2005 09:01:37 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050919130136.GF9545@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050916224113.6004C57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050916224113.6004C57EF5@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 16, 2005 at 03:41:13PM -0700, "Hal Finney" wrote: > One issue is how best to incorporate these new key sizes. As I see it, > there are three alternatives. > > 1. Just use the new sizes with the existing DSA keys. Instead of only > 512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the > proper hash algorithms in software. > > 2. Use a new algorithm ID for the new DSA keys, which would be only > for 2048 and 3072 bits. The old algorithm ID would continue to be > used for old DSA keys. > > 3. Use a new key packet version number for the new DSA keys, V5. > Perhaps V5 keys could use a SHA-256 based fingerprint. This would > represent a clean break from the old way. > > The first alternative would involve the least change to the spec, just > changes to the information about how to sign and verify with DSA keys. > The second alternative would require adding much the same material > but with the handling of the new algorithm ID called out separately. > It would probably duplicate some of the information on old-style DSA keys. > > The third alternative is the most ambitious and is not feasible for > RFC2440bis IMO. We could still go to a V5 key packet at some point in > the future anyway, and perhaps do other improvements at that time. I am a big fan of V5 keys (see http://www.imc.org/ietf-openpgp/mail-archive/msg09274.html), and I love the clean break, but I feel that if the new DSA was tied to V5 then discussions and design for a good V5 key format would delay availability of the new DSA in the field for an excessively long amount of time. People have been asking for a better DSA for a long time now, so it seems a shame to delay it further. I'm all for planning V5 of course, just not tied to the new DSA. > Between the first two, I would propose to decide largely on the basis of > backwards compatibility. Obviously signatures made with new-style DSA > keys will not be verifiable in old code. The question is how gracefully > existing implementations will fail when presented with such keys and > signatures, in either the first or second form. Testing on current > implementations could provide guidance as to which way of making the > change will cause the least trouble. Presuming that the size of q will change from 160 to 224 or 256 in the new key, importing a DSA key to GnuPG with the current algorithm number and a q that is not 160 bits or importing a new-style DSA key with a new algorithm number fails more or less gracefully in either case. So at least from the graceful failure perspective in GnuPG, it doesn't really matter much which way we go. I prefer the first option (using the current algorithm number) since it seems cleanest in both code and standard. David From owner-ietf-openpgp@mail.imc.org Mon Sep 19 11:11:07 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNIR-0002zw-8j for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:11:07 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00381 for ; Mon, 19 Sep 2005 11:10:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JEpW9r017208; Mon, 19 Sep 2005 07:51:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JEpWTZ017207; Mon, 19 Sep 2005 07:51:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JEpVXl017199 for ; Mon, 19 Sep 2005 07:51:32 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHN5l-0003Hw-32 for ; Mon, 19 Sep 2005 16:58:01 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHMtf-0005cI-Im for ; Mon, 19 Sep 2005 16:45:31 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <20050919130136.GF9545@jabberwocky.com> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 19 Sep 2005 16:45:31 +0200 In-Reply-To: <20050919130136.GF9545@jabberwocky.com> (David Shaw's message of "Mon, 19 Sep 2005 09:01:37 -0400") Message-ID: <8764sx3ylw.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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 Sep 2005 09:01:37 -0400, David Shaw said: > So at least from the graceful failure perspective in GnuPG, it doesn't > really matter much which way we go. I prefer the first option (using > the current algorithm number) since it seems cleanest in both code and However this does also means that another hash algorithm needs to be a MUST algorithm - unless we limit the MUST support for DSA to 1024 bits keys. The need for another algorithm makes a big difference for emdedded applications. Ofen the threat model does not require high budget spook proof algorithms. Shalom-Salam, Werner From owner-ietf-openpgp@mail.imc.org Mon Sep 19 11:38:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNin-00078W-Fn for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 11:38:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03582 for ; Mon, 19 Sep 2005 11:38:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JF8IFj019207; Mon, 19 Sep 2005 08:08:18 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JF8Ixt019206; Mon, 19 Sep 2005 08:08:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JF8HKf019195 for ; Mon, 19 Sep 2005 08:08:18 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <2005091915080801300ab7qke>; Mon, 19 Sep 2005 15:08:12 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8JF8D0m010531 for ; Mon, 19 Sep 2005 11:08:13 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8JF87vT012077 for ; Mon, 19 Sep 2005 11:08:07 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8JF87VV012076 for ietf-openpgp@imc.org; Mon, 19 Sep 2005 11:08:07 -0400 Date: Mon, 19 Sep 2005 11:08:07 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050919150807.GC12013@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050916224113.6004C57EF5@finney.org> <20050919130136.GF9545@jabberwocky.com> <8764sx3ylw.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8764sx3ylw.fsf@wheatstone.g10code.de> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 19, 2005 at 04:45:31PM +0200, Werner Koch wrote: > > On Mon, 19 Sep 2005 09:01:37 -0400, David Shaw said: > > > So at least from the graceful failure perspective in GnuPG, it doesn't > > really matter much which way we go. I prefer the first option (using > > the current algorithm number) since it seems cleanest in both code and > > However this does also means that another hash algorithm needs to be a > MUST algorithm - unless we limit the MUST support for DSA to 1024 bits > keys. Yes. I'm not against limiting the MUST support to 1024/160 DSA. David From owner-ietf-openpgp@mail.imc.org Mon Sep 19 13:58:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPuB-0002kY-CT for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 13:58:15 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10666 for ; Mon, 19 Sep 2005 13:58:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHbM59035140; Mon, 19 Sep 2005 10:37:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JHbMTY035139; Mon, 19 Sep 2005 10:37:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHbL0u035131 for ; Mon, 19 Sep 2005 10:37:21 -0700 (PDT) (envelope-from nagydani@epointsystem.org) From: nagydani@epointsystem.org Received: by mail.epointsystem.org (Postfix, from userid 1001) id 3FD952B480E; Mon, 19 Sep 2005 19:37:18 +0200 (CEST) Date: Mon, 19 Sep 2005 19:34:20 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050919173420.GA26064@epointsystem.org> References: <20050916224113.6004C57EF5@finney.org> <20050919130136.GF9545@jabberwocky.com> <8764sx3ylw.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8764sx3ylw.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 19, 2005 at 04:45:31PM +0200, Werner Koch wrote: > > On Mon, 19 Sep 2005 09:01:37 -0400, David Shaw said: > > > So at least from the graceful failure perspective in GnuPG, it doesn't > > really matter much which way we go. I prefer the first option (using > > the current algorithm number) since it seems cleanest in both code and > > However this does also means that another hash algorithm needs to be a > MUST algorithm - unless we limit the MUST support for DSA to 1024 bits > keys. > > The need for another algorithm makes a big difference for emdedded > applications. Ofen the threat model does not require > high budget spook proof algorithms. I fully agree with that. I would limit the MUST support to plain old SHA1 and 1024bit DSA for the time being. -- Daniel From owner-ietf-openpgp@mail.imc.org Mon Sep 19 13:58:16 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPuC-0002lQ-OW for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 13:58:16 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10667 for ; Mon, 19 Sep 2005 13:58:13 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHZL7X035009; Mon, 19 Sep 2005 10:35:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JHZLbQ035008; Mon, 19 Sep 2005 10:35:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHZJjP035001 for ; Mon, 19 Sep 2005 10:35:20 -0700 (PDT) (envelope-from nagydani@epointsystem.org) From: nagydani@epointsystem.org Received: by mail.epointsystem.org (Postfix, from userid 1001) id 513052B4810; Mon, 19 Sep 2005 19:35:18 +0200 (CEST) Date: Mon, 19 Sep 2005 19:34:20 +0200 To: Werner Koch Subject: Re: Bigger DSA keys Message-ID: <20050919173420.GA26064@epointsystem.org> References: <20050916224113.6004C57EF5@finney.org> <20050919130136.GF9545@jabberwocky.com> <8764sx3ylw.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8764sx3ylw.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 19, 2005 at 04:45:31PM +0200, Werner Koch wrote: > > On Mon, 19 Sep 2005 09:01:37 -0400, David Shaw said: > > > So at least from the graceful failure perspective in GnuPG, it doesn't > > really matter much which way we go. I prefer the first option (using > > the current algorithm number) since it seems cleanest in both code and > > However this does also means that another hash algorithm needs to be a > MUST algorithm - unless we limit the MUST support for DSA to 1024 bits > keys. > > The need for another algorithm makes a big difference for emdedded > applications. Ofen the threat model does not require > high budget spook proof algorithms. I fully agree with that. I would limit the MUST support to plain old SHA1 and 1024bit DSA for the time being. -- Daniel From owner-ietf-openpgp@mail.imc.org Mon Sep 19 15:30:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHRLk-0002Cv-4a for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 15:30:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18218 for ; Mon, 19 Sep 2005 15:30:45 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHxx0N037066; Mon, 19 Sep 2005 10:59:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JHxxa5037065; Mon, 19 Sep 2005 10:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHxwsm037059 for ; Mon, 19 Sep 2005 10:59:58 -0700 (PDT) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Mon, 19 Sep 2005 10:59:57 -0700 Received: from [10.240.12.188] ([208.54.15.1]) by keys.merrymeet.com (PGP Universal service); Mon, 19 Sep 2005 10:59:57 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 19 Sep 2005 10:59:57 -0700 In-Reply-To: <20050916224113.6004C57EF5@finney.org> References: <20050916224113.6004C57EF5@finney.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3253EF24-1377-43A1-A348-9AB7872A5658@callas.org> Cc: ietf-openpgp@imc.org Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Bigger DSA keys Date: Mon, 19 Sep 2005 10:59:54 -0700 To: Hal Finney X-Mailer: Apple Mail (2.734) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 16 Sep 2005, at 3:41 PM, Hal Finney wrote: > > I have it on good authority that NIST will be announcing larger size > DSS keys soon. According to my source, the date will be by the end > of October. > We've been waiting for this for years. I think it's important enough to warrant a change in last call for. Jon From owner-ietf-openpgp@mail.imc.org Mon Sep 19 20:54:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHWOf-000782-Mo for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 20:54:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11694 for ; Mon, 19 Sep 2005 20:54:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K0UfPI069344; Mon, 19 Sep 2005 17:30:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K0Uf3W069343; Mon, 19 Sep 2005 17:30:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K0Uf9R069337 for ; Mon, 19 Sep 2005 17:30:41 -0700 (PDT) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for ; Mon, 19 Sep 2005 17:30:40 -0700 Received: from [172.16.1.2] ([72.254.169.116]) by keys.merrymeet.com (PGP Universal service); Mon, 19 Sep 2005 17:30:40 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 19 Sep 2005 17:30:40 -0700 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: OpenPGP From: Jon Callas Subject: Interop grill-off Date: Mon, 19 Sep 2005 14:05:19 -0700 X-Mailer: Apple Mail (2.734) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I think it would be good for us to have some sort of interoperability test and event. Putting on my PGP Corporation hat, I'm happy to sponsor it. However, it doesn't *have* to be a physical event. Does anyone else think it would be a good idea? Does anyone want to help put it on, come up with test cases, that sort of thing? Jon From owner-ietf-openpgp@mail.imc.org Mon Sep 19 22:14:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHXeZ-0004PX-Rq for openpgp-archive@megatron.ietf.org; Mon, 19 Sep 2005 22:14:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15069 for ; Mon, 19 Sep 2005 22:14:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K1ijx0076488; Mon, 19 Sep 2005 18:44:45 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K1ijaY076487; Mon, 19 Sep 2005 18:44:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K1ii71076478 for ; Mon, 19 Sep 2005 18:44:44 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2762157EF5; Mon, 19 Sep 2005 18:44:29 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-Id: <20050920014429.2762157EF5@finney.org> Date: Mon, 19 Sep 2005 18:44:29 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As far as the issue of generating large DSA keys, a good algorithm to use is the following. First generate an appropriately sized subgroup prime q (160, 224, or 256 bits respectively). Then search for a prime modulus p of the required size (1024, 2048 or 3072 bits) such that p is one more than a multiple of q. The trick is to make that second search fast. Typically a fast prime search is done in two phases: first sieving out multiples of small primes to identify prime candidates, then a slower probabilistic primality test to find a good prime. The key for DSA keys is that sieving can still be used even when looking for primes which are of the form qk+1. Usually when sieving is done, the method already takes into consideration that the prime must be odd. So it already adjusts for the fact that the number is of the form 2k+1. The same basic approach works for primes of the form qk+1 as well. Since q is relatively prime to all of the primes being sieved by, for a prime "j" we will eliminate every jth item. The only question is where is the starting point for eliminating such items in the sieve. This comes down to computing q mod j. Doing this one extra step for each prime j being sieved by, allows the basic sieve concept to still be used. This method allows DSA primes to be found about as quickly as ordinary primes of the same size. The extra time to find the q prime is small, and the sieve can run about as fast. So generating such large primes is not particularly costly or difficult. In contrast, finding "strong" primes p such that (p-1)/2 is also prime does tend to be slow. I think there is a trick to do it using a double sieve but it is still much slower than finding regular primes. DSA primes do not suffer from this deficiency. Hal From owner-ietf-openpgp@mail.imc.org Tue Sep 20 01:45:59 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHax5-00081a-Bv for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 01:45:59 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24181 for ; Tue, 20 Sep 2005 01:45:57 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K5Wcte097177; Mon, 19 Sep 2005 22:32:38 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K5WcRp097176; Mon, 19 Sep 2005 22:32:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K5Wbeb097169 for ; Mon, 19 Sep 2005 22:32:38 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 68D102B47DD; Tue, 20 Sep 2005 07:32:31 +0200 (CEST) Date: Tue, 20 Sep 2005 07:32:31 +0200 To: ietf-openpgp@imc.org Subject: Problems with v4 key packet format Message-ID: <20050920053207.GA5245@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In order to design a successor to v4 key packet format, it is important to first identify its shortcomings. Here's a list of my problems with it: 1. No cryptographic binding between the encrypted private key material and the public key material. This results in a serious security issue, by allowing an attacker to replace the public material thus compromising the private material with the first use in the signature. There are various stop-gap measures to deal with this attack, but the only sure protetction would be some MDC binding together the private and the public key material. 2. No explicit count of MPIs constituting the key material (both public and private). This information can only be inferred from the algorithm specifier, meaning that any implementation that wants to perform key management must have some rudimentary knowledge about all public key algorithms. This, in turn, hampers forward-compatibility. 3. Key fingerprint depends on data unrelated to the actual key (namely: creation date). This prevents solutions when signature keys are generated on the fly (e.g. directly from a passphrase), as the key creation (or, in this case, key registration) date is not available at the time of signing, thus making it impossible to put am unambiguous reference to the public key into the signature. 4. More generally, creation time does not belong to the key packet. Because it is just an attribute of the key as any other, thus belonging to certificatiton signature sub-packets, rather than the key packet. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 03:16:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHcN2-0006bI-NP for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 03:16:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA12480 for ; Tue, 20 Sep 2005 03:16:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K6rmRk006714; Mon, 19 Sep 2005 23:53:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K6rmoK006713; Mon, 19 Sep 2005 23:53:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K6rlx3006704 for ; Mon, 19 Sep 2005 23:53:47 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8F2D02B47EE; Tue, 20 Sep 2005 08:53:46 +0200 (CEST) Date: Tue, 20 Sep 2005 08:53:46 +0200 To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920065346.GA21364@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 19, 2005 at 02:05:19PM -0700, Jon Callas wrote: > I think it would be good for us to have some sort of interoperability > test and event. Putting on my PGP Corporation hat, I'm happy to > sponsor it. However, it doesn't *have* to be a physical event. Does > anyone else think it would be a good idea? Does anyone want to help > put it on, come up with test cases, that sort of thing? How about simply posting test cases with descriptions here, and testing on various OpenPGP implementations, also posting the results to the mailing list. Then you (or someone else) could post a summary here and/or to some webpage. I'm also wondering what are you more after: unusual data conforming to RFC2400 (or RFC2440bis) or slight (but logical) deviations, extensions? I guess, many of us have already identified interoperability problems. Would it make sense to collect them first, before going into testing questionable cases? Here's my list of problematic cases that I have encountered: (offenders: HushMail, PKS, SKS, GnuPG) 1. HushMail's idea of signed and encrypted messages is encrypting a clearsigned message as canonical text, including the message boundary and the armored signature. Other applications usually don't verify the signature, though, of course, it's easy to do "by hand" (by running a second pass). In the other direction, it's worse: HushMail decrypts the properly signed and encrypted message, but keeps silent about the one-pass signature within the encrypted payload; the message is identified as encrypted but not signed. 2. Some keyservers omit canonization before hashing the key packet. If the key packet is shorter than 256 bytes (typically the case for 1024-bit RSA keys) and uses the shortest possible packet header with a one-byte length, the fingerprint and the key IDs are mis-calculated. PKS is guilty of this. 3. Some keyservers do not return matching keys, if searched by the long (16 byte) key ID of a subkey. SKS is guilty of this. 4. Some implementations give up before trying all possible ways of decrypting a message. For example, GnuPG gives up if it encounters a passphrase-derived symmetric key specifier and the entered passphrase is wrong, even if it is followed by an asymmetrically encrypted symmetric key for which it does have access to the corresponding private decryption key. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 04:30:15 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHdW3-0008RG-HY for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 04:30:15 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA15320 for ; Tue, 20 Sep 2005 04:30:12 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8BgJo015860; Tue, 20 Sep 2005 01:11:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8BgwU015859; Tue, 20 Sep 2005 01:11:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8BXp2015847 for ; Tue, 20 Sep 2005 01:11:36 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHdKE-00087C-F9 for ; Tue, 20 Sep 2005 10:18:02 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHd9A-0001CI-Ch; Tue, 20 Sep 2005 10:06:36 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 10:06:36 +0200 In-Reply-To: <20050920065346.GA21364@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 08:53:46 +0200") Message-ID: <87r7bk17ub.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 08:53:46 +0200, Daniel A Nagy said: > 4. Some implementations give up before trying all possible ways of > decrypting a message. For example, GnuPG gives up if it encounters a > passphrase-derived symmetric key specifier and the entered passphrase is > wrong, even if it is followed by an asymmetrically encrypted symmetric key > for which it does have access to the corresponding private decryption key. There are actually two problems: There is no way to cancel the input of a passphrase when using the CLI, so that gpg can continue with other keys. When using the gpg-agent, this is possible but a bug inhibited this - I just fixed that one. The other problem is that we can't reliable decide whether the passphrase is correct. The only way to do this is by looking at the algorithm byte to check whether this gives a valid algorithm. This is far form being reliable. Due to gpg's streaming based design with only a very limited look-ahead we can't do a test decryption and roll back if it does not work out. A way to check early that the decryption worked would be needed to solve the problem - I am not sure whether this is really needed given the security implications of such a check. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Tue Sep 20 04:47:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHdmE-0005Mt-LM for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 04:47:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16302 for ; Tue, 20 Sep 2005 04:46:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8YpAC018753; Tue, 20 Sep 2005 01:34:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8YpXw018750; Tue, 20 Sep 2005 01:34:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.off.net (off.net [66.96.28.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8YoAg018743 for ; Tue, 20 Sep 2005 01:34:50 -0700 (PDT) (envelope-from adam@mail.off.net) Received: by mail.off.net (Postfix, from userid 948) id 27EFD7704B2; Tue, 20 Sep 2005 04:34:41 -0400 (EDT) Received: by bitchcake.off.net (hashcash-sendmail, from uid 948); Tue, 20 Sep 2005 04:34:39 -0400 Date: Tue, 20 Sep 2005 04:34:38 -0400 From: Adam Back To: Hal Finney Cc: ietf-openpgp@imc.org, Adam Back Subject: Re: Bigger DSA keys Message-ID: <20050920083438.GA2105@bitchcake.off.net> References: <20050920014429.2762157EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920014429.2762157EF5@finney.org> User-Agent: Mutt/1.4.1i X-Hashcash: 1:20:050920:hal@finney.org::g1dJ0NQDtfHJjJ2E:jdO X-Hashcash: 1:20:050920:ietf-openpgp@imc.org::4zHziochWPpcMseH:QL+ X-Hashcash: 1:20:050920:adam@cypherspace.org::EvGICYX2COSvdnlE:9nEa Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Could one not use the Lim Lee safe prime generation method for DSA? It has significant speed advantages. Adam On Mon, Sep 19, 2005 at 06:44:29PM -0700, "Hal Finney" wrote: > As far as the issue of generating large DSA keys, a good algorithm to > use is the following. First generate an appropriately sized subgroup > prime q (160, 224, or 256 bits respectively). Then search for a prime > modulus p of the required size (1024, 2048 or 3072 bits) such that p is > one more than a multiple of q. From owner-ietf-openpgp@mail.imc.org Tue Sep 20 04:54:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHdtD-0007tY-9y for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 04:54:11 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16678 for ; Tue, 20 Sep 2005 04:54:08 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8dw0t019308; Tue, 20 Sep 2005 01:39:58 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8dwh8019307; Tue, 20 Sep 2005 01:39:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8dvF4019300 for ; Tue, 20 Sep 2005 01:39:57 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 4D1242B4794; Tue, 20 Sep 2005 10:39:56 +0200 (CEST) Date: Tue, 20 Sep 2005 10:39:56 +0200 To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920083955.GA24261@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r7bk17ub.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 10:06:36AM +0200, Werner Koch wrote: > On Tue, 20 Sep 2005 08:53:46 +0200, Daniel A Nagy said: > > > 4. Some implementations give up before trying all possible ways of > > decrypting a message. For example, GnuPG gives up if it encounters a > > passphrase-derived symmetric key specifier and the entered passphrase is > > wrong, even if it is followed by an asymmetrically encrypted symmetric key > > for which it does have access to the corresponding private decryption key. > > There are actually two problems: > > There is no way to cancel the input of a passphrase when using the > CLI, so that gpg can continue with other keys. When using the > gpg-agent, this is possible but a bug inhibited this - I just fixed > that one. I never thought of this as a problem, but maybe you're right. > The other problem is that we can't reliable decide whether the > passphrase is correct. The only way to do this is by looking at the > algorithm byte to check whether this gives a valid algorithm. This is > far form being reliable. Due to gpg's streaming based design with only > a very limited look-ahead we can't do a test decryption and roll back > if it does not work out. I would suggest a completely different approach: try extracting a key from each ESK (be it password-derived, password-encrypted or asymmetcially encrypted), and use the one which inspires most confidence: An asymmetrically decrypted key has an approx. 1 in 17 million chance of being incorrect, symmetrically encrypted keys have a roughly 1 in 20 chance of being incorrect, while there's absolutely no indication wheter a passphrase-derived secret key is correct or not. Thus, deriving a decryption key from a passphrase and then merrily proceeding to the decryption of the encrypted content is incorrect. A correct implementation should try to extract a key from each ESK, and in case of success (asymmetric decryption with leading 0 and correct checksum, symmetric encryption with valid algorithm id or any passphrase-derived key) replacing the tentative decryption key, if the new key inspires more confidence than the previous tentative key. Eventually, the last tentative key should be used for decryption. > A way to check early that the decryption worked would be needed to > solve the problem - I am not sure whether this is really needed given > the security implications of such a check. Yes, that's somewhat hazardous, indeed (although only in non-interactive applications). But it's not necessary, as explained above. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 05:00:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHdz8-0000tl-0I for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 05:00:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16937 for ; Tue, 20 Sep 2005 05:00:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8lxXC020408; Tue, 20 Sep 2005 01:47:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8lx6X020407; Tue, 20 Sep 2005 01:47:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8lwr4020399 for ; Tue, 20 Sep 2005 01:47:59 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id D1D9D2B47E3; Tue, 20 Sep 2005 10:47:57 +0200 (CEST) Date: Tue, 20 Sep 2005 10:47:57 +0200 To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920084757.GB24261@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r7bk17ub.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 10:06:36AM +0200, Werner Koch wrote: > Due to gpg's streaming based design ... By the way, what does gpg do given the --try-all-secrets option, if there's more than one ESK? Does it try all of them with all the private keys, or just the first one? -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 05:06:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHe5P-00038t-9n for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 05:06:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17315 for ; Tue, 20 Sep 2005 05:06:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8sYFe021341; Tue, 20 Sep 2005 01:54:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8sYJx021340; Tue, 20 Sep 2005 01:54:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8sX5j021333 for ; Tue, 20 Sep 2005 01:54:33 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 85CF82B47E4; Tue, 20 Sep 2005 10:54:32 +0200 (CEST) Date: Tue, 20 Sep 2005 10:54:32 +0200 To: OpenPGP Subject: Re: Bigger DSA keys Message-ID: <20050920085432.GC24261@epointsystem.org> References: <20050920014429.2762157EF5@finney.org> <20050920083438.GA2105@bitchcake.off.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920083438.GA2105@bitchcake.off.net> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 04:34:38AM -0400, Adam Back wrote: > Could one not use the Lim Lee safe prime generation method for DSA? > > It has significant speed advantages. > > Adam DSS explicitly specifies how to generate primes for DSA keys. It can be easily generalized for larger keys and other hash functions, and its reasonable to assume that the new DSS will do that. My estimates were based on that specification. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 05:35:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHeWz-0002KW-4t for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 05:35:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18761 for ; Tue, 20 Sep 2005 05:35:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9BY9p023014; Tue, 20 Sep 2005 02:11:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K9BYYA023013; Tue, 20 Sep 2005 02:11:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9BXOQ022998 for ; Tue, 20 Sep 2005 02:11:33 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHeGI-0008SP-T1 for ; Tue, 20 Sep 2005 11:18:02 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHe5l-0001GH-KY; Tue, 20 Sep 2005 11:07:09 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> <20050920083955.GA24261@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 11:07:09 +0200 In-Reply-To: <20050920083955.GA24261@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 10:39:56 +0200") Message-ID: <87aci8151e.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 10:39:56 +0200, Daniel A Nagy said: > I would suggest a completely different approach: try extracting a key from > each ESK (be it password-derived, password-encrypted or > asymmetcially encrypted), and use the one which inspires most confidence: Makes sense. We have not seen many pubkey/symkey encrypted messages in the wild thus the way we handle them is straightforward. Need to look at it closer. Thanks, Werner From owner-ietf-openpgp@mail.imc.org Tue Sep 20 06:01:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHewI-0000a7-Os for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 06:01:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19783 for ; Tue, 20 Sep 2005 06:01:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9fX1N026576; Tue, 20 Sep 2005 02:41:33 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K9fXZx026575; Tue, 20 Sep 2005 02:41:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9fWqP026564 for ; Tue, 20 Sep 2005 02:41:32 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHejJ-0000Cl-OM for ; Tue, 20 Sep 2005 11:48:01 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHeal-0001JM-4Y; Tue, 20 Sep 2005 11:39:11 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> <20050920084757.GB24261@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 11:39:11 +0200 In-Reply-To: <20050920084757.GB24261@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 10:47:57 +0200") Message-ID: <87mzm8xem8.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 10:47:57 +0200, Daniel A Nagy said: > By the way, what does gpg do given the --try-all-secrets option, if there's > more than one ESK? Does it try all of them with all the private keys, or --try-all-secrets applies only to PKESK to assume wildcard key IDs. Shalom-Salam, Werner From owner-ietf-openpgp@mail.imc.org Tue Sep 20 06:06:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHf1C-0001gb-M9 for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 06:06:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20000 for ; Tue, 20 Sep 2005 06:06:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9aYSX025852; Tue, 20 Sep 2005 02:36:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K9aYwN025851; Tue, 20 Sep 2005 02:36:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9aXss025843 for ; Tue, 20 Sep 2005 02:36:33 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHeeV-0000Bs-0x for ; Tue, 20 Sep 2005 11:43:03 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHeW0-0001In-J1; Tue, 20 Sep 2005 11:34:16 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Bigger DSA keys References: <20050920014429.2762157EF5@finney.org> <20050920083438.GA2105@bitchcake.off.net> <20050920085432.GC24261@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 11:34:16 +0200 In-Reply-To: <20050920085432.GC24261@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 10:54:32 +0200") Message-ID: <87r7bkxeuf.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 10:54:32 +0200, Daniel A Nagy said: > DSS explicitly specifies how to generate primes for DSA keys. It can be > easily generalized for larger keys and other hash functions, and its > reasonable to assume that the new DSS will do that. FWIW, the Lim & Lee algorithm is newer than DSS. It was published in Crypto 97 whereas FIPS 186 was published in 1994. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Tue Sep 20 10:49:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHjRW-0006Ii-Db for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 10:49:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05191 for ; Tue, 20 Sep 2005 10:49:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KETTod055721; Tue, 20 Sep 2005 07:29:29 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KETTcc055720; Tue, 20 Sep 2005 07:29:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KETSsM055712 for ; Tue, 20 Sep 2005 07:29:28 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 00EB15A79D; Tue, 20 Sep 2005 15:29:26 +0100 (BST) Message-ID: <43301CEC.2070500@systemics.com> Date: Tue, 20 Sep 2005 15:30:04 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Werner Koch Cc: Ben Laurie , Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> <432D4F13.6080703@algroup.co.uk> <432D712D.4060502@systemics.com> <871x3l790m.fsf@wheatstone.g10code.de> In-Reply-To: <871x3l790m.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Werner Koch wrote: > DSA 100 times sign verify > ----------------------------- > DSA 1024/160 910ms 430ms > DSA 2048/224 1560ms 1890ms > DSA 3072/256 3610ms 4380ms > > (The numbers for sign are not very reliable because it employs the > RNG and I could not adjust for it) > > 3072 takes more more than double the time of 2048 which is not too > bad. Compared to 1024 this is a real slowdown and would make key > signature verification a very time consuming operation. On slow > machines (embedded devices, older hardware) this would be very > annoying. Ah, ok, so this last point about slow / small hardware platforms makes sense. So we might be tempted to suggest that implementations SHOULD verify any of the three lengths, and let them choose which length to deliver for signing beyond the MUST of 1024/160. (Which is after all a minor side discussion in Hal's thread of whether to wait or not.) iang From owner-ietf-openpgp@mail.imc.org Tue Sep 20 11:46:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHkKG-0007Ts-D4 for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 11:46:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10527 for ; Tue, 20 Sep 2005 11:46:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFHD6d062083; Tue, 20 Sep 2005 08:17:13 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KFHDDS062082; Tue, 20 Sep 2005 08:17:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [216.148.227.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFHDp1062060 for ; Tue, 20 Sep 2005 08:17:13 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <2005092015170701500459u4e>; Tue, 20 Sep 2005 15:17:07 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8KFH60m015463 for ; Tue, 20 Sep 2005 11:17:06 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8KFH5sU015061 for ; Tue, 20 Sep 2005 11:17:05 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8KFH5dP015060 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 11:17:05 -0400 Date: Tue, 20 Sep 2005 11:17:05 -0400 From: David Shaw To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920151705.GA14884@jabberwocky.com> Mail-Followup-To: OpenPGP References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920065346.GA21364@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 08:53:46AM +0200, Daniel A. Nagy wrote: > 2. Some keyservers omit canonization before hashing the key packet. If the > key packet is shorter than 256 bytes (typically the case for 1024-bit RSA > keys) and uses the shortest possible packet header with a one-byte length, > the fingerprint and the key IDs are mis-calculated. PKS is guilty of this. This is a good one. I've seen this mistake made more than once, and not just in PKS. Incidentally, that bug in PKS was fixed quite a while ago. PKS had many problems, including miscalculating v4 RSA fingerprints, mangling keys with more than one subkey, discarding attribute ID packets, etc. Most of the worst have been fixed, but the point may be moot as so far as I know, PKS is not being developed any longer. > 3. Some keyservers do not return matching keys, if searched by the long > (16 byte) key ID of a subkey. SKS is guilty of this. Isn't this a just SKS feature request? Nothing in the draft says anything about how keyservers work, or even that a UI must allow particular ways to search. David From owner-ietf-openpgp@mail.imc.org Tue Sep 20 12:08:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHkfR-0004Ug-5k for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 12:08:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12011 for ; Tue, 20 Sep 2005 12:08:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFo4EY066371; Tue, 20 Sep 2005 08:50:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KFo4YO066370; Tue, 20 Sep 2005 08:50:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFo3Aj066361 for ; Tue, 20 Sep 2005 08:50:03 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 6A7A52B47EA; Tue, 20 Sep 2005 17:50:02 +0200 (CEST) Date: Tue, 20 Sep 2005 17:50:02 +0200 To: Werner Koch , OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920155001.GA16991@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> <20050920084757.GB24261@epointsystem.org> <87mzm8xem8.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mzm8xem8.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 11:39:11AM +0200, Werner Koch wrote: > On Tue, 20 Sep 2005 10:47:57 +0200, Daniel A Nagy said: > > > By the way, what does gpg do given the --try-all-secrets option, if there's > > more than one ESK? Does it try all of them with all the private keys, or > > --try-all-secrets applies only to PKESK to assume wildcard key IDs. Right, but what if there are more of these (multiple recipients)? -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 12:16:25 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHknB-0006VO-Ch for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 12:16:25 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12500 for ; Tue, 20 Sep 2005 12:16:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KG54GR067845; Tue, 20 Sep 2005 09:05:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KG54PW067844; Tue, 20 Sep 2005 09:05:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KG53rr067837 for ; Tue, 20 Sep 2005 09:05:04 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8AC422B480E; Tue, 20 Sep 2005 18:04:57 +0200 (CEST) Date: Tue, 20 Sep 2005 18:04:57 +0200 To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920160452.GB16991@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920151705.GA14884@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 11:17:05AM -0400, David Shaw wrote: > > 3. Some keyservers do not return matching keys, if searched by the long > > (16 byte) key ID of a subkey. SKS is guilty of this. > > Isn't this a just SKS feature request? Nothing in the draft says > anything about how keyservers work, or even that a UI must allow > particular ways to search. No, it isn't. This becomes a major interoperability issue, when you use signature subkeys. It's not quite clear from RFC2440 wether the 8-byte signatory field sould point to the main key or the subkey, but in several implementations it points to the subkey, which actually made the signature (and this is the right behavior, IMHO). In this case, databases of keys, be it local keyrings or remote keyservers MUST be indexed by subkey IDs as well, otherwise such signatures cannot be verified. For example, this SKS deficienci breaks interoperability (namely yautotmatic key retrieval) with GnuPG (and very possibly PGP), if signature subkeys are used. Signature subkeys have many uses, and although they are less popular than encryption subkeys (because of the default settings of pgp and gpg) their use is an important security measure allowing for changing the regularly used signing key without losing all certificatitons on the main key. They are also useful if the same user wishes to make signatures from different computers without risking too much. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 12:29:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHl0G-0003Cd-LY for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 12:29:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13107 for ; Tue, 20 Sep 2005 12:29:53 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KGGYwN068600; Tue, 20 Sep 2005 09:16:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KGGYr9068599; Tue, 20 Sep 2005 09:16:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KGGXkc068590 for ; Tue, 20 Sep 2005 09:16:33 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHkta-00029z-Kd for ; Tue, 20 Sep 2005 18:23:02 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHklM-0001lA-On; Tue, 20 Sep 2005 18:14:32 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> <20050920084757.GB24261@epointsystem.org> <87mzm8xem8.fsf@wheatstone.g10code.de> <20050920155001.GA16991@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 18:14:32 +0200 In-Reply-To: <20050920155001.GA16991@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 17:50:02 +0200") Message-ID: <87vf0vra1j.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 17:50:02 +0200, Daniel A Nagy said: >> > more than one ESK? Does it try all of them with all the private keys, or >> >> --try-all-secrets applies only to PKESK to assume wildcard key IDs. > Right, but what if there are more of these (multiple recipients)? Yes, it tries all of them with all available secret keys. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Tue Sep 20 13:27:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHltz-0000wV-8C for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 13:27:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17541 for ; Tue, 20 Sep 2005 13:27:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHCt60075515; Tue, 20 Sep 2005 10:12:55 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KHCtUa075514; Tue, 20 Sep 2005 10:12:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHCtA9075504 for ; Tue, 20 Sep 2005 10:12:55 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <200509201712490150044buue>; Tue, 20 Sep 2005 17:12:49 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8KHCn0m015844 for ; Tue, 20 Sep 2005 13:12:49 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8KHClQH015190 for ; Tue, 20 Sep 2005 13:12:47 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8KHCl3c015189 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 13:12:47 -0400 Date: Tue, 20 Sep 2005 13:12:47 -0400 From: David Shaw To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920171247.GD14884@jabberwocky.com> Mail-Followup-To: OpenPGP References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> <20050920160452.GB16991@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920160452.GB16991@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 06:04:57PM +0200, Daniel A. Nagy wrote: > > On Tue, Sep 20, 2005 at 11:17:05AM -0400, David Shaw wrote: > > > > 3. Some keyservers do not return matching keys, if searched by the long > > > (16 byte) key ID of a subkey. SKS is guilty of this. > > > > Isn't this a just SKS feature request? Nothing in the draft says > > anything about how keyservers work, or even that a UI must allow > > particular ways to search. > > No, it isn't. This becomes a major interoperability issue, when you use > signature subkeys. It's not quite clear from RFC2440 wether the 8-byte > signatory field sould point to the main key or the subkey, but in several > implementations it points to the subkey, which actually made the signature > (and this is the right behavior, IMHO). I don't know of *any* implementations that set the issuer subpacket to anything other than the key that made the signature, as specified in the RFC. Doing otherwise would be an absurd thing to do - the signing equivalent of putting the main key ID into a PKESK packet when encrypting to a subkey. If you can point to a single implementation that does this wrong, I'll immediately concede the point. David From owner-ietf-openpgp@mail.imc.org Tue Sep 20 13:43:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHm9f-00086z-Kw for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 13:43:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18704 for ; Tue, 20 Sep 2005 13:43:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHUu4T077688; Tue, 20 Sep 2005 10:30:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KHUuxq077687; Tue, 20 Sep 2005 10:30:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHUtH5077681 for ; Tue, 20 Sep 2005 10:30:55 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2289733C1B; Tue, 20 Sep 2005 18:30:54 +0100 (BST) Message-ID: <4330474D.6050800@algroup.co.uk> Date: Tue, 20 Sep 2005 18:30:53 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" CC: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050918001303.96B4F57EF5@finney.org> <20050918123430.GB6483@epointsystem.org> In-Reply-To: <20050918123430.GB6483@epointsystem.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > It's important to keep in mind that DSS-style signatures are twice the hash > size. This is one of their nicest features; they do not grow with the > modulus. A signature of a 3072/256 key will be 512 bits (plus overhead). > > As for generating long modulae, it's not that big a problem, altough it has > to be noted that generating a modulus for DSA takes more than just > generating a prime that big; DSA moduli p are such that p-1 is divisible by > some large (hash-sized) q. The generation of such moduli takes substantially > longer than generating primes. For 3072/256 on a 500MHz intel, it would take > approx. three minutes, provided that the random stream is available without > waiting. > > On the other hand, the overwhelming majority of DSS implementations use > pre-calculated moduli, as there are no security hazards associated with > using a common modulus for DSS. When keys need to be generated frequently, > a pre-calculated modulus is the way to go. If one just needs to generate a > personal signature key for the next five years, one can wait three minutes, > in case they want to show off a self-generated modulus. Good point. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Tue Sep 20 13:45:12 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmB6-0008TM-10 for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 13:45:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18742 for ; Tue, 20 Sep 2005 13:45:09 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHXpgC077944; Tue, 20 Sep 2005 10:33:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KHXpt8077943; Tue, 20 Sep 2005 10:33:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHXog8077935 for ; Tue, 20 Sep 2005 10:33:50 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 96E1A57EF5; Tue, 20 Sep 2005 10:33:37 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-Id: <20050920173337.96E1A57EF5@finney.org> Date: Tue, 20 Sep 2005 10:33:37 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > I don't know of *any* implementations that set the issuer subpacket to > anything other than the key that made the signature, as specified in > the RFC. Doing otherwise would be an absurd thing to do - the signing > equivalent of putting the main key ID into a PKESK packet when > encrypting to a subkey. If you can point to a single implementation > that does this wrong, I'll immediately concede the point. Perhaps we should clarify the language in the RFC to eliminate any such ambiguity. 5.2.3.5, the Issuer subpacket, just says: The OpenPGP key ID of the key issuing the signature. We could add "If the signature is issued by a subkey then the key ID of this subkey is used here instead of the key ID of the primary key." We do have similar language in 5.2 for PKESKs: - An eight-octet number that gives the key ID of the public key that the session key is encrypted to. If the session key is encrypted to a subkey then the key ID of this subkey is used here instead of the key ID of the primary key. This would make sure there is no ambiguity about which key ID to use. Hal Finney From owner-ietf-openpgp@mail.imc.org Tue Sep 20 13:54:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmJy-0002B8-98 for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 13:54:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19283 for ; Tue, 20 Sep 2005 13:54:20 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHdpGC078424; Tue, 20 Sep 2005 10:39:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KHdpJ7078423; Tue, 20 Sep 2005 10:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHdpMo078417 for ; Tue, 20 Sep 2005 10:39:51 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 33F0957EF5; Tue, 20 Sep 2005 10:39:39 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Line spacing in normative references Message-Id: <20050920173939.33F0957EF5@finney.org> Date: Tue, 20 Sep 2005 10:39:39 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A minor point, I notice that the spacing is inconsistent in the normative references. Some are separated by blank lines and some are not. It would look nicer to be consistent here. I don't know if some macro is misfiring or if we could clean it up and make it look better. Hal From owner-ietf-openpgp@mail.imc.org Tue Sep 20 14:30:47 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmtC-0003WQ-Ux for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 14:30:47 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21117 for ; Tue, 20 Sep 2005 14:30:44 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI6xE9081386; Tue, 20 Sep 2005 11:06:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KI6xpD081385; Tue, 20 Sep 2005 11:06:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [216.148.227.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI6wVk081375 for ; Tue, 20 Sep 2005 11:06:59 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <200509201806530150043lfde>; Tue, 20 Sep 2005 18:06:53 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8KI6r0m016062 for ; Tue, 20 Sep 2005 14:06:53 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8KI6pCt015306 for ; Tue, 20 Sep 2005 14:06:51 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8KI6p7F015305 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 14:06:51 -0400 Date: Tue, 20 Sep 2005 14:06:51 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-ID: <20050920180651.GA15299@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050920173337.96E1A57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920173337.96E1A57EF5@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 10:33:37AM -0700, "Hal Finney" wrote: > Perhaps we should clarify the language in the RFC to eliminate any > such ambiguity. 5.2.3.5, the Issuer subpacket, just says: > > The OpenPGP key ID of the key issuing the signature. > > We could add "If the signature is issued by a subkey then the key ID of > this subkey is used here instead of the key ID of the primary key." > > We do have similar language in 5.2 for PKESKs: > > - An eight-octet number that gives the key ID of the public key > that the session key is encrypted to. If the session key is > encrypted to a subkey then the key ID of this subkey is used > here instead of the key ID of the primary key. I think that is reasonable, but it would need to be mentioned in several places (in bis-14): 5.2.2 (V3 signatures), 5.2.3.5 (issuer subpacket), and 5.4 (Onepass signature packet). Perhaps something could be said in 3.3 (Key IDs) that covers them all? David From owner-ietf-openpgp@mail.imc.org Tue Sep 20 14:31:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmu7-0003ow-W0 for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 14:31:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21185 for ; Tue, 20 Sep 2005 14:31:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI8Wxp081482; Tue, 20 Sep 2005 11:08:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KI8Veb081480; Tue, 20 Sep 2005 11:08:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI8VP7081473 for ; Tue, 20 Sep 2005 11:08:31 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005092018082601400ohnkge>; Tue, 20 Sep 2005 18:08:26 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8KI8Q0m016079 for ; Tue, 20 Sep 2005 14:08:26 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8KI8NoD015312 for ; Tue, 20 Sep 2005 14:08:23 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8KI8Npr015311 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 14:08:23 -0400 Date: Tue, 20 Sep 2005 14:08:23 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Information and meta-information Message-ID: <20050920180823.GB15299@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050831152646.GB31148@epointsystem.org> <8BADBD06-012A-44B0-A9A7-6BDAE8ED8E37@hhhh.org> <20050907233120.GA31910@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907233120.GA31910@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 08, 2005 at 01:31:25AM +0200, Daniel A. Nagy wrote: > > On Wed, Sep 07, 2005 at 03:56:58PM -0700, Wim Lewis wrote: > > > The existing 'b', 't', etc. tags could then be defined as shorthands > > for particular MIME headers (content-type and charset). > > I disagree, because these tags convey a slightly different (lower-level) > meaning than the mime headers. Also, the above suggestion would be a > security hazard, since the literal packet's tag is not hashed and can be > therefore altered in a signed message, without breaking the signature. > PGP/MIME headers, on the other hand, are included in the hashed material, so > they are part of the signed message. > > > >I would suggest the following modification of RFC2440bis-14: > > > > Do you mean removing the 't' and 'u' tags? Or supplementing them with > > 'm'? > > Supplementing with 'm', of course. Removing 't' and 'b' tags (what's 'u'?) > would break almost everything. 't' = unspecified charset 'u' = utf-8 charset David From owner-ietf-openpgp@mail.imc.org Tue Sep 20 14:34:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmwl-0005FS-9h for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 14:34:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21445 for ; Tue, 20 Sep 2005 14:34:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI2Wnw081103; Tue, 20 Sep 2005 11:02:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KI2W2g081102; Tue, 20 Sep 2005 11:02:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI2VeJ081095 for ; Tue, 20 Sep 2005 11:02:31 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 74FE257EF5; Tue, 20 Sep 2005 11:02:19 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-Id: <20050920180219.74FE257EF5@finney.org> Date: Tue, 20 Sep 2005 11:02:19 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There are a few differences between the OpenPGP requirements for DSA keys and those in the DSS spec. Usually, OpenPGP implementations do not use pre-calculated moduli for DSA keys. Likewise, OpenPGP does not require that DSA keys be generated by the method described in the DSS standard. This is the reason why we generally call them DSA keys and not DSS keys in the spec. Nevertheless we do follow the FIPS-186 recommendations for modulus sizes, as their advice is good. There are a few issues here. Pre-calculated moduli do have some advantages. Generating the modulus is the slow part of DSA keygen. With a pre-calculated modulus, all that is necessary to generate a key is to pick a random value x and do one exponentiation to generate y = g^x mod p. This can also save space in key distribution; if there is a widely shared modulus then only the y value has to be distributed for each key. There are a few disadvantages though. There are theoretical attacks where the body that generates the pre-calculated modulus can use "trapdoor" primes which allow faster calculation of discrete log. Anyone who generated a key using that shared modulus would be at risk of having his private key broken by the body which created that modulus. In order to protect users against this possibility, DSS specifies that the public parameters (p, q, g) be generated using a randomization technique which essentially eliminates the possibility of a trapdoor. But it also requires that a sort of "certificate" of the parameter generation be created and distributed, and that end users verify that certificate to make sure that the public parameters have no trapdoors. This is pretty complicated, and furthermore the general paranoia among much of OpenPGP's audience is likely to make them mistrust even shared parameters that are accompanied by such certificates. As a result OpenPGP has not pursued this approach. There are no OpenPGP data structures to share DSS public parameter certificates and nothing in the spec about creating DSS keys in the standard way, or sharing and verifying such certificates. So OpenPGP generally envisions DSA keys being generated with fresh public parameters for each key. Not only is this more secure and simpler, but it allows for the fast generation method I described in my mail yesterday, which uses sieving. Generating DSS moduli per FIPS-186 is relatively slow, and extending that method to larger prime sizes may become prohibitively slow. (Of course, if the FIPS-186 method is used with shared moduli, then keygen becomes very faster as I noted above, just a single exponentiation to calculate y.) I'm not sure how other systems that implement DSS handle the issue of validating public parameter certificates. It could be that OpenPGP is the main user of DSA/DSS and nobody else worries about it. I know I've seen X.509 certificate specs for DSS keys and they don't have the extra information necessary (although strangely, X.509 Diffie-Hellman keys do have it!). I guess they just assume that checks for legal DSS public parameters are outside the scope of their spec. Hal Finney From owner-ietf-openpgp@mail.imc.org Tue Sep 20 20:06:38 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHs8E-0006cu-Ls for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 20:06:38 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15963 for ; Tue, 20 Sep 2005 20:06:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KNlVIg012102; Tue, 20 Sep 2005 16:47:31 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KNlVB8012101; Tue, 20 Sep 2005 16:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KNlTV5012095 for ; Tue, 20 Sep 2005 16:47:30 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id CDED12B4794; Wed, 21 Sep 2005 01:47:28 +0200 (CEST) Date: Wed, 21 Sep 2005 01:47:28 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050920234728.GA28452@epointsystem.org> References: <20050920180219.74FE257EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920180219.74FE257EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 11:02:19AM -0700, "Hal Finney" wrote: > I'm not sure how other systems that implement DSS handle the issue of > validating public parameter certificates. It could be that OpenPGP is > the main user of DSA/DSS and nobody else worries about it. I know I've > seen X.509 certificate specs for DSS keys and they don't have the extra > information necessary (although strangely, X.509 Diffie-Hellman keys do > have it!). I guess they just assume that checks for legal DSS public > parameters are outside the scope of their spec. I know about one other major implementation of DSS, which is java.security by Sun Microsystems. Their key generation method uses pre-calculated moduli for the common key sizes, but one can turn that feature off and have the key generated from scratch (which takes a lot longer, of course). The certificates of the pre-calculated moduli are in a comment of the source code, which you may obtain from Sun upon request (they are very forthcoming about that, becasue they understand that openness is the basis of trust in crypto matters). -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 20:13:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHsEr-0001OH-0q for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 20:13:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16297 for ; Tue, 20 Sep 2005 20:13:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KNrgfM012580; Tue, 20 Sep 2005 16:53:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KNrgM3012579; Tue, 20 Sep 2005 16:53:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KNrfJG012572 for ; Tue, 20 Sep 2005 16:53:41 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 7791C2B4794; Wed, 21 Sep 2005 01:53:39 +0200 (CEST) Date: Wed, 21 Sep 2005 01:53:39 +0200 To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-ID: <20050920235332.GB28452@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> <20050920160452.GB16991@epointsystem.org> <20050920171247.GD14884@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920171247.GD14884@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 01:12:47PM -0400, David Shaw wrote: > > No, it isn't. This becomes a major interoperability issue, when you use > > signature subkeys. It's not quite clear from RFC2440 wether the 8-byte > > signatory field sould point to the main key or the subkey, but in several > > implementations it points to the subkey, which actually made the signature > > (and this is the right behavior, IMHO). > > I don't know of *any* implementations that set the issuer subpacket to > anything other than the key that made the signature, as specified in > the RFC. You mean the actual subkey, right? Where is it specified in the RFC? The formulation "the key that made the signature" is a bit ambiguous, IMHO, but, of course, the sensible thing to do is obvious. > Doing otherwise would be an absurd thing to do - the signing > equivalent of putting the main key ID into a PKESK packet when > encrypting to a subkey. If you can point to a single implementation > that does this wrong, I'll immediately concede the point. Of course, I can't. This is why I am saying that SKS has an important interoperability problem. It EXPECTS the wrong behavior, while nobody actually does it. -- Daniel From owner-ietf-openpgp@mail.imc.org Tue Sep 20 21:35:06 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHtVq-0005sv-DC for openpgp-archive@megatron.ietf.org; Tue, 20 Sep 2005 21:35:06 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18983 for ; Tue, 20 Sep 2005 21:35:03 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L1BBQw018181; Tue, 20 Sep 2005 18:11:11 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8L1BBAQ018180; Tue, 20 Sep 2005 18:11:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L1B4g0018135 for ; Tue, 20 Sep 2005 18:11:07 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc12) with ESMTP id <20050921011056014000qpm9e>; Wed, 21 Sep 2005 01:10:56 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8L1Av0m017334 for ; Tue, 20 Sep 2005 21:10:57 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8L1AriR015973 for ; Tue, 20 Sep 2005 21:10:53 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8L1Ar0P015972 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 21:10:53 -0400 Date: Tue, 20 Sep 2005 21:10:53 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-ID: <20050921011053.GA15822@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> <20050920160452.GB16991@epointsystem.org> <20050920171247.GD14884@jabberwocky.com> <20050920235332.GB28452@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920235332.GB28452@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 01:53:39AM +0200, Daniel A. Nagy wrote: > > Doing otherwise would be an absurd thing to do - the signing > > equivalent of putting the main key ID into a PKESK packet when > > encrypting to a subkey. If you can point to a single implementation > > that does this wrong, I'll immediately concede the point. > > Of course, I can't. This is why I am saying that SKS has an important > interoperability problem. It EXPECTS the wrong behavior, while nobody > actually does it. While it is true that SKS doesn't do long keyid searches for subkeys, and I agree this is suboptimal behavior, understand that this is not connected to what clients put in the issuer key ID subpacket. There has never been a client that put anything other than the signing key ID in the subpacket, and the SKS behavior is not based on some misreading of that point in the draft. Even if SKS started supporting long subkey ID searches tomorrow, it would not resolve this problem, as GnuPG doesn't provide long key IDs when speaking to any HKP-ish keyserver because there are still old PKS servers out that that just won't die. I believe PGP does the same thing. If you want long key ID searches, you need to use LDAP. Note that even those PKS servers that don't blow up completely on long key ID searches don't really do them either: they just pretend to, and ignore the upper 32 bits - try searching for 0x99242560 and 0x1111111199242560. PKS doesn't do subkey searches at all. I'm all for getting these problems fixed, but we stand a better chance of doing by working the actual problem. By all means, add some clarifying text to the text for the issuer key ID subpacket, but understand that won't change the keyserver situation. It's just two different problems. David From owner-ietf-openpgp@mail.imc.org Wed Sep 21 06:23:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI1lC-0000qK-29 for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 06:23:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10112 for ; Wed, 21 Sep 2005 06:23:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L9iTJQ064154; Wed, 21 Sep 2005 02:44:29 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8L9iTDW064153; Wed, 21 Sep 2005 02:44:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L9iRQF064146 for ; Wed, 21 Sep 2005 02:44:28 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 5A87A2B47E3; Wed, 21 Sep 2005 11:44:26 +0200 (CEST) Date: Wed, 21 Sep 2005 11:44:26 +0200 To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-ID: <20050921094426.GA26811@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> <20050920160452.GB16991@epointsystem.org> <20050920171247.GD14884@jabberwocky.com> <20050920235332.GB28452@epointsystem.org> <20050921011053.GA15822@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921011053.GA15822@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 09:10:53PM -0400, David Shaw wrote: > I'm all for getting these problems fixed, but we stand a better chance > of doing by working the actual problem. By all means, add some > clarifying text to the text for the issuer key ID subpacket, but > understand that won't change the keyserver situation. It's just two > different problems. Oh, there seems to be a misunderstanding between us, for which I should probably apologize. I never for a moment suggested that SKS's bad behavior was the result of the wording in RFC2440, though reading back, it might have indeed come across like I did. I simply listed interoperability problems that I have encountered that in my opinion resulted from not anticipating less obvious, yet perfectly RFC-compliant behavior. In this particular case, I have noted a minor possible ambiguity in the standard text, which, I repeat, should be obvious for anyone giving it a little thought. As an implementer myself, I have resorted to the same workarounds: canonizing public key packets before uploading to keyserver and using short key IDs. Also, I totally agree with you that clarification in the standard is not the way to fix this problem, but listing it as a known interoperability issue in the mailing list archive or even on some webpage dedicated to interoperability between OpenPGP applications (is that what Jon aims to do?) might help in two ways: culprits may eventually fix their bugs, and meanwhile others might avoid running into them. For example, if such a list existed when I coded the relevant parts of ePointPGP, it would have saved me a lot of time. I think, Jon's idea of an interop grill-off is an excellent opportunity for assembling such a list of known interoperability issues, before venturing into testing unknown, suspected ones. That said, SKS is by far the most standards-compliant HKP-compatible keyserver that I have seen. Others do horrible things to keys and search results. Since keyservers are (correctly) considered outside of security perimeters and should be treated as untrustworthy in any case, they tend to be the least carefully written and maintained applications in the OpenPGP world. That's just a fact of life, I guess, that we need to cope with. And again, apologies in case I have unintentionally offended someone. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 07:33:00 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI2qS-0001vb-2X for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 07:33:00 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13247 for ; Wed, 21 Sep 2005 07:32:59 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LAw0f9070620; Wed, 21 Sep 2005 03:58:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LAw0g2070619; Wed, 21 Sep 2005 03:58:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LAvw7o070610 for ; Wed, 21 Sep 2005 03:57:59 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 615DE5AA0A; Wed, 21 Sep 2005 11:57:57 +0100 (BST) Message-ID: <43313CD8.6000303@systemics.com> Date: Wed, 21 Sep 2005 11:58:32 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Cc: "Daniel A. Nagy" Subject: [v5] Re: Problems with v4 key packet format References: <20050920053207.GA5245@epointsystem.org> In-Reply-To: <20050920053207.GA5245@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > In order to design a successor to v4 key packet format, it is important to > first identify its shortcomings. Here's a list of my problems with it: Perhaps a pass at listing the problems in v4 ** would be a fair first phase. Here's a couple of issues (although I admit to not bit-peeping as much as I should, most of these are user/mgr level grumbles): 5. Too many integers and formats and what have you. There should be a base level of formats which should cover all requirements, and these should be flexible enough to do that job, while simple and short enough to be easily implementable and understandable. 6. PGP's feedback mode. There's no point to this. It's a thing that PRZ added in because he thought it was cool; he was wrong on that point && and it would make matters easier if the standard CBC modes that are described in all the textbooks were used. 7. Cipher suites, not algorithms. Although I like OpenPGP's tradition of opening up to experiments in algorithms and so forth, I think it is a pain for interoperability and implementation. It might be fine to demand the "right" to implement odd-length RSA with Ripem-666 hashes and the latest chinese cipher feedback modes over GOST encryption, but this is just plain stupidity at the software engineering level. As much as possible, I'd suggest that a cipher suites approach be used: Cipher suite #1 should fix the PK, the encryption algorithm, the hash, the feedback modes, and all that. When something breaks, deprecate the whole sodding lot, and move on to #2. Life was really good in the days up to pgp2.6. Then it all went to pot. We may never go back to those simple times, but we can attempt to simulate it by using cipher suites $$. (some of these points are contradictory at some level :-) iang PS **: if we are going to start discussing futures like v5, it might be easier to stick something in the subject so people know quickly that it does not effect the current doc. PS &&: This is not a criticism of him; nobody ever builds a perfect cryptosystem, and it falls to later disciples to carefully clean out the mistakes. PS $$: Allowing experimental cipher suites would be fine. Another trap to avoid is the SSL cipher suite rabbit explosion ... but that should be easy to do if we allow people to experiment with their own and only promote the really useful, strong ones. I.e., rejection of marginal improvements as a routine. From owner-ietf-openpgp@mail.imc.org Wed Sep 21 07:34:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI2s8-0002Gz-1d for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 07:34:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13339 for ; Wed, 21 Sep 2005 07:34:42 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LB0IvA070743; Wed, 21 Sep 2005 04:00:18 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LB0I0k070742; Wed, 21 Sep 2005 04:00:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LB0H1i070736 for ; Wed, 21 Sep 2005 04:00:17 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 631D85AA12; Wed, 21 Sep 2005 12:00:16 +0100 (BST) Message-ID: <43313D64.8070501@systemics.com> Date: Wed, 21 Sep 2005 12:00:52 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Cc: Jon Callas Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> In-Reply-To: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Jon Callas wrote: > > I think it would be good for us to have some sort of interoperability > test and event. Putting on my PGP Corporation hat, I'm happy to sponsor > it. However, it doesn't *have* to be a physical event. Physics is fun, but net chemistry also works. I've had some degree of success in testing cross-platform code using a "webservice" approach. Basically, build a server that offers a number of actions over HTTP **. The basic action is an echo service that forms part of a read/write cycle to prove serialisation. It works roughly this way: 1. Create a garbage packet. 2. Serialise it into its network form. 3. Send it off to the other implementation over some sort of server protocol. 4. The echo server sits there and waits for packets: a. read a packet in, b. parse it, objectise it, c. write it out again in network form, d. return it as the response to the request. 5. The original sender reads back the response, recovers it and then compares it internally with the original packet it sent. This means that there needs to be two routines added to every packet: create a garbage packet, and compare two packets for equality. Once that basic architecture is defined, many variants are possible.... > Does anyone else > think it would be a good idea? Does anyone want to help put it on, come > up with test cases, that sort of thing? It's definately a good idea. The main thing above would be to define a list of the minimal packets that should be echoed: public key packet with basic feature set and only the MUST algorithms encrypted message, signed message, cleartext and binary encrypted + signed binary Start with the absolute minimum. (Obviously encrypted and signed messages will involve some state ....) iang PS: To add in another buzzword, I'd do it in REST format, which basically means do it as a simulated web server, and have the client and server deal with HTTP POST requests with some form of application binary data. This avoids most of the complications of defining ones own transport protocol, avoids having to talk to the firewall people, and for most languages means you don't have to run a server at all, just slot it in as a CGI into Apache. From owner-ietf-openpgp@mail.imc.org Wed Sep 21 09:02:39 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4FD-0007CB-6h for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 09:02:39 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17379 for ; Wed, 21 Sep 2005 09:02:37 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCOLnq078598; Wed, 21 Sep 2005 05:24:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LCOL0c078597; Wed, 21 Sep 2005 05:24:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCOKRp078587 for ; Wed, 21 Sep 2005 05:24:20 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 579B233C1A; Wed, 21 Sep 2005 13:24:19 +0100 (BST) Message-ID: <433150F4.1000307@algroup.co.uk> Date: Wed, 21 Sep 2005 13:24:20 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hal Finney CC: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050920014429.2762157EF5@finney.org> In-Reply-To: <20050920014429.2762157EF5@finney.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hal Finney wrote: > In contrast, finding "strong" primes p such that (p-1)/2 is also prime > does tend to be slow. I think there is a trick to do it using a double > sieve but it is still much slower than finding regular primes. There is - Geoff Thorpe and I planned to implement it for OpenSSL, but never got around to it. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Sep 21 09:03:13 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4Fk-0007GG-SS for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 09:03:12 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17421 for ; Wed, 21 Sep 2005 09:03:10 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCSRYP078817; Wed, 21 Sep 2005 05:28:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LCSRUj078816; Wed, 21 Sep 2005 05:28:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCSREP078810 for ; Wed, 21 Sep 2005 05:28:27 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 712BF33C1B; Wed, 21 Sep 2005 13:28:26 +0100 (BST) Message-ID: <433151EB.6050805@algroup.co.uk> Date: Wed, 21 Sep 2005 13:28:27 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" CC: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format References: <20050920053207.GA5245@epointsystem.org> In-Reply-To: <20050920053207.GA5245@epointsystem.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > In order to design a successor to v4 key packet format, it is important to > first identify its shortcomings. Here's a list of my problems with it: > > 1. No cryptographic binding between the encrypted private key material and > the public key material. > > This results in a serious security issue, by allowing an attacker to replace > the public material thus compromising the private material with the first > use in the signature. There are various stop-gap measures to deal with this > attack, but the only sure protetction would be some MDC binding together the > private and the public key material. I don't understand this attack. > 2. No explicit count of MPIs constituting the key material (both public and > private). > > This information can only be inferred from the algorithm specifier, meaning > that any implementation that wants to perform key management must have some > rudimentary knowledge about all public key algorithms. This, in turn, > hampers forward-compatibility. This appears to me to be incorrect - an implementation that didn't know the algorithm could still deduce the number of MPIs by parsing the packet until it is exhausted. This would mean introducing a requirement that all public key parameters were MPIs, of course. > 3. Key fingerprint depends on data unrelated to the actual key (namely: > creation date). > > This prevents solutions when signature keys are generated on the fly (e.g. > directly from a passphrase), as the key creation (or, in this case, key > registration) date is not available at the time of signing, thus making it > impossible to put am unambiguous reference to the public key into the > signature. Not impossible, but I'll agree, crufty. One could use a fixed creation date. > 4. More generally, creation time does not belong to the key packet. > > Because it is just an attribute of the key as any other, thus belonging to > certificatiton signature sub-packets, rather than the key packet. So? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Sep 21 09:32:56 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4iU-0006a1-Ir for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 09:32:56 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19410 for ; Wed, 21 Sep 2005 09:32:52 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCuQaD081294; Wed, 21 Sep 2005 05:56:26 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LCuQEG081293; Wed, 21 Sep 2005 05:56:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.76.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCuQRU081282 for ; Wed, 21 Sep 2005 05:56:26 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <2005092112562001300a77npe>; Wed, 21 Sep 2005 12:56:20 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8LCuM0m019742 for ; Wed, 21 Sep 2005 08:56:22 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8LCuJZ8017441 for ; Wed, 21 Sep 2005 08:56:19 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8LCuJfE017440 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 08:56:19 -0400 Date: Wed, 21 Sep 2005 08:56:19 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921125619.GB15822@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050920053207.GA5245@epointsystem.org> <433151EB.6050805@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433151EB.6050805@algroup.co.uk> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 01:28:27PM +0100, Ben Laurie wrote: > >2. No explicit count of MPIs constituting the key material (both public and > >private). > > > >This information can only be inferred from the algorithm specifier, meaning > >that any implementation that wants to perform key management must have some > >rudimentary knowledge about all public key algorithms. This, in turn, > >hampers forward-compatibility. > > This appears to me to be incorrect - an implementation that didn't know > the algorithm could still deduce the number of MPIs by parsing the > packet until it is exhausted. This would mean introducing a requirement > that all public key parameters were MPIs, of course. You could also do what GnuPG does - if it doesn't know the algorithm it just reads the entire list of MPIs (or anything else in the packet) into an opaque buffer. I suppose it could figure out the MPIs, but there seems to be little point since either way, the key is not usable without support for the algorithm. I suppose if the implementation stored keys in a backend that needed to know the individual key parameters that would be different. > >3. Key fingerprint depends on data unrelated to the actual key (namely: > >creation date). > > > >This prevents solutions when signature keys are generated on the fly (e.g. > >directly from a passphrase), as the key creation (or, in this case, key > >registration) date is not available at the time of signing, thus making it > >impossible to put am unambiguous reference to the public key into the > >signature. > > Not impossible, but I'll agree, crufty. One could use a fixed creation date. Some people want to include things in the key fingerprint and some don't. There are good reasons for both, so I favor v5 keys with optional subpackets like v4 signatures. Within reason, it's a "make everyone happy" solution. David From owner-ietf-openpgp@mail.imc.org Wed Sep 21 10:30:23 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5c7-0007K5-TD for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 10:30:23 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24435 for ; Wed, 21 Sep 2005 10:30:21 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCmPUG080687; Wed, 21 Sep 2005 05:48:25 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LCmPDt080686; Wed, 21 Sep 2005 05:48:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCmOCe080678 for ; Wed, 21 Sep 2005 05:48:24 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AACDE33C1A; Wed, 21 Sep 2005 13:48:23 +0100 (BST) Message-ID: <43315698.4030607@algroup.co.uk> Date: Wed, 21 Sep 2005 13:48:24 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" CC: OpenPGP Subject: Re: Bigger DSA keys References: <20050920014429.2762157EF5@finney.org> <20050920083438.GA2105@bitchcake.off.net> <20050920085432.GC24261@epointsystem.org> In-Reply-To: <20050920085432.GC24261@epointsystem.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > On Tue, Sep 20, 2005 at 04:34:38AM -0400, Adam Back wrote: > > >>Could one not use the Lim Lee safe prime generation method for DSA? >> >>It has significant speed advantages. >> >>Adam > > > DSS explicitly specifies how to generate primes for DSA keys. It can be > easily generalized for larger keys and other hash functions, and its > reasonable to assume that the new DSS will do that. > > My estimates were based on that specification. You only have to follow DSS if you want FIPS-140 and the like, of course. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Wed Sep 21 13:00:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI7xX-0000I5-Uy for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:00:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04682 for ; Wed, 21 Sep 2005 13:00:36 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGLZ85003687; Wed, 21 Sep 2005 09:21:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGLZvY003686; Wed, 21 Sep 2005 09:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGLYRb003679 for ; Wed, 21 Sep 2005 09:21:35 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 65AA02B47E9; Wed, 21 Sep 2005 18:21:32 +0200 (CEST) Date: Wed, 21 Sep 2005 18:21:31 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921162119.GA10971@epointsystem.org> References: <20050920053207.GA5245@epointsystem.org> <433151EB.6050805@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433151EB.6050805@algroup.co.uk> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 01:28:27PM +0100, Ben Laurie wrote: > I don't understand this attack. It's the well-known Klima-Rosa attack. It has been discussed earlier on this list. > >2. No explicit count of MPIs constituting the key material (both public and > >private). > > > >This information can only be inferred from the algorithm specifier, meaning > >that any implementation that wants to perform key management must have some > >rudimentary knowledge about all public key algorithms. This, in turn, > >hampers forward-compatibility. > > This appears to me to be incorrect - an implementation that didn't know > the algorithm could still deduce the number of MPIs by parsing the > packet until it is exhausted. Except for private key packets. > This would mean introducing a requirement > that all public key parameters were MPIs, of course. That, too. > >3. Key fingerprint depends on data unrelated to the actual key (namely: > >creation date). > > > >This prevents solutions when signature keys are generated on the fly (e.g. > >directly from a passphrase), as the key creation (or, in this case, key > >registration) date is not available at the time of signing, thus making it > >impossible to put am unambiguous reference to the public key into the > >signature. > > Not impossible, but I'll agree, crufty. One could use a fixed creation date. That's a horrible cruft breaking all sorts of things (validity period, etc.). I like Dave's suggestion about adding optional subpackets, similar to those in signatures. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 13:15:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8Bm-00047p-Fy for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:15:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05412 for ; Wed, 21 Sep 2005 13:15:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGcEDU005861; Wed, 21 Sep 2005 09:38:14 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGcE13005860; Wed, 21 Sep 2005 09:38:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGcDGc005852 for ; Wed, 21 Sep 2005 09:38:13 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 993F02B4806; Wed, 21 Sep 2005 18:36:48 +0200 (CEST) Date: Wed, 21 Sep 2005 18:36:48 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921163646.GB10971@epointsystem.org> References: <20050920053207.GA5245@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920053207.GA5245@epointsystem.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Oh, one item that I forgot to include in my list: Encrypted private key packets are superfluous, IMO. Internally, it can be up to the implementation how it secures private keys (as it varies from situation to situation what the requirements and environmental assumptions are), while for interoperability, it's perfectly secure to export unencrypted private key packets (and the auxiliary stuff) within an MDC-protected encrypted data packet, with some ESK in front of it. This way, designers and implementers would only need to worry only about the security of one MDC-protected encrypted data packet format, instead of two, slightly different ones. The only capability that would be lost is exporting and importing private keys without knowing the corresponding passphrases, but I can't imagine legitimate uses for that anyway, while such an action may well be part of some more sophisticated active attack. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 13:15:22 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8Bm-00047o-Jz for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:15:22 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05413 for ; Wed, 21 Sep 2005 13:15:18 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGaeu1005609; Wed, 21 Sep 2005 09:36:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGaeod005608; Wed, 21 Sep 2005 09:36:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGaeUL005602 for ; Wed, 21 Sep 2005 09:36:40 -0700 (PDT) (envelope-from frantz@pwpconsult.com) Received: from [68.164.87.96] (helo=[192.168.1.5]) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1EI7aJ-0000Gs-Ra for ietf-openpgp@imc.org; Wed, 21 Sep 2005 12:36:40 -0400 Date: Wed, 21 Sep 2005 09:36:37 -0700 From: Bill Frantz Subject: Re: Bigger DSA keys To: ietf-openpgp@imc.org X-Priority: 3 In-Reply-To: <432D5936.5020701@algroup.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: Mailsmith 2.1.5 (Blindsider) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c952702934c0bba4bd40b011a7917318350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.87.96 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8LGaeUL005603 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On 9/18/05, ben@algroup.co.uk (Ben Laurie) wrote: > >Ian G wrote: >> Numbers? > >I was going to provide them, but accurate numbers for DSA is difficult, >because it requires modifying the core code in OpenSSL (or some other >DSA generator), and I couldn't be bothered. > >One can get a feel for it with: > >time openssl gendh I'm not sure, based on these numbers, that this benchmark procedure is reproducible enough to give valid data with only one sample per prime size. However, here is what I got. On a Mac G4/450MHz running OS 10.3.9: [G4:~] billfran% time openssl gendh 512 ... 9.850u 0.170s 0:18.39 54.4% 0+0k 3+7io 0pf+0w [G4:~] billfran% time openssl gendh 1024 ... 11.920u 0.070s 0:13.19 90.9% 0+0k 0+3io 0pf+0w [G4:~] billfran% time openssl gendh 2048 ... 5909.970u 24.060s 1:45:08.60 94.0% 0+0k 0+4io 0pf+0w [G4:~] billfran% time openssl gendh 3072 ... 21017.450u 166.540s 6:42:28.96 87.7% 0+0k 0+3io 0pf+0w Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 From owner-ietf-openpgp@mail.imc.org Wed Sep 21 13:16:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8CX-0004G4-8C for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:16:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05446 for ; Wed, 21 Sep 2005 13:16:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGg0IP006194; Wed, 21 Sep 2005 09:42:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGg07L006193; Wed, 21 Sep 2005 09:42:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGfx5e006183 for ; Wed, 21 Sep 2005 09:42:00 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id D33212B47DD; Wed, 21 Sep 2005 18:41:57 +0200 (CEST) Date: Wed, 21 Sep 2005 18:41:56 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921164155.GC10971@epointsystem.org> References: <20050920053207.GA5245@epointsystem.org> <433151EB.6050805@algroup.co.uk> <20050921125619.GB15822@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921125619.GB15822@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 08:56:19AM -0400, David Shaw wrote: > You could also do what GnuPG does - if it doesn't know the algorithm > it just reads the entire list of MPIs (or anything else in the packet) > into an opaque buffer. I suppose it could figure out the MPIs, but > there seems to be little point since either way, the key is not usable > without support for the algorithm. I suppose if the implementation > stored keys in a backend that needed to know the individual key > parameters that would be different. That's what I actually do. But I don't like it. From an OO perspective, it makes certain abstractions less efficient. > Some people want to include things in the key fingerprint and some > don't. There are good reasons for both, so I favor v5 keys with > optional subpackets like v4 signatures. Within reason, it's a "make > everyone happy" solution. Excellent idea! Maybe, we can use a common set of subpackets, where some make sense only in signatures while others only in keys. There are too many overlaps for warranting a separate design. -- Daniels From owner-ietf-openpgp@mail.imc.org Wed Sep 21 13:29:32 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8PU-0001Gq-Dl for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:29:32 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06532 for ; Wed, 21 Sep 2005 13:29:29 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGqhNb007032; Wed, 21 Sep 2005 09:52:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGqhst007031; Wed, 21 Sep 2005 09:52:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGqgwZ007024 for ; Wed, 21 Sep 2005 09:52:42 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 74FAA57EF5; Wed, 21 Sep 2005 09:52:33 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-Id: <20050921165233.74FAA57EF5@finney.org> Date: Wed, 21 Sep 2005 09:52:33 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let me give my responses to Daniel's points about V4 key packets. First I want to mention that Ian seemed to take a much larger view and wanted to redesign the whole of the OpenPGP format. V4 to V5 key packets is only one small part of the spec. No one is proposing to redo OpenPGP from scratch here. > 1. No cryptographic binding between the encrypted private key material and > the public key material. > > This results in a serious security issue, by allowing an attacker to replace > the public material thus compromising the private material with the first > use in the signature. There are various stop-gap measures to deal with this > attack, but the only sure protetction would be some MDC binding together the > private and the public key material. This is a very good point, and it is a little different from the previous attacks. If we had thought of it, we would have tried to fix it when we added the checksum over the private key material. The previous attack involved modifying some private key material and causing the signature algorithm to fail. In RSA keys, if you hack just one of p or q and get it to do the signature using the Chinese Remainder Theorem (CRT), the resulting value can leak the other of p or q and therefore leak your private key. To defend against this we added a SHA-1 hash over the private material as a checksum. Daniel proposes an extension to the attack where the private key material is left alone and the public material (in the private key packet) is modified. I don't think this would do anything on RSA keys, as the CRT based signature algorithm does not use the public modulus or exponent. However it would be effective against DSA keys. The attacker could change p and q to be much smaller values, such that discrete logs were feasible, then request a DSA signature using these values, solve the discrete log and reveal x (the private value) mod q. Do this a few times with different q's would reveal x. Had we thought about this, we could easily have had the SHA-1 hash cover the public as well as the private key material, but we didn't, unfortunately. Putting some size-based sanity checks in the DSA signature code might be a good idea though. I don't know if there are other variations on the attack that could also be addressed for now with sanity checks. > 2. No explicit count of MPIs constituting the key material (both public and > private). > > This information can only be inferred from the algorithm specifier, meaning > that any implementation that wants to perform key management must have some > rudimentary knowledge about all public key algorithms. This, in turn, > hampers forward-compatibility. I am inclined to agree with David that there is not much point to being able to parse a packet's details when we can't do anything useful with it. > 3. Key fingerprint depends on data unrelated to the actual key (namely: > creation date). > > This prevents solutions when signature keys are generated on the fly (e.g. > directly from a passphrase), as the key creation (or, in this case, key > registration) date is not available at the time of signing, thus making it > impossible to put am unambiguous reference to the public key into the > signature. Yes, this has hurt our PGP implementation when dealing with foreign keys such as X.509 certificates. If we want to import a raw modulus+exponent pair as a PGP key, and we want to know if we already have one on the keyring, we can't easily compute a fingerprint and look for a match, because creation date affects fingerprints. I agree that fingerprints should just be over the formatted key material. > 4. More generally, creation time does not belong to the key packet. > > Because it is just an attribute of the key as any other, thus belonging to > certificatiton signature sub-packets, rather than the key packet. I like David's idea better to have some sub-packets in the V5 key. I would like to see immutable material put there. One thing that bothers me in the current V4 is that the key's expiration date can be changed by updating the self-signature. Suppose your key has expired and you don't use it any more. As a result perhaps you don't protect it that well. If someone gets hold of the private part, they can issue a new self-sig with a new expiration date and bring this dead key back to life. It would be better if a dead key would stay dead. Expiration date and creation date would be better placed in the key packet, IMO (as they were with V3 keys). Hal Finney From owner-ietf-openpgp@mail.imc.org Wed Sep 21 13:49:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI8iT-0007i2-C2 for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 13:49:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07432 for ; Wed, 21 Sep 2005 13:49:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LHLZlj010244; Wed, 21 Sep 2005 10:21:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LHLZe0010243; Wed, 21 Sep 2005 10:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LHLYWY010235 for ; Wed, 21 Sep 2005 10:21:34 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EI8O3-0000V0-6a for ; Wed, 21 Sep 2005 19:28:03 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EI8FG-0003CL-Dg; Wed, 21 Sep 2005 19:18:58 +0200 To: hal@finney.org ("Hal Finney") Cc: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format References: <20050921165233.74FAA57EF5@finney.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 21 Sep 2005 19:18:58 +0200 In-Reply-To: <20050921165233.74FAA57EF5@finney.org> (Hal Finney's message of "Wed, 21 Sep 2005 09:52:33 -0700 (PDT)") Message-ID: <87aci6nxtp.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 21 Sep 2005 09:52:33 -0700 (PDT), "Hal Finney" said: > be better if a dead key would stay dead. Expiration date and creation > date would be better placed in the key packet, IMO (as they were with > V3 keys). We discussed this issue a long time ago and came to the conclusion that both kinds of exiration dates make a lot of sense. Prolonging the expiration time is something what quite some users are doing now on a regular basis. If nothing else it helps against a lost passphrase. The suggestion was that we put a hard-expiration into a v5 key packet but keep the existing soft-expiration in the self-signature. Salam-Shalom, Werner From owner-ietf-openpgp@mail.imc.org Wed Sep 21 16:26:27 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBAh-0003bA-Qz for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 16:26:27 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26581 for ; Wed, 21 Sep 2005 16:26:25 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJnFfF024550; Wed, 21 Sep 2005 12:49:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LJnFSj024549; Wed, 21 Sep 2005 12:49:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJnE0f024539 for ; Wed, 21 Sep 2005 12:49:14 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 3C3C42B47EA; Wed, 21 Sep 2005 21:49:13 +0200 (CEST) Date: Wed, 21 Sep 2005 21:49:13 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921194913.GA10842@epointsystem.org> References: <20050921165233.74FAA57EF5@finney.org> <87aci6nxtp.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87aci6nxtp.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 07:18:58PM +0200, Werner Koch wrote: > The suggestion was that we put a hard-expiration into a v5 key packet > but keep the existing soft-expiration in the self-signature. I think, David's subpacket solution accomodates for this without being overly restrictive. If you want to make sure your key stays dead after expiration, you put a hashed expiration date subpacket into your key. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 16:31:44 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBFo-0008PX-4M for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 16:31:44 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27056 for ; Wed, 21 Sep 2005 16:31:41 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJugW6025241; Wed, 21 Sep 2005 12:56:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LJug0q025240; Wed, 21 Sep 2005 12:56:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJuevi025234 for ; Wed, 21 Sep 2005 12:56:41 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 4F9662B47ED; Wed, 21 Sep 2005 21:56:38 +0200 (CEST) Date: Wed, 21 Sep 2005 21:56:38 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921195621.GB10842@epointsystem.org> References: <20050921165233.74FAA57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921165233.74FAA57EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 09:52:33AM -0700, "Hal Finney" wrote: > > 3. Key fingerprint depends on data unrelated to the actual key (namely: > > creation date). > > Yes, this has hurt our PGP implementation when dealing with foreign keys > such as X.509 certificates. If we want to import a raw modulus+exponent > pair as a PGP key, and we want to know if we already have one on the > keyring, we can't easily compute a fingerprint and look for a match, > because creation date affects fingerprints. I agree that fingerprints > should just be over the formatted key material. > > > 4. More generally, creation time does not belong to the key packet. > > > > Because it is just an attribute of the key as any other, thus belonging to > > certificatiton signature sub-packets, rather than the key packet. > > I like David's idea better to have some sub-packets in the V5 key. Me too. > I would like to see immutable material put there. One thing that bothers > me in the current V4 is that the key's expiration date can be changed by > updating the self-signature. Suppose your key has expired and you don't > use it any more. As a result perhaps you don't protect it that well. > If someone gets hold of the private part, they can issue a new self-sig > with a new expiration date and bring this dead key back to life. It would > be better if a dead key would stay dead. Expiration date and creation > date would be better placed in the key packet, IMO (as they were with > V3 keys). Careful! If this information is not part of the fingerprint/keyID it can still be changed by updating the self-signature, no matter whether it's in thte signature packet or in the key packet. David's idea with sub-packets should be implemented in such a way that hashed sub-packets are part of the fingerprint. Maybe, we don't even need unhashed sub-packets. If you're importing a foreign key or generating one on the fly, you don't put subpackets into the key that cannot be determined next time you use the same source to get the key. A flag in a subpacket indicating where the key comes from might be useful, though. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 16:57:57 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBfB-0000Q7-38 for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 16:57:57 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00245 for ; Wed, 21 Sep 2005 16:57:54 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LKMgll027954; Wed, 21 Sep 2005 13:22:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LKMgtL027953; Wed, 21 Sep 2005 13:22:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LKMgmV027939 for ; Wed, 21 Sep 2005 13:22:42 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005092120221201400oggeke>; Wed, 21 Sep 2005 20:22:13 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8LKMD0m021641 for ; Wed, 21 Sep 2005 16:22:13 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8LKM8wn018152 for ; Wed, 21 Sep 2005 16:22:08 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8LKM8bl018151 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 16:22:08 -0400 Date: Wed, 21 Sep 2005 16:22:08 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050921202208.GB18050@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is my original mail about V5 and keys with subpackets. Since V5 is being discussed now, it seems reasonable to repost. David ----- Forwarded message from David Shaw ----- Date: Mon, 21 Feb 2005 12:11:31 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Some thoughts on a v5 key and why it shouldn't be a mess Mail-Followup-To: ietf-openpgp@imc.org OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc I had around 10 hours in a car this weekend, which gave me a good bit of time to think some more about the v5 key idea. I don't see this as a "drop everything and do v5" suggestion. It's more of a "design v5 in 2005, because we need it a few years from now". Attacks only get better, and if we want to be able to shrug off a future SHA-1 break like we were able to shrug off the MD5 break, we need to start the process. While this is prompted by the SHA-1 problems, note that NIST was already replacing SHA-1 with the SHA-2 family by 2010 for size reasons. Even if the recent SHA-1 problems hadn't happened, I'd still think it was time to start designing a v5 key. I don't think there needs to be a lot of fear over a version number bump. To be sure, the change from v3 to v4 was disruptive. In one step, the packet format, the default symmetric cipher, and the public-key algorithm was changed. Even the concept of a key was altered by adding subkeys. I'm not criticizing - the changes were necessary for many reasons, but unfortunately they also split the user base into "before" and "after", with interoperability problems between the two groups. In some (occasionally frustrating) corners, the change hasn't even happened yet. I don't see the change from v4 to v5 being nearly as disruptive as the v3 to v4 change. The straw proposal I'm putting forth here is an incremental change over v4, large enough to be worth doing, small enough that if the change is done carefully, it should be painless. v4 and the proposed v5 can also quite happily co-exist without anyone noticing or caring. Note that I'm not talking about making a v5 signature at this point. Here is a proposed packet format for a v5 key, interspersed with comments. Obviously, not every detail is given, but the general ideas should be clear: - A one-octet version number (5). - A one-octet hash algorithm number. This is an attempt to balance Jon's comments about 160 bits being all that a human user can handle for a fingerprint, and the desire to not be locked to SHA-1 in case of future trouble. Essentially you set this value to the fingerprint hash you want to use for this key. The value itself is hashed into the fingerprint (and signatures on the key), so it cannot be changed once the key is generated. Is is possible for different v5 key fingerprints to be of different lengths. A v5 fingerprint is written "algo - colon - data", like 2:12 34 56 78 9A BC DE F0 ...(etc). The v5 keyid concept is the same as v4: the keyid is the lower 32 or 64 bits of the fingerprint, however long it may be. There are some problems with this idea, not least that any implementation that doesn't understand the hash algorithm won't be able to use the key. It may well be better to lock this value to SHA-256 and be done with it. - A two-octet scalar octet count for the following subpacket data. Note that this is the length in octets of all of the hashed subpackets; a pointer incremented by this number will skip over the subpackets. - Subpacket data. Yes, v5 keys have subpackets. It's a bit of future-proofing since it is a lot easier to add a subpacket than it is to go to a v6 key format. Note that there are no "unhashed" subpackets here. All subpackets are hashed into the fingerprint, and therefore are fixed at key generation time. The subpacket numbers do not need to be the same as signature subpackets, but the encoding format is the same, and the critical bit has the same meaning here as it does for signatures. Only one subpacket comes to mind at the moment, and that is: Expiration time (4 octet time field) The validity period limit of the key. This is the number of seconds after the key creation time that the key must expire by. If this is not present or has a value of zero, the key has no hard expiration. This gives a "hard" expiration time which cannot be extended, unlike the current "soft" expiration in v4. There were a number of disagreements over the v4 soft expirations, and while it's an interesting discussion, at the end of the day there are good reasons to support both. In practice, this key subpacket sets a hard limit on the lifetime of a key, and any soft expirations can only affect the lifetime of the key up to that hard point. No hard expiration acts just like v4. Users can mix the two to give whatever semantics they want. - A four-octet number denoting the time that the key was created. This might be better as a subpacket, but then implementers would have to deal with the case if it was missing. - A one-octet number denoting the public key algorithm of this key. - A series of multiprecision integers comprising the key material. Same as v4. There is no need to change MPIs around. There are only so many ways to store large numbers in a row. The v5 secret keys, like the v4 secret keys, are the same as the public key with the secret material appended. An additional change, which is not part of the key packet format is that v5 keys have AES as both their "last resort" and "must implement" ciphers. When encrypting to v4 and v5 keys together, the default cipher is 3DES. One way to look at this is that cipher preferences on a v5 key have "AES, 3DES" implicitly at the end if not explicitly used earlier. When combined with the implicit "3DES" already at the end of a v4 preference list, the right thing will happen automatically. Note that while AES is the "must" cipher for v5, implementations that support v4 keys must also implement 3DES. To make the transition from v4 to v5 as invisible as possible, I'd suggest having read support for this in implementations for as long as possible (say, 1 year) before allowing users to create these keys. This gives time for upgrading (and there will be a certain amount of upgrading for other reasons during that time as well, which the v5 keys can be included with), and for various other processes that interact with OpenPGP like keyservers to be updated. I also suggest that this not be a part of 2440bis. The v5 discussions will undoubtedly take a while, and delaying 2440bis for an unknown (but probably long) period of time seems a shame. Anyway, this is a starting point. Please thow darts and make suggestions. David ----- End forwarded message ----- From owner-ietf-openpgp@mail.imc.org Wed Sep 21 16:58:10 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIBfO-0000SI-As for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 16:58:10 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00276 for ; Wed, 21 Sep 2005 16:58:06 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LKJbkg027694; Wed, 21 Sep 2005 13:19:38 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LKJbxZ027693; Wed, 21 Sep 2005 13:19:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.76.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LKJbl6027682 for ; Wed, 21 Sep 2005 13:19:37 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005092120192801400jq001e>; Wed, 21 Sep 2005 20:19:29 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8LKJW0m021625 for ; Wed, 21 Sep 2005 16:19:32 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8LKJMRD018140 for ; Wed, 21 Sep 2005 16:19:22 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8LKJL74018139 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 16:19:21 -0400 Date: Wed, 21 Sep 2005 16:19:21 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921201921.GA18050@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921165233.74FAA57EF5@finney.org> <20050921195621.GB10842@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921195621.GB10842@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 09:56:38PM +0200, Daniel A. Nagy wrote: > > On Wed, Sep 21, 2005 at 09:52:33AM -0700, "Hal Finney" wrote: > > > > 3. Key fingerprint depends on data unrelated to the actual key (namely: > > > creation date). > > > > Yes, this has hurt our PGP implementation when dealing with foreign keys > > such as X.509 certificates. If we want to import a raw modulus+exponent > > pair as a PGP key, and we want to know if we already have one on the > > keyring, we can't easily compute a fingerprint and look for a match, > > because creation date affects fingerprints. I agree that fingerprints > > should just be over the formatted key material. > > > > > 4. More generally, creation time does not belong to the key packet. > > > > > > Because it is just an attribute of the key as any other, thus belonging to > > > certificatiton signature sub-packets, rather than the key packet. > > > > I like David's idea better to have some sub-packets in the V5 key. > > Me too. > > > I would like to see immutable material put there. One thing that bothers > > me in the current V4 is that the key's expiration date can be changed by > > updating the self-signature. Suppose your key has expired and you don't > > use it any more. As a result perhaps you don't protect it that well. > > If someone gets hold of the private part, they can issue a new self-sig > > with a new expiration date and bring this dead key back to life. It would > > be better if a dead key would stay dead. Expiration date and creation > > date would be better placed in the key packet, IMO (as they were with > > V3 keys). > > Careful! If this information is not part of the fingerprint/keyID it can > still be changed by updating the self-signature, no matter whether it's in > thte signature packet or in the key packet. > > David's idea with sub-packets should be implemented in such a way that > hashed sub-packets are part of the fingerprint. Maybe, we don't even need > unhashed sub-packets. There have been a number of mentions of the key-with-subpackets idea recently, so I'll repost the mail where I first proposed the idea. It has many more details than I mentioned in this thread. In short though, the subpackets are hashed into the fingerprint and any certification signatures (including self signatures). In my proposal there are no unhashed subpackets. In the case of expiration, we would have two different ways to specify expiration. The expiration time hashed into the key is a hard expiration time that cannot be extended. The expiration time in the self-signature is a soft expiration time that can be extended or changed whenever desired - but only up to the hard limit given in the key itself. David From owner-ietf-openpgp@mail.imc.org Wed Sep 21 17:37:37 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICHZ-0003Fp-ON for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 17:37:37 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03951 for ; Wed, 21 Sep 2005 17:37:34 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LL0HgZ034028; Wed, 21 Sep 2005 14:00:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LL0H4R034026; Wed, 21 Sep 2005 14:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LL0GG9034020 for ; Wed, 21 Sep 2005 14:00:16 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 769002B47E9; Wed, 21 Sep 2005 23:00:15 +0200 (CEST) Date: Wed, 21 Sep 2005 23:00:15 +0200 To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050921210015.GA2316@epointsystem.org> References: <20050921202208.GB18050@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921202208.GB18050@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As before, I would like to express my concerns about allowing a choice of hash algorithms. Here's some detail: A complete break (feasible reversal) of ANY ONE of the supported hash algorithms would allow generating keys with arbitrary long key IDs, possibly colliding with an attacked key. This was a major problem with v3 and v4 was a giant step in the right direction. This would be a small step backwards. For MDC purposes, it's even worse. Since collisions are of no concern in the case of the key fingerprint and MDC, I would just stick to SHA1 for the time being. Precisely because of this, assuming a full-strength hash function, half of the hash suffices. This is just a remark to the length requirement. 128 bit fingerprints are secure for the forseable future, but using the 160 bit SHA1 (with all its problems), is a reasonable overdesign taking into account what we don't know. Collision resistance is important for signatures and even more so for certifications, but it is of no concern whatsoever for fingerprints and MDC. Where RFC2440 has SHA1 hardwired into the spec, it is completely safe and even somewhat of an overkill. Using Ian's terminology, it's still pareto-secure and even pareto-complete. No alternative would provide more security. Signatures and certifications are a completely different issue altogether. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 17:49:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICTA-0005tK-Ed for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 17:49:36 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04457 for ; Wed, 21 Sep 2005 17:49:33 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLDIY8035056; Wed, 21 Sep 2005 14:13:18 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LLDIjr035055; Wed, 21 Sep 2005 14:13:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLDGZF035049 for ; Wed, 21 Sep 2005 14:13:17 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 2CF192B47DD; Wed, 21 Sep 2005 23:13:16 +0200 (CEST) Date: Wed, 21 Sep 2005 23:13:16 +0200 To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050921211316.GB2316@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry, something being "pareto complete for a particular purpose" is an abuse of Ian's definition. SHA1 is not pareto-complete, but still pareto-secure if collision-resistance is not an issue. There is a number of good papers on truncating hash functions for message authentication and there's a general consensus that at least 80 bits or half of the bits (whichever is more) of a full-stregth hash function are sufficient for medium-term security. For long term, I would upgrade that to 128 bits, and taking into account known and unforseen weeknesses of hash functions, using 160 bits should satisfy even the most paranoid. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 18:04:58 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EICi2-0003DY-6p for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 18:04:58 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05209 for ; Wed, 21 Sep 2005 18:04:55 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLQMTw036632; Wed, 21 Sep 2005 14:26:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LLQM82036631; Wed, 21 Sep 2005 14:26:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLQLlo036625 for ; Wed, 21 Sep 2005 14:26:21 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 09EAF57EF5; Wed, 21 Sep 2005 14:26:13 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-Id: <20050921212613.09EAF57EF5@finney.org> Date: Wed, 21 Sep 2005 14:26:13 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > On Wed, Sep 21, 2005 at 09:52:33AM -0700, "Hal Finney" wrote: > > I would like to see immutable material put there. One thing that bothers > > me in the current V4 is that the key's expiration date can be changed by > > updating the self-signature. Suppose your key has expired and you don't > > use it any more. As a result perhaps you don't protect it that well. > > If someone gets hold of the private part, they can issue a new self-sig > > with a new expiration date and bring this dead key back to life. It would > > be better if a dead key would stay dead. Expiration date and creation > > date would be better placed in the key packet, IMO (as they were with > > V3 keys). > > Careful! If this information is not part of the fingerprint/keyID it can > still be changed by updating the self-signature, no matter whether it's in > thte signature packet or in the key packet. Not exactly, the self-signature would not (by convention) override the information in the key subpackets. So just issuing a new self-signature would not help. What could happen is that someone who got hold of the private material could create a new key packet with the same keyid/fingerprint but with a different expiration date. But(!) the new key would not inherit the signatures on the old key. That is what I was thinking of as important. It would not be valid, it would not be part of the Web of Trust. The idea is that key signatures would cover all of the subpackets, even though fingerprints do not. > David's idea with sub-packets should be implemented in such a way that > hashed sub-packets are part of the fingerprint. Maybe, we don't even need > unhashed sub-packets. > > If you're importing a foreign key or generating one on the fly, you don't > put subpackets into the key that cannot be determined next time you use the > same source to get the key. A flag in a subpacket indicating where the key > comes from might be useful, though. This is a good point, I'll have to think about it. I'm still not sure that covering this material with key fingerprints and keyids is the right thing to do. What would the security threats be from being able to bring a key back to life with the same fingerprint and keyid, but without any signatures on it being valid? Hal Finney From owner-ietf-openpgp@mail.imc.org Wed Sep 21 18:31:42 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EID7t-00036h-PW for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 18:31:42 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07184 for ; Wed, 21 Sep 2005 18:31:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLtC3q040049; Wed, 21 Sep 2005 14:55:12 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LLtCfc040048; Wed, 21 Sep 2005 14:55:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLtBn4040039 for ; Wed, 21 Sep 2005 14:55:12 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <20050921215506015004247re>; Wed, 21 Sep 2005 21:55:06 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8LLt80m021948 for ; Wed, 21 Sep 2005 17:55:08 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8LLt3GE018367 for ; Wed, 21 Sep 2005 17:55:03 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8LLt3hE018366 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 17:55:03 -0400 Date: Wed, 21 Sep 2005 17:55:03 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921215503.GA18343@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921212613.09EAF57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921212613.09EAF57EF5@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote: > > If you're importing a foreign key or generating one on the fly, you don't > > put subpackets into the key that cannot be determined next time you use the > > same source to get the key. A flag in a subpacket indicating where the key > > comes from might be useful, though. > > This is a good point, I'll have to think about it. I'm still not > sure that covering this material with key fingerprints and keyids is > the right thing to do. What would the security threats be from being > able to bring a key back to life with the same fingerprint and keyid, > but without any signatures on it being valid? My original idea with subpackets was that they would be part of the fingerprint, and changing a subpacket was akin to making a whole new key as the fingerprint and key ID (though not the key material) would change. I see some advantages of what you are discussing. It would (somewhat) allow someone to violate a hard expiration date on their key: make the key, get signatures, and then when the key expires, just remake the key. Essentially you can buy an extension on your "hard" expiration time at the cost of losing all of your signatures. The thing is, I can't really decide if that is a threat or a feature... David From owner-ietf-openpgp@mail.imc.org Wed Sep 21 19:34:19 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIE6V-0004kr-8k for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 19:34:19 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10026 for ; Wed, 21 Sep 2005 19:34:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LN0kXR046727; Wed, 21 Sep 2005 16:00:46 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LN0kZQ046726; Wed, 21 Sep 2005 16:00:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LN0i7P046719 for ; Wed, 21 Sep 2005 16:00:45 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id D92882B47DB; Thu, 22 Sep 2005 01:00:43 +0200 (CEST) Date: Thu, 22 Sep 2005 01:00:43 +0200 To: Hal Finney , ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921230038.GA8089@epointsystem.org> References: <20050921212613.09EAF57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921212613.09EAF57EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote: > > Careful! If this information is not part of the fingerprint/keyID it can > > still be changed by updating the self-signature, no matter whether it's in > > thte signature packet or in the key packet. > > Not exactly, the self-signature would not (by convention) override the > information in the key subpackets. So just issuing a new self-signature > would not help. That's not what I meant. If the self-signanture is the only integrity protection measure, then someone in possession of the private part of the key can alter the expiration date in the key packet just as he can alter it in the signature subpacket. If it's hashed with the key ID, changing it would also change the key ID, ergo resulting in a different key. > What could happen is that someone who got hold of the private material > could create a new key packet with the same keyid/fingerprint but with > a different expiration date. But(!) the new key would not inherit the > signatures on the old key. That's correct. > That is what I was thinking of as important. > It would not be valid, it would not be part of the Web of Trust. > The idea is that key signatures would cover all of the subpackets, > even though fingerprints do not. And what about keys that are not part of WoT? In the present standard, I can trust a key not only because someone I trust has signed it, but also because I know the fingerprint. Should we break that? > This is a good point, I'll have to think about it. I'm still not > sure that covering this material with key fingerprints and keyids is > the right thing to do. Me neither, but the more I think about it, the more I am leaning towards giving the choice to the user by having hashed and unhashed subpackets, both of which are signed, but only the hashed ones being included in the fingerprint. But I'll have to think more about it myself. > What would the security threats be from being > able to bring a key back to life with the same fingerprint and keyid, > but without any signatures on it being valid? Well, it depends on the applicatiton and the user's trust model. What I like most about OpenPGP is the flexibility of the trust model. Ignoring the WoT is certainly an option I would like to have. -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 19:35:30 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIE7e-00050O-Cy for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 19:35:30 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10071 for ; Wed, 21 Sep 2005 19:35:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LN3MnB046890; Wed, 21 Sep 2005 16:03:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LN3M5r046889; Wed, 21 Sep 2005 16:03:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LN3LBj046881 for ; Wed, 21 Sep 2005 16:03:22 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id E3D302B47DB; Thu, 22 Sep 2005 01:03:20 +0200 (CEST) Date: Thu, 22 Sep 2005 01:03:20 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921230320.GB8089@epointsystem.org> References: <20050921212613.09EAF57EF5@finney.org> <20050921215503.GA18343@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921215503.GA18343@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 05:55:03PM -0400, David Shaw wrote: > The thing is, I can't really decide if that is a threat or a > feature... In such cases isn't the best policy to let the users and/or implementers decide for themselves? How about having hashed and unhashed subpackets just like in v4 signatures, where all are subject to signatures but only the hashed ones are included in the fingerprint? -- Daniel From owner-ietf-openpgp@mail.imc.org Wed Sep 21 19:59:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIEUj-0003Bh-8h for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 19:59:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11066 for ; Wed, 21 Sep 2005 19:59:19 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LNORiA049141; Wed, 21 Sep 2005 16:24:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LNOR1l049140; Wed, 21 Sep 2005 16:24:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LNOQUm049134 for ; Wed, 21 Sep 2005 16:24:26 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 3AE50A3491 for ; Wed, 21 Sep 2005 16:24:26 -0700 (PDT) Received: from mailserver5.hushmail.com (mailserver5.hushmail.com [65.39.178.19]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 21 Sep 2005 16:24:25 -0700 (PDT) Received: by mailserver5.hushmail.com (Postfix, from userid 65534) id A64E933C58; Wed, 21 Sep 2005 16:24:25 -0700 (PDT) Date: Wed, 21 Sep 2005 16:24:22 -0700 To: Subject: Re: Problems with v4 key packet format From: Message-Id: <20050921232425.A64E933C58@mailserver5.hushmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 21 Sep 2005 14:55:03 -0700 David Shaw wrote: > It >would >(somewhat) allow someone to violate a hard expiration date on >their >key: make the key, get signatures, and then when the key expires, >just >remake the key. Essentially you can buy an extension on your >"hard" >expiration time at the cost of losing all of your signatures. > >The thing is, I can't really decide if that is a threat or a >feature... to the unsuspecting users who thought that an 'expired' key is *really* expired, it would be confusing to have someone claim, "i 'revived' it, it was dead, but it's better now, just re-sign it and trust it again ..." so, while not really a threat, and not really a feature, it potentially could add to the confusion of the key trust issue, rather than simplify it... vedaal Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 From owner-ietf-openpgp@mail.imc.org Wed Sep 21 22:17:45 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIGef-0007Vv-4k for openpgp-archive@megatron.ietf.org; Wed, 21 Sep 2005 22:17:45 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA16658 for ; Wed, 21 Sep 2005 22:17:38 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M0m8jt055559; Wed, 21 Sep 2005 17:48:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8M0m82q055558; Wed, 21 Sep 2005 17:48:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M0m7PN055548 for ; Wed, 21 Sep 2005 17:48:07 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc12) with ESMTP id <200509220048010140010bb8e>; Thu, 22 Sep 2005 00:48:01 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8M0m40m022410 for ; Wed, 21 Sep 2005 20:48:04 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8M0lwtX018613 for ; Wed, 21 Sep 2005 20:47:58 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8M0lwlw018612 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 20:47:58 -0400 Date: Wed, 21 Sep 2005 20:47:58 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050922004758.GA18468@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921212613.09EAF57EF5@finney.org> <20050921215503.GA18343@jabberwocky.com> <20050921230320.GB8089@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921230320.GB8089@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 01:03:20AM +0200, Daniel A. Nagy wrote: > > On Wed, Sep 21, 2005 at 05:55:03PM -0400, David Shaw wrote: > > > The thing is, I can't really decide if that is a threat or a > > feature... > > In such cases isn't the best policy to let the users and/or implementers decide > for themselves? How about having hashed and unhashed subpackets just like in > v4 signatures, where all are subject to signatures but only the hashed ones > are included in the fingerprint? I think this might cause some serious user confusion. With both types of subpackets, plus the existing v4 signature subpackets, we would have three different ways to specify expiration, each with a slightly different meaning: key-subpacket-in-fingerprint: hard expiration date. All other expiration dates can only be extended to this point. Changing it changes the fingerprint and key ID. key-subpacket-in-signature: soft expiration date. Changing it invalidates all signatures, but does not change the fingerprint/key ID. regular-old-selfsig: very soft expiration date. Can be changed at any time with no impact on anything but the expiration date. Then we have various combinations of the above... David From owner-ietf-openpgp@mail.imc.org Thu Sep 22 01:06:40 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIJI8-0001Hl-7k for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 01:06:40 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23443 for ; Thu, 22 Sep 2005 01:06:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M4Tv9p074436; Wed, 21 Sep 2005 21:29:57 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8M4TvFd074435; Wed, 21 Sep 2005 21:29:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M4TuIp074428 for ; Wed, 21 Sep 2005 21:29:56 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 28FCE2B479A; Thu, 22 Sep 2005 06:29:55 +0200 (CEST) Date: Thu, 22 Sep 2005 06:29:55 +0200 To: ietf-openpgp@imc.org Subject: Plausible deniability (a feature to think about) Message-ID: <20050922042955.GA30473@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just got a message from a human rights activist, who pointed out a shortcoming of PGP for -- for the lack of a better word -- paranoid conspirators. Imagine, that a conspiracy expects to be infiltrated. They send encrypted messages back and forth but they have a dilemma: to sign or not to sign? If they do sign, the infiltrator will have damning evidence on his hands and the bad guys will be able to crack down on the conspirators. If they don't sign, the infiltrator will be able to forge messages and thus seriously interfere with the activities of the group (e.g. call off action in the name of the ringleader, etc.). Now, there exists a cryptographic solution for this problem, moreover, RFC2440 even hints that it might be implemented in OpenPGP, though I have never seen it used: X9.42 Diffie-Hellman key agreement (see also RFC2630, RFC2631 and RFC2633). In addition to signature and encryption keys, one can have a DH subkey which may be used to create a (salted) two-party shared secret session key and send an MDC-protected encnrypted message using that key. Now, the receiving party can be sure that it was composed by the sender, but has no means of proving it to a third party. The sender can plausibly deny authorship, claiming that the receiver has forged it using his private key and the sender's public key. Has anybody ever bothered implementing (or even designing an implementation of) this in an OpenPGP-friendly manner? Seems like it's just a matter of a third ESK type (tentatively called DH-ESK) and a clear definiton of DH keys (for which we have reserved identifier 21), which, I guess, should be identical to ElGamal keys, though it is instrumental that the entie conspiracy used the same modulus and generator element. DH-ESK should be very similar to SK-ESK with a salted (but not iterated) S2K, except for the additional 8-octet IDs of the sender's and the recipient's public DH keys. The usual traffic-analysis thwarting techniques of leaving one or both of them blank obviously apply. Allowing for an ephemeral sender PK to be included is pointless, as that would bring us back to ElGamal encryption (well, almost), for which there is already a PK-ESK. If the MDC verification works out on the receiving end, the implementation should show the message as being "sealed" by the sender on the date from the literal packet, in addition to decrypting it, much like it handles signed+encrypted messages. It's so easy and straightforward that I'd dare to propose it for 2440bis. -- Daniel From owner-ietf-openpgp@mail.imc.org Thu Sep 22 02:27:18 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIKY9-0005Jy-P7 for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 02:27:18 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA09726 for ; Thu, 22 Sep 2005 02:27:16 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M5i09e080861; Wed, 21 Sep 2005 22:44:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8M5i0bn080860; Wed, 21 Sep 2005 22:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M5hwM7080835 for ; Wed, 21 Sep 2005 22:43:59 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 25ECF34F33; Thu, 22 Sep 2005 17:43:53 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07132-10; Thu, 22 Sep 2005 17:43:53 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id DBAD834F32; Thu, 22 Sep 2005 17:43:52 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 42A6237756; Thu, 22 Sep 2005 17:43:52 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EIJsD-0008KQ-00; Thu, 22 Sep 2005 17:43:57 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: Plausible deniability (a feature to think about) In-Reply-To: <20050922042955.GA30473@epointsystem.org> Message-Id: Date: Thu, 22 Sep 2005 17:43:57 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: nagydani@epointsystem.org (Daniel A. Nagy) writes: >Now, there exists a cryptographic solution for this problem, moreover, >RFC2440 even hints that it might be implemented in OpenPGP, though I have >never seen it used: X9.42 Diffie-Hellman key agreement (see also RFC2630, >RFC2631 and RFC2633). X9.42 was only added to S/MIME for political reasons. AFAIK only one implementation ever supported it, and that was the USG-funded reference implementation that was required to support it. In addition, MS supported a read-only implementation just so they couldn't be accused of not supporting it. (I remember having a conversation with a rather baffled security application developer who wanted to see X9.42 in an S/MIME toolkit and just couldn't understand that although the spec had it as a MUST requirement, all the implementors knew that you should ignore it). >Has anybody ever bothered implementing (or even designing an implementation >of) this in an OpenPGP-friendly manner? See above. Peter. From owner-ietf-openpgp@mail.imc.org Thu Sep 22 08:03:48 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIPno-0004fZ-ER for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 08:03:48 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24936 for ; Thu, 22 Sep 2005 08:03:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MBSamN013342; Thu, 22 Sep 2005 04:28:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MBSa4h013341; Thu, 22 Sep 2005 04:28:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ethos.braverock.com (ethos.braverock.com [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MBSZ5S013334 for ; Thu, 22 Sep 2005 04:28:35 -0700 (PDT) (envelope-from brian@braverock.com) Received: from [10.23.2.104] (dsl017-021-008.chi1.dsl.speakeasy.net [69.17.21.8]) (authenticated bits=0) by ethos.braverock.com (8.13.3/8.13.1) with ESMTP id j8MBSYGf012553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 22 Sep 2005 06:28:34 -0500 From: "Brian G. Peterson" To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Date: Thu, 22 Sep 2005 06:28:33 -0500 User-Agent: KMail/1.8.1 References: <20050922042955.GA30473@epointsystem.org> In-Reply-To: <20050922042955.GA30473@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509220628.33636.brian@braverock.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday 21 September 2005 11:29 pm, Daniel A. Nagy wrote: > I just got a message from a human rights activist, who pointed out a > shortcoming of PGP for -- for the lack of a better word -- paranoid > conspirators. > > Imagine, that a conspiracy expects to be infiltrated. They send encrypted > messages back and forth but they have a dilemma: to sign or not to sign? If > they do sign, the infiltrator will have damning evidence on his hands and > the bad guys will be able to crack down on the conspirators. If they don't > sign, the infiltrator will be able to forge messages and thus seriously > interfere with the activities of the group (e.g. call off action in the > name of the ringleader, etc.). <...> >The sender can plausibly deny authorship, claiming that the receiver has >forged it using his private key and the sender's public key. Interesting thought experiement. I led the development team of the solution used by the CryptoRights Foundation http://www.cryptorights.org/ our solution consisted of management tools, user interfaces, translations, and other niceties around a gnupg based engine. We were most concerned with chain of evidence and verifiability, not plausible deniability. In the real world, most human rights organizations already have extensive methods of verifying information that is provided to them, and informers have elaborate methods of communicating that information, that only rarely involves electronic communication, encrypted or otherwise, becasue of the danger of interception. In a country (like China) where much/most private use of encryption is disallowed anyway, sending *any* encrypted message is a risk that most human rights workers and informers will not take. I don't think that OpenPGP needs a new shared-secret method of communication, or that the spec needs another wrinkle for implementors to chew on. Regards, - Brian From owner-ietf-openpgp@mail.imc.org Thu Sep 22 09:59:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIRbp-0006Dy-JU for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 09:59:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01145 for ; Thu, 22 Sep 2005 09:59:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDDDAQ023054; Thu, 22 Sep 2005 06:13:13 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MDDDsY023053; Thu, 22 Sep 2005 06:13:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDDCxq023043 for ; Thu, 22 Sep 2005 06:13:12 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 09DC45ACCC; Thu, 22 Sep 2005 14:13:07 +0100 (BST) Message-ID: <431093A0.90102@systemics.com> Date: Sat, 27 Aug 2005 17:24:00 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: ietf-openpgp@imc.org Subject: Re: Signature types References: <20050827075018.GA17967@epointsystem.org> <20050827135551.GA1832@jabberwocky.com> <20050827152645.GA20223@epointsystem.org> In-Reply-To: <20050827152645.GA20223@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > It's actually RFC1991 that got me wondering: > > <40> - time stamping ("I saw this document") (*) > ... Type <40> is intended to > be a signature of a signature, as a notary seal on a signed document. > > Now, this is contradictory. If a signature does not have any cryptograpic > binding (except the indirect one through the other signature) to the > document, it cannot be used to assert the integrity thereof. > > Someone with the public key of the notary cannot verify this claim. Also, it > makes a lot of sense to certify documents that have not been signed. [snip] >> This signature is a signature over some other OpenPGP >> signature packet(s). It is analogous to a notary seal on the >> signed data. > > > Except that if it's a signature on the signature, then it cannot be > analogous to a notary seal on the signed data (see above). One of the difficulties that may be occuring here is that the word 'notary' has different meanings in civil and common law contexts. In the former, a notary is likely to be interested in the content of the signed data; whereas in the latter, the notary is normally only interested in the quality of the signature, and not the data. We had a long threat on this about a year ago, and I believe some changes were made disambiguate .. I think the context that the Draft uses the word notary is more towards the common law case of just the signature and not the data that is signed. iang From owner-ietf-openpgp@mail.imc.org Thu Sep 22 10:30:01 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIS5I-0006iT-VP for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 10:30:01 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03734 for ; Thu, 22 Sep 2005 10:29:58 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDudbO027449; Thu, 22 Sep 2005 06:56:39 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MDudoa027448; Thu, 22 Sep 2005 06:56:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDuc7d027442 for ; Thu, 22 Sep 2005 06:56:38 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 5F3252B47E4; Thu, 22 Sep 2005 15:56:34 +0200 (CEST) Date: Thu, 22 Sep 2005 15:56:34 +0200 To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-ID: <20050922135632.GA1725@epointsystem.org> References: <20050922042955.GA30473@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 05:43:57PM +1200, Peter Gutmann wrote: > nagydani@epointsystem.org (Daniel A. Nagy) writes: > > >Now, there exists a cryptographic solution for this problem, moreover, > >RFC2440 even hints that it might be implemented in OpenPGP, though I have > >never seen it used: X9.42 Diffie-Hellman key agreement (see also RFC2630, > >RFC2631 and RFC2633). > > X9.42 was only added to S/MIME for political reasons. AFAIK only one > implementation ever supported it, and that was the USG-funded reference > implementation that was required to support it. In addition, MS supported a > read-only implementation just so they couldn't be accused of not supporting > it. What political reasons? And why is there a reserved ID in OpenPGP? > (I remember having a conversation with a rather baffled security application > developer who wanted to see X9.42 in an S/MIME toolkit and just couldn't > understand that although the spec had it as a MUST requirement, all the > implementors knew that you should ignore it). X9.42 may be flawed (is it?), but DH key agreement is one of the strongest primitives in asymmetric cryptography. -- Daniel From owner-ietf-openpgp@mail.imc.org Thu Sep 22 10:58:34 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISWw-0006qb-Dr for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 10:58:34 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05399 for ; Thu, 22 Sep 2005 10:58:31 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MELi6N029311; Thu, 22 Sep 2005 07:21:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MELia1029310; Thu, 22 Sep 2005 07:21:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MELhQg029304 for ; Thu, 22 Sep 2005 07:21:43 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 3E7F7A34DA for ; Thu, 22 Sep 2005 07:21:43 -0700 (PDT) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Thu, 22 Sep 2005 07:21:42 -0700 (PDT) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id j8MELgMq047103 for ; Thu, 22 Sep 2005 07:21:42 -0700 (PDT) (envelope-from vedaal@hush.com) Message-Id: <200509221421.j8MELgMq047103@mailserver3.hushmail.com> Date: Thu, 22 Sep 2005 07:21:39 -0700 To: Subject: Re: Plausible deniability (a feature to think about) From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 21 Sep 2005 21:29:55 -0700 "Daniel A. Nagy" wrote: > Now, >the >receiving party can be sure that it was composed by the sender, >but has no >means of proving it to a third party. The sender can plausibly >deny >authorship, claiming that the receiver has forged it using his >private key >and the sender's public key. >Has anybody ever bothered implementing (or even designing an >implementation >of) this in an OpenPGP-friendly manner? this can easily be accomplished now, within the existing standard, and existing implementations: any two correspondents, can simply make a third keypair, with a third name, and each have the public and private signing and encrypting keys, anything signed with the third key, authenticates only to the correspondents where the receiver knows that the sender signed it, but cannot be proved to any third party, other than the fact that any possessor of the signing key, signed it. many variations of this are possible; new signing subkeys, set to expire within hours of the message time, split key systems with shares set to one, and split to only the receiver and sender keys, etc. vedaal Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 From owner-ietf-openpgp@mail.imc.org Thu Sep 22 11:21:46 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIStO-0004yI-Ks for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 11:21:46 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06383 for ; Thu, 22 Sep 2005 11:21:43 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEjLM1031758; Thu, 22 Sep 2005 07:45:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MEjLmh031757; Thu, 22 Sep 2005 07:45:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEjJwB031726 for ; Thu, 22 Sep 2005 07:45:20 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 11E172B47DB; Thu, 22 Sep 2005 16:45:19 +0200 (CEST) Date: Thu, 22 Sep 2005 16:45:19 +0200 To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-ID: <20050922144518.GA20419@epointsystem.org> References: <20050922042955.GA30473@epointsystem.org> <200509220628.33636.brian@braverock.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509220628.33636.brian@braverock.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 06:28:33AM -0500, Brian G. Peterson wrote: > We were most concerned with chain of evidence and verifiability, not plausible > deniability. Different people have different concerns, I suppose. > In the real world, most human rights organizations already have > extensive methods of verifying information that is provided to them, and > informers have elaborate methods of communicating that information, that only > rarely involves electronic communication, encrypted or otherwise, becasue of > the danger of interception. The "real world" keeps changing. If you can make something cheaper, more reliable, simpler, etc., why stop short of doing so? Also, I am not convinced that what you're stating is universally true. AFAIK, PGP has been quite popular with activists since its very first public releases. > In a country (like China) where much/most > private use of encryption is disallowed anyway, sending *any* encrypted > message is a risk that most human rights workers and informers will not take. The world is not black and white. "Countries like that" are not the only places where basic human rights are under assault, and not even necessarily by the government. There's a large number of considerably less-than-democratic governments that for one reason or another must maintain a democratic facade. And again, the government is not necessarily the threat you're caring about. > I don't think that OpenPGP needs a new shared-secret method of communication, > or that the spec needs another wrinkle for implementors to chew on. It would be obviously optional, and as outlined in the first email of the thread, not much of a trouble to design or implement. Bests, -- Daniel From owner-ietf-openpgp@mail.imc.org Thu Sep 22 11:23:03 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EISuY-0005H8-RG for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 11:23:03 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06464 for ; Thu, 22 Sep 2005 11:22:56 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEqA5n032587; Thu, 22 Sep 2005 07:52:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MEqAkh032586; Thu, 22 Sep 2005 07:52:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEq8pf032580 for ; Thu, 22 Sep 2005 07:52:09 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 4696C2B47DB; Thu, 22 Sep 2005 16:52:08 +0200 (CEST) Date: Thu, 22 Sep 2005 16:52:08 +0200 To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-ID: <20050922145208.GB20419@epointsystem.org> References: <200509221421.j8MELgMq047103@mailserver3.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509221421.j8MELgMq047103@mailserver3.hushmail.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 07:21:39AM -0700, vedaal@hush.com wrote: > this can easily be accomplished now, > within the existing standard, and existing implementations: > > any two correspondents, > can simply make a third keypair, with a third name, > and each have the public and private signing and encrypting keys, Simply? How exactly do you suggest to share a common key so that the parties can be reassured that it's their shared secret? > anything signed with the third key, authenticates only to the > correspondents > where the receiver knows that the sender signed it, > but cannot be proved to any third party, > other than the fact that any possessor of the signing key, signed > it. Actually, once you share some secret, you don't need to use asymmetric crypto anymore. A message with MDC encrypted with a shared symmetric key has all the necessary reassurances. Sharing the secret is the tricky part. > many variations of this are possible; > > new signing subkeys, set to expire within hours of the message > time, Again, how do you share them? > split key systems with shares set to one, and split to only the > receiver and sender keys, etc. I haven't seen split key implementations either in OpenPGP compliant tools, though I know they are mentioned in RFC2440. -- Daniel From owner-ietf-openpgp@mail.imc.org Thu Sep 22 12:28:21 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EITvo-0001mS-AR for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 12:28:21 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09965 for ; Thu, 22 Sep 2005 12:28:17 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MFoeOM038030; Thu, 22 Sep 2005 08:50:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MFoerW038029; Thu, 22 Sep 2005 08:50:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MFod4m038017 for ; Thu, 22 Sep 2005 08:50:39 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id BFFDDA3549 for ; Thu, 22 Sep 2005 08:50:38 -0700 (PDT) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Thu, 22 Sep 2005 08:50:38 -0700 (PDT) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id j8MFocVe057963 for ; Thu, 22 Sep 2005 08:50:38 -0700 (PDT) (envelope-from vedaal@hush.com) Message-Id: <200509221550.j8MFocVe057963@mailserver3.hushmail.com> Date: Thu, 22 Sep 2005 08:50:34 -0700 To: Subject: Re: Plausible deniability (a feature to think about) From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 22 Sep 2005 07:52:08 -0700 "Daniel A. Nagy" wrote: >Simply? How exactly do you suggest to share a common key so that >the parties >can be reassured that it's their shared secret? >> many variations of this are possible; >> >> new signing subkeys, set to expire within hours of the message >> time, > >Again, how do you share them? the sender generates the new keypair, and sends it signed and encrypted, to the receiver it is neither more nor less trustworthy than the primary keys of the sender and receiver, which could also conceivably be given to other parties, >> split key systems with shares set to one, and split to only the >> receiver and sender keys, etc. > >I haven't seen split key implementations either in OpenPGP >compliant tools, >though I know they are mentioned in RFC2440. pgp has had them implemented since 6.x a new type of pgp signature to deal with this issue was proposed by Ian Brown and Adam Back, http://www.cs.ucl.ac.uk/staff/I.Brown/nts.htm where the session key is signed, not the plaintext (don't know if people want to explore this now, or wait until after the rfc 2440 is finalized, and save it for a further update, i would welcome this useful type of signature, as i imagine many users would ) vedaal >-- >Daniel Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 From owner-ietf-openpgp@mail.imc.org Thu Sep 22 13:32:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIUvg-0002re-SR for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 13:32:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12642 for ; Thu, 22 Sep 2005 13:32:14 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MGpFq9042952; Thu, 22 Sep 2005 09:51:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MGpFgc042951; Thu, 22 Sep 2005 09:51:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MGpE7e042945 for ; Thu, 22 Sep 2005 09:51:14 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id EABD057EF5; Thu, 22 Sep 2005 09:51:08 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-Id: <20050922165108.EABD057EF5@finney.org> Date: Thu, 22 Sep 2005 09:51:08 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > Imagine, that a conspiracy expects to be infiltrated. They send encrypted > messages back and forth but they have a dilemma: to sign or not to sign? If > they do sign, the infiltrator will have damning evidence on his hands and > the bad guys will be able to crack down on the conspirators. If they don't > sign, the infiltrator will be able to forge messages and thus seriously > interfere with the activities of the group (e.g. call off action in the name > of the ringleader, etc.). These kinds of stories are often used to motivate cryptographic constructions, but the real world generally doesn't work that way. An infiltrator does not need cryptographic proof of his information about who is in the conspiracy! After all, he doesn't have any such proof in the physical world, yet infiltrators, informants and spies have long been used as valuable sources of information. I admit to a fondness for fancy crypto and it would be fun to see some form of deniable authentication in OpenPGP, but realistically it is not going to meet our customers' needs. If we do want to pursue it, there are a number of technologies, like the DH shared keys you describe, the signed ESK packets Vedaal mentioned, or ring signatures and other variants of Chaum's designated-confirmer signatures. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Sep 22 14:53:17 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWC4-0002QC-W7 for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 14:53:17 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17407 for ; Thu, 22 Sep 2005 14:53:15 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIKarM054593; Thu, 22 Sep 2005 11:20:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MIKa2o054592; Thu, 22 Sep 2005 11:20:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIKZDP054582 for ; Thu, 22 Sep 2005 11:20:35 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 29BE92B47CD; Thu, 22 Sep 2005 20:20:31 +0200 (CEST) Date: Thu, 22 Sep 2005 20:20:29 +0200 To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-ID: <20050922182025.GA2481@epointsystem.org> References: <20050922165108.EABD057EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922165108.EABD057EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 09:51:08AM -0700, "Hal Finney" wrote: > These kinds of stories are often used to motivate cryptographic > constructions, but the real world generally doesn't work that way. > An infiltrator does not need cryptographic proof of his information > about who is in the conspiracy! After all, he doesn't have any such > proof in the physical world, yet infiltrators, informants and spies have > long been used as valuable sources of information. I don't fully agree. Obviously, I wrote the story about the conspiracy and the infiltrator with tongue firmly embedded in cheek. That's a long-standing tradition in the crypto community and I certainly enjoy it. But nevertheless, in many cases the presented scenario is precisely what happens, just there's a lot less pathos surrounding it: The overwhelming majority of "goverment agents" "infiltrating" "conspiracies" are not politically motivated counter-intetlligence operations but tax audits. A tax auditor pretends to be a customer and buys someting. He sure as hell needs a rock-solid third-party proof to crack down on you if you fail to report that income. Now, what is taxed and what is not (by law!) depends on what is easy to tax and what is hard to tax. If something is easy to tax, laws are passed and it gets taxed. If something is hard to tax, if it's necessary for the functioning of the society, it is not taxed, if it's not necessary, then it's outlawed. Right now, e-commerce falls into the hard-to-tax-but-necessary category, but the arms race is on. I'd certainly like it to stay the way it is. While commerce is the single biggest user of crypto, there are other uses, which we cannot even imagine. I don't have any reason to doubt that the activist who wrote me about the missing feature in PGP could really use it. Since ePointSystem is first and foremost a financial cryptography consultancy, the first application on my mind was deniable invoicing. It's a fair choice: either you use undeniable invoices, pay your taxes and resolve your disputes in court relying on government enforcement, or you use deniable invoices, don't pay taxes, and rely solely on reputational self-regulation. I am pretty sure that most e-commerce will get taxed like everything else, as soon as governments sort out their jurisdictional problems. Having working deniable invoices would be a powerful argument in the ensuing debate over taxation policies. > I admit to a fondness for fancy crypto and it would be fun to see some > form of deniable authentication in OpenPGP, but realistically it is not > going to meet our customers' needs. How do you know? In my experience, predicting what people will use your product for is one of the most difficult tasks an engineer or a scientist faces. People are amazingly inventive. > If we do want to pursue it, there > are a number of technologies, like the DH shared keys you describe, > the signed ESK packets Vedaal mentioned, or ring signatures and other > variants of Chaum's designated-confirmer signatures. All of which have slightly different characteristics and are therefore optimal solutions for slightly different problems. In all cases, however, interoperability is a major boon, and thus it's ITEF's business to provide for it, isn't it? DH shared keys and signed ESK packets are both very easy to incorporate into the OpenPGP framework, and if we do it early on, we can hope that different implementations will interoperate right away. -- Daniel From owner-ietf-openpgp@mail.imc.org Thu Sep 22 15:23:53 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWfh-0003bL-Ju for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 15:23:53 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20876 for ; Thu, 22 Sep 2005 15:23:51 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIleVS056698; Thu, 22 Sep 2005 11:47:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MIlewf056697; Thu, 22 Sep 2005 11:47:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIldUr056686 for ; Thu, 22 Sep 2005 11:47:39 -0700 (PDT) (envelope-from konrad@silmor.de) Received: from p54b3db8c.dip.t-dialin.net ([84.179.219.140] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1EIW6X-00071y-00 for ; Thu, 22 Sep 2005 20:47:33 +0200 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Date: Thu, 22 Sep 2005 20:47:05 +0200 User-Agent: KMail/1.8 References: <20050921212613.09EAF57EF5@finney.org> In-Reply-To: <20050921212613.09EAF57EF5@finney.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1822501.mXWWIfq2zu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509222047.06402@zaphod.konrad.silmor.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1822501.mXWWIfq2zu Content-Type: text/plain; charset="iso-8859-15" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wednesday 21 September 2005 23:26, Hal Finney wrote: > This is a good point, I'll have to think about it. I'm still not > sure that covering this material with key fingerprints and keyids is > the right thing to do. What would the security threats be from being > able to bring a key back to life with the same fingerprint and keyid, > but without any signatures on it being valid? It becomes a threat once you get hold of the private key (through some=20 accident, a data leak, whatever) because then you can also issue new=20 self-signatures. I see two possibilities to limit the damage:=20 a) changing the expiration also changes the fingerprint, so the key does no= =20 longer match whatever users have in their keyring and would basically be a= =20 new key.=20 b) changing the expiration breaks ALL signatures (not only self-sig) on the= =20 key. (Actually b must be implemented as well, when a is implemented.) On the other hand: expiration dates are a very weak measure against key=20 abuse (they only limit the damage), un-revocable revocation sigs seem much= =20 more effective to me. Konrad --nextPart1822501.mXWWIfq2zu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDMvwqClt766LaIH0RAg81AJ9YD2xQyzzH7YrH/TXO2wXkT2YEpACdHB1l CDGgQtLGiD/7m2hOcJbLfsw= =gVOb -----END PGP SIGNATURE----- --nextPart1822501.mXWWIfq2zu-- From owner-ietf-openpgp@mail.imc.org Thu Sep 22 15:37:52 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWtE-0006jK-5y for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 15:37:52 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21910 for ; Thu, 22 Sep 2005 15:37:50 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJ0Z2e057707; Thu, 22 Sep 2005 12:00:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJ0Zot057706; Thu, 22 Sep 2005 12:00:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJ0Y0o057696 for ; Thu, 22 Sep 2005 12:00:34 -0700 (PDT) (envelope-from konrad@silmor.de) Received: from p54b3db8c.dip.t-dialin.net ([84.179.219.140] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1EIWJ1-00074L-00 for ; Thu, 22 Sep 2005 21:00:28 +0200 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Date: Thu, 22 Sep 2005 21:00:00 +0200 User-Agent: KMail/1.8 References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> In-Reply-To: <20050921210015.GA2316@epointsystem.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1493410.qBePzIRu3u"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509222100.01040@zaphod.konrad.silmor.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1493410.qBePzIRu3u Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wednesday 21 September 2005 23:00, Daniel A. Nagy wrote: > As before, I would like to express my concerns about allowing a choice of > hash algorithms. Here's some detail: > > A complete break (feasible reversal) of ANY ONE of the supported hash > algorithms would allow generating keys with arbitrary long key IDs, > possibly colliding with an attacked key. This was a major problem with v3 > and v4 was a giant step in the right direction. This would be a small > step backwards. I don't see how this attack would work. Let's say MDX is broken by some genius. =46irst the trivial case:=20 Alices Key A uses MDX as its fingerprint algorithm. The fingerprint looks=20 like: 99:AB 12 34 56 78 90 CD EF... Mallory can now generate an arbitrary key M, that has the same algorithm an= d=20 fingerprint. Now the less trivial: Bobs key B uses MDY (which was not broken). Fingerprint: A0:12 34 56 78... Mallory could attempt to create a key M2 which has the same hash value usin= g=20 MDY as Bobs key using MDX, but the fingerprint would still be different:=20 99:12 34 56 78... I don't see any way for Mallory to compromise Bobs key without changing the= =20 first byte of the fingerprint. So allowing different algorithms AND=20 including their ID in the fingerprint would in my opinion be a good measure= =20 to limit the damage (only Alices key becomes ambiguous, not Bobs) in case=20 of a broken algorithm. Konrad --nextPart1493410.qBePzIRu3u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDMv8xClt766LaIH0RAtNrAJ9DelOcMBWZ87cEhujc9XaCRHvvBgCeMjzN KN5LMmvOmftInwgjeYdvX1w= =GOMT -----END PGP SIGNATURE----- --nextPart1493410.qBePzIRu3u-- From owner-ietf-openpgp@mail.imc.org Thu Sep 22 15:40:29 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIWvk-0007CT-7z for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 15:40:29 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22085 for ; Thu, 22 Sep 2005 15:40:26 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJ6xbf058370; Thu, 22 Sep 2005 12:06:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJ6xHL058369; Thu, 22 Sep 2005 12:06:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJ6wY9058354 for ; Thu, 22 Sep 2005 12:06:59 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005092219065001400oma58e>; Thu, 22 Sep 2005 19:06:50 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8MJ6o0m026505 for ; Thu, 22 Sep 2005 15:06:50 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8MJ6mOG000415 for ; Thu, 22 Sep 2005 15:06:48 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8MJ6mbH000414 for ietf-openpgp@imc.org; Thu, 22 Sep 2005 15:06:48 -0400 Date: Thu, 22 Sep 2005 15:06:48 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050922190648.GD32759@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921212613.09EAF57EF5@finney.org> <200509222047.06402@zaphod.konrad.silmor.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509222047.06402@zaphod.konrad.silmor.de> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 08:47:05PM +0200, Konrad Rosenbaum wrote: > On Wednesday 21 September 2005 23:26, Hal Finney wrote: > > This is a good point, I'll have to think about it. I'm still not > > sure that covering this material with key fingerprints and keyids is > > the right thing to do. What would the security threats be from being > > able to bring a key back to life with the same fingerprint and keyid, > > but without any signatures on it being valid? > > It becomes a threat once you get hold of the private key (through some > accident, a data leak, whatever) because then you can also issue new > self-signatures. > > I see two possibilities to limit the damage: > > a) changing the expiration also changes the fingerprint, so the key does no > longer match whatever users have in their keyring and would basically be a > new key. > > b) changing the expiration breaks ALL signatures (not only self-sig) on the > key. (Actually b must be implemented as well, when a is implemented.) If I understand what Hal was proposing, then b is already true. Self-sigs aren't treated any differently than any other certification signature. > On the other hand: expiration dates are a very weak measure against key > abuse (they only limit the damage), un-revocable revocation sigs seem much > more effective to me. True, but an unrevocable revocation signature can be stripped off the key, so it becomes a key distribution problem. Expiration dates are naturally carried along with the key. David From owner-ietf-openpgp@mail.imc.org Thu Sep 22 15:51:49 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIX6j-0002ER-BK for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 15:51:49 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22750 for ; Thu, 22 Sep 2005 15:51:47 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJIeao059223; Thu, 22 Sep 2005 12:18:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJIeLY059222; Thu, 22 Sep 2005 12:18:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJIdJk059216 for ; Thu, 22 Sep 2005 12:18:39 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0B8988002; Thu, 22 Sep 2005 21:18:37 +0200 (CEST) Date: Thu, 22 Sep 2005 21:18:36 +0200 To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050922191832.GB2481@epointsystem.org> References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> <200509222100.01040@zaphod.konrad.silmor.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509222100.01040@zaphod.konrad.silmor.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 09:00:00PM +0200, Konrad Rosenbaum wrote: > Let's say MDX is broken by some genius. Remember, that the key ID is the last 8 (or four) byes of the fingerprint. If MDX is broken, one can generatet a key with an arbitrary ID. -- Daniel From owner-ietf-openpgp@mail.imc.org Thu Sep 22 16:31:26 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIXj4-0002YZ-4X for openpgp-archive@megatron.ietf.org; Thu, 22 Sep 2005 16:31:26 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24658 for ; Thu, 22 Sep 2005 16:31:23 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJvHUl062903; Thu, 22 Sep 2005 12:57:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJvH5U062902; Thu, 22 Sep 2005 12:57:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJvFNX062892 for ; Thu, 22 Sep 2005 12:57:16 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 6D9752B47F0; Thu, 22 Sep 2005 21:57:13 +0200 (CEST) Date: Thu, 22 Sep 2005 21:57:13 +0200 To: David Shaw , ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050922195710.GA24782@epointsystem.org> References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> <200509222100.01040@zaphod.konrad.silmor.de> <20050922191832.GB2481@epointsystem.org> <20050922193636.GE32759@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922193636.GE32759@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 03:36:36PM -0400, David Shaw wrote: > Well yes, but someone can generate a key with an arbitrary ID today. > Even forgetting the DEADBEEF games that are possible with v3 RSA keys, > there is a program out there that generates v4 DSA keys over and over > until the requested (short) key ID comes up. As I understand, that's precisely thre reason why long IDs are used as key pointers. It would take 4 million times longer to generate one of those. Still possible for a determined, well-funded adversary, but expensive. In case of v3 keys, it was trivial. In case of the proposed hash function choice, it will be still expensive, but substantially cheaper (even if nothing is broken) than with current v4 keys, and in a "brittle" way: a breaktrough in one case breaks the whole thing. I think that SHA1 for key identification and fingerprinting is still a comfortable overkill. -- Daniel From owner-ietf-openpgp@mail.imc.org Fri Sep 23 07:11:31 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlSk-0004QM-Lf for openpgp-archive@megatron.ietf.org; Fri, 23 Sep 2005 07:11:31 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07987 for ; Fri, 23 Sep 2005 07:11:27 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NAZfWK040042; Fri, 23 Sep 2005 03:35:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NAZf7K040041; Fri, 23 Sep 2005 03:35:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NAZen9040032 for ; Fri, 23 Sep 2005 03:35:41 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id BB69333C1D; Fri, 23 Sep 2005 11:35:39 +0100 (BST) Message-ID: <4333DA7E.1000301@algroup.co.uk> Date: Fri, 23 Sep 2005 11:35:42 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Shaw CC: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format References: <20050921212613.09EAF57EF5@finney.org> <20050921215503.GA18343@jabberwocky.com> In-Reply-To: <20050921215503.GA18343@jabberwocky.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit David Shaw wrote: > On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote: > > >>>If you're importing a foreign key or generating one on the fly, you don't >>>put subpackets into the key that cannot be determined next time you use the >>>same source to get the key. A flag in a subpacket indicating where the key >>>comes from might be useful, though. >> >>This is a good point, I'll have to think about it. I'm still not >>sure that covering this material with key fingerprints and keyids is >>the right thing to do. What would the security threats be from being >>able to bring a key back to life with the same fingerprint and keyid, >>but without any signatures on it being valid? > > > My original idea with subpackets was that they would be part of the > fingerprint, and changing a subpacket was akin to making a whole new > key as the fingerprint and key ID (though not the key material) would > change. I see some advantages of what you are discussing. It would > (somewhat) allow someone to violate a hard expiration date on their > key: make the key, get signatures, and then when the key expires, just > remake the key. Essentially you can buy an extension on your "hard" > expiration time at the cost of losing all of your signatures. > > The thing is, I can't really decide if that is a threat or a > feature... You can already do this by signing the new version of the key with the old version of the key - same keypair, so messages to either will work, and signatures made by either key will still check - but different IDs and signatures on the keys. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff From owner-ietf-openpgp@mail.imc.org Fri Sep 23 07:52:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIm6i-0005Zj-80 for openpgp-archive@megatron.ietf.org; Fri, 23 Sep 2005 07:52:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09506 for ; Fri, 23 Sep 2005 07:52:46 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBG2PX043806; Fri, 23 Sep 2005 04:16:02 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NBG25f043805; Fri, 23 Sep 2005 04:16:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBG1hF043793 for ; Fri, 23 Sep 2005 04:16:01 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 0BF8E5ADC4; Fri, 23 Sep 2005 12:15:59 +0100 (BST) Message-ID: <4333E413.4000308@systemics.com> Date: Fri, 23 Sep 2005 12:16:35 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> <200509222100.01040@zaphod.konrad.silmor.de> <20050922191832.GB2481@epointsystem.org> <20050922193636.GE32759@jabberwocky.com> <20050922195710.GA24782@epointsystem.org> In-Reply-To: <20050922195710.GA24782@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Daniel A. Nagy wrote: > I think that SHA1 for key identification and fingerprinting is still a > comfortable overkill. It would seem that most efforts in this direction are divisible into two classes - those with human interaction and those without. For the latter, it would seem reasonable to always use full strength - the full bits available for all computations. Overkill is not a problem for computers. For human interaction issues, it is clearly tricky in some cases that are hard to predict to use a full length identifier. So the notion could be that each usage of a hash presented to humans simply defines its own minimum portion of bits, but also can and will accept a longer or even full length hash without complaint. (In effect that is what is done but the minimums seem to be more hard coded and larger portions have no acceptibility.) From this pov, we should * use the best hash available (e.g. SHA512, excessively) * convert to the display form as late as possible in the code * make sure that the "short form" convention is understood by all inputs * and recognisable/parsable in its text form. (Something like a dotted notation: DEAD.BEEF would give us the 32 bits, DEAD.BEEF.C001.D00D would be 64 bits. These are relatively easy to parse, easier than the whitespace separated form.) iang PS: I'm not recommending SHA512 here, just conceptualising the software engineering principles involved. From owner-ietf-openpgp@mail.imc.org Fri Sep 23 08:22:51 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImZn-0004M6-4E for openpgp-archive@megatron.ietf.org; Fri, 23 Sep 2005 08:22:51 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11245 for ; Fri, 23 Sep 2005 08:22:49 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBkuxQ047188; Fri, 23 Sep 2005 04:46:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NBkuLM047187; Fri, 23 Sep 2005 04:46:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.76.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBktMJ047168 for ; Fri, 23 Sep 2005 04:46:55 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <2005092311464901300a7f0be>; Fri, 23 Sep 2005 11:46:50 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8NBkn0m029565; Fri, 23 Sep 2005 07:46:49 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8NBknFG003008; Fri, 23 Sep 2005 07:46:49 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8NBkhNp003007; Fri, 23 Sep 2005 07:46:43 -0400 Date: Fri, 23 Sep 2005 07:46:43 -0400 From: David Shaw To: Ben Laurie Cc: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050923114643.GA861@jabberwocky.com> Mail-Followup-To: Ben Laurie , ietf-openpgp@imc.org References: <20050921212613.09EAF57EF5@finney.org> <20050921215503.GA18343@jabberwocky.com> <4333DA7E.1000301@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4333DA7E.1000301@algroup.co.uk> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 23, 2005 at 11:35:42AM +0100, Ben Laurie wrote: > > David Shaw wrote: > >On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote: > > > > > >>>If you're importing a foreign key or generating one on the fly, you don't > >>>put subpackets into the key that cannot be determined next time you use > >>>the > >>>same source to get the key. A flag in a subpacket indicating where the > >>>key > >>>comes from might be useful, though. > >> > >>This is a good point, I'll have to think about it. I'm still not > >>sure that covering this material with key fingerprints and keyids is > >>the right thing to do. What would the security threats be from being > >>able to bring a key back to life with the same fingerprint and keyid, > >>but without any signatures on it being valid? > > > > > >My original idea with subpackets was that they would be part of the > >fingerprint, and changing a subpacket was akin to making a whole new > >key as the fingerprint and key ID (though not the key material) would > >change. I see some advantages of what you are discussing. It would > >(somewhat) allow someone to violate a hard expiration date on their > >key: make the key, get signatures, and then when the key expires, just > >remake the key. Essentially you can buy an extension on your "hard" > >expiration time at the cost of losing all of your signatures. > > > >The thing is, I can't really decide if that is a threat or a > >feature... > > You can already do this by signing the new version of the key with the > old version of the key - same keypair, so messages to either will work, > and signatures made by either key will still check - but different IDs > and signatures on the keys. Absolutely, but from the trust perspective (at least using the web of trust), this second key is one further "hop" away from the one that was signed. It becomes the same situation as if someone generated a brand new key without doing any trickery by keeping the same key material and just signed it with the old one; the fact that the key material is the same is interesting, but not really useful in practice since the (changed) key ID is used to locate it in a keyring when verifying a signature or handling a PKESK. David From owner-ietf-openpgp@mail.imc.org Sat Sep 24 04:07:43 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJ54Q-000559-LO for openpgp-archive@megatron.ietf.org; Sat, 24 Sep 2005 04:07:43 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23822 for ; Sat, 24 Sep 2005 04:07:39 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8O7VWpH050071; Sat, 24 Sep 2005 00:31:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8O7VWW8050070; Sat, 24 Sep 2005 00:31:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8O7VUA7050061 for ; Sat, 24 Sep 2005 00:31:31 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 404C13439D; Sat, 24 Sep 2005 19:31:25 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23538-22; Sat, 24 Sep 2005 19:31:25 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 05AE633F45; Sat, 24 Sep 2005 19:31:24 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 473D23775D; Sat, 24 Sep 2005 19:31:24 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EJ4VO-0002AP-00; Sat, 24 Sep 2005 19:31:30 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: Plausible deniability (a feature to think about) In-Reply-To: <20050922135632.GA1725@epointsystem.org> Message-Id: Date: Sat, 24 Sep 2005 19:31:30 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: nagydani@epointsystem.org (Daniel A. Nagy) writes: >On Thu, Sep 22, 2005 at 05:43:57PM +1200, Peter Gutmann wrote: >> X9.42 was only added to S/MIME for political reasons. AFAIK only one >> implementation ever supported it, and that was the USG-funded reference >> implementation that was required to support it. In addition, MS supported a >> read-only implementation just so they couldn't be accused of not supporting >> it. > >>What political reasons? For a brief period during the S/MIME development, RSA was still owned by RSADSI while DH wasn't. From "The Crypto Gardening Guide and Planting Tips", http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt: An Internet standard RFC required that implementors support X9.42 DH key agreement, and provided RSA as an option (in IETF terms, "MUST X9.42, MAY RSA"). However, no existing software supported X9.42, no CAs would issue certificates for it, even if they did no-one wanted to renew all of their certificates ($$$) for an algorithm that provided no advantages over RSA, and no hardware (either crypto accelerators or smart cards) supported it (there was some token support after a few years, although even now there are problems being found with the X9.42 test vectors which indicate that no-one has really looked at them). As a result, even though the standard mandated use of X9.42, everyone treated it as if it said "MUST RSA, SHOULD NOT X9.42", pretending to do X9.42 while running business as usual with RSA. >And why is there a reserved ID in OpenPGP? OpenPGP has reserved IDs for all sorts of weird and wonderful stuff. I guess X9.42 is no exception. Peter. From SallyRowell@rattlebones.net Mon Sep 26 21:41:11 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK4T1-0000DF-3T; Mon, 26 Sep 2005 21:41:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24051; Mon, 26 Sep 2005 21:41:09 -0400 (EDT) Received: from 20-129.207-68.elmore.res.rr.com ([68.207.129.20]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EK4a7-0005P1-Ka; Mon, 26 Sep 2005 21:48:35 -0400 Received: from 9QOe@localhost by axFJ.int (8.11.6/8.11.6); Tue, 27 Sep 2005 00:07:52 -0300 Message-ID: <8SxcS3IAhReEsmRcbNrjc@springtides.net> From: "Debbie Thorpe" Reply-To: "Debbie Thorpe" To: openpgp-archive@ietf.org Cc: i-d-announce-bounces@ietf.org Subject: MS Office XP Pro $49.95 Adobe, Windows Date: Tue, 27 Sep 2005 06:10:52 +0300 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: SallyRowell@rattlebones.net Content-Type: multipart/mixed; boundary="--yslgJRteTz8onlys" X-Spam-Score: 2.7 (++) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 VVog ----yslgJRteTz8onlys Content-Type: text/html; Content-Transfer-Encoding: quoted-printable R
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

TOP 10 NEW TITLES

  

 = ON SALE NOW!

 1 = Office Pro 2003
 2 Ad= obe Photoshop 9.0
 3 Wi= ndows XP Pro
 4 Adobe= Acrobat 7 Pro
 5 Flash= MX 2004
 6 Corel Dr= aw 12
 7 Norton Antiv= irus 2005
 <= font face=3DVerdana size=3D1>8 Windows= 2003 Server
 9 Alias= Maya 6 Wavefrt
 10 = Adobe Illustrator 11
  See more by this manufacturer
   Microsoft
  = Symantec
   Adobe
  Custom= ers also bought
  these other items...

Micro= soft Office Professional Edition *2003*
Microsoft

Choose:
 

You Save:



Availability: Available for INSTANT down= load!
Coupon Code: G8S8pr
 

Sales Rank: #1
System requirements  |  Other Versions
Date= Coupon Expires: August 31st, 2005
Av= erage Customer Review:3D"5 Based on 139255 reviews. Write a review.

<= table border=3D0 cellpadding=3D0 cellspacing=3D0 style=3D"border-collapse:= collapse" bordercolor=3D#111111 width=3D100% id=3DAutoNumber1 height=3D55= >
List Price:$499.00
Price:$69.99
$429.01 (86%)

Adobe Photoshop CS2 V= 9.0
Adobe<= /a>

Choose:=
 

=
List Price:$599.00
Price:= $69.99
You Save:$529.01 (90%)



Av= ailability: Available for INSTANT download!
Coupon Code: 60= InAqRdx
 

Sales Rank: #2 System re= quirements  |  Other Vers= ions
Date Coupon Expires: August = 31st, 2005
Average Customer Review: Based on 126348 reviews. Write a= review.

Microsoft Windows XP Professional = or Longhorn Edition
Microsoft

<= table cellSpacing=3D0 cellPadding=3D0 border=3D0 height=3D21 width=3D189><= tr>
Choose:
 
List Price:$279.00
Price:$49.99
You = Save:$229.01 (85%)

<= a href=3Dhttp://soft4cheap.net/?l>

Availability: Available for INSTANT download!=
Coupon Code: hR7IWO2
 

Sales Rank: #3
System requirements  |  Other Versions
Date Co= upon Expires: August 31st, 2005
Avera= ge Customer Review:3D"5 Based on 1139 reviews. Write a review.

Adobe Acrob= at Professional V 7.0
Adobe

Choose:
=  
=

=
List Pr= ice:$499.00
Pric= e:$69.99
You Save:$429.01 (85%)

<= br>
Availability: Available for INSTANT download!
Coupon= Code: rHsnr27KF
 

Sales R= ank: #4<= br> System requirements  |  Other Versions
Date Coupon Expires= : August 31st, 2005
Average Customer = Review:3D"5 Based on 182886 reviews. Write a review.

<= /td>
----yslgJRteTz8onlys-- From MichelleStout@gis-ltd.co.uk Fri Sep 30 06:50:36 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELITL-00047z-VU; Fri, 30 Sep 2005 06:50:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04370; Fri, 30 Sep 2005 06:50:33 -0400 (EDT) Received: from host-538eab8d.elsat.net.pl ([83.142.171.141]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ELIak-00026O-WF; Fri, 30 Sep 2005 06:58:42 -0400 Received: from UZy@localhost by MfIc.int (8.11.6/8.11.6); Fri, 30 Sep 2005 10:39:39 -0100 Message-ID: From: "Blanca Metz" Reply-To: "Blanca Metz" To: openpgp-archive@ietf.org, i-d-announce-bounces@ietf.org Subject: 100's of titles by AutoCAD Photoshop & XP Pro starting @ 9.99 Date: Fri, 30 Sep 2005 16:42:39 +0500 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.71.2730.2 X-Sender: MichelleStout@gis-ltd.co.uk Content-Type: multipart/mixed; boundary="--OWEbvhdZowNRWKu" X-Spam-Score: 0.2 (/) X-Scan-Signature: 8cb9b411340046bf4080a729180a0672 j3N ----OWEbvhdZowNRWKu Content-Type: text/html; Content-Transfer-Encoding: quoted-printable g
Opt-in Email Special Offer   = ;  unsubscribe me
=
SEARCH

<= tr vAlign=3Dtop bgColor=3D#333399>

TOP 10 NEW TITLES

<= /td>
<= tr>

 = ON SALE NOW!

 1 O= ffice Pro 2003
 2 Adobe = Photoshop 9.0
 3 Window= s XP Pro
 4 Adobe Acro= bat 7 Pro
 <= font face=3DVerdana size=3D1>5 Flash MX= 2004
 6 Corel Draw 1= 2
 7 Norton Antivirus = 2005
 8 Windows 2003 = Server
 9 Alias Maya = 6 Wavefrt
 <= font face=3DVerdana size=3D1>10 Adobe <= /a> Illustrator 11
&nb= sp; See more by this manufacturer
   Microsoft
   Symantec
   Adobe<= /a>
  Customers also bo= ught
   these other items...

Microsoft Office = Professional Edition *2003*
Microsoft

<= /table>

Choose= :
 
Lis= t Price:$499.00
Pr= ice:$69.99
You Save:= $429.01 (86%)

=

Availability: Available for INSTANT download!
Coupo= n Code: X58HFhs9x
 

Sales = Rank: #1
System requirements  |  Other Versions
Date Coupon Expires:= August 31st, 2005
Average Customer R= eview:3D"5 Based on 14828 reviews. Write a review.

Adobe Photoshop CS2 V 9.0
Adobe

Choose:
 <= /td>

<= img height=3D150 src=3Dhttp://images.amazon.com/images/P/B00081I6JI.01._PE= 7_SCMZZZZZZZ_.jpg width=3D144 align=3Dleft border=3D0 name=3Dprod_image>

List Price:$599.00
Price:$69.99<= /b>
You Save:$529.01 (90= %)



Availability: A= vailable for INSTANT download!
Coupon Code: 85moHXOW
 =

Sales Rank: #2
System requirements = ; |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 13591= reviews. Write a review.

=
Microsoft Windows XP Professional or Longhorn Edition=
Microsoft

Choose:
 

=
List Price:$279.00
Price:= $49.99
You Save:$229.01 (85%)



Ava= ilability: Available for INSTANT download!
Coupon Code: k2r= ZgFyYr
 

Sales Rank: #3
System requ= irements  |  Other Version= s
Date Coupon Expires: August 31s= t, 2005
Average Customer Review:3D"5 Based on 14245 reviews. Write a revie= w.

Adobe Acrobat Professional V 7.0
= Adobe

Choose:
&nbs= p;

List Price:$499.00
Price:$69.99<= /b>
You Save:$429.01 (85= %)



Availability: A= vailable for INSTANT download!
Coupon Code: GiznwP1X
 =

Sales Rank: #4
System requirements = |  Other Versions
Date Coupon Expires: August 31st, 2005
Average Customer Review:3D= Based on 18262= 6 reviews. Write a review.

= ----OWEbvhdZowNRWKu-- From owner-ietf-openpgp@mail.imc.org Fri Sep 30 21:26:09 2005 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELW8f-00084t-D2 for openpgp-archive@megatron.ietf.org; Fri, 30 Sep 2005 21:26:09 -0400 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA02652 for ; Fri, 30 Sep 2005 21:26:07 -0400 (EDT) Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j910n9WV029477; Fri, 30 Sep 2005 17:49:09 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j910n9SG029476; Fri, 30 Sep 2005 17:49:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j910n9l3029469 for ; Fri, 30 Sep 2005 17:49:09 -0700 (PDT) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Fri, 30 Sep 2005 17:49:07 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 30 Sep 2005 17:49:07 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 30 Sep 2005 17:49:07 -0700 In-Reply-To: <20050920173939.33F0957EF5@finney.org> References: <20050920173939.33F0957EF5@finney.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83B08249-1403-49A2-8218-2B860243982C@callas.org> Cc: ietf-openpgp@imc.org Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Line spacing in normative references Date: Fri, 30 Sep 2005 17:49:06 -0700 To: Hal Finney X-Mailer: Apple Mail (2.734) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 20 Sep 2005, at 10:39 AM, Hal Finney wrote: > > A minor point, I notice that the spacing is inconsistent in the > normative > references. Some are separated by blank lines and some are not. It > would > look nicer to be consistent here. I don't know if some macro is > misfiring > or if we could clean it up and make it look better. Cleaned up. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j910n9WV029477; Fri, 30 Sep 2005 17:49:09 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j910n9SG029476; Fri, 30 Sep 2005 17:49:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j910n9l3029469 for ; Fri, 30 Sep 2005 17:49:09 -0700 (PDT) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Fri, 30 Sep 2005 17:49:07 -0700 Received: from [63.251.255.205] ([63.251.255.205]) by keys.merrymeet.com (PGP Universal service); Fri, 30 Sep 2005 17:49:07 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Fri, 30 Sep 2005 17:49:07 -0700 In-Reply-To: <20050920173939.33F0957EF5@finney.org> References: <20050920173939.33F0957EF5@finney.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <83B08249-1403-49A2-8218-2B860243982C@callas.org> Cc: ietf-openpgp@imc.org Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Line spacing in normative references Date: Fri, 30 Sep 2005 17:49:06 -0700 To: Hal Finney X-Mailer: Apple Mail (2.734) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 20 Sep 2005, at 10:39 AM, Hal Finney wrote: > > A minor point, I notice that the spacing is inconsistent in the > normative > references. Some are separated by blank lines and some are not. It > would > look nicer to be consistent here. I don't know if some macro is > misfiring > or if we could clean it up and make it look better. Cleaned up. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8O7VWpH050071; Sat, 24 Sep 2005 00:31:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8O7VWW8050070; Sat, 24 Sep 2005 00:31:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtpb.itss.auckland.ac.nz (chico.itss.auckland.ac.nz [130.216.190.12]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8O7VUA7050061 for ; Sat, 24 Sep 2005 00:31:31 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 404C13439D; Sat, 24 Sep 2005 19:31:25 +1200 (NZST) Received: from smtpb.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23538-22; Sat, 24 Sep 2005 19:31:25 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpb.itss.auckland.ac.nz (Postfix) with ESMTP id 05AE633F45; Sat, 24 Sep 2005 19:31:24 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 473D23775D; Sat, 24 Sep 2005 19:31:24 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EJ4VO-0002AP-00; Sat, 24 Sep 2005 19:31:30 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: Plausible deniability (a feature to think about) In-Reply-To: <20050922135632.GA1725@epointsystem.org> Message-Id: Date: Sat, 24 Sep 2005 19:31:30 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: nagydani@epointsystem.org (Daniel A. Nagy) writes: >On Thu, Sep 22, 2005 at 05:43:57PM +1200, Peter Gutmann wrote: >> X9.42 was only added to S/MIME for political reasons. AFAIK only one >> implementation ever supported it, and that was the USG-funded reference >> implementation that was required to support it. In addition, MS supported a >> read-only implementation just so they couldn't be accused of not supporting >> it. > >>What political reasons? For a brief period during the S/MIME development, RSA was still owned by RSADSI while DH wasn't. From "The Crypto Gardening Guide and Planting Tips", http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_guide.txt: An Internet standard RFC required that implementors support X9.42 DH key agreement, and provided RSA as an option (in IETF terms, "MUST X9.42, MAY RSA"). However, no existing software supported X9.42, no CAs would issue certificates for it, even if they did no-one wanted to renew all of their certificates ($$$) for an algorithm that provided no advantages over RSA, and no hardware (either crypto accelerators or smart cards) supported it (there was some token support after a few years, although even now there are problems being found with the X9.42 test vectors which indicate that no-one has really looked at them). As a result, even though the standard mandated use of X9.42, everyone treated it as if it said "MUST RSA, SHOULD NOT X9.42", pretending to do X9.42 while running business as usual with RSA. >And why is there a reserved ID in OpenPGP? OpenPGP has reserved IDs for all sorts of weird and wonderful stuff. I guess X9.42 is no exception. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBkuxQ047188; Fri, 23 Sep 2005 04:46:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NBkuLM047187; Fri, 23 Sep 2005 04:46:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.76.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBktMJ047168 for ; Fri, 23 Sep 2005 04:46:55 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <2005092311464901300a7f0be>; Fri, 23 Sep 2005 11:46:50 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8NBkn0m029565; Fri, 23 Sep 2005 07:46:49 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8NBknFG003008; Fri, 23 Sep 2005 07:46:49 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8NBkhNp003007; Fri, 23 Sep 2005 07:46:43 -0400 Date: Fri, 23 Sep 2005 07:46:43 -0400 From: David Shaw To: Ben Laurie Cc: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050923114643.GA861@jabberwocky.com> Mail-Followup-To: Ben Laurie , ietf-openpgp@imc.org References: <20050921212613.09EAF57EF5@finney.org> <20050921215503.GA18343@jabberwocky.com> <4333DA7E.1000301@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4333DA7E.1000301@algroup.co.uk> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 23, 2005 at 11:35:42AM +0100, Ben Laurie wrote: > > David Shaw wrote: > >On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote: > > > > > >>>If you're importing a foreign key or generating one on the fly, you don't > >>>put subpackets into the key that cannot be determined next time you use > >>>the > >>>same source to get the key. A flag in a subpacket indicating where the > >>>key > >>>comes from might be useful, though. > >> > >>This is a good point, I'll have to think about it. I'm still not > >>sure that covering this material with key fingerprints and keyids is > >>the right thing to do. What would the security threats be from being > >>able to bring a key back to life with the same fingerprint and keyid, > >>but without any signatures on it being valid? > > > > > >My original idea with subpackets was that they would be part of the > >fingerprint, and changing a subpacket was akin to making a whole new > >key as the fingerprint and key ID (though not the key material) would > >change. I see some advantages of what you are discussing. It would > >(somewhat) allow someone to violate a hard expiration date on their > >key: make the key, get signatures, and then when the key expires, just > >remake the key. Essentially you can buy an extension on your "hard" > >expiration time at the cost of losing all of your signatures. > > > >The thing is, I can't really decide if that is a threat or a > >feature... > > You can already do this by signing the new version of the key with the > old version of the key - same keypair, so messages to either will work, > and signatures made by either key will still check - but different IDs > and signatures on the keys. Absolutely, but from the trust perspective (at least using the web of trust), this second key is one further "hop" away from the one that was signed. It becomes the same situation as if someone generated a brand new key without doing any trickery by keeping the same key material and just signed it with the old one; the fact that the key material is the same is interesting, but not really useful in practice since the (changed) key ID is used to locate it in a keyring when verifying a signature or handling a PKESK. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBG2PX043806; Fri, 23 Sep 2005 04:16:02 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NBG25f043805; Fri, 23 Sep 2005 04:16:02 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NBG1hF043793 for ; Fri, 23 Sep 2005 04:16:01 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 0BF8E5ADC4; Fri, 23 Sep 2005 12:15:59 +0100 (BST) Message-ID: <4333E413.4000308@systemics.com> Date: Fri, 23 Sep 2005 12:16:35 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050921) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: David Shaw , ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> <200509222100.01040@zaphod.konrad.silmor.de> <20050922191832.GB2481@epointsystem.org> <20050922193636.GE32759@jabberwocky.com> <20050922195710.GA24782@epointsystem.org> In-Reply-To: <20050922195710.GA24782@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > I think that SHA1 for key identification and fingerprinting is still a > comfortable overkill. It would seem that most efforts in this direction are divisible into two classes - those with human interaction and those without. For the latter, it would seem reasonable to always use full strength - the full bits available for all computations. Overkill is not a problem for computers. For human interaction issues, it is clearly tricky in some cases that are hard to predict to use a full length identifier. So the notion could be that each usage of a hash presented to humans simply defines its own minimum portion of bits, but also can and will accept a longer or even full length hash without complaint. (In effect that is what is done but the minimums seem to be more hard coded and larger portions have no acceptibility.) From this pov, we should * use the best hash available (e.g. SHA512, excessively) * convert to the display form as late as possible in the code * make sure that the "short form" convention is understood by all inputs * and recognisable/parsable in its text form. (Something like a dotted notation: DEAD.BEEF would give us the 32 bits, DEAD.BEEF.C001.D00D would be 64 bits. These are relatively easy to parse, easier than the whitespace separated form.) iang PS: I'm not recommending SHA512 here, just conceptualising the software engineering principles involved. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NAZfWK040042; Fri, 23 Sep 2005 03:35:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8NAZf7K040041; Fri, 23 Sep 2005 03:35:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8NAZen9040032 for ; Fri, 23 Sep 2005 03:35:41 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id BB69333C1D; Fri, 23 Sep 2005 11:35:39 +0100 (BST) Message-ID: <4333DA7E.1000301@algroup.co.uk> Date: Fri, 23 Sep 2005 11:35:42 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Shaw CC: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format References: <20050921212613.09EAF57EF5@finney.org> <20050921215503.GA18343@jabberwocky.com> In-Reply-To: <20050921215503.GA18343@jabberwocky.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw wrote: > On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote: > > >>>If you're importing a foreign key or generating one on the fly, you don't >>>put subpackets into the key that cannot be determined next time you use the >>>same source to get the key. A flag in a subpacket indicating where the key >>>comes from might be useful, though. >> >>This is a good point, I'll have to think about it. I'm still not >>sure that covering this material with key fingerprints and keyids is >>the right thing to do. What would the security threats be from being >>able to bring a key back to life with the same fingerprint and keyid, >>but without any signatures on it being valid? > > > My original idea with subpackets was that they would be part of the > fingerprint, and changing a subpacket was akin to making a whole new > key as the fingerprint and key ID (though not the key material) would > change. I see some advantages of what you are discussing. It would > (somewhat) allow someone to violate a hard expiration date on their > key: make the key, get signatures, and then when the key expires, just > remake the key. Essentially you can buy an extension on your "hard" > expiration time at the cost of losing all of your signatures. > > The thing is, I can't really decide if that is a threat or a > feature... You can already do this by signing the new version of the key with the old version of the key - same keypair, so messages to either will work, and signatures made by either key will still check - but different IDs and signatures on the keys. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJvHUl062903; Thu, 22 Sep 2005 12:57:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJvH5U062902; Thu, 22 Sep 2005 12:57:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJvFNX062892 for ; Thu, 22 Sep 2005 12:57:16 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 6D9752B47F0; Thu, 22 Sep 2005 21:57:13 +0200 (CEST) Date: Thu, 22 Sep 2005 21:57:13 +0200 To: David Shaw , ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050922195710.GA24782@epointsystem.org> References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> <200509222100.01040@zaphod.konrad.silmor.de> <20050922191832.GB2481@epointsystem.org> <20050922193636.GE32759@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922193636.GE32759@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 03:36:36PM -0400, David Shaw wrote: > Well yes, but someone can generate a key with an arbitrary ID today. > Even forgetting the DEADBEEF games that are possible with v3 RSA keys, > there is a program out there that generates v4 DSA keys over and over > until the requested (short) key ID comes up. As I understand, that's precisely thre reason why long IDs are used as key pointers. It would take 4 million times longer to generate one of those. Still possible for a determined, well-funded adversary, but expensive. In case of v3 keys, it was trivial. In case of the proposed hash function choice, it will be still expensive, but substantially cheaper (even if nothing is broken) than with current v4 keys, and in a "brittle" way: a breaktrough in one case breaks the whole thing. I think that SHA1 for key identification and fingerprinting is still a comfortable overkill. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJaiba060894; Thu, 22 Sep 2005 12:36:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJaii4060893; Thu, 22 Sep 2005 12:36:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [63.240.76.21]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJah6D060884 for ; Thu, 22 Sep 2005 12:36:43 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc11) with ESMTP id <2005092219363801100pd5gre>; Thu, 22 Sep 2005 19:36:38 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8MJac0m026622 for ; Thu, 22 Sep 2005 15:36:38 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8MJaapt000457 for ; Thu, 22 Sep 2005 15:36:36 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8MJaate000456 for ietf-openpgp@imc.org; Thu, 22 Sep 2005 15:36:36 -0400 Date: Thu, 22 Sep 2005 15:36:36 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050922193636.GE32759@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> <200509222100.01040@zaphod.konrad.silmor.de> <20050922191832.GB2481@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922191832.GB2481@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 09:18:36PM +0200, Daniel A. Nagy wrote: > > On Thu, Sep 22, 2005 at 09:00:00PM +0200, Konrad Rosenbaum wrote: > > > Let's say MDX is broken by some genius. > > Remember, that the key ID is the last 8 (or four) byes of the fingerprint. > If MDX is broken, one can generatet a key with an arbitrary ID. Well yes, but someone can generate a key with an arbitrary ID today. Even forgetting the DEADBEEF games that are possible with v3 RSA keys, there is a program out there that generates v4 DSA keys over and over until the requested (short) key ID comes up. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJIeao059223; Thu, 22 Sep 2005 12:18:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJIeLY059222; Thu, 22 Sep 2005 12:18:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJIdJk059216 for ; Thu, 22 Sep 2005 12:18:39 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 0B8988002; Thu, 22 Sep 2005 21:18:37 +0200 (CEST) Date: Thu, 22 Sep 2005 21:18:36 +0200 To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050922191832.GB2481@epointsystem.org> References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> <200509222100.01040@zaphod.konrad.silmor.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509222100.01040@zaphod.konrad.silmor.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 09:00:00PM +0200, Konrad Rosenbaum wrote: > Let's say MDX is broken by some genius. Remember, that the key ID is the last 8 (or four) byes of the fingerprint. If MDX is broken, one can generatet a key with an arbitrary ID. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJ6xbf058370; Thu, 22 Sep 2005 12:06:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJ6xHL058369; Thu, 22 Sep 2005 12:06:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [204.127.198.54]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJ6wY9058354 for ; Thu, 22 Sep 2005 12:06:59 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005092219065001400oma58e>; Thu, 22 Sep 2005 19:06:50 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8MJ6o0m026505 for ; Thu, 22 Sep 2005 15:06:50 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8MJ6mOG000415 for ; Thu, 22 Sep 2005 15:06:48 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8MJ6mbH000414 for ietf-openpgp@imc.org; Thu, 22 Sep 2005 15:06:48 -0400 Date: Thu, 22 Sep 2005 15:06:48 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050922190648.GD32759@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921212613.09EAF57EF5@finney.org> <200509222047.06402@zaphod.konrad.silmor.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509222047.06402@zaphod.konrad.silmor.de> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 08:47:05PM +0200, Konrad Rosenbaum wrote: > On Wednesday 21 September 2005 23:26, Hal Finney wrote: > > This is a good point, I'll have to think about it. I'm still not > > sure that covering this material with key fingerprints and keyids is > > the right thing to do. What would the security threats be from being > > able to bring a key back to life with the same fingerprint and keyid, > > but without any signatures on it being valid? > > It becomes a threat once you get hold of the private key (through some > accident, a data leak, whatever) because then you can also issue new > self-signatures. > > I see two possibilities to limit the damage: > > a) changing the expiration also changes the fingerprint, so the key does no > longer match whatever users have in their keyring and would basically be a > new key. > > b) changing the expiration breaks ALL signatures (not only self-sig) on the > key. (Actually b must be implemented as well, when a is implemented.) If I understand what Hal was proposing, then b is already true. Self-sigs aren't treated any differently than any other certification signature. > On the other hand: expiration dates are a very weak measure against key > abuse (they only limit the damage), un-revocable revocation sigs seem much > more effective to me. True, but an unrevocable revocation signature can be stripped off the key, so it becomes a key distribution problem. Expiration dates are naturally carried along with the key. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJ0Z2e057707; Thu, 22 Sep 2005 12:00:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MJ0Zot057706; Thu, 22 Sep 2005 12:00:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MJ0Y0o057696 for ; Thu, 22 Sep 2005 12:00:34 -0700 (PDT) (envelope-from konrad@silmor.de) Received: from p54b3db8c.dip.t-dialin.net ([84.179.219.140] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1EIWJ1-00074L-00 for ; Thu, 22 Sep 2005 21:00:28 +0200 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Date: Thu, 22 Sep 2005 21:00:00 +0200 User-Agent: KMail/1.8 References: <20050921202208.GB18050@jabberwocky.com> <20050921210015.GA2316@epointsystem.org> In-Reply-To: <20050921210015.GA2316@epointsystem.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1493410.qBePzIRu3u"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509222100.01040@zaphod.konrad.silmor.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1493410.qBePzIRu3u Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 September 2005 23:00, Daniel A. Nagy wrote: > As before, I would like to express my concerns about allowing a choice of > hash algorithms. Here's some detail: > > A complete break (feasible reversal) of ANY ONE of the supported hash > algorithms would allow generating keys with arbitrary long key IDs, > possibly colliding with an attacked key. This was a major problem with v3 > and v4 was a giant step in the right direction. This would be a small > step backwards. I don't see how this attack would work. Let's say MDX is broken by some genius. =46irst the trivial case:=20 Alices Key A uses MDX as its fingerprint algorithm. The fingerprint looks=20 like: 99:AB 12 34 56 78 90 CD EF... Mallory can now generate an arbitrary key M, that has the same algorithm an= d=20 fingerprint. Now the less trivial: Bobs key B uses MDY (which was not broken). Fingerprint: A0:12 34 56 78... Mallory could attempt to create a key M2 which has the same hash value usin= g=20 MDY as Bobs key using MDX, but the fingerprint would still be different:=20 99:12 34 56 78... I don't see any way for Mallory to compromise Bobs key without changing the= =20 first byte of the fingerprint. So allowing different algorithms AND=20 including their ID in the fingerprint would in my opinion be a good measure= =20 to limit the damage (only Alices key becomes ambiguous, not Bobs) in case=20 of a broken algorithm. Konrad --nextPart1493410.qBePzIRu3u Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDMv8xClt766LaIH0RAtNrAJ9DelOcMBWZ87cEhujc9XaCRHvvBgCeMjzN KN5LMmvOmftInwgjeYdvX1w= =GOMT -----END PGP SIGNATURE----- --nextPart1493410.qBePzIRu3u-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIleVS056698; Thu, 22 Sep 2005 11:47:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MIlewf056697; Thu, 22 Sep 2005 11:47:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from p15139323.pureserver.info (silmor.de [217.160.219.75]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIldUr056686 for ; Thu, 22 Sep 2005 11:47:39 -0700 (PDT) (envelope-from konrad@silmor.de) Received: from p54b3db8c.dip.t-dialin.net ([84.179.219.140] helo=zaphod.local) by p15139323.pureserver.info with asmtp (Exim 3.35 #1 (Debian)) id 1EIW6X-00071y-00 for ; Thu, 22 Sep 2005 20:47:33 +0200 From: Konrad Rosenbaum To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Date: Thu, 22 Sep 2005 20:47:05 +0200 User-Agent: KMail/1.8 References: <20050921212613.09EAF57EF5@finney.org> In-Reply-To: <20050921212613.09EAF57EF5@finney.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1822501.mXWWIfq2zu"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200509222047.06402@zaphod.konrad.silmor.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --nextPart1822501.mXWWIfq2zu Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 September 2005 23:26, Hal Finney wrote: > This is a good point, I'll have to think about it. I'm still not > sure that covering this material with key fingerprints and keyids is > the right thing to do. What would the security threats be from being > able to bring a key back to life with the same fingerprint and keyid, > but without any signatures on it being valid? It becomes a threat once you get hold of the private key (through some=20 accident, a data leak, whatever) because then you can also issue new=20 self-signatures. I see two possibilities to limit the damage:=20 a) changing the expiration also changes the fingerprint, so the key does no= =20 longer match whatever users have in their keyring and would basically be a= =20 new key.=20 b) changing the expiration breaks ALL signatures (not only self-sig) on the= =20 key. (Actually b must be implemented as well, when a is implemented.) On the other hand: expiration dates are a very weak measure against key=20 abuse (they only limit the damage), un-revocable revocation sigs seem much= =20 more effective to me. Konrad --nextPart1822501.mXWWIfq2zu Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBDMvwqClt766LaIH0RAg81AJ9YD2xQyzzH7YrH/TXO2wXkT2YEpACdHB1l CDGgQtLGiD/7m2hOcJbLfsw= =gVOb -----END PGP SIGNATURE----- --nextPart1822501.mXWWIfq2zu-- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIKarM054593; Thu, 22 Sep 2005 11:20:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MIKa2o054592; Thu, 22 Sep 2005 11:20:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MIKZDP054582 for ; Thu, 22 Sep 2005 11:20:35 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 29BE92B47CD; Thu, 22 Sep 2005 20:20:31 +0200 (CEST) Date: Thu, 22 Sep 2005 20:20:29 +0200 To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-ID: <20050922182025.GA2481@epointsystem.org> References: <20050922165108.EABD057EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050922165108.EABD057EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 09:51:08AM -0700, "Hal Finney" wrote: > These kinds of stories are often used to motivate cryptographic > constructions, but the real world generally doesn't work that way. > An infiltrator does not need cryptographic proof of his information > about who is in the conspiracy! After all, he doesn't have any such > proof in the physical world, yet infiltrators, informants and spies have > long been used as valuable sources of information. I don't fully agree. Obviously, I wrote the story about the conspiracy and the infiltrator with tongue firmly embedded in cheek. That's a long-standing tradition in the crypto community and I certainly enjoy it. But nevertheless, in many cases the presented scenario is precisely what happens, just there's a lot less pathos surrounding it: The overwhelming majority of "goverment agents" "infiltrating" "conspiracies" are not politically motivated counter-intetlligence operations but tax audits. A tax auditor pretends to be a customer and buys someting. He sure as hell needs a rock-solid third-party proof to crack down on you if you fail to report that income. Now, what is taxed and what is not (by law!) depends on what is easy to tax and what is hard to tax. If something is easy to tax, laws are passed and it gets taxed. If something is hard to tax, if it's necessary for the functioning of the society, it is not taxed, if it's not necessary, then it's outlawed. Right now, e-commerce falls into the hard-to-tax-but-necessary category, but the arms race is on. I'd certainly like it to stay the way it is. While commerce is the single biggest user of crypto, there are other uses, which we cannot even imagine. I don't have any reason to doubt that the activist who wrote me about the missing feature in PGP could really use it. Since ePointSystem is first and foremost a financial cryptography consultancy, the first application on my mind was deniable invoicing. It's a fair choice: either you use undeniable invoices, pay your taxes and resolve your disputes in court relying on government enforcement, or you use deniable invoices, don't pay taxes, and rely solely on reputational self-regulation. I am pretty sure that most e-commerce will get taxed like everything else, as soon as governments sort out their jurisdictional problems. Having working deniable invoices would be a powerful argument in the ensuing debate over taxation policies. > I admit to a fondness for fancy crypto and it would be fun to see some > form of deniable authentication in OpenPGP, but realistically it is not > going to meet our customers' needs. How do you know? In my experience, predicting what people will use your product for is one of the most difficult tasks an engineer or a scientist faces. People are amazingly inventive. > If we do want to pursue it, there > are a number of technologies, like the DH shared keys you describe, > the signed ESK packets Vedaal mentioned, or ring signatures and other > variants of Chaum's designated-confirmer signatures. All of which have slightly different characteristics and are therefore optimal solutions for slightly different problems. In all cases, however, interoperability is a major boon, and thus it's ITEF's business to provide for it, isn't it? DH shared keys and signed ESK packets are both very easy to incorporate into the OpenPGP framework, and if we do it early on, we can hope that different implementations will interoperate right away. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MGpFq9042952; Thu, 22 Sep 2005 09:51:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MGpFgc042951; Thu, 22 Sep 2005 09:51:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MGpE7e042945 for ; Thu, 22 Sep 2005 09:51:14 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id EABD057EF5; Thu, 22 Sep 2005 09:51:08 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-Id: <20050922165108.EABD057EF5@finney.org> Date: Thu, 22 Sep 2005 09:51:08 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > Imagine, that a conspiracy expects to be infiltrated. They send encrypted > messages back and forth but they have a dilemma: to sign or not to sign? If > they do sign, the infiltrator will have damning evidence on his hands and > the bad guys will be able to crack down on the conspirators. If they don't > sign, the infiltrator will be able to forge messages and thus seriously > interfere with the activities of the group (e.g. call off action in the name > of the ringleader, etc.). These kinds of stories are often used to motivate cryptographic constructions, but the real world generally doesn't work that way. An infiltrator does not need cryptographic proof of his information about who is in the conspiracy! After all, he doesn't have any such proof in the physical world, yet infiltrators, informants and spies have long been used as valuable sources of information. I admit to a fondness for fancy crypto and it would be fun to see some form of deniable authentication in OpenPGP, but realistically it is not going to meet our customers' needs. If we do want to pursue it, there are a number of technologies, like the DH shared keys you describe, the signed ESK packets Vedaal mentioned, or ring signatures and other variants of Chaum's designated-confirmer signatures. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MFoeOM038030; Thu, 22 Sep 2005 08:50:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MFoerW038029; Thu, 22 Sep 2005 08:50:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MFod4m038017 for ; Thu, 22 Sep 2005 08:50:39 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id BFFDDA3549 for ; Thu, 22 Sep 2005 08:50:38 -0700 (PDT) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Thu, 22 Sep 2005 08:50:38 -0700 (PDT) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id j8MFocVe057963 for ; Thu, 22 Sep 2005 08:50:38 -0700 (PDT) (envelope-from vedaal@hush.com) Message-Id: <200509221550.j8MFocVe057963@mailserver3.hushmail.com> Date: Thu, 22 Sep 2005 08:50:34 -0700 To: Cc: Subject: Re: Plausible deniability (a feature to think about) From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 22 Sep 2005 07:52:08 -0700 "Daniel A. Nagy" wrote: >Simply? How exactly do you suggest to share a common key so that >the parties >can be reassured that it's their shared secret? >> many variations of this are possible; >> >> new signing subkeys, set to expire within hours of the message >> time, > >Again, how do you share them? the sender generates the new keypair, and sends it signed and encrypted, to the receiver it is neither more nor less trustworthy than the primary keys of the sender and receiver, which could also conceivably be given to other parties, >> split key systems with shares set to one, and split to only the >> receiver and sender keys, etc. > >I haven't seen split key implementations either in OpenPGP >compliant tools, >though I know they are mentioned in RFC2440. pgp has had them implemented since 6.x a new type of pgp signature to deal with this issue was proposed by Ian Brown and Adam Back, http://www.cs.ucl.ac.uk/staff/I.Brown/nts.htm where the session key is signed, not the plaintext (don't know if people want to explore this now, or wait until after the rfc 2440 is finalized, and save it for a further update, i would welcome this useful type of signature, as i imagine many users would ) vedaal >-- >Daniel Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEqA5n032587; Thu, 22 Sep 2005 07:52:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MEqAkh032586; Thu, 22 Sep 2005 07:52:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEq8pf032580 for ; Thu, 22 Sep 2005 07:52:09 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 4696C2B47DB; Thu, 22 Sep 2005 16:52:08 +0200 (CEST) Date: Thu, 22 Sep 2005 16:52:08 +0200 To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-ID: <20050922145208.GB20419@epointsystem.org> References: <200509221421.j8MELgMq047103@mailserver3.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509221421.j8MELgMq047103@mailserver3.hushmail.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 07:21:39AM -0700, vedaal@hush.com wrote: > this can easily be accomplished now, > within the existing standard, and existing implementations: > > any two correspondents, > can simply make a third keypair, with a third name, > and each have the public and private signing and encrypting keys, Simply? How exactly do you suggest to share a common key so that the parties can be reassured that it's their shared secret? > anything signed with the third key, authenticates only to the > correspondents > where the receiver knows that the sender signed it, > but cannot be proved to any third party, > other than the fact that any possessor of the signing key, signed > it. Actually, once you share some secret, you don't need to use asymmetric crypto anymore. A message with MDC encrypted with a shared symmetric key has all the necessary reassurances. Sharing the secret is the tricky part. > many variations of this are possible; > > new signing subkeys, set to expire within hours of the message > time, Again, how do you share them? > split key systems with shares set to one, and split to only the > receiver and sender keys, etc. I haven't seen split key implementations either in OpenPGP compliant tools, though I know they are mentioned in RFC2440. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEjLM1031758; Thu, 22 Sep 2005 07:45:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MEjLmh031757; Thu, 22 Sep 2005 07:45:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MEjJwB031726 for ; Thu, 22 Sep 2005 07:45:20 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 11E172B47DB; Thu, 22 Sep 2005 16:45:19 +0200 (CEST) Date: Thu, 22 Sep 2005 16:45:19 +0200 To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-ID: <20050922144518.GA20419@epointsystem.org> References: <20050922042955.GA30473@epointsystem.org> <200509220628.33636.brian@braverock.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200509220628.33636.brian@braverock.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 06:28:33AM -0500, Brian G. Peterson wrote: > We were most concerned with chain of evidence and verifiability, not plausible > deniability. Different people have different concerns, I suppose. > In the real world, most human rights organizations already have > extensive methods of verifying information that is provided to them, and > informers have elaborate methods of communicating that information, that only > rarely involves electronic communication, encrypted or otherwise, becasue of > the danger of interception. The "real world" keeps changing. If you can make something cheaper, more reliable, simpler, etc., why stop short of doing so? Also, I am not convinced that what you're stating is universally true. AFAIK, PGP has been quite popular with activists since its very first public releases. > In a country (like China) where much/most > private use of encryption is disallowed anyway, sending *any* encrypted > message is a risk that most human rights workers and informers will not take. The world is not black and white. "Countries like that" are not the only places where basic human rights are under assault, and not even necessarily by the government. There's a large number of considerably less-than-democratic governments that for one reason or another must maintain a democratic facade. And again, the government is not necessarily the threat you're caring about. > I don't think that OpenPGP needs a new shared-secret method of communication, > or that the spec needs another wrinkle for implementors to chew on. It would be obviously optional, and as outlined in the first email of the thread, not much of a trouble to design or implement. Bests, -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MELi6N029311; Thu, 22 Sep 2005 07:21:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MELia1029310; Thu, 22 Sep 2005 07:21:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MELhQg029304 for ; Thu, 22 Sep 2005 07:21:43 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 3E7F7A34DA for ; Thu, 22 Sep 2005 07:21:43 -0700 (PDT) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Thu, 22 Sep 2005 07:21:42 -0700 (PDT) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.11/8.12.9/Submit) id j8MELgMq047103 for ; Thu, 22 Sep 2005 07:21:42 -0700 (PDT) (envelope-from vedaal@hush.com) Message-Id: <200509221421.j8MELgMq047103@mailserver3.hushmail.com> Date: Thu, 22 Sep 2005 07:21:39 -0700 To: Cc: Subject: Re: Plausible deniability (a feature to think about) From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 21 Sep 2005 21:29:55 -0700 "Daniel A. Nagy" wrote: > Now, >the >receiving party can be sure that it was composed by the sender, >but has no >means of proving it to a third party. The sender can plausibly >deny >authorship, claiming that the receiver has forged it using his >private key >and the sender's public key. >Has anybody ever bothered implementing (or even designing an >implementation >of) this in an OpenPGP-friendly manner? this can easily be accomplished now, within the existing standard, and existing implementations: any two correspondents, can simply make a third keypair, with a third name, and each have the public and private signing and encrypting keys, anything signed with the third key, authenticates only to the correspondents where the receiver knows that the sender signed it, but cannot be proved to any third party, other than the fact that any possessor of the signing key, signed it. many variations of this are possible; new signing subkeys, set to expire within hours of the message time, split key systems with shares set to one, and split to only the receiver and sender keys, etc. vedaal Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDudbO027449; Thu, 22 Sep 2005 06:56:39 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MDudoa027448; Thu, 22 Sep 2005 06:56:39 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDuc7d027442 for ; Thu, 22 Sep 2005 06:56:38 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 5F3252B47E4; Thu, 22 Sep 2005 15:56:34 +0200 (CEST) Date: Thu, 22 Sep 2005 15:56:34 +0200 To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Message-ID: <20050922135632.GA1725@epointsystem.org> References: <20050922042955.GA30473@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 05:43:57PM +1200, Peter Gutmann wrote: > nagydani@epointsystem.org (Daniel A. Nagy) writes: > > >Now, there exists a cryptographic solution for this problem, moreover, > >RFC2440 even hints that it might be implemented in OpenPGP, though I have > >never seen it used: X9.42 Diffie-Hellman key agreement (see also RFC2630, > >RFC2631 and RFC2633). > > X9.42 was only added to S/MIME for political reasons. AFAIK only one > implementation ever supported it, and that was the USG-funded reference > implementation that was required to support it. In addition, MS supported a > read-only implementation just so they couldn't be accused of not supporting > it. What political reasons? And why is there a reserved ID in OpenPGP? > (I remember having a conversation with a rather baffled security application > developer who wanted to see X9.42 in an S/MIME toolkit and just couldn't > understand that although the spec had it as a MUST requirement, all the > implementors knew that you should ignore it). X9.42 may be flawed (is it?), but DH key agreement is one of the strongest primitives in asymmetric cryptography. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDDDAQ023054; Thu, 22 Sep 2005 06:13:13 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MDDDsY023053; Thu, 22 Sep 2005 06:13:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MDDCxq023043 for ; Thu, 22 Sep 2005 06:13:12 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 09DC45ACCC; Thu, 22 Sep 2005 14:13:07 +0100 (BST) Message-ID: <431093A0.90102@systemics.com> Date: Sat, 27 Aug 2005 17:24:00 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050726) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" Cc: ietf-openpgp@imc.org Subject: Re: Signature types References: <20050827075018.GA17967@epointsystem.org> <20050827135551.GA1832@jabberwocky.com> <20050827152645.GA20223@epointsystem.org> In-Reply-To: <20050827152645.GA20223@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > It's actually RFC1991 that got me wondering: > > <40> - time stamping ("I saw this document") (*) > ... Type <40> is intended to > be a signature of a signature, as a notary seal on a signed document. > > Now, this is contradictory. If a signature does not have any cryptograpic > binding (except the indirect one through the other signature) to the > document, it cannot be used to assert the integrity thereof. > > Someone with the public key of the notary cannot verify this claim. Also, it > makes a lot of sense to certify documents that have not been signed. [snip] >> This signature is a signature over some other OpenPGP >> signature packet(s). It is analogous to a notary seal on the >> signed data. > > > Except that if it's a signature on the signature, then it cannot be > analogous to a notary seal on the signed data (see above). One of the difficulties that may be occuring here is that the word 'notary' has different meanings in civil and common law contexts. In the former, a notary is likely to be interested in the content of the signed data; whereas in the latter, the notary is normally only interested in the quality of the signature, and not the data. We had a long threat on this about a year ago, and I believe some changes were made disambiguate .. I think the context that the Draft uses the word notary is more towards the common law case of just the signature and not the data that is signed. iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MBSamN013342; Thu, 22 Sep 2005 04:28:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8MBSa4h013341; Thu, 22 Sep 2005 04:28:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ethos.braverock.com (ethos.braverock.com [66.92.142.163] (may be forged)) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8MBSZ5S013334 for ; Thu, 22 Sep 2005 04:28:35 -0700 (PDT) (envelope-from brian@braverock.com) Received: from [10.23.2.104] (dsl017-021-008.chi1.dsl.speakeasy.net [69.17.21.8]) (authenticated bits=0) by ethos.braverock.com (8.13.3/8.13.1) with ESMTP id j8MBSYGf012553 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Thu, 22 Sep 2005 06:28:34 -0500 From: "Brian G. Peterson" To: ietf-openpgp@imc.org Subject: Re: Plausible deniability (a feature to think about) Date: Thu, 22 Sep 2005 06:28:33 -0500 User-Agent: KMail/1.8.1 References: <20050922042955.GA30473@epointsystem.org> In-Reply-To: <20050922042955.GA30473@epointsystem.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200509220628.33636.brian@braverock.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wednesday 21 September 2005 11:29 pm, Daniel A. Nagy wrote: > I just got a message from a human rights activist, who pointed out a > shortcoming of PGP for -- for the lack of a better word -- paranoid > conspirators. > > Imagine, that a conspiracy expects to be infiltrated. They send encrypted > messages back and forth but they have a dilemma: to sign or not to sign? If > they do sign, the infiltrator will have damning evidence on his hands and > the bad guys will be able to crack down on the conspirators. If they don't > sign, the infiltrator will be able to forge messages and thus seriously > interfere with the activities of the group (e.g. call off action in the > name of the ringleader, etc.). <...> >The sender can plausibly deny authorship, claiming that the receiver has >forged it using his private key and the sender's public key. Interesting thought experiement. I led the development team of the solution used by the CryptoRights Foundation http://www.cryptorights.org/ our solution consisted of management tools, user interfaces, translations, and other niceties around a gnupg based engine. We were most concerned with chain of evidence and verifiability, not plausible deniability. In the real world, most human rights organizations already have extensive methods of verifying information that is provided to them, and informers have elaborate methods of communicating that information, that only rarely involves electronic communication, encrypted or otherwise, becasue of the danger of interception. In a country (like China) where much/most private use of encryption is disallowed anyway, sending *any* encrypted message is a risk that most human rights workers and informers will not take. I don't think that OpenPGP needs a new shared-secret method of communication, or that the spec needs another wrinkle for implementors to chew on. Regards, - Brian Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M5i09e080861; Wed, 21 Sep 2005 22:44:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8M5i0bn080860; Wed, 21 Sep 2005 22:44:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M5hwM7080835 for ; Wed, 21 Sep 2005 22:43:59 -0700 (PDT) (envelope-from pgut001@cs.auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 25ECF34F33; Thu, 22 Sep 2005 17:43:53 +1200 (NZST) Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07132-10; Thu, 22 Sep 2005 17:43:53 +1200 (NZST) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id DBAD834F32; Thu, 22 Sep 2005 17:43:52 +1200 (NZST) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 42A6237756; Thu, 22 Sep 2005 17:43:52 +1200 (NZST) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1EIJsD-0008KQ-00; Thu, 22 Sep 2005 17:43:57 +1200 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, nagydani@epointsystem.org Subject: Re: Plausible deniability (a feature to think about) In-Reply-To: <20050922042955.GA30473@epointsystem.org> Message-Id: Date: Thu, 22 Sep 2005 17:43:57 +1200 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: nagydani@epointsystem.org (Daniel A. Nagy) writes: >Now, there exists a cryptographic solution for this problem, moreover, >RFC2440 even hints that it might be implemented in OpenPGP, though I have >never seen it used: X9.42 Diffie-Hellman key agreement (see also RFC2630, >RFC2631 and RFC2633). X9.42 was only added to S/MIME for political reasons. AFAIK only one implementation ever supported it, and that was the USG-funded reference implementation that was required to support it. In addition, MS supported a read-only implementation just so they couldn't be accused of not supporting it. (I remember having a conversation with a rather baffled security application developer who wanted to see X9.42 in an S/MIME toolkit and just couldn't understand that although the spec had it as a MUST requirement, all the implementors knew that you should ignore it). >Has anybody ever bothered implementing (or even designing an implementation >of) this in an OpenPGP-friendly manner? See above. Peter. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M4Tv9p074436; Wed, 21 Sep 2005 21:29:57 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8M4TvFd074435; Wed, 21 Sep 2005 21:29:57 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M4TuIp074428 for ; Wed, 21 Sep 2005 21:29:56 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 28FCE2B479A; Thu, 22 Sep 2005 06:29:55 +0200 (CEST) Date: Thu, 22 Sep 2005 06:29:55 +0200 To: ietf-openpgp@imc.org Subject: Plausible deniability (a feature to think about) Message-ID: <20050922042955.GA30473@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just got a message from a human rights activist, who pointed out a shortcoming of PGP for -- for the lack of a better word -- paranoid conspirators. Imagine, that a conspiracy expects to be infiltrated. They send encrypted messages back and forth but they have a dilemma: to sign or not to sign? If they do sign, the infiltrator will have damning evidence on his hands and the bad guys will be able to crack down on the conspirators. If they don't sign, the infiltrator will be able to forge messages and thus seriously interfere with the activities of the group (e.g. call off action in the name of the ringleader, etc.). Now, there exists a cryptographic solution for this problem, moreover, RFC2440 even hints that it might be implemented in OpenPGP, though I have never seen it used: X9.42 Diffie-Hellman key agreement (see also RFC2630, RFC2631 and RFC2633). In addition to signature and encryption keys, one can have a DH subkey which may be used to create a (salted) two-party shared secret session key and send an MDC-protected encnrypted message using that key. Now, the receiving party can be sure that it was composed by the sender, but has no means of proving it to a third party. The sender can plausibly deny authorship, claiming that the receiver has forged it using his private key and the sender's public key. Has anybody ever bothered implementing (or even designing an implementation of) this in an OpenPGP-friendly manner? Seems like it's just a matter of a third ESK type (tentatively called DH-ESK) and a clear definiton of DH keys (for which we have reserved identifier 21), which, I guess, should be identical to ElGamal keys, though it is instrumental that the entie conspiracy used the same modulus and generator element. DH-ESK should be very similar to SK-ESK with a salted (but not iterated) S2K, except for the additional 8-octet IDs of the sender's and the recipient's public DH keys. The usual traffic-analysis thwarting techniques of leaving one or both of them blank obviously apply. Allowing for an ephemeral sender PK to be included is pointless, as that would bring us back to ElGamal encryption (well, almost), for which there is already a PK-ESK. If the MDC verification works out on the receiving end, the implementation should show the message as being "sealed" by the sender on the date from the literal packet, in addition to decrypting it, much like it handles signed+encrypted messages. It's so easy and straightforward that I'd dare to propose it for 2440bis. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M0m8jt055559; Wed, 21 Sep 2005 17:48:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8M0m82q055558; Wed, 21 Sep 2005 17:48:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8M0m7PN055548 for ; Wed, 21 Sep 2005 17:48:07 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc12) with ESMTP id <200509220048010140010bb8e>; Thu, 22 Sep 2005 00:48:01 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8M0m40m022410 for ; Wed, 21 Sep 2005 20:48:04 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8M0lwtX018613 for ; Wed, 21 Sep 2005 20:47:58 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8M0lwlw018612 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 20:47:58 -0400 Date: Wed, 21 Sep 2005 20:47:58 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050922004758.GA18468@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921212613.09EAF57EF5@finney.org> <20050921215503.GA18343@jabberwocky.com> <20050921230320.GB8089@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921230320.GB8089@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 22, 2005 at 01:03:20AM +0200, Daniel A. Nagy wrote: > > On Wed, Sep 21, 2005 at 05:55:03PM -0400, David Shaw wrote: > > > The thing is, I can't really decide if that is a threat or a > > feature... > > In such cases isn't the best policy to let the users and/or implementers decide > for themselves? How about having hashed and unhashed subpackets just like in > v4 signatures, where all are subject to signatures but only the hashed ones > are included in the fingerprint? I think this might cause some serious user confusion. With both types of subpackets, plus the existing v4 signature subpackets, we would have three different ways to specify expiration, each with a slightly different meaning: key-subpacket-in-fingerprint: hard expiration date. All other expiration dates can only be extended to this point. Changing it changes the fingerprint and key ID. key-subpacket-in-signature: soft expiration date. Changing it invalidates all signatures, but does not change the fingerprint/key ID. regular-old-selfsig: very soft expiration date. Can be changed at any time with no impact on anything but the expiration date. Then we have various combinations of the above... David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LNORiA049141; Wed, 21 Sep 2005 16:24:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LNOR1l049140; Wed, 21 Sep 2005 16:24:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LNOQUm049134 for ; Wed, 21 Sep 2005 16:24:26 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from smtp3.hushmail.com (localhost.hushmail.com [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 3AE50A3491 for ; Wed, 21 Sep 2005 16:24:26 -0700 (PDT) Received: from mailserver5.hushmail.com (mailserver5.hushmail.com [65.39.178.19]) by smtp3.hushmail.com (Postfix) with ESMTP for ; Wed, 21 Sep 2005 16:24:25 -0700 (PDT) Received: by mailserver5.hushmail.com (Postfix, from userid 65534) id A64E933C58; Wed, 21 Sep 2005 16:24:25 -0700 (PDT) Date: Wed, 21 Sep 2005 16:24:22 -0700 To: Cc: Subject: Re: Problems with v4 key packet format From: Message-Id: <20050921232425.A64E933C58@mailserver5.hushmail.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 21 Sep 2005 14:55:03 -0700 David Shaw wrote: > It >would >(somewhat) allow someone to violate a hard expiration date on >their >key: make the key, get signatures, and then when the key expires, >just >remake the key. Essentially you can buy an extension on your >"hard" >expiration time at the cost of losing all of your signatures. > >The thing is, I can't really decide if that is a threat or a >feature... to the unsuspecting users who thought that an 'expired' key is *really* expired, it would be confusing to have someone claim, "i 'revived' it, it was dead, but it's better now, just re-sign it and trust it again ..." so, while not really a threat, and not really a feature, it potentially could add to the confusion of the key trust issue, rather than simplify it... vedaal Concerned about your privacy? Follow this link to get secure FREE email: http://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger http://www.hushmail.com/services-messenger?l=434 Promote security and make money with the Hushmail Affiliate Program: http://www.hushmail.com/about-affiliate?l=427 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LN3MnB046890; Wed, 21 Sep 2005 16:03:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LN3M5r046889; Wed, 21 Sep 2005 16:03:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LN3LBj046881 for ; Wed, 21 Sep 2005 16:03:22 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id E3D302B47DB; Thu, 22 Sep 2005 01:03:20 +0200 (CEST) Date: Thu, 22 Sep 2005 01:03:20 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921230320.GB8089@epointsystem.org> References: <20050921212613.09EAF57EF5@finney.org> <20050921215503.GA18343@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921215503.GA18343@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 05:55:03PM -0400, David Shaw wrote: > The thing is, I can't really decide if that is a threat or a > feature... In such cases isn't the best policy to let the users and/or implementers decide for themselves? How about having hashed and unhashed subpackets just like in v4 signatures, where all are subject to signatures but only the hashed ones are included in the fingerprint? -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LN0kXR046727; Wed, 21 Sep 2005 16:00:46 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LN0kZQ046726; Wed, 21 Sep 2005 16:00:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LN0i7P046719 for ; Wed, 21 Sep 2005 16:00:45 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id D92882B47DB; Thu, 22 Sep 2005 01:00:43 +0200 (CEST) Date: Thu, 22 Sep 2005 01:00:43 +0200 To: Hal Finney , ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921230038.GA8089@epointsystem.org> References: <20050921212613.09EAF57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921212613.09EAF57EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote: > > Careful! If this information is not part of the fingerprint/keyID it can > > still be changed by updating the self-signature, no matter whether it's in > > thte signature packet or in the key packet. > > Not exactly, the self-signature would not (by convention) override the > information in the key subpackets. So just issuing a new self-signature > would not help. That's not what I meant. If the self-signanture is the only integrity protection measure, then someone in possession of the private part of the key can alter the expiration date in the key packet just as he can alter it in the signature subpacket. If it's hashed with the key ID, changing it would also change the key ID, ergo resulting in a different key. > What could happen is that someone who got hold of the private material > could create a new key packet with the same keyid/fingerprint but with > a different expiration date. But(!) the new key would not inherit the > signatures on the old key. That's correct. > That is what I was thinking of as important. > It would not be valid, it would not be part of the Web of Trust. > The idea is that key signatures would cover all of the subpackets, > even though fingerprints do not. And what about keys that are not part of WoT? In the present standard, I can trust a key not only because someone I trust has signed it, but also because I know the fingerprint. Should we break that? > This is a good point, I'll have to think about it. I'm still not > sure that covering this material with key fingerprints and keyids is > the right thing to do. Me neither, but the more I think about it, the more I am leaning towards giving the choice to the user by having hashed and unhashed subpackets, both of which are signed, but only the hashed ones being included in the fingerprint. But I'll have to think more about it myself. > What would the security threats be from being > able to bring a key back to life with the same fingerprint and keyid, > but without any signatures on it being valid? Well, it depends on the applicatiton and the user's trust model. What I like most about OpenPGP is the flexibility of the trust model. Ignoring the WoT is certainly an option I would like to have. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLtC3q040049; Wed, 21 Sep 2005 14:55:12 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LLtCfc040048; Wed, 21 Sep 2005 14:55:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLtBn4040039 for ; Wed, 21 Sep 2005 14:55:12 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <20050921215506015004247re>; Wed, 21 Sep 2005 21:55:06 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8LLt80m021948 for ; Wed, 21 Sep 2005 17:55:08 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8LLt3GE018367 for ; Wed, 21 Sep 2005 17:55:03 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8LLt3hE018366 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 17:55:03 -0400 Date: Wed, 21 Sep 2005 17:55:03 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921215503.GA18343@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921212613.09EAF57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921212613.09EAF57EF5@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 02:26:13PM -0700, "Hal Finney" wrote: > > If you're importing a foreign key or generating one on the fly, you don't > > put subpackets into the key that cannot be determined next time you use the > > same source to get the key. A flag in a subpacket indicating where the key > > comes from might be useful, though. > > This is a good point, I'll have to think about it. I'm still not > sure that covering this material with key fingerprints and keyids is > the right thing to do. What would the security threats be from being > able to bring a key back to life with the same fingerprint and keyid, > but without any signatures on it being valid? My original idea with subpackets was that they would be part of the fingerprint, and changing a subpacket was akin to making a whole new key as the fingerprint and key ID (though not the key material) would change. I see some advantages of what you are discussing. It would (somewhat) allow someone to violate a hard expiration date on their key: make the key, get signatures, and then when the key expires, just remake the key. Essentially you can buy an extension on your "hard" expiration time at the cost of losing all of your signatures. The thing is, I can't really decide if that is a threat or a feature... David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLQMTw036632; Wed, 21 Sep 2005 14:26:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LLQM82036631; Wed, 21 Sep 2005 14:26:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLQLlo036625 for ; Wed, 21 Sep 2005 14:26:21 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 09EAF57EF5; Wed, 21 Sep 2005 14:26:13 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-Id: <20050921212613.09EAF57EF5@finney.org> Date: Wed, 21 Sep 2005 14:26:13 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > On Wed, Sep 21, 2005 at 09:52:33AM -0700, "Hal Finney" wrote: > > I would like to see immutable material put there. One thing that bothers > > me in the current V4 is that the key's expiration date can be changed by > > updating the self-signature. Suppose your key has expired and you don't > > use it any more. As a result perhaps you don't protect it that well. > > If someone gets hold of the private part, they can issue a new self-sig > > with a new expiration date and bring this dead key back to life. It would > > be better if a dead key would stay dead. Expiration date and creation > > date would be better placed in the key packet, IMO (as they were with > > V3 keys). > > Careful! If this information is not part of the fingerprint/keyID it can > still be changed by updating the self-signature, no matter whether it's in > thte signature packet or in the key packet. Not exactly, the self-signature would not (by convention) override the information in the key subpackets. So just issuing a new self-signature would not help. What could happen is that someone who got hold of the private material could create a new key packet with the same keyid/fingerprint but with a different expiration date. But(!) the new key would not inherit the signatures on the old key. That is what I was thinking of as important. It would not be valid, it would not be part of the Web of Trust. The idea is that key signatures would cover all of the subpackets, even though fingerprints do not. > David's idea with sub-packets should be implemented in such a way that > hashed sub-packets are part of the fingerprint. Maybe, we don't even need > unhashed sub-packets. > > If you're importing a foreign key or generating one on the fly, you don't > put subpackets into the key that cannot be determined next time you use the > same source to get the key. A flag in a subpacket indicating where the key > comes from might be useful, though. This is a good point, I'll have to think about it. I'm still not sure that covering this material with key fingerprints and keyids is the right thing to do. What would the security threats be from being able to bring a key back to life with the same fingerprint and keyid, but without any signatures on it being valid? Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLDIY8035056; Wed, 21 Sep 2005 14:13:18 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LLDIjr035055; Wed, 21 Sep 2005 14:13:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LLDGZF035049 for ; Wed, 21 Sep 2005 14:13:17 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 2CF192B47DD; Wed, 21 Sep 2005 23:13:16 +0200 (CEST) Date: Wed, 21 Sep 2005 23:13:16 +0200 To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050921211316.GB2316@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry, something being "pareto complete for a particular purpose" is an abuse of Ian's definition. SHA1 is not pareto-complete, but still pareto-secure if collision-resistance is not an issue. There is a number of good papers on truncating hash functions for message authentication and there's a general consensus that at least 80 bits or half of the bits (whichever is more) of a full-stregth hash function are sufficient for medium-term security. For long term, I would upgrade that to 128 bits, and taking into account known and unforseen weeknesses of hash functions, using 160 bits should satisfy even the most paranoid. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LL0HgZ034028; Wed, 21 Sep 2005 14:00:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LL0H4R034026; Wed, 21 Sep 2005 14:00:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LL0GG9034020 for ; Wed, 21 Sep 2005 14:00:16 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 769002B47E9; Wed, 21 Sep 2005 23:00:15 +0200 (CEST) Date: Wed, 21 Sep 2005 23:00:15 +0200 To: ietf-openpgp@imc.org Subject: Re: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050921210015.GA2316@epointsystem.org> References: <20050921202208.GB18050@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921202208.GB18050@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As before, I would like to express my concerns about allowing a choice of hash algorithms. Here's some detail: A complete break (feasible reversal) of ANY ONE of the supported hash algorithms would allow generating keys with arbitrary long key IDs, possibly colliding with an attacked key. This was a major problem with v3 and v4 was a giant step in the right direction. This would be a small step backwards. For MDC purposes, it's even worse. Since collisions are of no concern in the case of the key fingerprint and MDC, I would just stick to SHA1 for the time being. Precisely because of this, assuming a full-strength hash function, half of the hash suffices. This is just a remark to the length requirement. 128 bit fingerprints are secure for the forseable future, but using the 160 bit SHA1 (with all its problems), is a reasonable overdesign taking into account what we don't know. Collision resistance is important for signatures and even more so for certifications, but it is of no concern whatsoever for fingerprints and MDC. Where RFC2440 has SHA1 hardwired into the spec, it is completely safe and even somewhat of an overkill. Using Ian's terminology, it's still pareto-secure and even pareto-complete. No alternative would provide more security. Signatures and certifications are a completely different issue altogether. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LKMgll027954; Wed, 21 Sep 2005 13:22:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LKMgtL027953; Wed, 21 Sep 2005 13:22:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LKMgmV027939 for ; Wed, 21 Sep 2005 13:22:42 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005092120221201400oggeke>; Wed, 21 Sep 2005 20:22:13 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8LKMD0m021641 for ; Wed, 21 Sep 2005 16:22:13 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8LKM8wn018152 for ; Wed, 21 Sep 2005 16:22:08 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8LKM8bl018151 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 16:22:08 -0400 Date: Wed, 21 Sep 2005 16:22:08 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Some thoughts on a v5 key and why it shouldn't be a mess (fwd) Message-ID: <20050921202208.GB18050@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is my original mail about V5 and keys with subpackets. Since V5 is being discussed now, it seems reasonable to repost. David ----- Forwarded message from David Shaw ----- Date: Mon, 21 Feb 2005 12:11:31 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Some thoughts on a v5 key and why it shouldn't be a mess Mail-Followup-To: ietf-openpgp@imc.org OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc I had around 10 hours in a car this weekend, which gave me a good bit of time to think some more about the v5 key idea. I don't see this as a "drop everything and do v5" suggestion. It's more of a "design v5 in 2005, because we need it a few years from now". Attacks only get better, and if we want to be able to shrug off a future SHA-1 break like we were able to shrug off the MD5 break, we need to start the process. While this is prompted by the SHA-1 problems, note that NIST was already replacing SHA-1 with the SHA-2 family by 2010 for size reasons. Even if the recent SHA-1 problems hadn't happened, I'd still think it was time to start designing a v5 key. I don't think there needs to be a lot of fear over a version number bump. To be sure, the change from v3 to v4 was disruptive. In one step, the packet format, the default symmetric cipher, and the public-key algorithm was changed. Even the concept of a key was altered by adding subkeys. I'm not criticizing - the changes were necessary for many reasons, but unfortunately they also split the user base into "before" and "after", with interoperability problems between the two groups. In some (occasionally frustrating) corners, the change hasn't even happened yet. I don't see the change from v4 to v5 being nearly as disruptive as the v3 to v4 change. The straw proposal I'm putting forth here is an incremental change over v4, large enough to be worth doing, small enough that if the change is done carefully, it should be painless. v4 and the proposed v5 can also quite happily co-exist without anyone noticing or caring. Note that I'm not talking about making a v5 signature at this point. Here is a proposed packet format for a v5 key, interspersed with comments. Obviously, not every detail is given, but the general ideas should be clear: - A one-octet version number (5). - A one-octet hash algorithm number. This is an attempt to balance Jon's comments about 160 bits being all that a human user can handle for a fingerprint, and the desire to not be locked to SHA-1 in case of future trouble. Essentially you set this value to the fingerprint hash you want to use for this key. The value itself is hashed into the fingerprint (and signatures on the key), so it cannot be changed once the key is generated. Is is possible for different v5 key fingerprints to be of different lengths. A v5 fingerprint is written "algo - colon - data", like 2:12 34 56 78 9A BC DE F0 ...(etc). The v5 keyid concept is the same as v4: the keyid is the lower 32 or 64 bits of the fingerprint, however long it may be. There are some problems with this idea, not least that any implementation that doesn't understand the hash algorithm won't be able to use the key. It may well be better to lock this value to SHA-256 and be done with it. - A two-octet scalar octet count for the following subpacket data. Note that this is the length in octets of all of the hashed subpackets; a pointer incremented by this number will skip over the subpackets. - Subpacket data. Yes, v5 keys have subpackets. It's a bit of future-proofing since it is a lot easier to add a subpacket than it is to go to a v6 key format. Note that there are no "unhashed" subpackets here. All subpackets are hashed into the fingerprint, and therefore are fixed at key generation time. The subpacket numbers do not need to be the same as signature subpackets, but the encoding format is the same, and the critical bit has the same meaning here as it does for signatures. Only one subpacket comes to mind at the moment, and that is: Expiration time (4 octet time field) The validity period limit of the key. This is the number of seconds after the key creation time that the key must expire by. If this is not present or has a value of zero, the key has no hard expiration. This gives a "hard" expiration time which cannot be extended, unlike the current "soft" expiration in v4. There were a number of disagreements over the v4 soft expirations, and while it's an interesting discussion, at the end of the day there are good reasons to support both. In practice, this key subpacket sets a hard limit on the lifetime of a key, and any soft expirations can only affect the lifetime of the key up to that hard point. No hard expiration acts just like v4. Users can mix the two to give whatever semantics they want. - A four-octet number denoting the time that the key was created. This might be better as a subpacket, but then implementers would have to deal with the case if it was missing. - A one-octet number denoting the public key algorithm of this key. - A series of multiprecision integers comprising the key material. Same as v4. There is no need to change MPIs around. There are only so many ways to store large numbers in a row. The v5 secret keys, like the v4 secret keys, are the same as the public key with the secret material appended. An additional change, which is not part of the key packet format is that v5 keys have AES as both their "last resort" and "must implement" ciphers. When encrypting to v4 and v5 keys together, the default cipher is 3DES. One way to look at this is that cipher preferences on a v5 key have "AES, 3DES" implicitly at the end if not explicitly used earlier. When combined with the implicit "3DES" already at the end of a v4 preference list, the right thing will happen automatically. Note that while AES is the "must" cipher for v5, implementations that support v4 keys must also implement 3DES. To make the transition from v4 to v5 as invisible as possible, I'd suggest having read support for this in implementations for as long as possible (say, 1 year) before allowing users to create these keys. This gives time for upgrading (and there will be a certain amount of upgrading for other reasons during that time as well, which the v5 keys can be included with), and for various other processes that interact with OpenPGP like keyservers to be updated. I also suggest that this not be a part of 2440bis. The v5 discussions will undoubtedly take a while, and delaying 2440bis for an unknown (but probably long) period of time seems a shame. Anyway, this is a starting point. Please thow darts and make suggestions. David ----- End forwarded message ----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LKJbkg027694; Wed, 21 Sep 2005 13:19:38 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LKJbxZ027693; Wed, 21 Sep 2005 13:19:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [63.240.76.49]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LKJbl6027682 for ; Wed, 21 Sep 2005 13:19:37 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc14) with ESMTP id <2005092120192801400jq001e>; Wed, 21 Sep 2005 20:19:29 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8LKJW0m021625 for ; Wed, 21 Sep 2005 16:19:32 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8LKJMRD018140 for ; Wed, 21 Sep 2005 16:19:22 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8LKJL74018139 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 16:19:21 -0400 Date: Wed, 21 Sep 2005 16:19:21 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921201921.GA18050@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050921165233.74FAA57EF5@finney.org> <20050921195621.GB10842@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921195621.GB10842@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 09:56:38PM +0200, Daniel A. Nagy wrote: > > On Wed, Sep 21, 2005 at 09:52:33AM -0700, "Hal Finney" wrote: > > > > 3. Key fingerprint depends on data unrelated to the actual key (namely: > > > creation date). > > > > Yes, this has hurt our PGP implementation when dealing with foreign keys > > such as X.509 certificates. If we want to import a raw modulus+exponent > > pair as a PGP key, and we want to know if we already have one on the > > keyring, we can't easily compute a fingerprint and look for a match, > > because creation date affects fingerprints. I agree that fingerprints > > should just be over the formatted key material. > > > > > 4. More generally, creation time does not belong to the key packet. > > > > > > Because it is just an attribute of the key as any other, thus belonging to > > > certificatiton signature sub-packets, rather than the key packet. > > > > I like David's idea better to have some sub-packets in the V5 key. > > Me too. > > > I would like to see immutable material put there. One thing that bothers > > me in the current V4 is that the key's expiration date can be changed by > > updating the self-signature. Suppose your key has expired and you don't > > use it any more. As a result perhaps you don't protect it that well. > > If someone gets hold of the private part, they can issue a new self-sig > > with a new expiration date and bring this dead key back to life. It would > > be better if a dead key would stay dead. Expiration date and creation > > date would be better placed in the key packet, IMO (as they were with > > V3 keys). > > Careful! If this information is not part of the fingerprint/keyID it can > still be changed by updating the self-signature, no matter whether it's in > thte signature packet or in the key packet. > > David's idea with sub-packets should be implemented in such a way that > hashed sub-packets are part of the fingerprint. Maybe, we don't even need > unhashed sub-packets. There have been a number of mentions of the key-with-subpackets idea recently, so I'll repost the mail where I first proposed the idea. It has many more details than I mentioned in this thread. In short though, the subpackets are hashed into the fingerprint and any certification signatures (including self signatures). In my proposal there are no unhashed subpackets. In the case of expiration, we would have two different ways to specify expiration. The expiration time hashed into the key is a hard expiration time that cannot be extended. The expiration time in the self-signature is a soft expiration time that can be extended or changed whenever desired - but only up to the hard limit given in the key itself. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJugW6025241; Wed, 21 Sep 2005 12:56:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LJug0q025240; Wed, 21 Sep 2005 12:56:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJuevi025234 for ; Wed, 21 Sep 2005 12:56:41 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 4F9662B47ED; Wed, 21 Sep 2005 21:56:38 +0200 (CEST) Date: Wed, 21 Sep 2005 21:56:38 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921195621.GB10842@epointsystem.org> References: <20050921165233.74FAA57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921165233.74FAA57EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 09:52:33AM -0700, "Hal Finney" wrote: > > 3. Key fingerprint depends on data unrelated to the actual key (namely: > > creation date). > > Yes, this has hurt our PGP implementation when dealing with foreign keys > such as X.509 certificates. If we want to import a raw modulus+exponent > pair as a PGP key, and we want to know if we already have one on the > keyring, we can't easily compute a fingerprint and look for a match, > because creation date affects fingerprints. I agree that fingerprints > should just be over the formatted key material. > > > 4. More generally, creation time does not belong to the key packet. > > > > Because it is just an attribute of the key as any other, thus belonging to > > certificatiton signature sub-packets, rather than the key packet. > > I like David's idea better to have some sub-packets in the V5 key. Me too. > I would like to see immutable material put there. One thing that bothers > me in the current V4 is that the key's expiration date can be changed by > updating the self-signature. Suppose your key has expired and you don't > use it any more. As a result perhaps you don't protect it that well. > If someone gets hold of the private part, they can issue a new self-sig > with a new expiration date and bring this dead key back to life. It would > be better if a dead key would stay dead. Expiration date and creation > date would be better placed in the key packet, IMO (as they were with > V3 keys). Careful! If this information is not part of the fingerprint/keyID it can still be changed by updating the self-signature, no matter whether it's in thte signature packet or in the key packet. David's idea with sub-packets should be implemented in such a way that hashed sub-packets are part of the fingerprint. Maybe, we don't even need unhashed sub-packets. If you're importing a foreign key or generating one on the fly, you don't put subpackets into the key that cannot be determined next time you use the same source to get the key. A flag in a subpacket indicating where the key comes from might be useful, though. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJnFfF024550; Wed, 21 Sep 2005 12:49:15 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LJnFSj024549; Wed, 21 Sep 2005 12:49:15 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LJnE0f024539 for ; Wed, 21 Sep 2005 12:49:14 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 3C3C42B47EA; Wed, 21 Sep 2005 21:49:13 +0200 (CEST) Date: Wed, 21 Sep 2005 21:49:13 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921194913.GA10842@epointsystem.org> References: <20050921165233.74FAA57EF5@finney.org> <87aci6nxtp.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87aci6nxtp.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 07:18:58PM +0200, Werner Koch wrote: > The suggestion was that we put a hard-expiration into a v5 key packet > but keep the existing soft-expiration in the self-signature. I think, David's subpacket solution accomodates for this without being overly restrictive. If you want to make sure your key stays dead after expiration, you put a hashed expiration date subpacket into your key. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LHLZlj010244; Wed, 21 Sep 2005 10:21:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LHLZe0010243; Wed, 21 Sep 2005 10:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LHLYWY010235 for ; Wed, 21 Sep 2005 10:21:34 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EI8O3-0000V0-6a for ; Wed, 21 Sep 2005 19:28:03 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EI8FG-0003CL-Dg; Wed, 21 Sep 2005 19:18:58 +0200 To: hal@finney.org ("Hal Finney") Cc: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format References: <20050921165233.74FAA57EF5@finney.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Wed, 21 Sep 2005 19:18:58 +0200 In-Reply-To: <20050921165233.74FAA57EF5@finney.org> (Hal Finney's message of "Wed, 21 Sep 2005 09:52:33 -0700 (PDT)") Message-ID: <87aci6nxtp.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 21 Sep 2005 09:52:33 -0700 (PDT), "Hal Finney" said: > be better if a dead key would stay dead. Expiration date and creation > date would be better placed in the key packet, IMO (as they were with > V3 keys). We discussed this issue a long time ago and came to the conclusion that both kinds of exiration dates make a lot of sense. Prolonging the expiration time is something what quite some users are doing now on a regular basis. If nothing else it helps against a lost passphrase. The suggestion was that we put a hard-expiration into a v5 key packet but keep the existing soft-expiration in the self-signature. Salam-Shalom, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGqhNb007032; Wed, 21 Sep 2005 09:52:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGqhst007031; Wed, 21 Sep 2005 09:52:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGqgwZ007024 for ; Wed, 21 Sep 2005 09:52:42 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 74FAA57EF5; Wed, 21 Sep 2005 09:52:33 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-Id: <20050921165233.74FAA57EF5@finney.org> Date: Wed, 21 Sep 2005 09:52:33 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Let me give my responses to Daniel's points about V4 key packets. First I want to mention that Ian seemed to take a much larger view and wanted to redesign the whole of the OpenPGP format. V4 to V5 key packets is only one small part of the spec. No one is proposing to redo OpenPGP from scratch here. > 1. No cryptographic binding between the encrypted private key material and > the public key material. > > This results in a serious security issue, by allowing an attacker to replace > the public material thus compromising the private material with the first > use in the signature. There are various stop-gap measures to deal with this > attack, but the only sure protetction would be some MDC binding together the > private and the public key material. This is a very good point, and it is a little different from the previous attacks. If we had thought of it, we would have tried to fix it when we added the checksum over the private key material. The previous attack involved modifying some private key material and causing the signature algorithm to fail. In RSA keys, if you hack just one of p or q and get it to do the signature using the Chinese Remainder Theorem (CRT), the resulting value can leak the other of p or q and therefore leak your private key. To defend against this we added a SHA-1 hash over the private material as a checksum. Daniel proposes an extension to the attack where the private key material is left alone and the public material (in the private key packet) is modified. I don't think this would do anything on RSA keys, as the CRT based signature algorithm does not use the public modulus or exponent. However it would be effective against DSA keys. The attacker could change p and q to be much smaller values, such that discrete logs were feasible, then request a DSA signature using these values, solve the discrete log and reveal x (the private value) mod q. Do this a few times with different q's would reveal x. Had we thought about this, we could easily have had the SHA-1 hash cover the public as well as the private key material, but we didn't, unfortunately. Putting some size-based sanity checks in the DSA signature code might be a good idea though. I don't know if there are other variations on the attack that could also be addressed for now with sanity checks. > 2. No explicit count of MPIs constituting the key material (both public and > private). > > This information can only be inferred from the algorithm specifier, meaning > that any implementation that wants to perform key management must have some > rudimentary knowledge about all public key algorithms. This, in turn, > hampers forward-compatibility. I am inclined to agree with David that there is not much point to being able to parse a packet's details when we can't do anything useful with it. > 3. Key fingerprint depends on data unrelated to the actual key (namely: > creation date). > > This prevents solutions when signature keys are generated on the fly (e.g. > directly from a passphrase), as the key creation (or, in this case, key > registration) date is not available at the time of signing, thus making it > impossible to put am unambiguous reference to the public key into the > signature. Yes, this has hurt our PGP implementation when dealing with foreign keys such as X.509 certificates. If we want to import a raw modulus+exponent pair as a PGP key, and we want to know if we already have one on the keyring, we can't easily compute a fingerprint and look for a match, because creation date affects fingerprints. I agree that fingerprints should just be over the formatted key material. > 4. More generally, creation time does not belong to the key packet. > > Because it is just an attribute of the key as any other, thus belonging to > certificatiton signature sub-packets, rather than the key packet. I like David's idea better to have some sub-packets in the V5 key. I would like to see immutable material put there. One thing that bothers me in the current V4 is that the key's expiration date can be changed by updating the self-signature. Suppose your key has expired and you don't use it any more. As a result perhaps you don't protect it that well. If someone gets hold of the private part, they can issue a new self-sig with a new expiration date and bring this dead key back to life. It would be better if a dead key would stay dead. Expiration date and creation date would be better placed in the key packet, IMO (as they were with V3 keys). Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGg0IP006194; Wed, 21 Sep 2005 09:42:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGg07L006193; Wed, 21 Sep 2005 09:42:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGfx5e006183 for ; Wed, 21 Sep 2005 09:42:00 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id D33212B47DD; Wed, 21 Sep 2005 18:41:57 +0200 (CEST) Date: Wed, 21 Sep 2005 18:41:56 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921164155.GC10971@epointsystem.org> References: <20050920053207.GA5245@epointsystem.org> <433151EB.6050805@algroup.co.uk> <20050921125619.GB15822@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921125619.GB15822@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 08:56:19AM -0400, David Shaw wrote: > You could also do what GnuPG does - if it doesn't know the algorithm > it just reads the entire list of MPIs (or anything else in the packet) > into an opaque buffer. I suppose it could figure out the MPIs, but > there seems to be little point since either way, the key is not usable > without support for the algorithm. I suppose if the implementation > stored keys in a backend that needed to know the individual key > parameters that would be different. That's what I actually do. But I don't like it. From an OO perspective, it makes certain abstractions less efficient. > Some people want to include things in the key fingerprint and some > don't. There are good reasons for both, so I favor v5 keys with > optional subpackets like v4 signatures. Within reason, it's a "make > everyone happy" solution. Excellent idea! Maybe, we can use a common set of subpackets, where some make sense only in signatures while others only in keys. There are too many overlaps for warranting a separate design. -- Daniels Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGcEDU005861; Wed, 21 Sep 2005 09:38:14 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGcE13005860; Wed, 21 Sep 2005 09:38:14 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGcDGc005852 for ; Wed, 21 Sep 2005 09:38:13 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 993F02B4806; Wed, 21 Sep 2005 18:36:48 +0200 (CEST) Date: Wed, 21 Sep 2005 18:36:48 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921163646.GB10971@epointsystem.org> References: <20050920053207.GA5245@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920053207.GA5245@epointsystem.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Oh, one item that I forgot to include in my list: Encrypted private key packets are superfluous, IMO. Internally, it can be up to the implementation how it secures private keys (as it varies from situation to situation what the requirements and environmental assumptions are), while for interoperability, it's perfectly secure to export unencrypted private key packets (and the auxiliary stuff) within an MDC-protected encrypted data packet, with some ESK in front of it. This way, designers and implementers would only need to worry only about the security of one MDC-protected encrypted data packet format, instead of two, slightly different ones. The only capability that would be lost is exporting and importing private keys without knowing the corresponding passphrases, but I can't imagine legitimate uses for that anyway, while such an action may well be part of some more sophisticated active attack. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGaeu1005609; Wed, 21 Sep 2005 09:36:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGaeod005608; Wed, 21 Sep 2005 09:36:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtpauth08.mail.atl.earthlink.net (smtpauth08.mail.atl.earthlink.net [209.86.89.68]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGaeUL005602 for ; Wed, 21 Sep 2005 09:36:40 -0700 (PDT) (envelope-from frantz@pwpconsult.com) Received: from [68.164.87.96] (helo=[192.168.1.5]) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1EI7aJ-0000Gs-Ra for ietf-openpgp@imc.org; Wed, 21 Sep 2005 12:36:40 -0400 Date: Wed, 21 Sep 2005 09:36:37 -0700 From: Bill Frantz Subject: Re: Bigger DSA keys To: ietf-openpgp@imc.org X-Priority: 3 In-Reply-To: <432D5936.5020701@algroup.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: Mailsmith 2.1.5 (Blindsider) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c952702934c0bba4bd40b011a7917318350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.164.87.96 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j8LGaeUL005603 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 9/18/05, ben@algroup.co.uk (Ben Laurie) wrote: > >Ian G wrote: >> Numbers? > >I was going to provide them, but accurate numbers for DSA is difficult, >because it requires modifying the core code in OpenSSL (or some other >DSA generator), and I couldn't be bothered. > >One can get a feel for it with: > >time openssl gendh I'm not sure, based on these numbers, that this benchmark procedure is reproducible enough to give valid data with only one sample per prime size. However, here is what I got. On a Mac G4/450MHz running OS 10.3.9: [G4:~] billfran% time openssl gendh 512 ... 9.850u 0.170s 0:18.39 54.4% 0+0k 3+7io 0pf+0w [G4:~] billfran% time openssl gendh 1024 ... 11.920u 0.070s 0:13.19 90.9% 0+0k 0+3io 0pf+0w [G4:~] billfran% time openssl gendh 2048 ... 5909.970u 24.060s 1:45:08.60 94.0% 0+0k 0+4io 0pf+0w [G4:~] billfran% time openssl gendh 3072 ... 21017.450u 166.540s 6:42:28.96 87.7% 0+0k 0+3io 0pf+0w Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGLZ85003687; Wed, 21 Sep 2005 09:21:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LGLZvY003686; Wed, 21 Sep 2005 09:21:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LGLYRb003679 for ; Wed, 21 Sep 2005 09:21:35 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 65AA02B47E9; Wed, 21 Sep 2005 18:21:32 +0200 (CEST) Date: Wed, 21 Sep 2005 18:21:31 +0200 To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921162119.GA10971@epointsystem.org> References: <20050920053207.GA5245@epointsystem.org> <433151EB.6050805@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433151EB.6050805@algroup.co.uk> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 01:28:27PM +0100, Ben Laurie wrote: > I don't understand this attack. It's the well-known Klima-Rosa attack. It has been discussed earlier on this list. > >2. No explicit count of MPIs constituting the key material (both public and > >private). > > > >This information can only be inferred from the algorithm specifier, meaning > >that any implementation that wants to perform key management must have some > >rudimentary knowledge about all public key algorithms. This, in turn, > >hampers forward-compatibility. > > This appears to me to be incorrect - an implementation that didn't know > the algorithm could still deduce the number of MPIs by parsing the > packet until it is exhausted. Except for private key packets. > This would mean introducing a requirement > that all public key parameters were MPIs, of course. That, too. > >3. Key fingerprint depends on data unrelated to the actual key (namely: > >creation date). > > > >This prevents solutions when signature keys are generated on the fly (e.g. > >directly from a passphrase), as the key creation (or, in this case, key > >registration) date is not available at the time of signing, thus making it > >impossible to put am unambiguous reference to the public key into the > >signature. > > Not impossible, but I'll agree, crufty. One could use a fixed creation date. That's a horrible cruft breaking all sorts of things (validity period, etc.). I like Dave's suggestion about adding optional subpackets, similar to those in signatures. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCuQaD081294; Wed, 21 Sep 2005 05:56:26 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LCuQEG081293; Wed, 21 Sep 2005 05:56:26 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [63.240.76.28]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCuQRU081282 for ; Wed, 21 Sep 2005 05:56:26 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <2005092112562001300a77npe>; Wed, 21 Sep 2005 12:56:20 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8LCuM0m019742 for ; Wed, 21 Sep 2005 08:56:22 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8LCuJZ8017441 for ; Wed, 21 Sep 2005 08:56:19 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8LCuJfE017440 for ietf-openpgp@imc.org; Wed, 21 Sep 2005 08:56:19 -0400 Date: Wed, 21 Sep 2005 08:56:19 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format Message-ID: <20050921125619.GB15822@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050920053207.GA5245@epointsystem.org> <433151EB.6050805@algroup.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <433151EB.6050805@algroup.co.uk> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 01:28:27PM +0100, Ben Laurie wrote: > >2. No explicit count of MPIs constituting the key material (both public and > >private). > > > >This information can only be inferred from the algorithm specifier, meaning > >that any implementation that wants to perform key management must have some > >rudimentary knowledge about all public key algorithms. This, in turn, > >hampers forward-compatibility. > > This appears to me to be incorrect - an implementation that didn't know > the algorithm could still deduce the number of MPIs by parsing the > packet until it is exhausted. This would mean introducing a requirement > that all public key parameters were MPIs, of course. You could also do what GnuPG does - if it doesn't know the algorithm it just reads the entire list of MPIs (or anything else in the packet) into an opaque buffer. I suppose it could figure out the MPIs, but there seems to be little point since either way, the key is not usable without support for the algorithm. I suppose if the implementation stored keys in a backend that needed to know the individual key parameters that would be different. > >3. Key fingerprint depends on data unrelated to the actual key (namely: > >creation date). > > > >This prevents solutions when signature keys are generated on the fly (e.g. > >directly from a passphrase), as the key creation (or, in this case, key > >registration) date is not available at the time of signing, thus making it > >impossible to put am unambiguous reference to the public key into the > >signature. > > Not impossible, but I'll agree, crufty. One could use a fixed creation date. Some people want to include things in the key fingerprint and some don't. There are good reasons for both, so I favor v5 keys with optional subpackets like v4 signatures. Within reason, it's a "make everyone happy" solution. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCmPUG080687; Wed, 21 Sep 2005 05:48:25 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LCmPDt080686; Wed, 21 Sep 2005 05:48:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCmOCe080678 for ; Wed, 21 Sep 2005 05:48:24 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id AACDE33C1A; Wed, 21 Sep 2005 13:48:23 +0100 (BST) Message-ID: <43315698.4030607@algroup.co.uk> Date: Wed, 21 Sep 2005 13:48:24 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" CC: OpenPGP Subject: Re: Bigger DSA keys References: <20050920014429.2762157EF5@finney.org> <20050920083438.GA2105@bitchcake.off.net> <20050920085432.GC24261@epointsystem.org> In-Reply-To: <20050920085432.GC24261@epointsystem.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > On Tue, Sep 20, 2005 at 04:34:38AM -0400, Adam Back wrote: > > >>Could one not use the Lim Lee safe prime generation method for DSA? >> >>It has significant speed advantages. >> >>Adam > > > DSS explicitly specifies how to generate primes for DSA keys. It can be > easily generalized for larger keys and other hash functions, and its > reasonable to assume that the new DSS will do that. > > My estimates were based on that specification. You only have to follow DSS if you want FIPS-140 and the like, of course. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCSRYP078817; Wed, 21 Sep 2005 05:28:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LCSRUj078816; Wed, 21 Sep 2005 05:28:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCSREP078810 for ; Wed, 21 Sep 2005 05:28:27 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 712BF33C1B; Wed, 21 Sep 2005 13:28:26 +0100 (BST) Message-ID: <433151EB.6050805@algroup.co.uk> Date: Wed, 21 Sep 2005 13:28:27 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" CC: ietf-openpgp@imc.org Subject: Re: Problems with v4 key packet format References: <20050920053207.GA5245@epointsystem.org> In-Reply-To: <20050920053207.GA5245@epointsystem.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > In order to design a successor to v4 key packet format, it is important to > first identify its shortcomings. Here's a list of my problems with it: > > 1. No cryptographic binding between the encrypted private key material and > the public key material. > > This results in a serious security issue, by allowing an attacker to replace > the public material thus compromising the private material with the first > use in the signature. There are various stop-gap measures to deal with this > attack, but the only sure protetction would be some MDC binding together the > private and the public key material. I don't understand this attack. > 2. No explicit count of MPIs constituting the key material (both public and > private). > > This information can only be inferred from the algorithm specifier, meaning > that any implementation that wants to perform key management must have some > rudimentary knowledge about all public key algorithms. This, in turn, > hampers forward-compatibility. This appears to me to be incorrect - an implementation that didn't know the algorithm could still deduce the number of MPIs by parsing the packet until it is exhausted. This would mean introducing a requirement that all public key parameters were MPIs, of course. > 3. Key fingerprint depends on data unrelated to the actual key (namely: > creation date). > > This prevents solutions when signature keys are generated on the fly (e.g. > directly from a passphrase), as the key creation (or, in this case, key > registration) date is not available at the time of signing, thus making it > impossible to put am unambiguous reference to the public key into the > signature. Not impossible, but I'll agree, crufty. One could use a fixed creation date. > 4. More generally, creation time does not belong to the key packet. > > Because it is just an attribute of the key as any other, thus belonging to > certificatiton signature sub-packets, rather than the key packet. So? Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCOLnq078598; Wed, 21 Sep 2005 05:24:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LCOL0c078597; Wed, 21 Sep 2005 05:24:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LCOKRp078587 for ; Wed, 21 Sep 2005 05:24:20 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 579B233C1A; Wed, 21 Sep 2005 13:24:19 +0100 (BST) Message-ID: <433150F4.1000307@algroup.co.uk> Date: Wed, 21 Sep 2005 13:24:20 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hal Finney CC: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050920014429.2762157EF5@finney.org> In-Reply-To: <20050920014429.2762157EF5@finney.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal Finney wrote: > In contrast, finding "strong" primes p such that (p-1)/2 is also prime > does tend to be slow. I think there is a trick to do it using a double > sieve but it is still much slower than finding regular primes. There is - Geoff Thorpe and I planned to implement it for OpenSSL, but never got around to it. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LB0IvA070743; Wed, 21 Sep 2005 04:00:18 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LB0I0k070742; Wed, 21 Sep 2005 04:00:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LB0H1i070736 for ; Wed, 21 Sep 2005 04:00:17 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 631D85AA12; Wed, 21 Sep 2005 12:00:16 +0100 (BST) Message-ID: <43313D64.8070501@systemics.com> Date: Wed, 21 Sep 2005 12:00:52 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Cc: Jon Callas Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> In-Reply-To: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas wrote: > > I think it would be good for us to have some sort of interoperability > test and event. Putting on my PGP Corporation hat, I'm happy to sponsor > it. However, it doesn't *have* to be a physical event. Physics is fun, but net chemistry also works. I've had some degree of success in testing cross-platform code using a "webservice" approach. Basically, build a server that offers a number of actions over HTTP **. The basic action is an echo service that forms part of a read/write cycle to prove serialisation. It works roughly this way: 1. Create a garbage packet. 2. Serialise it into its network form. 3. Send it off to the other implementation over some sort of server protocol. 4. The echo server sits there and waits for packets: a. read a packet in, b. parse it, objectise it, c. write it out again in network form, d. return it as the response to the request. 5. The original sender reads back the response, recovers it and then compares it internally with the original packet it sent. This means that there needs to be two routines added to every packet: create a garbage packet, and compare two packets for equality. Once that basic architecture is defined, many variants are possible.... > Does anyone else > think it would be a good idea? Does anyone want to help put it on, come > up with test cases, that sort of thing? It's definately a good idea. The main thing above would be to define a list of the minimal packets that should be echoed: public key packet with basic feature set and only the MUST algorithms encrypted message, signed message, cleartext and binary encrypted + signed binary Start with the absolute minimum. (Obviously encrypted and signed messages will involve some state ....) iang PS: To add in another buzzword, I'd do it in REST format, which basically means do it as a simulated web server, and have the client and server deal with HTTP POST requests with some form of application binary data. This avoids most of the complications of defining ones own transport protocol, avoids having to talk to the firewall people, and for most languages means you don't have to run a server at all, just slot it in as a CGI into Apache. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LAw0f9070620; Wed, 21 Sep 2005 03:58:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8LAw0g2070619; Wed, 21 Sep 2005 03:58:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8LAvw7o070610 for ; Wed, 21 Sep 2005 03:57:59 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 615DE5AA0A; Wed, 21 Sep 2005 11:57:57 +0100 (BST) Message-ID: <43313CD8.6000303@systemics.com> Date: Wed, 21 Sep 2005 11:58:32 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Cc: "Daniel A. Nagy" Subject: [v5] Re: Problems with v4 key packet format References: <20050920053207.GA5245@epointsystem.org> In-Reply-To: <20050920053207.GA5245@epointsystem.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > In order to design a successor to v4 key packet format, it is important to > first identify its shortcomings. Here's a list of my problems with it: Perhaps a pass at listing the problems in v4 ** would be a fair first phase. Here's a couple of issues (although I admit to not bit-peeping as much as I should, most of these are user/mgr level grumbles): 5. Too many integers and formats and what have you. There should be a base level of formats which should cover all requirements, and these should be flexible enough to do that job, while simple and short enough to be easily implementable and understandable. 6. PGP's feedback mode. There's no point to this. It's a thing that PRZ added in because he thought it was cool; he was wrong on that point && and it would make matters easier if the standard CBC modes that are described in all the textbooks were used. 7. Cipher suites, not algorithms. Although I like OpenPGP's tradition of opening up to experiments in algorithms and so forth, I think it is a pain for interoperability and implementation. It might be fine to demand the "right" to implement odd-length RSA with Ripem-666 hashes and the latest chinese cipher feedback modes over GOST encryption, but this is just plain stupidity at the software engineering level. As much as possible, I'd suggest that a cipher suites approach be used: Cipher suite #1 should fix the PK, the encryption algorithm, the hash, the feedback modes, and all that. When something breaks, deprecate the whole sodding lot, and move on to #2. Life was really good in the days up to pgp2.6. Then it all went to pot. We may never go back to those simple times, but we can attempt to simulate it by using cipher suites $$. (some of these points are contradictory at some level :-) iang PS **: if we are going to start discussing futures like v5, it might be easier to stick something in the subject so people know quickly that it does not effect the current doc. PS &&: This is not a criticism of him; nobody ever builds a perfect cryptosystem, and it falls to later disciples to carefully clean out the mistakes. PS $$: Allowing experimental cipher suites would be fine. Another trap to avoid is the SSL cipher suite rabbit explosion ... but that should be easy to do if we allow people to experiment with their own and only promote the really useful, strong ones. I.e., rejection of marginal improvements as a routine. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L9iTJQ064154; Wed, 21 Sep 2005 02:44:29 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8L9iTDW064153; Wed, 21 Sep 2005 02:44:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L9iRQF064146 for ; Wed, 21 Sep 2005 02:44:28 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 5A87A2B47E3; Wed, 21 Sep 2005 11:44:26 +0200 (CEST) Date: Wed, 21 Sep 2005 11:44:26 +0200 To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-ID: <20050921094426.GA26811@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> <20050920160452.GB16991@epointsystem.org> <20050920171247.GD14884@jabberwocky.com> <20050920235332.GB28452@epointsystem.org> <20050921011053.GA15822@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050921011053.GA15822@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 09:10:53PM -0400, David Shaw wrote: > I'm all for getting these problems fixed, but we stand a better chance > of doing by working the actual problem. By all means, add some > clarifying text to the text for the issuer key ID subpacket, but > understand that won't change the keyserver situation. It's just two > different problems. Oh, there seems to be a misunderstanding between us, for which I should probably apologize. I never for a moment suggested that SKS's bad behavior was the result of the wording in RFC2440, though reading back, it might have indeed come across like I did. I simply listed interoperability problems that I have encountered that in my opinion resulted from not anticipating less obvious, yet perfectly RFC-compliant behavior. In this particular case, I have noted a minor possible ambiguity in the standard text, which, I repeat, should be obvious for anyone giving it a little thought. As an implementer myself, I have resorted to the same workarounds: canonizing public key packets before uploading to keyserver and using short key IDs. Also, I totally agree with you that clarification in the standard is not the way to fix this problem, but listing it as a known interoperability issue in the mailing list archive or even on some webpage dedicated to interoperability between OpenPGP applications (is that what Jon aims to do?) might help in two ways: culprits may eventually fix their bugs, and meanwhile others might avoid running into them. For example, if such a list existed when I coded the relevant parts of ePointPGP, it would have saved me a lot of time. I think, Jon's idea of an interop grill-off is an excellent opportunity for assembling such a list of known interoperability issues, before venturing into testing unknown, suspected ones. That said, SKS is by far the most standards-compliant HKP-compatible keyserver that I have seen. Others do horrible things to keys and search results. Since keyservers are (correctly) considered outside of security perimeters and should be treated as untrustworthy in any case, they tend to be the least carefully written and maintained applications in the OpenPGP world. That's just a fact of life, I guess, that we need to cope with. And again, apologies in case I have unintentionally offended someone. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L1BBQw018181; Tue, 20 Sep 2005 18:11:11 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8L1BBAQ018180; Tue, 20 Sep 2005 18:11:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [204.127.198.43]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8L1B4g0018135 for ; Tue, 20 Sep 2005 18:11:07 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc12) with ESMTP id <20050921011056014000qpm9e>; Wed, 21 Sep 2005 01:10:56 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8L1Av0m017334 for ; Tue, 20 Sep 2005 21:10:57 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8L1AriR015973 for ; Tue, 20 Sep 2005 21:10:53 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8L1Ar0P015972 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 21:10:53 -0400 Date: Tue, 20 Sep 2005 21:10:53 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-ID: <20050921011053.GA15822@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> <20050920160452.GB16991@epointsystem.org> <20050920171247.GD14884@jabberwocky.com> <20050920235332.GB28452@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920235332.GB28452@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 21, 2005 at 01:53:39AM +0200, Daniel A. Nagy wrote: > > Doing otherwise would be an absurd thing to do - the signing > > equivalent of putting the main key ID into a PKESK packet when > > encrypting to a subkey. If you can point to a single implementation > > that does this wrong, I'll immediately concede the point. > > Of course, I can't. This is why I am saying that SKS has an important > interoperability problem. It EXPECTS the wrong behavior, while nobody > actually does it. While it is true that SKS doesn't do long keyid searches for subkeys, and I agree this is suboptimal behavior, understand that this is not connected to what clients put in the issuer key ID subpacket. There has never been a client that put anything other than the signing key ID in the subpacket, and the SKS behavior is not based on some misreading of that point in the draft. Even if SKS started supporting long subkey ID searches tomorrow, it would not resolve this problem, as GnuPG doesn't provide long key IDs when speaking to any HKP-ish keyserver because there are still old PKS servers out that that just won't die. I believe PGP does the same thing. If you want long key ID searches, you need to use LDAP. Note that even those PKS servers that don't blow up completely on long key ID searches don't really do them either: they just pretend to, and ignore the upper 32 bits - try searching for 0x99242560 and 0x1111111199242560. PKS doesn't do subkey searches at all. I'm all for getting these problems fixed, but we stand a better chance of doing by working the actual problem. By all means, add some clarifying text to the text for the issuer key ID subpacket, but understand that won't change the keyserver situation. It's just two different problems. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KNrgfM012580; Tue, 20 Sep 2005 16:53:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KNrgM3012579; Tue, 20 Sep 2005 16:53:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KNrfJG012572 for ; Tue, 20 Sep 2005 16:53:41 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 7791C2B4794; Wed, 21 Sep 2005 01:53:39 +0200 (CEST) Date: Wed, 21 Sep 2005 01:53:39 +0200 To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-ID: <20050920235332.GB28452@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> <20050920160452.GB16991@epointsystem.org> <20050920171247.GD14884@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920171247.GD14884@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 01:12:47PM -0400, David Shaw wrote: > > No, it isn't. This becomes a major interoperability issue, when you use > > signature subkeys. It's not quite clear from RFC2440 wether the 8-byte > > signatory field sould point to the main key or the subkey, but in several > > implementations it points to the subkey, which actually made the signature > > (and this is the right behavior, IMHO). > > I don't know of *any* implementations that set the issuer subpacket to > anything other than the key that made the signature, as specified in > the RFC. You mean the actual subkey, right? Where is it specified in the RFC? The formulation "the key that made the signature" is a bit ambiguous, IMHO, but, of course, the sensible thing to do is obvious. > Doing otherwise would be an absurd thing to do - the signing > equivalent of putting the main key ID into a PKESK packet when > encrypting to a subkey. If you can point to a single implementation > that does this wrong, I'll immediately concede the point. Of course, I can't. This is why I am saying that SKS has an important interoperability problem. It EXPECTS the wrong behavior, while nobody actually does it. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KNlVIg012102; Tue, 20 Sep 2005 16:47:31 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KNlVB8012101; Tue, 20 Sep 2005 16:47:31 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KNlTV5012095 for ; Tue, 20 Sep 2005 16:47:30 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id CDED12B4794; Wed, 21 Sep 2005 01:47:28 +0200 (CEST) Date: Wed, 21 Sep 2005 01:47:28 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050920234728.GA28452@epointsystem.org> References: <20050920180219.74FE257EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920180219.74FE257EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 11:02:19AM -0700, "Hal Finney" wrote: > I'm not sure how other systems that implement DSS handle the issue of > validating public parameter certificates. It could be that OpenPGP is > the main user of DSA/DSS and nobody else worries about it. I know I've > seen X.509 certificate specs for DSS keys and they don't have the extra > information necessary (although strangely, X.509 Diffie-Hellman keys do > have it!). I guess they just assume that checks for legal DSS public > parameters are outside the scope of their spec. I know about one other major implementation of DSS, which is java.security by Sun Microsystems. Their key generation method uses pre-calculated moduli for the common key sizes, but one can turn that feature off and have the key generated from scratch (which takes a lot longer, of course). The certificates of the pre-calculated moduli are in a comment of the source code, which you may obtain from Sun upon request (they are very forthcoming about that, becasue they understand that openness is the basis of trust in crypto matters). -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI8Wxp081482; Tue, 20 Sep 2005 11:08:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KI8Veb081480; Tue, 20 Sep 2005 11:08:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI8VP7081473 for ; Tue, 20 Sep 2005 11:08:31 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc14) with ESMTP id <2005092018082601400ohnkge>; Tue, 20 Sep 2005 18:08:26 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8KI8Q0m016079 for ; Tue, 20 Sep 2005 14:08:26 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8KI8NoD015312 for ; Tue, 20 Sep 2005 14:08:23 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8KI8Npr015311 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 14:08:23 -0400 Date: Tue, 20 Sep 2005 14:08:23 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Information and meta-information Message-ID: <20050920180823.GB15299@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050831152646.GB31148@epointsystem.org> <8BADBD06-012A-44B0-A9A7-6BDAE8ED8E37@hhhh.org> <20050907233120.GA31910@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050907233120.GA31910@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Sep 08, 2005 at 01:31:25AM +0200, Daniel A. Nagy wrote: > > On Wed, Sep 07, 2005 at 03:56:58PM -0700, Wim Lewis wrote: > > > The existing 'b', 't', etc. tags could then be defined as shorthands > > for particular MIME headers (content-type and charset). > > I disagree, because these tags convey a slightly different (lower-level) > meaning than the mime headers. Also, the above suggestion would be a > security hazard, since the literal packet's tag is not hashed and can be > therefore altered in a signed message, without breaking the signature. > PGP/MIME headers, on the other hand, are included in the hashed material, so > they are part of the signed message. > > > >I would suggest the following modification of RFC2440bis-14: > > > > Do you mean removing the 't' and 'u' tags? Or supplementing them with > > 'm'? > > Supplementing with 'm', of course. Removing 't' and 'b' tags (what's 'u'?) > would break almost everything. 't' = unspecified charset 'u' = utf-8 charset David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI6xE9081386; Tue, 20 Sep 2005 11:06:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KI6xpD081385; Tue, 20 Sep 2005 11:06:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [216.148.227.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI6wVk081375 for ; Tue, 20 Sep 2005 11:06:59 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <200509201806530150043lfde>; Tue, 20 Sep 2005 18:06:53 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8KI6r0m016062 for ; Tue, 20 Sep 2005 14:06:53 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8KI6pCt015306 for ; Tue, 20 Sep 2005 14:06:51 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8KI6p7F015305 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 14:06:51 -0400 Date: Tue, 20 Sep 2005 14:06:51 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-ID: <20050920180651.GA15299@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050920173337.96E1A57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920173337.96E1A57EF5@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 10:33:37AM -0700, "Hal Finney" wrote: > Perhaps we should clarify the language in the RFC to eliminate any > such ambiguity. 5.2.3.5, the Issuer subpacket, just says: > > The OpenPGP key ID of the key issuing the signature. > > We could add "If the signature is issued by a subkey then the key ID of > this subkey is used here instead of the key ID of the primary key." > > We do have similar language in 5.2 for PKESKs: > > - An eight-octet number that gives the key ID of the public key > that the session key is encrypted to. If the session key is > encrypted to a subkey then the key ID of this subkey is used > here instead of the key ID of the primary key. I think that is reasonable, but it would need to be mentioned in several places (in bis-14): 5.2.2 (V3 signatures), 5.2.3.5 (issuer subpacket), and 5.4 (Onepass signature packet). Perhaps something could be said in 3.3 (Key IDs) that covers them all? David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI2Wnw081103; Tue, 20 Sep 2005 11:02:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KI2W2g081102; Tue, 20 Sep 2005 11:02:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KI2VeJ081095 for ; Tue, 20 Sep 2005 11:02:31 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 74FE257EF5; Tue, 20 Sep 2005 11:02:19 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-Id: <20050920180219.74FE257EF5@finney.org> Date: Tue, 20 Sep 2005 11:02:19 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There are a few differences between the OpenPGP requirements for DSA keys and those in the DSS spec. Usually, OpenPGP implementations do not use pre-calculated moduli for DSA keys. Likewise, OpenPGP does not require that DSA keys be generated by the method described in the DSS standard. This is the reason why we generally call them DSA keys and not DSS keys in the spec. Nevertheless we do follow the FIPS-186 recommendations for modulus sizes, as their advice is good. There are a few issues here. Pre-calculated moduli do have some advantages. Generating the modulus is the slow part of DSA keygen. With a pre-calculated modulus, all that is necessary to generate a key is to pick a random value x and do one exponentiation to generate y = g^x mod p. This can also save space in key distribution; if there is a widely shared modulus then only the y value has to be distributed for each key. There are a few disadvantages though. There are theoretical attacks where the body that generates the pre-calculated modulus can use "trapdoor" primes which allow faster calculation of discrete log. Anyone who generated a key using that shared modulus would be at risk of having his private key broken by the body which created that modulus. In order to protect users against this possibility, DSS specifies that the public parameters (p, q, g) be generated using a randomization technique which essentially eliminates the possibility of a trapdoor. But it also requires that a sort of "certificate" of the parameter generation be created and distributed, and that end users verify that certificate to make sure that the public parameters have no trapdoors. This is pretty complicated, and furthermore the general paranoia among much of OpenPGP's audience is likely to make them mistrust even shared parameters that are accompanied by such certificates. As a result OpenPGP has not pursued this approach. There are no OpenPGP data structures to share DSS public parameter certificates and nothing in the spec about creating DSS keys in the standard way, or sharing and verifying such certificates. So OpenPGP generally envisions DSA keys being generated with fresh public parameters for each key. Not only is this more secure and simpler, but it allows for the fast generation method I described in my mail yesterday, which uses sieving. Generating DSS moduli per FIPS-186 is relatively slow, and extending that method to larger prime sizes may become prohibitively slow. (Of course, if the FIPS-186 method is used with shared moduli, then keygen becomes very faster as I noted above, just a single exponentiation to calculate y.) I'm not sure how other systems that implement DSS handle the issue of validating public parameter certificates. It could be that OpenPGP is the main user of DSA/DSS and nobody else worries about it. I know I've seen X.509 certificate specs for DSS keys and they don't have the extra information necessary (although strangely, X.509 Diffie-Hellman keys do have it!). I guess they just assume that checks for legal DSS public parameters are outside the scope of their spec. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHdpGC078424; Tue, 20 Sep 2005 10:39:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KHdpJ7078423; Tue, 20 Sep 2005 10:39:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHdpMo078417 for ; Tue, 20 Sep 2005 10:39:51 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 33F0957EF5; Tue, 20 Sep 2005 10:39:39 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Line spacing in normative references Message-Id: <20050920173939.33F0957EF5@finney.org> Date: Tue, 20 Sep 2005 10:39:39 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: A minor point, I notice that the spacing is inconsistent in the normative references. Some are separated by blank lines and some are not. It would look nicer to be consistent here. I don't know if some macro is misfiring or if we could clean it up and make it look better. Hal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHXpgC077944; Tue, 20 Sep 2005 10:33:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KHXpt8077943; Tue, 20 Sep 2005 10:33:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHXog8077935 for ; Tue, 20 Sep 2005 10:33:50 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 96E1A57EF5; Tue, 20 Sep 2005 10:33:37 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Interop grill-off Message-Id: <20050920173337.96E1A57EF5@finney.org> Date: Tue, 20 Sep 2005 10:33:37 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > I don't know of *any* implementations that set the issuer subpacket to > anything other than the key that made the signature, as specified in > the RFC. Doing otherwise would be an absurd thing to do - the signing > equivalent of putting the main key ID into a PKESK packet when > encrypting to a subkey. If you can point to a single implementation > that does this wrong, I'll immediately concede the point. Perhaps we should clarify the language in the RFC to eliminate any such ambiguity. 5.2.3.5, the Issuer subpacket, just says: The OpenPGP key ID of the key issuing the signature. We could add "If the signature is issued by a subkey then the key ID of this subkey is used here instead of the key ID of the primary key." We do have similar language in 5.2 for PKESKs: - An eight-octet number that gives the key ID of the public key that the session key is encrypted to. If the session key is encrypted to a subkey then the key ID of this subkey is used here instead of the key ID of the primary key. This would make sure there is no ambiguity about which key ID to use. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHUu4T077688; Tue, 20 Sep 2005 10:30:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KHUuxq077687; Tue, 20 Sep 2005 10:30:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHUtH5077681 for ; Tue, 20 Sep 2005 10:30:55 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.219] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2289733C1B; Tue, 20 Sep 2005 18:30:54 +0100 (BST) Message-ID: <4330474D.6050800@algroup.co.uk> Date: Tue, 20 Sep 2005 18:30:53 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Daniel A. Nagy" CC: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050918001303.96B4F57EF5@finney.org> <20050918123430.GB6483@epointsystem.org> In-Reply-To: <20050918123430.GB6483@epointsystem.org> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel A. Nagy wrote: > It's important to keep in mind that DSS-style signatures are twice the hash > size. This is one of their nicest features; they do not grow with the > modulus. A signature of a 3072/256 key will be 512 bits (plus overhead). > > As for generating long modulae, it's not that big a problem, altough it has > to be noted that generating a modulus for DSA takes more than just > generating a prime that big; DSA moduli p are such that p-1 is divisible by > some large (hash-sized) q. The generation of such moduli takes substantially > longer than generating primes. For 3072/256 on a 500MHz intel, it would take > approx. three minutes, provided that the random stream is available without > waiting. > > On the other hand, the overwhelming majority of DSS implementations use > pre-calculated moduli, as there are no security hazards associated with > using a common modulus for DSS. When keys need to be generated frequently, > a pre-calculated modulus is the way to go. If one just needs to generate a > personal signature key for the next five years, one can wait three minutes, > in case they want to show off a self-generated modulus. Good point. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHCt60075515; Tue, 20 Sep 2005 10:12:55 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KHCtUa075514; Tue, 20 Sep 2005 10:12:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KHCtA9075504 for ; Tue, 20 Sep 2005 10:12:55 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <200509201712490150044buue>; Tue, 20 Sep 2005 17:12:49 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8KHCn0m015844 for ; Tue, 20 Sep 2005 13:12:49 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8KHClQH015190 for ; Tue, 20 Sep 2005 13:12:47 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8KHCl3c015189 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 13:12:47 -0400 Date: Tue, 20 Sep 2005 13:12:47 -0400 From: David Shaw To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920171247.GD14884@jabberwocky.com> Mail-Followup-To: OpenPGP References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> <20050920160452.GB16991@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920160452.GB16991@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 06:04:57PM +0200, Daniel A. Nagy wrote: > > On Tue, Sep 20, 2005 at 11:17:05AM -0400, David Shaw wrote: > > > > 3. Some keyservers do not return matching keys, if searched by the long > > > (16 byte) key ID of a subkey. SKS is guilty of this. > > > > Isn't this a just SKS feature request? Nothing in the draft says > > anything about how keyservers work, or even that a UI must allow > > particular ways to search. > > No, it isn't. This becomes a major interoperability issue, when you use > signature subkeys. It's not quite clear from RFC2440 wether the 8-byte > signatory field sould point to the main key or the subkey, but in several > implementations it points to the subkey, which actually made the signature > (and this is the right behavior, IMHO). I don't know of *any* implementations that set the issuer subpacket to anything other than the key that made the signature, as specified in the RFC. Doing otherwise would be an absurd thing to do - the signing equivalent of putting the main key ID into a PKESK packet when encrypting to a subkey. If you can point to a single implementation that does this wrong, I'll immediately concede the point. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KGGYwN068600; Tue, 20 Sep 2005 09:16:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KGGYr9068599; Tue, 20 Sep 2005 09:16:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KGGXkc068590 for ; Tue, 20 Sep 2005 09:16:33 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHkta-00029z-Kd for ; Tue, 20 Sep 2005 18:23:02 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHklM-0001lA-On; Tue, 20 Sep 2005 18:14:32 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> <20050920084757.GB24261@epointsystem.org> <87mzm8xem8.fsf@wheatstone.g10code.de> <20050920155001.GA16991@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 18:14:32 +0200 In-Reply-To: <20050920155001.GA16991@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 17:50:02 +0200") Message-ID: <87vf0vra1j.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 17:50:02 +0200, Daniel A Nagy said: >> > more than one ESK? Does it try all of them with all the private keys, or >> >> --try-all-secrets applies only to PKESK to assume wildcard key IDs. > Right, but what if there are more of these (multiple recipients)? Yes, it tries all of them with all available secret keys. Salam-Shalom, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KG54GR067845; Tue, 20 Sep 2005 09:05:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KG54PW067844; Tue, 20 Sep 2005 09:05:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KG53rr067837 for ; Tue, 20 Sep 2005 09:05:04 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8AC422B480E; Tue, 20 Sep 2005 18:04:57 +0200 (CEST) Date: Tue, 20 Sep 2005 18:04:57 +0200 To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920160452.GB16991@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <20050920151705.GA14884@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920151705.GA14884@jabberwocky.com> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 11:17:05AM -0400, David Shaw wrote: > > 3. Some keyservers do not return matching keys, if searched by the long > > (16 byte) key ID of a subkey. SKS is guilty of this. > > Isn't this a just SKS feature request? Nothing in the draft says > anything about how keyservers work, or even that a UI must allow > particular ways to search. No, it isn't. This becomes a major interoperability issue, when you use signature subkeys. It's not quite clear from RFC2440 wether the 8-byte signatory field sould point to the main key or the subkey, but in several implementations it points to the subkey, which actually made the signature (and this is the right behavior, IMHO). In this case, databases of keys, be it local keyrings or remote keyservers MUST be indexed by subkey IDs as well, otherwise such signatures cannot be verified. For example, this SKS deficienci breaks interoperability (namely yautotmatic key retrieval) with GnuPG (and very possibly PGP), if signature subkeys are used. Signature subkeys have many uses, and although they are less popular than encryption subkeys (because of the default settings of pgp and gpg) their use is an important security measure allowing for changing the regularly used signing key without losing all certificatitons on the main key. They are also useful if the same user wishes to make signatures from different computers without risking too much. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFo4EY066371; Tue, 20 Sep 2005 08:50:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KFo4YO066370; Tue, 20 Sep 2005 08:50:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFo3Aj066361 for ; Tue, 20 Sep 2005 08:50:03 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 6A7A52B47EA; Tue, 20 Sep 2005 17:50:02 +0200 (CEST) Date: Tue, 20 Sep 2005 17:50:02 +0200 To: Werner Koch , OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920155001.GA16991@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> <20050920084757.GB24261@epointsystem.org> <87mzm8xem8.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87mzm8xem8.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 11:39:11AM +0200, Werner Koch wrote: > On Tue, 20 Sep 2005 10:47:57 +0200, Daniel A Nagy said: > > > By the way, what does gpg do given the --try-all-secrets option, if there's > > more than one ESK? Does it try all of them with all the private keys, or > > --try-all-secrets applies only to PKESK to assume wildcard key IDs. Right, but what if there are more of these (multiple recipients)? -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFHD6d062083; Tue, 20 Sep 2005 08:17:13 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KFHDDS062082; Tue, 20 Sep 2005 08:17:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [216.148.227.118]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KFHDp1062060 for ; Tue, 20 Sep 2005 08:17:13 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (rwcrmhc13) with ESMTP id <2005092015170701500459u4e>; Tue, 20 Sep 2005 15:17:07 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8KFH60m015463 for ; Tue, 20 Sep 2005 11:17:06 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8KFH5sU015061 for ; Tue, 20 Sep 2005 11:17:05 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8KFH5dP015060 for ietf-openpgp@imc.org; Tue, 20 Sep 2005 11:17:05 -0400 Date: Tue, 20 Sep 2005 11:17:05 -0400 From: David Shaw To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920151705.GA14884@jabberwocky.com> Mail-Followup-To: OpenPGP References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920065346.GA21364@epointsystem.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 08:53:46AM +0200, Daniel A. Nagy wrote: > 2. Some keyservers omit canonization before hashing the key packet. If the > key packet is shorter than 256 bytes (typically the case for 1024-bit RSA > keys) and uses the shortest possible packet header with a one-byte length, > the fingerprint and the key IDs are mis-calculated. PKS is guilty of this. This is a good one. I've seen this mistake made more than once, and not just in PKS. Incidentally, that bug in PKS was fixed quite a while ago. PKS had many problems, including miscalculating v4 RSA fingerprints, mangling keys with more than one subkey, discarding attribute ID packets, etc. Most of the worst have been fixed, but the point may be moot as so far as I know, PKS is not being developed any longer. > 3. Some keyservers do not return matching keys, if searched by the long > (16 byte) key ID of a subkey. SKS is guilty of this. Isn't this a just SKS feature request? Nothing in the draft says anything about how keyservers work, or even that a UI must allow particular ways to search. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KETTod055721; Tue, 20 Sep 2005 07:29:29 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8KETTcc055720; Tue, 20 Sep 2005 07:29:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8KETSsM055712 for ; Tue, 20 Sep 2005 07:29:28 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 00EB15A79D; Tue, 20 Sep 2005 15:29:26 +0100 (BST) Message-ID: <43301CEC.2070500@systemics.com> Date: Tue, 20 Sep 2005 15:30:04 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Werner Koch Cc: Ben Laurie , Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> <432D4F13.6080703@algroup.co.uk> <432D712D.4060502@systemics.com> <871x3l790m.fsf@wheatstone.g10code.de> In-Reply-To: <871x3l790m.fsf@wheatstone.g10code.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch wrote: > DSA 100 times sign verify > ----------------------------- > DSA 1024/160 910ms 430ms > DSA 2048/224 1560ms 1890ms > DSA 3072/256 3610ms 4380ms > > (The numbers for sign are not very reliable because it employs the > RNG and I could not adjust for it) > > 3072 takes more more than double the time of 2048 which is not too > bad. Compared to 1024 this is a real slowdown and would make key > signature verification a very time consuming operation. On slow > machines (embedded devices, older hardware) this would be very > annoying. Ah, ok, so this last point about slow / small hardware platforms makes sense. So we might be tempted to suggest that implementations SHOULD verify any of the three lengths, and let them choose which length to deliver for signing beyond the MUST of 1024/160. (Which is after all a minor side discussion in Hal's thread of whether to wait or not.) iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9fX1N026576; Tue, 20 Sep 2005 02:41:33 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K9fXZx026575; Tue, 20 Sep 2005 02:41:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9fWqP026564 for ; Tue, 20 Sep 2005 02:41:32 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHejJ-0000Cl-OM for ; Tue, 20 Sep 2005 11:48:01 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHeal-0001JM-4Y; Tue, 20 Sep 2005 11:39:11 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> <20050920084757.GB24261@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 11:39:11 +0200 In-Reply-To: <20050920084757.GB24261@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 10:47:57 +0200") Message-ID: <87mzm8xem8.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 10:47:57 +0200, Daniel A Nagy said: > By the way, what does gpg do given the --try-all-secrets option, if there's > more than one ESK? Does it try all of them with all the private keys, or --try-all-secrets applies only to PKESK to assume wildcard key IDs. Shalom-Salam, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9aYSX025852; Tue, 20 Sep 2005 02:36:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K9aYwN025851; Tue, 20 Sep 2005 02:36:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9aXss025843 for ; Tue, 20 Sep 2005 02:36:33 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHeeV-0000Bs-0x for ; Tue, 20 Sep 2005 11:43:03 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHeW0-0001In-J1; Tue, 20 Sep 2005 11:34:16 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Bigger DSA keys References: <20050920014429.2762157EF5@finney.org> <20050920083438.GA2105@bitchcake.off.net> <20050920085432.GC24261@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 11:34:16 +0200 In-Reply-To: <20050920085432.GC24261@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 10:54:32 +0200") Message-ID: <87r7bkxeuf.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 10:54:32 +0200, Daniel A Nagy said: > DSS explicitly specifies how to generate primes for DSA keys. It can be > easily generalized for larger keys and other hash functions, and its > reasonable to assume that the new DSS will do that. FWIW, the Lim & Lee algorithm is newer than DSS. It was published in Crypto 97 whereas FIPS 186 was published in 1994. Salam-Shalom, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9BY9p023014; Tue, 20 Sep 2005 02:11:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K9BYYA023013; Tue, 20 Sep 2005 02:11:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K9BXOQ022998 for ; Tue, 20 Sep 2005 02:11:33 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHeGI-0008SP-T1 for ; Tue, 20 Sep 2005 11:18:02 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHe5l-0001GH-KY; Tue, 20 Sep 2005 11:07:09 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> <20050920083955.GA24261@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 11:07:09 +0200 In-Reply-To: <20050920083955.GA24261@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 10:39:56 +0200") Message-ID: <87aci8151e.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 10:39:56 +0200, Daniel A Nagy said: > I would suggest a completely different approach: try extracting a key from > each ESK (be it password-derived, password-encrypted or > asymmetcially encrypted), and use the one which inspires most confidence: Makes sense. We have not seen many pubkey/symkey encrypted messages in the wild thus the way we handle them is straightforward. Need to look at it closer. Thanks, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8sYFe021341; Tue, 20 Sep 2005 01:54:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8sYJx021340; Tue, 20 Sep 2005 01:54:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8sX5j021333 for ; Tue, 20 Sep 2005 01:54:33 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 85CF82B47E4; Tue, 20 Sep 2005 10:54:32 +0200 (CEST) Date: Tue, 20 Sep 2005 10:54:32 +0200 To: OpenPGP Subject: Re: Bigger DSA keys Message-ID: <20050920085432.GC24261@epointsystem.org> References: <20050920014429.2762157EF5@finney.org> <20050920083438.GA2105@bitchcake.off.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920083438.GA2105@bitchcake.off.net> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 04:34:38AM -0400, Adam Back wrote: > Could one not use the Lim Lee safe prime generation method for DSA? > > It has significant speed advantages. > > Adam DSS explicitly specifies how to generate primes for DSA keys. It can be easily generalized for larger keys and other hash functions, and its reasonable to assume that the new DSS will do that. My estimates were based on that specification. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8lxXC020408; Tue, 20 Sep 2005 01:47:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8lx6X020407; Tue, 20 Sep 2005 01:47:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8lwr4020399 for ; Tue, 20 Sep 2005 01:47:59 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id D1D9D2B47E3; Tue, 20 Sep 2005 10:47:57 +0200 (CEST) Date: Tue, 20 Sep 2005 10:47:57 +0200 To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920084757.GB24261@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r7bk17ub.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 10:06:36AM +0200, Werner Koch wrote: > Due to gpg's streaming based design ... By the way, what does gpg do given the --try-all-secrets option, if there's more than one ESK? Does it try all of them with all the private keys, or just the first one? -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8dw0t019308; Tue, 20 Sep 2005 01:39:58 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8dwh8019307; Tue, 20 Sep 2005 01:39:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8dvF4019300 for ; Tue, 20 Sep 2005 01:39:57 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 4D1242B4794; Tue, 20 Sep 2005 10:39:56 +0200 (CEST) Date: Tue, 20 Sep 2005 10:39:56 +0200 To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920083955.GA24261@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> <87r7bk17ub.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r7bk17ub.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Sep 20, 2005 at 10:06:36AM +0200, Werner Koch wrote: > On Tue, 20 Sep 2005 08:53:46 +0200, Daniel A Nagy said: > > > 4. Some implementations give up before trying all possible ways of > > decrypting a message. For example, GnuPG gives up if it encounters a > > passphrase-derived symmetric key specifier and the entered passphrase is > > wrong, even if it is followed by an asymmetrically encrypted symmetric key > > for which it does have access to the corresponding private decryption key. > > There are actually two problems: > > There is no way to cancel the input of a passphrase when using the > CLI, so that gpg can continue with other keys. When using the > gpg-agent, this is possible but a bug inhibited this - I just fixed > that one. I never thought of this as a problem, but maybe you're right. > The other problem is that we can't reliable decide whether the > passphrase is correct. The only way to do this is by looking at the > algorithm byte to check whether this gives a valid algorithm. This is > far form being reliable. Due to gpg's streaming based design with only > a very limited look-ahead we can't do a test decryption and roll back > if it does not work out. I would suggest a completely different approach: try extracting a key from each ESK (be it password-derived, password-encrypted or asymmetcially encrypted), and use the one which inspires most confidence: An asymmetrically decrypted key has an approx. 1 in 17 million chance of being incorrect, symmetrically encrypted keys have a roughly 1 in 20 chance of being incorrect, while there's absolutely no indication wheter a passphrase-derived secret key is correct or not. Thus, deriving a decryption key from a passphrase and then merrily proceeding to the decryption of the encrypted content is incorrect. A correct implementation should try to extract a key from each ESK, and in case of success (asymmetric decryption with leading 0 and correct checksum, symmetric encryption with valid algorithm id or any passphrase-derived key) replacing the tentative decryption key, if the new key inspires more confidence than the previous tentative key. Eventually, the last tentative key should be used for decryption. > A way to check early that the decryption worked would be needed to > solve the problem - I am not sure whether this is really needed given > the security implications of such a check. Yes, that's somewhat hazardous, indeed (although only in non-interactive applications). But it's not necessary, as explained above. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8YpAC018753; Tue, 20 Sep 2005 01:34:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8YpXw018750; Tue, 20 Sep 2005 01:34:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.off.net (off.net [66.96.28.3]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8YoAg018743 for ; Tue, 20 Sep 2005 01:34:50 -0700 (PDT) (envelope-from adam@mail.off.net) Received: by mail.off.net (Postfix, from userid 948) id 27EFD7704B2; Tue, 20 Sep 2005 04:34:41 -0400 (EDT) Received: by bitchcake.off.net (hashcash-sendmail, from uid 948); Tue, 20 Sep 2005 04:34:39 -0400 Date: Tue, 20 Sep 2005 04:34:38 -0400 From: Adam Back To: Hal Finney Cc: ietf-openpgp@imc.org, Adam Back Subject: Re: Bigger DSA keys Message-ID: <20050920083438.GA2105@bitchcake.off.net> References: <20050920014429.2762157EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050920014429.2762157EF5@finney.org> User-Agent: Mutt/1.4.1i X-Hashcash: 1:20:050920:hal@finney.org::g1dJ0NQDtfHJjJ2E:jdO X-Hashcash: 1:20:050920:ietf-openpgp@imc.org::4zHziochWPpcMseH:QL+ X-Hashcash: 1:20:050920:adam@cypherspace.org::EvGICYX2COSvdnlE:9nEa Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Could one not use the Lim Lee safe prime generation method for DSA? It has significant speed advantages. Adam On Mon, Sep 19, 2005 at 06:44:29PM -0700, "Hal Finney" wrote: > As far as the issue of generating large DSA keys, a good algorithm to > use is the following. First generate an appropriately sized subgroup > prime q (160, 224, or 256 bits respectively). Then search for a prime > modulus p of the required size (1024, 2048 or 3072 bits) such that p is > one more than a multiple of q. Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8BgJo015860; Tue, 20 Sep 2005 01:11:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K8BgwU015859; Tue, 20 Sep 2005 01:11:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K8BXp2015847 for ; Tue, 20 Sep 2005 01:11:36 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHdKE-00087C-F9 for ; Tue, 20 Sep 2005 10:18:02 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHd9A-0001CI-Ch; Tue, 20 Sep 2005 10:06:36 +0200 To: nagydani@epointsystem.org (Daniel A. Nagy) Cc: OpenPGP Subject: Re: Interop grill-off References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> <20050920065346.GA21364@epointsystem.org> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Tue, 20 Sep 2005 10:06:36 +0200 In-Reply-To: <20050920065346.GA21364@epointsystem.org> (Daniel A. Nagy's message of "Tue, 20 Sep 2005 08:53:46 +0200") Message-ID: <87r7bk17ub.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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, 20 Sep 2005 08:53:46 +0200, Daniel A Nagy said: > 4. Some implementations give up before trying all possible ways of > decrypting a message. For example, GnuPG gives up if it encounters a > passphrase-derived symmetric key specifier and the entered passphrase is > wrong, even if it is followed by an asymmetrically encrypted symmetric key > for which it does have access to the corresponding private decryption key. There are actually two problems: There is no way to cancel the input of a passphrase when using the CLI, so that gpg can continue with other keys. When using the gpg-agent, this is possible but a bug inhibited this - I just fixed that one. The other problem is that we can't reliable decide whether the passphrase is correct. The only way to do this is by looking at the algorithm byte to check whether this gives a valid algorithm. This is far form being reliable. Due to gpg's streaming based design with only a very limited look-ahead we can't do a test decryption and roll back if it does not work out. A way to check early that the decryption worked would be needed to solve the problem - I am not sure whether this is really needed given the security implications of such a check. Salam-Shalom, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K6rmRk006714; Mon, 19 Sep 2005 23:53:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K6rmoK006713; Mon, 19 Sep 2005 23:53:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K6rlx3006704 for ; Mon, 19 Sep 2005 23:53:47 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8F2D02B47EE; Tue, 20 Sep 2005 08:53:46 +0200 (CEST) Date: Tue, 20 Sep 2005 08:53:46 +0200 To: OpenPGP Subject: Re: Interop grill-off Message-ID: <20050920065346.GA21364@epointsystem.org> References: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 19, 2005 at 02:05:19PM -0700, Jon Callas wrote: > I think it would be good for us to have some sort of interoperability > test and event. Putting on my PGP Corporation hat, I'm happy to > sponsor it. However, it doesn't *have* to be a physical event. Does > anyone else think it would be a good idea? Does anyone want to help > put it on, come up with test cases, that sort of thing? How about simply posting test cases with descriptions here, and testing on various OpenPGP implementations, also posting the results to the mailing list. Then you (or someone else) could post a summary here and/or to some webpage. I'm also wondering what are you more after: unusual data conforming to RFC2400 (or RFC2440bis) or slight (but logical) deviations, extensions? I guess, many of us have already identified interoperability problems. Would it make sense to collect them first, before going into testing questionable cases? Here's my list of problematic cases that I have encountered: (offenders: HushMail, PKS, SKS, GnuPG) 1. HushMail's idea of signed and encrypted messages is encrypting a clearsigned message as canonical text, including the message boundary and the armored signature. Other applications usually don't verify the signature, though, of course, it's easy to do "by hand" (by running a second pass). In the other direction, it's worse: HushMail decrypts the properly signed and encrypted message, but keeps silent about the one-pass signature within the encrypted payload; the message is identified as encrypted but not signed. 2. Some keyservers omit canonization before hashing the key packet. If the key packet is shorter than 256 bytes (typically the case for 1024-bit RSA keys) and uses the shortest possible packet header with a one-byte length, the fingerprint and the key IDs are mis-calculated. PKS is guilty of this. 3. Some keyservers do not return matching keys, if searched by the long (16 byte) key ID of a subkey. SKS is guilty of this. 4. Some implementations give up before trying all possible ways of decrypting a message. For example, GnuPG gives up if it encounters a passphrase-derived symmetric key specifier and the entered passphrase is wrong, even if it is followed by an asymmetrically encrypted symmetric key for which it does have access to the corresponding private decryption key. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K5Wcte097177; Mon, 19 Sep 2005 22:32:38 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K5WcRp097176; Mon, 19 Sep 2005 22:32:38 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K5Wbeb097169 for ; Mon, 19 Sep 2005 22:32:38 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 68D102B47DD; Tue, 20 Sep 2005 07:32:31 +0200 (CEST) Date: Tue, 20 Sep 2005 07:32:31 +0200 To: ietf-openpgp@imc.org Subject: Problems with v4 key packet format Message-ID: <20050920053207.GA5245@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In order to design a successor to v4 key packet format, it is important to first identify its shortcomings. Here's a list of my problems with it: 1. No cryptographic binding between the encrypted private key material and the public key material. This results in a serious security issue, by allowing an attacker to replace the public material thus compromising the private material with the first use in the signature. There are various stop-gap measures to deal with this attack, but the only sure protetction would be some MDC binding together the private and the public key material. 2. No explicit count of MPIs constituting the key material (both public and private). This information can only be inferred from the algorithm specifier, meaning that any implementation that wants to perform key management must have some rudimentary knowledge about all public key algorithms. This, in turn, hampers forward-compatibility. 3. Key fingerprint depends on data unrelated to the actual key (namely: creation date). This prevents solutions when signature keys are generated on the fly (e.g. directly from a passphrase), as the key creation (or, in this case, key registration) date is not available at the time of signing, thus making it impossible to put am unambiguous reference to the public key into the signature. 4. More generally, creation time does not belong to the key packet. Because it is just an attribute of the key as any other, thus belonging to certificatiton signature sub-packets, rather than the key packet. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K1ijx0076488; Mon, 19 Sep 2005 18:44:45 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K1ijaY076487; Mon, 19 Sep 2005 18:44:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K1ii71076478 for ; Mon, 19 Sep 2005 18:44:44 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 2762157EF5; Mon, 19 Sep 2005 18:44:29 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-Id: <20050920014429.2762157EF5@finney.org> Date: Mon, 19 Sep 2005 18:44:29 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As far as the issue of generating large DSA keys, a good algorithm to use is the following. First generate an appropriately sized subgroup prime q (160, 224, or 256 bits respectively). Then search for a prime modulus p of the required size (1024, 2048 or 3072 bits) such that p is one more than a multiple of q. The trick is to make that second search fast. Typically a fast prime search is done in two phases: first sieving out multiples of small primes to identify prime candidates, then a slower probabilistic primality test to find a good prime. The key for DSA keys is that sieving can still be used even when looking for primes which are of the form qk+1. Usually when sieving is done, the method already takes into consideration that the prime must be odd. So it already adjusts for the fact that the number is of the form 2k+1. The same basic approach works for primes of the form qk+1 as well. Since q is relatively prime to all of the primes being sieved by, for a prime "j" we will eliminate every jth item. The only question is where is the starting point for eliminating such items in the sieve. This comes down to computing q mod j. Doing this one extra step for each prime j being sieved by, allows the basic sieve concept to still be used. This method allows DSA primes to be found about as quickly as ordinary primes of the same size. The extra time to find the q prime is small, and the sieve can run about as fast. So generating such large primes is not particularly costly or difficult. In contrast, finding "strong" primes p such that (p-1)/2 is also prime does tend to be slow. I think there is a trick to do it using a double sieve but it is still much slower than finding regular primes. DSA primes do not suffer from this deficiency. Hal Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K0UfPI069344; Mon, 19 Sep 2005 17:30:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8K0Uf3W069343; Mon, 19 Sep 2005 17:30:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8K0Uf9R069337 for ; Mon, 19 Sep 2005 17:30:41 -0700 (PDT) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6) for ; Mon, 19 Sep 2005 17:30:40 -0700 Received: from [172.16.1.2] ([72.254.169.116]) by keys.merrymeet.com (PGP Universal service); Mon, 19 Sep 2005 17:30:40 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 19 Sep 2005 17:30:40 -0700 Mime-Version: 1.0 (Apple Message framework v734) Content-Transfer-Encoding: 7bit Message-Id: <1B9BCC4C-4753-43B3-A94C-08E6FC8C706C@callas.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: OpenPGP From: Jon Callas Subject: Interop grill-off Date: Mon, 19 Sep 2005 14:05:19 -0700 X-Mailer: Apple Mail (2.734) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think it would be good for us to have some sort of interoperability test and event. Putting on my PGP Corporation hat, I'm happy to sponsor it. However, it doesn't *have* to be a physical event. Does anyone else think it would be a good idea? Does anyone want to help put it on, come up with test cases, that sort of thing? Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHxx0N037066; Mon, 19 Sep 2005 10:59:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JHxxa5037065; Mon, 19 Sep 2005 10:59:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHxwsm037059 for ; Mon, 19 Sep 2005 10:59:58 -0700 (PDT) (envelope-from jon@callas.org) Received: from keys.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server X 3.2.6); Mon, 19 Sep 2005 10:59:57 -0700 Received: from [10.240.12.188] ([208.54.15.1]) by keys.merrymeet.com (PGP Universal service); Mon, 19 Sep 2005 10:59:57 -0700 X-PGP-Universal: processed; by keys.merrymeet.com on Mon, 19 Sep 2005 10:59:57 -0700 In-Reply-To: <20050916224113.6004C57EF5@finney.org> References: <20050916224113.6004C57EF5@finney.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3253EF24-1377-43A1-A348-9AB7872A5658@callas.org> Cc: ietf-openpgp@imc.org Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: Bigger DSA keys Date: Mon, 19 Sep 2005 10:59:54 -0700 To: Hal Finney X-Mailer: Apple Mail (2.734) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 16 Sep 2005, at 3:41 PM, Hal Finney wrote: > > I have it on good authority that NIST will be announcing larger size > DSS keys soon. According to my source, the date will be by the end > of October. > We've been waiting for this for years. I think it's important enough to warrant a change in last call for. Jon Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHbM59035140; Mon, 19 Sep 2005 10:37:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JHbMTY035139; Mon, 19 Sep 2005 10:37:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHbL0u035131 for ; Mon, 19 Sep 2005 10:37:21 -0700 (PDT) (envelope-from nagydani@epointsystem.org) From: nagydani@epointsystem.org Received: by mail.epointsystem.org (Postfix, from userid 1001) id 3FD952B480E; Mon, 19 Sep 2005 19:37:18 +0200 (CEST) Date: Mon, 19 Sep 2005 19:34:20 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050919173420.GA26064@epointsystem.org> References: <20050916224113.6004C57EF5@finney.org> <20050919130136.GF9545@jabberwocky.com> <8764sx3ylw.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8764sx3ylw.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 19, 2005 at 04:45:31PM +0200, Werner Koch wrote: > > On Mon, 19 Sep 2005 09:01:37 -0400, David Shaw said: > > > So at least from the graceful failure perspective in GnuPG, it doesn't > > really matter much which way we go. I prefer the first option (using > > the current algorithm number) since it seems cleanest in both code and > > However this does also means that another hash algorithm needs to be a > MUST algorithm - unless we limit the MUST support for DSA to 1024 bits > keys. > > The need for another algorithm makes a big difference for emdedded > applications. Ofen the threat model does not require > high budget spook proof algorithms. I fully agree with that. I would limit the MUST support to plain old SHA1 and 1024bit DSA for the time being. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHZL7X035009; Mon, 19 Sep 2005 10:35:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JHZLbQ035008; Mon, 19 Sep 2005 10:35:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JHZJjP035001 for ; Mon, 19 Sep 2005 10:35:20 -0700 (PDT) (envelope-from nagydani@epointsystem.org) From: nagydani@epointsystem.org Received: by mail.epointsystem.org (Postfix, from userid 1001) id 513052B4810; Mon, 19 Sep 2005 19:35:18 +0200 (CEST) Date: Mon, 19 Sep 2005 19:34:20 +0200 To: Werner Koch Subject: Re: Bigger DSA keys Message-ID: <20050919173420.GA26064@epointsystem.org> References: <20050916224113.6004C57EF5@finney.org> <20050919130136.GF9545@jabberwocky.com> <8764sx3ylw.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8764sx3ylw.fsf@wheatstone.g10code.de> User-Agent: Mutt/1.5.6+20040907i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 19, 2005 at 04:45:31PM +0200, Werner Koch wrote: > > On Mon, 19 Sep 2005 09:01:37 -0400, David Shaw said: > > > So at least from the graceful failure perspective in GnuPG, it doesn't > > really matter much which way we go. I prefer the first option (using > > the current algorithm number) since it seems cleanest in both code and > > However this does also means that another hash algorithm needs to be a > MUST algorithm - unless we limit the MUST support for DSA to 1024 bits > keys. > > The need for another algorithm makes a big difference for emdedded > applications. Ofen the threat model does not require > high budget spook proof algorithms. I fully agree with that. I would limit the MUST support to plain old SHA1 and 1024bit DSA for the time being. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JF8IFj019207; Mon, 19 Sep 2005 08:08:18 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JF8Ixt019206; Mon, 19 Sep 2005 08:08:18 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JF8HKf019195 for ; Mon, 19 Sep 2005 08:08:18 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc13) with ESMTP id <2005091915080801300ab7qke>; Mon, 19 Sep 2005 15:08:12 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8JF8D0m010531 for ; Mon, 19 Sep 2005 11:08:13 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8JF87vT012077 for ; Mon, 19 Sep 2005 11:08:07 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8JF87VV012076 for ietf-openpgp@imc.org; Mon, 19 Sep 2005 11:08:07 -0400 Date: Mon, 19 Sep 2005 11:08:07 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050919150807.GC12013@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050916224113.6004C57EF5@finney.org> <20050919130136.GF9545@jabberwocky.com> <8764sx3ylw.fsf@wheatstone.g10code.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8764sx3ylw.fsf@wheatstone.g10code.de> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Sep 19, 2005 at 04:45:31PM +0200, Werner Koch wrote: > > On Mon, 19 Sep 2005 09:01:37 -0400, David Shaw said: > > > So at least from the graceful failure perspective in GnuPG, it doesn't > > really matter much which way we go. I prefer the first option (using > > the current algorithm number) since it seems cleanest in both code and > > However this does also means that another hash algorithm needs to be a > MUST algorithm - unless we limit the MUST support for DSA to 1024 bits > keys. Yes. I'm not against limiting the MUST support to 1024/160 DSA. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JEpW9r017208; Mon, 19 Sep 2005 07:51:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JEpWTZ017207; Mon, 19 Sep 2005 07:51:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JEpVXl017199 for ; Mon, 19 Sep 2005 07:51:32 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHN5l-0003Hw-32 for ; Mon, 19 Sep 2005 16:58:01 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHMtf-0005cI-Im for ; Mon, 19 Sep 2005 16:45:31 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <20050919130136.GF9545@jabberwocky.com> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 19 Sep 2005 16:45:31 +0200 In-Reply-To: <20050919130136.GF9545@jabberwocky.com> (David Shaw's message of "Mon, 19 Sep 2005 09:01:37 -0400") Message-ID: <8764sx3ylw.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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 Sep 2005 09:01:37 -0400, David Shaw said: > So at least from the graceful failure perspective in GnuPG, it doesn't > really matter much which way we go. I prefer the first option (using > the current algorithm number) since it seems cleanest in both code and However this does also means that another hash algorithm needs to be a MUST algorithm - unless we limit the MUST support for DSA to 1024 bits keys. The need for another algorithm makes a big difference for emdedded applications. Ofen the threat model does not require high budget spook proof algorithms. Shalom-Salam, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JD1i44008974; Mon, 19 Sep 2005 06:01:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8JD1ii7008973; Mon, 19 Sep 2005 06:01:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JD1irS008956 for ; Mon, 19 Sep 2005 06:01:44 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from walrus.hsd1.ma.comcast.net ([24.60.132.70]) by comcast.net (sccrmhc12) with ESMTP id <2005091913013801200qnirre>; Mon, 19 Sep 2005 13:01:38 +0000 Received: from grover.jabberwocky.com (grover.jabberwocky.com [172.24.84.28]) by walrus.hsd1.ma.comcast.net (8.12.8/8.12.8) with ESMTP id j8JD1g0m009958 for ; Mon, 19 Sep 2005 09:01:42 -0400 Received: from grover.jabberwocky.com (grover.jabberwocky.com [127.0.0.1]) by grover.jabberwocky.com (8.13.1/8.13.1) with ESMTP id j8JD1bFw011779 for ; Mon, 19 Sep 2005 09:01:37 -0400 Received: (from dshaw@localhost) by grover.jabberwocky.com (8.13.1/8.13.1/Submit) id j8JD1bJ3011778 for ietf-openpgp@imc.org; Mon, 19 Sep 2005 09:01:37 -0400 Date: Mon, 19 Sep 2005 09:01:37 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050919130136.GF9545@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20050916224113.6004C57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050916224113.6004C57EF5@finney.org> OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc User-Agent: Mutt/1.5.8i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 16, 2005 at 03:41:13PM -0700, "Hal Finney" wrote: > One issue is how best to incorporate these new key sizes. As I see it, > there are three alternatives. > > 1. Just use the new sizes with the existing DSA keys. Instead of only > 512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the > proper hash algorithms in software. > > 2. Use a new algorithm ID for the new DSA keys, which would be only > for 2048 and 3072 bits. The old algorithm ID would continue to be > used for old DSA keys. > > 3. Use a new key packet version number for the new DSA keys, V5. > Perhaps V5 keys could use a SHA-256 based fingerprint. This would > represent a clean break from the old way. > > The first alternative would involve the least change to the spec, just > changes to the information about how to sign and verify with DSA keys. > The second alternative would require adding much the same material > but with the handling of the new algorithm ID called out separately. > It would probably duplicate some of the information on old-style DSA keys. > > The third alternative is the most ambitious and is not feasible for > RFC2440bis IMO. We could still go to a V5 key packet at some point in > the future anyway, and perhaps do other improvements at that time. I am a big fan of V5 keys (see http://www.imc.org/ietf-openpgp/mail-archive/msg09274.html), and I love the clean break, but I feel that if the new DSA was tied to V5 then discussions and design for a good V5 key format would delay availability of the new DSA in the field for an excessively long amount of time. People have been asking for a better DSA for a long time now, so it seems a shame to delay it further. I'm all for planning V5 of course, just not tied to the new DSA. > Between the first two, I would propose to decide largely on the basis of > backwards compatibility. Obviously signatures made with new-style DSA > keys will not be verifiable in old code. The question is how gracefully > existing implementations will fail when presented with such keys and > signatures, in either the first or second form. Testing on current > implementations could provide guidance as to which way of making the > change will cause the least trouble. Presuming that the size of q will change from 160 to 224 or 256 in the new key, importing a DSA key to GnuPG with the current algorithm number and a q that is not 160 bits or importing a new-style DSA key with a new algorithm number fails more or less gracefully in either case. So at least from the graceful failure perspective in GnuPG, it doesn't really matter much which way we go. I prefer the first option (using the current algorithm number) since it seems cleanest in both code and standard. David Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J8aYDC009527; Mon, 19 Sep 2005 01:36:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8J8aYgh009526; Mon, 19 Sep 2005 01:36:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8J8aW20009471 for ; Mon, 19 Sep 2005 01:36:32 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EHHEq-0001XX-ST for ; Mon, 19 Sep 2005 10:43:00 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EHH4b-00055q-IL; Mon, 19 Sep 2005 10:32:25 +0200 To: Ian G Cc: Ben Laurie , Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> <432D4F13.6080703@algroup.co.uk> <432D712D.4060502@systemics.com> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Mon, 19 Sep 2005 10:32:25 +0200 In-Reply-To: <432D712D.4060502@systemics.com> (Ian G.'s message of "Sun, 18 Sep 2005 14:52:45 +0100") Message-ID: <871x3l790m.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) 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 Sun, 18 Sep 2005 14:52:45 +0100, Ian G said: >> How about because generating 2048 bit primes already takes long >> enough, and 3072 takes ages? > Numbers? A quick test shows about 4 seconds for 2048 bit and 21 seconds for 3072. However this includes the time required to gather enough randomness; further tests took much longer very likely due to a lack of entropy in the machine. Most applications don't need to generate keys very ofthen, thus this should not be a problem. OTOH, verification is used very often. Here are number from Libgcrypt: DSA 100 times sign verify ----------------------------- DSA 1024/160 910ms 430ms DSA 2048/224 1560ms 1890ms DSA 3072/256 3610ms 4380ms (The numbers for sign are not very reliable because it employs the RNG and I could not adjust for it) 3072 takes more more than double the time of 2048 which is not too bad. Compared to 1024 this is a real slowdown and would make key signature verification a very time consuming operation. On slow machines (embedded devices, older hardware) this would be very annoying. Shalom-Salam, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IClk7h099402; Sun, 18 Sep 2005 05:47:46 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IClkXF099401; Sun, 18 Sep 2005 05:47:46 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IClj9b099395 for ; Sun, 18 Sep 2005 05:47:46 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 57D8B2B47D5; Sun, 18 Sep 2005 14:47:38 +0200 (CEST) Date: Sun, 18 Sep 2005 14:47:38 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050918124733.GC6483@epointsystem.org> References: <20050916224113.6004C57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050916224113.6004C57EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Sep 16, 2005 at 03:41:13PM -0700, "Hal Finney" wrote: > The new DSS keys will, according to what I have heard, be for two sizes: > 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. > (SHA-224 is not presently an OpenPGP algorithm; it is basically a > truncated version of SHA-256 with a different internal initial value). > This will allow for larger keys and use a different hash than SHA-1. For this reason, I'd agree with Ian and just ignore the 2048/224 key specification. Too much trouble for no gain. > 1. Just use the new sizes with the existing DSA keys. Instead of only > 512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the > proper hash algorithms in software. I like this solution. If old implementations do not do very silly things when encountering such signatures (e.g. claiming them to be bad signatures as opposed to unverifiable), it is the cleanest way to go about it. > 2. Use a new algorithm ID for the new DSA keys, which would be only > for 2048 and 3072 bits. The old algorithm ID would continue to be > used for old DSA keys. This approach would eat up the algorithm identifier space and provide very little advantage. It is reasonable to expect new DSS key specifications every decade, if NIST continues its current practices. > 3. Use a new key packet version number for the new DSA keys, V5. > Perhaps V5 keys could use a SHA-256 based fingerprint. This would > represent a clean break from the old way. Let's wait with that. There are several problems with the v4 key formats and using SHA-256 for fingerprinting is not necessarily a good idea, given that its design is quickly becoming obsolete. > Between the first two, I would propose to decide largely on the basis of > backwards compatibility. Obviously signatures made with new-style DSA > keys will not be verifiable in old code. The question is how gracefully > existing implementations will fail when presented with such keys and > signatures, in either the first or second form. Testing on current > implementations could provide guidance as to which way of making the > change will cause the least trouble. That's a very reasonable suggestion. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8ICYgqv098612; Sun, 18 Sep 2005 05:34:42 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8ICYgGf098611; Sun, 18 Sep 2005 05:34:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8ICYfci098604 for ; Sun, 18 Sep 2005 05:34:41 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 127E82B4812; Sun, 18 Sep 2005 14:34:40 +0200 (CEST) Date: Sun, 18 Sep 2005 14:34:39 +0200 To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-ID: <20050918123430.GB6483@epointsystem.org> References: <20050918001303.96B4F57EF5@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050918001303.96B4F57EF5@finney.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: It's important to keep in mind that DSS-style signatures are twice the hash size. This is one of their nicest features; they do not grow with the modulus. A signature of a 3072/256 key will be 512 bits (plus overhead). As for generating long modulae, it's not that big a problem, altough it has to be noted that generating a modulus for DSA takes more than just generating a prime that big; DSA moduli p are such that p-1 is divisible by some large (hash-sized) q. The generation of such moduli takes substantially longer than generating primes. For 3072/256 on a 500MHz intel, it would take approx. three minutes, provided that the random stream is available without waiting. On the other hand, the overwhelming majority of DSS implementations use pre-calculated moduli, as there are no security hazards associated with using a common modulus for DSS. When keys need to be generated frequently, a pre-calculated modulus is the way to go. If one just needs to generate a personal signature key for the next five years, one can wait three minutes, in case they want to show off a self-generated modulus. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8ICAbK5097176; Sun, 18 Sep 2005 05:10:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8ICAbLd097175; Sun, 18 Sep 2005 05:10:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8ICAXw0097165 for ; Sun, 18 Sep 2005 05:10:35 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 2D08933C1A; Sun, 18 Sep 2005 13:10:28 +0100 (BST) Message-ID: <432D5936.5020701@algroup.co.uk> Date: Sun, 18 Sep 2005 13:10:30 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian G CC: Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> <432D4F13.6080703@algroup.co.uk> <432D712D.4060502@systemics.com> In-Reply-To: <432D712D.4060502@systemics.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G wrote: > Ben Laurie wrote: > >> Ian G wrote: >> >>> Hal Finney wrote: >>> >>>> The new DSS keys will, according to what I have heard, be for two >>>> sizes: >>>> 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. >>>> (SHA-224 is not presently an OpenPGP algorithm; it is basically a >>>> truncated version of SHA-256 with a different internal initial value). >>>> This will allow for larger keys and use a different hash than SHA-1. >>> >>> >>> >>> (assuming we do it,) I would suggest we ditch the 2048/224 >>> and just implement the 3072/256. >>> >>> (We could add the other one as a MAY ... but I can't see >>> the point of it. Sure NIST may split hairs on it, but >>> let's save ourselves the doco and the discussion and >>> just do the better one.) >> >> >> >> How about because generating 2048 bit primes already takes long >> enough, and 3072 takes ages? > > > Numbers? I was going to provide them, but accurate numbers for DSA is difficult, because it requires modifying the core code in OpenSSL (or some other DSA generator), and I couldn't be bothered. One can get a feel for it with: time openssl gendh which takes a long time. Long enough that I didn't wait for it to finish before hitting send. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IBsf5Z096360; Sun, 18 Sep 2005 04:54:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IBsfD8096359; Sun, 18 Sep 2005 04:54:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IBseow096352 for ; Sun, 18 Sep 2005 04:54:40 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id F2400417BB; Sun, 18 Sep 2005 12:54:29 +0100 (BST) Message-ID: <432D712D.4060502@systemics.com> Date: Sun, 18 Sep 2005 14:52:45 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ben Laurie Cc: Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> <432D4F13.6080703@algroup.co.uk> In-Reply-To: <432D4F13.6080703@algroup.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ben Laurie wrote: > Ian G wrote: > >> Hal Finney wrote: >> >>> The new DSS keys will, according to what I have heard, be for two sizes: >>> 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. >>> (SHA-224 is not presently an OpenPGP algorithm; it is basically a >>> truncated version of SHA-256 with a different internal initial value). >>> This will allow for larger keys and use a different hash than SHA-1. >> >> >> (assuming we do it,) I would suggest we ditch the 2048/224 >> and just implement the 3072/256. >> >> (We could add the other one as a MAY ... but I can't see >> the point of it. Sure NIST may split hairs on it, but >> let's save ourselves the doco and the discussion and >> just do the better one.) > > > How about because generating 2048 bit primes already takes long enough, > and 3072 takes ages? Numbers? iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IBRNYt094610; Sun, 18 Sep 2005 04:27:23 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8IBRNTa094609; Sun, 18 Sep 2005 04:27:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.links.org (mail.links.org [217.155.92.109]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8IBRIuw094600 for ; Sun, 18 Sep 2005 04:27:21 -0700 (PDT) (envelope-from ben@algroup.co.uk) Received: from [193.133.15.218] (localhost [127.0.0.1]) by mail.links.org (Postfix) with ESMTP id 49B8933C1A; Sun, 18 Sep 2005 12:27:13 +0100 (BST) Message-ID: <432D4F13.6080703@algroup.co.uk> Date: Sun, 18 Sep 2005 12:27:15 +0100 From: Ben Laurie User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ian G CC: Hal Finney , ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> <432CAAC9.2050305@systemics.com> In-Reply-To: <432CAAC9.2050305@systemics.com> X-Enigmail-Version: 0.89.6.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian G wrote: > Hal Finney wrote: >> The new DSS keys will, according to what I have heard, be for two sizes: >> 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. >> (SHA-224 is not presently an OpenPGP algorithm; it is basically a >> truncated version of SHA-256 with a different internal initial value). >> This will allow for larger keys and use a different hash than SHA-1. > > (assuming we do it,) I would suggest we ditch the 2048/224 > and just implement the 3072/256. > > (We could add the other one as a MAY ... but I can't see > the point of it. Sure NIST may split hairs on it, but > let's save ourselves the doco and the discussion and > just do the better one.) How about because generating 2048 bit primes already takes long enough, and 3072 takes ages? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8I0DSDm042721; Sat, 17 Sep 2005 17:13:28 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8I0DSwB042720; Sat, 17 Sep 2005 17:13:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8I0DR9C042713 for ; Sat, 17 Sep 2005 17:13:27 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 96B4F57EF5; Sat, 17 Sep 2005 17:13:03 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys Message-Id: <20050918001303.96B4F57EF5@finney.org> Date: Sat, 17 Sep 2005 17:13:03 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ian Grigg writes: > (assuming we do it,) I would suggest we ditch the 2048/224 > and just implement the 3072/256. > > (We could add the other one as a MAY ... but I can't see > the point of it. Sure NIST may split hairs on it, but > let's save ourselves the doco and the discussion and > just do the better one.) > ... > I don't think it is that easy. SHAs are under a cloud, > and until we get some more definitive info on the new > hardware factoring, even the numbers suggested above > won't satisfy all the extremists. Consider that the > extreme community considers 4096 to be a minimum, and > all the news is supporting them at the moment; also, > NIST's hash work has been controversial (SHA0, SHA2 > being just an "extension" ...), I'd like to see what > the crypto community comes up with in hash research as > that feeds into DSS. I'm not sure why there is not a plan for larger key sizes. A possible clue is in this NIST document, "Recommendation for Key Management", http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf . Table 2 on page 63 shows the following correspondences between hash size and modulus size: 160/1024; 224/2048; 256/3072; 384/7680; and 512/15360. This fits what we know, with SHA-1 and a 1024 bit modulus as the traditional DSS; SHA-224 and a 2048 bit modulus, and SHA-256 and a 3072 bit modulus in this new DSS that I have been told about. It implies that the natural next size would be SHA-384 and a 7680 bit modulus. But that modulus is too big for most people's convenience. You might say, just use SHA-384 and a 4096 bit modulus, but that is not such a nice fit. The hash is a lot stronger than the modulus and so it is not well balanced. Perhaps such esthetic considerations motivated NIST's decision. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8HLm4hH030086; Sat, 17 Sep 2005 14:48:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8HLm4Zu030085; Sat, 17 Sep 2005 14:48:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8HLm3Qi030076 for ; Sat, 17 Sep 2005 14:48:03 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id E0FD9415F0; Sat, 17 Sep 2005 22:48:01 +0100 (BST) Message-ID: <432CAAC9.2050305@systemics.com> Date: Sun, 18 Sep 2005 00:46:17 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Hal Finney Cc: ietf-openpgp@imc.org Subject: Re: Bigger DSA keys References: <20050916224113.6004C57EF5@finney.org> In-Reply-To: <20050916224113.6004C57EF5@finney.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal Finney wrote: > The new DSS keys will, according to what I have heard, be for two sizes: > 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. > (SHA-224 is not presently an OpenPGP algorithm; it is basically a > truncated version of SHA-256 with a different internal initial value). > This will allow for larger keys and use a different hash than SHA-1. (assuming we do it,) I would suggest we ditch the 2048/224 and just implement the 3072/256. (We could add the other one as a MAY ... but I can't see the point of it. Sure NIST may split hairs on it, but let's save ourselves the doco and the discussion and just do the better one.) > If this report is correct, it would be good to see these new key sizes > in RFC2440bis. Otherwise the DSS support in the spec will be essentially > "dead on arrival". Rather than publishing a spec with a major class > of keys that has no future utility, I think it makes sense to wait six > weeks and see if we can incorporate the new information, making the > spec much more robust and long-lasting. I don't think it is that easy. SHAs are under a cloud, and until we get some more definitive info on the new hardware factoring, even the numbers suggested above won't satisfy all the extremists. Consider that the extreme community considers 4096 to be a minimum, and all the news is supporting them at the moment; also, NIST's hash work has been controversial (SHA0, SHA2 being just an "extension" ...), I'd like to see what the crypto community comes up with in hash research as that feeds into DSS. Which rambling means to say that even after the October date, I suspect it will be all too easy to say "let's wait a bit more..." > For those who say we have waited too long already, I will just note that > the weeks and months drift by without much reason for delay but without > much progress either. Now that there is a good reason to hold off a > bit more, I would hate to see us suddenly rush to close the door. > > One issue is how best to incorporate these new key sizes. As I see it, > there are three alternatives. > > 1. Just use the new sizes with the existing DSA keys. Instead of only > 512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the > proper hash algorithms in software. > > 2. Use a new algorithm ID for the new DSA keys, which would be only > for 2048 and 3072 bits. The old algorithm ID would continue to be > used for old DSA keys. I think I'd lean towards this one. This would allow us to deprecate DSA-old just as soon as we can. > 3. Use a new key packet version number for the new DSA keys, V5. > Perhaps V5 keys could use a SHA-256 based fingerprint. This would > represent a clean break from the old way. I'd go against this (for the same reason you outline below). > The first alternative would involve the least change to the spec, just > changes to the information about how to sign and verify with DSA keys. > The second alternative would require adding much the same material > but with the handling of the new algorithm ID called out separately. > It would probably duplicate some of the information on old-style DSA keys. Ah, good point. But unless by some miracle all the implementations can handle #1 without blowing up, then I can't see how we'd countenance an incompatible change? > The third alternative is the most ambitious and is not feasible for > RFC2440bis IMO. We could still go to a V5 key packet at some point in > the future anyway, and perhaps do other improvements at that time. Right. > Between the first two, I would propose to decide largely on the basis of > backwards compatibility. Obviously signatures made with new-style DSA > keys will not be verifiable in old code. The question is how gracefully > existing implementations will fail when presented with such keys and > signatures, in either the first or second form. Testing on current > implementations could provide guidance as to which way of making the > change will cause the least trouble. Certainly interesting times for DSS fans. I use it in a lot of my stuff and have pretty much made up my mind to move to RSA when and as I can. Mostly this is because NIST have moved too little, too late on this one, and the numbers above are already looking like we'll be into a change again in about 2-3 years when the new Hash research settles into a new generation of algorithms. iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8GMffid002923; Fri, 16 Sep 2005 15:41:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8GMff3k002922; Fri, 16 Sep 2005 15:41:41 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8GMfeFh002916 for ; Fri, 16 Sep 2005 15:41:40 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 6004C57EF5; Fri, 16 Sep 2005 15:41:13 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Bigger DSA keys Message-Id: <20050916224113.6004C57EF5@finney.org> Date: Fri, 16 Sep 2005 15:41:13 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have it on good authority that NIST will be announcing larger size DSS keys soon. According to my source, the date will be by the end of October. Currently, DSS keys have two problems. First, they can be no bigger than 1024 bits. Recent results show that keys of this size can no longer be considered safe from large scale attackers. See for example http://lists.virus.org/cryptography-0509/msg00080.html (although this is for RSA keys, DSS keys of a similar size are not thought to be too much more difficult). Second, DSS keys are locked into using SHA-1, for which attacks have been published. The new DSS keys will, according to what I have heard, be for two sizes: 2048 and 3072 bits, and will use SHA-224 and SHA-256 respectively. (SHA-224 is not presently an OpenPGP algorithm; it is basically a truncated version of SHA-256 with a different internal initial value). This will allow for larger keys and use a different hash than SHA-1. If this report is correct, it would be good to see these new key sizes in RFC2440bis. Otherwise the DSS support in the spec will be essentially "dead on arrival". Rather than publishing a spec with a major class of keys that has no future utility, I think it makes sense to wait six weeks and see if we can incorporate the new information, making the spec much more robust and long-lasting. For those who say we have waited too long already, I will just note that the weeks and months drift by without much reason for delay but without much progress either. Now that there is a good reason to hold off a bit more, I would hate to see us suddenly rush to close the door. One issue is how best to incorporate these new key sizes. As I see it, there are three alternatives. 1. Just use the new sizes with the existing DSA keys. Instead of only 512-1024 bits, let DSA keys also be 2048 and 3072 bits, and enforce the proper hash algorithms in software. 2. Use a new algorithm ID for the new DSA keys, which would be only for 2048 and 3072 bits. The old algorithm ID would continue to be used for old DSA keys. 3. Use a new key packet version number for the new DSA keys, V5. Perhaps V5 keys could use a SHA-256 based fingerprint. This would represent a clean break from the old way. The first alternative would involve the least change to the spec, just changes to the information about how to sign and verify with DSA keys. The second alternative would require adding much the same material but with the handling of the new algorithm ID called out separately. It would probably duplicate some of the information on old-style DSA keys. The third alternative is the most ambitious and is not feasible for RFC2440bis IMO. We could still go to a V5 key packet at some point in the future anyway, and perhaps do other improvements at that time. Between the first two, I would propose to decide largely on the basis of backwards compatibility. Obviously signatures made with new-style DSA keys will not be verifiable in old code. The question is how gracefully existing implementations will fail when presented with such keys and signatures, in either the first or second form. Testing on current implementations could provide guidance as to which way of making the change will cause the least trouble. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G2Xu0Z061491; Thu, 15 Sep 2005 19:33:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8G2Xumx061490; Thu, 15 Sep 2005 19:33:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G2XtLO061482 for ; Thu, 15 Sep 2005 19:33:55 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 40C3657EF5; Thu, 15 Sep 2005 19:33:25 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Re: Any SHA-1 dependencies? Message-Id: <20050916023325.40C3657EF5@finney.org> Date: Thu, 15 Sep 2005 19:33:25 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Daniel Nagy writes: > Basically, what you are proposing is a sort of universal hash function, > where the hash algorithm identifier is followed by the hash computed using > that particular algorithm. > > This is potentially very dangerous, as it does not follow several > assumptions about a good hash function. Namely the hash value is not > unique and parts of the hash function are not uniformly strong. I agree that is one way to look at it. In a hypothetical future key fingerprint system, there would be multiple kinds: a SHA-1 fingerprint, a SHA256 fingerprint, a RIPEMD160 fingerprint, and so on. So it is non-unique. The idea is that if SHA-1 or some other hash became broken, the other kinds of fingerprints could be used, without revising the spec. Of course an attacker could replace a fingerprint with one based on an old, weak hash, but it would ultimately be up to the verifier to decide which hashes he would trust. In the event of a break, switching over to a new hash would be a potentially costly operation but it would not require issuing a new spec. I'm not sure what dangers you see over a system which would require changing both implementations and specifications. > On the other hand, there is a fair chance that SHA1 (and even MD5, though > its 128 bit length is a problem by itself) might be fixed. The known > collision attacks are based on collisions in the compression function > and it seems that in both cases the set of "problematic" blocks is actually > very sparse and easily detectable. This allows for several security > improvements: first, (and it has already been done, AFAIK) one can > immediately detect a data stream as one that is likely to be an > attempted attack on the hash function, second, one might create a "fixed" > compression function that does something different for problematic blocks, > thus yielding a hash function that gives the same output as SHA1 for the > vast majority of inputs, while being resistant against SHA1 collisions. > > The detection result is very likely to be presented at Eurocrypt2006, and > there's a chance that the fix will be presented too. I will look forward to seeing that. I wonder if it might be discussed at the NIST Halloween "hash bash", it sounds like it would be of great interest there. Without knowing the details it is hard to comment, but in general I would worry that any detection system might be "brittle" and possibly small changes to the attack method might bypass the detector while still producing collisions (perhaps somewhat more expensively). For example the Wang attacks always use the same initial differential, but there is no reason they could not work with slightly different differentials, I think. She chose the best one but I gather that there are others that weren't too bad. A detection system tuned too closely to known attacks might miss these alternatives. > The sparsity of problematic blocks also implies (although this is not > strictly within the scope of the discussion) that key-id binding signatures > might collide only on the key part (*), which is not dangerous. If the above > mentioned sanity check is performed, it removes even the non-dangerous key > collision as a possibility. I also remember Eli Biham last year at Crypto demonstrating very textual looking collisions on truncated SHA-1. His collisions were composed of ascii characters and even English words. Granted, truncation makes a world of difference in the ease of the attack but I wonder if we can be sure that the full SHA-1 attacks can never be improved in this way. > Also remember, that collisions are of concern only if the data is to be signed by > someone different from its author. There are protocol-level safeguards > against this possibility, though employing these would require a major > overhaul of OpenPGP, which in the light of the above is not warranted (yet). > Someday, however, we might very well be forced to introduce version 5 > signatures for certification and other notarial purposes. It is better to > postpone that as long as possible, because important discoveries with > immediate consequencnes on design and standardization decisions might lay ahead. Yes, there have been strong debates in online forums for example about changing signature procedures so that the signer prepends a block of data of his choice to the message to be signed, in case the message is prepared by someone else. There seems to be no consensus on whether this is on balance a good idea or not. > So, I would recommend sticking to SHA1 for the time being, as there is no > hash function with a better design at this point. Alternatives that belong > to the same MD4 family of hash functions (e.g. the now-fashionable > RIPEMD-160) have not been attacked only because SHA1 was a more rewarding > target. I didn't recommend stopping using SHA-1. In fact my only actual recommendation was to include SHA256 as another MUST hash, in case SHA-1 gets broken more badly (and in the hope that SHA256 will be OK). > Now, moving to 256-bit hash functions in order to have a built-in "safety > factor" keeping the hash-function safe even if it's partially broken, seems > to be inconsistent with market-economies. In our case it is particularly > relevant, because the standard we are designing is not enforced, leaving the > choice to the user. In general, though, it is risky to use non-MUST hashes in your signatures, for interoperability reasons. Of course we have only limited leverage over this via the spec, and as you note the market may force implementations to move to SHA256 regardless of whether it is MUST or not. [Skipping on a bit] > Back on topic, this is why I would advise against moving to 256-bit hashes > based on the MD4 design. Yes, it would add some security against hypotetical > ultra-motivated adversaries flush with resources, but you are interested in > these not because they are actually threats but because you are catering to > paranoid customers. Those would sneer at a partially broken SHA256 just as > they sneer at a partially broken SHA1. So, you will have to switch again > very soon, without gaining anything from the previous switch. It's not > rational behavior, especially in standardization. So, are you predicting that SHA256 will have at least theoretical breaks of its own? The people I have talked to seem quite non-committal about this prospect. No one can rule it out but most people say it should be stronger than SHA-1 and more resistant to this kind of attack. > Thus, my recommendation would be to postpone the discussion until more is > known, to avoid swift moves and stick to SHA1 for the time being. Maybe a > footnote would be warranted to explain why it's still safe to do things the > way we do them. Again, the only thing I recommended was to add SHA256 as a MUST. The only MUST-implement hash we have now is SHA-1. What do you think of that change? > Now, I have a separate set of grievances about the v4 private key packet format > and the way v4 key fingerprints are being calculated, but that has very > little to do with the recent developments around our once-favorite hash > function. In a separate post, I will explain why I would like to introduce a > new version of key packets (both public and private), and once we embark on > designing new packet formats, we can address the use of hash functions in > that context as well, but again, it's a separate topic. I have another change to suggest as well, which will also go into a future message. Thanks for your comments, they are very interesting and helpful. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G1QSqT055353; Thu, 15 Sep 2005 18:26:28 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8G1QSxD055352; Thu, 15 Sep 2005 18:26:28 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org ([195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8G1QQgG055345 for ; Thu, 15 Sep 2005 18:26:27 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id 8BD122B47A9; Fri, 16 Sep 2005 03:26:25 +0200 (CEST) Date: Fri, 16 Sep 2005 03:26:25 +0200 To: ietf-openpgp@imc.org Subject: Re: Any SHA-1 dependencies? Message-ID: <20050916012625.GB2627@epointsystem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hal, Basically, what you are proposing is a sort of universal hash function, where the hash algorithm identifier is followed by the hash computed using that particular algorithm. This is potentially very dangerous, as it does not follow several assumptions about a good hash function. Namely the hash value is not unique and parts of the hash function are not uniformly strong. On the other hand, there is a fair chance that SHA1 (and even MD5, though its 128 bit length is a problem by itself) might be fixed. The known collision attacks are based on collisions in the compression function and it seems that in both cases the set of "problematic" blocks is actually very sparse and easily detectable. This allows for several security improvements: first, (and it has already been done, AFAIK) one can immediately detect a data stream as one that is likely to be an attempted attack on the hash function, second, one might create a "fixed" compression function that does something different for problematic blocks, thus yielding a hash function that gives the same output as SHA1 for the vast majority of inputs, while being resistant against SHA1 collisions. The detection result is very likely to be presented at Eurocrypt2006, and there's a chance that the fix will be presented too. The sparsity of problematic blocks also implies (although this is not strictly within the scope of the discussion) that key-id binding signatures might collide only on the key part (*), which is not dangerous. If the above mentioned sanity check is performed, it removes even the non-dangerous key collision as a possibility. Also remember, that collisions are of concern only if the data is to be signed by someone different from its author. There are protocol-level safeguards against this possibility, though employing these would require a major overhaul of OpenPGP, which in the light of the above is not warranted (yet). Someday, however, we might very well be forced to introduce version 5 signatures for certification and other notarial purposes. It is better to postpone that as long as possible, because important discoveries with immediate consequencnes on design and standardization decisions might lay ahead. So, I would recommend sticking to SHA1 for the time being, as there is no hash function with a better design at this point. Alternatives that belong to the same MD4 family of hash functions (e.g. the now-fashionable RIPEMD-160) have not been attacked only because SHA1 was a more rewarding target. Now, moving to 256-bit hash functions in order to have a built-in "safety factor" keeping the hash-function safe even if it's partially broken, seems to be inconsistent with market-economies. In our case it is particularly relevant, because the standard we are designing is not enforced, leaving the choice to the user. The thing is that partially broken security products are a tough sell even if the remaining part is still secure enough. It is pretty clear from your post that you _are_ concerned about this. Let me digress a bit: In the USSR, it was okay to slash development costs by building in safety factors, so that even if the hash function or the block cipher turned out to be weaker than the designers originally thought, they would be still secure enough. Hence the 256-bit key length of the standard soviet block cipher (GOST 28147-89) which also doubles as the compression function of their standard hash function (standardized later as GOST 34.11-94). For government use (**) and for use in a planned economy this was the most rational way of designing the system: quick, cheap and a little dirty. In market economies, this approach won't fly, because as soon as your product is discredited by being partially broken, you will have to switch anyway, so cheap development with safety factors won't save you money in the long run. Hence, it's not a rational approach to cryptographic algorithm design and indeed, we don't see it in successful products in the free market. It is important to emphasize that it is not because your customers are somehow dumber in a market economy but because in addition to your development costs, they also have to bear the cost of choosing the right product for themselves (this cost does not occur in planned economies -- in certain cases, it can be a significant saving), and they are rational about minimizing it by not touching anything that has been discredited in any way -- they simply cannot afford to behave otherwise (in most cases). Back on topic, this is why I would advise against moving to 256-bit hashes based on the MD4 design. Yes, it would add some security against hypotetical ultra-motivated adversaries flush with resources, but you are interested in these not because they are actually threats but because you are catering to paranoid customers. Those would sneer at a partially broken SHA256 just as they sneer at a partially broken SHA1. So, you will have to switch again very soon, without gaining anything from the previous switch. It's not rational behavior, especially in standardization. Thus, my recommendation would be to postpone the discussion until more is known, to avoid swift moves and stick to SHA1 for the time being. Maybe a footnote would be warranted to explain why it's still safe to do things the way we do them. Now, I have a separate set of grievances about the v4 private key packet format and the way v4 key fingerprints are being calculated, but that has very little to do with the recent developments around our once-favorite hash function. In a separate post, I will explain why I would like to introduce a new version of key packets (both public and private), and once we embark on designing new packet formats, we can address the use of hash functions in that context as well, but again, it's a separate topic. (*) It is impossible to trick someone into binding a sane-looking unseen UID to a given public key by presenting him with another sane-looking UID that would collide with the unseen one for signature. (**) There is evidence suggesting that the mentioned algorithms were in government use long before having been released to the public as industry standards. Probably since the early eighties or even earlier. Bests, -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FMxUBu044206; Thu, 15 Sep 2005 15:59:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8FMxUWe044205; Thu, 15 Sep 2005 15:59:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8FMxTRV044198 for ; Thu, 15 Sep 2005 15:59:29 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id 25EC357EF5; Thu, 15 Sep 2005 15:58:58 -0700 (PDT) To: ietf-openpgp@imc.org Subject: Any SHA-1 dependencies? Message-Id: <20050915225858.25EC357EF5@finney.org> Date: Thu, 15 Sep 2005 15:58:58 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There are a few places in the OpenPGP spec where we hard-code the use of the SHA-1 hash. Given the recent attacks on this hash, we should look and see if there will be any security weaknesses if it should turn out that SHA-1 is broken and it becomes easier to generate collisions. This is actually a pretty complicated issue and it becomes something of a "can of worms" situation, ie. there are many complexities and subtleties that arise in the analysis. Here are some: - We don't know how badly SHA-1 might be broken. Current attacks can theoretically generate limited sorts of collisions in (at last report) about 2^64 work. Perhaps this work level will be lowered. Perhaps the limitations on collisions may be reduced. Perhaps even more powerful attacks such as preimage attacks (to find data that matches the hash of a given value) will become possible. - Any hash algorithm might in principle be broken eventually. A spec like OpenPGP can at best allow a choice of hash algorithms. However even then it will be necessary for communicators to decide which hash algorithms they trust. If someone loses confidence in a hash algorithm while others are still using it, interoperability is lost. My approach to these problems is to assume that SHA-1 will be broken to the extent that collisions can be found with moderate effort, even collisions with particular structures. However, preimages will not be possible. I think this is a conservative assumption given what is known about the new attacks. As far as the second issue, I will outline places where we hard-code SHA-1, and we should think about what would be involved in trying to allow for different hash algorithms to be used in place. Here then are the places we hard-code SHA-1 and the security implications. 5.5.3 Secret Key Packet Formats This has the option of using a 20-byte SHA-1 hash as a checksum of the secret key material. This should be safe. 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) This uses the SHA-1 hash of the message as a checksum for integrity. This should be safe. 9.4. Hash Algorithms SHA-1 is the only MUST implement hash algorithm. I would recommend that we include at least SHA-256 as a MUST implement algorithm, for future security. 11.2. Key IDs and Fingerprints A V4 key fingerprint is the SHA-1 hash of the key material. If SHA-1 is broken then it will be possible to create two keys which have the same fingerprint. Any places in the spec where fingerprints are used as pointers to keys, it will be possible for the key creator to substitute another key he created. Likewise, the V4 key ID is a substring of the fingerprint so the same considerations arise. (However, with respect to key IDs it is an old problem, since 64 bit key IDs can be made to collide with only 2^32 work, a very tractable amount.) Places where fingerprints are used: 5.2.3.15. Revocation key The revocation key (designated revoker) is specified via key fingerprint. This should be safe since the key holder is trusted to perform this service, so if he created a key collision he would only be able to transfer this power among keys he controlled. It is not an OpenPGP issue, but PGP uses signature subpacket 10 as an additional decryption key indicator, and this is also done via a key fingerprint. Similar considerations apply as for the designated revoker. With regard to key IDs, these are used in the following places: 5.1. Public-Key Encrypted Session Key Packets (Tag 1) The key ID indicates which key can decrypt the message. Ability to create keys with colliding key IDs should not cause security problems. 5.2.2. Version 3 Signature Packet Format The key ID of the signing key is stored in the V3 signature packet. Ability to create keys with colliding key IDs should not cause security problems. 5.2.3.5. Issuer This is the V4 key ID. Same situation as for V3. In fact we usually put this signature packet in the unhashed region. 5.4. One-Pass Signature Packets (Tag 4) Same situation as above. Summary None of the hard-coded uses of SHA-1 in the OpenPGP spec appear to introduce security problems, even if creating SHA-1 collisions becomes easy. This analysis does not cover the case of finding pre-images. The one change we might consider is to expand the set of MUST algorithms beyond SHA-1 since the community is shifting away from that hash. In the longer term it would be desirable to consider parameterizing the few places where SHA-1 is hard-coded, to take a hash algorithm specifier. This will allow us to avoid even the appearance of weakness which may be of concern to potential users, as SHA-1 becomes deprecated in a wide range of products and protocols in future years. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EB6Me3027453; Wed, 14 Sep 2005 04:06:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8EB6Mxp027452; Wed, 14 Sep 2005 04:06:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8EB6L1S027445 for ; Wed, 14 Sep 2005 04:06:22 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 1745D41599 for ; Wed, 14 Sep 2005 12:06:20 +0100 (BST) Message-ID: <4328050F.3020309@systemics.com> Date: Wed, 14 Sep 2005 12:10:07 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: OpenPGP Subject: Armouring - silly fix Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: If we haven't entered last call. In Section 6.6 it says "is indented by two spaces" but looks like three to me :-) I would suggest it say "is indented by several spaces". ============8<============================8<================ 6.6. Example of an ASCII Armored Message -----BEGIN PGP MESSAGE----- Version: OpenPrivacy 0.99 yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS vBSFjNSiVHsuAA== =njUN -----END PGP MESSAGE----- Callas, et al. Expires Jan 08, 2006 [Page 53] ^LINTERNET-DRAFT OpenPGP Message Format Jul 08, 2005 Note that this example is indented by two spaces. ============8<============================8<================ iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87NVaKQ022524; Wed, 7 Sep 2005 16:31:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j87NVaVI022523; Wed, 7 Sep 2005 16:31:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epointsystem.org (120.156-228-195.hosting.adatpark.hu [195.228.156.120]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87NVY4s022516 for ; Wed, 7 Sep 2005 16:31:35 -0700 (PDT) (envelope-from nagydani@epointsystem.org) Received: by mail.epointsystem.org (Postfix, from userid 1001) id C452A2B47BE; Thu, 8 Sep 2005 01:31:25 +0200 (CEST) Date: Thu, 8 Sep 2005 01:31:25 +0200 To: ietf-openpgp@imc.org Subject: Re: Information and meta-information Message-ID: <20050907233120.GA31910@epointsystem.org> References: <20050831152646.GB31148@epointsystem.org> <8BADBD06-012A-44B0-A9A7-6BDAE8ED8E37@hhhh.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8BADBD06-012A-44B0-A9A7-6BDAE8ED8E37@hhhh.org> User-Agent: Mutt/1.5.6+20040907i From: nagydani@epointsystem.org (Daniel A. Nagy) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Sep 07, 2005 at 03:56:58PM -0700, Wim Lewis wrote: > The existing 'b', 't', etc. tags could then be defined as shorthands > for particular MIME headers (content-type and charset). I disagree, because these tags convey a slightly different (lower-level) meaning than the mime headers. Also, the above suggestion would be a security hazard, since the literal packet's tag is not hashed and can be therefore altered in a signed message, without breaking the signature. PGP/MIME headers, on the other hand, are included in the hashed material, so they are part of the signed message. > >I would suggest the following modification of RFC2440bis-14: > > Do you mean removing the 't' and 'u' tags? Or supplementing them with > 'm'? Supplementing with 'm', of course. Removing 't' and 'b' tags (what's 'u'?) would break almost everything. -- Daniel Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87Mv4eG019720; Wed, 7 Sep 2005 15:57:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j87Mv4uB019719; Wed, 7 Sep 2005 15:57:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from machop.omnigroup.com (omnigroup.com [198.151.161.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j87Mv315019712 for ; Wed, 7 Sep 2005 15:57:03 -0700 (PDT) (envelope-from wiml@hhhh.org) Received: from [198.151.161.70] (slowpoke.omnigroup.com [198.151.161.70]) by machop.omnigroup.com (Postfix) with ESMTP id 1945B3C19CEE; Wed, 7 Sep 2005 15:56:59 -0700 (PDT) In-Reply-To: <20050831152646.GB31148@epointsystem.org> References: <20050831152646.GB31148@epointsystem.org> Mime-Version: 1.0 (Apple Message framework v734) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8BADBD06-012A-44B0-A9A7-6BDAE8ED8E37@hhhh.org> Cc: "Daniel A. Nagy" Content-Transfer-Encoding: 7bit From: Wim Lewis Subject: Re: Information and meta-information Date: Wed, 7 Sep 2005 15:56:58 -0700 To: ietf-openpgp@imc.org X-Mailer: Apple Mail (2.734) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 31 Aug, 2005, at 8:26 AM, Daniel A. Nagy wrote: > There is no distinction between PGP/MIME data and regular RFC2440 > data, > although all it would take is a flag in the Literal packet. This > way, if I > saved the PGP MESSAGE from an application/pgp-encrypted MIME chunk > (which is > doable even with MUAs ignorant of PGP/MIME), I could still decrypt > it into a > usable file (e.g. a jpeg image). I have had exactly the same thought (down to the choice of an 'm' in that field to indicate MIME data). This seems like a good idea in general. It would be useful outside of PGP/MIME as well: if metadata such as datatype or character encoding needs to be associated with the PGP-protected data, it seems reasonable to piggyback on MIME, just as (e.g.) HTTP does. The existing 'b', 't', etc. tags could then be defined as shorthands for particular MIME headers (content-type and charset). > I would suggest the following modification of RFC2440bis-14: Do you mean removing the 't' and 'u' tags? Or supplementing them with 'm'? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j83F6Mh6089203; Sat, 3 Sep 2005 08:06:22 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j83F6MuE089202; Sat, 3 Sep 2005 08:06:22 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j83F6L9h089192 for ; Sat, 3 Sep 2005 08:06:21 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id 405B34142E; Sat, 3 Sep 2005 16:06:20 +0100 (BST) Message-ID: <4319BCD4.60902@systemics.com> Date: Sat, 03 Sep 2005 16:10:12 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Atkins Cc: ietf-openpgp@imc.org Subject: Re: IETF-63 Proceedings Submission References: <431891A7.3060101@systemics.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins wrote: > Of course this didn't make it into the minutes; this messages > happened well after the IETF met in August. The minutes are a > status report of the IETF meeting; It does not take into account > messages that have been processed *since* the IETF. Apologies - I was confused and didn't realise this related to a meeting back then. iang Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j83E1WNW083671; Sat, 3 Sep 2005 07:01:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j83E1WCu083670; Sat, 3 Sep 2005 07:01:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from cliodev.pgp.com (me@CLIODEV.IHTFP.ORG [204.107.200.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j83E1UrJ083658 for ; Sat, 3 Sep 2005 07:01:31 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j83E1T2O012901; Sat, 3 Sep 2005 10:01:29 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j83E1Tcs012898; Sat, 3 Sep 2005 10:01:29 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: Ian G Cc: ietf-openpgp@imc.org Subject: Re: IETF-63 Proceedings Submission References: <431891A7.3060101@systemics.com> Date: Sat, 03 Sep 2005 10:01:29 -0400 In-Reply-To: <431891A7.3060101@systemics.com> (Ian G.'s message of "Fri, 02 Sep 2005 18:53:43 +0100") Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) 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: Of course this didn't make it into the minutes; this messages happened well after the IETF met in August. The minutes are a status report of the IETF meeting; It does not take into account messages that have been processed *since* the IETF. -derek And no, we're not in final call, yet. I need to catch up and make sure we've handled all the open issues. I'll see if I can get to that this week. Ian G writes: > Derek Atkins wrote: >> - If you want changes in wording - need to be compatable and suggest text. >> - Only open issue is David Shaw's BNF request for literal+literal. No reason not to include David Shaw's request, but not in draft 14. Should go into 15 > > I guess the below didn't make it then. Oh well. > > > > -------- Original Message -------- > Subject: Re: Signature types > Date: Sat, 27 Aug 2005 10:25:07 +0100 > From: Ian G > Organization: http://financialcryptography.com/ > To: ietf-openpgp@imc.org > References: <20050827075018.GA17967@epointsystem.org> > > > Daniel A. Nagy wrote: >> ... [some stuff] > > On that section, but not on Daniel's question, it occurs to > me that the caveat found half way down ("Please note that > the vagueness...") could be usefully expanded to cover all > of 5.2.1. > > Something like: > > 5.2.1. Signature Types > > There are a number of possible meanings for a signature. > By convention, OpenPGP suggests meanings by the following > signature type octets in any given signature. > > Please note that the vagueness of these signature claims > is not a flaw, but a feature of the system. Cryptographic > signing technology alone cannot make these claims true, > and a relying party would need to examine the intentions > of any signer, and the wider context of the system and > environment in order to assess any claims. OpenPGP places > final authority and responsibility on the receiver of any > signature. > > 0x01:... > > Which then allows a simplification of the post-0x13 comment: > > 0x13:... > > Please note that one authority's casual certification > might be more rigorous than some other authority's > positive certification. These classifications allow a > certification authority to issue fine-grained claims. > > Most OpenPGP implementations make their "key signatures" as 0x10 > certifications. Some implementations can issue 0x11-0x13 > certifications, but few differentiate between the types. > > > As an alternate, such general commentary could append to the > end of the section - but in legal terms, if it is a warning > as to limitations, it should be at the front. Given the > somewhat poisoned waters of digital signatures, I'd prefer > to see the disclaims before any claims. > > iang > > PS: are we in final call already? > > > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j82HnsGF040692; Fri, 2 Sep 2005 10:49:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j82Hns7a040691; Fri, 2 Sep 2005 10:49:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailgate.enhyper.net ([80.168.109.121]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j82HnrPw040684 for ; Fri, 2 Sep 2005 10:49:53 -0700 (PDT) (envelope-from iang@systemics.com) Received: from [IPv6:::1] (localhost [127.0.0.1]) by mailgate.enhyper.net (Postfix) with ESMTP id E346C5D137; Fri, 2 Sep 2005 18:49:51 +0100 (BST) Message-ID: <431891A7.3060101@systemics.com> Date: Fri, 02 Sep 2005 18:53:43 +0100 From: Ian G Organization: http://financialcryptography.com/ User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050831) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Derek Atkins Cc: ietf-openpgp@imc.org Subject: Re: IETF-63 Proceedings Submission References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Derek Atkins wrote: > - If you want changes in wording - need to be compatable and suggest text. > - Only open issue is David Shaw's BNF request for literal+literal. No reason not to include David Shaw's request, but not in draft 14. Should go into 15 I guess the below didn't make it then. Oh well. -------- Original Message -------- Subject: Re: Signature types Date: Sat, 27 Aug 2005 10:25:07 +0100 From: Ian G Organization: http://financialcryptography.com/ To: ietf-openpgp@imc.org References: <20050827075018.GA17967@epointsystem.org> Daniel A. Nagy wrote: > ... [some stuff] On that section, but not on Daniel's question, it occurs to me that the caveat found half way down ("Please note that the vagueness...") could be usefully expanded to cover all of 5.2.1. Something like: 5.2.1. Signature Types There are a number of possible meanings for a signature. By convention, OpenPGP suggests meanings by the following signature type octets in any given signature. Please note that the vagueness of these signature claims is not a flaw, but a feature of the system. Cryptographic signing technology alone cannot make these claims true, and a relying party would need to examine the intentions of any signer, and the wider context of the system and environment in order to assess any claims. OpenPGP places final authority and responsibility on the receiver of any signature. 0x01:... Which then allows a simplification of the post-0x13 comment: 0x13:... Please note that one authority's casual certification might be more rigorous than some other authority's positive certification. These classifications allow a certification authority to issue fine-grained claims. Most OpenPGP implementations make their "key signatures" as 0x10 certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types. As an alternate, such general commentary could append to the end of the section - but in legal terms, if it is a warning as to limitations, it should be at the front. Given the somewhat poisoned waters of digital signatures, I'd prefer to see the disclaims before any claims. iang PS: are we in final call already? Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j82GMmR0030768; Fri, 2 Sep 2005 09:22:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j82GMmRi030767; Fri, 2 Sep 2005 09:22:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from cliodev.pgp.com (me@CLIODEV.IHTFP.ORG [204.107.200.20]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j82GMlxl030760 for ; Fri, 2 Sep 2005 09:22:47 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from cliodev.pgp.com (cliodev.pgp.com [127.0.0.1]) by cliodev.pgp.com (8.13.1/8.13.1) with ESMTP id j82GMfVW011099; Fri, 2 Sep 2005 12:22:41 -0400 Received: (from warlord@localhost) by cliodev.pgp.com (8.13.1/8.13.1/Submit) id j82GMZta011096; Fri, 2 Sep 2005 12:22:35 -0400 X-Authentication-Warning: cliodev.pgp.com: warlord set sender to warlord@MIT.EDU using -f From: Derek Atkins To: proceedings@ietf.org Cc: ietf-openpgp@imc.org Subject: IETF-63 Proceedings Submission Date: Fri, 02 Sep 2005 12:22:35 -0400 Message-ID: User-Agent: Gnus/5.110003 (No Gnus v0.3) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=-=-= Minutes of OpenPGP Meeting at IETF-63 -derek --=-=-= Content-Disposition: attachment; filename=Minutes-63.txt Content-Description: OpenPGP Minutes AGENDA -- -- Introduction and Agenda Bashing No changes -- 2440 bis status - In "pentultimate last call" for some time (over a year) - now only doing tweaks to the document. - If you want changes in wording - need to be compatable and suggest text. - Only open issue is David Shaw's BNF request for literal+literal. No reason not to include David Shaw's request, but not in draft 14. Should go into 15 - Run last call and finish this document - Use difference documents for new work - downside is that not everything will be in a small number of documents. Good news is that will have a fixed definitive document -- 2440 next steps - Go to Last call. finish by end of August - Try for a bake off? try for Draft Standard. (early in '06) - update milestones - proposal given. - Draft standard would be tried for 6 months after IESG approval. - New Life - New documents not hit 2440bis. - -- Proposed Milestones Aug 05 WGLC for 2440bis Sep 05 Submit 2440bis to IESG as Proposed Standard Nov 05 Finish Interop Test Plan Jan 06 Begin 2440bis Interop Testing Mar 06 Request DRAFT Status for 2440bis - No Objections --- Message Header - draft-josefsson-openpgp-mailnews-header-01.txt - standardize some X- headers for PGP. - Lookup URL and key id of a sender - simplified original by dropping some unnecessary data. - key id - longer fingerprint - url to key - What is the problem to be solved? - Not completely clear - invent header that could be used programatically to lookup key and keyid of sender - Manual cut & paste? - request for additinoal current usage of old headers for inclusion in the doument. - Open Issuses: - Add token to state strong preference for reciving PGP and potentially the PGP format to be sent. - IETF process restricted to MIME? - place same info into a packet? - Keyserver field? - unsure of what this would be really for. Next expansion of the idea. - BNF problems on the draft need corrections. Open MIKE JON - Supports idea of draft - supports "supports token" - PGP has a similar item already used. used with different values for different reading devices. - Wants support to plain inline text - kill mime and only use plain text as a personal preference. - response - Need additional proposals to solve some of the problems? JON - display problems not format issues - Don't ban text only w/o mime wrappers. 8-bit character set problems with servers - Vigourous dispute on issues with character sets. Thomas Roessler - two formats - with and w/o tag - please elimiate the untagged version. ??? - Please add finger print header - used for validation. - possible support already? JON - KeyID is a trucated fingerprint - allow for longer id to get fuller fingerprint w/o much additional parsing. - -00 to -01 allowed for longer KeyID from a fixed length. --- Open Discussion - Meeting closed. --=-=-= -- 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 above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8271LwO062931; Fri, 2 Sep 2005 00:01:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j8271LG8062930; Fri, 2 Sep 2005 00:01:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8271JqI062922 for ; Fri, 2 Sep 2005 00:01:20 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EB5eO-0006Wj-BI for ; Fri, 02 Sep 2005 09:07:48 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EB5Wq-0004WP-4H; Fri, 02 Sep 2005 09:00:00 +0200 To: Karl Kashofer Cc: ietf-openpgp@imc.org Subject: Re: Encrypt subject References: <20050831224025.BBED557EF5@finney.org> <4316D4CC.8080501@gmx.at> <877je0oq4r.fsf@wheatstone.g10code.de> <43175586.3040100@gmx.at> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Fri, 02 Sep 2005 09:00:00 +0200 In-Reply-To: <43175586.3040100@gmx.at> (Karl Kashofer's message of "Thu, 01 Sep 2005 20:24:54 +0100") Message-ID: <87ek88kl8v.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 01 Sep 2005 20:24:54 +0100, Karl Kashofer said: > I see what you mean, but from a practical point of view, how much PGP > encrypted spam have you gotten lately ? I was not talking about spam but on how to prioritize/ignore regular mail. Salam-Shalom, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81JPXq9065753; Thu, 1 Sep 2005 12:25:33 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81JPX3D065752; Thu, 1 Sep 2005 12:25:33 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j81JPWTv065732 for ; Thu, 1 Sep 2005 12:25:32 -0700 (PDT) (envelope-from karl.kashofer@gmx.at) Received: (qmail invoked by alias); 01 Sep 2005 19:25:25 -0000 Received: from unknown (EHLO [10.0.0.50]) [81.189.102.241] by mail.gmx.net (mp026) with SMTP; 01 Sep 2005 21:25:25 +0200 X-Authenticated: #7548666 Received: from 127.0.0.1 (AVG SMTP 7.0.344 [267.10.16]); Thu, 01 Sep 2005 20:24:54 +0100 Message-ID: <43175586.3040100@gmx.at> Date: Thu, 01 Sep 2005 20:24:54 +0100 From: Karl Kashofer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ietf-openpgp@imc.org Subject: Re: Encrypt subject References: <20050831224025.BBED557EF5@finney.org> <4316D4CC.8080501@gmx.at> <877je0oq4r.fsf@wheatstone.g10code.de> In-Reply-To: <877je0oq4r.fsf@wheatstone.g10code.de> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! > What I mean is that a subject you need to decrypt first is not very > usable for the purpose a subject line is commonly used, i.e. to > quickly decide what messages belong together and whether to read them. > > With a slow connection and POP3 and with IMAP in general many people > just look at the subject to decide whether to retrieve the entire > message. Requiring to decrypt it first make no sense then. I see what you mean, but from a practical point of view, how much PGP encrypted spam have you gotten lately ? I assume if its encrypted it might actually be worth reading ? > So, my suggestion is to use a non-sense subject line to merely help > visualizing a theread. Sure, but if enigmail were able to permanently decrypt messages this could still be accomplished once the message is decrypted. Problem seems to be that mozilla/thunderbird does atm not allow them to permanently modify the message, so it might take a while to implement that anyway. Thanks for your help, I will carry this to the enigmail mailing list, Cheers, Karl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDF1WFyD2v/adjdKMRAjh8AKDv4KMDbGWH12JSU2C3yJM7B7p8OgCfep+X gW6I3WSYKl7ejzqudPQUp5Q= =9fjR -----END PGP SIGNATURE----- Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81JEuGh064642; Thu, 1 Sep 2005 12:14:56 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81JEuxf064641; Thu, 1 Sep 2005 12:14:56 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81JEsLT064634 for ; Thu, 1 Sep 2005 12:14:55 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.50 #1 (Debian)) id 1EAuck-0002Td-FT for ; Thu, 01 Sep 2005 21:21:22 +0200 Received: from wk by localhost with local (Exim 4.34 #1 (Debian)) id 1EApQj-0003QO-MC; Thu, 01 Sep 2005 15:48:37 +0200 To: Karl Kashofer Cc: ietf-openpgp@imc.org Subject: Re: Encrypt subject References: <20050831224025.BBED557EF5@finney.org> <4316D4CC.8080501@gmx.at> From: Werner Koch Organisation: g10 Code GmbH OpenPGP: id=5B0358A2; url=finger:wk@g10code.com Date: Thu, 01 Sep 2005 15:48:36 +0200 In-Reply-To: <4316D4CC.8080501@gmx.at> (Karl Kashofer's message of "Thu, 01 Sep 2005 11:15:40 +0100") Message-ID: <877je0oq4r.fsf@wheatstone.g10code.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 01 Sep 2005 11:15:40 +0100, Karl Kashofer said: > Well the way Werner describes it, he just advises not to use a Subject. What I mean is that a subject you need to decrypt first is not very usable for the purpose a subject line is commonly used, i.e. to quickly decide what messages belong together and whether to read them. With a slow connection and POP3 and with IMAP in general many people just look at the subject to decide whether to retrieve the entire message. Requiring to decrypt it first make no sense then. So, my suggestion is to use a non-sense subject line to merely help visualizing a theread. > Could you by any means describe this in more detail ? Something like this: From: me@example.org To: you@example.com Subject: none Content-Type: multipart/encrypted; protocol=application/pgp-encrypted; boundary="xxxxxx" --xxxxxx Content-Type: application/pgp-encrypted Version: 1 --xxxxxx Content-Type: application/octet-stream & Content-Type: message/rfc822; boundary="yyyyy" & & & --yyyyyy & From: me@example.org & To: you@example.com & Subject: Don't tell anyone that PGP/MIME just works & Content-Type: text/plain & & Proposal on how to gain world domination of PGP/MIME & and to abolish any use of S/MIME. & & --yyyyyy-- --xxxxxx-- Where the lines marked by "&" are actually encrypted. Salam-Shalom, Werner Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81I3AGR058080; Thu, 1 Sep 2005 11:03:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81I3Att058079; Thu, 1 Sep 2005 11:03:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81I37DQ058070 for ; Thu, 1 Sep 2005 11:03:09 -0700 (PDT) (envelope-from hal@finney.org) Received: by finney.org (Postfix, from userid 500) id D128B57EF5; Thu, 1 Sep 2005 10:13:22 -0700 (PDT) To: ietf-openpgp@imc.org, karl.kashofer@gmx.at Subject: Re: Encrypt subject Message-Id: <20050901171322.D128B57EF5@finney.org> Date: Thu, 1 Sep 2005 10:13:22 -0700 (PDT) From: hal@finney.org ("Hal Finney") Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Karl Kashofer writes: > So this would adhere to the standards, and allow to embed headers inside > the PGP encryption block ? > > Could you by any means describe this in more detail ? > > I would try to bring it to the attention of enigmail developers, maybe > they are interested in it. Well, PGP/MIME is http://www.ietf.org/rfc/rfc3156.txt which is based on the MIME security extensions, http://www.ietf.org/rfc/rfc1847.txt . The message/rfc822 type for embedding mail with headers is described in http://www.ietf.org/rfc/rfc2046.txt section 5.2.1. The implementation concept would be that when you decrypt a PGP/MIME message and find that the inner type is message/rfc822, you would promote the relevant mail headers, particularly Subject, from the inner type to the outer message. This might also include source information ("From"), for example if the message were delivered via an anonymous remailer network. Maybe some other headers could also be usefully encrypted. Hal Finney Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j81AGAnv016214; Thu, 1 Sep 2005 03:16:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j81AGA4E016213; Thu, 1 Sep 2005 03:16:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by above.proper.com (8.12.11/8.12.9) with SMTP id j81AG8Zc016154 for ; Thu, 1 Sep 2005 03:16:09 -0700 (PDT) (envelope-from karl.kashofer@gmx.at) Received: (qmail invoked by alias); 01 Sep 2005 10:16:02 -0000 Received: from unknown (EHLO hotmail.com) [81.189.102.241] by mail.gmx.net (mp029) with SMTP; 01 Sep 2005 12:16:02 +0200 X-Authenticated: #7548666 Received: from 127.0.0.1 (AVG SMTP 7.0.344 [267.10.16]); Thu, 01 Sep 2005 11:15:41 +0100 Message-ID: <4316D4CC.8080501@gmx.at> Date: Thu, 01 Sep 2005 11:15:40 +0100 From: Karl Kashofer User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Encrypt subject References: <20050831224025.BBED557EF5@finney.org> In-Reply-To: <20050831224025.BBED557EF5@finney.org> X-Enigmail-Version: 0.92.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi ! > The problem is that we do sort of have a solution to this already, which > Werner described: use PGP/MIME. MIME allows for embedding one email > message inside another, and the MIME security extensions, including > PGP/MIME, show how to encrypt such an embedded message. Well the way Werner describes it, he just advises not to use a Subject. >>Simply send your mail as an encrypted message/rfc2822 MIME message and >>put an innocent subject into the header. > The problem is that almost no mailers support this. Few enough even > support PGP/MIME, and then they would also have to be smart enough to > figure out what to do with an embedded email message. Replacing the > enclosing message's headers with those from the embedded message is not > an obvious thing to do. So this would adhere to the standards, and allow to embed headers inside the PGP encryption block ? Could you by any means describe this in more detail ? I would try to bring it to the attention of enigmail developers, maybe they are interested in it. They have Per-Recipient-Rules, so it would be possible to implement that, and then specify it in these rules, so its only used for recipients which are able to decrypt it. I do that with PGP/MIME to only use it for thunderbird recipients, works fine. I would really like to see this implemented, and I am sure it annoys a few other people as well. Cheers, Karl -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDFtTMyD2v/adjdKMRAoCiAJ0butw/p1Nnefj7dOV0K/coITSRKgCg1M6r mFt5/JSKgtAVVezPYxIpPVE= =n0fX -----END PGP SIGNATURE-----