From owner-ietf-openpgp@mail.imc.org Fri Dec 1 14:22:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29504 for ; Fri, 1 Dec 2000 14:22:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA18184 for ietf-openpgp-bks; Fri, 1 Dec 2000 11:04:10 -0800 (PST) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18179 for ; Fri, 1 Dec 2000 11:04:06 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA55564 for ; Fri, 1 Dec 2000 13:38:02 -0500 (EST) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id OAA07013 for ; Fri, 1 Dec 2000 14:05:09 -0500 (EST) Message-ID: <001201c05bc9$82930080$66c52609@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: Encoding of hash in El-Gamal signatures Date: Fri, 1 Dec 2000 14:04:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- The specification already mentions precautions in ElGamal signature handling, and provides a reference. The original question is still valid, though, and I'd also be interested in seeing clarification. If the specification includes ElGamal signatures, it should provide sufficient definition to achieve interoperability. For other algorithms, there is a discussion of how the hash is padded (where applicable) and what the algorithm-specific fields in the signature should be. One might guess that the same PKCS-1 padding scheme should be used, and that the MPIs should be the "r" (=g^k mod p) and "s" (=(h-r*x)/k mod p) values, in that order. Is that right? Yes, I could use the GnuPG source as the specification, but that shouldn't be necessary. If you want to argue that OpenPGP shouldn't support this algorithm, and that it should be removed from the specification entirely, I wouldn't object. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOif2F2NDnIII+QUHAQF+PAf8DkebuHLUbNgHWtZv6r0vDTnnqxjZAEv6 B6UGtwa1llicCQUED+K5kfQDM4O4hi+GDfvrnnEhsmy7j2V2hBPwS0hWm6dnlmQF I08MGLL6ZikTu6OZwMc9eQi7vlce7ZfWqSQc97T7muhq7oXQu66gYEN3AoaH600L 9xY9BF3NzogIsK74/UYWTFlshjRwtDyh4ycShoEk3CQPYoS0UBgWjxLbZcehup3w T3plyY8GKD/z9BIakfvubkRp5V2t+onvjFj8pojqjqNSibv8izvuCOkBBePGBt+l WNkbs97K7XzDNOF1Dh1unhbX6I7ZlBi5fZ+Vebzl3bx3m6eCGKnVPg== =2FiL -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Dec 8 01:06:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11649 for ; Fri, 8 Dec 2000 01:06:06 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA13485 for ietf-openpgp-bks; Thu, 7 Dec 2000 21:49:18 -0800 (PST) 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 VAA13481 for ; Thu, 7 Dec 2000 21:49:17 -0800 (PST) Received: (from marc@localhost) by horowitz.ne.mediaone.net (8.8.8/8.8.8) id AAA08004; Fri, 8 Dec 2000 00:51:20 -0500 (EST) X-Authentication-Warning: horowitz.ne.mediaone.net: marc set sender to marc@horowitz.ne.mediaone.net using -f From: Marc Horowitz To: ietf-openpgp@imc.org Subject: rfc2440bis-02 comments Date: 08 Dec 2000 00:51:19 -0500 Message-ID: Lines: 62 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.3 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: Many of these comments come from notes I took on rfc2440, so I may have some section numbers wrong. I did compare these notes to the I-D, and I believe all of them are still relevant. 1. Section 5.2 is vague about how to compute signature types 0x30 and 0x40. The document should specify over what data to compute the hash to be signed. There was also a comment in the list archives about the description of signature type 0x18, which says This signature is calculated directly on the subkey itself, not on any User ID or other packets. This is tremendously misleading, since the signature is actually computed on a hash over a prefix, the key packet, the subkey packet, and a trailer. Section 5.2.4 gives a more detailed description of how to compute a subkey binding signature. 2. Section 5.2.4 contains another error. It states Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked. However, analysis of existing implementations indicates that this is incorrect for subkey revocation signatures (type 0x28); like type 0x18, both the primary key and the subkey are included in the hash. 3. Subpacket 23 (key server preferences) is specified to be "found only on a self-signature". It should say if that means a direct key signature (which makes the most sense to me), or something else. 4. The document is vague on what constitures "advisory information" in a signature subpacket (section 5.2.3). I believe that unhashed signature subpackets were a mistake (I can expound on this if people want). If existing implementations did not include unsigned subpackets, I would suggest removing them from the spec entirely. However, current implementations usually include the issuer key id subpacket (type 16) in the unhashed subpackets. Therefore, I suggest that implementations MUST NOT generate any unhashed subpackets, SHOULD accept type 16 unsigned subpackets in order to process existing signatures, and MUST NOT accept any other subpacket types in the unhashed subpackets. 5. There should be a note that the critical bit MUST be ignored on unhashed signature subpackets. Otherwise, an attacker can easily cause any signature to fail to verify. 6. The terms used in 11.1 are inconsistent with the rest of the document, and in some places, the rest of the document is also inconsistent. Where 11.1 uses "revocation self signature", the rest of the document uses "key revocation signature". Where 11.1 uses "direct key self signature", the rest of the document uses "direct key signature", "direct-key signature", and "Signature directly on a key". Where 11.1 uses "binding-signature-revocation", the rest of the document uses "subkey revocation signature". Where 11.1 uses primary-key-binding-signature", the rest of the document uses "subkey binding signature". Marc From owner-ietf-openpgp@mail.imc.org Fri Dec 8 07:16:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA02097 for ; Fri, 8 Dec 2000 07:16:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA24670 for ietf-openpgp-bks; Fri, 8 Dec 2000 03:57:25 -0800 (PST) Received: from mail.hsp.de (mail.hsp.de [194.77.127.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24657 for ; Fri, 8 Dec 2000 03:57:22 -0800 (PST) Received: from kasiski.gnupg.de (werner-gw.openit.de [194.231.77.111]) by mail.hsp.de (8.11.1/8.11.1) with ESMTP id eB8BxZH07251 for ; Fri, 8 Dec 2000 12:59:35 +0100 Received: from wk by kasiski.gnupg.de with local (Exim 3.16 #1 (Debian)) id 144MGJ-0007eW-00; Fri, 08 Dec 2000 13:04:27 +0100 Date: Fri, 8 Dec 2000 13:04:27 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: rfc2440bis-02 comments Message-ID: <20001208130427.J21969@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.2.5i In-Reply-To: ; from marc@mit.edu on Fri, Dec 08, 2000 at 12:51:19AM -0500 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 8 Dec 2000, Marc Horowitz wrote: > 3. Subpacket 23 (key server preferences) is specified to be "found > only on a self-signature". It should say if that means a direct > key signature (which makes the most sense to me), or something As with many other subpackets there is no clear definition on what to do and it is left to the implementor to decide this. From my understanding it does make sense to handle such things this way: * If it is on any direct key signature, use this one (or exactly the one on the latest direct key signure. * Otherwise take it from the latest self-signature. (I have worked out some more rules and checked them with Hal. Currently I can't access them - please ask me next week, if you are interested) > 4. The document is vague on what constitures "advisory information" in > a signature subpacket (section 5.2.3). I believe that unhashed > signature subpackets were a mistake (I can expound on this if No, they make sense. It may happen that you need to store some meta information about a signature which you have to calculate after signature creation. However, a big warning about unhashed stuff should be present. > 5. There should be a note that the critical bit MUST be ignored on > unhashed signature subpackets. Otherwise, an attacker can easily > cause any signature to fail to verify. Does not make sense. An attacker can make _any_ signature fail but just flipping one bit. Werner From owner-ietf-openpgp@mail.imc.org Sat Dec 9 12:31:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25830 for ; Sat, 9 Dec 2000 12:31:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17721 for ietf-openpgp-bks; Sat, 9 Dec 2000 09:12:36 -0800 (PST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17717; Sat, 9 Dec 2000 09:12:34 -0800 (PST) Message-Id: <200012091712.JAA17717@ns.secondary.com> From: Mail Sender To: ietf-nntp-request@academ.com CC: ietf-openpgp@imc.org, ietf-openpgp-request@imc.org, ietf-otp@research.telcordia.com, ietf-otp-request@research.telcordia.com, ietf-pkix@imc.org Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 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: www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru From owner-ietf-openpgp@mail.imc.org Mon Dec 11 19:26:54 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14248 for ; Mon, 11 Dec 2000 19:26:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08725 for ietf-openpgp-bks; Mon, 11 Dec 2000 14:58:29 -0800 (PST) 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 OAA08719 for ; Mon, 11 Dec 2000 14:58:28 -0800 (PST) Received: by sentry.gw.tislabs.com; id SAA25981; Mon, 11 Dec 2000 18:04:02 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma025973; Mon, 11 Dec 00 18:03:09 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id RAA29304 for ietf-openpgp@imc.org; Mon, 11 Dec 2000 17:59:27 -0500 (EST) Date: Mon, 11 Dec 2000 17:59:27 -0500 (EST) From: "David M. Balenson" Message-Id: <200012112259.RAA29304@clipper.gw.tislabs.com> To: ietf-openpgp@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. From owner-ietf-openpgp@mail.imc.org Tue Dec 12 05:41:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05030 for ; Tue, 12 Dec 2000 05:41:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA20130 for ietf-openpgp-bks; Tue, 12 Dec 2000 02:23:43 -0800 (PST) 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 CAA20124 for ; Tue, 12 Dec 2000 02:23:41 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id KAA23033; Tue, 12 Dec 2000 10:26:13 GMT Message-ID: Date: Tue, 12 Dec 2000 10:23:24 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Dash-escaping and the Usenet sig convention 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: It has been suggested that our mail/news client offer an option to "fix up" the Usenet sig separator in clear-signed messages to newsgroups/mailing lists - the problem being that the "-- " gets stuffed to "- -- " with the result that recipients' clients will no longer recognize and strip the personal signature in response messages. The dash-escaping leads to complaints about clear-signed messages to some groups and some users have taken to removing the dash-escaping by hand. Although this breaks RFC2440, (NAI)PGP clients still seem to correctly "de-escape" the message and verify the PGP signature. The question is, how do openPGP clients cope with such messages and what do other client vendors think about this? Since [open]PGP clients only need to be able to correctly parse nested ASCII-armored header lines, and these all begin with five hyphens, it would be possible to make an exception for lines such as "-- " when doing the dash-escaping. Munging the "- -- " back to "-- " does seem to yield benefits in inter- operability (for the sig-sep convention) and acceptability of PGP-signed messages, but it is important that it doesn't break inter-operability between PGP clients. Should RFC2440bis be updated to mention this? Do any existing clients fall over by spotting that some lines are escaped at the "wrong" depth? -- Ian Bell T U R N P I K E From owner-ietf-openpgp@mail.imc.org Tue Dec 12 08:14:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21788 for ; Tue, 12 Dec 2000 08:14:08 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA10944 for ietf-openpgp-bks; Tue, 12 Dec 2000 04:56:18 -0800 (PST) Received: from mail.hsp.de (mail.hsp.de [194.77.127.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10931 for ; Tue, 12 Dec 2000 04:56:08 -0800 (PST) Received: from kasiski.gnupg.de (werner-gw.openit.de [194.231.77.111]) by mail.hsp.de (8.11.1/8.11.1) with ESMTP id eBCCwXH02598 for ; Tue, 12 Dec 2000 13:58:33 +0100 Received: from wk by kasiski.gnupg.de with local (Exim 3.16 #1 (Debian)) id 145ovV-0004bQ-00; Tue, 12 Dec 2000 13:53:01 +0100 Date: Tue, 12 Dec 2000 13:53:01 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Dash-escaping and the Usenet sig convention Message-ID: <20001212135300.N21969@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.2.5i In-Reply-To: ; from ianbell@turnpike.com on Tue, Dec 12, 2000 at 10:23:24AM +0000 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 12 Dec 2000, Ian Bell wrote: > newsgroups/mailing lists - the problem being that the "-- " gets stuffed > to "- -- " with the result that recipients' clients will no longer The preferred way to encapsulate OpenPGP messages in mail is by using MIME as defined in RFC2015. No need for the old fashioned cleartext signing. > The question is, how do openPGP clients cope with such messages and what It is a matter of the MUA to handle this right. Mutt for example does remove the dash escaping even when it does not verify the signature. Werner From owner-ietf-openpgp@mail.imc.org Tue Dec 12 11:34:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16647 for ; Tue, 12 Dec 2000 11:34:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25188 for ietf-openpgp-bks; Tue, 12 Dec 2000 08:03:56 -0800 (PST) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25179 for ; Tue, 12 Dec 2000 08:03:54 -0800 (PST) Received: from [63.73.97.184] (208.54.71.35) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1); Tue, 12 Dec 2000 08:06:18 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <20001212135300.N21969@gnupg.de> References: <20001212135300.N21969@gnupg.de> Date: Tue, 12 Dec 2000 08:06:12 -0800 To: Werner Koch , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Dash-escaping and the Usenet sig convention Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Re: Dash-escaping and the Usenet sig convention", shown on 12/12/00), Werner Koch said: >The preferred way to encapsulate OpenPGP messages in mail is by using >MIME as defined in RFC2015. No need for the old fashioned cleartext >signing. > I disagree completely. The correct way to encapsulate messages is with cleartext. I often delete PGP-MIME messages without reading them because it's such a pain to deal with them. I commonly use five different mail readers on four different OSes, and none of them do PGP-MIME reliably. That's Eudora on Mac and Windows, Outlook on Windows, Netscape and Pine on Linux and OSX. The biggest pain is on Windows, where it's hard to scrape up the attachment to put it in a text editor. >> The question is, how do openPGP clients cope with such messages and what > >It is a matter of the MUA to handle this right. Mutt for example >does remove the dash escaping even when it does not verify the >signature. I agree that this is a MUA and newsreader issue. They should parse out the quoting. The dash-escape may be ugly, but it's been a part of PGP since day 2, if not day 1. Jon From owner-ietf-openpgp@mail.imc.org Tue Dec 12 12:12:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA26827 for ; Tue, 12 Dec 2000 12:12:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28049 for ietf-openpgp-bks; Tue, 12 Dec 2000 08:40:27 -0800 (PST) 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 IAA28044 for ; Tue, 12 Dec 2000 08:40:26 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id QAA22090; Tue, 12 Dec 2000 16:42:59 GMT Message-ID: Date: Tue, 12 Dec 2000 16:42:20 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: Dash-escaping and the Usenet sig convention References: <20001212135300.N21969@gnupg.de> In-Reply-To: <20001212135300.N21969@gnupg.de> 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 12 Dec 2000, Werner Koch wrote: >On Tue, 12 Dec 2000, Ian Bell wrote: > >> newsgroups/mailing lists - the problem being that the "-- " gets stuffed >> to "- -- " with the result that recipients' clients will no longer > >The preferred way to encapsulate OpenPGP messages in mail is by using >MIME as defined in RFC2015. In an ideal world, PGP/MIME would be the only way anyone would send PGP in email... > No need for the old fashioned cleartext >signing. ...however, the reality is that most clients (in terms of numbers deployed) seem not to be able to cope. We have been asked to munge the dash-stuffed clear text as in practice the use of PGP/MIME signed messages causes more complaints than clear- signed messages, but clear-signing messages causes complaints about broken sig-seps :-( >> The question is, how do openPGP clients cope with such messages and what > >It is a matter of the MUA to handle this right. Mutt for example >does remove the dash escaping even when it does not verify the >signature. As does Turnpike. However, it will be the openPGP client that has to deal with the clear-text message with dash-stuffing that breaks RFC- 2440. As an example I have signed this message and broken the dash- stuffing (behind Turnpike's back, I might add!). I'd be interested if it causes any problems. -- Ian Bell T U R N P I K E -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBOjZUxb3aNYn/fmK7EQLGcACdH2kUCbQH06wWa/9Ap/6XaaWpdBMAnj1G IoOPuvpMBehwVZFZ52sEW63d =yQWW -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Dec 15 06:26:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09506 for ; Fri, 15 Dec 2000 06:26:25 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03485 for ietf-openpgp-bks; Fri, 15 Dec 2000 03:08:48 -0800 (PST) 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 DAA03479 for ; Fri, 15 Dec 2000 03:08:46 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id DAA06530; Fri, 15 Dec 2000 03:11:15 -0800 Date: Fri, 15 Dec 2000 03:11:03 -0800 (PST) From: "L. Sassaman" X-Sender: To: Marc Horowitz cc: Subject: Re: rfc2440bis-02 comments In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc mentioned 5.2.3.17 (Key server preferences) and that reminded me of a suggestion I wanted to make. One of the major complaints I hear about PGP key servers is the inability to delete keys once they are sent to the server. I'd like to request the addition of two new flags for subpacket 23: 0x40 = Disabled the key holder requests that this key not be returned upon a search of the key server. 0x60 = Enabled the key holder requests that this key be returned upon a search of the key server. Keys bearing the disabled flag would either reside on the key server and never be returned in a search (except perhaps to the administrator), or they would be immediately deleted upon receipt by the key server. (The reason for the enabled flag is to reverse the effects of the disabled flag at a later date. And of course, if neither the disabled not the enabled flags are set, keys are implicitly enabled.) __ L. Sassaman Security Architect | "The world's gone crazy, Technology Consultant | and it makes no sense..." | http://sion.quickie.net | --Sting -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE6OfxSPYrxsgmsCmoRAug/AKDPWFT9+sykMTtbg3h6oheoaZEeuwCgipzp JLp7rXBfHFN5+uqIDz4h7R8= =7h+X -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Dec 15 17:44:01 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16300 for ; Fri, 15 Dec 2000 17:44:00 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18461 for ietf-openpgp-bks; Fri, 15 Dec 2000 14:25:58 -0800 (PST) Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18456 for ; Fri, 15 Dec 2000 14:25:57 -0800 (PST) Received: from [204.179.131.28] (204.179.131.133) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2); Fri, 15 Dec 2000 14:28:45 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 15 Dec 2000 14:22:43 -0800 To: "L. Sassaman" From: Dave Del Torto Subject: Re: rfc2440bis-02 comments Cc: Marc Horowitz , 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 3:11 am -0800 2000-12-15, L. Sassaman wrote: >One of the major complaints I hear about PGP key servers is the inability >to delete keys once they are sent to the server. I'd like to request the >addition of two new flags for subpacket 23: > > 0x40 = Disabled > the key holder requests that this key not be returned upon > a search of the key server. > > 0x60 = Enabled > the key holder requests that this key be returned upon a > search of the key server. > >Keys bearing the disabled flag would either reside on the key server and >never be returned in a search (except perhaps to the administrator), or >they would be immediately deleted upon receipt by the key server. Len, I'm intrigued by your idea of "disabling" keys as a solution to this problem. I think it could be a useful addition, even with the questions it raises. If the intent is to allow a Alice to effectively Remove her public key -- even if the keyserver's policy/software doesn't allow her to Delete it -- then I think this is useful. Of course, this presumes that Alice still retains her ability to modify the public key. However, if the intent is to "mask" the presence of Bob's key on the keyserver in lieu of Deleting it, it's hard to see what sort of keyserver response behaviour would prevent Eve from trying to determine the presence of Bob's key on the server -- by deducing that information using the very 0x40 flag you describe in conjunction with the keyserver behaviour. This simply shifts the policy focus from the pksd's delete policy to its search policy. All Eve would need to do is upload the public component to the keyserver in order to determine the status of the subpacket 23 enable/disable flags: if the key is present but disabled, it will "vanish," confirming that it's disabled. If not present, it will be returned by a subsequent search. A rudimentary traffic analysis technique. The big question of course, is "who can set these flags?" IMHO, they musn't be outside the hashed subpackets: they need to be set by the key-owner, lest they contribute to a DoS attack on any given public key. This means that Alice or Bob could just as easily Revoke (or, pksd policy permitting, Delete) their keypairs. If the keyserver admmin is to be allowed to set the flag, this raises a serious key management policy question, again just shifting the problem elsewhere, but not solving it entirely. dave From owner-ietf-openpgp@mail.imc.org Fri Dec 15 17:57:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19611 for ; Fri, 15 Dec 2000 17:57:03 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19005 for ietf-openpgp-bks; Fri, 15 Dec 2000 14:44:45 -0800 (PST) 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 OAA19000 for ; Fri, 15 Dec 2000 14:44:43 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id OAA21493; Fri, 15 Dec 2000 14:46:56 -0800 Date: Fri, 15 Dec 2000 14:46:48 -0800 (PST) From: "L. Sassaman" X-Sender: To: Dave Del Torto cc: Marc Horowitz , Subject: Re: rfc2440bis-02 comments In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 15 Dec 2000, Dave Del Torto wrote: > If the intent is to allow a Alice to effectively Remove her public > key -- even if the keyserver's policy/software doesn't allow her to > Delete it -- then I think this is useful. Of course, this presumes > that Alice still retains her ability to modify the public key. Of course. > However, if the intent is to "mask" the presence of Bob's key on the > keyserver in lieu of Deleting it, it's hard to see what sort of > keyserver response behaviour would prevent Eve from trying to > determine the presence of Bob's key on the server -- by deducing that > information using the very 0x40 flag you describe in conjunction with > the keyserver behaviour. This simply shifts the policy focus from the > pksd's delete policy to its search policy. > > All Eve would need to do is upload the public component to the > keyserver in order to determine the status of the subpacket 23 > enable/disable flags: if the key is present but disabled, it will > "vanish," confirming that it's disabled. If not present, it will be > returned by a subsequent search. A rudimentary traffic analysis > technique. Where is the threat here? The reason I prefer a "disable" approach to a "delete" approach is that deleted keys can always reappear. The behavior you describe seems to me to be the appropriate one. > The big question of course, is "who can set these flags?" IMHO, they > musn't be outside the hashed subpackets: they need to be set by the > key-owner, lest they contribute to a DoS attack on any given public > key. This means that Alice or Bob could just as easily Revoke (or, > pksd policy permitting, Delete) their keypairs. If the keyserver > admmin is to be allowed to set the flag, this raises a serious key > management policy question, again just shifting the problem > elsewhere, but not solving it entirely. Right, no one, not even the key server admin, would be able to set these flags besides the key owner. I didn't feel that needed stating, since these flags are an addition to an existing subpacket which is already only found in self-signatures. They MUST NOT be placed outside the hashed area. - --Len. __ L. Sassaman Security Architect | "The world's gone crazy, Technology Consultant | and it makes no sense..." | http://sion.quickie.net | --Sting -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE6Op9fPYrxsgmsCmoRAvRKAKCsxYv996YOGDSAqWyAa+iSuJltqgCg+wn8 F54h58lhEm9yYUcvEAuiHAY= =/A05 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Dec 15 19:05:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07562 for ; Fri, 15 Dec 2000 19:05:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20533 for ietf-openpgp-bks; Fri, 15 Dec 2000 15:51:24 -0800 (PST) Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20529 for ; Fri, 15 Dec 2000 15:51:23 -0800 (PST) Received: from [204.179.131.28] (204.179.131.133) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2); Fri, 15 Dec 2000 15:54:13 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 15 Dec 2000 15:48:57 -0800 To: "L. Sassaman" From: Dave Del Torto Subject: Re: rfc2440bis-02 comments Cc: Marc Horowitz , , pgp-keyserver-folk@flame.org 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 2:46 pm -0800 2000-12-15, L. Sassaman wrote: >On Fri, 15 Dec 2000, Dave Del Torto wrote: >>However, if the intent is to "mask" the presence of Bob's key on >>the keyserver in lieu of Deleting it, it's hard to see what sort of >>keyserver response behaviour would prevent Eve from trying to >>determine the presence of Bob's key on the server -- by deducing >>that information using the very 0x40 flag you describe in >>conjunction with the keyserver behaviour. This simply shifts the >>policy focus from the pksd's delete policy to its search policy. >> >>All Eve would need to do is upload the public component to the >>keyserver in order to determine the status of the subpacket 23 >>enable/disable flags: if the key is present but disabled, it will >>"vanish," confirming that it's disabled. If not present, it will be >>returned by a subsequent search. A rudimentary traffic analysis >>technique. > >Where is the threat here? The threat, perhaps a theoretical one at this point in time, is that if you're trying to mask the very existence of your key on one or more keyservers (for example to thwart an improperly coercive demand for keying material from rogue officials), you will not be able to do so with these flags. You would only be able to do this by deleting them via an LDAPS (or similarly secure) keyserver connection. BTW, the trail of evidence that Deletion would involve, reminds me of another thread I wanted to raise (wearing my CryptoRights hat) with the keyserver managers, regarding the need for standardized mechanisms permitting secure, UNauthenticated, UNlogged connections to keyservers. Deleting a key would still require a passphrase, but it would permit one to clear a key if one was under threat. >The reason I prefer a "disable" approach to a "delete" approach is >that deleted keys can always reappear. The behavior you describe >seems to me to be the appropriate one. We can agree on that much. I guess I'm just applying a more stringent threat model -- speculating that regimes like RIPA may someday soon negatively impact the human rights of crypto users. I still like your key-disable flag idea, Len. dave From owner-ietf-openpgp@mail.imc.org Fri Dec 15 20:09:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27756 for ; Fri, 15 Dec 2000 20:09:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA21688 for ietf-openpgp-bks; Fri, 15 Dec 2000 16:51:40 -0800 (PST) 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 QAA21682 for ; Fri, 15 Dec 2000 16:51:38 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id QAA25198; Fri, 15 Dec 2000 16:54:03 -0800 Date: Fri, 15 Dec 2000 16:53:55 -0800 (PST) From: "L. Sassaman" X-Sender: To: Dave Del Torto cc: Marc Horowitz , , Subject: Re: rfc2440bis-02 comments In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 15 Dec 2000, Dave Del Torto wrote: > The threat, perhaps a theoretical one at this point in time, is > that if you're trying to mask the very existence of your key on > one or more keyservers (for example to thwart an improperly coercive > demand for keying material from rogue officials), you will not be able > to do so with these flags. You would only be able to do this by > deleting them via an LDAPS (or similarly secure) keyserver connection. Sure. That isn't the threat these flags were intended to solve. In fact, I am not sure this threat you mention isn't an intractable problem; once a key is deleted from the server, it can always be re-added by a third party. (Unless, of course, the no-modify flag is set. Then the owner of the key would be required to authenticate himself prior to adding the key to the server.) > BTW, the trail of evidence that Deletion would involve, reminds me of > another thread I wanted to raise (wearing my CryptoRights hat) with > the keyserver managers, regarding the need for standardized > mechanisms permitting secure, UNauthenticated, UNlogged connections > to keyservers. Deleting a key would still require a passphrase, but > it would permit one to clear a key if one was under threat. Hrmm. guaranteeing that connections are unlogged isn't really possible, I don't think. Though if this became a really important issue, I suspect you could set up some sort of key request system using the anonymous remailer network... but that seems a bit extreme. Rodney Thayer and I are working on an Internet Draft for key server behavior. We'll try to cover all these issues in there, and will welcome any comments on it when we publish. (Key server issues are really beyond the scope of 2440. The only reason I've brought this up now is that I would like to see these flags added so we can utilize them in the key servers.) Thanks for your comments, - --Len. __ L. Sassaman Security Architect | "The world's gone crazy, Technology Consultant | and it makes no sense..." | http://sion.quickie.net | --Sting -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE6Or0qPYrxsgmsCmoRAo3bAKDkWxI1TZK+devdAK/dpF0RqLogfQCgupTw UxT8xssVKNoNxR2ezEPpHZs= =UbHQ -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun Dec 17 12:48:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10680 for ; Sun, 17 Dec 2000 12:48:13 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27124 for ietf-openpgp-bks; Sun, 17 Dec 2000 09:18:15 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27120 for ; Sun, 17 Dec 2000 09:18:13 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id MAA30834; Sun, 17 Dec 2000 12:21:05 -0500 To: "L. Sassaman" Cc: Dave Del Torto , Marc Horowitz , , Subject: Re: rfc2440bis-02 comments References: From: Derek Atkins Date: 17 Dec 2000 12:21:05 -0500 In-Reply-To: "L. Sassaman"'s message of "Fri, 15 Dec 2000 16:53:55 -0800 (PST)" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Unfortunately this particular approach will not solve what I believe to be the bigger problem: "I reinstalled my machine and lost my secret key; can you remove it from the keyserver, please?" or "I forgot my passphrase, can you please delete my key from the keyservers?" If I had a dollar for every time I received one of these messages, I'd be a very rich man right now ;) The additional packets really don't help much more than being able to revoke one's key. If one could 'disable' a key themselves, they could also revoke that same key. The problem is that most of the requests come from people who cannot modify their key (due to circumstances that may or may not be out of their control). If we're going to solve the "key disable" problem, we need to do so in a manner that helps the user who lost their own key. Otherwise the solution really doesn't solve the real problems that exist today. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Mon Dec 18 00:59:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA22777 for ; Mon, 18 Dec 2000 00:59:17 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA22070 for ietf-openpgp-bks; Sun, 17 Dec 2000 21:40:07 -0800 (PST) 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 VAA22065 for ; Sun, 17 Dec 2000 21:40:01 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 22085 invoked from network); 18 Dec 2000 05:34:36 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 18 Dec 2000 05:34:36 -0000 Date: Mon, 18 Dec 2000 14:42:52 +0900 (JST) Message-Id: <20001218.144252.59672699.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: rfc2440bis-02 comments In-Reply-To: References: X-Mailer: Mew version 1.95b89 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Derek Atkins Subject: Re: rfc2440bis-02 comments Date: 17 Dec 2000 12:21:05 -0500 > Unfortunately this particular approach will not solve what I believe > to be the bigger problem: "I reinstalled my machine and lost my secret > key; can you remove it from the keyserver, please?" or "I forgot my > passphrase, can you please delete my key from the keyservers?" If I > had a dollar for every time I received one of these messages, I'd be a > very rich man right now ;) is it possible to address this issue w/o the keyservers doing any sort of authentication? i had thought that there was a fairly strong feeling that the keyservers should not do any sort of authentication. has this changed? one authentication-less way that occurred to me is to have keys have life times on servers (default being 1 year perhaps?). then, though you might have to wait a while, at least your old keys could disappear from servers after a certain period of time. your client software can remind you that you need to upload your key when it gets close to the "expiration" date/time. [ of course the "expire-from-server" date needs to be in the hashed area. ] From owner-ietf-openpgp@mail.imc.org Mon Dec 18 09:23:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08948 for ; Mon, 18 Dec 2000 09:23:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23531 for ietf-openpgp-bks; Mon, 18 Dec 2000 05:59:48 -0800 (PST) Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23527 for ; Mon, 18 Dec 2000 05:59:46 -0800 (PST) Received: from [204.179.136.48] (204.179.136.33) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2); Mon, 18 Dec 2000 06:02:47 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <20001218.144252.59672699.sen_ml@eccosys.com> References: <20001218.144252.59672699.sen_ml@eccosys.com> Date: Mon, 18 Dec 2000 05:54:56 -0800 To: sen_ml@eccosys.com From: Dave Del Torto Subject: Re: rfc2440bis-02 comments Cc: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org 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 2:42 pm +0900 2000-12-18, sen_ml@eccosys.com wrote: >one authentication-less way that occurred to me is to have keys have >life times on servers (default being 1 year perhaps?). then, though >you might have to wait a while, at least your old keys could disappear >from servers after a certain period of time. I agree that the default should be one year. I've been calling for this for a very long time, and I'm definitely not alone. There are so many confused users out there on these key management points: I'm beginning to wonder if the development community is really paying attention to usability issues. PGP 7's Key Reconstruction is a very nice idea, but I've tried to get some newbies to use it and their reaction to being confronted by a dialog asking them to come up with five questions in case they forgot their passphrase was "are you kidding me?!" Also consider the idea of keyservers employing "flushing routines" for potentially "dead" keys. In one possible scenario, a key has languished on a server (e.g. hasn't been accessed for n ticks) for two years, has no expiration and is about to disappear as described above. The keyserver could email it to all of the email addresses on the key (this would encourage people to keep their userids current, yet another extremely common key hygiene problem). If the key wasn't updated by anyone within another time period (set by the admin), the key would be dropped. Storing your key on a public keyserver is a privilege, not a right. If you can't do the most basic things to maintain it, you're not doing anyone any good, least of all yourself if you want people to use it. >your client software can remind you that you need to upload your key >when it gets close to the "expiration" date/time. It would make sense if *all* OpenPGP-compliant implementations had some basic HCI features like this: a warning when one's key is about to expire seems extremely obvious -- or even when signatures made by one's key on others' keys (stored on one's local keyring) are about to expire. Jon, perhaps expiration packets can be mentioned in 2440bis as being potential triggers for this mechanism. Implementors could also be encouraged to consider providing expiration warning mechanisms. dave From owner-ietf-openpgp@mail.imc.org Tue Dec 19 18:13:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27291 for ; Tue, 19 Dec 2000 18:13:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA06498 for ietf-openpgp-bks; Tue, 19 Dec 2000 14:50:17 -0800 (PST) Received: from LindaleUSA.com (pppoe0338.lr.centurytel.net [64.91.13.212]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA06489 for ; Tue, 19 Dec 2000 14:50:14 -0800 (PST) Date: Tue, 19 Dec 2000 14:50:14 -0800 (PST) From: Linda&Dale@LindaleUSA.com Message-Id: <200012192250.OAA06489@ns.secondary.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=200012191751=" To: ietf-openpgp@imc.org X-Mailer: DD3C1F9.76B4BC64.62d9d2633ce1b9717adc2cd54a8fe321 Subject: FREE Catalog Organization: Lindale USA Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=200012191751= Content-Type: text/plain;charset=US-ASCII Happy Holidays from Linda and Dale! YOU have been selected to receive a FREE "Showcase" catalog! As our Holiday gift to you, we will send you our BEAUTIFUL full-color "Showcase" catalog just for the asking! All you have to do is click here... http://www.wholesalespecialties.com/showcasecatalogorder.htm It's jam-packed with our best high-quality gift merchandise that is PERFECT for every gift occasion. We even have a way for you to make money while you shop for gifts! Please click here to order your FREE "Showcase" catalog... http://www.wholesalespecialties.com/showcasecatalogorder.htm and click here to visit our online gift shop... http://www.wholesalespecialties.com Thanks again and have a WONDREFUL hoilday season! Linda and Dale Lindale USA Your email address was submitted to us by a visitor to our web site. They want to let you know about our fabulous offer so that you can have your own FREE catalog too. If your email address has been given to us by mistake or if you have received this email offer by mistake, please click here to be automatically removed from our list... remove@wholesalespecialties.com --=200012191751=-- From owner-ietf-openpgp@mail.imc.org Tue Dec 19 23:21:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03918 for ; Tue, 19 Dec 2000 23:21:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12307 for ietf-openpgp-bks; Tue, 19 Dec 2000 19:59:27 -0800 (PST) Received: from merchantsystems.com (pppoe0118.lr.centurytel.net [209.206.192.55]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA12299 for ; Tue, 19 Dec 2000 19:59:25 -0800 (PST) Date: Tue, 19 Dec 2000 19:59:25 -0800 (PST) From: carlgroh@merchantsystems.com Message-Id: <200012200359.TAA12299@ns.secondary.com> To: ietf-openpgp@imc.org X-Mailer: 5F5DEEF.6F9931C8.5b2805d9e793625394b4e5f0e7705308 Subject: Don't Get Ripped Off! Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm sure... If my competitors get a hold of this letter, I might as well move out of the country! Let me explain. I'm in the business of setting people up to do business on the Internet. As you probably know, there's only a few things that you actually need to accomplish this.... 1. Something to sell 2. A working website 3. Traffic to the website 4. A way for people to pay you over the net. Here's my point. While my competitors are charging anywhere from $695 to a few thousand to get people set up to do business on the net, my company does it all for -- a one time -- complete price of $195! Maybe that's the reason we currently have over 180,000 clients using our services. (We list a large number of them on our website). The $195 includes everything... Your own Domain (website), Free website hosting unlimited email accounts, autoresponders, shopping cart system, online credit card acceptace (processing) system, Internet merchant account, Free software that creates your website, Free instructions on getting traffic to your website, and many other Free tools to neumerous to list in a short email message. Anyway, If you've been thinking about selling online, but thought it was too expensive or complicated or too confusing, you've been paying to much attention to my competitors. If you're interested and want to find out more, It's very simple to do. Simply call my office -- toll free -- 888-269-7960 and I'll be glad to explain everything to you in detail. Just be aware, that I might be on the phone helping someone else out. So kindly leave a message and I'll get right back to you. If you're not interested, just delete this message. You'll never hear from me again. I guarantee it! Merchant Systems From owner-ietf-openpgp@mail.imc.org Thu Dec 21 07:06:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15396 for ; Thu, 21 Dec 2000 07:06:35 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA17810 for ietf-openpgp-bks; Thu, 21 Dec 2000 03:47:00 -0800 (PST) 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 DAA17805 for ; Thu, 21 Dec 2000 03:46:59 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA26898; Thu, 21 Dec 2000 11:50:16 GMT Message-ID: Date: Thu, 21 Dec 2000 11:47:39 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: Dash-escaping and the Usenet sig convention References: <20001212135300.N21969@gnupg.de> 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 Tue, 12 Dec 2000, Ian Bell wrote: >On Tue, 12 Dec 2000, Werner Koch wrote: >We have been asked to munge the dash-stuffed clear text as in practice >the use of PGP/MIME signed messages causes more complaints than clear- >signed messages, but clear-signing messages causes complaints about >broken sig-seps :-( >>It is a matter of the MUA to handle this right. Mutt for example >>does remove the dash escaping even when it does not verify the >>signature. MUAs in general won't handle this right because for the most part MUAs are PGP-unaware. The interoperability problem here is between PGP-aware MUAs and PGP-unaware MUAs . Clear-signed messages are more acceptable to PGP-unaware MUAs if the sig-sep is not hyphen-stuffed, and hence clear- signing will be more acceptable in newsgroups and mailing-lists. In order to increase the acceptability of PGP signed messages in general, could 7.1 in 2440bis be amended as follows? 7.1. Dash-Escaped Text The cleartext content of the message must also be dash-escaped. Dash escaped cleartext is the ordinary cleartext where every line starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and space ' ' (0x20). This prevents the parser from recognizing armor headers of the cleartext itself. The message digest is computed using the cleartext itself, not the dash escaped form. * Note: dash-escaping can cause interoperability problems between PGP- * aware clients and PGP-unaware clients because some commonly used * separator conventions use lines starting with multiple dashes. To * improve interoperability in these cases, clients MAY omit the dash- * escaping for lines that cannot be armor headers and that are not * already dash-escaped. Lines beginning with dash-space (0x2D, 0x20), * or with five dashes MUST be dash-escaped. As with binary signatures on text documents, a cleartext signature is calculated on the text using canonical line endings. The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. -- Ian Bell T U R N P I K E From owner-ietf-openpgp@mail.imc.org Thu Dec 21 08:09:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17251 for ; Thu, 21 Dec 2000 08:09:15 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA21233 for ietf-openpgp-bks; Thu, 21 Dec 2000 04:49:55 -0800 (PST) Received: from mail.hsp.de (mail.hsp.de [194.77.127.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA21216 for ; Thu, 21 Dec 2000 04:49:51 -0800 (PST) Received: from kasiski.gnupg.de (werner-gw.openit.de [194.231.77.111]) by mail.hsp.de (8.11.1/8.11.1) with ESMTP id eBLCrBJ25601 for ; Thu, 21 Dec 2000 13:53:11 +0100 Received: from wk by kasiski.gnupg.de with local (Exim 3.16 #1 (Debian)) id 14952a-000888-00; Thu, 21 Dec 2000 13:41:48 +0100 Date: Thu, 21 Dec 2000 13:41:48 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Dash-escaping and the Usenet sig convention Message-ID: <20001221134148.D29043@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20001212135300.N21969@gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ianbell@turnpike.com on Thu, Dec 21, 2000 at 11:47:39AM +0000 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.guug.de/~werner.koch/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 21 Dec 2000, Ian Bell wrote: > * separator conventions use lines starting with multiple dashes. To > * improve interoperability in these cases, clients MAY omit the dash- > * escaping for lines that cannot be armor headers and that are not > * already dash-escaped. Lines beginning with dash-space (0x2D, 0x20), I am not sure whether yoy are talking about an OpenPGP implementaion or an MUA. We can't do that in the OpenPGP protocol. The only thing we could do is to allow dash escaping in certain situations like we do it for '^From '. But it may break other applications and I don't know why it should make sense at all. Werner From owner-ietf-openpgp@mail.imc.org Thu Dec 21 10:00:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21306 for ; Thu, 21 Dec 2000 10:00:44 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA25904 for ietf-openpgp-bks; Thu, 21 Dec 2000 06:37:25 -0800 (PST) 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 GAA25900 for ; Thu, 21 Dec 2000 06:37:23 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id OAA19980; Thu, 21 Dec 2000 14:40:43 GMT Message-ID: Date: Thu, 21 Dec 2000 14:38:08 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: Dash-escaping and the Usenet sig convention References: <20001212135300.N21969@gnupg.de> <20001221134148.D29043@gnupg.de> In-Reply-To: <20001221134148.D29043@gnupg.de> 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 Thu, 21 Dec 2000, Werner Koch wrote: >On Thu, 21 Dec 2000, Ian Bell wrote: > >> * separator conventions use lines starting with multiple dashes. To >> * improve interoperability in these cases, clients MAY omit the dash- >> * escaping for lines that cannot be armor headers and that are not >> * already dash-escaped. Lines beginning with dash-space (0x2D, 0x20), > >I am not sure whether yoy are talking about an OpenPGP implementaion >or an MUA. We can't do that in the OpenPGP protocol. >The only thing we could do is to allow dash escaping in certain >situations like we do it for '^From '. But it may break other >applications and I don't know why it should make sense at all. It makes sense from a MUA perspective because it increases interoperability between MUAs in the real world. The problem can indeed be ignored by open PGP implementations when they create clear-signed text and can be dealt with by MUAs changing the dash-escaping before posting in the way we have been asked to do. However this pushes the problem on to the receiving openPGP implementation. It is the receiving openPGP implementation that has to parse the results of clear-signed messages with some dash-escaping removed. They can either cope, or treat the message as an invalid clear- signed message (as old versions of Turnpike used to do!). In the real world, some users are changing the dash-escaping by hand and they have found that PGP (NAI) copes well. I feel that there should be at least a note to reflect what is being done to the dash-escaping in order to make openPGP implementations robust when they encounter such messages and hopefully to encourage them to correctly verify signatures in such messages as PGP itself would do. -- Ian Bell T U R N P I K E From owner-ietf-openpgp@mail.imc.org Thu Dec 21 11: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 SMTP id LAA22953 for ; Thu, 21 Dec 2000 11:05:38 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA02268 for ietf-openpgp-bks; Thu, 21 Dec 2000 07:39:43 -0800 (PST) Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02256 for ; Thu, 21 Dec 2000 07:39:42 -0800 (PST) Received: from [205.211.160.30] ([205.211.160.30] EHLO MSH4906 ident: TIMEDOUT [port 16989]) by bureau6.utcc.utoronto.ca with ESMTP id <464413-15546>; Thu, 21 Dec 2000 10:42:48 -0500 Date: Thu, 21 Dec 2000 10:45:01 -0500 From: Robert Guerra To: ietf-openpgp@imc.org cc: Keyserver-Folk-Mailinglist Subject: [PGP-USERS] (mac) PGP 6.5.8 -> Request for patchfix comments.. (fwd) Message-ID: <2437924968.977395501@MSH4906> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ---------- Forwarded Message ---------- Date: Thursday, December 21, 2000 8:17 AM -0500 From: Robert Guerra To: pgp-users@cryptorights.org Subject: [PGP-USERS] (mac) PGP 6.5.8 -> Request for patchfix comments.. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there: A couple days back I detailed a persistant problem in which the first couple of lines of pgp cyphertext appears in the Header section of email. I've consulted with the developper of the the email client I use (eudora) and the email server I use (EIMS 3.02) and they both point fingers to it being a problem with the pgp-plugin on the mac end. As it's not a security hole, and since NAI won't issue a specific bug fix...it leaves it to me to see what to do.. Consequently I have dowloaded the (mac) PGP 658 source code from the www.pgpi.org site and quickly looked over the code. I currently don't have the time nor resources to recompiple the code..so i've included my suggested patches in an archive for peer review. http://www.cryptorights.org/pgp-users/resources/mac-pgpfix.sit.Hqx I'm hoping those more knowleable with the code will : 1. take a look at it 2. ok the changes and/or correct it further 3. post any comments and/or additional suggestions 4. re-compile the code for the community looking forward to everyone's comments regards robert -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v2.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBOkIC68KdCsHMpdeSEQJQtQCgh0jF7ejx9KPxfVTef/3jTNrffBkAoO/H 7rZ7jQ/OK2mEZw6lh7JH3Bfg =ogqN -----END PGP SIGNATURE----- .................................................................... Unsubscribe: Automated Help/Info: List Homepage: List Admin (human): Please do not send administrative commands to the list address! Thanks. ---------- End Forwarded Message ---------- From owner-ietf-openpgp@mail.imc.org Thu Dec 21 16:51:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02153 for ; Thu, 21 Dec 2000 16:51:32 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24932 for ietf-openpgp-bks; Thu, 21 Dec 2000 13:30:52 -0800 (PST) Received: from mp.a-phys.eng.osaka-cu.ac.jp ([160.193.160.180]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24919 for ; Thu, 21 Dec 2000 13:30:39 -0800 (PST) From: hj4hj6@yahoo.com Received: by mp.a-phys.eng.osaka-cu.ac.jp id AA31928; Fri, 22 Dec 2000 06:24:32 +0900 Date: 21 Dec 00 1:39:39 PM Message-Id: <1Oxd7w7SeQB2> Subject: Improve your stepfamily life Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does your stepfamily life resemble a soap opera more than it does the Brady Bunch? The Stepfamily Association of America invites you to participate in THE NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans Marriott Hotel. This is an opportunity, designed by knowledgeable professionals, in stepfamilies themselves, to help you: * Make your remarriage a success * Create bonds with your stepchildren * Help your children adjust emotionally * Manage money matters unique to your family * Get more help from legal, financial, psychological advisors * Overcome stepfather and stepmother stereotypes * Elicit cooperation from your children's schools * Bring more harmony into family life Complete conference details at http://www.edupr.com REGISTER ONLINE! Attend, and also enjoy Mardi Gras week in New Orleans! Special discounts for couples, students, groups. HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND AIRLINE SEATS FILL Special rates for conference attendees. Visit http://www.edupr.com for discounts. Childcare available through a bonded local service. Up to 17 professional development credits available if you are an educator, clinician, financial planner, social worker. Questions? Email stepfamilyconf@mail.com If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience. From owner-ietf-openpgp@mail.imc.org Wed Dec 27 00:13:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01737 for ; Wed, 27 Dec 2000 00:13:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19366 for ietf-openpgp-bks; Tue, 26 Dec 2000 20:31:03 -0800 (PST) Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19360 for ; Tue, 26 Dec 2000 20:31:00 -0800 (PST) Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id NAA25523; Wed, 27 Dec 2000 13:33:40 +0900 Message-Id: <200012270433.NAA25523@blue.h2np.net> From: Hironobu SUZUKI To: Marc Horowitz cc: Derek Atkins , "L. Sassaman" , Dave Del Torto , ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: rfc2440bis-02 comments In-reply-to: Your message of "26 Dec 2000 22:36:38 EST." Date: Wed, 27 Dec 2000 13:33:38 +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Marc. > - I don't want my key on the keyservers at all. > > Your proposal solves this problem, but in my experience, this almost > never happens. 2 years ago, I got a complain e-mail about adding public key by a third party. Then I thought multi-phase commit for keyserver. But my idea looks crypto-over-kill for our public keyserver. Step 1: User submit their public key to keyserver. Step 2: Keyserver save this public key in queue database. Step 3: keyserver returns "ticket (challenge random number)" which is encrypted by user's public key. Step 4: After User decrypt received "ticket", user sign "ticket" by their secret key and send "signed ticket" to keyserver. Step 5: Keyserver check "signed ticket" by user's queued public key. Ture -> move it to public-open database. False -> delete from queue database. Note: When keyserver use this scheme, Sync data must be signed or something against forge sync data. (Also adding MAC looks good). This solution is not simple and powerful CPU is required for keyserver. But I'm not sure that it is too much cost for keyserver. Please note that this is only idea and I don't recommend it. --hironobu From owner-ietf-openpgp@mail.imc.org Wed Dec 27 00:26:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01796 for ; Wed, 27 Dec 2000 00:26:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA18095 for ietf-openpgp-bks; Tue, 26 Dec 2000 19:33:04 -0800 (PST) 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 TAA18091 for ; Tue, 26 Dec 2000 19:33:02 -0800 (PST) Received: (from marc@localhost) by horowitz.ne.mediaone.net (8.8.8/8.8.8) id WAA04228; Tue, 26 Dec 2000 22:36:39 -0500 (EST) X-Authentication-Warning: horowitz.ne.mediaone.net: marc set sender to marc@horowitz.ne.mediaone.net using -f From: Marc Horowitz To: Derek Atkins Cc: "L. Sassaman" , Dave Del Torto , , Subject: Re: rfc2440bis-02 comments References: Date: 26 Dec 2000 22:36:38 -0500 In-Reply-To: Derek Atkins's message of "17 Dec 2000 12:21:05 -0500" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.3 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: Len, exactly what problem is you proposal intended to solve? You said: One of the major complaints I hear about PGP key servers is the inability to delete keys once they are sent to the server. I'd like to request the addition of two new flags for subpacket 23: Why do these people want to delete their keys? - They lost the private key or forgot the passphrase. Like Derek, this is by far the most common reason I get email from people who want their keys deleted. Your proposal doesn't solve this problem, since they can't modify the key to change the keyserver preferences. - They don't want anybody to know they have a key. It doesn't solve this problem, either, as others have pointed out. - The key is compromised. In this case, they should revoke it. - I don't want my key on the keyservers at all. Your proposal solves this problem, but in my experience, this almost never happens. or is there another problem I've missed? Marc From owner-ietf-openpgp@mail.imc.org Wed Dec 27 01:40:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06578 for ; Wed, 27 Dec 2000 01:40:38 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19723 for ietf-openpgp-bks; Tue, 26 Dec 2000 20:59:14 -0800 (PST) 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 UAA19719 for ; Tue, 26 Dec 2000 20:59:11 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 19929 invoked from network); 27 Dec 2000 04:54:13 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 27 Dec 2000 04:54:13 -0000 Date: Wed, 27 Dec 2000 14:02:58 +0900 (JST) Message-Id: <20001227.140258.10297812.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Cc: hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-Reply-To: <200012270433.NAA25523@blue.h2np.net> References: <200012270433.NAA25523@blue.h2np.net> X-Mailer: Mew version 1.95b92 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit hello all, From: Hironobu SUZUKI Subject: Re: rfc2440bis-02 comments Date: Wed, 27 Dec 2000 13:33:38 +0900 > 2 years ago, I got a complain e-mail about adding public key by a > third party. Then I thought multi-phase commit for keyserver. But my > idea looks crypto-over-kill for our public keyserver. [ detailed description of pk-based challenge-response scheme snipped ] > This solution is not simple and powerful CPU is required for > keyserver. But I'm not sure that it is too much cost for keyserver. > > Please note that this is only idea and I don't recommend it. to add more hypothetical information to the situation... if keyservers are going to do authentication-like things (a big "if"), why not do the following: -before adding a key from the queue to a database, use an email confirmation system to solicit confirming email (don't need to use pk-based challenge-response for this) -- just use what many mailing list systems use. if confirmation is obtained, add the key to the database. -in order to remove a key from the database, use a challenge-response system like Hironobu described. -keys expire from servers by default. perhaps 6 months or 1 year. points to observe: -if deletions are relatively scarce events, you don't need much cpu power. keyservers can even decide to only service delete requests periodically in bulk. -in the case that the confirmation by email process is "spoofed" and a third party adds someone's key, the holder of the secret key can remove the key using the above method. i'm assuming the spoofing shouldn't be something that should continue to happen to a particular individual -- if it does, imo, that person has other problems that need to deal with first. -an "expire-from-server" time field (only allowed in the hashed area) could be defined in rfc 2440, support for this in keyservers and openpgp client implementations seems like one way to accomplish the expiration idea. -unused keys will be removed from servers over time. less garbage is collected and people who lose their secret keys can relax after a while. new users can be encouraged to choose short "expire-from-server" times. i think it's important to be able to update one's "expire-from-server" time -- i don't understand how key information on keyservers gets updated (which key information takes priority? always what gets submitted later in time? if so, may be something like a "timestamp" field is necessary in the hashed area so that a keyserver can decide which key info is more recent). -it's not required that keys have email address info associated w/ them. it's not clear to me whether one would bother w/ confirmation for these. thoughts? From owner-ietf-openpgp@mail.imc.org Wed Dec 27 01:42:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06788 for ; Wed, 27 Dec 2000 01:42:18 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA20471 for ietf-openpgp-bks; Tue, 26 Dec 2000 21:58:30 -0800 (PST) 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 VAA20467 for ; Tue, 26 Dec 2000 21:58:28 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 22556 invoked from network); 27 Dec 2000 05:53:31 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 27 Dec 2000 05:53:31 -0000 Date: Wed, 27 Dec 2000 15:02:15 +0900 (JST) Message-Id: <20001227.150215.99461534.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Cc: hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-Reply-To: <200012270541.OAA25585@blue.h2np.net> References: <20001227.140258.10297812.sen_ml@eccosys.com> <200012270541.OAA25585@blue.h2np.net> X-Mailer: Mew version 1.95b92 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Hironobu SUZUKI Subject: Re: rfc2440bis-02 comments Date: Wed, 27 Dec 2000 14:41:13 +0900 > Removing from keyserver is bad idea. After public key was issued, > there are two status for public keys which are "Valid" or "Not-Valid" > (removked). [ example snipped ] i don't think the example in question should dictate everyone's policy. if it really is the case that in step 1 alice distributes her public key to the world for verifying her signed text by everyone, that is her policy decision and she has to figure out a way to make that work -- assuming that the mechanisms exist, she can express that in her key info by setting an expire time significantly in the future and perhaps some other field that expresses the idea that she cannot go back on her word. other people may not want that kind of policy. i know i don't for every key i make. From owner-ietf-openpgp@mail.imc.org Wed Dec 27 02:21:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15070 for ; Wed, 27 Dec 2000 02:21:39 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA20194 for ietf-openpgp-bks; Tue, 26 Dec 2000 21:38:24 -0800 (PST) Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20189 for ; Tue, 26 Dec 2000 21:38:22 -0800 (PST) Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id OAA25585; Wed, 27 Dec 2000 14:41:16 +0900 Message-Id: <200012270541.OAA25585@blue.h2np.net> From: Hironobu SUZUKI To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org, hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-reply-to: Your message of "Wed, 27 Dec 2000 14:02:58 +0900." <20001227.140258.10297812.sen_ml@eccosys.com> Date: Wed, 27 Dec 2000 14:41:13 +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -keys expire from servers by default. perhaps 6 months or 1 year. Removing from keyserver is bad idea. After public key was issued, there are two status for public keys which are "Valid" or "Not-Valid" (removked). Alice, Bob and Olive story. Step 1: Alice distribute her public key to the world for verifying her signed text by everyone. Step 2: Alice sign text and distribute signed text to the world. Step 3: Bob get Alice's public key and verify Alice's signed text. Bob is certain that this text was written by Alice. Step 4: Alice remove her public key from all of the world. Step 5: Olive get Alice's signed text. But she can't get Alice's public key and can't verify Alice's signed text. Olive is not certain that this text was written by Alice. Step 6: Bob says "this is Alice's text", Olive says "I'm not sure this is Alice's text". This is a kind of chaos. --hironobu From owner-ietf-openpgp@mail.imc.org Wed Dec 27 03:33:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA15388 for ; Wed, 27 Dec 2000 03:33:54 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21272 for ietf-openpgp-bks; Tue, 26 Dec 2000 22:47:57 -0800 (PST) Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA21267 for ; Tue, 26 Dec 2000 22:47:55 -0800 (PST) Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id PAA25681; Wed, 27 Dec 2000 15:50:47 +0900 Message-Id: <200012270650.PAA25681@blue.h2np.net> From: Hironobu SUZUKI To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org, hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-reply-to: Your message of "Wed, 27 Dec 2000 15:02:15 +0900." <20001227.150215.99461534.sen_ml@eccosys.com> Date: Wed, 27 Dec 2000 15:50:44 +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > i don't think the example in question should dictate everyone's > policy. Alice, Bob and Olive story may be vulnerability of public key distribution and verification, is not sort of policy. If you mention about privacy, I mean hiding personal information, PGP's (simple) digital signature scheme is not enough to solve it. You might need blind signature, undeniable signature, non-transitive or other digital signature scheme. --hironobu From owner-ietf-openpgp@mail.imc.org Wed Dec 27 21:50:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28661 for ; Wed, 27 Dec 2000 21:50:23 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12178 for ietf-openpgp-bks; Wed, 27 Dec 2000 18:18:07 -0800 (PST) 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 SAA12173 for ; Wed, 27 Dec 2000 18:18:05 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 6032 invoked from network); 28 Dec 2000 02:13:09 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 28 Dec 2000 02:13:09 -0000 Date: Thu, 28 Dec 2000 11:21:56 +0900 (JST) Message-Id: <20001228.112156.59477997.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Cc: hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-Reply-To: <200012270650.PAA25681@blue.h2np.net> References: <20001227.150215.99461534.sen_ml@eccosys.com> <200012270650.PAA25681@blue.h2np.net> X-Mailer: Mew version 1.95b92 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Hironobu SUZUKI Subject: Re: rfc2440bis-02 comments Date: Wed, 27 Dec 2000 15:50:44 +0900 ... > > i don't think the example in question should dictate everyone's > > policy. > > Alice, Bob and Olive story may be vulnerability of public key > distribution and verification, is not sort of policy. i'm sorry, but i wasn't able to understand what you meant. my guess is that you are saying that addressing the example scenario you gave is a design goal of public key distribution and verification. is that what you meant? if not, please elaborate. i don't think the current keyserver structure alone addresses the scenario you gave. you also need to establish that a particular key belongs to a particular entity -- this is not possible using only the keyservers -- you need to perform at least one key fingerprint verification and depending on the situation, you may also need a trail of appropriate signatures to the entity's key. in your example scenario: in step 3, bob is not certain that the text was written by alice until he verifies that the key is hers. he can do that via contacting alice, or if an appropriate chain of signatures exist, he can do it via that method (it depends on his policy). once bob has verified the relationship between alice and the key he downloaded, then he can be certain (actually he can be certain w/o this, but he will be foolish for being certain ;-) ) in step 5, it is true that olive can't verify alice's text because she doesn't have alice's public key. but having a key from the keyserver that might be alice's key is not enough. olive must also establish that the key is alice's. so to summarize, verifying signed text is going to require verifying entity-key associations. that's going to require communication between entities. imo, this communication should clear up difficulties in most cases. i think there will be pathological cases where verification of signatures will not be possible. in fact, the current situation does provide examples of such situations -- for example, there are already keys on the keyservers for which no one can establish relationships to owning entities: any key that no one has done a fingerprint verification for and the secret key material is lost if there is some text signed w/ such a key floating out there, no one will be able to verify the signature. even if one person has performed a key fingerprint verification for the key, if no one else trusts this person as a verifying entity, no one else will be able to verify the signature. imo, those kinds of pathelogical situations need to manage their risks using additional means. From owner-ietf-openpgp@mail.imc.org Thu Dec 28 00:05:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA00796 for ; Thu, 28 Dec 2000 00:05:31 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA14539 for ietf-openpgp-bks; Wed, 27 Dec 2000 20:21:10 -0800 (PST) Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14535 for ; Wed, 27 Dec 2000 20:21:08 -0800 (PST) Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id NAA26704; Thu, 28 Dec 2000 13:24:07 +0900 Message-Id: <200012280424.NAA26704@blue.h2np.net> From: Hironobu SUZUKI To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: rfc2440bis-02 comments In-reply-to: Your message of "Thu, 28 Dec 2000 11:21:56 +0900." <20001228.112156.59477997.sen_ml@eccosys.com> Date: Thu, 28 Dec 2000 13:24:02 +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > my guess is that you are saying that addressing the example scenario > you gave is a design goal of public key distribution and verification. I meant that PGP's conventional (simple, oldstyle, or whatever :-) digital signature can use in very simple digital signature scheme. My scenario will be applied to not only PGP but also almost current digital signature tools. I guess that you want more sophisticated digital signature scheme than current PGP digital signature scheme. > but having a key from the keyserver that might be alice's > key is not enough. olive must also establish that the key is alice's. Web-of-trust, X.509, and some certification schemes give us the capability of public key trustness without contacting public-key owner. --hironobu From owner-ietf-openpgp@mail.imc.org Thu Dec 28 04:40:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA14609 for ; Thu, 28 Dec 2000 04:40:01 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA08356 for ietf-openpgp-bks; Thu, 28 Dec 2000 00:49:34 -0800 (PST) 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 AAA08341 for ; Thu, 28 Dec 2000 00:49:29 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 12688 invoked from network); 28 Dec 2000 08:44:33 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 28 Dec 2000 08:44:33 -0000 Date: Thu, 28 Dec 2000 17:53:15 +0900 (JST) Message-Id: <20001228.175315.74726442.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Cc: hironobu@h2np.net Subject: Re: rfc2440bis-02 comments In-Reply-To: <200012280424.NAA26704@blue.h2np.net> References: <20001228.112156.59477997.sen_ml@eccosys.com> <200012280424.NAA26704@blue.h2np.net> X-Mailer: Mew version 1.95b93 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit i am about to give up...i think we're going off-topic. perhaps we should continue this off-list. the points i wish to make are: -expiring keys from keyservers is not necessarily a bad idea -- at least your example does not convince me that we would be significantly worse off than the current situation. i like Dave Del Torto's statement: Storing your key on a public keyserver is a privilege, not a right. If you can't do the most basic things to maintain it, you're not doing anyone any good, least of all yourself if you want people to use it. -out-of-band channels for verification are necessary for using these kinds of systems well -- keyservers can help reduce the total amount of out-of-band verification, but it is not a substitute on its own. (both web-of-trust and x.509 require at least some out-of-band verification at some point) From owner-ietf-openpgp@mail.imc.org Thu Dec 28 21:10:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21296 for ; Thu, 28 Dec 2000 21:10:30 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA08915 for ietf-openpgp-bks; Thu, 28 Dec 2000 17:30:55 -0800 (PST) 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 RAA08911 for ; Thu, 28 Dec 2000 17:30:52 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 20851 invoked from network); 29 Dec 2000 01:25:59 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 29 Dec 2000 01:25:59 -0000 Date: Fri, 29 Dec 2000 10:34:49 +0900 (JST) Message-Id: <20001229.103449.74734016.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: rfc2440bis-02 comments In-Reply-To: References: X-Mailer: Mew version 1.95b93 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Marc Horowitz Subject: Re: rfc2440bis-02 comments Date: 26 Dec 2000 22:36:38 -0500 > Why do these people want to delete their keys? [ text of various reasons deleted ] > - I don't want my key on the keyservers at all. for reference, below is part of an edited recent post from the gnupg-users@gnupg.org mailing list of someone who doesn't want their key on a keyserver at all. perhaps a survey announced on the various user-oriented pgp lists would be useful for collecting feedback on the issue of deleting keys from keyservers? Subject: Re: Deleting Keys on Keyservers From: Lazarus Long [address deleted] To: GnuPG Users List Date: Thu, 28 Dec 2000 15:50:23 +0000 On Wed, Dec 27, 2000 at 09:49:55PM +0100, Martin wrote: > From: Martin [address deleted] > im just curious. Is there a way to delete a key from a keyserver? Nope. Once your key is there, you are hanging out there in the wind for spambots to come harvest for all eternity. From owner-ietf-openpgp@mail.imc.org Thu Dec 28 22:01:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22484 for ; Thu, 28 Dec 2000 22:01:59 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA10329 for ietf-openpgp-bks; Thu, 28 Dec 2000 18:29:24 -0800 (PST) Received: from srh1157.urh.uiuc.edu (qmailr@srh1157.urh.uiuc.edu [130.126.76.179]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA10323 for ; Thu, 28 Dec 2000 18:29:22 -0800 (PST) Received: (qmail 3755 invoked by uid 1000); 29 Dec 2000 02:33:22 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Dec 2000 02:33:22 -0000 Date: Thu, 28 Dec 2000 20:33:12 -0600 (CST) From: Frank Tobin X-X-Sender: To: cc: Subject: Re: rfc2440bis-02 comments In-Reply-To: <20001229.103449.74734016.sen_ml@eccosys.com> 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 sen_ml@eccosys.com, at 10:34 +0900 on Fri, 29 Dec 2000, wrote: perhaps a survey announced on the various user-oriented pgp lists would be useful for collecting feedback on the issue of deleting keys from keyservers? Of course, in the future, people's needs are going to change. They're going to want new policies about how keyservers (and other entities) handle their keys, and have other metadata associated with them. To try to "guess" what people are going to really need or want two years from now is a reach at best. If there is no attempt to use an extensible format that accounts for the many different key-handling policies and metadata that different people/entities are going to want to use, evil, bad hacks are going to start occuring eventually. One of the problems, I feel, is that we're trying to jam too much into the few bits available in the OpenPGP spec. Simple boolean's just don't cut it. This is me dreaming here, but what'd really be good is to have the metadata for keys separated out from the OpenPGP spec, and handled by another, extensible mechanism, quite possibly/preferably XML. This could allow the metadata to be extended via namespaces by however one wishes. There is no tie-down by specification mandating what policies can be accomodated. OpenPGP need not know about this extensible spec, since it's pretty much finalized, but clients could adapt, and handle the specs in pair. In the end, I forsee troubles for OpenPGP if we try to quantify what policies OpenPGP keys should be capable of holding metadata about. - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjpL9/EACgkQVv/RCiYMT6OxqwCeOR74gDWVe8f3o1F5+2yAw6C4 u7MAn2yQkgOB/ILH5flzoJzAPWLeWJIG =IwEa -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sat Dec 30 16:36:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03337 for ; Sat, 30 Dec 2000 16:36:20 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15819 for ietf-openpgp-bks; Sat, 30 Dec 2000 12:56:35 -0800 (PST) Received: from limbo.net (IDENT:root@meridian.limbo.net [209.209.9.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15815 for ; Sat, 30 Dec 2000 12:56:33 -0800 (PST) Received: from opcenter2.tillerman.to (IDENT:root@module-two.rwthayer.com [216.240.42.201] (may be forged)) by limbo.net (8.9.3/8.9.0) with ESMTP id NAA00191 for ; Sat, 30 Dec 2000 13:00:37 -0800 Message-Id: <5.0.0.25.2.20001230124922.034d9590@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 30 Dec 2000 12:57:30 -0800 To: ietf-openpgp@imc.org From: Rodney Thayer Subject: Fwd: Re: rfc2440bis-02 comments Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 this sounds way too vague. how are the other implementors with this? >On Fri, 8 Dec 2000, Marc Horowitz wrote: > > > 3. Subpacket 23 (key server preferences) is specified to be "found > > only on a self-signature". It should say if that means a direct > > key signature (which makes the most sense to me), or something > >As with many other subpackets there is no clear definition on what >to do and it is left to the implementor to decide this. From my >understanding it does make sense to handle such things this way: > > * If it is on any direct key signature, use this one (or exactly > the one on the latest direct key signure. > > * Otherwise take it from the latest self-signature. > >(I have worked out some more rules and checked them with Hal. >Currently I can't access them - please ask me next week, if you are >interested) "I have worked out some more rules" implies he had to work out rules, which implies the text merits changing. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOk5MOj/0TyQ4fTjtEQJCIACg9woWniJ40MN/O/Mj62SbFB9441gAoOQv 5hggU5GTTu2hFpZhJ8XFqVC7 =RjWr -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sat Dec 30 16:36:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03349 for ; Sat, 30 Dec 2000 16:36:57 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA14773 for ietf-openpgp-bks; Sat, 30 Dec 2000 12:43:58 -0800 (PST) Received: from limbo.net (IDENT:root@meridian.limbo.net [209.209.9.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14768 for ; Sat, 30 Dec 2000 12:43:56 -0800 (PST) Received: from opcenter2.tillerman.to (IDENT:root@module-two.rwthayer.com [216.240.42.201] (may be forged)) by limbo.net (8.9.3/8.9.0) with ESMTP id MAA00005 for ; Sat, 30 Dec 2000 12:48:00 -0800 Message-Id: <5.0.0.25.2.20001230123707.0325eeb0@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 30 Dec 2000 12:42:33 -0800 To: ietf-openpgp@imc.org From: Rodney Thayer Subject: Re: Dash-escaping and the Usenet sig convention In-Reply-To: References: <20001212135300.N21969@gnupg.de> <20001212135300.N21969@gnupg.de> Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with Jon on this. Insisting that the world suddenly change to MIME is not helping the adoption of PGP, in fact, it makes it harder as people tend to delete these nasty MIME messages. It's even worse with windows, as the (almost unreadable) "...ems" message looks annoyingly similar to a (usually unreadable) SMIME message. I too tend to delete these messages, as they are functionally equivalent to spam. I think we should be be building systems that INCREASE the usage of this technology, not decrease it. I agree it's the MUA's job to handle this civilly, but until that happens, the cleartext solution is much more likely to be usable in the real world. At 08:06 AM 12/12/00 -0800, Jon Callas wrote: >In our last episode ("Re: Dash-escaping and the Usenet sig convention", >shown on 12/12/00), Werner Koch said: > > >The preferred way to encapsulate OpenPGP messages in mail is by using > >MIME as defined in RFC2015. No need for the old fashioned cleartext > >signing. > > > >I disagree completely. The correct way to encapsulate messages is with >cleartext. I often delete PGP-MIME messages without reading them because >it's such a pain to deal with them. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOk5IuT/0TyQ4fTjtEQKxrACg0NXaax51BPsNvs0MzVtMoohZkN8An1VH mqFabgyxS7EQVa94GLk8jZhC =EH/s -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15819 for ietf-openpgp-bks; Sat, 30 Dec 2000 12:56:35 -0800 (PST) Received: from limbo.net (IDENT:root@meridian.limbo.net [209.209.9.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA15815 for ; Sat, 30 Dec 2000 12:56:33 -0800 (PST) Received: from opcenter2.tillerman.to (IDENT:root@module-two.rwthayer.com [216.240.42.201] (may be forged)) by limbo.net (8.9.3/8.9.0) with ESMTP id NAA00191 for ; Sat, 30 Dec 2000 13:00:37 -0800 Message-Id: <5.0.0.25.2.20001230124922.034d9590@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 30 Dec 2000 12:57:30 -0800 To: ietf-openpgp@imc.org From: Rodney Thayer Subject: Fwd: Re: rfc2440bis-02 comments Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 this sounds way too vague. how are the other implementors with this? >On Fri, 8 Dec 2000, Marc Horowitz wrote: > > > 3. Subpacket 23 (key server preferences) is specified to be "found > > only on a self-signature". It should say if that means a direct > > key signature (which makes the most sense to me), or something > >As with many other subpackets there is no clear definition on what >to do and it is left to the implementor to decide this. From my >understanding it does make sense to handle such things this way: > > * If it is on any direct key signature, use this one (or exactly > the one on the latest direct key signure. > > * Otherwise take it from the latest self-signature. > >(I have worked out some more rules and checked them with Hal. >Currently I can't access them - please ask me next week, if you are >interested) "I have worked out some more rules" implies he had to work out rules, which implies the text merits changing. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOk5MOj/0TyQ4fTjtEQJCIACg9woWniJ40MN/O/Mj62SbFB9441gAoOQv 5hggU5GTTu2hFpZhJ8XFqVC7 =RjWr -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id MAA14773 for ietf-openpgp-bks; Sat, 30 Dec 2000 12:43:58 -0800 (PST) Received: from limbo.net (IDENT:root@meridian.limbo.net [209.209.9.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA14768 for ; Sat, 30 Dec 2000 12:43:56 -0800 (PST) Received: from opcenter2.tillerman.to (IDENT:root@module-two.rwthayer.com [216.240.42.201] (may be forged)) by limbo.net (8.9.3/8.9.0) with ESMTP id MAA00005 for ; Sat, 30 Dec 2000 12:48:00 -0800 Message-Id: <5.0.0.25.2.20001230123707.0325eeb0@127.0.0.1> X-Sender: rodney@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Sat, 30 Dec 2000 12:42:33 -0800 To: ietf-openpgp@imc.org From: Rodney Thayer Subject: Re: Dash-escaping and the Usenet sig convention In-Reply-To: References: <20001212135300.N21969@gnupg.de> <20001212135300.N21969@gnupg.de> Mime-Version: 1.0 Content-Type: text/plain Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree with Jon on this. Insisting that the world suddenly change to MIME is not helping the adoption of PGP, in fact, it makes it harder as people tend to delete these nasty MIME messages. It's even worse with windows, as the (almost unreadable) "...ems" message looks annoyingly similar to a (usually unreadable) SMIME message. I too tend to delete these messages, as they are functionally equivalent to spam. I think we should be be building systems that INCREASE the usage of this technology, not decrease it. I agree it's the MUA's job to handle this civilly, but until that happens, the cleartext solution is much more likely to be usable in the real world. At 08:06 AM 12/12/00 -0800, Jon Callas wrote: >In our last episode ("Re: Dash-escaping and the Usenet sig convention", >shown on 12/12/00), Werner Koch said: > > >The preferred way to encapsulate OpenPGP messages in mail is by using > >MIME as defined in RFC2015. No need for the old fashioned cleartext > >signing. > > > >I disagree completely. The correct way to encapsulate messages is with >cleartext. I often delete PGP-MIME messages without reading them because >it's such a pain to deal with them. -----BEGIN PGP SIGNATURE----- Version: PGP 7.0 iQA/AwUBOk5IuT/0TyQ4fTjtEQKxrACg0NXaax51BPsNvs0MzVtMoohZkN8An1VH mqFabgyxS7EQVa94GLk8jZhC =EH/s -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id SAA10329 for ietf-openpgp-bks; Thu, 28 Dec 2000 18:29:24 -0800 (PST) Received: from srh1157.urh.uiuc.edu (qmailr@srh1157.urh.uiuc.edu [130.126.76.179]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA10323 for ; Thu, 28 Dec 2000 18:29:22 -0800 (PST) Received: (qmail 3755 invoked by uid 1000); 29 Dec 2000 02:33:22 -0000 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 29 Dec 2000 02:33:22 -0000 Date: Thu, 28 Dec 2000 20:33:12 -0600 (CST) From: Frank Tobin X-X-Sender: To: cc: Subject: Re: rfc2440bis-02 comments In-Reply-To: <20001229.103449.74734016.sen_ml@eccosys.com> 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 sen_ml@eccosys.com, at 10:34 +0900 on Fri, 29 Dec 2000, wrote: perhaps a survey announced on the various user-oriented pgp lists would be useful for collecting feedback on the issue of deleting keys from keyservers? Of course, in the future, people's needs are going to change. They're going to want new policies about how keyservers (and other entities) handle their keys, and have other metadata associated with them. To try to "guess" what people are going to really need or want two years from now is a reach at best. If there is no attempt to use an extensible format that accounts for the many different key-handling policies and metadata that different people/entities are going to want to use, evil, bad hacks are going to start occuring eventually. One of the problems, I feel, is that we're trying to jam too much into the few bits available in the OpenPGP spec. Simple boolean's just don't cut it. This is me dreaming here, but what'd really be good is to have the metadata for keys separated out from the OpenPGP spec, and handled by another, extensible mechanism, quite possibly/preferably XML. This could allow the metadata to be extended via namespaces by however one wishes. There is no tie-down by specification mandating what policies can be accomodated. OpenPGP need not know about this extensible spec, since it's pretty much finalized, but clients could adapt, and handle the specs in pair. In the end, I forsee troubles for OpenPGP if we try to quantify what policies OpenPGP keys should be capable of holding metadata about. - -- Frank Tobin http://www.uiuc.edu/~ftobin/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (FreeBSD) Comment: pgpenvelope 2.9.0 - http://pgpenvelope.sourceforge.net/ iEYEARECAAYFAjpL9/EACgkQVv/RCiYMT6OxqwCeOR74gDWVe8f3o1F5+2yAw6C4 u7MAn2yQkgOB/ILH5flzoJzAPWLeWJIG =IwEa -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id RAA08915 for ietf-openpgp-bks; Thu, 28 Dec 2000 17:30:55 -0800 (PST) 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 RAA08911 for ; Thu, 28 Dec 2000 17:30:52 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 20851 invoked from network); 29 Dec 2000 01:25:59 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 29 Dec 2000 01:25:59 -0000 Date: Fri, 29 Dec 2000 10:34:49 +0900 (JST) Message-Id: <20001229.103449.74734016.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: rfc2440bis-02 comments In-Reply-To: References: X-Mailer: Mew version 1.95b93 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Marc Horowitz Subject: Re: rfc2440bis-02 comments Date: 26 Dec 2000 22:36:38 -0500 > Why do these people want to delete their keys? [ text of various reasons deleted ] > - I don't want my key on the keyservers at all. for reference, below is part of an edited recent post from the gnupg-users@gnupg.org mailing list of someone who doesn't want their key on a keyserver at all. perhaps a survey announced on the various user-oriented pgp lists would be useful for collecting feedback on the issue of deleting keys from keyservers? Subject: Re: Deleting Keys on Keyservers From: Lazarus Long [address deleted] To: GnuPG Users List Date: Thu, 28 Dec 2000 15:50:23 +0000 On Wed, Dec 27, 2000 at 09:49:55PM +0100, Martin wrote: > From: Martin [address deleted] > im just curious. Is there a way to delete a key from a keyserver? Nope. Once your key is there, you are hanging out there in the wind for spambots to come harvest for all eternity. Received: by ns.secondary.com (8.9.3/8.9.3) id AAA08356 for ietf-openpgp-bks; Thu, 28 Dec 2000 00:49:34 -0800 (PST) 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 AAA08341 for ; Thu, 28 Dec 2000 00:49:29 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 12688 invoked from network); 28 Dec 2000 08:44:33 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 28 Dec 2000 08:44:33 -0000 Date: Thu, 28 Dec 2000 17:53:15 +0900 (JST) Message-Id: <20001228.175315.74726442.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Cc: hironobu@h2np.net Subject: Re: rfc2440bis-02 comments In-Reply-To: <200012280424.NAA26704@blue.h2np.net> References: <20001228.112156.59477997.sen_ml@eccosys.com> <200012280424.NAA26704@blue.h2np.net> X-Mailer: Mew version 1.95b93 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: i am about to give up...i think we're going off-topic. perhaps we should continue this off-list. the points i wish to make are: -expiring keys from keyservers is not necessarily a bad idea -- at least your example does not convince me that we would be significantly worse off than the current situation. i like Dave Del Torto's statement: Storing your key on a public keyserver is a privilege, not a right. If you can't do the most basic things to maintain it, you're not doing anyone any good, least of all yourself if you want people to use it. -out-of-band channels for verification are necessary for using these kinds of systems well -- keyservers can help reduce the total amount of out-of-band verification, but it is not a substitute on its own. (both web-of-trust and x.509 require at least some out-of-band verification at some point) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA14539 for ietf-openpgp-bks; Wed, 27 Dec 2000 20:21:10 -0800 (PST) Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA14535 for ; Wed, 27 Dec 2000 20:21:08 -0800 (PST) Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id NAA26704; Thu, 28 Dec 2000 13:24:07 +0900 Message-Id: <200012280424.NAA26704@blue.h2np.net> From: Hironobu SUZUKI To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: rfc2440bis-02 comments In-reply-to: Your message of "Thu, 28 Dec 2000 11:21:56 +0900." <20001228.112156.59477997.sen_ml@eccosys.com> Date: Thu, 28 Dec 2000 13:24:02 +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > my guess is that you are saying that addressing the example scenario > you gave is a design goal of public key distribution and verification. I meant that PGP's conventional (simple, oldstyle, or whatever :-) digital signature can use in very simple digital signature scheme. My scenario will be applied to not only PGP but also almost current digital signature tools. I guess that you want more sophisticated digital signature scheme than current PGP digital signature scheme. > but having a key from the keyserver that might be alice's > key is not enough. olive must also establish that the key is alice's. Web-of-trust, X.509, and some certification schemes give us the capability of public key trustness without contacting public-key owner. --hironobu Received: by ns.secondary.com (8.9.3/8.9.3) id SAA12178 for ietf-openpgp-bks; Wed, 27 Dec 2000 18:18:07 -0800 (PST) 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 SAA12173 for ; Wed, 27 Dec 2000 18:18:05 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 6032 invoked from network); 28 Dec 2000 02:13:09 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 28 Dec 2000 02:13:09 -0000 Date: Thu, 28 Dec 2000 11:21:56 +0900 (JST) Message-Id: <20001228.112156.59477997.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Cc: hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-Reply-To: <200012270650.PAA25681@blue.h2np.net> References: <20001227.150215.99461534.sen_ml@eccosys.com> <200012270650.PAA25681@blue.h2np.net> X-Mailer: Mew version 1.95b92 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Hironobu SUZUKI Subject: Re: rfc2440bis-02 comments Date: Wed, 27 Dec 2000 15:50:44 +0900 ... > > i don't think the example in question should dictate everyone's > > policy. > > Alice, Bob and Olive story may be vulnerability of public key > distribution and verification, is not sort of policy. i'm sorry, but i wasn't able to understand what you meant. my guess is that you are saying that addressing the example scenario you gave is a design goal of public key distribution and verification. is that what you meant? if not, please elaborate. i don't think the current keyserver structure alone addresses the scenario you gave. you also need to establish that a particular key belongs to a particular entity -- this is not possible using only the keyservers -- you need to perform at least one key fingerprint verification and depending on the situation, you may also need a trail of appropriate signatures to the entity's key. in your example scenario: in step 3, bob is not certain that the text was written by alice until he verifies that the key is hers. he can do that via contacting alice, or if an appropriate chain of signatures exist, he can do it via that method (it depends on his policy). once bob has verified the relationship between alice and the key he downloaded, then he can be certain (actually he can be certain w/o this, but he will be foolish for being certain ;-) ) in step 5, it is true that olive can't verify alice's text because she doesn't have alice's public key. but having a key from the keyserver that might be alice's key is not enough. olive must also establish that the key is alice's. so to summarize, verifying signed text is going to require verifying entity-key associations. that's going to require communication between entities. imo, this communication should clear up difficulties in most cases. i think there will be pathological cases where verification of signatures will not be possible. in fact, the current situation does provide examples of such situations -- for example, there are already keys on the keyservers for which no one can establish relationships to owning entities: any key that no one has done a fingerprint verification for and the secret key material is lost if there is some text signed w/ such a key floating out there, no one will be able to verify the signature. even if one person has performed a key fingerprint verification for the key, if no one else trusts this person as a verifying entity, no one else will be able to verify the signature. imo, those kinds of pathelogical situations need to manage their risks using additional means. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21272 for ietf-openpgp-bks; Tue, 26 Dec 2000 22:47:57 -0800 (PST) Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA21267 for ; Tue, 26 Dec 2000 22:47:55 -0800 (PST) Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id PAA25681; Wed, 27 Dec 2000 15:50:47 +0900 Message-Id: <200012270650.PAA25681@blue.h2np.net> From: Hironobu SUZUKI To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org, hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-reply-to: Your message of "Wed, 27 Dec 2000 15:02:15 +0900." <20001227.150215.99461534.sen_ml@eccosys.com> Date: Wed, 27 Dec 2000 15:50:44 +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > i don't think the example in question should dictate everyone's > policy. Alice, Bob and Olive story may be vulnerability of public key distribution and verification, is not sort of policy. If you mention about privacy, I mean hiding personal information, PGP's (simple) digital signature scheme is not enough to solve it. You might need blind signature, undeniable signature, non-transitive or other digital signature scheme. --hironobu Received: by ns.secondary.com (8.9.3/8.9.3) id VAA20471 for ietf-openpgp-bks; Tue, 26 Dec 2000 21:58:30 -0800 (PST) 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 VAA20467 for ; Tue, 26 Dec 2000 21:58:28 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 22556 invoked from network); 27 Dec 2000 05:53:31 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 27 Dec 2000 05:53:31 -0000 Date: Wed, 27 Dec 2000 15:02:15 +0900 (JST) Message-Id: <20001227.150215.99461534.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Cc: hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-Reply-To: <200012270541.OAA25585@blue.h2np.net> References: <20001227.140258.10297812.sen_ml@eccosys.com> <200012270541.OAA25585@blue.h2np.net> X-Mailer: Mew version 1.95b92 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Hironobu SUZUKI Subject: Re: rfc2440bis-02 comments Date: Wed, 27 Dec 2000 14:41:13 +0900 > Removing from keyserver is bad idea. After public key was issued, > there are two status for public keys which are "Valid" or "Not-Valid" > (removked). [ example snipped ] i don't think the example in question should dictate everyone's policy. if it really is the case that in step 1 alice distributes her public key to the world for verifying her signed text by everyone, that is her policy decision and she has to figure out a way to make that work -- assuming that the mechanisms exist, she can express that in her key info by setting an expire time significantly in the future and perhaps some other field that expresses the idea that she cannot go back on her word. other people may not want that kind of policy. i know i don't for every key i make. Received: by ns.secondary.com (8.9.3/8.9.3) id VAA20194 for ietf-openpgp-bks; Tue, 26 Dec 2000 21:38:24 -0800 (PST) Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA20189 for ; Tue, 26 Dec 2000 21:38:22 -0800 (PST) Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id OAA25585; Wed, 27 Dec 2000 14:41:16 +0900 Message-Id: <200012270541.OAA25585@blue.h2np.net> From: Hironobu SUZUKI To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org, hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-reply-to: Your message of "Wed, 27 Dec 2000 14:02:58 +0900." <20001227.140258.10297812.sen_ml@eccosys.com> Date: Wed, 27 Dec 2000 14:41:13 +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > -keys expire from servers by default. perhaps 6 months or 1 year. Removing from keyserver is bad idea. After public key was issued, there are two status for public keys which are "Valid" or "Not-Valid" (removked). Alice, Bob and Olive story. Step 1: Alice distribute her public key to the world for verifying her signed text by everyone. Step 2: Alice sign text and distribute signed text to the world. Step 3: Bob get Alice's public key and verify Alice's signed text. Bob is certain that this text was written by Alice. Step 4: Alice remove her public key from all of the world. Step 5: Olive get Alice's signed text. But she can't get Alice's public key and can't verify Alice's signed text. Olive is not certain that this text was written by Alice. Step 6: Bob says "this is Alice's text", Olive says "I'm not sure this is Alice's text". This is a kind of chaos. --hironobu Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19723 for ietf-openpgp-bks; Tue, 26 Dec 2000 20:59:14 -0800 (PST) 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 UAA19719 for ; Tue, 26 Dec 2000 20:59:11 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 19929 invoked from network); 27 Dec 2000 04:54:13 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 27 Dec 2000 04:54:13 -0000 Date: Wed, 27 Dec 2000 14:02:58 +0900 (JST) Message-Id: <20001227.140258.10297812.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Cc: hironobu@h2np.net, marc@mit.edu, warlord@mit.edu, rabbi@quickie.net, ddt@lsd.com Subject: Re: rfc2440bis-02 comments In-Reply-To: <200012270433.NAA25523@blue.h2np.net> References: <200012270433.NAA25523@blue.h2np.net> X-Mailer: Mew version 1.95b92 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: hello all, From: Hironobu SUZUKI Subject: Re: rfc2440bis-02 comments Date: Wed, 27 Dec 2000 13:33:38 +0900 > 2 years ago, I got a complain e-mail about adding public key by a > third party. Then I thought multi-phase commit for keyserver. But my > idea looks crypto-over-kill for our public keyserver. [ detailed description of pk-based challenge-response scheme snipped ] > This solution is not simple and powerful CPU is required for > keyserver. But I'm not sure that it is too much cost for keyserver. > > Please note that this is only idea and I don't recommend it. to add more hypothetical information to the situation... if keyservers are going to do authentication-like things (a big "if"), why not do the following: -before adding a key from the queue to a database, use an email confirmation system to solicit confirming email (don't need to use pk-based challenge-response for this) -- just use what many mailing list systems use. if confirmation is obtained, add the key to the database. -in order to remove a key from the database, use a challenge-response system like Hironobu described. -keys expire from servers by default. perhaps 6 months or 1 year. points to observe: -if deletions are relatively scarce events, you don't need much cpu power. keyservers can even decide to only service delete requests periodically in bulk. -in the case that the confirmation by email process is "spoofed" and a third party adds someone's key, the holder of the secret key can remove the key using the above method. i'm assuming the spoofing shouldn't be something that should continue to happen to a particular individual -- if it does, imo, that person has other problems that need to deal with first. -an "expire-from-server" time field (only allowed in the hashed area) could be defined in rfc 2440, support for this in keyservers and openpgp client implementations seems like one way to accomplish the expiration idea. -unused keys will be removed from servers over time. less garbage is collected and people who lose their secret keys can relax after a while. new users can be encouraged to choose short "expire-from-server" times. i think it's important to be able to update one's "expire-from-server" time -- i don't understand how key information on keyservers gets updated (which key information takes priority? always what gets submitted later in time? if so, may be something like a "timestamp" field is necessary in the hashed area so that a keyserver can decide which key info is more recent). -it's not required that keys have email address info associated w/ them. it's not clear to me whether one would bother w/ confirmation for these. thoughts? Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19366 for ietf-openpgp-bks; Tue, 26 Dec 2000 20:31:03 -0800 (PST) Received: from blue.h2np.net (bule.h2np.net [210.145.219.253] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA19360 for ; Tue, 26 Dec 2000 20:31:00 -0800 (PST) Received: from mail.h2np.net (IDENT:hironobu@pc [192.168.1.10]) by blue.h2np.net (8.9.3/8.9.3) with ESMTP id NAA25523; Wed, 27 Dec 2000 13:33:40 +0900 Message-Id: <200012270433.NAA25523@blue.h2np.net> From: Hironobu SUZUKI To: Marc Horowitz cc: Derek Atkins , "L. Sassaman" , Dave Del Torto , ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: rfc2440bis-02 comments In-reply-to: Your message of "26 Dec 2000 22:36:38 EST." Date: Wed, 27 Dec 2000 13:33:38 +0900 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, Marc. > - I don't want my key on the keyservers at all. > > Your proposal solves this problem, but in my experience, this almost > never happens. 2 years ago, I got a complain e-mail about adding public key by a third party. Then I thought multi-phase commit for keyserver. But my idea looks crypto-over-kill for our public keyserver. Step 1: User submit their public key to keyserver. Step 2: Keyserver save this public key in queue database. Step 3: keyserver returns "ticket (challenge random number)" which is encrypted by user's public key. Step 4: After User decrypt received "ticket", user sign "ticket" by their secret key and send "signed ticket" to keyserver. Step 5: Keyserver check "signed ticket" by user's queued public key. Ture -> move it to public-open database. False -> delete from queue database. Note: When keyserver use this scheme, Sync data must be signed or something against forge sync data. (Also adding MAC looks good). This solution is not simple and powerful CPU is required for keyserver. But I'm not sure that it is too much cost for keyserver. Please note that this is only idea and I don't recommend it. --hironobu Received: by ns.secondary.com (8.9.3/8.9.3) id TAA18095 for ietf-openpgp-bks; Tue, 26 Dec 2000 19:33:04 -0800 (PST) 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 TAA18091 for ; Tue, 26 Dec 2000 19:33:02 -0800 (PST) Received: (from marc@localhost) by horowitz.ne.mediaone.net (8.8.8/8.8.8) id WAA04228; Tue, 26 Dec 2000 22:36:39 -0500 (EST) X-Authentication-Warning: horowitz.ne.mediaone.net: marc set sender to marc@horowitz.ne.mediaone.net using -f From: Marc Horowitz To: Derek Atkins Cc: "L. Sassaman" , Dave Del Torto , , Subject: Re: rfc2440bis-02 comments References: Date: 26 Dec 2000 22:36:38 -0500 In-Reply-To: Derek Atkins's message of "17 Dec 2000 12:21:05 -0500" Message-ID: Lines: 32 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.3 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: Len, exactly what problem is you proposal intended to solve? You said: One of the major complaints I hear about PGP key servers is the inability to delete keys once they are sent to the server. I'd like to request the addition of two new flags for subpacket 23: Why do these people want to delete their keys? - They lost the private key or forgot the passphrase. Like Derek, this is by far the most common reason I get email from people who want their keys deleted. Your proposal doesn't solve this problem, since they can't modify the key to change the keyserver preferences. - They don't want anybody to know they have a key. It doesn't solve this problem, either, as others have pointed out. - The key is compromised. In this case, they should revoke it. - I don't want my key on the keyservers at all. Your proposal solves this problem, but in my experience, this almost never happens. or is there another problem I've missed? Marc Received: by ns.secondary.com (8.9.3/8.9.3) id NAA24932 for ietf-openpgp-bks; Thu, 21 Dec 2000 13:30:52 -0800 (PST) Received: from mp.a-phys.eng.osaka-cu.ac.jp ([160.193.160.180]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id NAA24919 for ; Thu, 21 Dec 2000 13:30:39 -0800 (PST) From: hj4hj6@yahoo.com Received: by mp.a-phys.eng.osaka-cu.ac.jp id AA31928; Fri, 22 Dec 2000 06:24:32 +0900 Date: 21 Dec 00 1:39:39 PM Message-Id: <1Oxd7w7SeQB2> Subject: Improve your stepfamily life Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Apparently-To: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Does your stepfamily life resemble a soap opera more than it does the Brady Bunch? The Stepfamily Association of America invites you to participate in THE NATIONAL CONFERENCE FOR STEPFAMILIES, Feb. 23-24, 2001, at the New Orleans Marriott Hotel. This is an opportunity, designed by knowledgeable professionals, in stepfamilies themselves, to help you: * Make your remarriage a success * Create bonds with your stepchildren * Help your children adjust emotionally * Manage money matters unique to your family * Get more help from legal, financial, psychological advisors * Overcome stepfather and stepmother stereotypes * Elicit cooperation from your children's schools * Bring more harmony into family life Complete conference details at http://www.edupr.com REGISTER ONLINE! Attend, and also enjoy Mardi Gras week in New Orleans! Special discounts for couples, students, groups. HOTEL IS BOOKING UP FAST. ACT NOW BEFORE ROOM BLOCK AND AIRLINE SEATS FILL Special rates for conference attendees. Visit http://www.edupr.com for discounts. Childcare available through a bonded local service. Up to 17 professional development credits available if you are an educator, clinician, financial planner, social worker. Questions? Email stepfamilyconf@mail.com If you would like to be removed, please email us back with the word "Remove" in the subject line. We apologize for any inconvenience. Received: by ns.secondary.com (8.9.3/8.9.3) id HAA02268 for ietf-openpgp-bks; Thu, 21 Dec 2000 07:39:43 -0800 (PST) Received: from bureau6.utcc.utoronto.ca (bureau6.utcc.utoronto.ca [128.100.132.16]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA02256 for ; Thu, 21 Dec 2000 07:39:42 -0800 (PST) Received: from [205.211.160.30] ([205.211.160.30] EHLO MSH4906 ident: TIMEDOUT [port 16989]) by bureau6.utcc.utoronto.ca with ESMTP id <464413-15546>; Thu, 21 Dec 2000 10:42:48 -0500 Date: Thu, 21 Dec 2000 10:45:01 -0500 From: Robert Guerra To: ietf-openpgp@imc.org cc: Keyserver-Folk-Mailinglist Subject: [PGP-USERS] (mac) PGP 6.5.8 -> Request for patchfix comments.. (fwd) Message-ID: <2437924968.977395501@MSH4906> X-Mailer: Mulberry/2.0.5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: ---------- Forwarded Message ---------- Date: Thursday, December 21, 2000 8:17 AM -0500 From: Robert Guerra To: pgp-users@cryptorights.org Subject: [PGP-USERS] (mac) PGP 6.5.8 -> Request for patchfix comments.. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there: A couple days back I detailed a persistant problem in which the first couple of lines of pgp cyphertext appears in the Header section of email. I've consulted with the developper of the the email client I use (eudora) and the email server I use (EIMS 3.02) and they both point fingers to it being a problem with the pgp-plugin on the mac end. As it's not a security hole, and since NAI won't issue a specific bug fix...it leaves it to me to see what to do.. Consequently I have dowloaded the (mac) PGP 658 source code from the www.pgpi.org site and quickly looked over the code. I currently don't have the time nor resources to recompiple the code..so i've included my suggested patches in an archive for peer review. http://www.cryptorights.org/pgp-users/resources/mac-pgpfix.sit.Hqx I'm hoping those more knowleable with the code will : 1. take a look at it 2. ok the changes and/or correct it further 3. post any comments and/or additional suggestions 4. re-compile the code for the community looking forward to everyone's comments regards robert -----BEGIN PGP SIGNATURE----- Version: Mulberry PGP Plugin v2.0 Comment: processed by Mulberry PGP Plugin iQA/AwUBOkIC68KdCsHMpdeSEQJQtQCgh0jF7ejx9KPxfVTef/3jTNrffBkAoO/H 7rZ7jQ/OK2mEZw6lh7JH3Bfg =ogqN -----END PGP SIGNATURE----- .................................................................... Unsubscribe: Automated Help/Info: List Homepage: List Admin (human): Please do not send administrative commands to the list address! Thanks. ---------- End Forwarded Message ---------- Received: by ns.secondary.com (8.9.3/8.9.3) id GAA25904 for ietf-openpgp-bks; Thu, 21 Dec 2000 06:37:25 -0800 (PST) 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 GAA25900 for ; Thu, 21 Dec 2000 06:37:23 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id OAA19980; Thu, 21 Dec 2000 14:40:43 GMT Message-ID: Date: Thu, 21 Dec 2000 14:38:08 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: Dash-escaping and the Usenet sig convention References: <20001212135300.N21969@gnupg.de> <20001221134148.D29043@gnupg.de> In-Reply-To: <20001221134148.D29043@gnupg.de> 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 Thu, 21 Dec 2000, Werner Koch wrote: >On Thu, 21 Dec 2000, Ian Bell wrote: > >> * separator conventions use lines starting with multiple dashes. To >> * improve interoperability in these cases, clients MAY omit the dash- >> * escaping for lines that cannot be armor headers and that are not >> * already dash-escaped. Lines beginning with dash-space (0x2D, 0x20), > >I am not sure whether yoy are talking about an OpenPGP implementaion >or an MUA. We can't do that in the OpenPGP protocol. >The only thing we could do is to allow dash escaping in certain >situations like we do it for '^From '. But it may break other >applications and I don't know why it should make sense at all. It makes sense from a MUA perspective because it increases interoperability between MUAs in the real world. The problem can indeed be ignored by open PGP implementations when they create clear-signed text and can be dealt with by MUAs changing the dash-escaping before posting in the way we have been asked to do. However this pushes the problem on to the receiving openPGP implementation. It is the receiving openPGP implementation that has to parse the results of clear-signed messages with some dash-escaping removed. They can either cope, or treat the message as an invalid clear- signed message (as old versions of Turnpike used to do!). In the real world, some users are changing the dash-escaping by hand and they have found that PGP (NAI) copes well. I feel that there should be at least a note to reflect what is being done to the dash-escaping in order to make openPGP implementations robust when they encounter such messages and hopefully to encourage them to correctly verify signatures in such messages as PGP itself would do. -- Ian Bell T U R N P I K E Received: by ns.secondary.com (8.9.3/8.9.3) id EAA21233 for ietf-openpgp-bks; Thu, 21 Dec 2000 04:49:55 -0800 (PST) Received: from mail.hsp.de (mail.hsp.de [194.77.127.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA21216 for ; Thu, 21 Dec 2000 04:49:51 -0800 (PST) Received: from kasiski.gnupg.de (werner-gw.openit.de [194.231.77.111]) by mail.hsp.de (8.11.1/8.11.1) with ESMTP id eBLCrBJ25601 for ; Thu, 21 Dec 2000 13:53:11 +0100 Received: from wk by kasiski.gnupg.de with local (Exim 3.16 #1 (Debian)) id 14952a-000888-00; Thu, 21 Dec 2000 13:41:48 +0100 Date: Thu, 21 Dec 2000 13:41:48 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Dash-escaping and the Usenet sig convention Message-ID: <20001221134148.D29043@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20001212135300.N21969@gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ianbell@turnpike.com on Thu, Dec 21, 2000 at 11:47:39AM +0000 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.guug.de/~werner.koch/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 21 Dec 2000, Ian Bell wrote: > * separator conventions use lines starting with multiple dashes. To > * improve interoperability in these cases, clients MAY omit the dash- > * escaping for lines that cannot be armor headers and that are not > * already dash-escaped. Lines beginning with dash-space (0x2D, 0x20), I am not sure whether yoy are talking about an OpenPGP implementaion or an MUA. We can't do that in the OpenPGP protocol. The only thing we could do is to allow dash escaping in certain situations like we do it for '^From '. But it may break other applications and I don't know why it should make sense at all. Werner Received: by ns.secondary.com (8.9.3/8.9.3) id DAA17810 for ietf-openpgp-bks; Thu, 21 Dec 2000 03:47:00 -0800 (PST) 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 DAA17805 for ; Thu, 21 Dec 2000 03:46:59 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA26898; Thu, 21 Dec 2000 11:50:16 GMT Message-ID: Date: Thu, 21 Dec 2000 11:47:39 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: Dash-escaping and the Usenet sig convention References: <20001212135300.N21969@gnupg.de> 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 Tue, 12 Dec 2000, Ian Bell wrote: >On Tue, 12 Dec 2000, Werner Koch wrote: >We have been asked to munge the dash-stuffed clear text as in practice >the use of PGP/MIME signed messages causes more complaints than clear- >signed messages, but clear-signing messages causes complaints about >broken sig-seps :-( >>It is a matter of the MUA to handle this right. Mutt for example >>does remove the dash escaping even when it does not verify the >>signature. MUAs in general won't handle this right because for the most part MUAs are PGP-unaware. The interoperability problem here is between PGP-aware MUAs and PGP-unaware MUAs . Clear-signed messages are more acceptable to PGP-unaware MUAs if the sig-sep is not hyphen-stuffed, and hence clear- signing will be more acceptable in newsgroups and mailing-lists. In order to increase the acceptability of PGP signed messages in general, could 7.1 in 2440bis be amended as follows? 7.1. Dash-Escaped Text The cleartext content of the message must also be dash-escaped. Dash escaped cleartext is the ordinary cleartext where every line starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and space ' ' (0x20). This prevents the parser from recognizing armor headers of the cleartext itself. The message digest is computed using the cleartext itself, not the dash escaped form. * Note: dash-escaping can cause interoperability problems between PGP- * aware clients and PGP-unaware clients because some commonly used * separator conventions use lines starting with multiple dashes. To * improve interoperability in these cases, clients MAY omit the dash- * escaping for lines that cannot be armor headers and that are not * already dash-escaped. Lines beginning with dash-space (0x2D, 0x20), * or with five dashes MUST be dash-escaped. As with binary signatures on text documents, a cleartext signature is calculated on the text using canonical line endings. The line ending (i.e. the ) before the '-----BEGIN PGP SIGNATURE-----' line that terminates the signed text is not considered part of the signed text. Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of any line is ignored when the cleartext signature is calculated. -- Ian Bell T U R N P I K E Received: by ns.secondary.com (8.9.3/8.9.3) id TAA12307 for ietf-openpgp-bks; Tue, 19 Dec 2000 19:59:27 -0800 (PST) Received: from merchantsystems.com (pppoe0118.lr.centurytel.net [209.206.192.55]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA12299 for ; Tue, 19 Dec 2000 19:59:25 -0800 (PST) Date: Tue, 19 Dec 2000 19:59:25 -0800 (PST) From: carlgroh@merchantsystems.com Message-Id: <200012200359.TAA12299@ns.secondary.com> To: ietf-openpgp@imc.org X-Mailer: 5F5DEEF.6F9931C8.5b2805d9e793625394b4e5f0e7705308 Subject: Don't Get Ripped Off! Organization: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm sure... If my competitors get a hold of this letter, I might as well move out of the country! Let me explain. I'm in the business of setting people up to do business on the Internet. As you probably know, there's only a few things that you actually need to accomplish this.... 1. Something to sell 2. A working website 3. Traffic to the website 4. A way for people to pay you over the net. Here's my point. While my competitors are charging anywhere from $695 to a few thousand to get people set up to do business on the net, my company does it all for -- a one time -- complete price of $195! Maybe that's the reason we currently have over 180,000 clients using our services. (We list a large number of them on our website). The $195 includes everything... Your own Domain (website), Free website hosting unlimited email accounts, autoresponders, shopping cart system, online credit card acceptace (processing) system, Internet merchant account, Free software that creates your website, Free instructions on getting traffic to your website, and many other Free tools to neumerous to list in a short email message. Anyway, If you've been thinking about selling online, but thought it was too expensive or complicated or too confusing, you've been paying to much attention to my competitors. If you're interested and want to find out more, It's very simple to do. Simply call my office -- toll free -- 888-269-7960 and I'll be glad to explain everything to you in detail. Just be aware, that I might be on the phone helping someone else out. So kindly leave a message and I'll get right back to you. If you're not interested, just delete this message. You'll never hear from me again. I guarantee it! Merchant Systems Received: by ns.secondary.com (8.9.3/8.9.3) id OAA06498 for ietf-openpgp-bks; Tue, 19 Dec 2000 14:50:17 -0800 (PST) Received: from LindaleUSA.com (pppoe0338.lr.centurytel.net [64.91.13.212]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id OAA06489 for ; Tue, 19 Dec 2000 14:50:14 -0800 (PST) Date: Tue, 19 Dec 2000 14:50:14 -0800 (PST) From: Linda&Dale@LindaleUSA.com Message-Id: <200012192250.OAA06489@ns.secondary.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=200012191751=" To: ietf-openpgp@imc.org X-Mailer: DD3C1F9.76B4BC64.62d9d2633ce1b9717adc2cd54a8fe321 Subject: FREE Catalog Organization: Lindale USA Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --=200012191751= Content-Type: text/plain;charset=US-ASCII Happy Holidays from Linda and Dale! YOU have been selected to receive a FREE "Showcase" catalog! As our Holiday gift to you, we will send you our BEAUTIFUL full-color "Showcase" catalog just for the asking! All you have to do is click here... http://www.wholesalespecialties.com/showcasecatalogorder.htm It's jam-packed with our best high-quality gift merchandise that is PERFECT for every gift occasion. We even have a way for you to make money while you shop for gifts! Please click here to order your FREE "Showcase" catalog... http://www.wholesalespecialties.com/showcasecatalogorder.htm and click here to visit our online gift shop... http://www.wholesalespecialties.com Thanks again and have a WONDREFUL hoilday season! Linda and Dale Lindale USA Your email address was submitted to us by a visitor to our web site. They want to let you know about our fabulous offer so that you can have your own FREE catalog too. If your email address has been given to us by mistake or if you have received this email offer by mistake, please click here to be automatically removed from our list... remove@wholesalespecialties.com --=200012191751=-- Received: by ns.secondary.com (8.9.3/8.9.3) id FAA23531 for ietf-openpgp-bks; Mon, 18 Dec 2000 05:59:48 -0800 (PST) Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA23527 for ; Mon, 18 Dec 2000 05:59:46 -0800 (PST) Received: from [204.179.136.48] (204.179.136.33) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2); Mon, 18 Dec 2000 06:02:47 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: <20001218.144252.59672699.sen_ml@eccosys.com> References: <20001218.144252.59672699.sen_ml@eccosys.com> X-Sender: Date: Mon, 18 Dec 2000 05:54:56 -0800 To: sen_ml@eccosys.com From: Dave Del Torto Subject: Re: rfc2440bis-02 comments Cc: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org 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 2:42 pm +0900 2000-12-18, sen_ml@eccosys.com wrote: >one authentication-less way that occurred to me is to have keys have >life times on servers (default being 1 year perhaps?). then, though >you might have to wait a while, at least your old keys could disappear >from servers after a certain period of time. I agree that the default should be one year. I've been calling for this for a very long time, and I'm definitely not alone. There are so many confused users out there on these key management points: I'm beginning to wonder if the development community is really paying attention to usability issues. PGP 7's Key Reconstruction is a very nice idea, but I've tried to get some newbies to use it and their reaction to being confronted by a dialog asking them to come up with five questions in case they forgot their passphrase was "are you kidding me?!" Also consider the idea of keyservers employing "flushing routines" for potentially "dead" keys. In one possible scenario, a key has languished on a server (e.g. hasn't been accessed for n ticks) for two years, has no expiration and is about to disappear as described above. The keyserver could email it to all of the email addresses on the key (this would encourage people to keep their userids current, yet another extremely common key hygiene problem). If the key wasn't updated by anyone within another time period (set by the admin), the key would be dropped. Storing your key on a public keyserver is a privilege, not a right. If you can't do the most basic things to maintain it, you're not doing anyone any good, least of all yourself if you want people to use it. >your client software can remind you that you need to upload your key >when it gets close to the "expiration" date/time. It would make sense if *all* OpenPGP-compliant implementations had some basic HCI features like this: a warning when one's key is about to expire seems extremely obvious -- or even when signatures made by one's key on others' keys (stored on one's local keyring) are about to expire. Jon, perhaps expiration packets can be mentioned in 2440bis as being potential triggers for this mechanism. Implementors could also be encouraged to consider providing expiration warning mechanisms. dave Received: by ns.secondary.com (8.9.3/8.9.3) id VAA22070 for ietf-openpgp-bks; Sun, 17 Dec 2000 21:40:07 -0800 (PST) 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 VAA22065 for ; Sun, 17 Dec 2000 21:40:01 -0800 (PST) From: sen_ml@eccosys.com Received: (qmail 22085 invoked from network); 18 Dec 2000 05:34:36 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 18 Dec 2000 05:34:36 -0000 Date: Mon, 18 Dec 2000 14:42:52 +0900 (JST) Message-Id: <20001218.144252.59672699.sen_ml@eccosys.com> To: ietf-openpgp@imc.org, pgp-keyserver-folk@flame.org Subject: Re: rfc2440bis-02 comments In-Reply-To: References: X-Mailer: Mew version 1.95b89 on Emacs 21.0 / Mule 5.0 (SAKAKI) X-cite-me: =?iso-2022-jp?B?GyRCJDskcxsoQg==?= Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Derek Atkins Subject: Re: rfc2440bis-02 comments Date: 17 Dec 2000 12:21:05 -0500 > Unfortunately this particular approach will not solve what I believe > to be the bigger problem: "I reinstalled my machine and lost my secret > key; can you remove it from the keyserver, please?" or "I forgot my > passphrase, can you please delete my key from the keyservers?" If I > had a dollar for every time I received one of these messages, I'd be a > very rich man right now ;) is it possible to address this issue w/o the keyservers doing any sort of authentication? i had thought that there was a fairly strong feeling that the keyservers should not do any sort of authentication. has this changed? one authentication-less way that occurred to me is to have keys have life times on servers (default being 1 year perhaps?). then, though you might have to wait a while, at least your old keys could disappear from servers after a certain period of time. your client software can remind you that you need to upload your key when it gets close to the "expiration" date/time. [ of course the "expire-from-server" date needs to be in the hashed area. ] Received: by ns.secondary.com (8.9.3/8.9.3) id JAA27124 for ietf-openpgp-bks; Sun, 17 Dec 2000 09:18:15 -0800 (PST) Received: from rcn.ihtfp.org (me@ORANGE-TOUR.IHTFP.ORG [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA27120 for ; Sun, 17 Dec 2000 09:18:13 -0800 (PST) Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id MAA30834; Sun, 17 Dec 2000 12:21:05 -0500 To: "L. Sassaman" Cc: Dave Del Torto , Marc Horowitz , , Subject: Re: rfc2440bis-02 comments References: From: Derek Atkins Date: 17 Dec 2000 12:21:05 -0500 In-Reply-To: "L. Sassaman"'s message of "Fri, 15 Dec 2000 16:53:55 -0800 (PST)" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Unfortunately this particular approach will not solve what I believe to be the bigger problem: "I reinstalled my machine and lost my secret key; can you remove it from the keyserver, please?" or "I forgot my passphrase, can you please delete my key from the keyservers?" If I had a dollar for every time I received one of these messages, I'd be a very rich man right now ;) The additional packets really don't help much more than being able to revoke one's key. If one could 'disable' a key themselves, they could also revoke that same key. The problem is that most of the requests come from people who cannot modify their key (due to circumstances that may or may not be out of their control). If we're going to solve the "key disable" problem, we need to do so in a manner that helps the user who lost their own key. Otherwise the solution really doesn't solve the real problems that exist today. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: by ns.secondary.com (8.9.3/8.9.3) id QAA21688 for ietf-openpgp-bks; Fri, 15 Dec 2000 16:51:40 -0800 (PST) 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 QAA21682 for ; Fri, 15 Dec 2000 16:51:38 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id QAA25198; Fri, 15 Dec 2000 16:54:03 -0800 Date: Fri, 15 Dec 2000 16:53:55 -0800 (PST) From: "L. Sassaman" X-Sender: To: Dave Del Torto cc: Marc Horowitz , , Subject: Re: rfc2440bis-02 comments In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 15 Dec 2000, Dave Del Torto wrote: > The threat, perhaps a theoretical one at this point in time, is > that if you're trying to mask the very existence of your key on > one or more keyservers (for example to thwart an improperly coercive > demand for keying material from rogue officials), you will not be able > to do so with these flags. You would only be able to do this by > deleting them via an LDAPS (or similarly secure) keyserver connection. Sure. That isn't the threat these flags were intended to solve. In fact, I am not sure this threat you mention isn't an intractable problem; once a key is deleted from the server, it can always be re-added by a third party. (Unless, of course, the no-modify flag is set. Then the owner of the key would be required to authenticate himself prior to adding the key to the server.) > BTW, the trail of evidence that Deletion would involve, reminds me of > another thread I wanted to raise (wearing my CryptoRights hat) with > the keyserver managers, regarding the need for standardized > mechanisms permitting secure, UNauthenticated, UNlogged connections > to keyservers. Deleting a key would still require a passphrase, but > it would permit one to clear a key if one was under threat. Hrmm. guaranteeing that connections are unlogged isn't really possible, I don't think. Though if this became a really important issue, I suspect you could set up some sort of key request system using the anonymous remailer network... but that seems a bit extreme. Rodney Thayer and I are working on an Internet Draft for key server behavior. We'll try to cover all these issues in there, and will welcome any comments on it when we publish. (Key server issues are really beyond the scope of 2440. The only reason I've brought this up now is that I would like to see these flags added so we can utilize them in the key servers.) Thanks for your comments, - --Len. __ L. Sassaman Security Architect | "The world's gone crazy, Technology Consultant | and it makes no sense..." | http://sion.quickie.net | --Sting -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE6Or0qPYrxsgmsCmoRAo3bAKDkWxI1TZK+devdAK/dpF0RqLogfQCgupTw UxT8xssVKNoNxR2ezEPpHZs= =UbHQ -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id PAA20533 for ietf-openpgp-bks; Fri, 15 Dec 2000 15:51:24 -0800 (PST) Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA20529 for ; Fri, 15 Dec 2000 15:51:23 -0800 (PST) Received: from [204.179.131.28] (204.179.131.133) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2); Fri, 15 Dec 2000 15:54:13 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Sender: Date: Fri, 15 Dec 2000 15:48:57 -0800 To: "L. Sassaman" From: Dave Del Torto Subject: Re: rfc2440bis-02 comments Cc: Marc Horowitz , , pgp-keyserver-folk@flame.org 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 2:46 pm -0800 2000-12-15, L. Sassaman wrote: >On Fri, 15 Dec 2000, Dave Del Torto wrote: >>However, if the intent is to "mask" the presence of Bob's key on >>the keyserver in lieu of Deleting it, it's hard to see what sort of >>keyserver response behaviour would prevent Eve from trying to >>determine the presence of Bob's key on the server -- by deducing >>that information using the very 0x40 flag you describe in >>conjunction with the keyserver behaviour. This simply shifts the >>policy focus from the pksd's delete policy to its search policy. >> >>All Eve would need to do is upload the public component to the >>keyserver in order to determine the status of the subpacket 23 >>enable/disable flags: if the key is present but disabled, it will >>"vanish," confirming that it's disabled. If not present, it will be >>returned by a subsequent search. A rudimentary traffic analysis >>technique. > >Where is the threat here? The threat, perhaps a theoretical one at this point in time, is that if you're trying to mask the very existence of your key on one or more keyservers (for example to thwart an improperly coercive demand for keying material from rogue officials), you will not be able to do so with these flags. You would only be able to do this by deleting them via an LDAPS (or similarly secure) keyserver connection. BTW, the trail of evidence that Deletion would involve, reminds me of another thread I wanted to raise (wearing my CryptoRights hat) with the keyserver managers, regarding the need for standardized mechanisms permitting secure, UNauthenticated, UNlogged connections to keyservers. Deleting a key would still require a passphrase, but it would permit one to clear a key if one was under threat. >The reason I prefer a "disable" approach to a "delete" approach is >that deleted keys can always reappear. The behavior you describe >seems to me to be the appropriate one. We can agree on that much. I guess I'm just applying a more stringent threat model -- speculating that regimes like RIPA may someday soon negatively impact the human rights of crypto users. I still like your key-disable flag idea, Len. dave Received: by ns.secondary.com (8.9.3/8.9.3) id OAA19005 for ietf-openpgp-bks; Fri, 15 Dec 2000 14:44:45 -0800 (PST) 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 OAA19000 for ; Fri, 15 Dec 2000 14:44:43 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id OAA21493; Fri, 15 Dec 2000 14:46:56 -0800 Date: Fri, 15 Dec 2000 14:46:48 -0800 (PST) From: "L. Sassaman" X-Sender: To: Dave Del Torto cc: Marc Horowitz , Subject: Re: rfc2440bis-02 comments In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, 15 Dec 2000, Dave Del Torto wrote: > If the intent is to allow a Alice to effectively Remove her public > key -- even if the keyserver's policy/software doesn't allow her to > Delete it -- then I think this is useful. Of course, this presumes > that Alice still retains her ability to modify the public key. Of course. > However, if the intent is to "mask" the presence of Bob's key on the > keyserver in lieu of Deleting it, it's hard to see what sort of > keyserver response behaviour would prevent Eve from trying to > determine the presence of Bob's key on the server -- by deducing that > information using the very 0x40 flag you describe in conjunction with > the keyserver behaviour. This simply shifts the policy focus from the > pksd's delete policy to its search policy. > > All Eve would need to do is upload the public component to the > keyserver in order to determine the status of the subpacket 23 > enable/disable flags: if the key is present but disabled, it will > "vanish," confirming that it's disabled. If not present, it will be > returned by a subsequent search. A rudimentary traffic analysis > technique. Where is the threat here? The reason I prefer a "disable" approach to a "delete" approach is that deleted keys can always reappear. The behavior you describe seems to me to be the appropriate one. > The big question of course, is "who can set these flags?" IMHO, they > musn't be outside the hashed subpackets: they need to be set by the > key-owner, lest they contribute to a DoS attack on any given public > key. This means that Alice or Bob could just as easily Revoke (or, > pksd policy permitting, Delete) their keypairs. If the keyserver > admmin is to be allowed to set the flag, this raises a serious key > management policy question, again just shifting the problem > elsewhere, but not solving it entirely. Right, no one, not even the key server admin, would be able to set these flags besides the key owner. I didn't feel that needed stating, since these flags are an addition to an existing subpacket which is already only found in self-signatures. They MUST NOT be placed outside the hashed area. - --Len. __ L. Sassaman Security Architect | "The world's gone crazy, Technology Consultant | and it makes no sense..." | http://sion.quickie.net | --Sting -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE6Op9fPYrxsgmsCmoRAvRKAKCsxYv996YOGDSAqWyAa+iSuJltqgCg+wn8 F54h58lhEm9yYUcvEAuiHAY= =/A05 -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id OAA18461 for ietf-openpgp-bks; Fri, 15 Dec 2000 14:25:58 -0800 (PST) Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA18456 for ; Fri, 15 Dec 2000 14:25:57 -0800 (PST) Received: from [204.179.131.28] (204.179.131.133) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2); Fri, 15 Dec 2000 14:28:45 -0800 Mime-Version: 1.0 Message-Id: In-Reply-To: References: X-Sender: Date: Fri, 15 Dec 2000 14:22:43 -0800 To: "L. Sassaman" From: Dave Del Torto Subject: Re: rfc2440bis-02 comments Cc: Marc Horowitz , 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 3:11 am -0800 2000-12-15, L. Sassaman wrote: >One of the major complaints I hear about PGP key servers is the inability >to delete keys once they are sent to the server. I'd like to request the >addition of two new flags for subpacket 23: > > 0x40 = Disabled > the key holder requests that this key not be returned upon > a search of the key server. > > 0x60 = Enabled > the key holder requests that this key be returned upon a > search of the key server. > >Keys bearing the disabled flag would either reside on the key server and >never be returned in a search (except perhaps to the administrator), or >they would be immediately deleted upon receipt by the key server. Len, I'm intrigued by your idea of "disabling" keys as a solution to this problem. I think it could be a useful addition, even with the questions it raises. If the intent is to allow a Alice to effectively Remove her public key -- even if the keyserver's policy/software doesn't allow her to Delete it -- then I think this is useful. Of course, this presumes that Alice still retains her ability to modify the public key. However, if the intent is to "mask" the presence of Bob's key on the keyserver in lieu of Deleting it, it's hard to see what sort of keyserver response behaviour would prevent Eve from trying to determine the presence of Bob's key on the server -- by deducing that information using the very 0x40 flag you describe in conjunction with the keyserver behaviour. This simply shifts the policy focus from the pksd's delete policy to its search policy. All Eve would need to do is upload the public component to the keyserver in order to determine the status of the subpacket 23 enable/disable flags: if the key is present but disabled, it will "vanish," confirming that it's disabled. If not present, it will be returned by a subsequent search. A rudimentary traffic analysis technique. The big question of course, is "who can set these flags?" IMHO, they musn't be outside the hashed subpackets: they need to be set by the key-owner, lest they contribute to a DoS attack on any given public key. This means that Alice or Bob could just as easily Revoke (or, pksd policy permitting, Delete) their keypairs. If the keyserver admmin is to be allowed to set the flag, this raises a serious key management policy question, again just shifting the problem elsewhere, but not solving it entirely. dave Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03485 for ietf-openpgp-bks; Fri, 15 Dec 2000 03:08:48 -0800 (PST) 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 DAA03479 for ; Fri, 15 Dec 2000 03:08:46 -0800 (PST) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id DAA06530; Fri, 15 Dec 2000 03:11:15 -0800 Date: Fri, 15 Dec 2000 03:11:03 -0800 (PST) From: "L. Sassaman" X-Sender: To: Marc Horowitz cc: Subject: Re: rfc2440bis-02 comments In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marc mentioned 5.2.3.17 (Key server preferences) and that reminded me of a suggestion I wanted to make. One of the major complaints I hear about PGP key servers is the inability to delete keys once they are sent to the server. I'd like to request the addition of two new flags for subpacket 23: 0x40 = Disabled the key holder requests that this key not be returned upon a search of the key server. 0x60 = Enabled the key holder requests that this key be returned upon a search of the key server. Keys bearing the disabled flag would either reside on the key server and never be returned in a search (except perhaps to the administrator), or they would be immediately deleted upon receipt by the key server. (The reason for the enabled flag is to reverse the effects of the disabled flag at a later date. And of course, if neither the disabled not the enabled flags are set, keys are implicitly enabled.) __ L. Sassaman Security Architect | "The world's gone crazy, Technology Consultant | and it makes no sense..." | http://sion.quickie.net | --Sting -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE6OfxSPYrxsgmsCmoRAug/AKDPWFT9+sykMTtbg3h6oheoaZEeuwCgipzp JLp7rXBfHFN5+uqIDz4h7R8= =7h+X -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28049 for ietf-openpgp-bks; Tue, 12 Dec 2000 08:40:27 -0800 (PST) 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 IAA28044 for ; Tue, 12 Dec 2000 08:40:26 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id QAA22090; Tue, 12 Dec 2000 16:42:59 GMT Message-ID: Date: Tue, 12 Dec 2000 16:42:20 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: Dash-escaping and the Usenet sig convention References: <20001212135300.N21969@gnupg.de> In-Reply-To: <20001212135300.N21969@gnupg.de> 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: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 12 Dec 2000, Werner Koch wrote: >On Tue, 12 Dec 2000, Ian Bell wrote: > >> newsgroups/mailing lists - the problem being that the "-- " gets stuffed >> to "- -- " with the result that recipients' clients will no longer > >The preferred way to encapsulate OpenPGP messages in mail is by using >MIME as defined in RFC2015. In an ideal world, PGP/MIME would be the only way anyone would send PGP in email... > No need for the old fashioned cleartext >signing. ...however, the reality is that most clients (in terms of numbers deployed) seem not to be able to cope. We have been asked to munge the dash-stuffed clear text as in practice the use of PGP/MIME signed messages causes more complaints than clear- signed messages, but clear-signing messages causes complaints about broken sig-seps :-( >> The question is, how do openPGP clients cope with such messages and what > >It is a matter of the MUA to handle this right. Mutt for example >does remove the dash escaping even when it does not verify the >signature. As does Turnpike. However, it will be the openPGP client that has to deal with the clear-text message with dash-stuffing that breaks RFC- 2440. As an example I have signed this message and broken the dash- stuffing (behind Turnpike's back, I might add!). I'd be interested if it causes any problems. -- Ian Bell T U R N P I K E -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBOjZUxb3aNYn/fmK7EQLGcACdH2kUCbQH06wWa/9Ap/6XaaWpdBMAnj1G IoOPuvpMBehwVZFZ52sEW63d =yQWW -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id IAA25188 for ietf-openpgp-bks; Tue, 12 Dec 2000 08:03:56 -0800 (PST) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA25179 for ; Tue, 12 Dec 2000 08:03:54 -0800 (PST) Received: from [63.73.97.184] (208.54.71.35) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1); Tue, 12 Dec 2000 08:06:18 -0800 Mime-Version: 1.0 X-Sender: jon@63.73.97.162 Message-Id: In-Reply-To: <20001212135300.N21969@gnupg.de> References: <20001212135300.N21969@gnupg.de> Date: Tue, 12 Dec 2000 08:06:12 -0800 To: Werner Koch , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Dash-escaping and the Usenet sig convention Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Re: Dash-escaping and the Usenet sig convention", shown on 12/12/00), Werner Koch said: >The preferred way to encapsulate OpenPGP messages in mail is by using >MIME as defined in RFC2015. No need for the old fashioned cleartext >signing. > I disagree completely. The correct way to encapsulate messages is with cleartext. I often delete PGP-MIME messages without reading them because it's such a pain to deal with them. I commonly use five different mail readers on four different OSes, and none of them do PGP-MIME reliably. That's Eudora on Mac and Windows, Outlook on Windows, Netscape and Pine on Linux and OSX. The biggest pain is on Windows, where it's hard to scrape up the attachment to put it in a text editor. >> The question is, how do openPGP clients cope with such messages and what > >It is a matter of the MUA to handle this right. Mutt for example >does remove the dash escaping even when it does not verify the >signature. I agree that this is a MUA and newsreader issue. They should parse out the quoting. The dash-escape may be ugly, but it's been a part of PGP since day 2, if not day 1. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id EAA10944 for ietf-openpgp-bks; Tue, 12 Dec 2000 04:56:18 -0800 (PST) Received: from mail.hsp.de (mail.hsp.de [194.77.127.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA10931 for ; Tue, 12 Dec 2000 04:56:08 -0800 (PST) Received: from kasiski.gnupg.de (werner-gw.openit.de [194.231.77.111]) by mail.hsp.de (8.11.1/8.11.1) with ESMTP id eBCCwXH02598 for ; Tue, 12 Dec 2000 13:58:33 +0100 Received: from wk by kasiski.gnupg.de with local (Exim 3.16 #1 (Debian)) id 145ovV-0004bQ-00; Tue, 12 Dec 2000 13:53:01 +0100 Date: Tue, 12 Dec 2000 13:53:01 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Dash-escaping and the Usenet sig convention Message-ID: <20001212135300.N21969@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.2.5i In-Reply-To: ; from ianbell@turnpike.com on Tue, Dec 12, 2000 at 10:23:24AM +0000 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 12 Dec 2000, Ian Bell wrote: > newsgroups/mailing lists - the problem being that the "-- " gets stuffed > to "- -- " with the result that recipients' clients will no longer The preferred way to encapsulate OpenPGP messages in mail is by using MIME as defined in RFC2015. No need for the old fashioned cleartext signing. > The question is, how do openPGP clients cope with such messages and what It is a matter of the MUA to handle this right. Mutt for example does remove the dash escaping even when it does not verify the signature. Werner Received: by ns.secondary.com (8.9.3/8.9.3) id CAA20130 for ietf-openpgp-bks; Tue, 12 Dec 2000 02:23:43 -0800 (PST) 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 CAA20124 for ; Tue, 12 Dec 2000 02:23:41 -0800 (PST) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id KAA23033; Tue, 12 Dec 2000 10:26:13 GMT Message-ID: Date: Tue, 12 Dec 2000 10:23:24 +0000 To: ietf-openpgp@imc.org From: Ian Bell Subject: Dash-escaping and the Usenet sig convention 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: It has been suggested that our mail/news client offer an option to "fix up" the Usenet sig separator in clear-signed messages to newsgroups/mailing lists - the problem being that the "-- " gets stuffed to "- -- " with the result that recipients' clients will no longer recognize and strip the personal signature in response messages. The dash-escaping leads to complaints about clear-signed messages to some groups and some users have taken to removing the dash-escaping by hand. Although this breaks RFC2440, (NAI)PGP clients still seem to correctly "de-escape" the message and verify the PGP signature. The question is, how do openPGP clients cope with such messages and what do other client vendors think about this? Since [open]PGP clients only need to be able to correctly parse nested ASCII-armored header lines, and these all begin with five hyphens, it would be possible to make an exception for lines such as "-- " when doing the dash-escaping. Munging the "- -- " back to "-- " does seem to yield benefits in inter- operability (for the sig-sep convention) and acceptability of PGP-signed messages, but it is important that it doesn't break inter-operability between PGP clients. Should RFC2440bis be updated to mention this? Do any existing clients fall over by spotting that some lines are escaped at the "wrong" depth? -- Ian Bell T U R N P I K E Received: by ns.secondary.com (8.9.3/8.9.3) id OAA08725 for ietf-openpgp-bks; Mon, 11 Dec 2000 14:58:29 -0800 (PST) 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 OAA08719 for ; Mon, 11 Dec 2000 14:58:28 -0800 (PST) Received: by sentry.gw.tislabs.com; id SAA25981; Mon, 11 Dec 2000 18:04:02 -0500 (EST) Received: from clipper.gw.tislabs.com(10.33.1.2) by sentry.gw.tislabs.com via smap (V5.5) id xma025973; Mon, 11 Dec 00 18:03:09 -0500 Received: (from balenson@localhost) by clipper.gw.tislabs.com (8.9.3/8.9.1) id RAA29304 for ietf-openpgp@imc.org; Mon, 11 Dec 2000 17:59:27 -0500 (EST) Date: Mon, 11 Dec 2000 17:59:27 -0500 (EST) From: "David M. Balenson" Message-Id: <200012112259.RAA29304@clipper.gw.tislabs.com> To: ietf-openpgp@imc.org Subject: ANNOUNCE: ISOC Netw. & Distr. Sys. Security Symp. (NDSS'01) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: R E G I S T E R N O W ! ! THE INTERNET SOCIETY'S 2001 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'01) February 8-9, 2001 Catamaran Resort Hotel, San Diego, California General Chair: Steve Welke, Trusted Computer Solutions Program Chairs: Avi Rubin, AT&T Labs - Research Paul Van Oorschot, Entrust Technologies ONLINE INFORMATION AND REGISTRATION: http://www.isoc.org/ndss01 EARLY REGISTRATION DISCOUNT DEADLINE: January 11, 2001 The 8th annual NDSS Symposium brings together researchers, implementers, and users of network and distributed system security technologies to discuss today's important security issues and challenges. The Symposium provides a mix of technical papers and panel presentations that describe promising new approaches to security problems that are practical and, to the extent possible, have been implemented. NDSS fosters the exchange of technical information and encourages the Internet community to deploy available security technologies and develop new solutions to unsolved problems. THIS YEAR'S TOPICS INCLUDE: * IP Traceback * Authenticating Streamed Data * ATM Encryption * Source Authentication for Multicast * Distributed Certified E-Mail * Wireless Security * Multi-Security Domain Networks * Authentication And Key Agreement * Access Control Language for Security Policies * Limiting the Disclosure of Access Control Policies * Principles of Policy in Secure Groups * Trust Management for IPsec * Building Certification Paths * Decentralized Jini Security * Termination in Language-based Systems * Cryptography as a Network Service * Implementation of Kerberos Crossrealm Referral Handling * Security Risks of Peer-to-Peer Networking PRE-CONFERENCE TECHNICAL TUTORIALS: * Network Security Protocol Standards, Stephen Kent * Deployed & Emerging Security Systems for the Internet, Radia Perlman & Charlie Kaufman * Building Secure Software, Gary McGraw * Intrusion Detection, Dan Nadir * Biometrics, Jim Wayman * Group Security, Thomas Hardjono & Hugh Harney SPONSORSHIP OPPORTUNITIES AVAILABLE! Take advantage of this high visibility event. Contact Torryn Brazell at the Internet Society at +1-703-326-9880 or send e-mail to brazell@isoc.org. THE INTERNET SOCIETY is a non-governmental organization for global cooperation and coordination for the Internet and its internetworking technologies and applications. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA17721 for ietf-openpgp-bks; Sat, 9 Dec 2000 09:12:36 -0800 (PST) Received: from nt1.rocori.k12.mn.us (nt1.rocori.k12.mn.us [207.229.251.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA17717; Sat, 9 Dec 2000 09:12:34 -0800 (PST) Message-Id: <200012091712.JAA17717@ns.secondary.com> From: Mail Sender To: ietf-nntp-request@academ.com CC: ietf-openpgp@imc.org, ietf-openpgp-request@imc.org, ietf-otp@research.telcordia.com, ietf-otp-request@research.telcordia.com, ietf-pkix@imc.org Subject: Russian Goods and Service from Moscow Reply-To: mailsender@mailsender.ru Date: 09.12.2000 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: www.rusgoods.com www.rusgoods.ru ================================================================ We present you the production of the 1-st Moscow Watch Factory "Poljot" (Flying). From the simple mechanical watch of the series 2609 till unique, composite and precise mechanical o'clock - Marine timer . It is unique factory in Russia, which makes mechanical hours with the Swiss quality. Factory, which makes watches for the Russian Air Forces , Russian Naval Forces. All mechanical watch which we offer to you, will be delivered to you directly from the factory. If it isn't in the warehouse of the factory, we will place your order directly at the 1-st Moscow Watch Factory without any middlemans. The submarine "Kursk" had on board mechanical marine hronometr 6MX. =============================================================== The "table" of orders. Here you can to order, to find, to know almost everything, than the Russia is rich, everything that does not contradict Russian Federation laws. Here you can receive or order: The information about any enterprise, firm, organization, or person in Russia The production or any goods of Russian manufactories, and other things if it is possible. =============================================================== www.rusgoods.com www.rusgoods.ru Received: by ns.secondary.com (8.9.3/8.9.3) id DAA24670 for ietf-openpgp-bks; Fri, 8 Dec 2000 03:57:25 -0800 (PST) Received: from mail.hsp.de (mail.hsp.de [194.77.127.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24657 for ; Fri, 8 Dec 2000 03:57:22 -0800 (PST) Received: from kasiski.gnupg.de (werner-gw.openit.de [194.231.77.111]) by mail.hsp.de (8.11.1/8.11.1) with ESMTP id eB8BxZH07251 for ; Fri, 8 Dec 2000 12:59:35 +0100 Received: from wk by kasiski.gnupg.de with local (Exim 3.16 #1 (Debian)) id 144MGJ-0007eW-00; Fri, 08 Dec 2000 13:04:27 +0100 Date: Fri, 8 Dec 2000 13:04:27 +0100 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: rfc2440bis-02 comments Message-ID: <20001208130427.J21969@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.2.5i In-Reply-To: ; from marc@mit.edu on Fri, Dec 08, 2000 at 12:51:19AM -0500 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 8 Dec 2000, Marc Horowitz wrote: > 3. Subpacket 23 (key server preferences) is specified to be "found > only on a self-signature". It should say if that means a direct > key signature (which makes the most sense to me), or something As with many other subpackets there is no clear definition on what to do and it is left to the implementor to decide this. From my understanding it does make sense to handle such things this way: * If it is on any direct key signature, use this one (or exactly the one on the latest direct key signure. * Otherwise take it from the latest self-signature. (I have worked out some more rules and checked them with Hal. Currently I can't access them - please ask me next week, if you are interested) > 4. The document is vague on what constitures "advisory information" in > a signature subpacket (section 5.2.3). I believe that unhashed > signature subpackets were a mistake (I can expound on this if No, they make sense. It may happen that you need to store some meta information about a signature which you have to calculate after signature creation. However, a big warning about unhashed stuff should be present. > 5. There should be a note that the critical bit MUST be ignored on > unhashed signature subpackets. Otherwise, an attacker can easily > cause any signature to fail to verify. Does not make sense. An attacker can make _any_ signature fail but just flipping one bit. Werner Received: by ns.secondary.com (8.9.3/8.9.3) id VAA13485 for ietf-openpgp-bks; Thu, 7 Dec 2000 21:49:18 -0800 (PST) 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 VAA13481 for ; Thu, 7 Dec 2000 21:49:17 -0800 (PST) Received: (from marc@localhost) by horowitz.ne.mediaone.net (8.8.8/8.8.8) id AAA08004; Fri, 8 Dec 2000 00:51:20 -0500 (EST) X-Authentication-Warning: horowitz.ne.mediaone.net: marc set sender to marc@horowitz.ne.mediaone.net using -f From: Marc Horowitz To: ietf-openpgp@imc.org Subject: rfc2440bis-02 comments Date: 08 Dec 2000 00:51:19 -0500 Message-ID: Lines: 62 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.3 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: Many of these comments come from notes I took on rfc2440, so I may have some section numbers wrong. I did compare these notes to the I-D, and I believe all of them are still relevant. 1. Section 5.2 is vague about how to compute signature types 0x30 and 0x40. The document should specify over what data to compute the hash to be signed. There was also a comment in the list archives about the description of signature type 0x18, which says This signature is calculated directly on the subkey itself, not on any User ID or other packets. This is tremendously misleading, since the signature is actually computed on a hash over a prefix, the key packet, the subkey packet, and a trailer. Section 5.2.4 gives a more detailed description of how to compute a subkey binding signature. 2. Section 5.2.4 contains another error. It states Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked. However, analysis of existing implementations indicates that this is incorrect for subkey revocation signatures (type 0x28); like type 0x18, both the primary key and the subkey are included in the hash. 3. Subpacket 23 (key server preferences) is specified to be "found only on a self-signature". It should say if that means a direct key signature (which makes the most sense to me), or something else. 4. The document is vague on what constitures "advisory information" in a signature subpacket (section 5.2.3). I believe that unhashed signature subpackets were a mistake (I can expound on this if people want). If existing implementations did not include unsigned subpackets, I would suggest removing them from the spec entirely. However, current implementations usually include the issuer key id subpacket (type 16) in the unhashed subpackets. Therefore, I suggest that implementations MUST NOT generate any unhashed subpackets, SHOULD accept type 16 unsigned subpackets in order to process existing signatures, and MUST NOT accept any other subpacket types in the unhashed subpackets. 5. There should be a note that the critical bit MUST be ignored on unhashed signature subpackets. Otherwise, an attacker can easily cause any signature to fail to verify. 6. The terms used in 11.1 are inconsistent with the rest of the document, and in some places, the rest of the document is also inconsistent. Where 11.1 uses "revocation self signature", the rest of the document uses "key revocation signature". Where 11.1 uses "direct key self signature", the rest of the document uses "direct key signature", "direct-key signature", and "Signature directly on a key". Where 11.1 uses "binding-signature-revocation", the rest of the document uses "subkey revocation signature". Where 11.1 uses primary-key-binding-signature", the rest of the document uses "subkey binding signature". Marc Received: by ns.secondary.com (8.9.3/8.9.3) id LAA18184 for ietf-openpgp-bks; Fri, 1 Dec 2000 11:04:10 -0800 (PST) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA18179 for ; Fri, 1 Dec 2000 11:04:06 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA55564 for ; Fri, 1 Dec 2000 13:38:02 -0500 (EST) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id OAA07013 for ; Fri, 1 Dec 2000 14:05:09 -0500 (EST) Message-ID: <001201c05bc9$82930080$66c52609@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: Encoding of hash in El-Gamal signatures Date: Fri, 1 Dec 2000 14:04:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- The specification already mentions precautions in ElGamal signature handling, and provides a reference. The original question is still valid, though, and I'd also be interested in seeing clarification. If the specification includes ElGamal signatures, it should provide sufficient definition to achieve interoperability. For other algorithms, there is a discussion of how the hash is padded (where applicable) and what the algorithm-specific fields in the signature should be. One might guess that the same PKCS-1 padding scheme should be used, and that the MPIs should be the "r" (=g^k mod p) and "s" (=(h-r*x)/k mod p) values, in that order. Is that right? Yes, I could use the GnuPG source as the specification, but that shouldn't be necessary. If you want to argue that OpenPGP shouldn't support this algorithm, and that it should be removed from the specification entirely, I wouldn't object. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQEVAwUBOif2F2NDnIII+QUHAQF+PAf8DkebuHLUbNgHWtZv6r0vDTnnqxjZAEv6 B6UGtwa1llicCQUED+K5kfQDM4O4hi+GDfvrnnEhsmy7j2V2hBPwS0hWm6dnlmQF I08MGLL6ZikTu6OZwMc9eQi7vlce7ZfWqSQc97T7muhq7oXQu66gYEN3AoaH600L 9xY9BF3NzogIsK74/UYWTFlshjRwtDyh4ycShoEk3CQPYoS0UBgWjxLbZcehup3w T3plyY8GKD/z9BIakfvubkRp5V2t+onvjFj8pojqjqNSibv8izvuCOkBBePGBt+l WNkbs97K7XzDNOF1Dh1unhbX6I7ZlBi5fZ+Vebzl3bx3m6eCGKnVPg== =2FiL -----END PGP SIGNATURE-----