From owner-ietf-openpgp@mail.imc.org Tue May 9 09:46:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19554 for ; Tue, 9 May 2000 09:46:56 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA18254 for ietf-openpgp-bks; Tue, 9 May 2000 06:07:49 -0700 (PDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18248 for ; Tue, 9 May 2000 06:07:47 -0700 (PDT) Received: by sentry.gw.tislabs.com; id JAA10418; Tue, 9 May 2000 09:15:31 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010411; Tue, 9 May 00 09:14:38 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA17939 for ietf-openpgp@imc.org; Tue, 9 May 2000 09:07:54 -0400 (EDT) Date: Tue, 9 May 2000 09:07:54 -0400 (EDT) From: "David M. Balenson" Message-Id: <200005091307.JAA17939@clipper.gw.tislabs.com> To: ietf-openpgp@imc.org Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: C A L L F O R P A P E R S The Internet Society 2001 Network and Distributed System Security Symposium (NDSS'01) February 7-9, 2001 Catamaran Resort, San Diego, California IMPORTANT DATES Paper Submission due: August 2, 2000 Author Notification: September 27, 2000 Camera-ready final papers due: October 31, 2000 GOAL: This symposium will foster information exchange among researchers and practioners of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Submissions are solicited for, but are not limited to, the following topics: * Secure Electronic Commerce: e.g., payment, barter, EDI, notarization/timestamping, endorsement and licensing. * Intellectual Property Protection: protocols, schemas, implementations, metering, watermarking, other forms of rights management. * Implementation, deployment and management of network security policies. * Integrating Security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web. * Attack-resistant protocols and services. * Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: tele- and video-conferencing, groupwork, etc. * Fundamental services: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification, revocation, audit trails and accountability. * Public Key Infrastructure. * Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, database management, boot services, mobile computing. * Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Intrusion Avoidance, Detection, and Response: systems, experiences and architectures. * Network Perimeter Controls: firewalls, packet filters, application gateways. * Virtual Private Networks. BEST PAPER AWARD: There will be a best paper award again this year. The award will be presented at the symposium to the authors of the best overall paper as selected by the Program Committee. SUBMISSIONS: The Program Committee invites both technical papers and panel proposals. Technical papers should be at most 20 pages long. Panel proposals should be at most two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may - at the discretion of the panel chair - include written position statements from the panelists. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, e-mail addresses, and must specify the contact author in case of multi-author submissions. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by August 2, 2000, and must be made via electronically in either PostScript or ASCII format. If the Committee is unable to print a PostScript submission, a hardcopy will be requested. Therefore, PostScript submissions must arrive well before the deadline. Submission information can be found at http://www.isoc.org/ndss01/cfp. Dates, final call for papers, advance program, and registration information will be available soon at http://www.isoc.org/ndss01. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program Co-chairs as indicated below. Authors and panelists will be notified of acceptance by September 27, 2000. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by October 31, 2000. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies TUTORIAL CHAIR: Eric Harder, National Security Agency LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Mahesh Tripunitara, Purdue University PUBLICITY CHAIR: David Balenson, NAI Labs, Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society PROGRAM COMMITTEE: Bennet Yee, University of California San Diego Bill Cheswick, Bell Labs Dave Kormann, AT&T Labs - Research David Aucksmith, Intel Corportation David P. Maher, Intertrust David Wagner, UC Berkeley Edward W. Felten, Princeton University Fabian Monrose, Bell Labs Gary McGraw, Reliable Software Technologies James Ellis, Sun Microsystems Kevin McCurley, IBM Almaden Research Center Matt Bishop, UC Davis Mudge, L0pht Heavy Industries, Inc. Peter Gutmann, University of Auckland, New Zealand Radia Perlman, Sun Microsystems Sandra Murphy, Network Associates Tom Berson, Anagram Laboratories Virgil D. Gligor, University of Maryland From owner-ietf-openpgp@mail.imc.org Tue May 9 14:07:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26736 for ; Tue, 9 May 2000 14:07:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23516 for ietf-openpgp-bks; Tue, 9 May 2000 10:38:51 -0700 (PDT) Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23285; Tue, 9 May 2000 10:36:53 -0700 (PDT) Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST) Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Finance Director" Subject: Instant On-Line Credit Reports Date: Tue, 9 May 2000 16:34:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies From owner-ietf-openpgp@mail.imc.org Wed May 10 01:13:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA08849 for ; Wed, 10 May 2000 01:13:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA00559 for ietf-openpgp-bks; Tue, 9 May 2000 21:53:23 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA00549 for ; Tue, 9 May 2000 21:53:20 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 12687 invoked from network); 10 May 2000 04:56:02 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 May 2000 04:56:02 -0000 To: ietf-openpgp@imc.org Subject: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510135914U.1001@eccosys.com> Date: Wed, 10 May 2000 13:59:14 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 32 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit for reference, the following text is from the security considerations section of rfc 2368: A mailto URL gives a template for a message that can be sent by mail client software. The contents of that template may be opaque or difficult to read by the user at the time of specifying the URL. Thus, a mail client should never send a message based on a mailto URL without first showing the user the full message that will be sent (including all headers that were specified by the mailto URL), fully decoded, and asking the user for approval to send the message as electronic mail. The mail client should also make it clear that the user is about to send an electronic mail message, since the user may not be aware that this is the result of a mailto URL. A mail client should never send anything without complete disclosure to the user of what is will be sent; it should disclose not only the message destination, but also any headers. Unrecognized headers, or headers with values inconsistent with those the mail client would normally send should be especially suspect. MIME headers (MIME- Version, Content-*) are most likely inappropriate, as are those relating to routing (From, Bcc, Apparently-To, etc.) in a similar vein, would it not make sense to recommend that mail clients display the encrypted or signed form of messages and ask for confirmation before actually sending the message? or at least recommend providing the capability to do so. i would guess there have been cases of people who thought they had encrypted or signed a message before sending it, but it turned out they hadn't. i have a vague recollection of this being mentioned in a recent pgp usability study (perhaps someone can confirm). From owner-ietf-openpgp@mail.imc.org Wed May 10 05:12:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20787 for ; Wed, 10 May 2000 05:12:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA13290 for ietf-openpgp-bks; Wed, 10 May 2000 01:47:32 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13286 for ; Wed, 10 May 2000 01:47:30 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12pSVS-0001s1-00; Wed, 10 May 2000 11:10:14 +0200 Date: Wed, 10 May 2000 11:10:14 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) Message-ID: <20000510111014.H7032@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000510135914U.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000510135914U.1001@eccosys.com>; from sen_ml@eccosys.com on Wed, May 10, 2000 at 01:59:14PM +0900 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 May 2000, sen_ml@eccosys.com wrote: > i would guess there have been cases of people who thought they had > encrypted or signed a message before sending it, but it turned out > they hadn't. i have a vague recollection of this being mentioned in a > recent pgp usability study (perhaps someone can confirm). IMHO, an MTA which rejects unencrypted mails would be a better alternative to protect against such kinds of failures. It may look at some headers to detect ML replies and use a table of addresses which are allowed to receive unencrypted mail. Or reject everything unless a special formed address is used (which the MTA substitutes for the real address). Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Wed May 10 06:34:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21594 for ; Wed, 10 May 2000 06:34:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17871 for ietf-openpgp-bks; Wed, 10 May 2000 02:59:29 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17864 for ; Wed, 10 May 2000 02:59:27 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 20990 invoked from network); 10 May 2000 10:02:06 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 May 2000 10:02:06 -0000 To: ietf-openpgp@imc.org Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) In-Reply-To: <20000510111014.H7032@djebel.gnupg.de> References: <20000510135914U.1001@eccosys.com> <20000510111014.H7032@djebel.gnupg.de> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510190520G.1001@eccosys.com> Date: Wed, 10 May 2000 19:05:20 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 28 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Werner Koch Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) Date: Wed, 10 May 2000 11:10:14 +0200 Message-ID: <20000510111014.H7032@djebel.gnupg.de> > On Wed, 10 May 2000, sen_ml@eccosys.com wrote: > > > i would guess there have been cases of people who thought they had > > encrypted or signed a message before sending it, but it turned out > > they hadn't. i have a vague recollection of this being mentioned in a > > recent pgp usability study (perhaps someone can confirm). > > IMHO, an MTA which rejects unencrypted mails would be a better > alternative to protect against such kinds of failures. It may look > at some headers to detect ML replies and use a table of > addresses which are allowed to receive unencrypted mail. Or reject > everything unless a special formed address is used (which the MTA > substitutes for the real address). that is indeed another (not necessarily mutually exclusive) option. i presume you are referring to an mta on the sending client machine. that is correct, right? i think i would like a client that does both :-) in any case, i think it would make sense to point out somewhere these kinds of concerns -- hints for implementors. From owner-ietf-openpgp@mail.imc.org Wed May 10 06:52:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21826 for ; Wed, 10 May 2000 06:52:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20957 for ietf-openpgp-bks; Wed, 10 May 2000 03:27:28 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20953 for ; Wed, 10 May 2000 03:27:26 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin177-nt.pg7.frankfurt.nikoma.de [213.54.38.177]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id MAA37119; Wed, 10 May 2000 12:33:03 +0200 (CEST) (envelope-from roessler@guug.de) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id D99932ED3D; Wed, 10 May 2000 12:32:54 +0200 (CEST) Date: Wed, 10 May 2000 12:32:54 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Cc: John W Noerenberg II , Raph Levien , Michael Elkins , Dave Del Torto Subject: PGP/MIME: Time for last call? Message-ID: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org, John W Noerenberg II , Raph Levien , Michael Elkins , Dave Del Torto Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does anyone see a reason why we should not start getting the OpenPGP/MIME and multipart/mixed signature drafts into the RFC process? -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Wed May 10 10:36:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26901 for ; Wed, 10 May 2000 10:36:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26956 for ietf-openpgp-bks; Wed, 10 May 2000 07:06:01 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26952 for ; Wed, 10 May 2000 07:05:59 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12pXTj-000277-00; Wed, 10 May 2000 16:28:47 +0200 Date: Wed, 10 May 2000 16:28:47 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) Message-ID: <20000510162847.M7032@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000510135914U.1001@eccosys.com> <20000510111014.H7032@djebel.gnupg.de> <20000510190520G.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000510190520G.1001@eccosys.com>; from sen_ml@eccosys.com on Wed, May 10, 2000 at 07:05:20PM +0900 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 May 2000, sen_ml@eccosys.com wrote: > i presume you are referring to an mta on the sending client machine. > that is correct, right? Sure. The local /usr/lib/sendmail should do it. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Wed May 10 11:43:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28290 for ; Wed, 10 May 2000 11:43:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28377 for ietf-openpgp-bks; Wed, 10 May 2000 08:16:26 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28371 for ; Wed, 10 May 2000 08:16:24 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 27256 invoked from network); 10 May 2000 15:19:05 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 May 2000 15:19:05 -0000 To: ietf-openpgp@imc.org Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) In-Reply-To: <20000510162847.M7032@djebel.gnupg.de> References: <20000510111014.H7032@djebel.gnupg.de> <20000510190520G.1001@eccosys.com> <20000510162847.M7032@djebel.gnupg.de> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000511002219O.1001@eccosys.com> Date: Thu, 11 May 2000 00:22:19 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 29 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Werner Koch Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) Date: Wed, 10 May 2000 16:28:47 +0200 Message-ID: <20000510162847.M7032@djebel.gnupg.de> > On Wed, 10 May 2000, sen_ml@eccosys.com wrote: > > > i presume you are referring to an mta on the sending client machine. > > that is correct, right? > > Sure. The local /usr/lib/sendmail should do it. this sounds like you are assuming a unix system w/ sendmail. what i'm a bit more concerned about is all of the windows and mac clients that i have to look after for my users. each of those clients connects to an external smtp server to send mail (i think that is a pretty typical setup, don't you?). i'm not very happy about the idea of messages being accidentally transmitted in the clear between the client and the smtp server [*]. it seems like for those cases the mail client should (perhaps also) be doing the checking. as a side note, in fact the mail client which i am using already supports a bit of "policy" w.r.t. replying to messages that were encrypted -- sadly it isn't a mail client that my windows and mac users will use :-( [*] good reason to use ssh port-forwarding of the relevant smtp connection i guess, but not everyone will be so lucky... From owner-ietf-openpgp@mail.imc.org Thu May 11 05:06:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22911 for ; Thu, 11 May 2000 05:06:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02236 for ietf-openpgp-bks; Thu, 11 May 2000 01:40:57 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02232 for ; Thu, 11 May 2000 01:40:56 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA18968; Thu, 11 May 2000 09:46:52 +0100 (BST) Message-ID: Date: Thu, 11 May 2000 09:44:28 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME: Time for last call? References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> In-Reply-To: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 May 2000, Thomas Roessler wrote: >Does anyone see a reason why we should not start getting >the OpenPGP/MIME and multipart/mixed signature drafts into >the RFC process? Should the issue of binary versus text-mode signatures be addressed? RFC1847 had the design objective of aiding single-pass signature verification. To that end, it defined the micalg paramater so that the client could pre-calculate the hash over the MIME data. RFC2015 and RFC2015bis clients know what hash is required for the signature, but they don't know what data has actually been hashed. The line endings will always be CRLF because of the MIME canonicalization, but trailing spaces may or may not be included in the hash depending on the signature mode. Possible improvements to openPGP/MIME could therefore be: 1) Simply state the problem, and indicate that for one-pass processing, two hashes will have to be prepared - one for binary-mode signatures and one for text-mode signatures. 2) Mandate which form of signature must be used. Trailing spaces are often significant in email/news (sig-seps, RFC2646), so a binary-mode signature might seem preferable. However, existing PGP/MIME clients may be using either. 3) Define a "pgp-mode" parameter, pgp-mode=binary or pgp-mode=text and ensure that new clients add the parameter to the multipart/signed header. If the parameter is missing (RFC2015 messages), then one-pass clients will have to prepare two hashes. I feel that 3) is the most satisfactory fix to the problem, but that at least 1) is incorporated into the draft before it is sent to last call. -- Ian Bell T U R N P I K E Ltd From owner-ietf-openpgp@mail.imc.org Fri May 12 05:22:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA29723 for ; Fri, 12 May 2000 05:22:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA10032 for ietf-openpgp-bks; Fri, 12 May 2000 01:53:52 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA10022 for ; Fri, 12 May 2000 01:53:49 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 8858 invoked from network); 12 May 2000 08:56:35 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 12 May 2000 08:56:35 -0000 To: ietf-openpgp@imc.org Subject: question about section 3.6.1.1 simple s2k: how does preloading work? X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000512175954R.1001@eccosys.com> Date: Fri, 12 May 2000 17:59:54 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 40 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit i have a question about the "preloading" of hash contexts w/ zeros that is described in section 3.6.1.1. section 3.6.1.1 says: If the hash size is less than the key size, multiple instances of the hash context are created -- enough to produce the required key data. These instances are preloaded with 0, 1, 2, ... octets of zeros (that is to say, the first instance has no preloading, the second gets preloaded with 1 octet of zero, the third is preloaded with two octets of zeros, and so forth). i am trying to understand how this "preloading" works. using md5 as an example, would the values of the context state variables be: 0x00452301 0xefcdab89 0x98badcfe 0x10325476 for the second instance, and 0x00002301 0xefcdab89 0x98badcfe 0x10325476 for the third instance? that is, does the preloading occur after initializing the context state w/ A, B, C, D, (as in rfc 1321) and starting w/ the most significant byte? it is not clear to me from the text of the rfc (and the bis draft) that one can tell how the details of the preloading should work -- that is, it appears ambiguous to me. perhaps there is some general knowledge that i am ignorant of :-) is this type of preloading operation for hash contexts described in detail somewhere? any pointers would be appreciated. From owner-ietf-openpgp@mail.imc.org Fri May 12 11:07:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03621 for ; Fri, 12 May 2000 11:07:43 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24123 for ietf-openpgp-bks; Fri, 12 May 2000 07:41:26 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24119 for ; Fri, 12 May 2000 07:41:21 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12qGhe-0005aj-00; Fri, 12 May 2000 16:46:10 +0200 To: Ian Bell Cc: ietf-openpgp@imc.org Subject: Re: PGP/MIME: Time for last call? References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> From: Florian Weimer Date: 12 May 2000 16:46:10 +0200 Message-ID: Lines: 22 User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.5 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: Ian Bell writes: [micalg parameter doesn't contain all information to precompute the hash] > I feel that 3) is the most satisfactory fix to the problem, but that at > least 1) is incorporated into the draft before it is sent to last call. Or 4): Drop the micalg parameter. This will make one-pass processing impossible, but I doubt that it's worth the trouble (unless the theoretical possibility of one-pass processing is required by some MIME standard). Future revisions of the OpenPGP message standard might specify additional hash algorithms (which might even require some parameters); OpenPGP implementators might want to use proprietary algorithms, and so on. Synchronizing OpenPGP-MIME with these developments is not very complicated, but I think the benifit of having a micalg parameter is even too small for that. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 From owner-ietf-openpgp@mail.imc.org Fri May 12 11:36:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04466 for ; Fri, 12 May 2000 11:35:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24927 for ietf-openpgp-bks; Fri, 12 May 2000 08:09:37 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24923 for ; Fri, 12 May 2000 08:09:36 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA03777; Fri, 12 May 2000 08:15:42 -0400 Date: Fri, 12 May 2000 08:15:42 -0400 Message-Id: <200005121215.IAA03777@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The "preloading" means to hash the preloaded data. In other words, the preloaded data is a prefix to the rest of the data to be hashed. It is not inserted directly into the state variables. Without preloading, you would do hash(data). Preloading one byte of zero you would do hash(0,data). Preloading two bytes of data you would do hash(0,0,data), and so on, where the commas represent concatenation. Hal From owner-ietf-openpgp@mail.imc.org Fri May 12 11:43:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04679 for ; Fri, 12 May 2000 11:43:03 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25129 for ietf-openpgp-bks; Fri, 12 May 2000 08:16:53 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25125 for ; Fri, 12 May 2000 08:16:51 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin120-nt.pg12.frankfurt.nikoma.de [213.54.43.120]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id RAA31412; Fri, 12 May 2000 17:22:40 +0200 (CEST) (envelope-from roessler@guug.de) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id A44242ED3D; Fri, 12 May 2000 17:07:10 +0200 (CEST) Date: Fri, 12 May 2000 17:07:10 +0200 From: Thomas Roessler To: Florian Weimer Cc: Ian Bell , ietf-openpgp@imc.org Subject: Re: PGP/MIME: Time for last call? Message-ID: <20000512170710.A23026@sobolev.tlr-net.does-not-exist.org> Mail-Followup-To: Florian Weimer , Ian Bell , ietf-openpgp@imc.org References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3i In-Reply-To: ; from Florian.Weimer@RUS.Uni-Stuttgart.DE on Fri, May 12, 2000 at 04:46:10PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-05-12 16:46:10 +0200, Florian Weimer wrote: > Synchronizing OpenPGP-MIME with these developments is > not very complicated, but I think the benifit of having > a micalg parameter is even too small for that. Please note that the draft text already solves this: | The "micalg" parameter for the "application/pgp-signature" | protocol MUST contain exactly one hash-symbol of the | format "pgp-", where | identifies the Message Integrity Check (MIC) algorithm | used to generate the signature. Hash-symbols are | constructed from the text names registered in [1] or | according to the mechanism defined in that document by | converting the text name to lower case and prefixing it | with the four characters "pgp-". Ian: I'll come back to the issue you raised later. I'll have to check some things in 1847 for this. -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Fri May 12 11:52:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04973 for ; Fri, 12 May 2000 11:52:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25313 for ietf-openpgp-bks; Fri, 12 May 2000 08:29:31 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25309 for ; Fri, 12 May 2000 08:29:28 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id QAA13766; Fri, 12 May 2000 16:35:35 +0100 (BST) Message-ID: Date: Fri, 12 May 2000 16:33:16 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME: Time for last call? References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 12 May 2000, Florian Weimer wrote: >Ian Bell writes: > >[micalg parameter doesn't contain all information to precompute the hash] > >> I feel that 3) is the most satisfactory fix to the problem, but that at >> least 1) is incorporated into the draft before it is sent to last call. > >Or 4): Drop the micalg parameter. This will make one-pass processing >impossible, but I doubt that it's worth the trouble (unless the >theoretical possibility of one-pass processing is required by some >MIME standard). The micalg parameter is a required parameter of RFC1847. One-pass processing seems to have been a design-goal of RFC1847. I think there are benefits deriving from the fact that openPGP/MIME is based on RFC1847 which mean that the micalg parameter should not be dropped. (not least of which is that the multipart/mixed signature draft is written in terms of multiple RFC1847 signatures, not multiple openPGP/MIME signatures.) -- Ian Bell T U R N P I K E Ltd From owner-ietf-openpgp@mail.imc.org Fri May 12 12:13:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05704 for ; Fri, 12 May 2000 12:13:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25406 for ietf-openpgp-bks; Fri, 12 May 2000 08:35:51 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25402 for ; Fri, 12 May 2000 08:35:50 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiowk07105; Fri, 12 May 2000 15:41:54 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24764; Fri, 12 May 00 11:38:30 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA18076; Fri, 12 May 2000 11:41:53 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14620.9792.804075.924572@xedia.com> Date: Fri, 12 May 2000 11:41:52 -0400 (EDT) To: hal@finney.org Cc: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? References: <200005121215.IAA03777@finney.org> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "hal" == hal writes: hal> The "preloading" means to hash the preloaded data. In other hal> words, the preloaded data is a prefix to the rest of the data to hal> be hashed. It is not inserted directly into the state hal> variables. hal> Without preloading, you would do hash(data). Preloading one hal> byte of zero you would do hash(0,data). Preloading two bytes of hal> data you would do hash(0,0,data), and so on, where the commas hal> represent concatenation. The use of terms like "preloading" and "multiple instances of the hash context" makes it sound like a description of an implementation, which of course isn't what you want in a protocol spec. I wonder if it would help to phrase it in the other way you just used: hash (data) concatenated with hash (0 data) concatenated with ... The key extension description in the IKE spec is done in this way, if memory serves. paul From owner-ietf-openpgp@mail.imc.org Sat May 13 23:46:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA16681 for ; Sat, 13 May 2000 23:46:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA06742 for ietf-openpgp-bks; Sat, 13 May 2000 20:20:31 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA06729 for ; Sat, 13 May 2000 20:20:28 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 10033 invoked from network); 14 May 2000 03:23:18 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 14 May 2000 03:23:18 -0000 To: ietf-openpgp@imc.org Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? In-Reply-To: <200005121215.IAA03777@finney.org> References: <200005121215.IAA03777@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000514122641B.1001@eccosys.com> Date: Sun, 14 May 2000 12:26:41 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 40 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? Date: Fri, 12 May 2000 08:15:42 -0400 Message-ID: <200005121215.IAA03777@finney.org> > The "preloading" means to hash the preloaded data. In other words, > the preloaded data is a prefix to the rest of the data to be hashed. > It is not inserted directly into the state variables. > > Without preloading, you would do hash(data). Preloading one byte of > zero you would do hash(0,data). Preloading two bytes of data you would > do hash(0,0,data), and so on, where the commas represent concatenation. thank you very much for the clarification, i think i understand now. initially, i had thought that that might have been what was meant, but since elsewhere in the rfc the term "append" is used (5.1 and 5.5.3) to describe a similar type of concatenation, i thought that the term "prepend" might have been used if that was what was meant :-) also, the phrasing involving "perloading hash contexts" was confusing to me -- my image of a hash context comes from the source code of rfc 1321: MD5_CTX *context; /* context */ { context->count[0] = context->count[1] = 0; /* Load magic initialization constants. */ context->state[0] = 0x67452301; context->state[1] = 0xefcdab89; context->state[2] = 0x98badcfe; context->state[3] = 0x10325476; } this particular "context" doesn't appear to contain any octets from the message data to be hashed. is there a generally accepted definition for what constitutes a hash context? From owner-ietf-openpgp@mail.imc.org Mon May 15 17:37:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10406 for ; Mon, 15 May 2000 17:37:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04087 for ietf-openpgp-bks; Mon, 15 May 2000 14:06:59 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04083 for ; Mon, 15 May 2000 14:06:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id OAA01814; Mon, 15 May 2000 14:12:53 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id OAA01810; Mon, 15 May 2000 14:12:52 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000514122641B.1001@eccosys.com> References: <200005121215.IAA03777@finney.org> <20000514122641B.1001@eccosys.com> Date: Mon, 15 May 2000 13:53:36 -0700 To: sen_ml@eccosys.com, ietf-openpgp@imc.org From: Jon Callas Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'll look at clarifying the text. Jon From owner-ietf-openpgp@mail.imc.org Mon May 15 22:52:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15097 for ; Mon, 15 May 2000 22:52:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA26747 for ietf-openpgp-bks; Mon, 15 May 2000 19:34:17 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA26742 for ; Mon, 15 May 2000 19:34:13 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 17071 invoked from network); 16 May 2000 02:37:07 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 16 May 2000 02:37:07 -0000 To: ietf-openpgp@imc.org Subject: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: References: <200005121215.IAA03777@finney.org> <20000514122641B.1001@eccosys.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000516114038J.1001@eccosys.com> Date: Tue, 16 May 2000 11:40:38 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? Date: Mon, 15 May 2000 13:53:36 -0700 Message-ID: > I'll look at clarifying the text. thanks very much. i have some additional questions about the two subsequent sections. section 3.6.1.2 says: Salted S2K is exactly like Simple S2K, except that the input to the hash function(s) consists of the 8 octets of salt from the S2K specifier, followed by the passphrase. i presume this means that if the hash size is less than the key size, the method of utilizing multiple hash contexts and prepending octets of zeros described in 3.6.1.1 is employed. i assume that this also applies to iterated and salted s2k (section 3.6.1.3). if that is the case, suppose that the hash size is less than the key size: 1) for the second and subsequent hash context instances, do the octets of zeros get prepended to the salt: zero(s) + salt + passphrase or are the zeros prepended to the passphrase: salt + zero(s) + passphrase ? i presume it is the former, is that correct? 2) for iterated and salted s2k, is the calculated octet count value taken over all hash context instances or just the first instance? thanks. From owner-ietf-openpgp@mail.imc.org Mon May 15 23:58:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15905 for ; Mon, 15 May 2000 23:58:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA04051 for ietf-openpgp-bks; Mon, 15 May 2000 20:35:33 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04044 for ; Mon, 15 May 2000 20:35:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id UAA13745; Mon, 15 May 2000 20:41:58 -0400 Date: Mon, 15 May 2000 20:41:58 -0400 Message-Id: <200005160041.UAA13745@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > i have some additional questions about the two subsequent sections. section > 3.6.1.2 says: > > Salted S2K is exactly like Simple S2K, except that the input to the > hash function(s) consists of the 8 octets of salt from the S2K > specifier, followed by the passphrase. > > i presume this means that if the hash size is less than the key size, > the method of utilizing multiple hash contexts and prepending octets > of zeros described in 3.6.1.1 is employed. Yes. > i assume that this also applies to iterated and salted s2k (section 3.6.1.3). Yes. > if that is the case, suppose that the hash size is less than the key size: > > 1) for the second and subsequent hash context instances, do the octets > of zeros get prepended to the salt: > > zero(s) + salt + passphrase > > or are the zeros prepended to the passphrase: > > salt + zero(s) + passphrase > > ? i presume it is the former, is that correct? Yes. > 2) for iterated and salted s2k, is the calculated octet count value > taken over all hash context instances or just the first instance? The count is per-instance. Each instance is given a number of bytes of salt and passphrase, equal to the calculated octet count. The pre-loaded zeros are not included in this count. Hal From owner-ietf-openpgp@mail.imc.org Tue May 16 00:59:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16463 for ; Tue, 16 May 2000 00:59:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA07471 for ietf-openpgp-bks; Mon, 15 May 2000 21:38:21 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA07467 for ; Mon, 15 May 2000 21:38:19 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 19168 invoked from network); 16 May 2000 04:41:14 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 16 May 2000 04:41:14 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: <200005160041.UAA13745@finney.org> References: <200005160041.UAA13745@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000516134445F.1001@eccosys.com> Date: Tue, 16 May 2000 13:44:45 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 44 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Mon, 15 May 2000 20:41:58 -0400 Message-ID: <200005160041.UAA13745@finney.org> ... > > 2) for iterated and salted s2k, is the calculated octet count value > > taken over all hash context instances or just the first instance? > > The count is per-instance. i think i understand now. > Each instance is given a number of bytes of salt and passphrase, > equal to the calculated octet count. The pre-loaded zeros are not > included in this count. ok, i think i've got it -- below is an outline of my current understanding. for each hash context instance, the initial input is: zero(s) + salt + passphrase output from the hash, o1, is a fixed number of bytes, h. if the length of salt + passphrase in bytes is less than the calculated octet count, then o1 is given as input to the hash function which produces o2 (also length h). if the length of salt + passphrase + o1 is less than the calculated octet count, then o2 is given as input to the hash function and the process continues until the length of: salt + passphrase + o1 + ... + on is greater than or equal to the calculated octet count. also, none of o1, ..., on have octets of zeros prepended. is this correct? thanks again for the clarifications. From owner-ietf-openpgp@mail.imc.org Tue May 16 02:09:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28692 for ; Tue, 16 May 2000 02:09:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA13363 for ietf-openpgp-bks; Mon, 15 May 2000 22:44:55 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA13359 for ; Mon, 15 May 2000 22:44:53 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA14064; Mon, 15 May 2000 22:51:21 -0400 Date: Mon, 15 May 2000 22:51:21 -0400 Message-Id: <200005160251.WAA14064@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ok, i think i've got it -- below is an outline of my current understanding. > > for each hash context instance, the initial input is: > > zero(s) + salt + passphrase > > output from the hash, o1, is a fixed number of bytes, h. > > if the length of salt + passphrase in bytes is less than the > calculated octet count, then o1 is given as input to the hash > function which produces o2 (also length h). > > if the length of salt + passphrase + o1 is less than the calculated > octet count, then o2 is given as input to the hash function and the > process continues until the length of: > > salt + passphrase + o1 + ... + on > > is greater than or equal to the calculated octet count. > > also, none of o1, ..., on have octets of zeros prepended. > > is this correct? No, unfortunately this is not correct, although I can see that the "repeatedly hashed" language could be read this way. Actually what is input is: zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ... <--------------------- COUNT bytes -------------------------> and if COUNT (which is the computed octet count) is less than the length of salt + passphrase, we hash enough bytes so that we include the full salt + passphrase. Hal From owner-ietf-openpgp@mail.imc.org Tue May 16 02:53:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29014 for ; Tue, 16 May 2000 02:53:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA16151 for ietf-openpgp-bks; Mon, 15 May 2000 23:31:43 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA16147 for ; Mon, 15 May 2000 23:31:41 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 20974 invoked from network); 16 May 2000 06:34:36 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 16 May 2000 06:34:36 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: <200005160251.WAA14064@finney.org> References: <200005160251.WAA14064@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000516153807Y.1001@eccosys.com> Date: Tue, 16 May 2000 15:38:07 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Mon, 15 May 2000 22:51:21 -0400 Message-ID: <200005160251.WAA14064@finney.org> ... > > is this correct? > > No, unfortunately this is not correct, although I can see that the > "repeatedly hashed" language could be read this way. doh! perhaps another candidate for rewording :-) > Actually what is input is: > > zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ... > > <--------------------- COUNT bytes -------------------------> > > and if COUNT (which is the computed octet count) is less than the length > of salt + passphrase, we hash enough bytes so that we include the full > salt + passphrase. now i see the light! thanks again. From owner-ietf-openpgp@mail.imc.org Wed May 17 04:20:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01166 for ; Wed, 17 May 2000 04:20:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA07974 for ietf-openpgp-bks; Wed, 17 May 2000 00:48:26 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA07966 for ; Wed, 17 May 2000 00:48:23 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 17552 invoked from network); 17 May 2000 07:51:20 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 17 May 2000 07:51:20 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: <200005160251.WAA14064@finney.org> References: <200005160251.WAA14064@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000517165454U.1001@eccosys.com> Date: Wed, 17 May 2000 16:54:54 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit yet another clarifying question... From: hal@finney.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Mon, 15 May 2000 22:51:21 -0400 Message-ID: <200005160251.WAA14064@finney.org> > Actually what is input is: > > zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ... > > <--------------------- COUNT bytes -------------------------> > > and if COUNT (which is the computed octet count) is less than the length > of salt + passphrase, we hash enough bytes so that we include the full > salt + passphrase. what happens in the case where the computed octet count is: -not an integer multiple of the length of salt + passphrase and -greater than the length of salt + passphrase ? i presume that exactly "computed octet count" octets are handed to the message digest algorithm (+ message digest padding), and not an integer multiple number of instances of salt + passphrase. so the last octet before message digest padding would not be the last octet of the passphrase, as section 3.6.1.3 says: Then the salt, followed by the passphrase data is repeatedly hashed until the number of octets specified by the octet count has been hashed. The one exception is that if the octet count is less than the size of the salt plus passphrase, the full salt plus passphrase will be hashed even though that is greater than the octet count. is this correct? thanks again. From owner-ietf-openpgp@mail.imc.org Wed May 17 12:01:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07004 for ; Wed, 17 May 2000 12:01:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA01308 for ietf-openpgp-bks; Wed, 17 May 2000 08:31:36 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01302 for ; Wed, 17 May 2000 08:31:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA17677; Wed, 17 May 2000 08:39:08 -0700 Date: Wed, 17 May 2000 08:39:08 -0700 Message-Id: <200005171539.IAA17677@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > what happens in the case where the computed octet count is: > > -not an integer multiple of the length of salt + passphrase and > -greater than the length of salt + passphrase > > ? > > i presume that exactly "computed octet count" octets are handed to the > message digest algorithm (+ message digest padding), and not an > integer multiple number of instances of salt + passphrase. Yes. > so the last octet before message digest padding would not be the last > octet of the passphrase, as section 3.6.1.3 says: > > Then the salt, followed by the passphrase data is repeatedly hashed > until the number of octets specified by the octet count has been > hashed. The one exception is that if the octet count is less than > the size of the salt plus passphrase, the full salt plus passphrase > will be hashed even though that is greater than the octet count. > > is this correct? Yes, but I don't believe 3.6.1.3 says that the last octet before message digest padding would be the last octet of the passphrase. Hal From owner-ietf-openpgp@mail.imc.org Wed May 17 21:21:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13064 for ; Wed, 17 May 2000 21:21:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15847 for ietf-openpgp-bks; Wed, 17 May 2000 17:59:43 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA15834 for ; Wed, 17 May 2000 17:59:40 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 5220 invoked from network); 18 May 2000 01:02:38 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 18 May 2000 01:02:38 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: <200005171539.IAA17677@finney.org> References: <200005171539.IAA17677@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000518100613C.1001@eccosys.com> Date: Thu, 18 May 2000 10:06:13 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Wed, 17 May 2000 08:39:08 -0700 Message-ID: <200005171539.IAA17677@finney.org> > > so the last octet before message digest padding would not be the last > > octet of the passphrase, as section 3.6.1.3 says: > > > > Then the salt, followed by the passphrase data is repeatedly hashed > > until the number of octets specified by the octet count has been > > hashed. The one exception is that if the octet count is less than > > the size of the salt plus passphrase, the full salt plus passphrase > > will be hashed even though that is greater than the octet count. > > > > is this correct? > > Yes, but I don't believe 3.6.1.3 says that the last octet before message > digest padding would be the last octet of the passphrase. you are absolutely correct -- i agree that the section doesn't say that. the reason i asked this question was that since in the case where the computed octet count is less than the length of the salt + passphrase, the full salt + passphrase is hashed, one possible generalization for the cases where the computed octet count is greater than the length of the salt + passphrase would be to hash on salt + passphrase boundaries. what i found slightly ambiguous was the phrase: "until the number of ... has been hashed." i would probably not have been confused if the phrasing had been: "until exactly the number of ... has been hashed." thanks for the clarification. From owner-ietf-openpgp@mail.imc.org Thu May 18 23:23:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA17836 for ; Thu, 18 May 2000 23:23:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA24611 for ietf-openpgp-bks; Thu, 18 May 2000 19:57:30 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA24601 for ; Thu, 18 May 2000 19:57:27 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 813 invoked from network); 19 May 2000 03:00:27 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 May 2000 03:00:27 -0000 To: ietf-openpgp@imc.org Subject: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000519120406C.1001@eccosys.com> Date: Fri, 19 May 2000 12:04:06 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 66 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit here are some more clarification questions... -section 4.3 is titled "Packet Tags", and the term "packet tag" is used throughout, but strictly speaking, shouldn't that be "content tag" as per section 4.2? -section 5.2.3 describes the version 4 signature packet format. one of the fields is described as: Hashed subpacket data. (zero or more subpackets) what is meant by "hashed" here? are the contents of this field actual subpackets or hash(subpackets)? i presume it is the former and that "hashed" refers to the fact that the "hashed subpackets" field is included among the material that is hashed when a signature is computed. so "normally" the contents of the "hashed subpackets" field and the "unhashed subpackets" field should be identical, correct? if this is correct, i think it would be helpful to explicitly state that the contents of the "hashed supackets" field and the "unhashed subpackets" field are usually (should be?) the same. alternatively, perhaps the fields could be given different names? (actually, i think all fields should be named "bruce" to avoid confusion ;-P ) out of curiosity, why are the field contents repeated? -section 5.2.3.1 describes the signature subpacket specification. in the description of the subpacket header there is the following: - the subpacket type (1 octet) then, shortly after: The value of the subpacket type octet may be: 2 = signature creation time ... 100 to 110 = internal or user-defined however: Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error. i presume this means that the legal values (2, 3, 4, 5, 6, 7, etc.) listed for the subpacket type octet actually refer to bits 6 through 0 of the octet, and not that there haven't been any "critical subpacket types" defined yet. is this correct? if so, i think alternate wording would be less ambiguous. -section 5.2.3.3 has some notes on self-signatures. the following text appears therein: If the key is located by key id, then algorithm of the default user id of the key provides the default symmetric algorithm. the term "default user id" is used -- i failed to locate a definition for this term. could someone point out the definition in the specification or give one? thanks. From owner-ietf-openpgp@mail.imc.org Fri May 19 00:23:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18731 for ; Fri, 19 May 2000 00:23:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA01384 for ietf-openpgp-bks; Thu, 18 May 2000 20:52:37 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01377 for ; Thu, 18 May 2000 20:52:35 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id UAA21988; Thu, 18 May 2000 20:59:06 -0700 Date: Thu, 18 May 2000 20:58:58 -0700 (PDT) From: "L. Sassaman" To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) In-Reply-To: <20000519120406C.1001@eccosys.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 19 May 2000 sen_ml@eccosys.com wrote: > -section 5.2.3.3 has some notes on self-signatures. the following text > appears therein: > > If the key is located by key id, then algorithm of the default user id > of the key provides the default symmetric algorithm. > > the term "default user id" is used -- i failed to locate a definition for > this term. could someone point out the definition in the specification > or give one? I believe that "default user id" is synonymous with "primary user id". - From the current draft: 5.2.3.19. Primary user id (1 octet, boolean) This is a flag in a user id's self signature that states whether this user id is the main user id for this key. It is reasonable for an implementation to resolve ambiguities in preferences, etc. by referring to the primary user id. If this flag is absent, its value is zero. If more than one user id in a key is marked as primary, the implementation may resolve the ambiguity in any way it sees fit. - --Len. __ L. Sassaman System Administrator | "Everything must end; Technology Consultant | meanwhile we must icq.. 10735603 | amuse ourselves." pgp.. finger://ns.quickie.net/rabbi | --Voltaire -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5JLwJPYrxsgmsCmoRArtuAKCoOncD8T5mBJKQ/6zmOxntpXuAvQCgpJEm xkLx2Xi/Qy3puYUUWPfaVLk= =gAlL -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri May 19 01:09:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19531 for ; Fri, 19 May 2000 01:09:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA04669 for ietf-openpgp-bks; Thu, 18 May 2000 21:40:30 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA04660 for ; Thu, 18 May 2000 21:40:28 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id VAA22974; Thu, 18 May 2000 21:48:17 -0700 Date: Thu, 18 May 2000 21:48:17 -0700 Message-Id: <200005190448.VAA22974@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > here are some more clarification questions... > > -section 4.3 is titled "Packet Tags", and the term "packet tag" is used > throughout, but strictly speaking, shouldn't that be "content tag" as > per section 4.2? I'll let someone else worry about that... > -section 5.2.3 describes the version 4 signature packet format. one of the > fields is described as: > > Hashed subpacket data. (zero or more subpackets) > > what is meant by "hashed" here? are the contents of this field actual > subpackets or hash(subpackets)? i presume it is the former and that > "hashed" refers to the fact that the "hashed subpackets" field is included > among the material that is hashed when a signature is computed. Yes. > so "normally" the contents of the "hashed subpackets" field and the > "unhashed subpackets" field should be identical, correct? No. Some subpackets are hashed, while other ones are unhashed. The latter are not protected by the signature and would be considered "advisory", like hints about where to find the signing key. Currently we consider signing key id to be in that category. > -section 5.2.3.1 describes the signature subpacket specification. in > the description of the subpacket header there is the following: > > - the subpacket type (1 octet) > > then, shortly after: > > The value of the subpacket type octet may be: > > 2 = signature creation time > ... > 100 to 110 = internal or user-defined > > however: > > Bit 7 of the subpacket type is the "critical" bit. If set, it > denotes that the subpacket is one that is critical for the evaluator > of the signature to recognize. If a subpacket is encountered that > is marked critical but is unknown to the evaluating software, the > evaluator SHOULD consider the signature to be in error. > > i presume this means that the legal values (2, 3, 4, 5, 6, 7, etc.) listed > for the subpacket type octet actually refer to bits 6 through 0 of the > octet, and not that there haven't been any "critical subpacket types" defined > yet. is this correct? if so, i think alternate wording would be less > ambiguous. Yes, your interpretation is correct. > -section 5.2.3.3 has some notes on self-signatures. the following text > appears therein: > > If the key is located by key id, then algorithm of the default user id > of the key provides the default symmetric algorithm. > > the term "default user id" is used -- i failed to locate a definition for > this term. could someone point out the definition in the specification > or give one? The default user id is better known as the primary user id - the user id with a self-signature on it that includes the primary user id subpacket. Hal From owner-ietf-openpgp@mail.imc.org Fri May 19 01:13:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19976 for ; Fri, 19 May 2000 01:13:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA05801 for ietf-openpgp-bks; Thu, 18 May 2000 21:52:58 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA05794 for ; Thu, 18 May 2000 21:52:55 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 2749 invoked from network); 19 May 2000 04:55:57 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 May 2000 04:55:57 -0000 To: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) In-Reply-To: References: <20000519120406C.1001@eccosys.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000519135936P.1001@eccosys.com> Date: Fri, 19 May 2000 13:59:36 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: "L. Sassaman" Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) Date: Thu, 18 May 2000 20:58:58 -0700 (PDT) Message-ID: > I believe that "default user id" is synonymous with "primary user id". > > - From the current draft: > > 5.2.3.19. Primary user id > > (1 octet, boolean) > > This is a flag in a user id's self signature that states whether > this user id is the main user id for this key. It is reasonable for > an implementation to resolve ambiguities in preferences, etc. by > referring to the primary user id. If this flag is absent, its value > is zero. If more than one user id in a key is marked as primary, the > implementation may resolve the ambiguity in any way it sees fit. hmm...i don't get the impression that they are quite synonymous. section 5.2.3.2 uses the definite article (as in "the default user id"): If the key is located by key id, then [the] algorithm of the default user id of the key provides the default symmetric algorithm. i presume there is only one "default user id" -- that is, given a correct openpgp implementation, for any key (not packet, but entire key), the implementation should have some algorithm to decide what counts as the default user id. section 5.2.3.19 states that more than one user id in a key can be marked as primary and that the implementation may resolve the ambiguity in any way it sees fit. i presume this means that the implementation must choose a default user id, but it has the freedom to decide how this choosing is done. is that correct? From owner-ietf-openpgp@mail.imc.org Fri May 19 02:08:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01046 for ; Fri, 19 May 2000 02:08:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA09986 for ietf-openpgp-bks; Thu, 18 May 2000 22:47:00 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA09975 for ; Thu, 18 May 2000 22:46:58 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id WAA22727; Thu, 18 May 2000 22:53:36 -0700 Date: Thu, 18 May 2000 22:53:29 -0700 (PDT) From: "L. Sassaman" To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) In-Reply-To: <20000519135936P.1001@eccosys.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 19 May 2000 sen_ml@eccosys.com wrote: > section 5.2.3.2 uses the definite article (as in "the default user id"): > > If the key is located by key id, then [the] algorithm of the default user > id of the key provides the default symmetric algorithm. > > i presume there is only one "default user id" -- that is, given a > correct openpgp implementation, for any key (not packet, but entire > key), the implementation should have some algorithm to decide what > counts as the default user id. > > section 5.2.3.19 states that more than one user id in a key can be > marked as primary and that the implementation may resolve the > ambiguity in any way it sees fit. i presume this means that the > implementation must choose a default user id, but it has the freedom > to decide how this choosing is done. is that correct? Right. There is only one primary user id (or default user id) per key. More than one user id can have a self-sig with the primary user id bit set, but the implementation must in some way determine which is the "real" primary user id. I believe that checking the signature date, and picking the most recent, makes a lot of sense... but as the RFC says, it is up to the implementation. - --Len. __ L. Sassaman System Administrator | "Everything must end; Technology Consultant | meanwhile we must icq.. 10735603 | amuse ourselves." pgp.. finger://ns.quickie.net/rabbi | --Voltaire -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5JNbgPYrxsgmsCmoRAvOsAKDkbAPiACBSiMM+TZ5uJO4ug8DngQCfVEW+ LQDRfLb4VYgQv/YF5ByYgtM= =j5Mn -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon May 22 06:35:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28598 for ; Mon, 22 May 2000 06:35:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA13914 for ietf-openpgp-bks; Mon, 22 May 2000 03:00:54 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA13910 for ; Mon, 22 May 2000 03:00:52 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 7957 invoked from network); 22 May 2000 10:03:58 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 22 May 2000 10:03:58 -0000 To: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) In-Reply-To: <200005190448.VAA22974@finney.org> References: <200005190448.VAA22974@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000522190747D.1001@eccosys.com> Date: Mon, 22 May 2000 19:07:47 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) Date: Thu, 18 May 2000 21:48:17 -0700 Message-ID: <200005190448.VAA22974@finney.org> > > so "normally" the contents of the "hashed subpackets" field and the > > "unhashed subpackets" field should be identical, correct? > > No. Some subpackets are hashed, while other ones are unhashed. The > latter are not protected by the signature and would be considered > "advisory", like hints about where to find the signing key. Currently > we consider signing key id to be in that category. ok. so is the signing key id the only subpacket that is allowed to go in the unhashed area? also, for a given subpacket type, can instances of that subpacket appear in either the hashed subpacket field or the unhashed subpacket field, or is it a mutually exclusive situation? From owner-ietf-openpgp@mail.imc.org Mon May 22 07:10:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29262 for ; Mon, 22 May 2000 07:10:01 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA16846 for ietf-openpgp-bks; Mon, 22 May 2000 03:33:12 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA16841 for ; Mon, 22 May 2000 03:33:10 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 8701 invoked from network); 22 May 2000 10:36:18 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 22 May 2000 10:36:18 -0000 To: ietf-openpgp@imc.org Subject: minor typos/points? X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000522194007V.1001@eccosys.com> Date: Mon, 22 May 2000 19:40:07 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 131 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit below are some minor typos/points i came across. setion 5.2.1 says: 0x18: Subkey Binding Signature This signature is a statement by the top-level signing key indicates that it owns the subkey. shouldn't this be: 0x18: Subkey Binding Signature This signature is a statement by the top-level signing key indicating that it owns the subkey. ? section 5.2.4.1 says: An implementation SHOULD put the two mandatory subpackets, creation time and issuer, as the first subpackets in the subpacket list, simply to make it easier for the implementer to find them. but, section 5.2.3.4 says: 5.2.3.4. Issuer (8 octet key ID) The OpenPGP key ID of the key issuing the signature. and does not mention that the issuer subpacket is mandatory, while section 5.2.3.3 mentions that the signature creation time is mandatory and that it is present in the hashed area. i presume that 5.2.3.4 could read: 5.2.3.4. Issuer (8 octet key ID) The OpenPGP key ID of the key issuing the signature. MUST be present in the hashed area. section 5.3 says: Zero or more Encrypted Session Key packets and/or Symmetric-Key Encrypted Session Key packets may precede a Symmetrically Encrypted Data Packet that holds an encrypted message. does the phrase "more Encrypted Session Key packets" mean: more Public Key Encrypted Session Key packets ? section 5.6 says: Typically, this packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains literal data packets. does this mean that multiple contiguous literal data packets can be compressed into a compressed data packet? if so, how is an implementation supposed to interpret multiple literal data packets contained in a single compressed data packet? section 6 says: The checksum is a 24-bit CRC converted to four characters of radix-64 encoding shouldn't this be: The checksum is a 24-bit CRC converted to four characters of base64 encoding ? section 6.1 has: #define CRC24_POLY 0x1864cfbL should this not be: #define CRC24_POLY 0x864cfbL ? if not, shouldn't the constant listed in section 6: The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. be 0x1864CFB? section 11.2 says: A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet Tag, followed by the two-octet packet length, followed by the entire Public Key packet starting with the version field. strictly speaking, this seems to imply that only old packet format packets can be used. i presume that is not what is meant. how about the following wording: A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key packet (i.e. the entire packet header and all of the packet body fields). section 11.2 says: a.2) high order length octet of (b)-(f) (1 octet) a.3) low order length octet of (b)-(f) (1 octet) what does (f) refer to here? section 12.1 says: Note also that if an implementation does not implement the preference, then it is implicitly a TripleDES-only implementation. what does the phrase "the preference" refer to? does it mean if an implementation doesn't implement a system of preferences? section 12.7 says: We have reserver three algorithm IDs for the US NIST's Advanced i presume that should be: We have reserved three algorithm IDs for the US NIST's Advanced From owner-ietf-openpgp@mail.imc.org Mon May 22 07:55:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00248 for ; Mon, 22 May 2000 07:55:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA17830 for ietf-openpgp-bks; Mon, 22 May 2000 04:21:10 -0700 (PDT) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17826 for ; Mon, 22 May 2000 04:21:08 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialup27.ip.lu [208.161.253.27]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id NAA26333 for ; Mon, 22 May 2000 13:28:03 +0200 (CEST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 3E9C12ED3D; Mon, 22 May 2000 13:14:29 +0200 (CEST) Date: Mon, 22 May 2000 13:14:29 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: PGP/MIME: Time for last call? Message-ID: <20000522131429.A21039@sobolev.tlr-net.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.1i In-Reply-To: ; from ianbell@turnpike.com on Thu, May 11, 2000 at 09:44:28AM +0100 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-05-11 09:44:28 +0100, Ian Bell wrote: > 1) Simply state the problem, and indicate that for > one-pass processing, two hashes will have to be > prepared - one for binary-mode signatures and one > for text-mode signatures. > 2) Mandate which form of signature must be used. > Trailing spaces are often significant in email/news > (sig-seps, RFC2646), so a binary-mode signature > might seem preferable. However, existing PGP/MIME > clients may be using either. > 3) Define a "pgp-mode" parameter, pgp-mode=binary or > pgp-mode=text and ensure that new clients add the > parameter to the multipart/signed header. If the > parameter is missing (RFC2015 messages), then > one-pass clients will have to prepare two hashes. Well... As a fourth possibility, we could mandate that any trailing whitespace within body parts should lead to the use of quoted-printable or base64, thus effectively working around the problem. However, this is _not_ currently mandated by RFC 1847. Actually, doing this is suggested in one of the example messages, but for different reasons. -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Mon May 22 12:03:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04324 for ; Mon, 22 May 2000 12:03:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24421 for ietf-openpgp-bks; Mon, 22 May 2000 08:37:19 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24417 for ; Mon, 22 May 2000 08:37:18 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA01241; Mon, 22 May 2000 08:45:29 -0700 Date: Mon, 22 May 2000 08:45:29 -0700 Message-Id: <200005221545.IAA01241@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: minor typos/points? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > 5.2.3.4. Issuer > > (8 octet key ID) > > The OpenPGP key ID of the key issuing the signature. > > MUST be present in the hashed area. keyid can be unhashed. I'm not sure it makes sense to have a mandatory unhashed packet, since unhased packets can have no security properties. > section 5.6 says: > > Typically, this packet is found as the contents of an encrypted packet, > or following a Signature or One-Pass Signature packet, and contains > literal data packets. > > does this mean that multiple contiguous literal data packets can be > compressed into a compressed data packet? if so, how is an > implementation supposed to interpret multiple literal data packets > contained in a single compressed data packet? This is an area of ambiguity we have run into. Can you put multiple literal data packets into compressed or encrypted data? Can they be inside/after signature packets? My feeling is that it should be allowed. Literal packets can have file names associated with them and so this would be an efficient mechanism for transferring multiple files. I don't know what the current implementations do. > section 6.1 has: > > #define CRC24_POLY 0x1864cfbL > > should this not be: > > #define CRC24_POLY 0x864cfbL Not if you want the code to work... note the line where that constant is used, the high "1" is used to clear a "1" in the crc variable. > section 11.2 says: > > A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet > Tag, followed by the two-octet packet length, followed by the entire > Public Key packet starting with the version field. > > strictly speaking, this seems to imply that only old packet format packets > can be used. i presume that is not what is meant. how about the following > wording: > > A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key > packet (i.e. the entire packet header and all of the packet body fields). No, it has to be a two byte length. The length must be canonicalized to two bytes. Otherwise there may be ambiguity in that the same length can be expressed in different forms. > section 11.2 says: > > a.2) high order length octet of (b)-(f) (1 octet) > > a.3) low order length octet of (b)-(f) (1 octet) > > what does (f) refer to here? Should be (e). > section 12.1 says: > > Note also that if an implementation does not implement the preference, > then it is implicitly a TripleDES-only implementation. > > what does the phrase "the preference" refer to? does it mean if an > implementation doesn't implement a system of preferences? More specifically, that it doesn't support the preferred algorithm subpacket. It doesn't create them, it doesn't read them. It should always use triple des. Hal From owner-ietf-openpgp@mail.imc.org Mon May 22 12:04:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04345 for ; Mon, 22 May 2000 12:04:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24211 for ietf-openpgp-bks; Mon, 22 May 2000 08:28:27 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24207 for ; Mon, 22 May 2000 08:28:26 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA01210; Mon, 22 May 2000 08:36:36 -0700 Date: Mon, 22 May 2000 08:36:36 -0700 Message-Id: <200005221536.IAA01210@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > so is the signing key id the only subpacket that is allowed to go in > the unhashed area? No, anything which might reasonably be considered to be "advisory" and not security critical could go there. For example the URL where the cert can be found. I don't know if there is an exhaustive list. The point is that the software needs to be aware that material in the unhashed region is not authenticated and could have been tampered with. > also, for a given subpacket type, can instances of > that subpacket appear in either the hashed subpacket field or the > unhashed subpacket field, or is it a mutually exclusive situation? I don't see any problem in allowing that. Hal From owner-ietf-openpgp@mail.imc.org Mon May 22 23:35:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15042 for ; Mon, 22 May 2000 23:35:01 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA27718 for ietf-openpgp-bks; Mon, 22 May 2000 20:09:38 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA27710 for ; Mon, 22 May 2000 20:09:35 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 2380 invoked from network); 23 May 2000 03:12:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 23 May 2000 03:12:45 -0000 To: ietf-openpgp@imc.org Subject: Re: minor typos/points? In-Reply-To: <200005221545.IAA01241@finney.org> References: <200005221545.IAA01241@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000523121635R.1001@eccosys.com> Date: Tue, 23 May 2000 12:16:35 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 115 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: minor typos/points? Date: Mon, 22 May 2000 08:45:29 -0700 Message-ID: <200005221545.IAA01241@finney.org> > > 5.2.3.4. Issuer > > > > (8 octet key ID) > > > > The OpenPGP key ID of the key issuing the signature. > > > > MUST be present in the hashed area. > > keyid can be unhashed. I'm not sure it makes sense to have a mandatory > unhashed packet, since unhased packets can have no security properties. so, the issuer subpacket should not be mandatory then? > > section 5.6 says: > > > > Typically, this packet is found as the contents of an encrypted packet, > > or following a Signature or One-Pass Signature packet, and contains > > literal data packets. > > > > does this mean that multiple contiguous literal data packets can be > > compressed into a compressed data packet? if so, how is an > > implementation supposed to interpret multiple literal data packets > > contained in a single compressed data packet? > > This is an area of ambiguity we have run into. Can you put multiple > literal data packets into compressed or encrypted data? Can they be > inside/after signature packets? > > My feeling is that it should be allowed. Literal packets can have file > names associated with them and so this would be an efficient mechanism > for transferring multiple files. I don't know what the current > implementations do. i wonder about how well this would work w/ mime. for mail situations, i wonder whether it wouldn't be simpler and easier for users and implementors to either tar or zip up multiple files as a single file or to attach multiple files. for situations where the data is being processed directly by an openpgp implementation, processing multiple contiguous literal data packets seems fine...but openpgp and zip seem to be merging :-) > > section 6.1 has: > > > > #define CRC24_POLY 0x1864cfbL > > > > should this not be: > > > > #define CRC24_POLY 0x864cfbL > > Not if you want the code to work... doh! > note the line where that constant is used, the high "1" is used to > clear a "1" in the crc variable. how about the following code then? i think it would make the text and the code eaiser to understand and thus help prevent the question that i asked from being asked again in the future (hopefully, it wouldn't generate additional ones). #define CRC24_GENERATOR 0x864cfbL #define CRC24_POLY (CRC24_GENERATOR | 0x1000000L) > > section 11.2 says: > > > > A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet > > Tag, followed by the two-octet packet length, followed by the entire > > Public Key packet starting with the version field. > > > > strictly speaking, this seems to imply that only old packet format packets > > can be used. i presume that is not what is meant. how about the following > > wording: > > > > A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key > > packet (i.e. the entire packet header and all of the packet body fields). > > No, it has to be a two byte length. The length must be canonicalized > to two bytes. Otherwise there may be ambiguity in that the same length > can be expressed in different forms. ok i understand. i see i was completely off regarding the old format packets. how about adding an explicit note in the rfc noting that the length must be canonicalized to two bytes to prevent ambiguity in expressing a particular length? i presume that two-octet lengths are sufficient for all the relevant key sizes... i keep wondering why there are even one-octet and two-octet lengths in new format packets. it seems far simpler to just have five-octet and partial lengths. are there significant advantages to having one- and two-octet lengths? > > section 12.1 says: > > > > Note also that if an implementation does not implement the preference, > > then it is implicitly a TripleDES-only implementation. > > > > what does the phrase "the preference" refer to? does it mean if an > > implementation doesn't implement a system of preferences? > > More specifically, that it doesn't support the preferred algorithm > subpacket. It doesn't create them, it doesn't read them. It should > always use triple des. thanks for the clarification. From owner-ietf-openpgp@mail.imc.org Tue May 23 04:57:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28589 for ; Tue, 23 May 2000 04:57:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA06430 for ietf-openpgp-bks; Tue, 23 May 2000 01:27:35 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06423 for ; Tue, 23 May 2000 01:27:33 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA17057; Tue, 23 May 2000 09:34:22 +0100 (BST) Message-ID: Date: Tue, 23 May 2000 09:31:21 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME: Time for last call? References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> <20000522131429.A21039@sobolev.tlr-net.does-not-exist.org> In-Reply-To: <20000522131429.A21039@sobolev.tlr-net.does-not-exist.org> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 May 2000, Thomas Roessler wrote: >On 2000-05-11 09:44:28 +0100, Ian Bell wrote: > >> 1) Simply state the problem, and indicate that for >> one-pass processing, two hashes will have to be >> prepared - one for binary-mode signatures and one >> for text-mode signatures. > >> 2) Mandate which form of signature must be used. >> Trailing spaces are often significant in email/news >> (sig-seps, RFC2646), so a binary-mode signature >> might seem preferable. However, existing PGP/MIME >> clients may be using either. > >> 3) Define a "pgp-mode" parameter, pgp-mode=binary or >> pgp-mode=text and ensure that new clients add the >> parameter to the multipart/signed header. If the >> parameter is missing (RFC2015 messages), then >> one-pass clients will have to prepare two hashes. > >Well... As a fourth possibility, we could mandate that >any trailing whitespace within body parts should lead to >the use of quoted-printable or base64, thus effectively >working around the problem. However, this is _not_ >currently mandated by RFC 1847. Mandating quoted-printable just as a workround for a sig-mode problem seems a little of a kludge - 3) still seems to me the solution that fits best with the aims of RFC1847. [However, Turnpike already forces its PGP-signed messages into quoted-printable so that trailing-space corruption and Berkeley-From corruption problems are avoided] -- Ian Bell T U R N P I K E Ltd From owner-ietf-openpgp@mail.imc.org Wed May 24 04:09:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01024 for ; Wed, 24 May 2000 04:09:14 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA06826 for ietf-openpgp-bks; Wed, 24 May 2000 00:38:38 -0700 (PDT) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06822 for ; Wed, 24 May 2000 00:38:35 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialup16.ip.lu [208.161.253.16]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id JAA09590 for ; Wed, 24 May 2000 09:45:40 +0200 (CEST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id F3ACE2ED3D; Wed, 24 May 2000 09:43:06 +0200 (CEST) Date: Wed, 24 May 2000 09:43:06 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: FYI: Key Generation Security Flaw in PGP 5.0 Message-ID: <20000524094306.D8916@sobolev.tlr-net.does-not-exist.org> Reply-To: gec@acm.org, roessler@guug.de, ietf-openpgp@imc.org Mail-Followup-To: ietf-openpgp@imc.org, gec@acm.org, roessler@guug.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.1i In-Reply-To: <20000523141323.A28431@olymp.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA06823 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit ----- Forwarded message from gec@acm.org ----- Date: Tue, 23 May 2000 14:13:23 -0700 From: gec@acm.org To: undisclosed-recipients: ; Subject: Key Generation Security Flaw in PGP 5.0 Reply-To: gec@acm.org, roessler@guug.de Mail-Followup-To: gec@acm.org, roessler@guug.de SECURITY FLAW IN PGP 5.0 ======================== EXECUTIVE SUMMARY ----------------- A flaw has been found in the randomness gathering code of PGP 5. PGP 5 will, under certain well-defined circumstances, generate public/private key pairs with no or only a small amount of randomness. Such keys are insecure. Chances are very high that you have no problem. So, don't panic. WHO IS AFFECTED? ---------------- The flaw has been found in the PGP 5.0i code base. It is specific to Unix systems such as Linux or various BSD dialects with a /dev/random device. Versions 2.* and 6.5 of PGP do NOT share this problem. PGP versions ported to other platforms do NOT share this problem. The problem does NOT manifest itself under the following circumstances: - You typed in a lot of data while generating your key, including long user ID and pass phrase strings. - A random seed file PGP 5 could use existed on your system before you generated the key. However, the problem affects you in the worst possible manner if you started from scratch with pgp 5 on a Unix system with a /dev/random device, and created your key pair non-interactively with a command line like this one: pgpk -g WHAT TO DO? ----------- If you have generated your key non-interactively, you may wish to revoke it, and create a new key using a version of PGP which works correctly. DETAILS ------- In order to generate secure cryptographic keys, PGP needs to gather random numbers from reliable sources, so keys can't be predicted by attackers. Randomness sources PGP generally uses include: - a seed file with random data from previous sessions - user input and input timing Additionally, certain Unix systems such as OpenBSD, Linux, and others, offer a stream of random data over a central service typically called /dev/random or the like. If present, this service is used by PGP as a source of random data. PGP 5.0i's reading of these random numbers does not work. Instead of random numbers, a stream of bytes with the value "1" is read. In practice, this implies two things: 1. PGP5 will generally overestimate the amount of randomness available. We have not researched the effects of this in detail. However, we believe that the amount of randomness gathered from input data, timing information, and old random data will be sufficient for most applications. (See below for a detailed estimate.) 2. In situations in which no other randomness sources are available, PGP relies on the /dev/random service, and thus uses predictable instead of random numbers. This is not a flaw of the random service, but of the PGP5 implementation. One particular example of such a situation is non-interactive key generation with a virgin PGP 5 installation, like described above. Example: $ mkdir /tmp/pgp5test $ PGPPATH=/tmp/pgp5test $ pgpk -g RSA 1024 foo@bar.com 0 "passphrase string" In fact, RSA keys generated this way are entirely predictable, which can easily be verified by comparing key IDs and fingerprints. When using DSA/ElGamal keys, the DSA signature key is predictable, while the ElGamal encryption subkey will vary. Note that fingerprints and key IDs of the predictable DSA keys depend on a time stamp, and are themselves not predictable. Proof of concept key rings generated with pgp 5.0i are available from . GORY DETAILS ------------ 1. Code Here's the flawed code from src/lib/ttyui/pgpUserIO.c: 1314 static unsigned 1315 pgpDevRandomAccum(int fd, unsigned count) 1316 { 1317 char RandBuf; 1318 unsigned short i = 0; 1319 1320 pgpAssert(count); 1321 pgpAssert(fd >= 0); 1322 1323 for(i = 0; i <= count; ++i) { >1324 RandBuf = read(fd, &RandBuf, count); 1325 pgpRandomAddBytes(&pgpRandomPool, (byte *)&RandBuf, sizeof(RandBuf)); 1326 pgpRandPoolAddEntropy(256); 1327 } 1328 1329 return(i); 1330 } The count parameter is always set to the value 1 by the calling code. The byte read from the file descriptor fd into the RandBuf buffer is subsequently overwritten with the read() function's return value, which will be 1. The actual random data are not used. This can be fixed by replacing line 1324 by the following line of code: read (fd, &RandBuf, 1); 2. "Random" data A dump of random data gathered during an interactive key generation session is available at . This was dumped as passed to the pgpRandomAddByte() function, one byte at a time. Note the streams of bytes with the value 1 which should actually contain data gathered from /dev/random. Also note that the pass phrase ("asdf") and the user ID ("roessler@guug.de") are clearly visible, but mixed with timing data from the individual key presses. No random data occuring after the second stream of ones were generated from external events prior to the generation of the DSA key in question. 3. Some estimates We give a back-of-the-envelope upper estimate of the amount of random bits PGP may gather during interactive key generation. We assume that /dev/random reading is flawed, and that no seed file exists prior to running PGP. Timing is assumed to have a resolution of 1 us (gettimeofday()). During a PGP session of one minute, we can get at most 2^28 different time stamps (2^28 ~ 60*10^6). Note that one time stamp close to the point of time of key generation is known to attackers from the time stamp PGP leaves on the key. So the intervals between individual key presses remain as a source of randomness. Assuming that the user types at a rate of about 120 characters per minute, we have an interval of approximately 0.5 seconds between two key presses. Dropping the upmost non-random bit of the interval length, we get about 18 bits of random timing information per key press. This estimate gets worse for experienced and fast-typing users. With a user ID of 20 characters, and no pass phrase, PGP will have gathered roughly 300-400 random bits interactively. While this is not bad, it is not sufficient by PGP's own standards. CONCLUSIONS ----------- Public code review is a good thing - if it happens. CREDITS ------- This problem was found by Germano Caronni , and verified by Thomas Roessler and Marcel Waldvogel . ----- End forwarded message ----- From owner-ietf-openpgp@mail.imc.org Wed May 24 12:39:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08788 for ; Wed, 24 May 2000 12:39:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01479 for ietf-openpgp-bks; Wed, 24 May 2000 09:11:40 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01475 for ; Wed, 24 May 2000 09:11:35 -0700 (PDT) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id MAA01021; Wed, 24 May 2000 12:18:44 -0400 (EDT) Received: from [208.192.101.191] (ppp0b191.std.com [208.192.101.191]) by world.std.com (8.9.3/8.9.3) with ESMTP id MAA17667; Wed, 24 May 2000 12:14:31 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 May 2000 12:14:36 -0400 To: gec@acm.org, roessler@guug.de, mwa@arl.wustl.edu From: Don Davis Subject: Key Generation Security Flaw in PGP 5.0 Cc: ietf-openpgp@imc.org, dtd@world.std.com, Dan Geer Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So the intervals between individual key presses remain as a source > of randomness. > Assuming that the user types at a rate of about 120 characters per > minute, we have an interval of approximately 0.5 seconds between two > key presses. Dropping the upmost non-random bit of the interval > length, we get about 18 bits of random timing information per key > press. i'm sorry, but i think your estimate here is badly flawed. you seem to assume that keyboard-timings come in microsecond-scale resolutions. it turns out, though, that keyboard controllers check the keyboard for input only every few milliseconds (10 msec, if i remember correctly). thus, your keyboard-timings come in hundredth-sec increments, and you get at most 6 or 7 bits of variability per keystroke. further. these timings are not uniformly distributed, but probably show a normal distribution centered at, say, 500 msec. my guess is you're getting only 3 or 4 bits of entropy per keystroke, at most. i can calculate the entropy more precisely, if you want. > This estimate gets worse for experienced and > fast-typing users. much worse, because their keystroke timings will be highly correlated with the textual content. english text carries only around 1 bit of entropy per character. i congratulate you upon your discovery, and i thank you for your diligence. fwiw, i'm the author of a paper about extracting randomness from disk timings, which appeared at crypto '94, and which is cited in rfc 1750 "recommendations for randomness." - don davis http://world.std.com/~dtd - From owner-ietf-openpgp@mail.imc.org Thu May 25 08:49:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02003 for ; Thu, 25 May 2000 08:48:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA06278 for ietf-openpgp-bks; Thu, 25 May 2000 05:18:28 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06269 for ; Thu, 25 May 2000 05:18:26 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id IAA27315; Thu, 25 May 2000 08:24:31 -0400 Message-Id: <200005251224.IAA27315@domains.invweb.net> From: "William H. Geiger III" Date: Tue, 23 May 2000 07:40:44 -0500 To: sen_ml@eccosys.com In-Reply-To: <20000523121635R.1001@eccosys.com> Cc: ietf-openpgp@imc.org Subject: Re: minor typos/points? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20000523121635R.1001@eccosys.com>, on 05/22/00 at 09:16 PM, sen_ml@eccosys.com said: >> This is an area of ambiguity we have run into. Can you put multiple >> literal data packets into compressed or encrypted data? Can they be >> inside/after signature packets? >> >> My feeling is that it should be allowed. Literal packets can have file >> names associated with them and so this would be an efficient mechanism >> for transferring multiple files. I don't know what the current >> implementations do. >i wonder about how well this would work w/ mime. for mail situations, i >wonder whether it wouldn't be simpler and easier for users and >implementors to either tar or zip up multiple files as a single file or >to attach multiple files. >for situations where the data is being processed directly by an openpgp >implementation, processing multiple contiguous literal data packets seems >fine...but openpgp and zip seem to be merging :-) I always make it a practice to zip even individual files *before* encryption and sending. Zip seems better at dealing with file system issues better than PGP is (CRLF<->LF conversions, preserving EA's, ...ect). -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Thu May 25 08:49:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02088 for ; Thu, 25 May 2000 08:49:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA06279 for ietf-openpgp-bks; Thu, 25 May 2000 05:18:29 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06274 for ; Thu, 25 May 2000 05:18:27 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id IAA27413; Thu, 25 May 2000 08:25:29 -0400 Message-Id: <200005251225.IAA27413@domains.invweb.net> From: "William H. Geiger III" Date: Tue, 23 May 2000 07:29:01 -0500 To: hal@finney.org In-Reply-To: <200005221536.IAA01210@finney.org> Cc: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1 X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <200005221536.IAA01210@finney.org>, on 05/22/00 at 09:36 AM, hal@finney.org said: >> so is the signing key id the only subpacket that is allowed to go in >> the unhashed area? >No, anything which might reasonably be considered to be "advisory" and >not security critical could go there. For example the URL where the cert >can be found. I don't know if there is an exhaustive list. The point is >that the software needs to be aware that material in the unhashed region >is not authenticated and could have been tampered with. >> also, for a given subpacket type, can instances of >> that subpacket appear in either the hashed subpacket field or the >> unhashed subpacket field, or is it a mutually exclusive situation? >I don't see any problem in allowing that. As an open question to list members: What do you consider the proper response of OpenPGP software (client & server) when an established key (ie a key on the server or users keyring) is "updated" and unhashed data has been changed? Take the example: Software A lets the user enter on his key the prefered URL to obtain his key on the self-sig for his key and the software stores it in an unhashed subpacket. The user distributes his key (other users, servers, ...ect). Software A also allows the user to change this at a later date without creating a new signature. The user distributes this "updated" key. How should the receiving software treat this "updated" data? -- Ignore the "new" data -- Accept the "new" data in place of the old data -- Notify the receiver that there is "new" data and let him decide -- ....? -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Thu May 25 13:04:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13909 for ; Thu, 25 May 2000 13:04:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14933 for ietf-openpgp-bks; Thu, 25 May 2000 09:37:06 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14929 for ; Thu, 25 May 2000 09:37:05 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA11926 for ietf-openpgp@imc.org; Thu, 25 May 2000 09:45:24 -0700 Date: Thu, 25 May 2000 09:45:24 -0700 Message-Id: <200005251645.JAA11926@finney.org> To: ietf-openpgp@imc.org Subject: KeyID as left vs right substring of fingerprint Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Currently in V4 keys, the keyid is defined to be the rightmost 64 bits of the fingerprint. Phil Zimmermann has often complained about this and expressed the opinion that this was a blunder, and that we should have chosen the leftmost bits rather than the rightmost bits. He says that this would facilitate a generalization of the keyid to be the leftmost N bits of the fingerprint. N could be as long as the entire fingerprint, to have an essentially unambiguous pointer to a given key. Or N could be short, just a few bits, to have a nearly-"anonymous" key, where the set of possible keys was understood by all parties to be very small. He also suggests that this would facilitate going to a key server storage model where a length-N keyid was the index. N could be shorter or longer, and by using left substrings rather than right, he says that the server would have an easier time adapting to the variable length indexes. PGP 7.0, to be released shortly, will allow creation of V4 RSA keys for the first time. These will use the hash method to derive the fingerprint and keyid, as with other V4 keys. Phil proposed to me that we change the keyid calculation for these keys to use a left substring of the fingerprint rather than the right substring. More generally, all new key types would use left substrings. The only keys that used right substrings would be "legacy" DSA and ElGamal keys (assuming that no one else has implemented RSA V4 keys, which I am not sure about). We might do some kind of upgrade to DSA keys when the new larger hash is announced later this year, and they could switch at that time. Maybe some arbitrary change could be made to ElGamal as well. I will refrain from giving my own opinion about this idea, its justification, its timing, and its impact. Input from others is welcome. Hal From owner-ietf-openpgp@mail.imc.org Thu May 25 20:23:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23388 for ; Thu, 25 May 2000 20:23:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA21942 for ietf-openpgp-bks; Thu, 25 May 2000 16:42:39 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA21938 for ; Thu, 25 May 2000 16:42:37 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 12849 invoked from network); 25 May 2000 23:45:52 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 25 May 2000 23:45:52 -0000 To: ietf-openpgp@imc.org Subject: Re: minor typos/points? In-Reply-To: <200005251224.IAA27315@domains.invweb.net> References: <20000523121635R.1001@eccosys.com> <200005251224.IAA27315@domains.invweb.net> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000526084953D.1001@eccosys.com> Date: Fri, 26 May 2000 08:49:53 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 12 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: "William H. Geiger III" Subject: Re: minor typos/points? Date: Tue, 23 May 2000 07:40:44 -0500 Message-ID: <200005251224.IAA27315@domains.invweb.net> > I always make it a practice to zip even individual files *before* > encryption and sending. Zip seems better at dealing with file system > issues better than PGP is (CRLF<->LF conversions, preserving EA's, > ...ect). i would be interested in seeing concrete examples demonstrating the differences. can you provide any? From owner-ietf-openpgp@mail.imc.org Thu May 25 20:25:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23403 for ; Thu, 25 May 2000 20:25:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA22009 for ietf-openpgp-bks; Thu, 25 May 2000 16:48:07 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA22005 for ; Thu, 25 May 2000 16:48:06 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 13006 invoked from network); 25 May 2000 23:51:21 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 25 May 2000 23:51:21 -0000 To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: <200005251645.JAA11926@finney.org> References: <200005251645.JAA11926@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000526085522K.1001@eccosys.com> Date: Fri, 26 May 2000 08:55:22 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: KeyID as left vs right substring of fingerprint Date: Thu, 25 May 2000 09:45:24 -0700 Message-ID: <200005251645.JAA11926@finney.org> > Currently in V4 keys, the keyid is defined to be the rightmost 64 bits > of the fingerprint. Phil Zimmermann has often complained about this > and expressed the opinion that this was a blunder, and that we should > have chosen the leftmost bits rather than the rightmost bits. is the idea of giving the leftmost N bits a name other than "keyid" doable? then both concepts can continue to exist and "keyid" can be deprecated. some names that came to mind (in no particular order): left keyid, lkeyid, general keyid, revised keyid From owner-ietf-openpgp@mail.imc.org Thu May 25 20:55:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23645 for ; Thu, 25 May 2000 20:55:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA22479 for ietf-openpgp-bks; Thu, 25 May 2000 17:21:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22475 for ; Thu, 25 May 2000 17:21:56 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA23478; Thu, 25 May 2000 17:28:43 -0700 (PDT) Received: from [63.73.97.188] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA23474; Thu, 25 May 2000 17:28:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200005251645.JAA11926@finney.org> References: <200005251645.JAA11926@finney.org> Date: Thu, 25 May 2000 17:28:41 -0700 To: hal@finney.org, ietf-openpgp@imc.org From: Jon Callas Subject: Re: KeyID as left vs right substring of fingerprint Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree that in retrospect, it would have been better to have the key id be the high-order bits of the fingerprint rather than the low-order bits. I, too, think this was a mistake. However, that decision was made before this working group was formed. (And before I joined PGP, Inc. for that matter.) I believe that changing this and making it be dependent on the algorithm type would be utterly wrong. It would add one more little gnarly bit into a system that is already filled with too many gnarly bits. If this blunder needs to be fixed, the correct way to fix it is to make a V5 key structure. (For that matter, there are a couple other things I'd fix, too, if we made a V5 key structure.) However, I think that as unfortunate as this is, simplicity and compatibility override aesthetics, and we should just live with things as they are. Jon From owner-ietf-openpgp@mail.imc.org Fri May 26 02:35:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA10757 for ; Fri, 26 May 2000 02:35:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA00541 for ietf-openpgp-bks; Thu, 25 May 2000 23:00:41 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA00535 for ; Thu, 25 May 2000 23:00:38 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 26185 invoked from network); 26 May 2000 06:03:54 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 26 May 2000 06:03:54 -0000 To: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1 In-Reply-To: <200005251225.IAA27413@domains.invweb.net> References: <200005221536.IAA01210@finney.org> <200005251225.IAA27413@domains.invweb.net> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000526150754Z.1001@eccosys.com> Date: Fri, 26 May 2000 15:07:54 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: "William H. Geiger III" Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1 Date: Tue, 23 May 2000 07:29:01 -0500 Message-ID: <200005251225.IAA27413@domains.invweb.net> ... > As an open question to list members: > > What do you consider the proper response of OpenPGP software (client & > server) when an established key (ie a key on the server or users keyring) > is "updated" and unhashed data has been changed? it seems to me that this might be handled in a number of ways depending on the particular situation: -determined by "local" policy (the client or server has a policy which it follows) -determined by "key" policy (a policy is determined from some signed portion of the key) From owner-ietf-openpgp@mail.imc.org Fri May 26 04:03:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11202 for ; Fri, 26 May 2000 04:03:20 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA04321 for ietf-openpgp-bks; Fri, 26 May 2000 00:28:28 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04316 for ; Fri, 26 May 2000 00:28:26 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA31411; Fri, 26 May 2000 00:35:39 -0700 Date: Fri, 26 May 2000 00:35:31 -0700 (PDT) From: "L. Sassaman" To: hal@finney.org, prz@pgp.com cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: <200005251645.JAA11926@finney.org> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with Phil on this point. As it stands right now, we have only two types of keys in use: v3 RSA and v4 DSA/ElG keys. (I am ignoring ElGamal signing keys since I don't see anyone using them on any significant scale). Presently, both of the key types obtain their keyid in different ways, and there haven't been any problems with that. Granted, changing the scheme once again for obtaining the keyid would add confusion to the spec, but I think that obtaining the keyid from the left of the fingerprint would add considerable benefit. In fact, if we were to do it this way, the fingerprint itself would become the keyid, and users or implementations could provide as much or as little of the fingerprint as was determined necessary for a unique match. This would also allow for cases where a unique match was not desirable, such as anonymous communication where the user did not wish to have the key id of the recipient visible in the encrypted blob, but wished to provide a "hint" to the recipient as to which key it was encrypted. This would be useful for those with several private keys on the same keyring. A "v5" signature format would probably be the cleanest way to go (and then we could possibly convert all existing keys to v5 as well), but we run into backward compatability problems. As for other implementations using RSA v4 keys, I know that GnuPG doesn't generate them (though I provided Werner with an RSA v4 test keypair a while back). Thoughts? - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol On Thu, 25 May 2000 hal@finney.org wrote: > Currently in V4 keys, the keyid is defined to be the rightmost 64 bits > of the fingerprint. Phil Zimmermann has often complained about this > and expressed the opinion that this was a blunder, and that we should > have chosen the leftmost bits rather than the rightmost bits. > > He says that this would facilitate a generalization of the keyid to be > the leftmost N bits of the fingerprint. N could be as long as the entire > fingerprint, to have an essentially unambiguous pointer to a given key. > Or N could be short, just a few bits, to have a nearly-"anonymous" > key, where the set of possible keys was understood by all parties to be > very small. > > He also suggests that this would facilitate going to a key server storage > model where a length-N keyid was the index. N could be shorter or longer, > and by using left substrings rather than right, he says that the server > would have an easier time adapting to the variable length indexes. > > PGP 7.0, to be released shortly, will allow creation of V4 RSA keys for > the first time. These will use the hash method to derive the fingerprint > and keyid, as with other V4 keys. > > Phil proposed to me that we change the keyid calculation for these keys to > use a left substring of the fingerprint rather than the right substring. > More generally, all new key types would use left substrings. > > The only keys that used right substrings would be "legacy" DSA and ElGamal > keys (assuming that no one else has implemented RSA V4 keys, which I am > not sure about). We might do some kind of upgrade to DSA keys when the > new larger hash is announced later this year, and they could switch at > that time. Maybe some arbitrary change could be made to ElGamal as well. > > I will refrain from giving my own opinion about this idea, its > justification, its timing, and its impact. Input from others is welcome. > > Hal > -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LilKPYrxsgmsCmoRArpAAKD73N8R6ahvOJ55v74Vp+4jPQTbbACcDFD0 TnmWYi+DCFu2l4FDDcP+Vss= =0nwl -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri May 26 04:15:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11269 for ; Fri, 26 May 2000 04:15:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA04942 for ietf-openpgp-bks; Fri, 26 May 2000 00:38:13 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04936 for ; Fri, 26 May 2000 00:38:12 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA31449; Fri, 26 May 2000 00:45:23 -0700 Date: Fri, 26 May 2000 00:45:14 -0700 (PDT) From: "L. Sassaman" To: Jon Callas cc: hal@finney.org, marc@mit.edu, ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 25 May 2000, Jon Callas wrote: > If this blunder needs to be fixed, the correct way to fix it is to make a > V5 key structure. (For that matter, there are a couple other things I'd > fix, too, if we made a V5 key structure.) However, I think that as > unfortunate as this is, simplicity and compatibility override aesthetics, > and we should just live with things as they are. It's not just aesthetics. This issue was brought up by Marc Horowitz at the Keyserver Symposium this week. He thinks that it could have a positive impact on the internal workings of the keyservers, and would simplfy seaches for the user. However, I do agree that we should not break more than we fix. If the benefits of doing keyids this way do not outweigh the drawbacks, we probably shouldn't do it. Out of curiosity, what are the other things you would like to fix, given the chance to do a v5 key structure? __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LiuSPYrxsgmsCmoRAktoAKCdXFz9MP7vfldurisfwVJq4Buy6ACeJKzT 4LIaiqkmfXE8vR82E436k1s= =sdRU -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri May 26 04:42:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA11406 for ; Fri, 26 May 2000 04:42:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA07407 for ietf-openpgp-bks; Fri, 26 May 2000 01:14:02 -0700 (PDT) Received: from sobolev.does-not-exist.org (postfix@[208.161.253.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA07397 for ; Fri, 26 May 2000 01:13:58 -0700 (PDT) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 06EA82ED43; Fri, 26 May 2000 10:21:10 +0200 (CEST) Date: Fri, 26 May 2000 10:21:09 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Message-ID: <20000526102109.A19772@sobolev.tlr-net.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-05-25 09:45:24 -0700, hal@finney.org wrote: > The only keys that used right substrings would be > "legacy" DSA and ElGamal keys (assuming that no one > else has implemented RSA V4 keys, which I am not sure > about). We might do some kind of upgrade to DSA keys > when the new larger hash is announced later this year, > and they could switch at that time. Maybe some > arbitrary change could be made to ElGamal as well. If things absolutely have to be changed in an incompatible way, please use a different packet version (say, V5) for this, so old software nicely breaks on it. Everything else will lead to considerable confusion of users and software. -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Fri May 26 05:15:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11667 for ; Fri, 26 May 2000 05:14:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA09987 for ietf-openpgp-bks; Fri, 26 May 2000 01:40:42 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09983 for ; Fri, 26 May 2000 01:40:34 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12vFlW-0005AW-00 for ietf-openpgp@imc.org; Fri, 26 May 2000 10:46:46 +0200 To: ietf-openpgp@imc.org Subject: Behavior of implementations regarding certain key material From: Florian Weimer Date: 26 May 2000 10:46:46 +0200 Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for Revocation": | A revoked certification no longer is a part of validity | calculations. We were a bit surprised when we discovered this change to RFC 2440 because RFC 2440 primarily specifies the OpenPGP message format, and not the behavior of implementations when they encounter certain OpenPGP messages, much to our discomfort. We would like to see other requirements such as "An expired certification is no longer part of validity calculations." If you are running a CA, you certainly want all implementations to react to certfication expiration, certifying key expiration, certication revocation etc. in the same manner. If you agree that this should be addressed, we can document additional requirements which make sense from our point of view as a basis for further discussion. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 From owner-ietf-openpgp@mail.imc.org Fri May 26 09:45:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15329 for ; Fri, 26 May 2000 09:45:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA02961 for ietf-openpgp-bks; Fri, 26 May 2000 06:07:27 -0700 (PDT) Received: from horowitz.ne.mediaone.net (horowitz.ne.mediaone.net [24.147.233.208]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02956 for ; Fri, 26 May 2000 06:07:25 -0700 (PDT) Received: (from marc@localhost) by horowitz.ne.mediaone.net (8.8.8/8.8.8) id JAA16322; Fri, 26 May 2000 09:14:40 -0400 (EDT) From: Marc Horowitz To: "L. Sassaman" Cc: Jon Callas , hal@finney.org, ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint References: Date: 26 May 2000 09:14:40 -0400 In-Reply-To: "L. Sassaman"'s message of "Fri, 26 May 2000 00:45:14 -0700 (PDT)" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "L. Sassaman" writes: >> It's not just aesthetics. This issue was brought up by Marc Horowitz at >> the Keyserver Symposium this week. He thinks that it could have a positive >> impact on the internal workings of the keyservers, and would simplfy >> seaches for the user. I think Len is putting words in my mouth. I do have some ideas which came out of the meeting for changes which would have a positive impact on the internal workings of the keyservers, and on the externally visible functioning of the network as a whole, but changing how keyids are generated and interpreted isn't one of them. To address Phil's concerns as described by Hal, there's no reason that you couldn't use the variable rightmost N bits of the fingerprint to identify a key with arbitrary specificity today. For people's keyrings, the linear search won't take any more or less time. For the keyserver, if people wanted this feature, it would be possible to start keeping an index of the fingerprint in reverse bit order. Changes would be necessary in the keyserver to support lookup by anything but a fixed position+length of the fingerprint, anyway. This isn't pretty, but it would be complexity hidden from the user. I agree with everyone else that using the leftmost N bits would have been prettier, but isn't strictly necessary. Marc From owner-ietf-openpgp@mail.imc.org Fri May 26 09:45:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15349 for ; Fri, 26 May 2000 09:45:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA02977 for ietf-openpgp-bks; Fri, 26 May 2000 06:07:37 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02972 for ; Fri, 26 May 2000 06:07:36 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA11877 for ; Fri, 26 May 2000 09:09:07 -0400 (EDT) Message-Id: <200005261309.JAA11870@roadblock.missi.ncsc.mil> Date: Fri, 26 May 2000 09:12:13 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: KeyID as left vs right substring of fingerprint To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mmVajd5lUQd7KC36Tdej6w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Can someone explain the rationale for preferring to use one portion of a fingerprint rather than another as a key id? My interest is academic rather than strictly PGP related. X.509 also uses key ids which are profiled to be fixed sized fields containing a hash value, so the situation is not unique to PGP. My assumption is that: 1) no particular bits of a good cryptographic hash algorithm have any better collision resistance properties than any other bits, and 2) there is no significant computation savings in generating only a subset of the hash output, much less a difference in generating only high bits vs. only low bits. Is this assumption wrong, or are there other reasons that using the low n bits of the output of a cryptographic hash as a key id is a blunder? It would be unfortunate if the same mistake were repeated elsewhere. Dave Kemp (I considered the possiblity that the message from Hal was dated 1 April and was delayed in transit, and verified that it was not.) > Date: Thu, 25 May 2000 17:28:41 -0700 > To: hal@finney.org, ietf-openpgp@imc.org > From: Jon Callas > Subject: Re: KeyID as left vs right substring of fingerprint > > I agree that in retrospect, it would have been better to have the key id be > the high-order bits of the fingerprint rather than the low-order bits. I, > too, think this was a mistake. However, that decision was made before this > working group was formed. (And before I joined PGP, Inc. for that matter.) > > I believe that changing this and making it be dependent on the algorithm > type would be utterly wrong. It would add one more little gnarly bit into a > system that is already filled with too many gnarly bits. > > If this blunder needs to be fixed, the correct way to fix it is to make a > V5 key structure. (For that matter, there are a couple other things I'd > fix, too, if we made a V5 key structure.) However, I think that as > unfortunate as this is, simplicity and compatibility override aesthetics, > and we should just live with things as they are. > > Jon > > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** From owner-ietf-openpgp@mail.imc.org Fri May 26 11:36:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18334 for ; Fri, 26 May 2000 11:36:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07305 for ietf-openpgp-bks; Fri, 26 May 2000 07:57:40 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07301 for ; Fri, 26 May 2000 07:57:39 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA16864 for ietf-openpgp@imc.org; Fri, 26 May 2000 08:06:13 -0700 Date: Fri, 26 May 2000 08:06:13 -0700 Message-Id: <200005261506.IAA16864@finney.org> To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There is one possibly minor technical problem with making the change. Presently some of the pgp clients display only 32 bits of the 64 bit keyid. This might be done for example if they receive a message encrypted to or signed by a key they don't know. In that case they have the 64 bit keyid but they sometimes only display 32 bits because that is a more manageable size for humans. Manual key server searches have also supported 32 bit keyids. With keyids as the right substring of both V3 RSA moduli and V4 fingerprints, it is most logical to use the right 32 bits of the 64 bits for this purpose, and that is how it has been done. If some keys start using left substrings, then it would be awkward to continue to use the right 32 bits of the keyid as the short form. This would end up being bits 32-63 of the fingerprint. For keys that use left substrings, it would be more appropriate to use the left 32 bits of the 64 as the short form of the keyid. However, in the circumstances above where this arises, we don't know the key's version number. We have only the algorithm id and the keyid. So we can't base the decision on anything other than the algorithm id. There are a few possible solutions. We could eliminate the 32-bit keyid display entirely, and only show and input 64 bit keyids. This is really a UI issue which is outside the scope of this group, and while we have no obligation to support any particular shortening of keyids, I think we should be aware of the impact our decisions make on other parts of the system. We could make the decision about which way to shorten it depend entirely on the key algorithm, so that we'd need a new algorithm identifier for RSA keys which used the new convention. We could make new signature and pkesk packets which include more information about the keyid, enough to allow it to be shortened unambiguously (and perhaps supporting variable length keyids). Or of course we could leave it as it is now. I am still not convinced that the universe is constructed such that left substrings are inherently more natural than right ones. Endian wars, anyone? Hal From owner-ietf-openpgp@mail.imc.org Fri May 26 12:20:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19330 for ; Fri, 26 May 2000 12:20:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA08576 for ietf-openpgp-bks; Fri, 26 May 2000 08:52:30 -0700 (PDT) Received: from excalibur.iks-jena.de (root@excalibur.iks-jena.de [194.221.90.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08571 for ; Fri, 26 May 2000 08:52:29 -0700 (PDT) Received: from taranis.iks-jena.de (taranis.iks-jena.de [194.221.90.21]) by excalibur.iks-jena.de (8.10.1/8.10.1) with ESMTP id e4QFxmH24367 for ; Fri, 26 May 2000 17:59:48 +0200 Received: (from lutz@localhost) by taranis.iks-jena.de (8.10.1/8.10.1) id e4QFw6C01585 for ietf-openpgp@imc.org; Fri, 26 May 2000 17:58:06 +0200 X-Envelope-To: ietf-open-pgp@imc.org Received: (from news@localhost) by grannus.iks-jena.de (8.10.1/8.10.1) id e4QFe8l30076 for ietf-open-pgp@imc.org; Fri, 26 May 2000 17:40:08 +0200 To: ietf-open-pgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: KeyID as left vs right substring of fingerprint Date: 26 May 2000 15:40:07 GMT Organization: IKS GmbH Jena Lines: 13 Message-ID: References: <200005261506.IAA16864@finney.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.7 (UNIX) Status: RO Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * hal@finney.org wrote: [Problem of retrieving] >However, in the circumstances above where this arises, we don't know >the key's version number. We have only the algorithm id and the keyid. >So we can't base the decision on anything other than the algorithm id. So I urge to keep the current mechanism. Key IDs may expand to the left. >Or of course we could leave it as it is now. I am still not convinced >that the universe is constructed such that left substrings are inherently >more natural than right ones. Endian wars, anyone? Exactly. Keep it or run in trouble. * hal@finney.org wrote: [Problem of retrieving] >However, in the circumstances above where this arises, we don't know >the key's version number. We have only the algorithm id and the keyid. >So we can't base the decision on anything other than the algorithm id. So I urge to keep the current mechanism. Key IDs may expand to the left. >Or of course we could leave it as it is now. I am still not convinced >that the universe is constructed such that left substrings are inherently >more natural than right ones. Endian wars, anyone? Exactly. Keep it or run in trouble. From owner-ietf-openpgp@mail.imc.org Fri May 26 13:20:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20700 for ; Fri, 26 May 2000 13:20:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09697 for ietf-openpgp-bks; Fri, 26 May 2000 09:52:37 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09693 for ; Fri, 26 May 2000 09:52:35 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12vNmW-0004wY-00; Fri, 26 May 2000 19:20:20 +0200 Date: Fri, 26 May 2000 19:20:20 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Message-ID: <20000526192020.D17672@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200005261506.IAA16864@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <200005261506.IAA16864@finney.org>; from hal@finney.org on Fri, May 26, 2000 at 08:06:13AM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 26 May 2000, hal@finney.org wrote: > Or of course we could leave it as it is now. I am still not convinced Yes, please. There is not that much difference in the code for either of the ones. Adding code for taking the keyid from the left side just adds more complexity in terms of backward compatibilty and we already have so much code just for backword issues. > that the universe is constructed such that left substrings are inherently > more natural than right ones. Endian wars, anyone? No, thanks. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Fri May 26 15:48:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23872 for ; Fri, 26 May 2000 15:48:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12321 for ietf-openpgp-bks; Fri, 26 May 2000 12:19:17 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12317 for ; Fri, 26 May 2000 12:19:16 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqwr15275; Fri, 26 May 2000 19:26:34 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24887; Fri, 26 May 00 15:23:06 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA14333; Fri, 26 May 2000 15:26:32 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14638.53224.634970.847559@xedia.com> Date: Fri, 26 May 2000 15:26:32 -0400 (EDT) To: jon@callas.org Cc: hal@finney.org, ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint References: <200005251645.JAA11926@finney.org> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Jon" == Jon Callas writes: Jon> I agree that in retrospect, it would have been better to have Jon> the key id be the high-order bits of the fingerprint rather than Jon> the low-order bits. I, too, think this was a mistake. However, Jon> that decision was made before this working group was Jon> formed. (And before I joined PGP, Inc. for that matter.) Jon> I believe that changing this and making it be dependent on the Jon> algorithm type would be utterly wrong. It would add one more Jon> little gnarly bit into a system that is already filled with too Jon> many gnarly bits. I agree that it should not be changed. For that matter, I am thoroughly puzzled why anyone would say that it's better to use high order bits than low order bits. We're talking about taking a subset of the bits of a hash function, right? Any old subset is as good as any other. A random subset of the bits would be just as good, or just as bad, as the high order bits, or the low order bits. paul From owner-ietf-openpgp@mail.imc.org Fri May 26 15:58:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24162 for ; Fri, 26 May 2000 15:58:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12466 for ietf-openpgp-bks; Fri, 26 May 2000 12:26:46 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12462 for ; Fri, 26 May 2000 12:26:45 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqws22413; Fri, 26 May 2000 19:34:04 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24989; Fri, 26 May 00 15:30:36 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA14338; Fri, 26 May 2000 15:34:02 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14638.53674.708069.953816@xedia.com> Date: Fri, 26 May 2000 15:34:02 -0400 (EDT) To: rabbi@quickie.net Cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "L" == L Sassaman writes: L> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 L> On Thu, 25 May 2000, Jon Callas wrote: >> If this blunder needs to be fixed, the correct way to fix it is to >> make a V5 key structure. (For that matter, there are a couple >> other things I'd fix, too, if we made a V5 key structure.) >> However, I think that as unfortunate as this is, simplicity and >> compatibility override aesthetics, and we should just live with >> things as they are. L> It's not just aesthetics. This issue was brought up by Marc L> Horowitz at the Keyserver Symposium this week. He thinks that it L> could have a positive impact on the internal workings of the L> keyservers,... That doesn't compute. If key servers want to have "high order" bits used as lookup index, perhaps so standard database mechanisms that search for "match on leading bits" can be used, that's fine. This does NOT require a protocol change! A key server is perfectly well entitled to swizzle the data around in any way it chooses for its own convenience; all that is expected of it is that it unswizzles it before sending it back out. So if it's good for key servers, let the key servers internally turn the fingerprint end for end. Trivial coding and no protocol change needed. Not only that, but if you use a different database where this approach is not useful, or even counterproductive, or a different optimization is better, then you just do something else instead. But all of this is an internal implementation detail. paul From owner-ietf-openpgp@mail.imc.org Fri May 26 16:05:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24391 for ; Fri, 26 May 2000 16:05:00 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12634 for ietf-openpgp-bks; Fri, 26 May 2000 12:37:56 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12630 for ; Fri, 26 May 2000 12:37:54 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA01586; Fri, 26 May 2000 12:45:12 -0700 Date: Fri, 26 May 2000 12:45:05 -0700 (PDT) From: "L. Sassaman" To: "David P. Kemp" cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: <200005261309.JAA11870@roadblock.missi.ncsc.mil> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 26 May 2000, David P. Kemp wrote: > Can someone explain the rationale for preferring to use one portion > of a fingerprint rather than another as a key id? > > My interest is academic rather than strictly PGP related. > X.509 also uses key ids which are profiled to be fixed sized fields > containing a hash value, so the situation is not unique to PGP. My > assumption is that: 1) no particular bits of a good cryptographic hash > algorithm have any better collision resistance properties than any > other bits, and 2) there is no significant computation savings in > generating only a subset of the hash output, much less a difference in > generating only high bits vs. only low bits. > > Is this assumption wrong, or are there other reasons that using the low > n bits of the output of a cryptographic hash as a key id is a blunder? > It would be unfortunate if the same mistake were repeated elsewhere. The issue here wasn't a technical one, but an "ease-of-use" one really. If you obtain the keyid from the left of the fingerprint, it is easier for the user to adjust the length of the keyid when necessary. I am further assuming that your two assumptions are correct. The only benefit I see here is the ability to dynamically adjust the size of the "keyid" when searching for keys on a server or keyring, and when encrypting to keys. > Dave Kemp > > (I considered the possiblity that the message from Hal was dated > 1 April and was delayed in transit, and verified that it was not.) Hah! :) - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LtRIPYrxsgmsCmoRAhAxAJ9JWzu5KVmFSQEMQsNQO0MYDfHk2gCfbPyz pKayJ94WJ/ETUnaYZNlfVa4= =8+MS -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri May 26 16:09:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24449 for ; Fri, 26 May 2000 16:09:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12691 for ietf-openpgp-bks; Fri, 26 May 2000 12:43:59 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12687 for ; Fri, 26 May 2000 12:43:58 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA01616; Fri, 26 May 2000 12:51:04 -0700 Date: Fri, 26 May 2000 12:50:56 -0700 (PDT) From: "L. Sassaman" To: Marc Horowitz cc: Jon Callas , hal@finney.org, ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 May 2000, Marc Horowitz wrote: > "L. Sassaman" writes: > > >> It's not just aesthetics. This issue was brought up by Marc Horowitz at > >> the Keyserver Symposium this week. He thinks that it could have a positive > >> impact on the internal workings of the keyservers, and would simplfy > >> seaches for the user. > > I think Len is putting words in my mouth. I do have some ideas which > came out of the meeting for changes which would have a positive impact > on the internal workings of the keyservers, and on the externally > visible functioning of the network as a whole, but changing how keyids > are generated and interpreted isn't one of them. Sorry about that. I didn't mean to imply you suggested we change the keyids (though I see that my paragraph above looks like I meant that). But, if I am recalling correctly, you had thought it was something that "would have been nice" if done the way Phil had wanted. But then again, my recollection might be totally wrong... ;) > To address Phil's concerns as described by Hal, there's no reason that > you couldn't use the variable rightmost N bits of the fingerprint to > identify a key with arbitrary specificity today. For people's > keyrings, the linear search won't take any more or less time. For the > keyserver, if people wanted this feature, it would be possible to > start keeping an index of the fingerprint in reverse bit order. > Changes would be necessary in the keyserver to support lookup by > anything but a fixed position+length of the fingerprint, anyway. This > isn't pretty, but it would be complexity hidden from the user. Completely hidden from the user, but not as fluid as a leftmost keyid. Expanding from the right is less natural to users whose language reads from left to right, in my opinion. > I agree with everyone else that using the leftmost N bits would have > been prettier, but isn't strictly necessary. Then it is probably best to leave this as it is, and not make the change. Unless Jon can think of other things this group has discussed that would justify a v5 key format on their own... - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LtWnPYrxsgmsCmoRAlfFAKCjFRkgdgNdvwbZNdeRrJT1Nj+0dwCfYlZG BLYGxke/wOSIDhOtUwfDG8A= =ALY3 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri May 26 20:34:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28531 for ; Fri, 26 May 2000 20:34:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19223 for ietf-openpgp-bks; Fri, 26 May 2000 17:02:16 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19219 for ; Fri, 26 May 2000 17:02:15 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA05051; Fri, 26 May 2000 17:09:07 -0700 (PDT) Received: from [63.73.97.188] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA05047; Fri, 26 May 2000 17:09:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: Date: Fri, 26 May 2000 16:47:25 -0700 To: Florian Weimer , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Behavior of implementations regarding certain key material Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:46 AM +0200 5/26/00, Florian Weimer wrote: >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for >Revocation": > >| A revoked certification no longer is a part of validity >| calculations. > >We were a bit surprised when we discovered this change to RFC 2440 >because RFC 2440 primarily specifies the OpenPGP message format, >and not the behavior of implementations when they encounter certain >OpenPGP messages, much to our discomfort. > Umm, so what is the problem? Is there a reason that a revoked certification *should* be part of validity calculations? You're correct that 2440 is a syntax document, not a semantics document. However, there are times when you have to hint at semantics when you're describing syntax. In this particular case, OpenPGP does not specify a trust model. At one time, there were going to be a series of documents describing various trust models that one might use (for example, the so-called web of trust), but no one has seen fit to write these documents. However, even though we don't specify what validity calculations to use, there are nonetheless syntactic things we have to say about them. Whatever validity model you're using, it seems pretty straight forward that a revoked certification is null and void. That's all this is saying. It's in 2440bis because consensus asked that it be there. Jon From owner-ietf-openpgp@mail.imc.org Fri May 26 20:55:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28782 for ; Fri, 26 May 2000 20:55:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19584 for ietf-openpgp-bks; Fri, 26 May 2000 17:32:14 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19580 for ; Fri, 26 May 2000 17:32:13 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA05234 for ; Fri, 26 May 2000 17:39:05 -0700 (PDT) Received: from [63.73.97.188] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA05230 for ; Fri, 26 May 2000 17:39:04 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: Date: Fri, 26 May 2000 17:10:36 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: KeyID as left vs right substring of fingerprint Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think it really is just aesthetics whether you use the left or right bits as a key id. I also believe that the left bits are the more aesthetic ones to use, and I say that as a confirmed little-endian. I'll also concur that the key server can use whatever bytes it wants. That's no biggie. If I were to make a V5 key structure, the thing I'd change would be *not* to include the key creation time in with the SHA-1 hash for the fingerprint. This was unfortunate. It means that two keys that have the same key material, but different creation times have different key ids. At one time I thought this was a feature, and I've come to believe it's a bug. If I were really going to roto-till the spec, I'd get rid of key ids altogether and only use fingerprints. There have already been problems with key id collisions, and it would be much better to just use fingerprints. We already say that you SHOULD NOT assume they're unique, but arguably that really should be MUST NOT. However, I think that none of those changes can be made. There comes a point in any protocol's life where you just live with the warts because correcting them causes more problems. The key id selection is one of those. If we change things, we add more cruft into a system that already has cruft in it. There is already a separate algorithm for V3 keys and V4 keys. This would give us another one, and one that exists for no good reason. And as Hal has mentioned, the proper proper fix would be to make the UI that shows a 32 bit key id show the left 32 bits rather than the right ones. Fortunately, we've managed to bury that issue completely and not even mention them. 32 bit key ids only exist in implementations. Jon From owner-ietf-openpgp@mail.imc.org Sat May 27 00:22:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02545 for ; Sat, 27 May 2000 00:22:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA14857 for ietf-openpgp-bks; Fri, 26 May 2000 21:01:38 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA14853 for ; Fri, 26 May 2000 21:01:36 -0700 (PDT) Received: from [63.73.97.188] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Fri, 26 May 2000 21:08:56 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000516153807Y.1001@eccosys.com> References: <200005160251.WAA14064@finney.org> <20000516153807Y.1001@eccosys.com> Date: Fri, 26 May 2000 17:52:22 -0700 To: sen_ml@eccosys.com, ietf-openpgp@imc.org From: Jon Callas Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does anyone want to suggest wording on this? Jon From owner-ietf-openpgp@mail.imc.org Sat May 27 05:05:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15762 for ; Sat, 27 May 2000 05:05:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01695 for ietf-openpgp-bks; Sat, 27 May 2000 01:42:24 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01689 for ; Sat, 27 May 2000 01:42:22 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12vcHZ-0005dK-00; Sat, 27 May 2000 10:49:21 +0200 To: Jon Callas Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material References: From: Florian Weimer Date: 27 May 2000 10:49:21 +0200 In-Reply-To: Jon Callas's message of "Fri, 26 May 2000 16:47:25 -0700" Message-ID: Lines: 39 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > At 10:46 AM +0200 5/26/00, Florian Weimer wrote: > >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for > >Revocation": > > > >| A revoked certification no longer is a part of validity > >| calculations. > > > >We were a bit surprised when we discovered this change to RFC 2440 > >because RFC 2440 primarily specifies the OpenPGP message format, > >and not the behavior of implementations when they encounter certain > >OpenPGP messages, much to our discomfort. > > > > Umm, so what is the problem? Is there a reason that a revoked certification > *should* be part of validity calculations? No, of course not. Our point is: There is no reason why an expired certification should be part of validity calculations, either (at least by default). Ditto for expired keys. But 2440bis does not state what to do in these cases, and in fact, implementations already show different behavior. This is quite annoying if you want to limit in time the validity of your certificates. In the past, the only way to do that was to revoke the certifying keys (yuk!); with 2440bis, you have to revoke the certificates. Both options lead to a quickly growing CRL, which is very suboptimal. Just to make one thing clear: We do not want to standardize the validity calculations themselves, nor the way the web of trust is built. But we do want to have a set of conditions under which a certificate or a key won't be considered by validity calculations at all. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 From owner-ietf-openpgp@mail.imc.org Sat May 27 22:36:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24854 for ; Sat, 27 May 2000 22:36:13 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA24215 for ietf-openpgp-bks; Sat, 27 May 2000 19:09:32 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA24210 for ; Sat, 27 May 2000 19:09:29 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 16776 invoked from network); 28 May 2000 02:12:46 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 28 May 2000 02:12:46 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: References: <200005160251.WAA14064@finney.org> <20000516153807Y.1001@eccosys.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000528111654A.1001@eccosys.com> Date: Sun, 28 May 2000 11:16:54 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 102 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Jon Callas Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Fri, 26 May 2000 17:52:22 -0700 Message-ID: > Does anyone want to suggest wording on this? below is one attempt. p.s. there are other sections that i think could be made clearer. are people amenable to receiving other suggestions for wording as well? 3.6.1.1. Simple S2K This directly hashes the string to produce the key data. See below for how this hashing is done. Octet 0: 0x00 Octet 1: hash algorithm Simple S2K hashes the passphrase to produce the session key. The manner in which this is done depends on the size of the session key (which will depend on the cipher used) and the size of the hash algorithm's output. If the hash size is greater than or equal to the session key size, the high-order (leftmost) octets of the hash are used as the key. If the hash size is less than the key size, the key is determined as the result of the concatenation of multiple hash values -- enough to produce the required key data. Prior to each hash calculation, an appropriate number of octets of zeros are prepended to the data (in this case, the passphrase): hash(data) hash(0, data) hash(0, 0, data) ... and so on i.e. no prepending for the first hash computation, prepending one octet for the second hash computation, and thereafter increasing the number of prepended octets of zeros by one for each subsequent hash computation. The hash results are concatenated, first hash leftmost, to produce the key data, with any excess octets on the right discarded. Note that each hash computation should produce different output since in each case a different sequence of octets is hashed. 3.6.1.2. Salted S2K This includes a "salt" value in the S2K specifier -- some arbitrary data -- that gets hashed along with the passphrase string, to help prevent dictionary attacks. Octet 0: 0x01 Octet 1: hash algorithm Octets 2-9: 8-octet salt value Salted S2K is exactly like Simple S2K, except that the input to the hash function(s) consists of an appropriate number of octets of zeros, 8 octets of salt from the S2K specifier, followed by the passphrase. 3.6.1.3. Iterated and Salted S2K This includes both a salt and an octet count. The salt is combined with the passphrase repeatedly depending on the octet count, and the resulting value is hashed. This further increases the amount of work an attacker must do to try dictionary attacks. Octet 0: 0x03 Octet 1: hash algorithm Octets 2-9: 8-octet salt value Octet 10: count, a one-octet, coded value The count is coded into a one-octet number using the following formula: #define EXPBIAS 6 count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); The above formula is in C, where "Int32" is a type for a 32-bit integer, and the variable "c" is the coded count, Octet 10. The input to the hash function(s) is determined in the following manner. First, concatenate the 8 octets of salt from the S2K specifier and the passphrase. If the total length of the result is less than the count obtained by the above formula, concatenate sufficient octets from the salt and/or the passphrase such that the length of the resulting sequence is exactly equal to the count. Finally, prepend an appropriate number of octets of zeros: zero(s), salt, passphrase, salt, passphrase, salt, ... <--------------- count octets --------------> Note that the count does not apply to the number of prepended octets of zeros. Also, if the octet count is less than the size of the salt plus passphrase, the full salt plus passphrase will be hashed even though that is greater than the octet count. From owner-ietf-openpgp@mail.imc.org Sun May 28 08:13:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07811 for ; Sun, 28 May 2000 08:13:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA06316 for ietf-openpgp-bks; Sun, 28 May 2000 04:44:09 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06311 for ; Sun, 28 May 2000 04:44:07 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12w1vd-0000uX-00; Sun, 28 May 2000 14:12:25 +0200 Date: Sun, 28 May 2000 14:12:25 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Message-ID: <20000528141224.G3158@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: ; from jon@callas.org on Fri, May 26, 2000 at 05:10:36PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 26 May 2000, Jon Callas wrote: > If I were really going to roto-till the spec, I'd get rid of key ids > altogether and only use fingerprints. There have already been problems with I'd second this. However, the user will not see a difference as we can still present him a keyID, although we are not using it anymore. Using the keyID as a way to select a key is still a nice feature because typing the whole fingerprint is not that easy. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Mon May 29 21:40:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05609 for ; Mon, 29 May 2000 21:40:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12346 for ietf-openpgp-bks; Mon, 29 May 2000 18:00:38 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12335 for ; Mon, 29 May 2000 18:00:36 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id VAA30353; Mon, 29 May 2000 21:08:01 -0400 Message-Id: <200005300108.VAA30353@domains.invweb.net> From: "William H. Geiger III" Date: Mon, 29 May 2000 19:44:35 -0500 To: Florian Weimer In-Reply-To: Cc: Jon Callas , ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In , on 05/27/00 at 10:49 AM, Florian Weimer said: >Jon Callas writes: >> At 10:46 AM +0200 5/26/00, Florian Weimer wrote: >> >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for >> >Revocation": >> > >> >| A revoked certification no longer is a part of validity >> >| calculations. >> > >> >We were a bit surprised when we discovered this change to RFC 2440 >> >because RFC 2440 primarily specifies the OpenPGP message format, >> >and not the behavior of implementations when they encounter certain >> >OpenPGP messages, much to our discomfort. >> > >> >> Umm, so what is the problem? Is there a reason that a revoked certification >> *should* be part of validity calculations? >No, of course not. Our point is: There is no reason why an expired >certification should be part of validity calculations, either (at least >by default). Ditto for expired keys. But 2440bis does not state what to >do in these cases, and in fact, implementations already show different >behavior. This is quite annoying if you want to limit in time the >validity of your certificates. In the past, the only way to do that was >to revoke the certifying keys (yuk!); with 2440bis, you have to revoke >the certificates. Both options lead to a quickly growing CRL, which is >very suboptimal. Why can't you set an expiration time for the signature? This would seem the optimal way to do this. >Just to make one thing clear: We do not want to standardize the validity >calculations themselves, nor the way the web of trust is built. But we >do want to have a set of conditions under which a certificate or a key >won't be considered by validity calculations at all. Well either you need to have some standardization or you are going to have everyone doing their own thing. While I don't think a rigid RFC would be needed I do think a separate informational RFC would be advised. From the point of view of interoperability it will be important for developers to know how the WoT is being handled by the various vendors. The major issue is keyring sharing. Take the situation of 5 OpenPGP vendors developing both standalone and application integration products. Either the vendors must require the end user to make use of separate keyrings or there must be some documentation in this area so the various vendor products can share keyrings. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Tue May 30 11:24:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01141 for ; Tue, 30 May 2000 11:24:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07855 for ietf-openpgp-bks; Tue, 30 May 2000 07:40:45 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07845 for ; Tue, 30 May 2000 07:40:40 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12wnIh-0006tR-00; Tue, 30 May 2000 16:47:23 +0200 To: "William H. Geiger III" Cc: Jon Callas , ietf-openpgp@imc.org, goebel@RUS.Uni-Stuttgart.DE Subject: Re: Behavior of implementations regarding certain key material References: <200005300108.VAA30353@domains.invweb.net> From: Florian Weimer Date: 30 May 2000 16:47:23 +0200 In-Reply-To: "William H. Geiger III"'s message of "Mon, 29 May 2000 19:44:35 -0500" Message-ID: Lines: 55 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 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: "William H. Geiger III" writes: > Why can't you set an expiration time for the signature? This would seem > the optimal way to do this. AFAIK, there are implementations which use expired certificates in validity calculations. The certificate is used once to propagate trust, and if the neighborhood of the web of trust doesn't change, nothing happens if a certificate expires. > Well either you need to have some standardization or you are going to have > everyone doing their own thing. I believe that everyone shall build his own web of trust as he sees fit, but that's more a political statement than a technical one, of course. But I do want to have control over the validity of certificates issued by myself, that's the reason why I think that some standardization (i.e. some necessary (but not sufficient) conditions for certificate and key validity) are very useful. > While I don't think a rigid RFC would be > needed I do think a separate informational RFC would be advised. Yes, that was our internal conclusion as well. Oliver Goebel is preparing such a document. In addition, the document will contain recommendations for interactive OpenPGP implementations in borderline situations (just as an example, what to do if a chain of trust can be established to a key, but some of the links are expired certificates? -- the user should be given the choice not to use the key, use it anyway, or sign it locally to prevent future questions). > From the point of view of interoperability it will be important for > developers to know how the WoT is being handled by the various vendors. > The major issue is keyring sharing. I don't think this is a problem. Vendors can provide suitable conversion programs. In fact, OpenPGP implies a rather canonical key ring exchange format (simple concatenation of keys), and I think all OpenPGP implementation can handle this format. On the other hand, say if a secret key is protected by a passphrase and OpenPGP-optional symmetric cipher, there will always be implementations which cannot do anything useful with it, simply because the actual key material is protected by an unsupported cipher. (Direct key ring sharing doesn't make sense anyway because the actual key ring data structure depends heavily on the given application. Locking is another issue.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 From owner-ietf-openpgp@mail.imc.org Tue May 30 12:55:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04388 for ; Tue, 30 May 2000 12:55:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA10985 for ietf-openpgp-bks; Tue, 30 May 2000 09:10:29 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10981 for ; Tue, 30 May 2000 09:10:27 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirkz11470; Tue, 30 May 2000 16:17:55 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01477; Tue, 30 May 00 12:14:25 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA00554; Tue, 30 May 2000 12:17:54 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14643.59826.69664.318033@xedia.com> Date: Tue, 30 May 2000 12:17:54 -0400 (EDT) To: Florian.Weimer@RUS.Uni-Stuttgart.DE Cc: jon@callas.org, ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Florian" == Florian Weimer writes: Florian> Jon Callas writes: >> At 10:46 AM +0200 5/26/00, Florian Weimer wrote: >From >> draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for >> >Revocation": > >| A revoked certification no longer is a part of >> validity >| calculations. > >We were a bit surprised when we >> discovered this change to RFC 2440 >because RFC 2440 primarily >> specifies the OpenPGP message format, >and not the behavior of >> implementations when they encounter certain >OpenPGP messages, >> much to our discomfort. > >> >> Umm, so what is the problem? Is there a reason that a revoked >> certification *should* be part of validity calculations? Florian> No, of course not. Our point is: There is no reason why an Florian> expired certification should be part of validity Florian> calculations, either (at least by default). Ditto for Florian> expired keys. But 2440bis does not state what to do in Florian> these cases, and in fact, implementations already show Florian> different behavior. It seems to me the logical thing to do is very easy to describe: expired or revoked certs are treated as if they were nonexistent. paul From owner-ietf-openpgp@mail.imc.org Tue May 30 13:11:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04689 for ; Tue, 30 May 2000 13:11:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11590 for ietf-openpgp-bks; Tue, 30 May 2000 09:32:10 -0700 (PDT) Received: from grannus.iks-jena.de (root@grannus.iks-jena.de [194.221.90.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11585 for ; Tue, 30 May 2000 09:32:08 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.10.1/8.10.1) id e4UGdkn29582 for ietf-openpgp@imc.org; Tue, 30 May 2000 18:39:46 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Behavior of implementations regarding certain key material Date: 30 May 2000 16:39:45 GMT Organization: IKS GmbH Jena Lines: 5 Message-ID: References: <14643.59826.69664.318033@xedia.com> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.7 (UNIX) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Paul Koning wrote: >It seems to me the logical thing to do is very easy to describe: >expired or revoked certs are treated as if they were nonexistent. But certificates of expired keys are still valid. From owner-ietf-openpgp@mail.imc.org Tue May 30 14:02:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05866 for ; Tue, 30 May 2000 14:02:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12967 for ietf-openpgp-bks; Tue, 30 May 2000 10:27:18 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12963 for ; Tue, 30 May 2000 10:27:16 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12wq64-00019J-00; Tue, 30 May 2000 19:46:32 +0200 Date: Tue, 30 May 2000 19:46:32 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Message-ID: <20000530194632.P670@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <14643.59826.69664.318033@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: ; from lutz@iks-jena.de on Tue, May 30, 2000 at 04:39:45PM +0000 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 30 May 2000, Lutz Donnerhacke wrote: > But certificates of expired keys are still valid. However, this depends on the reason of certification. I am not sure whether the codes we already have for this are sufficient to automatically determine whether the cerificate is still valid. For example, a revocation may have been issued to express that the key has been compromised long time in the past and therefore the signature has never been valid. It is not easy to check this because it may be a pre-generated revocation or a malicious revocation. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Tue May 30 14:09:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05994 for ; Tue, 30 May 2000 14:09:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13387 for ietf-openpgp-bks; Tue, 30 May 2000 10:36:20 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13383 for ; Tue, 30 May 2000 10:36:19 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirle24972; Tue, 30 May 2000 17:43:53 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02615; Tue, 30 May 00 13:40:23 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA00619; Tue, 30 May 2000 13:43:51 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14643.64983.443333.934485@xedia.com> Date: Tue, 30 May 2000 13:43:51 -0400 (EDT) To: lutz@iks-jena.de Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Newsgroups: iks.lists.ietf-open-pgp References: <14643.59826.69664.318033@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Lutz" == Lutz Donnerhacke writes: Lutz> * Paul Koning wrote: >> It seems to me the logical thing to do is very easy to describe: >> expired or revoked certs are treated as if they were nonexistent. Lutz> But certificates of expired keys are still valid. For verifying old stuff, yes. Not for new stuff. So my simple description was too simplistic. I would apply it to things expired or revoked as of the creation date of whatever I want to verify. paul From owner-ietf-openpgp@mail.imc.org Tue May 30 15:05:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07411 for ; Tue, 30 May 2000 15:05:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA14989 for ietf-openpgp-bks; Tue, 30 May 2000 11:24:46 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14984 for ; Tue, 30 May 2000 11:24:45 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id LAA21884; Tue, 30 May 2000 11:32:18 -0700 Date: Tue, 30 May 2000 11:32:11 -0700 (PDT) From: "L. Sassaman" To: Paul Koning cc: lutz@iks-jena.de, ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material In-Reply-To: <14643.64983.443333.934485@xedia.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 30 May 2000, Paul Koning wrote: > >>>>> "Lutz" == Lutz Donnerhacke writes: > > Lutz> * Paul Koning wrote: > >> It seems to me the logical thing to do is very easy to describe: > >> expired or revoked certs are treated as if they were nonexistent. > > Lutz> But certificates of expired keys are still valid. > > For verifying old stuff, yes. Not for new stuff. So my simple > description was too simplistic. I would apply it to things expired or > revoked as of the creation date of whatever I want to verify. Eh? If you sign my key, and then your *key* expires, your signature is still included in validity calculations for my key. Even after your key expires. (However, you had to sign my key prior to the expiration of yours). __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5NAkyPYrxsgmsCmoRApzwAJ4j3ndnBh6zn3TzbrtwHVN1R82y0gCeIrVS r94YX2m3uWNeA/y7KXmispY= =sYh5 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue May 30 15:09:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07503 for ; Tue, 30 May 2000 15:09:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15082 for ietf-openpgp-bks; Tue, 30 May 2000 11:29:30 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15078 for ; Tue, 30 May 2000 11:29:29 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirli20892; Tue, 30 May 2000 18:37:09 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA03472; Tue, 30 May 00 14:33:39 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA00681; Tue, 30 May 2000 14:37:07 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14644.2643.563307.132775@xedia.com> Date: Tue, 30 May 2000 14:37:07 -0400 (EDT) To: rabbi@quickie.net Cc: lutz@iks-jena.de, ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material References: <14643.64983.443333.934485@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "L" == L Sassaman writes: L> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 L> On Tue, 30 May 2000, Paul Koning wrote: >> >>>>> "Lutz" == Lutz Donnerhacke writes: >> Lutz> * Paul Koning wrote: >> >> It seems to me the logical thing to do is very easy to >> describe: >> expired or revoked certs are treated as if they were >> nonexistent. >> Lutz> But certificates of expired keys are still valid. >> For verifying old stuff, yes. Not for new stuff. So my simple >> description was too simplistic. I would apply it to things >> expired or revoked as of the creation date of whatever I want to >> verify. L> Eh? If you sign my key, and then your *key* expires, your L> signature is still included in validity calculations for my L> key. Even after your key expires. (However, you had to sign my key L> prior to the expiration of yours). Agreed; that's what I meant. (Checking the signature requires a key that was good at the time that signature was created. It's the signature that is being verified, and the date of that signature is what matters.) paul From owner-ietf-openpgp@mail.imc.org Tue May 30 19:27:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12910 for ; Tue, 30 May 2000 19:27:00 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA21055 for ietf-openpgp-bks; Tue, 30 May 2000 15:50:34 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21051 for ; Tue, 30 May 2000 15:50:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA09379 for ietf-openpgp@imc.org; Tue, 30 May 2000 15:58:57 -0700 Date: Tue, 30 May 2000 15:58:57 -0700 Message-Id: <200005302258.PAA09379@finney.org> To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Koning writes, quoting Len Sassaman: > L> Eh? If you sign my key, and then your *key* expires, your > L> signature is still included in validity calculations for my > L> key. Even after your key expires. (However, you had to sign my key > L> prior to the expiration of yours). > > Agreed; that's what I meant. (Checking the signature requires a key > that was good at the time that signature was created. It's the > signature that is being verified, and the date of that signature is > what matters.) The problem is that we don't have a mechanism for securely timestamping signatures. If someone breaks or steals an expired key, they can create a back-dated signature with it. In my opinion it is risky to rely on a signature by an expired key. PGP versions 5.0 and later do not use expired keys in trust calculations. (PGP 2.6.2 and earlier did not support key expiration.) Hal From owner-ietf-openpgp@mail.imc.org Wed May 31 05:11:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01943 for ; Wed, 31 May 2000 05:11:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA23656 for ietf-openpgp-bks; Wed, 31 May 2000 01:36:55 -0700 (PDT) Received: from grannus.iks-jena.de (root@grannus.iks-jena.de [194.221.90.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23652 for ; Wed, 31 May 2000 01:36:53 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.10.1/8.10.1) id e4V8iac30911 for ietf-openpgp@imc.org; Wed, 31 May 2000 10:44:36 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Behavior of implementations regarding certain key material Date: 31 May 2000 08:44:35 GMT Organization: IKS GmbH Jena Lines: 23 Message-ID: References: <200005302258.PAA09379@finney.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.7 (UNIX) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * hal@finney.org wrote: >The problem is that we don't have a mechanism for securely timestamping >signatures. There are techniques to do so (eternity log, ...) but they are contraproductive on signature generation. Timestamps are optionally on reception. In most cases they are generated implicit by starting an business action. >If someone breaks or steals an expired key, they can create a back-dated >signature with it. German politics generated a (not required) appendix to the law, prohibitting specifically to back-date a computer while signing a document. So I can not happen. :-) >In my opinion it is risky to rely on a signature by an expired key. No. >PGP versions 5.0 and later do not use expired keys in trust calculations. Bad choice. From owner-ietf-openpgp@mail.imc.org Wed May 31 05:32:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02087 for ; Wed, 31 May 2000 05:32:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA23551 for ietf-openpgp-bks; Wed, 31 May 2000 01:28:47 -0700 (PDT) Received: from grannus.iks-jena.de (root@grannus.iks-jena.de [194.221.90.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23547 for ; Wed, 31 May 2000 01:28:45 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.10.1/8.10.1) id e4V8aS630634 for ietf-openpgp@imc.org; Wed, 31 May 2000 10:36:28 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Behavior of implementations regarding certain key material Date: 31 May 2000 08:36:28 GMT Organization: IKS GmbH Jena Lines: 21 Message-ID: References: <14643.59826.69664.318033@xedia.com> <20000530194632.P670@djebel.gnupg.de> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.7 (UNIX) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit * Werner Koch wrote: >On Tue, 30 May 2000, Lutz Donnerhacke wrote: >> But certificates of expired keys are still valid. > >However, this depends on the reason of certification. No. >For example, a revocation may have been issued to express that the >key has been compromised long time in the past and therefore the >signature has never been valid. Every certificate of an revoked key is invalid. In law all certificates with has a timestamp before the key revokation timestamp are valid. German law contains a protocol error to not require the timestamp at receiver's end. >It is not easy to check this because it may be a pre-generated revocation >or a malicious revocation. Definititly. That's why the law requires a timestamp on revokation and ultimate publication. From owner-ietf-openpgp@mail.imc.org Wed May 31 10:03:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10202 for ; Wed, 31 May 2000 10:03:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07016 for ietf-openpgp-bks; Wed, 31 May 2000 06:34:45 -0700 (PDT) Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07012 for ; Wed, 31 May 2000 06:34:41 -0700 (PDT) Received: from cdc1.cdc.informatik.tu-darmstadt.de (cdc1 [130.83.23.10]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 892CD2C51; Wed, 31 May 2000 15:42:30 +0200 (MET DST) Received: by cdc1.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id PAA25587; Wed, 31 May 2000 15:42:23 +0200 (MET DST) Date: Wed, 31 May 2000 15:42:22 +0200 From: Bodo Moeller To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Message-ID: <20000531154222.A25567@cdc.informatik.tu-darmstadt.de> References: <200005302258.PAA09379@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <200005302258.PAA09379@finney.org>; from hal@finney.org on Tue, May 30, 2000 at 03:58:57PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, May 30, 2000 at 03:58:57PM -0700, hal@finney.org wrote: > Paul Koning writes, quoting Len Sassaman: >>> Eh? If you sign my key, and then your *key* expires, your >>> signature is still included in validity calculations for my >>> key. Even after your key expires. (However, you had to sign my key >>> prior to the expiration of yours). >> Agreed; that's what I meant. (Checking the signature requires a key >> that was good at the time that signature was created. It's the >> signature that is being verified, and the date of that signature is >> what matters.) > The problem is that we don't have a mechanism for securely timestamping > signatures. If someone breaks or steals an expired key, they can create > a back-dated signature with it. > > In my opinion it is risky to rely on a signature by an expired key. Possibly, but ignoring keys on the grounds that they are expired does not buy you much because of the expiry date protocol failure in the OpenPGP key format. I've brought this up some time ago on this mailing list, here's a reminder: In the old PGP key format, key certification covers the expiration time, and all is well. (The validity period [key creation time and key expiration time] is part of the version 3 public key packet.) However, in the current OpenPGP key format, the key expiration time is covered only by self-signatures. (A version 4 public key packet cannot specify a validity period. The key validity period is in the signature packet instead.) Thus, if someone breaks or steals an expired OpenPGP key, they can renew it, and the old certificates will remain valid for the key with extended validity period or unlimited validity. Fix: Always include a signature expiration time when certifying a key that has a key expiration date in its self-signature; the time must be chosen such that the certificate's validity does not extend further into the future than the key's validity. The bottom line is that if you don't want to rely on signatures by expired keys, then you cannot rely on any certificates that don't contain a signature expiration time (unless the certified key is in a version 3 public key packet). -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 From owner-ietf-openpgp@mail.imc.org Wed May 31 13:27:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17277 for ; Wed, 31 May 2000 13:27:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA13925 for ietf-openpgp-bks; Wed, 31 May 2000 09:56:33 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13921 for ; Wed, 31 May 2000 09:56:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA12057; Wed, 31 May 2000 10:05:01 -0700 Date: Wed, 31 May 2000 10:05:01 -0700 Message-Id: <200005311705.KAA12057@finney.org> To: ietf-openpgp@imc.org, lutz@iks-jena.de Subject: Re: Behavior of implementations regarding certain key material Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lutz writes: > * hal@finney.org wrote: > >PGP versions 5.0 and later do not use expired keys in trust calculations. > > Bad choice. Yet I explained our reasoning in making this choice, and you appeared to basically agree: > >The problem is that we don't have a mechanism for securely timestamping > >signatures. > > There are techniques to do so (eternity log, ...) but they are > contraproductive on signature generation. Timestamps are optionally on > reception. In most cases they are generated implicit by starting an > business action. > > >If someone breaks or steals an expired key, they can create a back-dated > >signature with it. > > German politics generated a (not required) appendix to the law, prohibitting > specifically to back-date a computer while signing a document. So I can not > happen. :-) Since the techniques to timestamp messages aren't implemented in our protocol, and since the German law is obviously useless, it should be clear that the timestamp on a signature is largely meaningless for security purposes. Hence comparing that against the expiration time of the key is not a secure approach. The method used in PGP is safer. Hal From owner-ietf-openpgp@mail.imc.org Wed May 31 13:34:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17503 for ; Wed, 31 May 2000 13:34:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA14138 for ietf-openpgp-bks; Wed, 31 May 2000 10:04:32 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14134 for ; Wed, 31 May 2000 10:04:31 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA12079 for ietf-openpgp@imc.org; Wed, 31 May 2000 10:13:00 -0700 Date: Wed, 31 May 2000 10:13:00 -0700 Message-Id: <200005311713.KAA12079@finney.org> To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bodo Moeller writes: > In the old PGP key format, key certification covers the expiration > time, and all is well. (The validity period [key creation time and key > expiration time] is part of the version 3 public key packet.) > However, in the current OpenPGP key format, the key expiration time is > covered only by self-signatures. (A version 4 public key packet > cannot specify a validity period. The key validity period is in the > signature packet instead.) Thus, if someone breaks or steals an > expired OpenPGP key, they can renew it, and the old certificates will > remain valid for the key with extended validity period or unlimited > validity. I agree that this is a problem. In retrospect I wish we had done key expirations differently. There are two possible attacks: one is to strip away the self signature entirely, making it appear that the key has no expiration. The other is to issue a new self signature with a longer expiration. The first problem applies to key revocations as well. With a good key distribution infrastructure this should not be much of an issue. The second problem is specific to expirations. A workaround is to adopt the convention that if a key has multiple expirations, the earliest one applies. This prevents the "zombie key", where the attacker attempts to bring a dead key back to life. However it also prevents what I think was the original goal in putting expirations into self-sigs, which was to allow key holders to extend the life of their keys if they choose. > Fix: Always include a signature expiration time when certifying a key > that has a key expiration date in its self-signature; the time must be > chosen such that the certificate's validity does not extend further > into the future than the key's validity. That's a good idea, whether or not my proposal above was adopted. > The bottom line is that if you don't want to rely on signatures by > expired keys, then you cannot rely on any certificates that don't > contain a signature expiration time (unless the certified key > is in a version 3 public key packet). I think that my proposal would provide another way of addressing this. Hal From owner-ietf-openpgp@mail.imc.org Wed May 31 15:54:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22559 for ; Wed, 31 May 2000 15:54:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16236 for ietf-openpgp-bks; Wed, 31 May 2000 12:22:49 -0700 (PDT) Received: from fitug.de (fitug.e-technik.fh-muenchen.de [129.187.206.221]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16223 for ; Wed, 31 May 2000 12:22:46 -0700 (PDT) Received: from localhost (640 bytes) by fitug.de via sendmail with P:stdio/R:bind_hosts/T:smtp (sender: ) (ident using unix) id for ; Wed, 31 May 2000 21:30:31 +0200 (MET DST) (Smail-3.2.0.107 1999-Sep-8 #1 built DST-Sep-8) Date: Wed, 31 May 2000 21:30:31 +0200 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: ietf-openpgp@imc.org Subject: patents? Message-ID: <20000531213031.A637@netestate.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From the PGP documentation: "Network Associates INc. may have patens and/or pentding patent applications covering subject matter in this software or its documentation; the furnishing of this software or documentation does not give you any license to these patents." Does anybody know what that refers to? From owner-ietf-openpgp@mail.imc.org Wed May 31 16:23:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23784 for ; Wed, 31 May 2000 16:23:04 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA16662 for ietf-openpgp-bks; Wed, 31 May 2000 12:56:51 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16657 for ; Wed, 31 May 2000 12:56:49 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id NAA19273; Wed, 31 May 2000 13:04:32 -0700 Date: Wed, 31 May 2000 13:04:23 -0700 (PDT) From: "L. Sassaman" To: Lutz Donnerhacke cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31 May 2000, Lutz Donnerhacke wrote: > * Werner Koch wrote: > >On Tue, 30 May 2000, Lutz Donnerhacke wrote: > >> But certificates of expired keys are still valid. > > > >However, this depends on the reason of certification. > > No. > > >For example, a revocation may have been issued to express that the > >key has been compromised long time in the past and therefore the > >signature has never been valid. > > Every certificate of an revoked key is invalid. In law all certificates with > has a timestamp before the key revokation timestamp are valid. German law > contains a protocol error to not require the timestamp at receiver's end. You say that every certificate of a revoked key is invalid. The current draft claims otherwise. From 2440bis2:5.2.3.23: If a key has been revoked because of a compromise, all signatures created by that key are suspect. However, if it was merely superceded or retired, old signatures are still valid. If the revoked signature is the self-signature for certifying a user id, a revocation denotes that that user name is no longer in use. Such a revocation SHOULD inclide [sic] an 0x20 subpacket. Note that this brings up several issues. Current implementations of PGP do not use the Reason for Revocation tag, so all signatures made with PGP currently must be treated as invalid if the signing key is revoked. In the future, if this tag is used, keys revoked with reasons 0x01 and 0x03 should be considered "safe" in that certifications are still valid. All other reasons for revocation, including 0x00, should render certifications invalid. I have ignored 0x20 on this issue, since it does not apply to revoked keys. I think that we should have another revocation reason, 0x04 - Preemptive revocation certificate. I do not think that generating revocation certificates at the time of key gen, and saving them for future use is the best way to handle lost keys, but some people do this, and GnuPG actually advises the user to make such revocations at the time of key generation. Currently, they would fall into the category of 0x00, but due to the lack of a valid timestamp on them, I would prefer to see them with a more specific reason. Keys revoked with this reason should also render their certifications invalid. > >It is not easy to check this because it may be a pre-generated revocation > >or a malicious revocation. > > Definititly. That's why the law requires a timestamp on revokation and > ultimate publication. Again, a good reason to have a new reason for revocation in the case of pre-generated revocations. Another interesting problem that appears when certain revocations do not render certifications invalid is that now we must still provide the user with the means of re-revoking his key with a different reason for revocation. If the reason is 0x01 or 0x03, it seems to me that we would want to allow the user to change it to 0x02 if indeed it had been compromised. Or we simply say that all certifications by revoked keys are invalid, and change the wording in the draft. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5NXBPPYrxsgmsCmoRAlf+AJ9tueOebqUju8Mqpw8P6FxTJFTZlQCdG+Mt avRioD4mjQlivh29zsaYoa0= =Z7W9 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed May 31 16:35:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24266 for ; Wed, 31 May 2000 16:35:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16777 for ietf-openpgp-bks; Wed, 31 May 2000 13:00:11 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16772 for ; Wed, 31 May 2000 13:00:09 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id QAA26250; Wed, 31 May 2000 16:06:41 -0400 Message-Id: <200005312006.QAA26250@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 31 May 2000 15:05:15 -0500 To: Ulf =?US-ASCII?Q?M=94ller_?= In-Reply-To: <20000531213031.A637@netestate.de> Cc: ietf-openpgp@imc.org Subject: Re: patents? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA16774 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit In <20000531213031.A637@netestate.de>, on 05/31/00 at 01:30 PM, Ulf M”ller said: >>From the PGP documentation: "Network Associates INc. may have patens and/or >pentding patent applications covering subject matter in this software or >its documentation; the furnishing of this software or documentation does >not give you any license to these patents." Does anybody know what that >refers to? Probably just standard boilerplate. They are just putting you on notice that by publishing their source code they are not giving up any rights that the may hold on the code. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Wed May 31 17:47:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25631 for ; Wed, 31 May 2000 17:47:51 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA17658 for ietf-openpgp-bks; Wed, 31 May 2000 14:18:06 -0700 (PDT) Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17654 for ; Wed, 31 May 2000 14:18:04 -0700 (PDT) Received: from cdc1.cdc.informatik.tu-darmstadt.de (cdc1 [130.83.23.10]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id AC2AA2C4C; Wed, 31 May 2000 23:25:56 +0200 (MET DST) Received: by cdc1.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id XAA26048; Wed, 31 May 2000 23:25:49 +0200 (MET DST) Date: Wed, 31 May 2000 23:25:49 +0200 From: Bodo Moeller To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Message-ID: <20000531232548.A26035@cdc.informatik.tu-darmstadt.de> References: <200005311713.KAA12079@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <200005311713.KAA12079@finney.org>; from hal@finney.org on Wed, May 31, 2000 at 10:13:00AM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, May 31, 2000 at 10:13:00AM -0700, hal@finney.org wrote: >> [...] Thus, if someone breaks or steals an >> expired OpenPGP key, they can renew it, and the old certificates will >> remain valid for the key with extended validity period or unlimited >> validity. > I agree that this is a problem. In retrospect I wish we had done key > expirations differently. > > There are two possible attacks: one is to strip away the self signature > entirely, making it appear that the key has no expiration. The other > is to issue a new self signature with a longer expiration. > > The first problem applies to key revocations as well. Only if you you accept keys without a self-signature. GnuPG treats self-signatures as mandatory, which avoids this attack. (As far as self-signatures are concerned -- key revocations are obviously not mandatory :-) > With a good key > distribution infrastructure this should not be much of an issue. The > second problem is specific to expirations. > > A workaround is to adopt the convention that if a key has multiple > expirations, the earliest one applies. This prevents the "zombie key", > where the attacker attempts to bring a dead key back to life. However it > also prevents what I think was the original goal in putting expirations > into self-sigs, which was to allow key holders to extend the life of > their keys if they choose. Software could accept such life-extending signatures if they are received *while the key is still valid* (according to an earlier self-signature) -- later on, it could be argued that new self-signatures *must* be ignored because the key-owner told you so by having his signature key expire. (In case trusted timestamps by whatever means are available, date of receipt could be replaced by the timestamp date.) Note that key-expiration sub-packets as defined in RFC 2440 are still very useful for sub-keys: During the lifetime of your signature key, you could publish new encryption keys with short lifetime and with up-to-date cipher preferences (according to your current choice of software, availability of hardware accelerators, the state of the art of cryptography research, and so on), or could re-sign an existing encryption key with longer lifetime and updated cipher preferences. So it's not fully true that the original goal of putting expirations into the self-signatures is missed. >> Fix: Always include a signature expiration time when certifying a key >> that has a key expiration date in its self-signature; the time must be >> chosen such that the certificate's validity does not extend further >> into the future than the key's validity. > That's a good idea, whether or not my proposal above was adopted. >> The bottom line is that if you don't want to rely on signatures by >> expired keys, then you cannot rely on any certificates that don't >> contain a signature expiration time (unless the certified key >> is in a version 3 public key packet). > I think that my proposal would provide another way of addressing this. Yes, but it needs stronger assumptions -- you rely on what you call "a good key distribution infrastracture", i.e. you assume that the attacker cannot influence the infrastructure to hide existing signatures from you. A more prudent approach is to say that the inferred semantics should be monotonous in the set of signatures that one has seen; that is, to never base trust in something on the fact that you have *not* seen certain signatures. I am fully aware that this does not work for key revocations, but that's because they are a last resort -- and if you revoke a key because it has been compromised, then probably you won't just post the revocation to your favorite key server, but will also mail it directly to the folks you're communicating with; obviously such effort cannot usually be expected when handling ordinary key certificates. (OK, the S/MIME people do that all the time by effectively appending the equivalent of a "key ring" to their messages, but I hope you get the idea ...) -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 From owner-ietf-openpgp@mail.imc.org Wed May 31 19:38:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27378 for ; Wed, 31 May 2000 19:38:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20065 for ietf-openpgp-bks; Wed, 31 May 2000 16:12:44 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20061 for ; Wed, 31 May 2000 16:12:41 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA13118 for ietf-openpgp@imc.org; Wed, 31 May 2000 16:21:12 -0700 Date: Wed, 31 May 2000 16:21:12 -0700 Message-Id: <200005312321.QAA13118@finney.org> To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The question arises, what is the purpose or meaning of expiration dates on keys and signatures. In the case of keys, expirations have a couple of purposes. One is to reduce the attractiveness of the key as a target. A key with an indefinite lifespan is more valuable if stolen or cracked than one which will expire in the near future. This is especially true in the context of a brute force attack which may take a long time to mount. By giving the key an expiration date it may be effectively impossible to break the key before it expires, so no one would even try. A related purpose is to limit the damage if the key falls into someone else's hands. Ideally you will recognize when this happens and revoke the key, but the breach may not always be detected. Giving keys a limited lifetime and rolling over to new keys periodically will reduce the harm from this cause. In the case of signatures I think things are quite different. Signature expirations seem primarily used for the case where the certified information becomes incorrect or obsolete. In PGP we normally certify name and email address. Name is unlikely to change, but people do get new email addresses relatively frequently. It may be appropriate for a signature on an email address to expire periodically, with it being re-issued if the email address is still valid. Related to this, some systems may use certification by certain keys as an authorization method. Any key signed by the corporate key automatically gets access to the company network, for example. When someone quits their certification gets revoked, but due to difficulties in ensuring that revocation signatures propagate, putting an expiration in the original cert provides extra insurance. Again, valid certs would be re-issued periodically. Any other purposes which I have missed? Given this analysis, it's not clear to me that expired signatures should be ignored in trust calculations. Suppose I trust Alice, who has signed Bob's key, and I also trust Bob. If Alice's signature on Bob's key has expired, should I no longer trust signatures made by Bob's key? Bob is still the same person he always was. Maybe the sig on his key has expired because he no longer works at Alice's company, but that doesn't change who he is. The purpose of Alice's signature was to identify Bob, not to say that he is trustworthy. I am the one who made that latter determination. Given that Alice at one time certified Bob's identity, the fact that her certification has expired doesn't change the fact that I still trust him. In at least some cases, then, it might be reasonable to continue to use expired signatures in trust calculation. Hal From owner-ietf-openpgp@mail.imc.org Wed May 31 20:23:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28292 for ; Wed, 31 May 2000 20:23:40 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20794 for ietf-openpgp-bks; Wed, 31 May 2000 16:59:05 -0700 (PDT) Received: from rgate2.ricochet.net (rgate2.ricochet.net [204.179.143.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20785 for ; Wed, 31 May 2000 16:59:03 -0700 (PDT) Received: from teaparty.tillerman.to (mg-206253202-172.ricochet.net [206.253.202.172]) by rgate2.ricochet.net (8.9.3/8.9.3) with ESMTP id TAA29502; Wed, 31 May 2000 19:03:05 -0500 (CDT) Message-Id: <4.3.2.6.2.20000531164608.02e00a50@module-two.rwthayer.com> X-Sender: rodney@module-two.rwthayer.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Wed, 31 May 2000 16:46:24 -0700 To: "William H. Geiger III" , Ulf =?US-ASCII?Q?M=94ller_?= From: Rodney Thayer Subject: Re: patents? Cc: ietf-openpgp@imc.org In-Reply-To: <200005312006.QAA26250@domains.invweb.net> References: <20000531213031.A637@netestate.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Being as no evil lawyers from NAI or elsewhere have swooped down on this list or on the IETF I'd say it's safe for now. At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote: >In <20000531213031.A637@netestate.de>, on 05/31/00 > at 01:30 PM, Ulf M"ller said: > > >>From the PGP documentation: "Network Associates INc. may have patens and/or > >pentding patent applications covering subject matter in this software or > >its documentation; the furnishing of this software or documentation does > >not give you any license to these patents." Does anybody know what that > >refers to? > >Probably just standard boilerplate. They are just putting you on notice >that by publishing their source code they are not giving up any rights >that the may hold on the code. > >-- >--------------------------------------------------------------- >William H. Geiger III http://www.openpgp.net >Geiger Consulting > >Data Security & Cryptology Consulting >Programming, Networking, Analysis > >PGP for OS/2: http://www.openpgp.net/pgp.html >E-Secure: http://www.openpgp.net/esecure.html >--------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Wed May 31 20:57:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28834 for ; Wed, 31 May 2000 20:56:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA21271 for ietf-openpgp-bks; Wed, 31 May 2000 17:25:00 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21267 for ; Wed, 31 May 2000 17:25:00 -0700 (PDT) Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id RAA32551 for ; Wed, 31 May 2000 17:32:46 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 May 2000 17:24:40 -0700 To: ietf-openpgp@imc.org From: Dave Crocker Subject: Re: patents? In-Reply-To: <4.3.2.6.2.20000531164608.02e00a50@module-two.rwthayer.com> References: <200005312006.QAA26250@domains.invweb.net> <20000531213031.A637@netestate.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote: >Being as no evil lawyers from NAI or elsewhere have swooped down on this >list or on the IETF I'd say it's safe for now. > >At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote: >>Probably just standard boilerplate. They are just putting you on notice >>that by publishing their source code they are not giving up any rights >>that the may hold on the code. You are both being far too optimistic. While it is possible that you are correct, it is equally possible -- and many would say more likely -- that patents are, in fact, held or being prosecuted. The IETF has had some patents emerge very late in the process, so the concern is not academic. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA From owner-ietf-openpgp@mail.imc.org Wed May 31 21:43:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29489 for ; Wed, 31 May 2000 21:43:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA21139 for ietf-openpgp-bks; Wed, 31 May 2000 17:15:27 -0700 (PDT) Received: from srh0902.urh.uiuc.edu (qmailr@srh0902.urh.uiuc.edu [130.126.76.224]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21135 for ; Wed, 31 May 2000 17:15:25 -0700 (PDT) Received: (qmail 40513 invoked by uid 1000); 1 Jun 2000 00:23:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Jun 2000 00:23:11 -0000 Date: Wed, 31 May 2000 19:23:11 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0902.urh.uiuc.edu To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material In-Reply-To: <200005312321.QAA13118@finney.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hal@finney.org, at 16:21 -0700 on Wed, 31 May 2000, wrote: > Given this analysis, it's not clear to me that expired signatures should > be ignored in trust calculations. Suppose I trust Alice, who has signed > Bob's key, and I also trust Bob. If Alice's signature on Bob's key > has expired, should I no longer trust signatures made by Bob's key? > Bob is still the same person he always was. Maybe the sig on his key > has expired because he no longer works at Alice's company, but that > doesn't change who he is. However, it is possible that his identity has changed. Perhaps Alice was signing Bob's position in the company. Bob's position can change, and Alice decided when she signed whether she believes Bob's position to be static or variable information, by deciding on having the expiration or not. It is not up to you to decide whether what Alice signed was what she believes to be permanent or temporary information; she decides that. If she signed what you believe to be a "permanent identity" (e.g., name) with an expiration attached, one conclusion you could draw is that possibly a refinement of his identity in the future when the signature expires (perhaps another Bob Smith comes into the company, and more identifying information is needed). In the end, as time goes on, no identifier created so far will point directly to the entity known as Bob forever. This is what the sig expirations can be thought of as indicating, that the signer can only assure himself/herself that the signed, confirmed identity, can be trusted for at most the length of the signature. Whether that information is believed to be static or permament is decided by the signer, not by you. And if you don't trust the signer to make those distinctions, that's your decision on your end. -- Frank Tobin http://www.uiuc.edu/~ftobin/ "To learn what is good and what is to be valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus From owner-ietf-openpgp@mail.imc.org Wed May 31 22:55:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA02120 for ; Wed, 31 May 2000 22:55:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA07405 for ietf-openpgp-bks; Wed, 31 May 2000 19:10:30 -0700 (PDT) Received: from mailserver1.hrz.tu-darmstadt.de (root@mailserver1.hrz.tu-darmstadt.de [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07388 for ; Wed, 31 May 2000 19:10:27 -0700 (PDT) Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id EAA22686 for ; Thu, 1 Jun 2000 04:18:09 +0200 (MET DST) Received: from ppp203.stud.tu-darmstadt.de (ppp203.stud.tu-darmstadt.de [130.83.177.203]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id EAA06890 for ; Thu, 1 Jun 2000 04:18:11 +0200 (MET DST) Received: id ; Thu, 1 Jun 2000 04:49:26 +0200 (CEST) Message-Id: Date: Thu, 1 Jun 2000 04:49:26 +0200 (CEST) From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material In-Reply-To: <200005312321.QAA13118@finney.org> References: <200005312321.QAA13118@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit hal@finney.org: > The question arises, what is the purpose or meaning of expiration dates > on keys and signatures. > > In the case of keys, expirations have a couple of purposes. One is > to reduce the attractiveness of the key as a target. [...] > A related purpose is to limit the damage if the key falls into someone > else's hands. [...] A rule of thumb for this is as follows: Assume that every owner of a signing-only key may elect to publish their private key after expiry. (Further assume that consistent reliable clocks are available to all participating entities.) Can signatures created with these no-longer-private keys lead to problems? If so, then key expiry is not properly observed. > In the case of signatures I think things are quite different. [...] > In at least some cases, then, it might be reasonable to continue to use > expired signatures in trust calculation. This is true, in principle; however note that the workaround for enforcing key expiry (which is not covered by OpenPGP certificates) by setting an expiry time in certifying signatures works only if expired signatures are ignored. (The *key* expiration time sub-packet may be used only in self-signatures according to RFC 2440, so it cannot be used instead.) "Expired signatures must be ignored" actually is too strong a statement. More precisely, signatures must be ignored unless one is sure that they were created before the signing key expired. That is, if you know that you received the signature sufficiently early, then you may still use it; also if there's some trusted timestamp that convinces you, you may still use the signature. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 Received: by ns.secondary.com (8.9.3/8.9.3) id TAA07405 for ietf-openpgp-bks; Wed, 31 May 2000 19:10:30 -0700 (PDT) Received: from mailserver1.hrz.tu-darmstadt.de (root@mailserver1.hrz.tu-darmstadt.de [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA07388 for ; Wed, 31 May 2000 19:10:27 -0700 (PDT) Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id EAA22686 for ; Thu, 1 Jun 2000 04:18:09 +0200 (MET DST) Received: from ppp203.stud.tu-darmstadt.de (ppp203.stud.tu-darmstadt.de [130.83.177.203]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id EAA06890 for ; Thu, 1 Jun 2000 04:18:11 +0200 (MET DST) Received: id ; Thu, 1 Jun 2000 04:49:26 +0200 (CEST) Message-Id: Date: Thu, 1 Jun 2000 04:49:26 +0200 (CEST) From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material In-Reply-To: <200005312321.QAA13118@finney.org> References: <200005312321.QAA13118@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hal@finney.org: > The question arises, what is the purpose or meaning of expiration dates > on keys and signatures. > > In the case of keys, expirations have a couple of purposes. One is > to reduce the attractiveness of the key as a target. [...] > A related purpose is to limit the damage if the key falls into someone > else's hands. [...] A rule of thumb for this is as follows: Assume that every owner of a signing-only key may elect to publish their private key after expiry. (Further assume that consistent reliable clocks are available to all participating entities.) Can signatures created with these no-longer-private keys lead to problems? If so, then key expiry is not properly observed. > In the case of signatures I think things are quite different. [...] > In at least some cases, then, it might be reasonable to continue to use > expired signatures in trust calculation. This is true, in principle; however note that the workaround for enforcing key expiry (which is not covered by OpenPGP certificates) by setting an expiry time in certifying signatures works only if expired signatures are ignored. (The *key* expiration time sub-packet may be used only in self-signatures according to RFC 2440, so it cannot be used instead.) "Expired signatures must be ignored" actually is too strong a statement. More precisely, signatures must be ignored unless one is sure that they were created before the signing key expired. That is, if you know that you received the signature sufficiently early, then you may still use it; also if there's some trusted timestamp that convinces you, you may still use the signature. -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 Received: by ns.secondary.com (8.9.3/8.9.3) id RAA21271 for ietf-openpgp-bks; Wed, 31 May 2000 17:25:00 -0700 (PDT) Received: from joy.songbird.com (IDENT:root@joy.songbird.com [208.184.79.7]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA21267 for ; Wed, 31 May 2000 17:25:00 -0700 (PDT) Received: from free.88.106.bayarea.net (free.88.106.bayarea.net [205.219.88.106]) by joy.songbird.com (8.9.3/8.9.3) with SMTP id RAA32551 for ; Wed, 31 May 2000 17:32:46 -0700 X-Authentication-Warning: joy.songbird.com: free.88.106.bayarea.net [205.219.88.106] didn't use HELO protocol Message-Id: <4.3.2.7.0.20000531172252.00b8e8d0@mail.bayarea.net> X-Sender: dcrocker@mail.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 31 May 2000 17:24:40 -0700 To: ietf-openpgp@imc.org From: Dave Crocker Subject: Re: patents? In-Reply-To: <4.3.2.6.2.20000531164608.02e00a50@module-two.rwthayer.com> References: <200005312006.QAA26250@domains.invweb.net> <20000531213031.A637@netestate.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 04:46 PM 5/31/00 -0700, Rodney Thayer wrote: >Being as no evil lawyers from NAI or elsewhere have swooped down on this >list or on the IETF I'd say it's safe for now. > >At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote: >>Probably just standard boilerplate. They are just putting you on notice >>that by publishing their source code they are not giving up any rights >>that the may hold on the code. You are both being far too optimistic. While it is possible that you are correct, it is equally possible -- and many would say more likely -- that patents are, in fact, held or being prosecuted. The IETF has had some patents emerge very late in the process, so the concern is not academic. d/ =-=-=-=-= Dave Crocker Brandenburg Consulting Tel: +1.408.246.8253, Fax: +1.408.273.6464 675 Spruce Drive, Sunnyvale, CA 94086 USA Received: by ns.secondary.com (8.9.3/8.9.3) id RAA21139 for ietf-openpgp-bks; Wed, 31 May 2000 17:15:27 -0700 (PDT) Received: from srh0902.urh.uiuc.edu (qmailr@srh0902.urh.uiuc.edu [130.126.76.224]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA21135 for ; Wed, 31 May 2000 17:15:25 -0700 (PDT) Received: (qmail 40513 invoked by uid 1000); 1 Jun 2000 00:23:11 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 1 Jun 2000 00:23:11 -0000 Date: Wed, 31 May 2000 19:23:11 -0500 (CDT) From: Frank Tobin X-Sender: ftobin@srh0902.urh.uiuc.edu To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material In-Reply-To: <200005312321.QAA13118@finney.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hal@finney.org, at 16:21 -0700 on Wed, 31 May 2000, wrote: > Given this analysis, it's not clear to me that expired signatures should > be ignored in trust calculations. Suppose I trust Alice, who has signed > Bob's key, and I also trust Bob. If Alice's signature on Bob's key > has expired, should I no longer trust signatures made by Bob's key? > Bob is still the same person he always was. Maybe the sig on his key > has expired because he no longer works at Alice's company, but that > doesn't change who he is. However, it is possible that his identity has changed. Perhaps Alice was signing Bob's position in the company. Bob's position can change, and Alice decided when she signed whether she believes Bob's position to be static or variable information, by deciding on having the expiration or not. It is not up to you to decide whether what Alice signed was what she believes to be permanent or temporary information; she decides that. If she signed what you believe to be a "permanent identity" (e.g., name) with an expiration attached, one conclusion you could draw is that possibly a refinement of his identity in the future when the signature expires (perhaps another Bob Smith comes into the company, and more identifying information is needed). In the end, as time goes on, no identifier created so far will point directly to the entity known as Bob forever. This is what the sig expirations can be thought of as indicating, that the signer can only assure himself/herself that the signed, confirmed identity, can be trusted for at most the length of the signature. Whether that information is believed to be static or permament is decided by the signer, not by you. And if you don't trust the signer to make those distinctions, that's your decision on your end. -- Frank Tobin http://www.uiuc.edu/~ftobin/ "To learn what is good and what is to be valued, those truths which cannot be shaken or changed." Myst: The Book of Atrus Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20794 for ietf-openpgp-bks; Wed, 31 May 2000 16:59:05 -0700 (PDT) Received: from rgate2.ricochet.net (rgate2.ricochet.net [204.179.143.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20785 for ; Wed, 31 May 2000 16:59:03 -0700 (PDT) Received: from teaparty.tillerman.to (mg-206253202-172.ricochet.net [206.253.202.172]) by rgate2.ricochet.net (8.9.3/8.9.3) with ESMTP id TAA29502; Wed, 31 May 2000 19:03:05 -0500 (CDT) Message-Id: <4.3.2.6.2.20000531164608.02e00a50@module-two.rwthayer.com> X-Sender: rodney@module-two.rwthayer.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2.6 (Beta) Date: Wed, 31 May 2000 16:46:24 -0700 To: "William H. Geiger III" , Ulf =?US-ASCII?Q?M=94ller_?= From: Rodney Thayer Subject: Re: patents? Cc: ietf-openpgp@imc.org In-Reply-To: <200005312006.QAA26250@domains.invweb.net> References: <20000531213031.A637@netestate.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Being as no evil lawyers from NAI or elsewhere have swooped down on this list or on the IETF I'd say it's safe for now. At 03:05 PM 5/31/00 -0500, William H. Geiger III wrote: >In <20000531213031.A637@netestate.de>, on 05/31/00 > at 01:30 PM, Ulf M"ller said: > > >>From the PGP documentation: "Network Associates INc. may have patens and/or > >pentding patent applications covering subject matter in this software or > >its documentation; the furnishing of this software or documentation does > >not give you any license to these patents." Does anybody know what that > >refers to? > >Probably just standard boilerplate. They are just putting you on notice >that by publishing their source code they are not giving up any rights >that the may hold on the code. > >-- >--------------------------------------------------------------- >William H. Geiger III http://www.openpgp.net >Geiger Consulting > >Data Security & Cryptology Consulting >Programming, Networking, Analysis > >PGP for OS/2: http://www.openpgp.net/pgp.html >E-Secure: http://www.openpgp.net/esecure.html >--------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id QAA20065 for ietf-openpgp-bks; Wed, 31 May 2000 16:12:44 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA20061 for ; Wed, 31 May 2000 16:12:41 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA13118 for ietf-openpgp@imc.org; Wed, 31 May 2000 16:21:12 -0700 Date: Wed, 31 May 2000 16:21:12 -0700 Message-Id: <200005312321.QAA13118@finney.org> To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The question arises, what is the purpose or meaning of expiration dates on keys and signatures. In the case of keys, expirations have a couple of purposes. One is to reduce the attractiveness of the key as a target. A key with an indefinite lifespan is more valuable if stolen or cracked than one which will expire in the near future. This is especially true in the context of a brute force attack which may take a long time to mount. By giving the key an expiration date it may be effectively impossible to break the key before it expires, so no one would even try. A related purpose is to limit the damage if the key falls into someone else's hands. Ideally you will recognize when this happens and revoke the key, but the breach may not always be detected. Giving keys a limited lifetime and rolling over to new keys periodically will reduce the harm from this cause. In the case of signatures I think things are quite different. Signature expirations seem primarily used for the case where the certified information becomes incorrect or obsolete. In PGP we normally certify name and email address. Name is unlikely to change, but people do get new email addresses relatively frequently. It may be appropriate for a signature on an email address to expire periodically, with it being re-issued if the email address is still valid. Related to this, some systems may use certification by certain keys as an authorization method. Any key signed by the corporate key automatically gets access to the company network, for example. When someone quits their certification gets revoked, but due to difficulties in ensuring that revocation signatures propagate, putting an expiration in the original cert provides extra insurance. Again, valid certs would be re-issued periodically. Any other purposes which I have missed? Given this analysis, it's not clear to me that expired signatures should be ignored in trust calculations. Suppose I trust Alice, who has signed Bob's key, and I also trust Bob. If Alice's signature on Bob's key has expired, should I no longer trust signatures made by Bob's key? Bob is still the same person he always was. Maybe the sig on his key has expired because he no longer works at Alice's company, but that doesn't change who he is. The purpose of Alice's signature was to identify Bob, not to say that he is trustworthy. I am the one who made that latter determination. Given that Alice at one time certified Bob's identity, the fact that her certification has expired doesn't change the fact that I still trust him. In at least some cases, then, it might be reasonable to continue to use expired signatures in trust calculation. Hal Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA17658 for ietf-openpgp-bks; Wed, 31 May 2000 14:18:06 -0700 (PDT) Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17654 for ; Wed, 31 May 2000 14:18:04 -0700 (PDT) Received: from cdc1.cdc.informatik.tu-darmstadt.de (cdc1 [130.83.23.10]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id AC2AA2C4C; Wed, 31 May 2000 23:25:56 +0200 (MET DST) Received: by cdc1.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id XAA26048; Wed, 31 May 2000 23:25:49 +0200 (MET DST) Date: Wed, 31 May 2000 23:25:49 +0200 From: Bodo Moeller To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Message-ID: <20000531232548.A26035@cdc.informatik.tu-darmstadt.de> References: <200005311713.KAA12079@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <200005311713.KAA12079@finney.org>; from hal@finney.org on Wed, May 31, 2000 at 10:13:00AM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, May 31, 2000 at 10:13:00AM -0700, hal@finney.org wrote: >> [...] Thus, if someone breaks or steals an >> expired OpenPGP key, they can renew it, and the old certificates will >> remain valid for the key with extended validity period or unlimited >> validity. > I agree that this is a problem. In retrospect I wish we had done key > expirations differently. > > There are two possible attacks: one is to strip away the self signature > entirely, making it appear that the key has no expiration. The other > is to issue a new self signature with a longer expiration. > > The first problem applies to key revocations as well. Only if you you accept keys without a self-signature. GnuPG treats self-signatures as mandatory, which avoids this attack. (As far as self-signatures are concerned -- key revocations are obviously not mandatory :-) > With a good key > distribution infrastructure this should not be much of an issue. The > second problem is specific to expirations. > > A workaround is to adopt the convention that if a key has multiple > expirations, the earliest one applies. This prevents the "zombie key", > where the attacker attempts to bring a dead key back to life. However it > also prevents what I think was the original goal in putting expirations > into self-sigs, which was to allow key holders to extend the life of > their keys if they choose. Software could accept such life-extending signatures if they are received *while the key is still valid* (according to an earlier self-signature) -- later on, it could be argued that new self-signatures *must* be ignored because the key-owner told you so by having his signature key expire. (In case trusted timestamps by whatever means are available, date of receipt could be replaced by the timestamp date.) Note that key-expiration sub-packets as defined in RFC 2440 are still very useful for sub-keys: During the lifetime of your signature key, you could publish new encryption keys with short lifetime and with up-to-date cipher preferences (according to your current choice of software, availability of hardware accelerators, the state of the art of cryptography research, and so on), or could re-sign an existing encryption key with longer lifetime and updated cipher preferences. So it's not fully true that the original goal of putting expirations into the self-signatures is missed. >> Fix: Always include a signature expiration time when certifying a key >> that has a key expiration date in its self-signature; the time must be >> chosen such that the certificate's validity does not extend further >> into the future than the key's validity. > That's a good idea, whether or not my proposal above was adopted. >> The bottom line is that if you don't want to rely on signatures by >> expired keys, then you cannot rely on any certificates that don't >> contain a signature expiration time (unless the certified key >> is in a version 3 public key packet). > I think that my proposal would provide another way of addressing this. Yes, but it needs stronger assumptions -- you rely on what you call "a good key distribution infrastracture", i.e. you assume that the attacker cannot influence the infrastructure to hide existing signatures from you. A more prudent approach is to say that the inferred semantics should be monotonous in the set of signatures that one has seen; that is, to never base trust in something on the fact that you have *not* seen certain signatures. I am fully aware that this does not work for key revocations, but that's because they are a last resort -- and if you revoke a key because it has been compromised, then probably you won't just post the revocation to your favorite key server, but will also mail it directly to the folks you're communicating with; obviously such effort cannot usually be expected when handling ordinary key certificates. (OK, the S/MIME people do that all the time by effectively appending the equivalent of a "key ring" to their messages, but I hope you get the idea ...) -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 Received: by ns.secondary.com (8.9.3/8.9.3) id NAA16777 for ietf-openpgp-bks; Wed, 31 May 2000 13:00:11 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA16772 for ; Wed, 31 May 2000 13:00:09 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id QAA26250; Wed, 31 May 2000 16:06:41 -0400 Message-Id: <200005312006.QAA26250@domains.invweb.net> From: "William H. Geiger III" Date: Wed, 31 May 2000 15:05:15 -0500 To: Ulf =?US-ASCII?Q?M=94ller_?= In-Reply-To: <20000531213031.A637@netestate.de> Cc: ietf-openpgp@imc.org Subject: Re: patents? Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id NAA16774 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20000531213031.A637@netestate.de>, on 05/31/00 at 01:30 PM, Ulf M”ller said: >>From the PGP documentation: "Network Associates INc. may have patens and/or >pentding patent applications covering subject matter in this software or >its documentation; the furnishing of this software or documentation does >not give you any license to these patents." Does anybody know what that >refers to? Probably just standard boilerplate. They are just putting you on notice that by publishing their source code they are not giving up any rights that the may hold on the code. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id MAA16662 for ietf-openpgp-bks; Wed, 31 May 2000 12:56:51 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16657 for ; Wed, 31 May 2000 12:56:49 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id NAA19273; Wed, 31 May 2000 13:04:32 -0700 Date: Wed, 31 May 2000 13:04:23 -0700 (PDT) From: "L. Sassaman" To: Lutz Donnerhacke cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31 May 2000, Lutz Donnerhacke wrote: > * Werner Koch wrote: > >On Tue, 30 May 2000, Lutz Donnerhacke wrote: > >> But certificates of expired keys are still valid. > > > >However, this depends on the reason of certification. > > No. > > >For example, a revocation may have been issued to express that the > >key has been compromised long time in the past and therefore the > >signature has never been valid. > > Every certificate of an revoked key is invalid. In law all certificates with > has a timestamp before the key revokation timestamp are valid. German law > contains a protocol error to not require the timestamp at receiver's end. You say that every certificate of a revoked key is invalid. The current draft claims otherwise. From 2440bis2:5.2.3.23: If a key has been revoked because of a compromise, all signatures created by that key are suspect. However, if it was merely superceded or retired, old signatures are still valid. If the revoked signature is the self-signature for certifying a user id, a revocation denotes that that user name is no longer in use. Such a revocation SHOULD inclide [sic] an 0x20 subpacket. Note that this brings up several issues. Current implementations of PGP do not use the Reason for Revocation tag, so all signatures made with PGP currently must be treated as invalid if the signing key is revoked. In the future, if this tag is used, keys revoked with reasons 0x01 and 0x03 should be considered "safe" in that certifications are still valid. All other reasons for revocation, including 0x00, should render certifications invalid. I have ignored 0x20 on this issue, since it does not apply to revoked keys. I think that we should have another revocation reason, 0x04 - Preemptive revocation certificate. I do not think that generating revocation certificates at the time of key gen, and saving them for future use is the best way to handle lost keys, but some people do this, and GnuPG actually advises the user to make such revocations at the time of key generation. Currently, they would fall into the category of 0x00, but due to the lack of a valid timestamp on them, I would prefer to see them with a more specific reason. Keys revoked with this reason should also render their certifications invalid. > >It is not easy to check this because it may be a pre-generated revocation > >or a malicious revocation. > > Definititly. That's why the law requires a timestamp on revokation and > ultimate publication. Again, a good reason to have a new reason for revocation in the case of pre-generated revocations. Another interesting problem that appears when certain revocations do not render certifications invalid is that now we must still provide the user with the means of re-revoking his key with a different reason for revocation. If the reason is 0x01 or 0x03, it seems to me that we would want to allow the user to change it to 0x02 if indeed it had been compromised. Or we simply say that all certifications by revoked keys are invalid, and change the wording in the draft. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5NXBPPYrxsgmsCmoRAlf+AJ9tueOebqUju8Mqpw8P6FxTJFTZlQCdG+Mt avRioD4mjQlivh29zsaYoa0= =Z7W9 -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA16236 for ietf-openpgp-bks; Wed, 31 May 2000 12:22:49 -0700 (PDT) Received: from fitug.de (fitug.e-technik.fh-muenchen.de [129.187.206.221]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA16223 for ; Wed, 31 May 2000 12:22:46 -0700 (PDT) Received: from localhost (640 bytes) by fitug.de via sendmail with P:stdio/R:bind_hosts/T:smtp (sender: ) (ident using unix) id for ; Wed, 31 May 2000 21:30:31 +0200 (MET DST) (Smail-3.2.0.107 1999-Sep-8 #1 built DST-Sep-8) Date: Wed, 31 May 2000 21:30:31 +0200 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: ietf-openpgp@imc.org Subject: patents? Message-ID: <20000531213031.A637@netestate.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >From the PGP documentation: "Network Associates INc. may have patens and/or pentding patent applications covering subject matter in this software or its documentation; the furnishing of this software or documentation does not give you any license to these patents." Does anybody know what that refers to? Received: by ns.secondary.com (8.9.3/8.9.3) id KAA14138 for ietf-openpgp-bks; Wed, 31 May 2000 10:04:32 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA14134 for ; Wed, 31 May 2000 10:04:31 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA12079 for ietf-openpgp@imc.org; Wed, 31 May 2000 10:13:00 -0700 Date: Wed, 31 May 2000 10:13:00 -0700 Message-Id: <200005311713.KAA12079@finney.org> To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Bodo Moeller writes: > In the old PGP key format, key certification covers the expiration > time, and all is well. (The validity period [key creation time and key > expiration time] is part of the version 3 public key packet.) > However, in the current OpenPGP key format, the key expiration time is > covered only by self-signatures. (A version 4 public key packet > cannot specify a validity period. The key validity period is in the > signature packet instead.) Thus, if someone breaks or steals an > expired OpenPGP key, they can renew it, and the old certificates will > remain valid for the key with extended validity period or unlimited > validity. I agree that this is a problem. In retrospect I wish we had done key expirations differently. There are two possible attacks: one is to strip away the self signature entirely, making it appear that the key has no expiration. The other is to issue a new self signature with a longer expiration. The first problem applies to key revocations as well. With a good key distribution infrastructure this should not be much of an issue. The second problem is specific to expirations. A workaround is to adopt the convention that if a key has multiple expirations, the earliest one applies. This prevents the "zombie key", where the attacker attempts to bring a dead key back to life. However it also prevents what I think was the original goal in putting expirations into self-sigs, which was to allow key holders to extend the life of their keys if they choose. > Fix: Always include a signature expiration time when certifying a key > that has a key expiration date in its self-signature; the time must be > chosen such that the certificate's validity does not extend further > into the future than the key's validity. That's a good idea, whether or not my proposal above was adopted. > The bottom line is that if you don't want to rely on signatures by > expired keys, then you cannot rely on any certificates that don't > contain a signature expiration time (unless the certified key > is in a version 3 public key packet). I think that my proposal would provide another way of addressing this. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id JAA13925 for ietf-openpgp-bks; Wed, 31 May 2000 09:56:33 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA13921 for ; Wed, 31 May 2000 09:56:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA12057; Wed, 31 May 2000 10:05:01 -0700 Date: Wed, 31 May 2000 10:05:01 -0700 Message-Id: <200005311705.KAA12057@finney.org> To: ietf-openpgp@imc.org, lutz@iks-jena.de Subject: Re: Behavior of implementations regarding certain key material Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Lutz writes: > * hal@finney.org wrote: > >PGP versions 5.0 and later do not use expired keys in trust calculations. > > Bad choice. Yet I explained our reasoning in making this choice, and you appeared to basically agree: > >The problem is that we don't have a mechanism for securely timestamping > >signatures. > > There are techniques to do so (eternity log, ...) but they are > contraproductive on signature generation. Timestamps are optionally on > reception. In most cases they are generated implicit by starting an > business action. > > >If someone breaks or steals an expired key, they can create a back-dated > >signature with it. > > German politics generated a (not required) appendix to the law, prohibitting > specifically to back-date a computer while signing a document. So I can not > happen. :-) Since the techniques to timestamp messages aren't implemented in our protocol, and since the German law is obviously useless, it should be clear that the timestamp on a signature is largely meaningless for security purposes. Hence comparing that against the expiration time of the key is not a secure approach. The method used in PGP is safer. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id GAA07016 for ietf-openpgp-bks; Wed, 31 May 2000 06:34:45 -0700 (PDT) Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA07012 for ; Wed, 31 May 2000 06:34:41 -0700 (PDT) Received: from cdc1.cdc.informatik.tu-darmstadt.de (cdc1 [130.83.23.10]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with ESMTP id 892CD2C51; Wed, 31 May 2000 15:42:30 +0200 (MET DST) Received: by cdc1.cdc.informatik.tu-darmstadt.de (8.8.8+Sun/SMI-SVR4) id PAA25587; Wed, 31 May 2000 15:42:23 +0200 (MET DST) Date: Wed, 31 May 2000 15:42:22 +0200 From: Bodo Moeller To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Message-ID: <20000531154222.A25567@cdc.informatik.tu-darmstadt.de> References: <200005302258.PAA09379@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <200005302258.PAA09379@finney.org>; from hal@finney.org on Tue, May 30, 2000 at 03:58:57PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, May 30, 2000 at 03:58:57PM -0700, hal@finney.org wrote: > Paul Koning writes, quoting Len Sassaman: >>> Eh? If you sign my key, and then your *key* expires, your >>> signature is still included in validity calculations for my >>> key. Even after your key expires. (However, you had to sign my key >>> prior to the expiration of yours). >> Agreed; that's what I meant. (Checking the signature requires a key >> that was good at the time that signature was created. It's the >> signature that is being verified, and the date of that signature is >> what matters.) > The problem is that we don't have a mechanism for securely timestamping > signatures. If someone breaks or steals an expired key, they can create > a back-dated signature with it. > > In my opinion it is risky to rely on a signature by an expired key. Possibly, but ignoring keys on the grounds that they are expired does not buy you much because of the expiry date protocol failure in the OpenPGP key format. I've brought this up some time ago on this mailing list, here's a reminder: In the old PGP key format, key certification covers the expiration time, and all is well. (The validity period [key creation time and key expiration time] is part of the version 3 public key packet.) However, in the current OpenPGP key format, the key expiration time is covered only by self-signatures. (A version 4 public key packet cannot specify a validity period. The key validity period is in the signature packet instead.) Thus, if someone breaks or steals an expired OpenPGP key, they can renew it, and the old certificates will remain valid for the key with extended validity period or unlimited validity. Fix: Always include a signature expiration time when certifying a key that has a key expiration date in its self-signature; the time must be chosen such that the certificate's validity does not extend further into the future than the key's validity. The bottom line is that if you don't want to rely on signatures by expired keys, then you cannot rely on any certificates that don't contain a signature expiration time (unless the certified key is in a version 3 public key packet). -- Bodo Möller PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html * TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt * Tel. +49-6151-16-6628, Fax +49-6151-16-6036 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA23656 for ietf-openpgp-bks; Wed, 31 May 2000 01:36:55 -0700 (PDT) Received: from grannus.iks-jena.de (root@grannus.iks-jena.de [194.221.90.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23652 for ; Wed, 31 May 2000 01:36:53 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.10.1/8.10.1) id e4V8iac30911 for ietf-openpgp@imc.org; Wed, 31 May 2000 10:44:36 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Behavior of implementations regarding certain key material Date: 31 May 2000 08:44:35 GMT Organization: IKS GmbH Jena Lines: 23 Message-ID: References: <200005302258.PAA09379@finney.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.7 (UNIX) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * hal@finney.org wrote: >The problem is that we don't have a mechanism for securely timestamping >signatures. There are techniques to do so (eternity log, ...) but they are contraproductive on signature generation. Timestamps are optionally on reception. In most cases they are generated implicit by starting an business action. >If someone breaks or steals an expired key, they can create a back-dated >signature with it. German politics generated a (not required) appendix to the law, prohibitting specifically to back-date a computer while signing a document. So I can not happen. :-) >In my opinion it is risky to rely on a signature by an expired key. No. >PGP versions 5.0 and later do not use expired keys in trust calculations. Bad choice. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA23551 for ietf-openpgp-bks; Wed, 31 May 2000 01:28:47 -0700 (PDT) Received: from grannus.iks-jena.de (root@grannus.iks-jena.de [194.221.90.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA23547 for ; Wed, 31 May 2000 01:28:45 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.10.1/8.10.1) id e4V8aS630634 for ietf-openpgp@imc.org; Wed, 31 May 2000 10:36:28 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Behavior of implementations regarding certain key material Date: 31 May 2000 08:36:28 GMT Organization: IKS GmbH Jena Lines: 21 Message-ID: References: <14643.59826.69664.318033@xedia.com> <20000530194632.P670@djebel.gnupg.de> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.7 (UNIX) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Werner Koch wrote: >On Tue, 30 May 2000, Lutz Donnerhacke wrote: >> But certificates of expired keys are still valid. > >However, this depends on the reason of certification. No. >For example, a revocation may have been issued to express that the >key has been compromised long time in the past and therefore the >signature has never been valid. Every certificate of an revoked key is invalid. In law all certificates with has a timestamp before the key revokation timestamp are valid. German law contains a protocol error to not require the timestamp at receiver's end. >It is not easy to check this because it may be a pre-generated revocation >or a malicious revocation. Definititly. That's why the law requires a timestamp on revokation and ultimate publication. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA21055 for ietf-openpgp-bks; Tue, 30 May 2000 15:50:34 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA21051 for ; Tue, 30 May 2000 15:50:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA09379 for ietf-openpgp@imc.org; Tue, 30 May 2000 15:58:57 -0700 Date: Tue, 30 May 2000 15:58:57 -0700 Message-Id: <200005302258.PAA09379@finney.org> To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Paul Koning writes, quoting Len Sassaman: > L> Eh? If you sign my key, and then your *key* expires, your > L> signature is still included in validity calculations for my > L> key. Even after your key expires. (However, you had to sign my key > L> prior to the expiration of yours). > > Agreed; that's what I meant. (Checking the signature requires a key > that was good at the time that signature was created. It's the > signature that is being verified, and the date of that signature is > what matters.) The problem is that we don't have a mechanism for securely timestamping signatures. If someone breaks or steals an expired key, they can create a back-dated signature with it. In my opinion it is risky to rely on a signature by an expired key. PGP versions 5.0 and later do not use expired keys in trust calculations. (PGP 2.6.2 and earlier did not support key expiration.) Hal Received: by ns.secondary.com (8.9.3/8.9.3) id LAA15082 for ietf-openpgp-bks; Tue, 30 May 2000 11:29:30 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA15078 for ; Tue, 30 May 2000 11:29:29 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirli20892; Tue, 30 May 2000 18:37:09 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA03472; Tue, 30 May 00 14:33:39 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id OAA00681; Tue, 30 May 2000 14:37:07 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14644.2643.563307.132775@xedia.com> Date: Tue, 30 May 2000 14:37:07 -0400 (EDT) To: rabbi@quickie.net Cc: lutz@iks-jena.de, ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material References: <14643.64983.443333.934485@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "L" == L Sassaman writes: L> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 L> On Tue, 30 May 2000, Paul Koning wrote: >> >>>>> "Lutz" == Lutz Donnerhacke writes: >> Lutz> * Paul Koning wrote: >> >> It seems to me the logical thing to do is very easy to >> describe: >> expired or revoked certs are treated as if they were >> nonexistent. >> Lutz> But certificates of expired keys are still valid. >> For verifying old stuff, yes. Not for new stuff. So my simple >> description was too simplistic. I would apply it to things >> expired or revoked as of the creation date of whatever I want to >> verify. L> Eh? If you sign my key, and then your *key* expires, your L> signature is still included in validity calculations for my L> key. Even after your key expires. (However, you had to sign my key L> prior to the expiration of yours). Agreed; that's what I meant. (Checking the signature requires a key that was good at the time that signature was created. It's the signature that is being verified, and the date of that signature is what matters.) paul Received: by ns.secondary.com (8.9.3/8.9.3) id LAA14989 for ietf-openpgp-bks; Tue, 30 May 2000 11:24:46 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA14984 for ; Tue, 30 May 2000 11:24:45 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id LAA21884; Tue, 30 May 2000 11:32:18 -0700 Date: Tue, 30 May 2000 11:32:11 -0700 (PDT) From: "L. Sassaman" To: Paul Koning cc: lutz@iks-jena.de, ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material In-Reply-To: <14643.64983.443333.934485@xedia.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 30 May 2000, Paul Koning wrote: > >>>>> "Lutz" == Lutz Donnerhacke writes: > > Lutz> * Paul Koning wrote: > >> It seems to me the logical thing to do is very easy to describe: > >> expired or revoked certs are treated as if they were nonexistent. > > Lutz> But certificates of expired keys are still valid. > > For verifying old stuff, yes. Not for new stuff. So my simple > description was too simplistic. I would apply it to things expired or > revoked as of the creation date of whatever I want to verify. Eh? If you sign my key, and then your *key* expires, your signature is still included in validity calculations for my key. Even after your key expires. (However, you had to sign my key prior to the expiration of yours). __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5NAkyPYrxsgmsCmoRApzwAJ4j3ndnBh6zn3TzbrtwHVN1R82y0gCeIrVS r94YX2m3uWNeA/y7KXmispY= =sYh5 -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id KAA13387 for ietf-openpgp-bks; Tue, 30 May 2000 10:36:20 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA13383 for ; Tue, 30 May 2000 10:36:19 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirle24972; Tue, 30 May 2000 17:43:53 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA02615; Tue, 30 May 00 13:40:23 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id NAA00619; Tue, 30 May 2000 13:43:51 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14643.64983.443333.934485@xedia.com> Date: Tue, 30 May 2000 13:43:51 -0400 (EDT) To: lutz@iks-jena.de Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Newsgroups: iks.lists.ietf-open-pgp References: <14643.59826.69664.318033@xedia.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Lutz" == Lutz Donnerhacke writes: Lutz> * Paul Koning wrote: >> It seems to me the logical thing to do is very easy to describe: >> expired or revoked certs are treated as if they were nonexistent. Lutz> But certificates of expired keys are still valid. For verifying old stuff, yes. Not for new stuff. So my simple description was too simplistic. I would apply it to things expired or revoked as of the creation date of whatever I want to verify. paul Received: by ns.secondary.com (8.9.3/8.9.3) id KAA12967 for ietf-openpgp-bks; Tue, 30 May 2000 10:27:18 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA12963 for ; Tue, 30 May 2000 10:27:16 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12wq64-00019J-00; Tue, 30 May 2000 19:46:32 +0200 Date: Tue, 30 May 2000 19:46:32 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material Message-ID: <20000530194632.P670@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <14643.59826.69664.318033@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: ; from lutz@iks-jena.de on Tue, May 30, 2000 at 04:39:45PM +0000 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 30 May 2000, Lutz Donnerhacke wrote: > But certificates of expired keys are still valid. However, this depends on the reason of certification. I am not sure whether the codes we already have for this are sufficient to automatically determine whether the cerificate is still valid. For example, a revocation may have been issued to express that the key has been compromised long time in the past and therefore the signature has never been valid. It is not easy to check this because it may be a pre-generated revocation or a malicious revocation. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id JAA11590 for ietf-openpgp-bks; Tue, 30 May 2000 09:32:10 -0700 (PDT) Received: from grannus.iks-jena.de (root@grannus.iks-jena.de [194.221.90.36]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA11585 for ; Tue, 30 May 2000 09:32:08 -0700 (PDT) Received: (from news@localhost) by grannus.iks-jena.de (8.10.1/8.10.1) id e4UGdkn29582 for ietf-openpgp@imc.org; Tue, 30 May 2000 18:39:46 +0200 To: ietf-openpgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: Behavior of implementations regarding certain key material Date: 30 May 2000 16:39:45 GMT Organization: IKS GmbH Jena Lines: 5 Message-ID: References: <14643.59826.69664.318033@xedia.com> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.7 (UNIX) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * Paul Koning wrote: >It seems to me the logical thing to do is very easy to describe: >expired or revoked certs are treated as if they were nonexistent. But certificates of expired keys are still valid. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA10985 for ietf-openpgp-bks; Tue, 30 May 2000 09:10:29 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA10981 for ; Tue, 30 May 2000 09:10:27 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQirkz11470; Tue, 30 May 2000 16:17:55 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA01477; Tue, 30 May 00 12:14:25 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id MAA00554; Tue, 30 May 2000 12:17:54 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14643.59826.69664.318033@xedia.com> Date: Tue, 30 May 2000 12:17:54 -0400 (EDT) To: Florian.Weimer@RUS.Uni-Stuttgart.DE Cc: jon@callas.org, ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Florian" == Florian Weimer writes: Florian> Jon Callas writes: >> At 10:46 AM +0200 5/26/00, Florian Weimer wrote: >From >> draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for >> >Revocation": > >| A revoked certification no longer is a part of >> validity >| calculations. > >We were a bit surprised when we >> discovered this change to RFC 2440 >because RFC 2440 primarily >> specifies the OpenPGP message format, >and not the behavior of >> implementations when they encounter certain >OpenPGP messages, >> much to our discomfort. > >> >> Umm, so what is the problem? Is there a reason that a revoked >> certification *should* be part of validity calculations? Florian> No, of course not. Our point is: There is no reason why an Florian> expired certification should be part of validity Florian> calculations, either (at least by default). Ditto for Florian> expired keys. But 2440bis does not state what to do in Florian> these cases, and in fact, implementations already show Florian> different behavior. It seems to me the logical thing to do is very easy to describe: expired or revoked certs are treated as if they were nonexistent. paul Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07855 for ietf-openpgp-bks; Tue, 30 May 2000 07:40:45 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07845 for ; Tue, 30 May 2000 07:40:40 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12wnIh-0006tR-00; Tue, 30 May 2000 16:47:23 +0200 To: "William H. Geiger III" Cc: Jon Callas , ietf-openpgp@imc.org, goebel@RUS.Uni-Stuttgart.DE Subject: Re: Behavior of implementations regarding certain key material References: <200005300108.VAA30353@domains.invweb.net> From: Florian Weimer Date: 30 May 2000 16:47:23 +0200 In-Reply-To: "William H. Geiger III"'s message of "Mon, 29 May 2000 19:44:35 -0500" Message-ID: Lines: 55 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 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: "William H. Geiger III" writes: > Why can't you set an expiration time for the signature? This would seem > the optimal way to do this. AFAIK, there are implementations which use expired certificates in validity calculations. The certificate is used once to propagate trust, and if the neighborhood of the web of trust doesn't change, nothing happens if a certificate expires. > Well either you need to have some standardization or you are going to have > everyone doing their own thing. I believe that everyone shall build his own web of trust as he sees fit, but that's more a political statement than a technical one, of course. But I do want to have control over the validity of certificates issued by myself, that's the reason why I think that some standardization (i.e. some necessary (but not sufficient) conditions for certificate and key validity) are very useful. > While I don't think a rigid RFC would be > needed I do think a separate informational RFC would be advised. Yes, that was our internal conclusion as well. Oliver Goebel is preparing such a document. In addition, the document will contain recommendations for interactive OpenPGP implementations in borderline situations (just as an example, what to do if a chain of trust can be established to a key, but some of the links are expired certificates? -- the user should be given the choice not to use the key, use it anyway, or sign it locally to prevent future questions). > From the point of view of interoperability it will be important for > developers to know how the WoT is being handled by the various vendors. > The major issue is keyring sharing. I don't think this is a problem. Vendors can provide suitable conversion programs. In fact, OpenPGP implies a rather canonical key ring exchange format (simple concatenation of keys), and I think all OpenPGP implementation can handle this format. On the other hand, say if a secret key is protected by a passphrase and OpenPGP-optional symmetric cipher, there will always be implementations which cannot do anything useful with it, simply because the actual key material is protected by an unsupported cipher. (Direct key ring sharing doesn't make sense anyway because the actual key ring data structure depends heavily on the given application. Locking is another issue.) -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12346 for ietf-openpgp-bks; Mon, 29 May 2000 18:00:38 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA12335 for ; Mon, 29 May 2000 18:00:36 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id VAA30353; Mon, 29 May 2000 21:08:01 -0400 Message-Id: <200005300108.VAA30353@domains.invweb.net> From: "William H. Geiger III" Date: Mon, 29 May 2000 19:44:35 -0500 To: Florian Weimer In-Reply-To: Cc: Jon Callas , ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In , on 05/27/00 at 10:49 AM, Florian Weimer said: >Jon Callas writes: >> At 10:46 AM +0200 5/26/00, Florian Weimer wrote: >> >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for >> >Revocation": >> > >> >| A revoked certification no longer is a part of validity >> >| calculations. >> > >> >We were a bit surprised when we discovered this change to RFC 2440 >> >because RFC 2440 primarily specifies the OpenPGP message format, >> >and not the behavior of implementations when they encounter certain >> >OpenPGP messages, much to our discomfort. >> > >> >> Umm, so what is the problem? Is there a reason that a revoked certification >> *should* be part of validity calculations? >No, of course not. Our point is: There is no reason why an expired >certification should be part of validity calculations, either (at least >by default). Ditto for expired keys. But 2440bis does not state what to >do in these cases, and in fact, implementations already show different >behavior. This is quite annoying if you want to limit in time the >validity of your certificates. In the past, the only way to do that was >to revoke the certifying keys (yuk!); with 2440bis, you have to revoke >the certificates. Both options lead to a quickly growing CRL, which is >very suboptimal. Why can't you set an expiration time for the signature? This would seem the optimal way to do this. >Just to make one thing clear: We do not want to standardize the validity >calculations themselves, nor the way the web of trust is built. But we >do want to have a set of conditions under which a certificate or a key >won't be considered by validity calculations at all. Well either you need to have some standardization or you are going to have everyone doing their own thing. While I don't think a rigid RFC would be needed I do think a separate informational RFC would be advised. >From the point of view of interoperability it will be important for developers to know how the WoT is being handled by the various vendors. The major issue is keyring sharing. Take the situation of 5 OpenPGP vendors developing both standalone and application integration products. Either the vendors must require the end user to make use of separate keyrings or there must be some documentation in this area so the various vendor products can share keyrings. -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id EAA06316 for ietf-openpgp-bks; Sun, 28 May 2000 04:44:09 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA06311 for ; Sun, 28 May 2000 04:44:07 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12w1vd-0000uX-00; Sun, 28 May 2000 14:12:25 +0200 Date: Sun, 28 May 2000 14:12:25 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Message-ID: <20000528141224.G3158@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: ; from jon@callas.org on Fri, May 26, 2000 at 05:10:36PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 26 May 2000, Jon Callas wrote: > If I were really going to roto-till the spec, I'd get rid of key ids > altogether and only use fingerprints. There have already been problems with I'd second this. However, the user will not see a difference as we can still present him a keyID, although we are not using it anymore. Using the keyID as a way to select a key is still a nice feature because typing the whole fingerprint is not that easy. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA24215 for ietf-openpgp-bks; Sat, 27 May 2000 19:09:32 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA24210 for ; Sat, 27 May 2000 19:09:29 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 16776 invoked from network); 28 May 2000 02:12:46 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 28 May 2000 02:12:46 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: References: <200005160251.WAA14064@finney.org> <20000516153807Y.1001@eccosys.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000528111654A.1001@eccosys.com> Date: Sun, 28 May 2000 11:16:54 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 102 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Jon Callas Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Fri, 26 May 2000 17:52:22 -0700 Message-ID: > Does anyone want to suggest wording on this? below is one attempt. p.s. there are other sections that i think could be made clearer. are people amenable to receiving other suggestions for wording as well? 3.6.1.1. Simple S2K This directly hashes the string to produce the key data. See below for how this hashing is done. Octet 0: 0x00 Octet 1: hash algorithm Simple S2K hashes the passphrase to produce the session key. The manner in which this is done depends on the size of the session key (which will depend on the cipher used) and the size of the hash algorithm's output. If the hash size is greater than or equal to the session key size, the high-order (leftmost) octets of the hash are used as the key. If the hash size is less than the key size, the key is determined as the result of the concatenation of multiple hash values -- enough to produce the required key data. Prior to each hash calculation, an appropriate number of octets of zeros are prepended to the data (in this case, the passphrase): hash(data) hash(0, data) hash(0, 0, data) ... and so on i.e. no prepending for the first hash computation, prepending one octet for the second hash computation, and thereafter increasing the number of prepended octets of zeros by one for each subsequent hash computation. The hash results are concatenated, first hash leftmost, to produce the key data, with any excess octets on the right discarded. Note that each hash computation should produce different output since in each case a different sequence of octets is hashed. 3.6.1.2. Salted S2K This includes a "salt" value in the S2K specifier -- some arbitrary data -- that gets hashed along with the passphrase string, to help prevent dictionary attacks. Octet 0: 0x01 Octet 1: hash algorithm Octets 2-9: 8-octet salt value Salted S2K is exactly like Simple S2K, except that the input to the hash function(s) consists of an appropriate number of octets of zeros, 8 octets of salt from the S2K specifier, followed by the passphrase. 3.6.1.3. Iterated and Salted S2K This includes both a salt and an octet count. The salt is combined with the passphrase repeatedly depending on the octet count, and the resulting value is hashed. This further increases the amount of work an attacker must do to try dictionary attacks. Octet 0: 0x03 Octet 1: hash algorithm Octets 2-9: 8-octet salt value Octet 10: count, a one-octet, coded value The count is coded into a one-octet number using the following formula: #define EXPBIAS 6 count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); The above formula is in C, where "Int32" is a type for a 32-bit integer, and the variable "c" is the coded count, Octet 10. The input to the hash function(s) is determined in the following manner. First, concatenate the 8 octets of salt from the S2K specifier and the passphrase. If the total length of the result is less than the count obtained by the above formula, concatenate sufficient octets from the salt and/or the passphrase such that the length of the resulting sequence is exactly equal to the count. Finally, prepend an appropriate number of octets of zeros: zero(s), salt, passphrase, salt, passphrase, salt, ... <--------------- count octets --------------> Note that the count does not apply to the number of prepended octets of zeros. Also, if the octet count is less than the size of the salt plus passphrase, the full salt plus passphrase will be hashed even though that is greater than the octet count. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA01695 for ietf-openpgp-bks; Sat, 27 May 2000 01:42:24 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA01689 for ; Sat, 27 May 2000 01:42:22 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12vcHZ-0005dK-00; Sat, 27 May 2000 10:49:21 +0200 To: Jon Callas Cc: ietf-openpgp@imc.org Subject: Re: Behavior of implementations regarding certain key material References: From: Florian Weimer Date: 27 May 2000 10:49:21 +0200 In-Reply-To: Jon Callas's message of "Fri, 26 May 2000 16:47:25 -0700" Message-ID: Lines: 39 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > At 10:46 AM +0200 5/26/00, Florian Weimer wrote: > >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for > >Revocation": > > > >| A revoked certification no longer is a part of validity > >| calculations. > > > >We were a bit surprised when we discovered this change to RFC 2440 > >because RFC 2440 primarily specifies the OpenPGP message format, > >and not the behavior of implementations when they encounter certain > >OpenPGP messages, much to our discomfort. > > > > Umm, so what is the problem? Is there a reason that a revoked certification > *should* be part of validity calculations? No, of course not. Our point is: There is no reason why an expired certification should be part of validity calculations, either (at least by default). Ditto for expired keys. But 2440bis does not state what to do in these cases, and in fact, implementations already show different behavior. This is quite annoying if you want to limit in time the validity of your certificates. In the past, the only way to do that was to revoke the certifying keys (yuk!); with 2440bis, you have to revoke the certificates. Both options lead to a quickly growing CRL, which is very suboptimal. Just to make one thing clear: We do not want to standardize the validity calculations themselves, nor the way the web of trust is built. But we do want to have a set of conditions under which a certificate or a key won't be considered by validity calculations at all. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 Received: by ns.secondary.com (8.9.3/8.9.3) id VAA14857 for ietf-openpgp-bks; Fri, 26 May 2000 21:01:38 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA14853 for ; Fri, 26 May 2000 21:01:36 -0700 (PDT) Received: from [63.73.97.188] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Fri, 26 May 2000 21:08:56 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000516153807Y.1001@eccosys.com> References: <200005160251.WAA14064@finney.org> <20000516153807Y.1001@eccosys.com> Date: Fri, 26 May 2000 17:52:22 -0700 To: sen_ml@eccosys.com, ietf-openpgp@imc.org From: Jon Callas Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does anyone want to suggest wording on this? Jon Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19584 for ietf-openpgp-bks; Fri, 26 May 2000 17:32:14 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19580 for ; Fri, 26 May 2000 17:32:13 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA05234 for ; Fri, 26 May 2000 17:39:05 -0700 (PDT) Received: from [63.73.97.188] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA05230 for ; Fri, 26 May 2000 17:39:04 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: Date: Fri, 26 May 2000 17:10:36 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: KeyID as left vs right substring of fingerprint Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I think it really is just aesthetics whether you use the left or right bits as a key id. I also believe that the left bits are the more aesthetic ones to use, and I say that as a confirmed little-endian. I'll also concur that the key server can use whatever bytes it wants. That's no biggie. If I were to make a V5 key structure, the thing I'd change would be *not* to include the key creation time in with the SHA-1 hash for the fingerprint. This was unfortunate. It means that two keys that have the same key material, but different creation times have different key ids. At one time I thought this was a feature, and I've come to believe it's a bug. If I were really going to roto-till the spec, I'd get rid of key ids altogether and only use fingerprints. There have already been problems with key id collisions, and it would be much better to just use fingerprints. We already say that you SHOULD NOT assume they're unique, but arguably that really should be MUST NOT. However, I think that none of those changes can be made. There comes a point in any protocol's life where you just live with the warts because correcting them causes more problems. The key id selection is one of those. If we change things, we add more cruft into a system that already has cruft in it. There is already a separate algorithm for V3 keys and V4 keys. This would give us another one, and one that exists for no good reason. And as Hal has mentioned, the proper proper fix would be to make the UI that shows a 32 bit key id show the left 32 bits rather than the right ones. Fortunately, we've managed to bury that issue completely and not even mention them. 32 bit key ids only exist in implementations. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id RAA19223 for ietf-openpgp-bks; Fri, 26 May 2000 17:02:16 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA19219 for ; Fri, 26 May 2000 17:02:15 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA05051; Fri, 26 May 2000 17:09:07 -0700 (PDT) Received: from [63.73.97.188] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA05047; Fri, 26 May 2000 17:09:07 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: Date: Fri, 26 May 2000 16:47:25 -0700 To: Florian Weimer , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Behavior of implementations regarding certain key material Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:46 AM +0200 5/26/00, Florian Weimer wrote: >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for >Revocation": > >| A revoked certification no longer is a part of validity >| calculations. > >We were a bit surprised when we discovered this change to RFC 2440 >because RFC 2440 primarily specifies the OpenPGP message format, >and not the behavior of implementations when they encounter certain >OpenPGP messages, much to our discomfort. > Umm, so what is the problem? Is there a reason that a revoked certification *should* be part of validity calculations? You're correct that 2440 is a syntax document, not a semantics document. However, there are times when you have to hint at semantics when you're describing syntax. In this particular case, OpenPGP does not specify a trust model. At one time, there were going to be a series of documents describing various trust models that one might use (for example, the so-called web of trust), but no one has seen fit to write these documents. However, even though we don't specify what validity calculations to use, there are nonetheless syntactic things we have to say about them. Whatever validity model you're using, it seems pretty straight forward that a revoked certification is null and void. That's all this is saying. It's in 2440bis because consensus asked that it be there. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12691 for ietf-openpgp-bks; Fri, 26 May 2000 12:43:59 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12687 for ; Fri, 26 May 2000 12:43:58 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA01616; Fri, 26 May 2000 12:51:04 -0700 Date: Fri, 26 May 2000 12:50:56 -0700 (PDT) From: "L. Sassaman" To: Marc Horowitz cc: Jon Callas , hal@finney.org, ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 26 May 2000, Marc Horowitz wrote: > "L. Sassaman" writes: > > >> It's not just aesthetics. This issue was brought up by Marc Horowitz at > >> the Keyserver Symposium this week. He thinks that it could have a positive > >> impact on the internal workings of the keyservers, and would simplfy > >> seaches for the user. > > I think Len is putting words in my mouth. I do have some ideas which > came out of the meeting for changes which would have a positive impact > on the internal workings of the keyservers, and on the externally > visible functioning of the network as a whole, but changing how keyids > are generated and interpreted isn't one of them. Sorry about that. I didn't mean to imply you suggested we change the keyids (though I see that my paragraph above looks like I meant that). But, if I am recalling correctly, you had thought it was something that "would have been nice" if done the way Phil had wanted. But then again, my recollection might be totally wrong... ;) > To address Phil's concerns as described by Hal, there's no reason that > you couldn't use the variable rightmost N bits of the fingerprint to > identify a key with arbitrary specificity today. For people's > keyrings, the linear search won't take any more or less time. For the > keyserver, if people wanted this feature, it would be possible to > start keeping an index of the fingerprint in reverse bit order. > Changes would be necessary in the keyserver to support lookup by > anything but a fixed position+length of the fingerprint, anyway. This > isn't pretty, but it would be complexity hidden from the user. Completely hidden from the user, but not as fluid as a leftmost keyid. Expanding from the right is less natural to users whose language reads from left to right, in my opinion. > I agree with everyone else that using the leftmost N bits would have > been prettier, but isn't strictly necessary. Then it is probably best to leave this as it is, and not make the change. Unless Jon can think of other things this group has discussed that would justify a v5 key format on their own... - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LtWnPYrxsgmsCmoRAlfFAKCjFRkgdgNdvwbZNdeRrJT1Nj+0dwCfYlZG BLYGxke/wOSIDhOtUwfDG8A= =ALY3 -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12634 for ietf-openpgp-bks; Fri, 26 May 2000 12:37:56 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12630 for ; Fri, 26 May 2000 12:37:54 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id MAA01586; Fri, 26 May 2000 12:45:12 -0700 Date: Fri, 26 May 2000 12:45:05 -0700 (PDT) From: "L. Sassaman" To: "David P. Kemp" cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: <200005261309.JAA11870@roadblock.missi.ncsc.mil> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 26 May 2000, David P. Kemp wrote: > Can someone explain the rationale for preferring to use one portion > of a fingerprint rather than another as a key id? > > My interest is academic rather than strictly PGP related. > X.509 also uses key ids which are profiled to be fixed sized fields > containing a hash value, so the situation is not unique to PGP. My > assumption is that: 1) no particular bits of a good cryptographic hash > algorithm have any better collision resistance properties than any > other bits, and 2) there is no significant computation savings in > generating only a subset of the hash output, much less a difference in > generating only high bits vs. only low bits. > > Is this assumption wrong, or are there other reasons that using the low > n bits of the output of a cryptographic hash as a key id is a blunder? > It would be unfortunate if the same mistake were repeated elsewhere. The issue here wasn't a technical one, but an "ease-of-use" one really. If you obtain the keyid from the left of the fingerprint, it is easier for the user to adjust the length of the keyid when necessary. I am further assuming that your two assumptions are correct. The only benefit I see here is the ability to dynamically adjust the size of the "keyid" when searching for keys on a server or keyring, and when encrypting to keys. > Dave Kemp > > (I considered the possiblity that the message from Hal was dated > 1 April and was delayed in transit, and verified that it was not.) Hah! :) - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LtRIPYrxsgmsCmoRAhAxAJ9JWzu5KVmFSQEMQsNQO0MYDfHk2gCfbPyz pKayJ94WJ/ETUnaYZNlfVa4= =8+MS -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12466 for ietf-openpgp-bks; Fri, 26 May 2000 12:26:46 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12462 for ; Fri, 26 May 2000 12:26:45 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqws22413; Fri, 26 May 2000 19:34:04 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24989; Fri, 26 May 00 15:30:36 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA14338; Fri, 26 May 2000 15:34:02 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14638.53674.708069.953816@xedia.com> Date: Fri, 26 May 2000 15:34:02 -0400 (EDT) To: rabbi@quickie.net Cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint References: X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "L" == L Sassaman writes: L> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 L> On Thu, 25 May 2000, Jon Callas wrote: >> If this blunder needs to be fixed, the correct way to fix it is to >> make a V5 key structure. (For that matter, there are a couple >> other things I'd fix, too, if we made a V5 key structure.) >> However, I think that as unfortunate as this is, simplicity and >> compatibility override aesthetics, and we should just live with >> things as they are. L> It's not just aesthetics. This issue was brought up by Marc L> Horowitz at the Keyserver Symposium this week. He thinks that it L> could have a positive impact on the internal workings of the L> keyservers,... That doesn't compute. If key servers want to have "high order" bits used as lookup index, perhaps so standard database mechanisms that search for "match on leading bits" can be used, that's fine. This does NOT require a protocol change! A key server is perfectly well entitled to swizzle the data around in any way it chooses for its own convenience; all that is expected of it is that it unswizzles it before sending it back out. So if it's good for key servers, let the key servers internally turn the fingerprint end for end. Trivial coding and no protocol change needed. Not only that, but if you use a different database where this approach is not useful, or even counterproductive, or a different optimization is better, then you just do something else instead. But all of this is an internal implementation detail. paul Received: by ns.secondary.com (8.9.3/8.9.3) id MAA12321 for ietf-openpgp-bks; Fri, 26 May 2000 12:19:17 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA12317 for ; Fri, 26 May 2000 12:19:16 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiqwr15275; Fri, 26 May 2000 19:26:34 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24887; Fri, 26 May 00 15:23:06 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id PAA14333; Fri, 26 May 2000 15:26:32 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14638.53224.634970.847559@xedia.com> Date: Fri, 26 May 2000 15:26:32 -0400 (EDT) To: jon@callas.org Cc: hal@finney.org, ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint References: <200005251645.JAA11926@finney.org> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Jon" == Jon Callas writes: Jon> I agree that in retrospect, it would have been better to have Jon> the key id be the high-order bits of the fingerprint rather than Jon> the low-order bits. I, too, think this was a mistake. However, Jon> that decision was made before this working group was Jon> formed. (And before I joined PGP, Inc. for that matter.) Jon> I believe that changing this and making it be dependent on the Jon> algorithm type would be utterly wrong. It would add one more Jon> little gnarly bit into a system that is already filled with too Jon> many gnarly bits. I agree that it should not be changed. For that matter, I am thoroughly puzzled why anyone would say that it's better to use high order bits than low order bits. We're talking about taking a subset of the bits of a hash function, right? Any old subset is as good as any other. A random subset of the bits would be just as good, or just as bad, as the high order bits, or the low order bits. paul Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09697 for ietf-openpgp-bks; Fri, 26 May 2000 09:52:37 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09693 for ; Fri, 26 May 2000 09:52:35 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12vNmW-0004wY-00; Fri, 26 May 2000 19:20:20 +0200 Date: Fri, 26 May 2000 19:20:20 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Message-ID: <20000526192020.D17672@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200005261506.IAA16864@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <200005261506.IAA16864@finney.org>; from hal@finney.org on Fri, May 26, 2000 at 08:06:13AM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 26 May 2000, hal@finney.org wrote: > Or of course we could leave it as it is now. I am still not convinced Yes, please. There is not that much difference in the code for either of the ones. Adding code for taking the keyid from the left side just adds more complexity in terms of backward compatibilty and we already have so much code just for backword issues. > that the universe is constructed such that left substrings are inherently > more natural than right ones. Endian wars, anyone? No, thanks. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id IAA08576 for ietf-openpgp-bks; Fri, 26 May 2000 08:52:30 -0700 (PDT) Received: from excalibur.iks-jena.de (root@excalibur.iks-jena.de [194.221.90.35]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA08571 for ; Fri, 26 May 2000 08:52:29 -0700 (PDT) Received: from taranis.iks-jena.de (taranis.iks-jena.de [194.221.90.21]) by excalibur.iks-jena.de (8.10.1/8.10.1) with ESMTP id e4QFxmH24367 for ; Fri, 26 May 2000 17:59:48 +0200 Received: (from lutz@localhost) by taranis.iks-jena.de (8.10.1/8.10.1) id e4QFw6C01585 for ietf-openpgp@imc.org; Fri, 26 May 2000 17:58:06 +0200 X-Envelope-To: ietf-open-pgp@imc.org Received: (from news@localhost) by grannus.iks-jena.de (8.10.1/8.10.1) id e4QFe8l30076 for ietf-open-pgp@imc.org; Fri, 26 May 2000 17:40:08 +0200 To: ietf-open-pgp@imc.org Path: lutz From: lutz@iks-jena.de (Lutz Donnerhacke) Newsgroups: iks.lists.ietf-open-pgp Subject: Re: KeyID as left vs right substring of fingerprint Date: 26 May 2000 15:40:07 GMT Organization: IKS GmbH Jena Lines: 13 Message-ID: References: <200005261506.IAA16864@finney.org> NNTP-Posting-Host: taranis.iks-jena.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: slrn/0.9.5.7 (UNIX) Status: RO Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: * hal@finney.org wrote: [Problem of retrieving] >However, in the circumstances above where this arises, we don't know >the key's version number. We have only the algorithm id and the keyid. >So we can't base the decision on anything other than the algorithm id. So I urge to keep the current mechanism. Key IDs may expand to the left. >Or of course we could leave it as it is now. I am still not convinced >that the universe is constructed such that left substrings are inherently >more natural than right ones. Endian wars, anyone? Exactly. Keep it or run in trouble. * hal@finney.org wrote: [Problem of retrieving] >However, in the circumstances above where this arises, we don't know >the key's version number. We have only the algorithm id and the keyid. >So we can't base the decision on anything other than the algorithm id. So I urge to keep the current mechanism. Key IDs may expand to the left. >Or of course we could leave it as it is now. I am still not convinced >that the universe is constructed such that left substrings are inherently >more natural than right ones. Endian wars, anyone? Exactly. Keep it or run in trouble. Received: by ns.secondary.com (8.9.3/8.9.3) id HAA07305 for ietf-openpgp-bks; Fri, 26 May 2000 07:57:40 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA07301 for ; Fri, 26 May 2000 07:57:39 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA16864 for ietf-openpgp@imc.org; Fri, 26 May 2000 08:06:13 -0700 Date: Fri, 26 May 2000 08:06:13 -0700 Message-Id: <200005261506.IAA16864@finney.org> To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There is one possibly minor technical problem with making the change. Presently some of the pgp clients display only 32 bits of the 64 bit keyid. This might be done for example if they receive a message encrypted to or signed by a key they don't know. In that case they have the 64 bit keyid but they sometimes only display 32 bits because that is a more manageable size for humans. Manual key server searches have also supported 32 bit keyids. With keyids as the right substring of both V3 RSA moduli and V4 fingerprints, it is most logical to use the right 32 bits of the 64 bits for this purpose, and that is how it has been done. If some keys start using left substrings, then it would be awkward to continue to use the right 32 bits of the keyid as the short form. This would end up being bits 32-63 of the fingerprint. For keys that use left substrings, it would be more appropriate to use the left 32 bits of the 64 as the short form of the keyid. However, in the circumstances above where this arises, we don't know the key's version number. We have only the algorithm id and the keyid. So we can't base the decision on anything other than the algorithm id. There are a few possible solutions. We could eliminate the 32-bit keyid display entirely, and only show and input 64 bit keyids. This is really a UI issue which is outside the scope of this group, and while we have no obligation to support any particular shortening of keyids, I think we should be aware of the impact our decisions make on other parts of the system. We could make the decision about which way to shorten it depend entirely on the key algorithm, so that we'd need a new algorithm identifier for RSA keys which used the new convention. We could make new signature and pkesk packets which include more information about the keyid, enough to allow it to be shortened unambiguously (and perhaps supporting variable length keyids). Or of course we could leave it as it is now. I am still not convinced that the universe is constructed such that left substrings are inherently more natural than right ones. Endian wars, anyone? Hal Received: by ns.secondary.com (8.9.3/8.9.3) id GAA02977 for ietf-openpgp-bks; Fri, 26 May 2000 06:07:37 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (roadblock.missi.ncsc.mil [144.51.50.70]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02972 for ; Fri, 26 May 2000 06:07:36 -0700 (PDT) Received: from roadblock.missi.ncsc.mil (root@localhost) by roadblock.missi.ncsc.mil with ESMTP id JAA11877 for ; Fri, 26 May 2000 09:09:07 -0400 (EDT) Message-Id: <200005261309.JAA11870@roadblock.missi.ncsc.mil> Date: Fri, 26 May 2000 09:12:13 -0400 (EDT) From: "David P. Kemp" Reply-To: "David P. Kemp" Subject: Re: KeyID as left vs right substring of fingerprint To: ietf-openpgp@imc.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: mmVajd5lUQd7KC36Tdej6w== X-Mailer: dtmail 1.3.0 CDE Version 1.3 SunOS 5.7 sun4u sparc Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Can someone explain the rationale for preferring to use one portion of a fingerprint rather than another as a key id? My interest is academic rather than strictly PGP related. X.509 also uses key ids which are profiled to be fixed sized fields containing a hash value, so the situation is not unique to PGP. My assumption is that: 1) no particular bits of a good cryptographic hash algorithm have any better collision resistance properties than any other bits, and 2) there is no significant computation savings in generating only a subset of the hash output, much less a difference in generating only high bits vs. only low bits. Is this assumption wrong, or are there other reasons that using the low n bits of the output of a cryptographic hash as a key id is a blunder? It would be unfortunate if the same mistake were repeated elsewhere. Dave Kemp (I considered the possiblity that the message from Hal was dated 1 April and was delayed in transit, and verified that it was not.) > Date: Thu, 25 May 2000 17:28:41 -0700 > To: hal@finney.org, ietf-openpgp@imc.org > From: Jon Callas > Subject: Re: KeyID as left vs right substring of fingerprint > > I agree that in retrospect, it would have been better to have the key id be > the high-order bits of the fingerprint rather than the low-order bits. I, > too, think this was a mistake. However, that decision was made before this > working group was formed. (And before I joined PGP, Inc. for that matter.) > > I believe that changing this and making it be dependent on the algorithm > type would be utterly wrong. It would add one more little gnarly bit into a > system that is already filled with too many gnarly bits. > > If this blunder needs to be fixed, the correct way to fix it is to make a > V5 key structure. (For that matter, there are a couple other things I'd > fix, too, if we made a V5 key structure.) However, I think that as > unfortunate as this is, simplicity and compatibility override aesthetics, > and we should just live with things as they are. > > Jon > > > > ***************************************************************************** > This confirms that this email message has been swept by > MIMEsweeper for the presence of computer viruses. > ****************************************************************************** Received: by ns.secondary.com (8.9.3/8.9.3) id GAA02961 for ietf-openpgp-bks; Fri, 26 May 2000 06:07:27 -0700 (PDT) Received: from horowitz.ne.mediaone.net (horowitz.ne.mediaone.net [24.147.233.208]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA02956 for ; Fri, 26 May 2000 06:07:25 -0700 (PDT) Received: (from marc@localhost) by horowitz.ne.mediaone.net (8.8.8/8.8.8) id JAA16322; Fri, 26 May 2000 09:14:40 -0400 (EDT) From: Marc Horowitz To: "L. Sassaman" Cc: Jon Callas , hal@finney.org, ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint References: Date: 26 May 2000 09:14:40 -0400 In-Reply-To: "L. Sassaman"'s message of "Fri, 26 May 2000 00:45:14 -0700 (PDT)" Message-ID: Lines: 27 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "L. Sassaman" writes: >> It's not just aesthetics. This issue was brought up by Marc Horowitz at >> the Keyserver Symposium this week. He thinks that it could have a positive >> impact on the internal workings of the keyservers, and would simplfy >> seaches for the user. I think Len is putting words in my mouth. I do have some ideas which came out of the meeting for changes which would have a positive impact on the internal workings of the keyservers, and on the externally visible functioning of the network as a whole, but changing how keyids are generated and interpreted isn't one of them. To address Phil's concerns as described by Hal, there's no reason that you couldn't use the variable rightmost N bits of the fingerprint to identify a key with arbitrary specificity today. For people's keyrings, the linear search won't take any more or less time. For the keyserver, if people wanted this feature, it would be possible to start keeping an index of the fingerprint in reverse bit order. Changes would be necessary in the keyserver to support lookup by anything but a fixed position+length of the fingerprint, anyway. This isn't pretty, but it would be complexity hidden from the user. I agree with everyone else that using the leftmost N bits would have been prettier, but isn't strictly necessary. Marc Received: by ns.secondary.com (8.9.3/8.9.3) id BAA09987 for ietf-openpgp-bks; Fri, 26 May 2000 01:40:42 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA09983 for ; Fri, 26 May 2000 01:40:34 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12vFlW-0005AW-00 for ietf-openpgp@imc.org; Fri, 26 May 2000 10:46:46 +0200 To: ietf-openpgp@imc.org Subject: Behavior of implementations regarding certain key material From: Florian Weimer Date: 26 May 2000 10:46:46 +0200 Message-ID: Lines: 26 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >From draft-ietf-openpgp-rfc2440bis-00, 5.2.3.23, "Reason for Revocation": | A revoked certification no longer is a part of validity | calculations. We were a bit surprised when we discovered this change to RFC 2440 because RFC 2440 primarily specifies the OpenPGP message format, and not the behavior of implementations when they encounter certain OpenPGP messages, much to our discomfort. We would like to see other requirements such as "An expired certification is no longer part of validity calculations." If you are running a CA, you certainly want all implementations to react to certfication expiration, certifying key expiration, certication revocation etc. in the same manner. If you agree that this should be addressed, we can document additional requirements which make sense from our point of view as a basis for further discussion. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA07407 for ietf-openpgp-bks; Fri, 26 May 2000 01:14:02 -0700 (PDT) Received: from sobolev.does-not-exist.org (postfix@[208.161.253.61]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA07397 for ; Fri, 26 May 2000 01:13:58 -0700 (PDT) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 06EA82ED43; Fri, 26 May 2000 10:21:10 +0200 (CEST) Date: Fri, 26 May 2000 10:21:09 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint Message-ID: <20000526102109.A19772@sobolev.tlr-net.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.2i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-05-25 09:45:24 -0700, hal@finney.org wrote: > The only keys that used right substrings would be > "legacy" DSA and ElGamal keys (assuming that no one > else has implemented RSA V4 keys, which I am not sure > about). We might do some kind of upgrade to DSA keys > when the new larger hash is announced later this year, > and they could switch at that time. Maybe some > arbitrary change could be made to ElGamal as well. If things absolutely have to be changed in an incompatible way, please use a different packet version (say, V5) for this, so old software nicely breaks on it. Everything else will lead to considerable confusion of users and software. -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id AAA04942 for ietf-openpgp-bks; Fri, 26 May 2000 00:38:13 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04936 for ; Fri, 26 May 2000 00:38:12 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA31449; Fri, 26 May 2000 00:45:23 -0700 Date: Fri, 26 May 2000 00:45:14 -0700 (PDT) From: "L. Sassaman" To: Jon Callas cc: hal@finney.org, marc@mit.edu, ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 25 May 2000, Jon Callas wrote: > If this blunder needs to be fixed, the correct way to fix it is to make a > V5 key structure. (For that matter, there are a couple other things I'd > fix, too, if we made a V5 key structure.) However, I think that as > unfortunate as this is, simplicity and compatibility override aesthetics, > and we should just live with things as they are. It's not just aesthetics. This issue was brought up by Marc Horowitz at the Keyserver Symposium this week. He thinks that it could have a positive impact on the internal workings of the keyservers, and would simplfy seaches for the user. However, I do agree that we should not break more than we fix. If the benefits of doing keyids this way do not outweigh the drawbacks, we probably shouldn't do it. Out of curiosity, what are the other things you would like to fix, given the chance to do a v5 key structure? __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LiuSPYrxsgmsCmoRAktoAKCdXFz9MP7vfldurisfwVJq4Buy6ACeJKzT 4LIaiqkmfXE8vR82E436k1s= =sdRU -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA04321 for ietf-openpgp-bks; Fri, 26 May 2000 00:28:28 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA04316 for ; Fri, 26 May 2000 00:28:26 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA31411; Fri, 26 May 2000 00:35:39 -0700 Date: Fri, 26 May 2000 00:35:31 -0700 (PDT) From: "L. Sassaman" To: hal@finney.org, prz@pgp.com cc: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: <200005251645.JAA11926@finney.org> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with Phil on this point. As it stands right now, we have only two types of keys in use: v3 RSA and v4 DSA/ElG keys. (I am ignoring ElGamal signing keys since I don't see anyone using them on any significant scale). Presently, both of the key types obtain their keyid in different ways, and there haven't been any problems with that. Granted, changing the scheme once again for obtaining the keyid would add confusion to the spec, but I think that obtaining the keyid from the left of the fingerprint would add considerable benefit. In fact, if we were to do it this way, the fingerprint itself would become the keyid, and users or implementations could provide as much or as little of the fingerprint as was determined necessary for a unique match. This would also allow for cases where a unique match was not desirable, such as anonymous communication where the user did not wish to have the key id of the recipient visible in the encrypted blob, but wished to provide a "hint" to the recipient as to which key it was encrypted. This would be useful for those with several private keys on the same keyring. A "v5" signature format would probably be the cleanest way to go (and then we could possibly convert all existing keys to v5 as well), but we run into backward compatability problems. As for other implementations using RSA v4 keys, I know that GnuPG doesn't generate them (though I provided Werner with an RSA v4 test keypair a while back). Thoughts? - --Len. __ L. Sassaman System Administrator | "It's a nice day Technology Consultant | to start again." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Billy Idol On Thu, 25 May 2000 hal@finney.org wrote: > Currently in V4 keys, the keyid is defined to be the rightmost 64 bits > of the fingerprint. Phil Zimmermann has often complained about this > and expressed the opinion that this was a blunder, and that we should > have chosen the leftmost bits rather than the rightmost bits. > > He says that this would facilitate a generalization of the keyid to be > the leftmost N bits of the fingerprint. N could be as long as the entire > fingerprint, to have an essentially unambiguous pointer to a given key. > Or N could be short, just a few bits, to have a nearly-"anonymous" > key, where the set of possible keys was understood by all parties to be > very small. > > He also suggests that this would facilitate going to a key server storage > model where a length-N keyid was the index. N could be shorter or longer, > and by using left substrings rather than right, he says that the server > would have an easier time adapting to the variable length indexes. > > PGP 7.0, to be released shortly, will allow creation of V4 RSA keys for > the first time. These will use the hash method to derive the fingerprint > and keyid, as with other V4 keys. > > Phil proposed to me that we change the keyid calculation for these keys to > use a left substring of the fingerprint rather than the right substring. > More generally, all new key types would use left substrings. > > The only keys that used right substrings would be "legacy" DSA and ElGamal > keys (assuming that no one else has implemented RSA V4 keys, which I am > not sure about). We might do some kind of upgrade to DSA keys when the > new larger hash is announced later this year, and they could switch at > that time. Maybe some arbitrary change could be made to ElGamal as well. > > I will refrain from giving my own opinion about this idea, its > justification, its timing, and its impact. Input from others is welcome. > > Hal > -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5LilKPYrxsgmsCmoRArpAAKD73N8R6ahvOJ55v74Vp+4jPQTbbACcDFD0 TnmWYi+DCFu2l4FDDcP+Vss= =0nwl -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id XAA00541 for ietf-openpgp-bks; Thu, 25 May 2000 23:00:41 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA00535 for ; Thu, 25 May 2000 23:00:38 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 26185 invoked from network); 26 May 2000 06:03:54 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 26 May 2000 06:03:54 -0000 To: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1 In-Reply-To: <200005251225.IAA27413@domains.invweb.net> References: <200005221536.IAA01210@finney.org> <200005251225.IAA27413@domains.invweb.net> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000526150754Z.1001@eccosys.com> Date: Fri, 26 May 2000 15:07:54 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 21 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: "William H. Geiger III" Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1 Date: Tue, 23 May 2000 07:29:01 -0500 Message-ID: <200005251225.IAA27413@domains.invweb.net> ... > As an open question to list members: > > What do you consider the proper response of OpenPGP software (client & > server) when an established key (ie a key on the server or users keyring) > is "updated" and unhashed data has been changed? it seems to me that this might be handled in a number of ways depending on the particular situation: -determined by "local" policy (the client or server has a policy which it follows) -determined by "key" policy (a policy is determined from some signed portion of the key) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA22479 for ietf-openpgp-bks; Thu, 25 May 2000 17:21:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA22475 for ; Thu, 25 May 2000 17:21:56 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA23478; Thu, 25 May 2000 17:28:43 -0700 (PDT) Received: from [63.73.97.188] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA23474; Thu, 25 May 2000 17:28:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200005251645.JAA11926@finney.org> References: <200005251645.JAA11926@finney.org> Date: Thu, 25 May 2000 17:28:41 -0700 To: hal@finney.org, ietf-openpgp@imc.org From: Jon Callas Subject: Re: KeyID as left vs right substring of fingerprint Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I agree that in retrospect, it would have been better to have the key id be the high-order bits of the fingerprint rather than the low-order bits. I, too, think this was a mistake. However, that decision was made before this working group was formed. (And before I joined PGP, Inc. for that matter.) I believe that changing this and making it be dependent on the algorithm type would be utterly wrong. It would add one more little gnarly bit into a system that is already filled with too many gnarly bits. If this blunder needs to be fixed, the correct way to fix it is to make a V5 key structure. (For that matter, there are a couple other things I'd fix, too, if we made a V5 key structure.) However, I think that as unfortunate as this is, simplicity and compatibility override aesthetics, and we should just live with things as they are. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id QAA22009 for ietf-openpgp-bks; Thu, 25 May 2000 16:48:07 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA22005 for ; Thu, 25 May 2000 16:48:06 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 13006 invoked from network); 25 May 2000 23:51:21 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 25 May 2000 23:51:21 -0000 To: ietf-openpgp@imc.org Subject: Re: KeyID as left vs right substring of fingerprint In-Reply-To: <200005251645.JAA11926@finney.org> References: <200005251645.JAA11926@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000526085522K.1001@eccosys.com> Date: Fri, 26 May 2000 08:55:22 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 18 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: KeyID as left vs right substring of fingerprint Date: Thu, 25 May 2000 09:45:24 -0700 Message-ID: <200005251645.JAA11926@finney.org> > Currently in V4 keys, the keyid is defined to be the rightmost 64 bits > of the fingerprint. Phil Zimmermann has often complained about this > and expressed the opinion that this was a blunder, and that we should > have chosen the leftmost bits rather than the rightmost bits. is the idea of giving the leftmost N bits a name other than "keyid" doable? then both concepts can continue to exist and "keyid" can be deprecated. some names that came to mind (in no particular order): left keyid, lkeyid, general keyid, revised keyid Received: by ns.secondary.com (8.9.3/8.9.3) id QAA21942 for ietf-openpgp-bks; Thu, 25 May 2000 16:42:39 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id QAA21938 for ; Thu, 25 May 2000 16:42:37 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 12849 invoked from network); 25 May 2000 23:45:52 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 25 May 2000 23:45:52 -0000 To: ietf-openpgp@imc.org Subject: Re: minor typos/points? In-Reply-To: <200005251224.IAA27315@domains.invweb.net> References: <20000523121635R.1001@eccosys.com> <200005251224.IAA27315@domains.invweb.net> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000526084953D.1001@eccosys.com> Date: Fri, 26 May 2000 08:49:53 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 12 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: "William H. Geiger III" Subject: Re: minor typos/points? Date: Tue, 23 May 2000 07:40:44 -0500 Message-ID: <200005251224.IAA27315@domains.invweb.net> > I always make it a practice to zip even individual files *before* > encryption and sending. Zip seems better at dealing with file system > issues better than PGP is (CRLF<->LF conversions, preserving EA's, > ...ect). i would be interested in seeing concrete examples demonstrating the differences. can you provide any? Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14933 for ietf-openpgp-bks; Thu, 25 May 2000 09:37:06 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14929 for ; Thu, 25 May 2000 09:37:05 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA11926 for ietf-openpgp@imc.org; Thu, 25 May 2000 09:45:24 -0700 Date: Thu, 25 May 2000 09:45:24 -0700 Message-Id: <200005251645.JAA11926@finney.org> To: ietf-openpgp@imc.org Subject: KeyID as left vs right substring of fingerprint Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Currently in V4 keys, the keyid is defined to be the rightmost 64 bits of the fingerprint. Phil Zimmermann has often complained about this and expressed the opinion that this was a blunder, and that we should have chosen the leftmost bits rather than the rightmost bits. He says that this would facilitate a generalization of the keyid to be the leftmost N bits of the fingerprint. N could be as long as the entire fingerprint, to have an essentially unambiguous pointer to a given key. Or N could be short, just a few bits, to have a nearly-"anonymous" key, where the set of possible keys was understood by all parties to be very small. He also suggests that this would facilitate going to a key server storage model where a length-N keyid was the index. N could be shorter or longer, and by using left substrings rather than right, he says that the server would have an easier time adapting to the variable length indexes. PGP 7.0, to be released shortly, will allow creation of V4 RSA keys for the first time. These will use the hash method to derive the fingerprint and keyid, as with other V4 keys. Phil proposed to me that we change the keyid calculation for these keys to use a left substring of the fingerprint rather than the right substring. More generally, all new key types would use left substrings. The only keys that used right substrings would be "legacy" DSA and ElGamal keys (assuming that no one else has implemented RSA V4 keys, which I am not sure about). We might do some kind of upgrade to DSA keys when the new larger hash is announced later this year, and they could switch at that time. Maybe some arbitrary change could be made to ElGamal as well. I will refrain from giving my own opinion about this idea, its justification, its timing, and its impact. Input from others is welcome. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id FAA06279 for ietf-openpgp-bks; Thu, 25 May 2000 05:18:29 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06274 for ; Thu, 25 May 2000 05:18:27 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id IAA27413; Thu, 25 May 2000 08:25:29 -0400 Message-Id: <200005251225.IAA27413@domains.invweb.net> From: "William H. Geiger III" Date: Tue, 23 May 2000 07:29:01 -0500 To: hal@finney.org In-Reply-To: <200005221536.IAA01210@finney.org> Cc: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1 X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <200005221536.IAA01210@finney.org>, on 05/22/00 at 09:36 AM, hal@finney.org said: >> so is the signing key id the only subpacket that is allowed to go in >> the unhashed area? >No, anything which might reasonably be considered to be "advisory" and >not security critical could go there. For example the URL where the cert >can be found. I don't know if there is an exhaustive list. The point is >that the software needs to be aware that material in the unhashed region >is not authenticated and could have been tampered with. >> also, for a given subpacket type, can instances of >> that subpacket appear in either the hashed subpacket field or the >> unhashed subpacket field, or is it a mutually exclusive situation? >I don't see any problem in allowing that. As an open question to list members: What do you consider the proper response of OpenPGP software (client & server) when an established key (ie a key on the server or users keyring) is "updated" and unhashed data has been changed? Take the example: Software A lets the user enter on his key the prefered URL to obtain his key on the self-sig for his key and the software stores it in an unhashed subpacket. The user distributes his key (other users, servers, ...ect). Software A also allows the user to change this at a later date without creating a new signature. The user distributes this "updated" key. How should the receiving software treat this "updated" data? -- Ignore the "new" data -- Accept the "new" data in place of the old data -- Notify the receiver that there is "new" data and let him decide -- ....? -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id FAA06278 for ietf-openpgp-bks; Thu, 25 May 2000 05:18:28 -0700 (PDT) Received: from domains.invweb.net (root@domains.invweb.net [198.182.196.32]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA06269 for ; Thu, 25 May 2000 05:18:26 -0700 (PDT) Received: from whgiii (root@openpgp.net [199.184.252.29]) by domains.invweb.net (8.9.3/8.9.3) with SMTP id IAA27315; Thu, 25 May 2000 08:24:31 -0400 Message-Id: <200005251224.IAA27315@domains.invweb.net> From: "William H. Geiger III" Date: Tue, 23 May 2000 07:40:44 -0500 To: sen_ml@eccosys.com In-Reply-To: <20000523121635R.1001@eccosys.com> Cc: ietf-openpgp@imc.org Subject: Re: minor typos/points? X-Mailer: MR/2 Internet Cruiser Edition for OS/2 v2.19ze/19ze Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <20000523121635R.1001@eccosys.com>, on 05/22/00 at 09:16 PM, sen_ml@eccosys.com said: >> This is an area of ambiguity we have run into. Can you put multiple >> literal data packets into compressed or encrypted data? Can they be >> inside/after signature packets? >> >> My feeling is that it should be allowed. Literal packets can have file >> names associated with them and so this would be an efficient mechanism >> for transferring multiple files. I don't know what the current >> implementations do. >i wonder about how well this would work w/ mime. for mail situations, i >wonder whether it wouldn't be simpler and easier for users and >implementors to either tar or zip up multiple files as a single file or >to attach multiple files. >for situations where the data is being processed directly by an openpgp >implementation, processing multiple contiguous literal data packets seems >fine...but openpgp and zip seem to be merging :-) I always make it a practice to zip even individual files *before* encryption and sending. Zip seems better at dealing with file system issues better than PGP is (CRLF<->LF conversions, preserving EA's, ...ect). -- --------------------------------------------------------------- William H. Geiger III http://www.openpgp.net Geiger Consulting Data Security & Cryptology Consulting Programming, Networking, Analysis PGP for OS/2: http://www.openpgp.net/pgp.html E-Secure: http://www.openpgp.net/esecure.html --------------------------------------------------------------- Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01479 for ietf-openpgp-bks; Wed, 24 May 2000 09:11:40 -0700 (PDT) Received: from europe.std.com (europe.std.com [199.172.62.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA01475 for ; Wed, 24 May 2000 09:11:35 -0700 (PDT) Received: from world.std.com (root@world-f.std.com [199.172.62.5]) by europe.std.com (8.9.3/8.9.3) with ESMTP id MAA01021; Wed, 24 May 2000 12:18:44 -0400 (EDT) Received: from [208.192.101.191] (ppp0b191.std.com [208.192.101.191]) by world.std.com (8.9.3/8.9.3) with ESMTP id MAA17667; Wed, 24 May 2000 12:14:31 -0400 (EDT) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 24 May 2000 12:14:36 -0400 To: gec@acm.org, roessler@guug.de, mwa@arl.wustl.edu From: Don Davis Subject: Key Generation Security Flaw in PGP 5.0 Cc: ietf-openpgp@imc.org, dtd@world.std.com, Dan Geer Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > So the intervals between individual key presses remain as a source > of randomness. > Assuming that the user types at a rate of about 120 characters per > minute, we have an interval of approximately 0.5 seconds between two > key presses. Dropping the upmost non-random bit of the interval > length, we get about 18 bits of random timing information per key > press. i'm sorry, but i think your estimate here is badly flawed. you seem to assume that keyboard-timings come in microsecond-scale resolutions. it turns out, though, that keyboard controllers check the keyboard for input only every few milliseconds (10 msec, if i remember correctly). thus, your keyboard-timings come in hundredth-sec increments, and you get at most 6 or 7 bits of variability per keystroke. further. these timings are not uniformly distributed, but probably show a normal distribution centered at, say, 500 msec. my guess is you're getting only 3 or 4 bits of entropy per keystroke, at most. i can calculate the entropy more precisely, if you want. > This estimate gets worse for experienced and > fast-typing users. much worse, because their keystroke timings will be highly correlated with the textual content. english text carries only around 1 bit of entropy per character. i congratulate you upon your discovery, and i thank you for your diligence. fwiw, i'm the author of a paper about extracting randomness from disk timings, which appeared at crypto '94, and which is cited in rfc 1750 "recommendations for randomness." - don davis http://world.std.com/~dtd - Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA06826 for ietf-openpgp-bks; Wed, 24 May 2000 00:38:38 -0700 (PDT) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA06822 for ; Wed, 24 May 2000 00:38:35 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialup16.ip.lu [208.161.253.16]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id JAA09590 for ; Wed, 24 May 2000 09:45:40 +0200 (CEST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id F3ACE2ED3D; Wed, 24 May 2000 09:43:06 +0200 (CEST) Date: Wed, 24 May 2000 09:43:06 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: FYI: Key Generation Security Flaw in PGP 5.0 Message-ID: <20000524094306.D8916@sobolev.tlr-net.does-not-exist.org> Reply-To: gec@acm.org, roessler@guug.de, ietf-openpgp@imc.org Mail-Followup-To: ietf-openpgp@imc.org, gec@acm.org, roessler@guug.de Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.1i In-Reply-To: <20000523141323.A28431@olymp.org> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA06823 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ----- Forwarded message from gec@acm.org ----- Date: Tue, 23 May 2000 14:13:23 -0700 From: gec@acm.org To: undisclosed-recipients: ; Subject: Key Generation Security Flaw in PGP 5.0 Reply-To: gec@acm.org, roessler@guug.de Mail-Followup-To: gec@acm.org, roessler@guug.de SECURITY FLAW IN PGP 5.0 ======================== EXECUTIVE SUMMARY ----------------- A flaw has been found in the randomness gathering code of PGP 5. PGP 5 will, under certain well-defined circumstances, generate public/private key pairs with no or only a small amount of randomness. Such keys are insecure. Chances are very high that you have no problem. So, don't panic. WHO IS AFFECTED? ---------------- The flaw has been found in the PGP 5.0i code base. It is specific to Unix systems such as Linux or various BSD dialects with a /dev/random device. Versions 2.* and 6.5 of PGP do NOT share this problem. PGP versions ported to other platforms do NOT share this problem. The problem does NOT manifest itself under the following circumstances: - You typed in a lot of data while generating your key, including long user ID and pass phrase strings. - A random seed file PGP 5 could use existed on your system before you generated the key. However, the problem affects you in the worst possible manner if you started from scratch with pgp 5 on a Unix system with a /dev/random device, and created your key pair non-interactively with a command line like this one: pgpk -g WHAT TO DO? ----------- If you have generated your key non-interactively, you may wish to revoke it, and create a new key using a version of PGP which works correctly. DETAILS ------- In order to generate secure cryptographic keys, PGP needs to gather random numbers from reliable sources, so keys can't be predicted by attackers. Randomness sources PGP generally uses include: - a seed file with random data from previous sessions - user input and input timing Additionally, certain Unix systems such as OpenBSD, Linux, and others, offer a stream of random data over a central service typically called /dev/random or the like. If present, this service is used by PGP as a source of random data. PGP 5.0i's reading of these random numbers does not work. Instead of random numbers, a stream of bytes with the value "1" is read. In practice, this implies two things: 1. PGP5 will generally overestimate the amount of randomness available. We have not researched the effects of this in detail. However, we believe that the amount of randomness gathered from input data, timing information, and old random data will be sufficient for most applications. (See below for a detailed estimate.) 2. In situations in which no other randomness sources are available, PGP relies on the /dev/random service, and thus uses predictable instead of random numbers. This is not a flaw of the random service, but of the PGP5 implementation. One particular example of such a situation is non-interactive key generation with a virgin PGP 5 installation, like described above. Example: $ mkdir /tmp/pgp5test $ PGPPATH=/tmp/pgp5test $ pgpk -g RSA 1024 foo@bar.com 0 "passphrase string" In fact, RSA keys generated this way are entirely predictable, which can easily be verified by comparing key IDs and fingerprints. When using DSA/ElGamal keys, the DSA signature key is predictable, while the ElGamal encryption subkey will vary. Note that fingerprints and key IDs of the predictable DSA keys depend on a time stamp, and are themselves not predictable. Proof of concept key rings generated with pgp 5.0i are available from . GORY DETAILS ------------ 1. Code Here's the flawed code from src/lib/ttyui/pgpUserIO.c: 1314 static unsigned 1315 pgpDevRandomAccum(int fd, unsigned count) 1316 { 1317 char RandBuf; 1318 unsigned short i = 0; 1319 1320 pgpAssert(count); 1321 pgpAssert(fd >= 0); 1322 1323 for(i = 0; i <= count; ++i) { >1324 RandBuf = read(fd, &RandBuf, count); 1325 pgpRandomAddBytes(&pgpRandomPool, (byte *)&RandBuf, sizeof(RandBuf)); 1326 pgpRandPoolAddEntropy(256); 1327 } 1328 1329 return(i); 1330 } The count parameter is always set to the value 1 by the calling code. The byte read from the file descriptor fd into the RandBuf buffer is subsequently overwritten with the read() function's return value, which will be 1. The actual random data are not used. This can be fixed by replacing line 1324 by the following line of code: read (fd, &RandBuf, 1); 2. "Random" data A dump of random data gathered during an interactive key generation session is available at . This was dumped as passed to the pgpRandomAddByte() function, one byte at a time. Note the streams of bytes with the value 1 which should actually contain data gathered from /dev/random. Also note that the pass phrase ("asdf") and the user ID ("roessler@guug.de") are clearly visible, but mixed with timing data from the individual key presses. No random data occuring after the second stream of ones were generated from external events prior to the generation of the DSA key in question. 3. Some estimates We give a back-of-the-envelope upper estimate of the amount of random bits PGP may gather during interactive key generation. We assume that /dev/random reading is flawed, and that no seed file exists prior to running PGP. Timing is assumed to have a resolution of 1 us (gettimeofday()). During a PGP session of one minute, we can get at most 2^28 different time stamps (2^28 ~ 60*10^6). Note that one time stamp close to the point of time of key generation is known to attackers from the time stamp PGP leaves on the key. So the intervals between individual key presses remain as a source of randomness. Assuming that the user types at a rate of about 120 characters per minute, we have an interval of approximately 0.5 seconds between two key presses. Dropping the upmost non-random bit of the interval length, we get about 18 bits of random timing information per key press. This estimate gets worse for experienced and fast-typing users. With a user ID of 20 characters, and no pass phrase, PGP will have gathered roughly 300-400 random bits interactively. While this is not bad, it is not sufficient by PGP's own standards. CONCLUSIONS ----------- Public code review is a good thing - if it happens. CREDITS ------- This problem was found by Germano Caronni , and verified by Thomas Roessler and Marcel Waldvogel . ----- End forwarded message ----- Received: by ns.secondary.com (8.9.3/8.9.3) id BAA06430 for ietf-openpgp-bks; Tue, 23 May 2000 01:27:35 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06423 for ; Tue, 23 May 2000 01:27:33 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA17057; Tue, 23 May 2000 09:34:22 +0100 (BST) Message-ID: Date: Tue, 23 May 2000 09:31:21 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME: Time for last call? References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> <20000522131429.A21039@sobolev.tlr-net.does-not-exist.org> In-Reply-To: <20000522131429.A21039@sobolev.tlr-net.does-not-exist.org> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 22 May 2000, Thomas Roessler wrote: >On 2000-05-11 09:44:28 +0100, Ian Bell wrote: > >> 1) Simply state the problem, and indicate that for >> one-pass processing, two hashes will have to be >> prepared - one for binary-mode signatures and one >> for text-mode signatures. > >> 2) Mandate which form of signature must be used. >> Trailing spaces are often significant in email/news >> (sig-seps, RFC2646), so a binary-mode signature >> might seem preferable. However, existing PGP/MIME >> clients may be using either. > >> 3) Define a "pgp-mode" parameter, pgp-mode=binary or >> pgp-mode=text and ensure that new clients add the >> parameter to the multipart/signed header. If the >> parameter is missing (RFC2015 messages), then >> one-pass clients will have to prepare two hashes. > >Well... As a fourth possibility, we could mandate that >any trailing whitespace within body parts should lead to >the use of quoted-printable or base64, thus effectively >working around the problem. However, this is _not_ >currently mandated by RFC 1847. Mandating quoted-printable just as a workround for a sig-mode problem seems a little of a kludge - 3) still seems to me the solution that fits best with the aims of RFC1847. [However, Turnpike already forces its PGP-signed messages into quoted-printable so that trailing-space corruption and Berkeley-From corruption problems are avoided] -- Ian Bell T U R N P I K E Ltd Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id UAA27718 for ietf-openpgp-bks; Mon, 22 May 2000 20:09:38 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA27710 for ; Mon, 22 May 2000 20:09:35 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 2380 invoked from network); 23 May 2000 03:12:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 23 May 2000 03:12:45 -0000 To: ietf-openpgp@imc.org Subject: Re: minor typos/points? In-Reply-To: <200005221545.IAA01241@finney.org> References: <200005221545.IAA01241@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000523121635R.1001@eccosys.com> Date: Tue, 23 May 2000 12:16:35 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 115 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: minor typos/points? Date: Mon, 22 May 2000 08:45:29 -0700 Message-ID: <200005221545.IAA01241@finney.org> > > 5.2.3.4. Issuer > > > > (8 octet key ID) > > > > The OpenPGP key ID of the key issuing the signature. > > > > MUST be present in the hashed area. > > keyid can be unhashed. I'm not sure it makes sense to have a mandatory > unhashed packet, since unhased packets can have no security properties. so, the issuer subpacket should not be mandatory then? > > section 5.6 says: > > > > Typically, this packet is found as the contents of an encrypted packet, > > or following a Signature or One-Pass Signature packet, and contains > > literal data packets. > > > > does this mean that multiple contiguous literal data packets can be > > compressed into a compressed data packet? if so, how is an > > implementation supposed to interpret multiple literal data packets > > contained in a single compressed data packet? > > This is an area of ambiguity we have run into. Can you put multiple > literal data packets into compressed or encrypted data? Can they be > inside/after signature packets? > > My feeling is that it should be allowed. Literal packets can have file > names associated with them and so this would be an efficient mechanism > for transferring multiple files. I don't know what the current > implementations do. i wonder about how well this would work w/ mime. for mail situations, i wonder whether it wouldn't be simpler and easier for users and implementors to either tar or zip up multiple files as a single file or to attach multiple files. for situations where the data is being processed directly by an openpgp implementation, processing multiple contiguous literal data packets seems fine...but openpgp and zip seem to be merging :-) > > section 6.1 has: > > > > #define CRC24_POLY 0x1864cfbL > > > > should this not be: > > > > #define CRC24_POLY 0x864cfbL > > Not if you want the code to work... doh! > note the line where that constant is used, the high "1" is used to > clear a "1" in the crc variable. how about the following code then? i think it would make the text and the code eaiser to understand and thus help prevent the question that i asked from being asked again in the future (hopefully, it wouldn't generate additional ones). #define CRC24_GENERATOR 0x864cfbL #define CRC24_POLY (CRC24_GENERATOR | 0x1000000L) > > section 11.2 says: > > > > A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet > > Tag, followed by the two-octet packet length, followed by the entire > > Public Key packet starting with the version field. > > > > strictly speaking, this seems to imply that only old packet format packets > > can be used. i presume that is not what is meant. how about the following > > wording: > > > > A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key > > packet (i.e. the entire packet header and all of the packet body fields). > > No, it has to be a two byte length. The length must be canonicalized > to two bytes. Otherwise there may be ambiguity in that the same length > can be expressed in different forms. ok i understand. i see i was completely off regarding the old format packets. how about adding an explicit note in the rfc noting that the length must be canonicalized to two bytes to prevent ambiguity in expressing a particular length? i presume that two-octet lengths are sufficient for all the relevant key sizes... i keep wondering why there are even one-octet and two-octet lengths in new format packets. it seems far simpler to just have five-octet and partial lengths. are there significant advantages to having one- and two-octet lengths? > > section 12.1 says: > > > > Note also that if an implementation does not implement the preference, > > then it is implicitly a TripleDES-only implementation. > > > > what does the phrase "the preference" refer to? does it mean if an > > implementation doesn't implement a system of preferences? > > More specifically, that it doesn't support the preferred algorithm > subpacket. It doesn't create them, it doesn't read them. It should > always use triple des. thanks for the clarification. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24421 for ietf-openpgp-bks; Mon, 22 May 2000 08:37:19 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24417 for ; Mon, 22 May 2000 08:37:18 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA01241; Mon, 22 May 2000 08:45:29 -0700 Date: Mon, 22 May 2000 08:45:29 -0700 Message-Id: <200005221545.IAA01241@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: minor typos/points? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > 5.2.3.4. Issuer > > (8 octet key ID) > > The OpenPGP key ID of the key issuing the signature. > > MUST be present in the hashed area. keyid can be unhashed. I'm not sure it makes sense to have a mandatory unhashed packet, since unhased packets can have no security properties. > section 5.6 says: > > Typically, this packet is found as the contents of an encrypted packet, > or following a Signature or One-Pass Signature packet, and contains > literal data packets. > > does this mean that multiple contiguous literal data packets can be > compressed into a compressed data packet? if so, how is an > implementation supposed to interpret multiple literal data packets > contained in a single compressed data packet? This is an area of ambiguity we have run into. Can you put multiple literal data packets into compressed or encrypted data? Can they be inside/after signature packets? My feeling is that it should be allowed. Literal packets can have file names associated with them and so this would be an efficient mechanism for transferring multiple files. I don't know what the current implementations do. > section 6.1 has: > > #define CRC24_POLY 0x1864cfbL > > should this not be: > > #define CRC24_POLY 0x864cfbL Not if you want the code to work... note the line where that constant is used, the high "1" is used to clear a "1" in the crc variable. > section 11.2 says: > > A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet > Tag, followed by the two-octet packet length, followed by the entire > Public Key packet starting with the version field. > > strictly speaking, this seems to imply that only old packet format packets > can be used. i presume that is not what is meant. how about the following > wording: > > A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key > packet (i.e. the entire packet header and all of the packet body fields). No, it has to be a two byte length. The length must be canonicalized to two bytes. Otherwise there may be ambiguity in that the same length can be expressed in different forms. > section 11.2 says: > > a.2) high order length octet of (b)-(f) (1 octet) > > a.3) low order length octet of (b)-(f) (1 octet) > > what does (f) refer to here? Should be (e). > section 12.1 says: > > Note also that if an implementation does not implement the preference, > then it is implicitly a TripleDES-only implementation. > > what does the phrase "the preference" refer to? does it mean if an > implementation doesn't implement a system of preferences? More specifically, that it doesn't support the preferred algorithm subpacket. It doesn't create them, it doesn't read them. It should always use triple des. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24211 for ietf-openpgp-bks; Mon, 22 May 2000 08:28:27 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24207 for ; Mon, 22 May 2000 08:28:26 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA01210; Mon, 22 May 2000 08:36:36 -0700 Date: Mon, 22 May 2000 08:36:36 -0700 Message-Id: <200005221536.IAA01210@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > so is the signing key id the only subpacket that is allowed to go in > the unhashed area? No, anything which might reasonably be considered to be "advisory" and not security critical could go there. For example the URL where the cert can be found. I don't know if there is an exhaustive list. The point is that the software needs to be aware that material in the unhashed region is not authenticated and could have been tampered with. > also, for a given subpacket type, can instances of > that subpacket appear in either the hashed subpacket field or the > unhashed subpacket field, or is it a mutually exclusive situation? I don't see any problem in allowing that. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id EAA17830 for ietf-openpgp-bks; Mon, 22 May 2000 04:21:10 -0700 (PDT) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA17826 for ; Mon, 22 May 2000 04:21:08 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialup27.ip.lu [208.161.253.27]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id NAA26333 for ; Mon, 22 May 2000 13:28:03 +0200 (CEST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 3E9C12ED3D; Mon, 22 May 2000 13:14:29 +0200 (CEST) Date: Mon, 22 May 2000 13:14:29 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: PGP/MIME: Time for last call? Message-ID: <20000522131429.A21039@sobolev.tlr-net.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.1i In-Reply-To: ; from ianbell@turnpike.com on Thu, May 11, 2000 at 09:44:28AM +0100 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-05-11 09:44:28 +0100, Ian Bell wrote: > 1) Simply state the problem, and indicate that for > one-pass processing, two hashes will have to be > prepared - one for binary-mode signatures and one > for text-mode signatures. > 2) Mandate which form of signature must be used. > Trailing spaces are often significant in email/news > (sig-seps, RFC2646), so a binary-mode signature > might seem preferable. However, existing PGP/MIME > clients may be using either. > 3) Define a "pgp-mode" parameter, pgp-mode=binary or > pgp-mode=text and ensure that new clients add the > parameter to the multipart/signed header. If the > parameter is missing (RFC2015 messages), then > one-pass clients will have to prepare two hashes. Well... As a fourth possibility, we could mandate that any trailing whitespace within body parts should lead to the use of quoted-printable or base64, thus effectively working around the problem. However, this is _not_ currently mandated by RFC 1847. Actually, doing this is suggested in one of the example messages, but for different reasons. -- http://www.guug.de/~roessler/ Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA16846 for ietf-openpgp-bks; Mon, 22 May 2000 03:33:12 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA16841 for ; Mon, 22 May 2000 03:33:10 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 8701 invoked from network); 22 May 2000 10:36:18 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 22 May 2000 10:36:18 -0000 To: ietf-openpgp@imc.org Subject: minor typos/points? X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000522194007V.1001@eccosys.com> Date: Mon, 22 May 2000 19:40:07 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 131 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: below are some minor typos/points i came across. setion 5.2.1 says: 0x18: Subkey Binding Signature This signature is a statement by the top-level signing key indicates that it owns the subkey. shouldn't this be: 0x18: Subkey Binding Signature This signature is a statement by the top-level signing key indicating that it owns the subkey. ? section 5.2.4.1 says: An implementation SHOULD put the two mandatory subpackets, creation time and issuer, as the first subpackets in the subpacket list, simply to make it easier for the implementer to find them. but, section 5.2.3.4 says: 5.2.3.4. Issuer (8 octet key ID) The OpenPGP key ID of the key issuing the signature. and does not mention that the issuer subpacket is mandatory, while section 5.2.3.3 mentions that the signature creation time is mandatory and that it is present in the hashed area. i presume that 5.2.3.4 could read: 5.2.3.4. Issuer (8 octet key ID) The OpenPGP key ID of the key issuing the signature. MUST be present in the hashed area. section 5.3 says: Zero or more Encrypted Session Key packets and/or Symmetric-Key Encrypted Session Key packets may precede a Symmetrically Encrypted Data Packet that holds an encrypted message. does the phrase "more Encrypted Session Key packets" mean: more Public Key Encrypted Session Key packets ? section 5.6 says: Typically, this packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains literal data packets. does this mean that multiple contiguous literal data packets can be compressed into a compressed data packet? if so, how is an implementation supposed to interpret multiple literal data packets contained in a single compressed data packet? section 6 says: The checksum is a 24-bit CRC converted to four characters of radix-64 encoding shouldn't this be: The checksum is a 24-bit CRC converted to four characters of base64 encoding ? section 6.1 has: #define CRC24_POLY 0x1864cfbL should this not be: #define CRC24_POLY 0x864cfbL ? if not, shouldn't the constant listed in section 6: The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. be 0x1864CFB? section 11.2 says: A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet Tag, followed by the two-octet packet length, followed by the entire Public Key packet starting with the version field. strictly speaking, this seems to imply that only old packet format packets can be used. i presume that is not what is meant. how about the following wording: A V4 fingerprint is the 160-bit SHA-1 hash of the entire Public Key packet (i.e. the entire packet header and all of the packet body fields). section 11.2 says: a.2) high order length octet of (b)-(f) (1 octet) a.3) low order length octet of (b)-(f) (1 octet) what does (f) refer to here? section 12.1 says: Note also that if an implementation does not implement the preference, then it is implicitly a TripleDES-only implementation. what does the phrase "the preference" refer to? does it mean if an implementation doesn't implement a system of preferences? section 12.7 says: We have reserver three algorithm IDs for the US NIST's Advanced i presume that should be: We have reserved three algorithm IDs for the US NIST's Advanced Received: by ns.secondary.com (8.9.3/8.9.3) id DAA13914 for ietf-openpgp-bks; Mon, 22 May 2000 03:00:54 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA13910 for ; Mon, 22 May 2000 03:00:52 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 7957 invoked from network); 22 May 2000 10:03:58 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 22 May 2000 10:03:58 -0000 To: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) In-Reply-To: <200005190448.VAA22974@finney.org> References: <200005190448.VAA22974@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000522190747D.1001@eccosys.com> Date: Mon, 22 May 2000 19:07:47 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) Date: Thu, 18 May 2000 21:48:17 -0700 Message-ID: <200005190448.VAA22974@finney.org> > > so "normally" the contents of the "hashed subpackets" field and the > > "unhashed subpackets" field should be identical, correct? > > No. Some subpackets are hashed, while other ones are unhashed. The > latter are not protected by the signature and would be considered > "advisory", like hints about where to find the signing key. Currently > we consider signing key id to be in that category. ok. so is the signing key id the only subpacket that is allowed to go in the unhashed area? also, for a given subpacket type, can instances of that subpacket appear in either the hashed subpacket field or the unhashed subpacket field, or is it a mutually exclusive situation? Received: by ns.secondary.com (8.9.3/8.9.3) id WAA09986 for ietf-openpgp-bks; Thu, 18 May 2000 22:47:00 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA09975 for ; Thu, 18 May 2000 22:46:58 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id WAA22727; Thu, 18 May 2000 22:53:36 -0700 Date: Thu, 18 May 2000 22:53:29 -0700 (PDT) From: "L. Sassaman" To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) In-Reply-To: <20000519135936P.1001@eccosys.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 19 May 2000 sen_ml@eccosys.com wrote: > section 5.2.3.2 uses the definite article (as in "the default user id"): > > If the key is located by key id, then [the] algorithm of the default user > id of the key provides the default symmetric algorithm. > > i presume there is only one "default user id" -- that is, given a > correct openpgp implementation, for any key (not packet, but entire > key), the implementation should have some algorithm to decide what > counts as the default user id. > > section 5.2.3.19 states that more than one user id in a key can be > marked as primary and that the implementation may resolve the > ambiguity in any way it sees fit. i presume this means that the > implementation must choose a default user id, but it has the freedom > to decide how this choosing is done. is that correct? Right. There is only one primary user id (or default user id) per key. More than one user id can have a self-sig with the primary user id bit set, but the implementation must in some way determine which is the "real" primary user id. I believe that checking the signature date, and picking the most recent, makes a lot of sense... but as the RFC says, it is up to the implementation. - --Len. __ L. Sassaman System Administrator | "Everything must end; Technology Consultant | meanwhile we must icq.. 10735603 | amuse ourselves." pgp.. finger://ns.quickie.net/rabbi | --Voltaire -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5JNbgPYrxsgmsCmoRAvOsAKDkbAPiACBSiMM+TZ5uJO4ug8DngQCfVEW+ LQDRfLb4VYgQv/YF5ByYgtM= =j5Mn -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id VAA05801 for ietf-openpgp-bks; Thu, 18 May 2000 21:52:58 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA05794 for ; Thu, 18 May 2000 21:52:55 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 2749 invoked from network); 19 May 2000 04:55:57 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 May 2000 04:55:57 -0000 To: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) In-Reply-To: References: <20000519120406C.1001@eccosys.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000519135936P.1001@eccosys.com> Date: Fri, 19 May 2000 13:59:36 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 37 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: "L. Sassaman" Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) Date: Thu, 18 May 2000 20:58:58 -0700 (PDT) Message-ID: > I believe that "default user id" is synonymous with "primary user id". > > - From the current draft: > > 5.2.3.19. Primary user id > > (1 octet, boolean) > > This is a flag in a user id's self signature that states whether > this user id is the main user id for this key. It is reasonable for > an implementation to resolve ambiguities in preferences, etc. by > referring to the primary user id. If this flag is absent, its value > is zero. If more than one user id in a key is marked as primary, the > implementation may resolve the ambiguity in any way it sees fit. hmm...i don't get the impression that they are quite synonymous. section 5.2.3.2 uses the definite article (as in "the default user id"): If the key is located by key id, then [the] algorithm of the default user id of the key provides the default symmetric algorithm. i presume there is only one "default user id" -- that is, given a correct openpgp implementation, for any key (not packet, but entire key), the implementation should have some algorithm to decide what counts as the default user id. section 5.2.3.19 states that more than one user id in a key can be marked as primary and that the implementation may resolve the ambiguity in any way it sees fit. i presume this means that the implementation must choose a default user id, but it has the freedom to decide how this choosing is done. is that correct? Received: by ns.secondary.com (8.9.3/8.9.3) id VAA04669 for ietf-openpgp-bks; Thu, 18 May 2000 21:40:30 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA04660 for ; Thu, 18 May 2000 21:40:28 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id VAA22974; Thu, 18 May 2000 21:48:17 -0700 Date: Thu, 18 May 2000 21:48:17 -0700 Message-Id: <200005190448.VAA22974@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > here are some more clarification questions... > > -section 4.3 is titled "Packet Tags", and the term "packet tag" is used > throughout, but strictly speaking, shouldn't that be "content tag" as > per section 4.2? I'll let someone else worry about that... > -section 5.2.3 describes the version 4 signature packet format. one of the > fields is described as: > > Hashed subpacket data. (zero or more subpackets) > > what is meant by "hashed" here? are the contents of this field actual > subpackets or hash(subpackets)? i presume it is the former and that > "hashed" refers to the fact that the "hashed subpackets" field is included > among the material that is hashed when a signature is computed. Yes. > so "normally" the contents of the "hashed subpackets" field and the > "unhashed subpackets" field should be identical, correct? No. Some subpackets are hashed, while other ones are unhashed. The latter are not protected by the signature and would be considered "advisory", like hints about where to find the signing key. Currently we consider signing key id to be in that category. > -section 5.2.3.1 describes the signature subpacket specification. in > the description of the subpacket header there is the following: > > - the subpacket type (1 octet) > > then, shortly after: > > The value of the subpacket type octet may be: > > 2 = signature creation time > ... > 100 to 110 = internal or user-defined > > however: > > Bit 7 of the subpacket type is the "critical" bit. If set, it > denotes that the subpacket is one that is critical for the evaluator > of the signature to recognize. If a subpacket is encountered that > is marked critical but is unknown to the evaluating software, the > evaluator SHOULD consider the signature to be in error. > > i presume this means that the legal values (2, 3, 4, 5, 6, 7, etc.) listed > for the subpacket type octet actually refer to bits 6 through 0 of the > octet, and not that there haven't been any "critical subpacket types" defined > yet. is this correct? if so, i think alternate wording would be less > ambiguous. Yes, your interpretation is correct. > -section 5.2.3.3 has some notes on self-signatures. the following text > appears therein: > > If the key is located by key id, then algorithm of the default user id > of the key provides the default symmetric algorithm. > > the term "default user id" is used -- i failed to locate a definition for > this term. could someone point out the definition in the specification > or give one? The default user id is better known as the primary user id - the user id with a self-signature on it that includes the primary user id subpacket. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id UAA01384 for ietf-openpgp-bks; Thu, 18 May 2000 20:52:37 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA01377 for ; Thu, 18 May 2000 20:52:35 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id UAA21988; Thu, 18 May 2000 20:59:06 -0700 Date: Thu, 18 May 2000 20:58:58 -0700 (PDT) From: "L. Sassaman" To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) In-Reply-To: <20000519120406C.1001@eccosys.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 19 May 2000 sen_ml@eccosys.com wrote: > -section 5.2.3.3 has some notes on self-signatures. the following text > appears therein: > > If the key is located by key id, then algorithm of the default user id > of the key provides the default symmetric algorithm. > > the term "default user id" is used -- i failed to locate a definition for > this term. could someone point out the definition in the specification > or give one? I believe that "default user id" is synonymous with "primary user id". - From the current draft: 5.2.3.19. Primary user id (1 octet, boolean) This is a flag in a user id's self signature that states whether this user id is the main user id for this key. It is reasonable for an implementation to resolve ambiguities in preferences, etc. by referring to the primary user id. If this flag is absent, its value is zero. If more than one user id in a key is marked as primary, the implementation may resolve the ambiguity in any way it sees fit. - --Len. __ L. Sassaman System Administrator | "Everything must end; Technology Consultant | meanwhile we must icq.. 10735603 | amuse ourselves." pgp.. finger://ns.quickie.net/rabbi | --Voltaire -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5JLwJPYrxsgmsCmoRArtuAKCoOncD8T5mBJKQ/6zmOxntpXuAvQCgpJEm xkLx2Xi/Qy3puYUUWPfaVLk= =gAlL -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id TAA24611 for ietf-openpgp-bks; Thu, 18 May 2000 19:57:30 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA24601 for ; Thu, 18 May 2000 19:57:27 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 813 invoked from network); 19 May 2000 03:00:27 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 May 2000 03:00:27 -0000 To: ietf-openpgp@imc.org Subject: questions: packet tag or content tag (4.3), what is placed in hashed subpacket field (5.2.3), critical bit (5.2.3.1), default user id (5.2.3.3) X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000519120406C.1001@eccosys.com> Date: Fri, 19 May 2000 12:04:06 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 66 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: here are some more clarification questions... -section 4.3 is titled "Packet Tags", and the term "packet tag" is used throughout, but strictly speaking, shouldn't that be "content tag" as per section 4.2? -section 5.2.3 describes the version 4 signature packet format. one of the fields is described as: Hashed subpacket data. (zero or more subpackets) what is meant by "hashed" here? are the contents of this field actual subpackets or hash(subpackets)? i presume it is the former and that "hashed" refers to the fact that the "hashed subpackets" field is included among the material that is hashed when a signature is computed. so "normally" the contents of the "hashed subpackets" field and the "unhashed subpackets" field should be identical, correct? if this is correct, i think it would be helpful to explicitly state that the contents of the "hashed supackets" field and the "unhashed subpackets" field are usually (should be?) the same. alternatively, perhaps the fields could be given different names? (actually, i think all fields should be named "bruce" to avoid confusion ;-P ) out of curiosity, why are the field contents repeated? -section 5.2.3.1 describes the signature subpacket specification. in the description of the subpacket header there is the following: - the subpacket type (1 octet) then, shortly after: The value of the subpacket type octet may be: 2 = signature creation time ... 100 to 110 = internal or user-defined however: Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the evaluator SHOULD consider the signature to be in error. i presume this means that the legal values (2, 3, 4, 5, 6, 7, etc.) listed for the subpacket type octet actually refer to bits 6 through 0 of the octet, and not that there haven't been any "critical subpacket types" defined yet. is this correct? if so, i think alternate wording would be less ambiguous. -section 5.2.3.3 has some notes on self-signatures. the following text appears therein: If the key is located by key id, then algorithm of the default user id of the key provides the default symmetric algorithm. the term "default user id" is used -- i failed to locate a definition for this term. could someone point out the definition in the specification or give one? thanks. Received: by ns.secondary.com (8.9.3/8.9.3) id RAA15847 for ietf-openpgp-bks; Wed, 17 May 2000 17:59:43 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA15834 for ; Wed, 17 May 2000 17:59:40 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 5220 invoked from network); 18 May 2000 01:02:38 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 18 May 2000 01:02:38 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: <200005171539.IAA17677@finney.org> References: <200005171539.IAA17677@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000518100613C.1001@eccosys.com> Date: Thu, 18 May 2000 10:06:13 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 38 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Wed, 17 May 2000 08:39:08 -0700 Message-ID: <200005171539.IAA17677@finney.org> > > so the last octet before message digest padding would not be the last > > octet of the passphrase, as section 3.6.1.3 says: > > > > Then the salt, followed by the passphrase data is repeatedly hashed > > until the number of octets specified by the octet count has been > > hashed. The one exception is that if the octet count is less than > > the size of the salt plus passphrase, the full salt plus passphrase > > will be hashed even though that is greater than the octet count. > > > > is this correct? > > Yes, but I don't believe 3.6.1.3 says that the last octet before message > digest padding would be the last octet of the passphrase. you are absolutely correct -- i agree that the section doesn't say that. the reason i asked this question was that since in the case where the computed octet count is less than the length of the salt + passphrase, the full salt + passphrase is hashed, one possible generalization for the cases where the computed octet count is greater than the length of the salt + passphrase would be to hash on salt + passphrase boundaries. what i found slightly ambiguous was the phrase: "until the number of ... has been hashed." i would probably not have been confused if the phrasing had been: "until exactly the number of ... has been hashed." thanks for the clarification. Received: by ns.secondary.com (8.9.3/8.9.3) id IAA01308 for ietf-openpgp-bks; Wed, 17 May 2000 08:31:36 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA01302 for ; Wed, 17 May 2000 08:31:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA17677; Wed, 17 May 2000 08:39:08 -0700 Date: Wed, 17 May 2000 08:39:08 -0700 Message-Id: <200005171539.IAA17677@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > what happens in the case where the computed octet count is: > > -not an integer multiple of the length of salt + passphrase and > -greater than the length of salt + passphrase > > ? > > i presume that exactly "computed octet count" octets are handed to the > message digest algorithm (+ message digest padding), and not an > integer multiple number of instances of salt + passphrase. Yes. > so the last octet before message digest padding would not be the last > octet of the passphrase, as section 3.6.1.3 says: > > Then the salt, followed by the passphrase data is repeatedly hashed > until the number of octets specified by the octet count has been > hashed. The one exception is that if the octet count is less than > the size of the salt plus passphrase, the full salt plus passphrase > will be hashed even though that is greater than the octet count. > > is this correct? Yes, but I don't believe 3.6.1.3 says that the last octet before message digest padding would be the last octet of the passphrase. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id AAA07974 for ietf-openpgp-bks; Wed, 17 May 2000 00:48:26 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA07966 for ; Wed, 17 May 2000 00:48:23 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 17552 invoked from network); 17 May 2000 07:51:20 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 17 May 2000 07:51:20 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: <200005160251.WAA14064@finney.org> References: <200005160251.WAA14064@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000517165454U.1001@eccosys.com> Date: Wed, 17 May 2000 16:54:54 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 41 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: yet another clarifying question... From: hal@finney.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Mon, 15 May 2000 22:51:21 -0400 Message-ID: <200005160251.WAA14064@finney.org> > Actually what is input is: > > zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ... > > <--------------------- COUNT bytes -------------------------> > > and if COUNT (which is the computed octet count) is less than the length > of salt + passphrase, we hash enough bytes so that we include the full > salt + passphrase. what happens in the case where the computed octet count is: -not an integer multiple of the length of salt + passphrase and -greater than the length of salt + passphrase ? i presume that exactly "computed octet count" octets are handed to the message digest algorithm (+ message digest padding), and not an integer multiple number of instances of salt + passphrase. so the last octet before message digest padding would not be the last octet of the passphrase, as section 3.6.1.3 says: Then the salt, followed by the passphrase data is repeatedly hashed until the number of octets specified by the octet count has been hashed. The one exception is that if the octet count is less than the size of the salt plus passphrase, the full salt plus passphrase will be hashed even though that is greater than the octet count. is this correct? thanks again. Received: by ns.secondary.com (8.9.3/8.9.3) id XAA16151 for ietf-openpgp-bks; Mon, 15 May 2000 23:31:43 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA16147 for ; Mon, 15 May 2000 23:31:41 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 20974 invoked from network); 16 May 2000 06:34:36 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 16 May 2000 06:34:36 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: <200005160251.WAA14064@finney.org> References: <200005160251.WAA14064@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000516153807Y.1001@eccosys.com> Date: Tue, 16 May 2000 15:38:07 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 27 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Mon, 15 May 2000 22:51:21 -0400 Message-ID: <200005160251.WAA14064@finney.org> ... > > is this correct? > > No, unfortunately this is not correct, although I can see that the > "repeatedly hashed" language could be read this way. doh! perhaps another candidate for rewording :-) > Actually what is input is: > > zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ... > > <--------------------- COUNT bytes -------------------------> > > and if COUNT (which is the computed octet count) is less than the length > of salt + passphrase, we hash enough bytes so that we include the full > salt + passphrase. now i see the light! thanks again. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA13363 for ietf-openpgp-bks; Mon, 15 May 2000 22:44:55 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA13359 for ; Mon, 15 May 2000 22:44:53 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA14064; Mon, 15 May 2000 22:51:21 -0400 Date: Mon, 15 May 2000 22:51:21 -0400 Message-Id: <200005160251.WAA14064@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > ok, i think i've got it -- below is an outline of my current understanding. > > for each hash context instance, the initial input is: > > zero(s) + salt + passphrase > > output from the hash, o1, is a fixed number of bytes, h. > > if the length of salt + passphrase in bytes is less than the > calculated octet count, then o1 is given as input to the hash > function which produces o2 (also length h). > > if the length of salt + passphrase + o1 is less than the calculated > octet count, then o2 is given as input to the hash function and the > process continues until the length of: > > salt + passphrase + o1 + ... + on > > is greater than or equal to the calculated octet count. > > also, none of o1, ..., on have octets of zeros prepended. > > is this correct? No, unfortunately this is not correct, although I can see that the "repeatedly hashed" language could be read this way. Actually what is input is: zero(s) + salt + passphrase + salt + passphrase + salt + passphrase + ... <--------------------- COUNT bytes -------------------------> and if COUNT (which is the computed octet count) is less than the length of salt + passphrase, we hash enough bytes so that we include the full salt + passphrase. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id VAA07471 for ietf-openpgp-bks; Mon, 15 May 2000 21:38:21 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA07467 for ; Mon, 15 May 2000 21:38:19 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 19168 invoked from network); 16 May 2000 04:41:14 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 16 May 2000 04:41:14 -0000 To: ietf-openpgp@imc.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: <200005160041.UAA13745@finney.org> References: <200005160041.UAA13745@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000516134445F.1001@eccosys.com> Date: Tue, 16 May 2000 13:44:45 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 44 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Date: Mon, 15 May 2000 20:41:58 -0400 Message-ID: <200005160041.UAA13745@finney.org> ... > > 2) for iterated and salted s2k, is the calculated octet count value > > taken over all hash context instances or just the first instance? > > The count is per-instance. i think i understand now. > Each instance is given a number of bytes of salt and passphrase, > equal to the calculated octet count. The pre-loaded zeros are not > included in this count. ok, i think i've got it -- below is an outline of my current understanding. for each hash context instance, the initial input is: zero(s) + salt + passphrase output from the hash, o1, is a fixed number of bytes, h. if the length of salt + passphrase in bytes is less than the calculated octet count, then o1 is given as input to the hash function which produces o2 (also length h). if the length of salt + passphrase + o1 is less than the calculated octet count, then o2 is given as input to the hash function and the process continues until the length of: salt + passphrase + o1 + ... + on is greater than or equal to the calculated octet count. also, none of o1, ..., on have octets of zeros prepended. is this correct? thanks again for the clarifications. Received: by ns.secondary.com (8.9.3/8.9.3) id UAA04051 for ietf-openpgp-bks; Mon, 15 May 2000 20:35:33 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA04044 for ; Mon, 15 May 2000 20:35:32 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id UAA13745; Mon, 15 May 2000 20:41:58 -0400 Date: Mon, 15 May 2000 20:41:58 -0400 Message-Id: <200005160041.UAA13745@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > i have some additional questions about the two subsequent sections. section > 3.6.1.2 says: > > Salted S2K is exactly like Simple S2K, except that the input to the > hash function(s) consists of the 8 octets of salt from the S2K > specifier, followed by the passphrase. > > i presume this means that if the hash size is less than the key size, > the method of utilizing multiple hash contexts and prepending octets > of zeros described in 3.6.1.1 is employed. Yes. > i assume that this also applies to iterated and salted s2k (section 3.6.1.3). Yes. > if that is the case, suppose that the hash size is less than the key size: > > 1) for the second and subsequent hash context instances, do the octets > of zeros get prepended to the salt: > > zero(s) + salt + passphrase > > or are the zeros prepended to the passphrase: > > salt + zero(s) + passphrase > > ? i presume it is the former, is that correct? Yes. > 2) for iterated and salted s2k, is the calculated octet count value > taken over all hash context instances or just the first instance? The count is per-instance. Each instance is given a number of bytes of salt and passphrase, equal to the calculated octet count. The pre-loaded zeros are not included in this count. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id TAA26747 for ietf-openpgp-bks; Mon, 15 May 2000 19:34:17 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA26742 for ; Mon, 15 May 2000 19:34:13 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 17071 invoked from network); 16 May 2000 02:37:07 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 16 May 2000 02:37:07 -0000 To: ietf-openpgp@imc.org Subject: questions about sections 3.6.1.2 and 3.6.1.3 (was Re: question about section 3.6.1.1 simple s2k: how does preloading work?) In-Reply-To: References: <200005121215.IAA03777@finney.org> <20000514122641B.1001@eccosys.com> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000516114038J.1001@eccosys.com> Date: Tue, 16 May 2000 11:40:38 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Jon Callas Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? Date: Mon, 15 May 2000 13:53:36 -0700 Message-ID: > I'll look at clarifying the text. thanks very much. i have some additional questions about the two subsequent sections. section 3.6.1.2 says: Salted S2K is exactly like Simple S2K, except that the input to the hash function(s) consists of the 8 octets of salt from the S2K specifier, followed by the passphrase. i presume this means that if the hash size is less than the key size, the method of utilizing multiple hash contexts and prepending octets of zeros described in 3.6.1.1 is employed. i assume that this also applies to iterated and salted s2k (section 3.6.1.3). if that is the case, suppose that the hash size is less than the key size: 1) for the second and subsequent hash context instances, do the octets of zeros get prepended to the salt: zero(s) + salt + passphrase or are the zeros prepended to the passphrase: salt + zero(s) + passphrase ? i presume it is the former, is that correct? 2) for iterated and salted s2k, is the calculated octet count value taken over all hash context instances or just the first instance? thanks. Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04087 for ietf-openpgp-bks; Mon, 15 May 2000 14:06:59 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04083 for ; Mon, 15 May 2000 14:06:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id OAA01814; Mon, 15 May 2000 14:12:53 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id OAA01810; Mon, 15 May 2000 14:12:52 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000514122641B.1001@eccosys.com> References: <200005121215.IAA03777@finney.org> <20000514122641B.1001@eccosys.com> Date: Mon, 15 May 2000 13:53:36 -0700 To: sen_ml@eccosys.com, ietf-openpgp@imc.org From: Jon Callas Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'll look at clarifying the text. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id UAA06742 for ietf-openpgp-bks; Sat, 13 May 2000 20:20:31 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA06729 for ; Sat, 13 May 2000 20:20:28 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 10033 invoked from network); 14 May 2000 03:23:18 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 14 May 2000 03:23:18 -0000 To: ietf-openpgp@imc.org Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? In-Reply-To: <200005121215.IAA03777@finney.org> References: <200005121215.IAA03777@finney.org> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000514122641B.1001@eccosys.com> Date: Sun, 14 May 2000 12:26:41 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 40 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? Date: Fri, 12 May 2000 08:15:42 -0400 Message-ID: <200005121215.IAA03777@finney.org> > The "preloading" means to hash the preloaded data. In other words, > the preloaded data is a prefix to the rest of the data to be hashed. > It is not inserted directly into the state variables. > > Without preloading, you would do hash(data). Preloading one byte of > zero you would do hash(0,data). Preloading two bytes of data you would > do hash(0,0,data), and so on, where the commas represent concatenation. thank you very much for the clarification, i think i understand now. initially, i had thought that that might have been what was meant, but since elsewhere in the rfc the term "append" is used (5.1 and 5.5.3) to describe a similar type of concatenation, i thought that the term "prepend" might have been used if that was what was meant :-) also, the phrasing involving "perloading hash contexts" was confusing to me -- my image of a hash context comes from the source code of rfc 1321: MD5_CTX *context; /* context */ { context->count[0] = context->count[1] = 0; /* Load magic initialization constants. */ context->state[0] = 0x67452301; context->state[1] = 0xefcdab89; context->state[2] = 0x98badcfe; context->state[3] = 0x10325476; } this particular "context" doesn't appear to contain any octets from the message data to be hashed. is there a generally accepted definition for what constitutes a hash context? Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25406 for ietf-openpgp-bks; Fri, 12 May 2000 08:35:51 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25402 for ; Fri, 12 May 2000 08:35:50 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiowk07105; Fri, 12 May 2000 15:41:54 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA24764; Fri, 12 May 00 11:38:30 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id LAA18076; Fri, 12 May 2000 11:41:53 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14620.9792.804075.924572@xedia.com> Date: Fri, 12 May 2000 11:41:52 -0400 (EDT) To: hal@finney.org Cc: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? References: <200005121215.IAA03777@finney.org> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "hal" == hal writes: hal> The "preloading" means to hash the preloaded data. In other hal> words, the preloaded data is a prefix to the rest of the data to hal> be hashed. It is not inserted directly into the state hal> variables. hal> Without preloading, you would do hash(data). Preloading one hal> byte of zero you would do hash(0,data). Preloading two bytes of hal> data you would do hash(0,0,data), and so on, where the commas hal> represent concatenation. The use of terms like "preloading" and "multiple instances of the hash context" makes it sound like a description of an implementation, which of course isn't what you want in a protocol spec. I wonder if it would help to phrase it in the other way you just used: hash (data) concatenated with hash (0 data) concatenated with ... The key extension description in the IKE spec is done in this way, if memory serves. paul Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25313 for ietf-openpgp-bks; Fri, 12 May 2000 08:29:31 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25309 for ; Fri, 12 May 2000 08:29:28 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id QAA13766; Fri, 12 May 2000 16:35:35 +0100 (BST) Message-ID: Date: Fri, 12 May 2000 16:33:16 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME: Time for last call? References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> In-Reply-To: MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 12 May 2000, Florian Weimer wrote: >Ian Bell writes: > >[micalg parameter doesn't contain all information to precompute the hash] > >> I feel that 3) is the most satisfactory fix to the problem, but that at >> least 1) is incorporated into the draft before it is sent to last call. > >Or 4): Drop the micalg parameter. This will make one-pass processing >impossible, but I doubt that it's worth the trouble (unless the >theoretical possibility of one-pass processing is required by some >MIME standard). The micalg parameter is a required parameter of RFC1847. One-pass processing seems to have been a design-goal of RFC1847. I think there are benefits deriving from the fact that openPGP/MIME is based on RFC1847 which mean that the micalg parameter should not be dropped. (not least of which is that the multipart/mixed signature draft is written in terms of multiple RFC1847 signatures, not multiple openPGP/MIME signatures.) -- Ian Bell T U R N P I K E Ltd Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA25129 for ietf-openpgp-bks; Fri, 12 May 2000 08:16:53 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25125 for ; Fri, 12 May 2000 08:16:51 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin120-nt.pg12.frankfurt.nikoma.de [213.54.43.120]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id RAA31412; Fri, 12 May 2000 17:22:40 +0200 (CEST) (envelope-from roessler@guug.de) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id A44242ED3D; Fri, 12 May 2000 17:07:10 +0200 (CEST) Date: Fri, 12 May 2000 17:07:10 +0200 From: Thomas Roessler To: Florian Weimer Cc: Ian Bell , ietf-openpgp@imc.org Subject: Re: PGP/MIME: Time for last call? Message-ID: <20000512170710.A23026@sobolev.tlr-net.does-not-exist.org> Mail-Followup-To: Florian Weimer , Ian Bell , ietf-openpgp@imc.org References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3i In-Reply-To: ; from Florian.Weimer@RUS.Uni-Stuttgart.DE on Fri, May 12, 2000 at 04:46:10PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-05-12 16:46:10 +0200, Florian Weimer wrote: > Synchronizing OpenPGP-MIME with these developments is > not very complicated, but I think the benifit of having > a micalg parameter is even too small for that. Please note that the draft text already solves this: | The "micalg" parameter for the "application/pgp-signature" | protocol MUST contain exactly one hash-symbol of the | format "pgp-", where | identifies the Message Integrity Check (MIC) algorithm | used to generate the signature. Hash-symbols are | constructed from the text names registered in [1] or | according to the mechanism defined in that document by | converting the text name to lower case and prefixing it | with the four characters "pgp-". Ian: I'll come back to the issue you raised later. I'll have to check some things in 1847 for this. -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id IAA24927 for ietf-openpgp-bks; Fri, 12 May 2000 08:09:37 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA24923 for ; Fri, 12 May 2000 08:09:36 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA03777; Fri, 12 May 2000 08:15:42 -0400 Date: Fri, 12 May 2000 08:15:42 -0400 Message-Id: <200005121215.IAA03777@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: question about section 3.6.1.1 simple s2k: how does preloading work? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The "preloading" means to hash the preloaded data. In other words, the preloaded data is a prefix to the rest of the data to be hashed. It is not inserted directly into the state variables. Without preloading, you would do hash(data). Preloading one byte of zero you would do hash(0,data). Preloading two bytes of data you would do hash(0,0,data), and so on, where the commas represent concatenation. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id HAA24123 for ietf-openpgp-bks; Fri, 12 May 2000 07:41:26 -0700 (PDT) Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA24119 for ; Fri, 12 May 2000 07:41:21 -0700 (PDT) Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 12qGhe-0005aj-00; Fri, 12 May 2000 16:46:10 +0200 To: Ian Bell Cc: ietf-openpgp@imc.org Subject: Re: PGP/MIME: Time for last call? References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> From: Florian Weimer Date: 12 May 2000 16:46:10 +0200 Message-ID: Lines: 22 User-Agent: Gnus/5.0804 (Gnus v5.8.4) Emacs/20.5 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: Ian Bell writes: [micalg parameter doesn't contain all information to precompute the hash] > I feel that 3) is the most satisfactory fix to the problem, but that at > least 1) is incorporated into the draft before it is sent to last call. Or 4): Drop the micalg parameter. This will make one-pass processing impossible, but I doubt that it's worth the trouble (unless the theoretical possibility of one-pass processing is required by some MIME standard). Future revisions of the OpenPGP message standard might specify additional hash algorithms (which might even require some parameters); OpenPGP implementators might want to use proprietary algorithms, and so on. Synchronizing OpenPGP-MIME with these developments is not very complicated, but I think the benifit of having a micalg parameter is even too small for that. -- Florian Weimer Florian.Weimer@RUS.Uni-Stuttgart.DE University of Stuttgart http://cert.uni-stuttgart.de/ RUS-CERT +49-711-685-5973/fax +49-711-685-5898 http://ca.uni-stuttgart.de:11371/pks/lookup?op=get&search=0xC06EC3B5 Received: by ns.secondary.com (8.9.3/8.9.3) id BAA10032 for ietf-openpgp-bks; Fri, 12 May 2000 01:53:52 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA10022 for ; Fri, 12 May 2000 01:53:49 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 8858 invoked from network); 12 May 2000 08:56:35 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 12 May 2000 08:56:35 -0000 To: ietf-openpgp@imc.org Subject: question about section 3.6.1.1 simple s2k: how does preloading work? X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000512175954R.1001@eccosys.com> Date: Fri, 12 May 2000 17:59:54 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 40 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: i have a question about the "preloading" of hash contexts w/ zeros that is described in section 3.6.1.1. section 3.6.1.1 says: If the hash size is less than the key size, multiple instances of the hash context are created -- enough to produce the required key data. These instances are preloaded with 0, 1, 2, ... octets of zeros (that is to say, the first instance has no preloading, the second gets preloaded with 1 octet of zero, the third is preloaded with two octets of zeros, and so forth). i am trying to understand how this "preloading" works. using md5 as an example, would the values of the context state variables be: 0x00452301 0xefcdab89 0x98badcfe 0x10325476 for the second instance, and 0x00002301 0xefcdab89 0x98badcfe 0x10325476 for the third instance? that is, does the preloading occur after initializing the context state w/ A, B, C, D, (as in rfc 1321) and starting w/ the most significant byte? it is not clear to me from the text of the rfc (and the bis draft) that one can tell how the details of the preloading should work -- that is, it appears ambiguous to me. perhaps there is some general knowledge that i am ignorant of :-) is this type of preloading operation for hash contexts described in detail somewhere? any pointers would be appreciated. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02236 for ietf-openpgp-bks; Thu, 11 May 2000 01:40:57 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02232 for ; Thu, 11 May 2000 01:40:56 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA18968; Thu, 11 May 2000 09:46:52 +0100 (BST) Message-ID: Date: Thu, 11 May 2000 09:44:28 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME: Time for last call? References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> In-Reply-To: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 May 2000, Thomas Roessler wrote: >Does anyone see a reason why we should not start getting >the OpenPGP/MIME and multipart/mixed signature drafts into >the RFC process? Should the issue of binary versus text-mode signatures be addressed? RFC1847 had the design objective of aiding single-pass signature verification. To that end, it defined the micalg paramater so that the client could pre-calculate the hash over the MIME data. RFC2015 and RFC2015bis clients know what hash is required for the signature, but they don't know what data has actually been hashed. The line endings will always be CRLF because of the MIME canonicalization, but trailing spaces may or may not be included in the hash depending on the signature mode. Possible improvements to openPGP/MIME could therefore be: 1) Simply state the problem, and indicate that for one-pass processing, two hashes will have to be prepared - one for binary-mode signatures and one for text-mode signatures. 2) Mandate which form of signature must be used. Trailing spaces are often significant in email/news (sig-seps, RFC2646), so a binary-mode signature might seem preferable. However, existing PGP/MIME clients may be using either. 3) Define a "pgp-mode" parameter, pgp-mode=binary or pgp-mode=text and ensure that new clients add the parameter to the multipart/signed header. If the parameter is missing (RFC2015 messages), then one-pass clients will have to prepare two hashes. I feel that 3) is the most satisfactory fix to the problem, but that at least 1) is incorporated into the draft before it is sent to last call. -- Ian Bell T U R N P I K E Ltd Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28377 for ietf-openpgp-bks; Wed, 10 May 2000 08:16:26 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id IAA28371 for ; Wed, 10 May 2000 08:16:24 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 27256 invoked from network); 10 May 2000 15:19:05 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 May 2000 15:19:05 -0000 To: ietf-openpgp@imc.org Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) In-Reply-To: <20000510162847.M7032@djebel.gnupg.de> References: <20000510111014.H7032@djebel.gnupg.de> <20000510190520G.1001@eccosys.com> <20000510162847.M7032@djebel.gnupg.de> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000511002219O.1001@eccosys.com> Date: Thu, 11 May 2000 00:22:19 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 29 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Werner Koch Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) Date: Wed, 10 May 2000 16:28:47 +0200 Message-ID: <20000510162847.M7032@djebel.gnupg.de> > On Wed, 10 May 2000, sen_ml@eccosys.com wrote: > > > i presume you are referring to an mta on the sending client machine. > > that is correct, right? > > Sure. The local /usr/lib/sendmail should do it. this sounds like you are assuming a unix system w/ sendmail. what i'm a bit more concerned about is all of the windows and mac clients that i have to look after for my users. each of those clients connects to an external smtp server to send mail (i think that is a pretty typical setup, don't you?). i'm not very happy about the idea of messages being accidentally transmitted in the clear between the client and the smtp server [*]. it seems like for those cases the mail client should (perhaps also) be doing the checking. as a side note, in fact the mail client which i am using already supports a bit of "policy" w.r.t. replying to messages that were encrypted -- sadly it isn't a mail client that my windows and mac users will use :-( [*] good reason to use ssh port-forwarding of the relevant smtp connection i guess, but not everyone will be so lucky... Received: by ns.secondary.com (8.9.3/8.9.3) id HAA26956 for ietf-openpgp-bks; Wed, 10 May 2000 07:06:01 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA26952 for ; Wed, 10 May 2000 07:05:59 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12pXTj-000277-00; Wed, 10 May 2000 16:28:47 +0200 Date: Wed, 10 May 2000 16:28:47 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) Message-ID: <20000510162847.M7032@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000510135914U.1001@eccosys.com> <20000510111014.H7032@djebel.gnupg.de> <20000510190520G.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000510190520G.1001@eccosys.com>; from sen_ml@eccosys.com on Wed, May 10, 2000 at 07:05:20PM +0900 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 May 2000, sen_ml@eccosys.com wrote: > i presume you are referring to an mta on the sending client machine. > that is correct, right? Sure. The local /usr/lib/sendmail should do it. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20957 for ietf-openpgp-bks; Wed, 10 May 2000 03:27:28 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20953 for ; Wed, 10 May 2000 03:27:26 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin177-nt.pg7.frankfurt.nikoma.de [213.54.38.177]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id MAA37119; Wed, 10 May 2000 12:33:03 +0200 (CEST) (envelope-from roessler@guug.de) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id D99932ED3D; Wed, 10 May 2000 12:32:54 +0200 (CEST) Date: Wed, 10 May 2000 12:32:54 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Cc: John W Noerenberg II , Raph Levien , Michael Elkins , Dave Del Torto Subject: PGP/MIME: Time for last call? Message-ID: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org, John W Noerenberg II , Raph Levien , Michael Elkins , Dave Del Torto Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does anyone see a reason why we should not start getting the OpenPGP/MIME and multipart/mixed signature drafts into the RFC process? -- http://www.guug.de/~roessler/ Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17871 for ietf-openpgp-bks; Wed, 10 May 2000 02:59:29 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17864 for ; Wed, 10 May 2000 02:59:27 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 20990 invoked from network); 10 May 2000 10:02:06 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 May 2000 10:02:06 -0000 To: ietf-openpgp@imc.org Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) In-Reply-To: <20000510111014.H7032@djebel.gnupg.de> References: <20000510135914U.1001@eccosys.com> <20000510111014.H7032@djebel.gnupg.de> X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510190520G.1001@eccosys.com> Date: Wed, 10 May 2000 19:05:20 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 28 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Werner Koch Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) Date: Wed, 10 May 2000 11:10:14 +0200 Message-ID: <20000510111014.H7032@djebel.gnupg.de> > On Wed, 10 May 2000, sen_ml@eccosys.com wrote: > > > i would guess there have been cases of people who thought they had > > encrypted or signed a message before sending it, but it turned out > > they hadn't. i have a vague recollection of this being mentioned in a > > recent pgp usability study (perhaps someone can confirm). > > IMHO, an MTA which rejects unencrypted mails would be a better > alternative to protect against such kinds of failures. It may look > at some headers to detect ML replies and use a table of > addresses which are allowed to receive unencrypted mail. Or reject > everything unless a special formed address is used (which the MTA > substitutes for the real address). that is indeed another (not necessarily mutually exclusive) option. i presume you are referring to an mta on the sending client machine. that is correct, right? i think i would like a client that does both :-) in any case, i think it would make sense to point out somewhere these kinds of concerns -- hints for implementors. Received: by ns.secondary.com (8.9.3/8.9.3) id BAA13290 for ietf-openpgp-bks; Wed, 10 May 2000 01:47:32 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13286 for ; Wed, 10 May 2000 01:47:30 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12pSVS-0001s1-00; Wed, 10 May 2000 11:10:14 +0200 Date: Wed, 10 May 2000 11:10:14 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) Message-ID: <20000510111014.H7032@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000510135914U.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <20000510135914U.1001@eccosys.com>; from sen_ml@eccosys.com on Wed, May 10, 2000 at 01:59:14PM +0900 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 10 May 2000, sen_ml@eccosys.com wrote: > i would guess there have been cases of people who thought they had > encrypted or signed a message before sending it, but it turned out > they hadn't. i have a vague recollection of this being mentioned in a > recent pgp usability study (perhaps someone can confirm). IMHO, an MTA which rejects unencrypted mails would be a better alternative to protect against such kinds of failures. It may look at some headers to detect ML replies and use a table of addresses which are allowed to receive unencrypted mail. Or reject everything unless a special formed address is used (which the MTA substitutes for the real address). Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id VAA00559 for ietf-openpgp-bks; Tue, 9 May 2000 21:53:23 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA00549 for ; Tue, 9 May 2000 21:53:20 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 12687 invoked from network); 10 May 2000 04:56:02 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 May 2000 04:56:02 -0000 To: ietf-openpgp@imc.org Subject: suggesting displaying processed message before sending + confirmation (cf. rfc 2368) X-Mailer: Mew version 1.94.1 on Emacs 20.6 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000510135914U.1001@eccosys.com> Date: Wed, 10 May 2000 13:59:14 +0900 X-Dispatcher: imput version 991025(IM133) Lines: 32 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: for reference, the following text is from the security considerations section of rfc 2368: A mailto URL gives a template for a message that can be sent by mail client software. The contents of that template may be opaque or difficult to read by the user at the time of specifying the URL. Thus, a mail client should never send a message based on a mailto URL without first showing the user the full message that will be sent (including all headers that were specified by the mailto URL), fully decoded, and asking the user for approval to send the message as electronic mail. The mail client should also make it clear that the user is about to send an electronic mail message, since the user may not be aware that this is the result of a mailto URL. A mail client should never send anything without complete disclosure to the user of what is will be sent; it should disclose not only the message destination, but also any headers. Unrecognized headers, or headers with values inconsistent with those the mail client would normally send should be especially suspect. MIME headers (MIME- Version, Content-*) are most likely inappropriate, as are those relating to routing (From, Bcc, Apparently-To, etc.) in a similar vein, would it not make sense to recommend that mail clients display the encrypted or signed form of messages and ask for confirmation before actually sending the message? or at least recommend providing the capability to do so. i would guess there have been cases of people who thought they had encrypted or signed a message before sending it, but it turned out they hadn't. i have a vague recollection of this being mentioned in a recent pgp usability study (perhaps someone can confirm). Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23516 for ietf-openpgp-bks; Tue, 9 May 2000 10:38:51 -0700 (PDT) Received: from scooby.lineone.net ([194.75.152.224]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23285; Tue, 9 May 2000 10:36:53 -0700 (PDT) Received: from ukd ([195.171.177.9]) by scooby.lineone.net (8.9.3/8.9.3) with SMTP id QAA21977; Tue, 9 May 2000 16:27:42 +0100 (BST) Message-ID: <013c01bfb9cc$8f482480$09b1abc3@ukd> From: "Charlie Fletcher - www.ukdata.com" To: "Finance Director" Subject: Instant On-Line Credit Reports Date: Tue, 9 May 2000 16:34:00 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Do you need fast accurate information to assist you when appraising potential customers, and suppliers? The UK Data internet website www.ukdata.com contains 28 million pages of data with full information on every UK company! Credit Reports-Director Searches-Accounts-Annual Returns All of these products and many more are available to you immediately, and can be downloaded to and printed from your personal computer. Free samples of all reports are available at www.ukdata.com. Please also visit www.formacompany.co.uk the on-line company formation website Thank You Charles Fletcher www.ukdata.com an instant report on every UK business www.formacompany.co.uk the on-line company formation site www.irishdata.ie - instant reports on all Irish companies Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id GAA18254 for ietf-openpgp-bks; Tue, 9 May 2000 06:07:49 -0700 (PDT) Received: from sentry.gw.tislabs.com (firewall-user@sentry.gw.tislabs.com [192.94.214.100]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA18248 for ; Tue, 9 May 2000 06:07:47 -0700 (PDT) Received: by sentry.gw.tislabs.com; id JAA10418; Tue, 9 May 2000 09:15:31 -0400 (EDT) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma010411; Tue, 9 May 00 09:14:38 -0400 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id JAA17939 for ietf-openpgp@imc.org; Tue, 9 May 2000 09:07:54 -0400 (EDT) Date: Tue, 9 May 2000 09:07:54 -0400 (EDT) From: "David M. Balenson" Message-Id: <200005091307.JAA17939@clipper.gw.tislabs.com> To: ietf-openpgp@imc.org Subject: CFP: ISOC Netw & Distr Sys Security Symp (NDSS'01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: C A L L F O R P A P E R S The Internet Society 2001 Network and Distributed System Security Symposium (NDSS'01) February 7-9, 2001 Catamaran Resort, San Diego, California IMPORTANT DATES Paper Submission due: August 2, 2000 Author Notification: September 27, 2000 Camera-ready final papers due: October 31, 2000 GOAL: This symposium will foster information exchange among researchers and practioners of network and distributed system security services. The intended audience includes those who are interested in the practical aspects of network and distributed system security, focusing on actual system design and implementation, rather than theory. A major goal of the symposium is to encourage and enable the Internet community to apply, deploy, and advance the state of available security technology. The proceedings of the symposium will be published by the Internet Society. Submissions are solicited for, but are not limited to, the following topics: * Secure Electronic Commerce: e.g., payment, barter, EDI, notarization/timestamping, endorsement and licensing. * Intellectual Property Protection: protocols, schemas, implementations, metering, watermarking, other forms of rights management. * Implementation, deployment and management of network security policies. * Integrating Security in Internet protocols: routing, naming, TCP/IP, multicast, network management, and the Web. * Attack-resistant protocols and services. * Special problems and case studies: e.g., interplay and tradeoffs between security and efficiency, usability, reliability and cost. * Security for collaborative applications and services: tele- and video-conferencing, groupwork, etc. * Fundamental services: authentication, data integrity, confidentiality, authorization, non-repudiation, and availability. * Supporting mechanisms and APIs: key management and certification, revocation, audit trails and accountability. * Public Key Infrastructure. * Integrating security services with system and application security facilities and protocols: e.g., message handling, file transport/access, directories, time synchronization, database management, boot services, mobile computing. * Security for emerging technologies: sensor networks, specialized testbeds, wireless/mobile (and ad hoc) networks, personal communication systems, and large heterogeneous distributed systems. * Intrusion Avoidance, Detection, and Response: systems, experiences and architectures. * Network Perimeter Controls: firewalls, packet filters, application gateways. * Virtual Private Networks. BEST PAPER AWARD: There will be a best paper award again this year. The award will be presented at the symposium to the authors of the best overall paper as selected by the Program Committee. SUBMISSIONS: The Program Committee invites both technical papers and panel proposals. Technical papers should be at most 20 pages long. Panel proposals should be at most two pages and should describe the topic, identify the panel chair, explain the format of the panel, and list three to four potential panelists. Technical papers will appear in the proceedings. A description of each panel will appear in the proceedings, and may - at the discretion of the panel chair - include written position statements from the panelists. Each submission must contain a separate title page with the type of submission (paper or panel), the title or topic, the names of the author(s), organizational affiliation(s), telephone and FAX numbers, postal addresses, e-mail addresses, and must specify the contact author in case of multi-author submissions. The names of authors, affiliations, and other identifying information should appear only on the separate title page. Submissions must be received by August 2, 2000, and must be made via electronically in either PostScript or ASCII format. If the Committee is unable to print a PostScript submission, a hardcopy will be requested. Therefore, PostScript submissions must arrive well before the deadline. Submission information can be found at http://www.isoc.org/ndss01/cfp. Dates, final call for papers, advance program, and registration information will be available soon at http://www.isoc.org/ndss01. Each submission will be acknowledged by e-mail. If acknowledgment is not received within seven days, please contact the program Co-chairs as indicated below. Authors and panelists will be notified of acceptance by September 27, 2000. Instructions for preparing camera-ready copy for the proceedings will be sent at that time. The camera-ready copy must be received by October 31, 2000. GENERAL CHAIR: Stephen Welke, Trusted Computer Solutions PROGRAM CO-CHAIRS: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies TUTORIAL CHAIR: Eric Harder, National Security Agency LOCAL ARRANGEMENTS CHAIR: Thomas Hutton, San Diego Supercomputer Center PUBLICATIONS CHAIR: Mahesh Tripunitara, Purdue University PUBLICITY CHAIR: David Balenson, NAI Labs, Network Associates LOGISTICS CHAIR: Carla Rosenfeld, Internet Society PROGRAM COMMITTEE: Bennet Yee, University of California San Diego Bill Cheswick, Bell Labs Dave Kormann, AT&T Labs - Research David Aucksmith, Intel Corportation David P. Maher, Intertrust David Wagner, UC Berkeley Edward W. Felten, Princeton University Fabian Monrose, Bell Labs Gary McGraw, Reliable Software Technologies James Ellis, Sun Microsystems Kevin McCurley, IBM Almaden Research Center Matt Bishop, UC Davis Mudge, L0pht Heavy Industries, Inc. Peter Gutmann, University of Auckland, New Zealand Radia Perlman, Sun Microsystems Sandra Murphy, Network Associates Tom Berson, Anagram Laboratories Virgil D. Gligor, University of Maryland