From owner-ietf-openpgp@mail.imc.org Fri Oct 3 16:09:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24520 for ; Fri, 3 Oct 2003 16:09:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93JfbKP040364 for ; Fri, 3 Oct 2003 12:41:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93Jfa4O040363 for ietf-openpgp-bks; Fri, 3 Oct 2003 12:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.safe-mail.net (tapuz.safe-mail.net [212.68.149.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93JfYKP040357 for ; Fri, 3 Oct 2003 12:41:35 -0700 (PDT) (envelope-from poiboy@SAFe-mail.net) Received: from poiboy@SAFe-mail.net by www.safe-mail.net with SAFe-mail (Exim 4.20) id 1A5Vnt-0003Mx-FD for ietf-openpgp@imc.org; Fri, 03 Oct 2003 21:41:29 +0200 Received: from pc ([24.25.248.53]) by mail.SAFe-mail.net Subject: 3rd-party Signatures in a One-Pass Signed Message Date: Fri, 3 Oct 2003 18:41:29 +0000 From: poiboy@SAFe-mail.net To: ietf-openpgp@imc.org X-SMType: Regular X-SMRef: N1-OxansrD- Message-Id: MIME-Version: 1.0 Content-Type: text/plain 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, My assumption: A 3rd-party signature (0x50) is/must be detached and its handling is implementation-specific. * 10.2 does not recognize a sequence of signature packets as a valid message, and 5.2.1 states that the 3rd-party signature is made over such a sequence. * See Mr. Shaw's previous posts (including example sigs, below). I'd like to work with 3rd-party signatures in a bona-fide (standard, accepted) message context. This is handled in one case.. Put the signed key sequence in a literal data packet. This buys message-parsing convenience at the expense of requiring a literal parser to sneak a peek at the "data that is not to be further interpreted." (5.9) ..and could be handled in at least a couple other ways: Accept single (standalone/detached) signature packets as a third type of Signed Message :- Signature Packet | Signature Packet, OpenPGP Message | One-Pass Signed Message. I don't like this because there are a number of signatures (0x10-13, 0x18, ..) which really don't make sense on their own and I don't think that message definitions should start digging into packet body attributes (in this case, the signature type). -or- Add an option to the One-Pass "nested" flag which means "this signature is applied to the signatures on the same level as the next." The nested flag ('n') is only defined for n=0, leaving other n values up to the imagination. In practice, the signature directly bordering the signed message is given n=1 ..effectively stating "this next thing is in my signed nest." I'd like to use an n=2 (n=x, whatever) option declaring "this next thing is in my signed /signature/ nest" - a statement which remains true for all one-pass signatures up to (and including) the one-pass packet with n=1: 1PASS_N(n=2), 1PASS_A(n=0), 1PASS_B(n=1), MSG, SIG_B, SIG_A, SIG_N A and B have independently signed MSG, and N signs the combination SIG_B + SIG_A. The 3rd-party signature needs only the signature sequence (SIG_B, SIG_A) at creation time *but can later be represented* in what amounts to a complete message "history." This method has an "explicit advantage" over hiding signature sequences in literal packets. Thoughts? Kudos? Tomatoes? Aloha, poiboy at safe-mail.net ref: http://www.imc.org/ietf-openpgp/mail-archive/msg04135.html http://www.imc.org/ietf-openpgp/mail-archive/msg04385.html From subs-reminder@imc.org Mon Oct 6 23:48:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA04269 for ; Mon, 6 Oct 2003 23:48:12 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h973mIKP007632 for ; Mon, 6 Oct 2003 20:48:18 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h973mIVV007631; Mon, 6 Oct 2003 20:48:18 -0700 (PDT) Date: Mon, 6 Oct 2003 20:48:18 -0700 (PDT) Message-Id: <200310070348.h973mIVV007631@above.proper.com> To: openpgp-archive@ietf.org Subject: [[669360621]] Subscription to ietf-openpgp for openpgp-archive@lists.ietf.org Greetings. This message is a periodic reminder that openpgp-archive@lists.ietf.org is subscribed to the ietf-openpgp mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openpgp mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openpgp-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "openpgp-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openpgp@mail.imc.org Tue Oct 21 14:20:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29040 for ; Tue, 21 Oct 2003 14:20:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHnYI7033314 for ; Tue, 21 Oct 2003 10:49:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LHnYwi033313 for ietf-openpgp-bks; Tue, 21 Oct 2003 10:49:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHnUI7033303 for ; Tue, 21 Oct 2003 10:49:33 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9LHnVD27292 for ietf-openpgp@imc.org; Tue, 21 Oct 2003 13:49:31 -0400 Date: Tue, 21 Oct 2003 13:49:31 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: 3rd-party Signatures in a One-Pass Signed Message Message-ID: <20031021174931.GA27199@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Crescent (19% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Oct 03, 2003 at 06:41:29PM +0000, poiboy@SAFe-mail.net wrote: > > Hello all, > > My assumption: A 3rd-party signature (0x50) is/must be detached and > its handling is implementation-specific. It is true there is currently no language in the draft specifying how a 0x50 3rd-party or notary signature is handled, but I worry about the complexity of the proposed solution (extending the onepass functionality). When I suggested using a signature-in-a-subpacket to handle the need for a back-signature from a signing subkey to a main key, I mentioned that this basic idea could be useful in other places. 0x50 signatures seem to be a good place to use it: rather than extending onepass or parsing literal packets (which violate the idea of a *literal* packet), how about just putting the 0x50 signature as an unhashed subpacket on the signature that that the 0x50 signature covers? This gives a good bit of flexibility - it's clear which signature is being "notarized", and you can trivially generate notary sigs of notary sigs of notary sigs as many levels as you care to, AND it shouldn't affect any currently deployed code. David From owner-ietf-openpgp@mail.imc.org Tue Oct 21 16:49:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08211 for ; Tue, 21 Oct 2003 16:49:19 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKOWI7038925 for ; Tue, 21 Oct 2003 13:24:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LKOWS3038923 for ietf-openpgp-bks; Tue, 21 Oct 2003 13:24:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKOUI7038904 for ; Tue, 21 Oct 2003 13:24:31 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9LKORG05943 for ietf-openpgp@imc.org; Tue, 21 Oct 2003 16:24:27 -0400 Date: Tue, 21 Oct 2003 16:24:27 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Non-textual User IDs Message-ID: <20031021202427.GA5621@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Crescent (18% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 2440 defines a User ID (section 5.11) as: A User ID packet consists of data that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 822 mail name, but there are no restrictions on its content. The packet length in the header specifies the length of the user id. If it is text, it is encoded in UTF-8. The various 2440bis drafts keep this same text. Suggestion: change the current specification of contents (which is mostly unspecified) to UTF8 text only. Rationale: The current language was written before the OpenPGP standard got attribute IDs. Attribute IDs are a significantly better way to incorporate arbitrary binary blobs into user IDs. A simple way to look at this is to note that any user ID that isn't UTF8 text is going to be implementation-dependent. Since it is implementation dependent anyway, implementors may as well use attribute packets which won't gum up the programs (all OpenPGP programs I've seen) that more or less do expect user IDs to be text. Suggested language: A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 822 mail name, but there are no restrictions on its content. The packet length in the header specifies the length of the user id. David From owner-ietf-openpgp@mail.imc.org Fri Oct 24 13:20:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18900 for ; Fri, 24 Oct 2003 13:20:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGsAI7087137 for ; Fri, 24 Oct 2003 09:54:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OGsA8s087136 for ietf-openpgp-bks; Fri, 24 Oct 2003 09:54:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGs0I7087129 for ; Fri, 24 Oct 2003 09:54:00 -0700 (PDT) (envelope-from jwn2@qualcomm.com) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OGqG4t008303; Fri, 24 Oct 2003 09:52:16 -0700 (PDT) Received: from [129.46.76.119] (valinor.qualcomm.com [129.46.76.119]) by mage.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id h9OGq9E4016570; Fri, 24 Oct 2003 09:52:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200310230940.LAA20266@TR-Sys.de> References: <200310230940.LAA20266@TR-Sys.de> X-Mailer: eudora61carbon-1023030837 X-Esp-OSX: 0924030905 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 24 Oct 2003 09:48:24 -0700 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: "John W. Noerenberg II" Subject: Re: RFC 3156, status of RFC 2015 Cc: rfc-editor@rfc-editor.org, ddt@openpgp.org, Michael_Elkins@nai.com, raph@acm.org, roessler@does-not-exist.org, OpenPGP mailing list 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 11:40 AM +0200 10/23/03, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >studying the [Open]PGP RFCs, I found a distracting situation >concerning the status of these RFCs: Regarding 3156 and 2015, marking 2015 as Historic and obsoleted by 3156, and similarly, marking 3156 as obsoleting 2015 is a reasonable action. To be honest, I don't know if the IESG is required to recommend this action or if the RFC Editor can make this change at the WG's request (which I've made on behalf of the WG). In the past, Proposed RFCs that have been superceded by later RFCs linger as Proposed indefinitely instead of becoming Historic. For the sake of clarity your suggestion of marking 2015 as Historic is a good one, which is why I've requested the change. However, the common culture in the IETF is that a Proposed RFC which is obsolete is no longer relevant, so it's status on standards track is relatively harmless. 2440 does pay homage to 1991 in its text, but because 1991 is an Informational RFC and was never standards track, there's nothing for 2440 to obsolete. -- john noerenberg ---------------------------------------------------------------------- A good traveller has no fixed plans and is not intent on arriving. -- Lao Tzu (c. 570-490 B.C.) ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Fri Oct 24 13:25:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19098 for ; Fri, 24 Oct 2003 13:25:30 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGqDI7087079 for ; Fri, 24 Oct 2003 09:52:13 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OGqDlC087078 for ietf-openpgp-bks; Fri, 24 Oct 2003 09:52:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGqCI7087072 for ; Fri, 24 Oct 2003 09:52:12 -0700 (PDT) (envelope-from jwn2@qualcomm.com) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OGqC4t008296 for ; Fri, 24 Oct 2003 09:52:12 -0700 (PDT) Received: from [129.46.76.119] (valinor.qualcomm.com [129.46.76.119]) by mage.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id h9OGq9E2016570 for ; Fri, 24 Oct 2003 09:52:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: X-Mailer: eudora61carbon-1023030837 X-Esp-OSX: 0924030905 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 24 Oct 2003 09:46:15 -0700 To: OpenPGP mailing list From: "John W. Noerenberg II" Subject: Fwd: RFC 3156, status of RFC 2015 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9OGqCI7087074 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit >From: Alfred =?hp-roman8?B?SM5uZXM=?= >Subject: RFC 3156, status of RFC 2015 >To: jwn2@qualcomm.com, rfc-editor@rfc-editor.org >Date: Thu, 23 Oct 2003 11:40:03 +0200 (MESZ) >Cc: ddt@openpgp.org, Michael_Elkins@nai.com, raph@acm.org, > roessler@does-not-exist.org >X-Mailer: ELM [$Revision: 1.17.214.3 $] >Mime-Version: 1.0 > >studying the [Open]PGP RFCs, I found a distracting situation >concerning the status of these RFCs: > >RFC 3156 is a complete re-write and update of RFC 2015, hence it >effectively "obsoletes" RFC 2015. But, unfortunately, the header >of RFC 2015 states: "Updates: 2015", and not: "Obsoletes: 2015". >Consequentially, the RFC index, "rfc-index.txt", currently contains >the tags > (UPDATED BY 3156) for RFC 2015, and > (UPDATES 2015) for RFC 3156, >which effectively should be > (OBSOLETED BY 3156) for RFC 2015, and > (OBSOLETES 2015) for RFC 3156 . > >Moreover, RFC 2015 effectively makes *normative* reference to >RFC 1991, an INFORMATIONAL RFC. Therefore it should never have >been placed onto the RFC Standards Track and classified as a >PROPOSED STANDARD. > >RFC 1991 in turn actually has been obsoleted by RFC 2440 - another >fact which (unfortunately) was not stated in the header of RFC 2440. > >Obviously, the current proposed OpenPGP standard is specified >in RFC 2440 (Message formats) and RFC 3156 (application of MIME), >which both are PROPOSED STANDARDs. > >Therefore, RFC 2015 should now be removed from the standards >track and the PROPOSED STANDARDS section of "rfcxx00.txt" . > > >Please perform the necessary actions to resolve this situation. > >Best regards, > Alfred H‘nes. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ -- john noerenberg ---------------------------------------------------------------------- A good traveller has no fixed plans and is not intent on arriving. -- Lao Tzu (c. 570-490 B.C.) ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Fri Oct 24 19:01:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04919 for ; Fri, 24 Oct 2003 19:01:46 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OMWKI7098523 for ; Fri, 24 Oct 2003 15:32:20 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OMWKMK098522 for ietf-openpgp-bks; Fri, 24 Oct 2003 15:32:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OMWFI7098513 for ; Fri, 24 Oct 2003 15:32:16 -0700 (PDT) (envelope-from jwn2@qualcomm.com) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OMW34t028648; Fri, 24 Oct 2003 15:32:03 -0700 (PDT) Received: from [129.46.76.119] (valinor.qualcomm.com [129.46.76.119]) by mage.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id h9OMVuE2005197; Fri, 24 Oct 2003 15:31:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200310241638.JAA27692@gra.isi.edu> References: <200310241638.JAA27692@gra.isi.edu> X-Mailer: eudora61carbon-1023030837 X-Esp-OSX: 0924030905 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 24 Oct 2003 15:20:58 -0700 To: Bob Braden From: "John W. Noerenberg II" Subject: Re: Fwd: RFC 3156, status of RFC 2015 Cc: Derek Atkins , OpenPGP mailing list 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 9:38 AM -0700 10/24/03, Bob Braden wrote: >suppose a specification was >developed by an individual or organization outside the IETF process, >but published as an Informational RFC. That often happens, in fact. >Suppose that the IETF then takes this specification into the standards >track, resulting in publication of a new version of the spec as a >Proposed Standard. The PS will obsolete the Informational RFC. You raise a good point I hadn't considered. However, my original question is still unanswered: "Can the WG chair request the Editor amend 2440 with the note that it Obsoletes 1991?" Derek, I apologize for not doing so earlier, but I'll send you the note which originated this discussion. To show how out-of-touch I've become I didn't discover until today that you'd agreed to take on the job WG Chair after I asked to step down. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- A good traveller has no fixed plans and is not intent on arriving. -- Lao Tzu (c. 570-490 B.C.) ---------------------------------------------------------------------- From owner-ietf-openpgp@mail.imc.org Sat Oct 25 23:26:30 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23933 for ; Sat, 25 Oct 2003 23:26:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q2cRI7025108 for ; Sat, 25 Oct 2003 19:38:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q2cRtg025107 for ietf-openpgp-bks; Sat, 25 Oct 2003 19:38:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q2cQI7025102 for ; Sat, 25 Oct 2003 19:38:26 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9Q2cQxu003315; Sat, 25 Oct 2003 22:38:26 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9Q2cL9P002492; Sat, 25 Oct 2003 22:38:21 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9Q2cK0I007888; Sat, 25 Oct 2003 22:38:20 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h9Q2cJBp024438; Sat, 25 Oct 2003 22:38:19 -0400 (EDT) To: "John W. Noerenberg II" Cc: Bob Braden , OpenPGP mailing list From: Derek Atkins Subject: Re: Fwd: RFC 3156, status of RFC 2015 References: <200310241638.JAA27692@gra.isi.edu> Date: 25 Oct 2003 22:38:19 -0400 In-Reply-To: Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "John W. Noerenberg II" writes: > At 9:38 AM -0700 10/24/03, Bob Braden wrote: > >suppose a specification was > >developed by an individual or organization outside the IETF process, > >but published as an Informational RFC. That often happens, in fact. > >Suppose that the IETF then takes this specification into the standards > >track, resulting in publication of a new version of the spec as a > >Proposed Standard. The PS will obsolete the Informational RFC. > > You raise a good point I hadn't considered. However, my original > question is still unanswered: > > "Can the WG chair request the Editor amend 2440 with the note that it > Obsoletes 1991?" It's not worth our time to worry about 2440. We can add the text to 2440bis and do it then. Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the document header on the first page. > Derek, I apologize for not doing so earlier, but I'll send you the > note which originated this discussion. To show how out-of-touch I've > become I didn't discover until today that you'd agreed to take on the > job WG Chair after I asked to step down. No need for you to appologize, John. The person who should really be appologizing is Alfred who completely mis-addressed his original email. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Sat Oct 25 23:38:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24098 for ; Sat, 25 Oct 2003 23:38:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q2sYI7025836 for ; Sat, 25 Oct 2003 19:54:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q2sYoJ025835 for ietf-openpgp-bks; Sat, 25 Oct 2003 19:54:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q2sWI7025830 for ; Sat, 25 Oct 2003 19:54:32 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9Q2sYxu007243 for ; Sat, 25 Oct 2003 22:54:34 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9Q2sV9P002874 for ; Sat, 25 Oct 2003 22:54:31 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9Q2sU0I008017 for ; Sat, 25 Oct 2003 22:54:30 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h9Q2sUYv024470; Sat, 25 Oct 2003 22:54:30 -0400 (EDT) To: ietf-openpgp@imc.org Subject: Meeting in Minneapolis? From: Derek Atkins Date: 25 Oct 2003 22:54:30 -0400 Message-ID: Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry I've been remiss in my duties as Chair recently. I think we have enough topics to discuss to warrant a meeting in Minneapolis. I need to request a lot by noon on Tuesday, so let me know if I'm missing anything. Currently I think we have the following open issues from my reading of the mailing list: - Should we obsolete 1991? #219 - 3rd party signatures #220 - IDEA, v3-v4 algo. conflict #221 - non-text User IDs #222 - Need to update the charter (milestones) #29 Are there other open issues? Are there other PGP-related topics that people want to discuss in Minneapolis? Let me know ASAP so I can request a timeslot, and if you want to lead a discussion on some other topic, please let me know (e.g. pfs, etc.) I'd really like to get 2440bis completed, so that's my #1 priority. -derek PS: I've also been asked to start using RT (https://rt.psg.com) to track open issues. I'm still learning the system and I don't (yet) have a process in place to automatically enter new issues. But we'll see how it goes. -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Mon Oct 27 17:30:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22626 for ; Mon, 27 Oct 2003 17:30:47 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLqQI7076380 for ; Mon, 27 Oct 2003 13:52:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLqQRF076379 for ietf-openpgp-bks; Mon, 27 Oct 2003 13:52:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLqLI7076371 for ; Mon, 27 Oct 2003 13:52:21 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Mon, 27 Oct 2003 13:52:18 -0800 Received: from callas.org ([63.73.97.180]) by bletchley.merrymeet.com (PGP Universal service); Mon, 27 Oct 2003 13:52:20 -0800 Date: Mon, 27 Oct 2003 13:51:37 -0800 Subject: Re: Non-textual User IDs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-openpgp@imc.org To: David Shaw From: Jon Callas In-Reply-To: <20031021202427.GA5621@jabberwocky.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Tuesday, October 21, 2003, at 01:24 PM, David Shaw wrote: > A User ID packet consists of UTF-8 text that is intended to > represent the name and email address of the key holder. By > convention, it includes an RFC 822 mail name, but there are no > restrictions on its content. The packet length in the header > specifies the length of the user id. > In other words, just removing the line about if it is text.... Done. Jon From owner-ietf-openpgp@mail.imc.org Mon Oct 27 17:30:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22627 for ; Mon, 27 Oct 2003 17:30:48 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLuLI7076570 for ; Mon, 27 Oct 2003 13:56:21 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLuLqL076569 for ietf-openpgp-bks; Mon, 27 Oct 2003 13:56:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLuKI7076564 for ; Mon, 27 Oct 2003 13:56:20 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Mon, 27 Oct 2003 13:56:20 -0800 Received: from callas.org ([63.73.97.180]) by bletchley.merrymeet.com (PGP Universal service); Mon, 27 Oct 2003 13:56:21 -0800 Date: Mon, 27 Oct 2003 13:55:05 -0800 Subject: Re: RFC 3156, status of RFC 2015 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "John W. Noerenberg II" , Bob Braden , OpenPGP mailing list To: Derek Atkins From: Jon Callas In-Reply-To: Message-Id: <39505DF2-08C8-11D8-94B7-000A9568596C@callas.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, October 25, 2003, at 07:38 PM, Derek Atkins wrote: > Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the > document header on the first page. > Done. Jon From owner-ietf-openpgp@mail.imc.org Mon Oct 27 17:36:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23215 for ; Mon, 27 Oct 2003 17:36:17 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLxeI7076692 for ; Mon, 27 Oct 2003 13:59:40 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLxeUr076691 for ietf-openpgp-bks; Mon, 27 Oct 2003 13:59:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLxdI7076686 for ; Mon, 27 Oct 2003 13:59:39 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Mon, 27 Oct 2003 13:59:39 -0800 Received: from callas.org ([63.73.97.180]) by bletchley.merrymeet.com (PGP Universal service); Mon, 27 Oct 2003 13:59:40 -0800 Date: Mon, 27 Oct 2003 13:55:05 -0800 Subject: Re: RFC 3156, status of RFC 2015 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "John W. Noerenberg II" , Bob Braden , OpenPGP mailing list To: Derek Atkins From: Jon Callas In-Reply-To: Message-Id: <39505DF2-08C8-11D8-94B7-000A9568596C@callas.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, October 25, 2003, at 07:38 PM, Derek Atkins wrote: > Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the > document header on the first page. > Done. Jon From owner-ietf-openpgp@mail.imc.org Mon Oct 27 23:57:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09951 for ; Mon, 27 Oct 2003 23:57:07 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4TbI7091853 for ; Mon, 27 Oct 2003 20:29:37 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S4Tbqd091852 for ietf-openpgp-bks; Mon, 27 Oct 2003 20:29:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4TaI7091846 for ; Mon, 27 Oct 2003 20:29:36 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9S4TcS07682 for ietf-openpgp@imc.org; Mon, 27 Oct 2003 23:29:38 -0500 Date: Mon, 27 Oct 2003 23:29:38 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Meeting in Minneapolis? Message-ID: <20031028042938.GA4255@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (9% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Oct 25, 2003 at 10:54:30PM -0400, Derek Atkins wrote: > > Sorry I've been remiss in my duties as Chair recently. > > I think we have enough topics to discuss to warrant a meeting in > Minneapolis. I need to request a lot by noon on Tuesday, so let me > know if I'm missing anything. Currently I think we have the following > open issues from my reading of the mailing list: > > - Should we obsolete 1991? #219 > - 3rd party signatures #220 > - IDEA, v3-v4 algo. conflict #221 > - non-text User IDs #222 > - Need to update the charter (milestones) #29 > > Are there other open issues? Back-signatures from a signing subkey onto the primary key. David From owner-ietf-openpgp@mail.imc.org Tue Oct 28 11:45:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07168 for ; Tue, 28 Oct 2003 11:45:55 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGJwI7091752 for ; Tue, 28 Oct 2003 08:19:58 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SGJw0a091751 for ietf-openpgp-bks; Tue, 28 Oct 2003 08:19:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epost.de (mail.epost.de [193.28.100.187] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGJvI7091744 for ; Tue, 28 Oct 2003 08:19:57 -0800 (PST) (envelope-from mutz@kde.org) Received: from [212.144.7.36] (212.144.7.36) by mail.epost.de (6.7.015) (authenticated as Marc.Mutz@epost.de) id 3F8A95B9001CDAB1 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 17:19:54 +0100 From: Marc Mutz Organization: KDE To: ietf-openpgp@imc.org Subject: OpenPGP and IDNA/IMAA Date: Tue, 28 Oct 2003 17:07:59 +0100 User-Agent: KMail/1.5.93 X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_5Rpn/gghVJkmQy/"; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200310281708.26191@mail.marc-mutz.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_5Rpn/gghVJkmQy/ Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! After getting IDNA (internationalized domain names in applications) out=20 as RFCs, people are now looking at the local-part of email addresses. How is the relevant to the OpenPGP spec? OpenPGP UIDs are essentially free-form, but with the Name (Comment) convention for interop. The whole string is in utf-8. This opens up two possible ways to encode=20 a IDN (or an internationalized email address later) in the UID: 1. In ACE form (ASCII compatible encoding) 2. In UTF-8 The ACE form (obtained from the Unicode form by IDNA's ToAscii=20 transformtion) would look a bit silly given that the slot is=20 Unicode-aware, but it would work out of the box if you enter it in=20 encoded form. The UTF-8 form might or might not work, depending on whether the=20 software used to create the key would validate the address according to=20 rfc 2822 or 2821 or simply encode the whole thing in UTF-8. In any case, I think that rfc 2440bis as an IETF protocol that uses=20 UTF-8 needs to include at least a stringprep profile to use. I'm no=20 IETF expert, though, and it may suffice to reuse whatever comes out of=20 IMAA, but that's still at least half a year away. If nothing is said and it's accepted as such, then the slot is=20 automatically an IDNA-unaware one, to be filled with the ACE form. Some pointers: 3454 Preparation of Internationalized Strings ("stringprep"). P. Hoffman, M. Blanchet. December 2002. (Format: TXT=3D138684 bytes) (Status: PROPOSED STANDARD) 3490 Internationalizing Domain Names in Applications (IDNA). P. Faltstrom, P. Hoffman, A. Costello. March 2003. (Format: TXT=3D51943 bytes) (Status: PROPOSED STANDARD) 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN). P. Hoffman, M. Blanchet. March 2003. (Format: TXT=3D10316=20 bytes) (Status: PROPOSED STANDARD) 3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. (Format: TXT=3D67439 bytes) (Status: PROPOSED STANDARD) And discussions on ietf-imaa@imc.org and ietf-822@imc.org. Marc =2D-=20 It has become fashionable in the post Cold War world to label opponents as terrorists [...]. By doing so, the authorities instill within society a culture of fear, leading people to accept that their rights (and the rights of others) be trampled on for the sake of the common good. In other words, it justifies the loss of privacy and a state of surveillance they would otherwise not accept. Both communism and fascism were examples of this technique used to perfection. -- John Horvath: The Internet: A Terrorist Network? Telepolis 2001/08/22 (#9350) --Boundary-02=_5Rpn/gghVJkmQy/ Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/npR53oWD+L2/6DgRApWlAKCGiroGqthi7THsyyag1vXwW80OmACfWD7T sTcJp7jPdjh5bdvXYzahzoE= =oPwC -----END PGP SIGNATURE----- --Boundary-02=_5Rpn/gghVJkmQy/-- From owner-ietf-openpgp@mail.imc.org Tue Oct 28 11:59:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07952 for ; Tue, 28 Oct 2003 11:59:28 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGZTI7092875 for ; Tue, 28 Oct 2003 08:35:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SGZTgN092874 for ietf-openpgp-bks; Tue, 28 Oct 2003 08:35:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGZRI7092869 for ; Tue, 28 Oct 2003 08:35:28 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9SGZSt07276 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 11:35:28 -0500 Date: Tue, 28 Oct 2003 11:35:28 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Back-signatures proposal Message-ID: <20031028163528.GA6792@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (14% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We had a fairly extensive discussion of back-signatures a few months back on this list. It seemed (at least to me) that we more or less came to an understanding as to a way to address the problem. I'm planning on writing up the solution more formally, but before I do so, I'd like a sanity check whether the problem and solution as I understand it agrees with the problem and solution as everyone else understands it. The problem: it is possible for an attacker to take a signing subkey from a victim's key and attach this signing subkey to the attacker's own key. The attacker does this by issuing a new binding signature on the subkey from his own primary key. The end result is that a signature issued by this signing subkey may be claimed to be from either the attacker or the victim. Proposed solution: have the signing subkey issue a signature on the primary key. This prevents the attacker stealing the victim's subkey since the attacker could not issue this signature. Any signing subkey without such a "back-signature" should be assumed to be suspect. The details: 1) Define a new type of signature subpacket that consists of a regular signature contained in a subpacket. 2) Define a new signature class (Hal suggested 0x19), that is defined as a subkey signature on a primary key. The hashing rules here are the same as a 0x1F signature - we hash the primary key, and issue a signature from the subkey over this hash. 3) At (sub)key generation time (or later, for existing keys) create this 0x19 signature and store it as a subpacket on the subkey binding signature. It does not matter whether it is a hashed subpacket or not. Some advantages: 1) Old signatures issued before this back-signature protection became available are automatically protected once the back-signature is added to a given key. 2) Storing the back-signature on the subkey binding signatures simplifies key maintenance. If a subkey is deleted, the back-signature does with it automatically, and the implementation doesn't have to search for and delete back-signatures elsewhere on the key. 3) Existing signing subkeys can easily have a back-signature added. It is not necessary to create new subkeys. 4) By storing the data as a signature subpacket (which are generally ignored if not recognized), we minimize the chance of compatibility problems with older implementations. Comments? David From owner-ietf-openpgp@mail.imc.org Tue Oct 28 17:24:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01610 for ; Tue, 28 Oct 2003 17:24:35 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLv2I7007068 for ; Tue, 28 Oct 2003 13:57:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLv2j5007067 for ietf-openpgp-bks; Tue, 28 Oct 2003 13:57:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLusI7007059 for ; Tue, 28 Oct 2003 13:57:01 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-197-43.transarc.ibm.com [9.38.197.43]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id QAA18194 for ; Tue, 28 Oct 2003 16:56:42 -0500 (EST) Message-ID: <3F9EE602.90809@the-youngs.org> Date: Tue, 28 Oct 2003 16:56:18 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal References: <20031028163528.GA6792@jabberwocky.com> In-Reply-To: <20031028163528.GA6792@jabberwocky.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I like the general proposal, for all of the reasons that David listed. My only question is about the encoding of the cross-signature subpacket contents. It could be anything from: a full Signature packet (including packet header); to, just the Signature packet contents; to, a leaner form with just the required fields (hash algorithm and signature MPIs), with the rest being assumed for the hash computation in order to reuse that. I could live with any of these, but I lean toward the middle one. We may uncover a need for subpackets in the cross-signature itself, but it's hard to imagine wanting to use a different packet type (as opposed to signature *version*), and the length is absolutely redundant. [Note that the signature computation hashes a canonical header, not the actual one.] If we do use a regular Signature packet (with or without header), then I'd like to see a recommendation on what subpackets it should contain. The usual rules don't apply: for example, the issuer is known. I don't see a *need* for any subpackets, even creation time (but I'm open to arguments). -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP57l6uc3iHYL8FknEQLpywCg9RM4ZmGdMwymtDmhRByKaMwywQMAn0Qf rnWryiBvTQJ0JA1huQQqCh81 =SW/6 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Oct 28 17:44:41 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03355 for ; Tue, 28 Oct 2003 17:44:40 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMFsI7008655 for ; Tue, 28 Oct 2003 14:15:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMFrZs008654 for ietf-openpgp-bks; Tue, 28 Oct 2003 14:15:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.safe-mail.net (tapuz.safe-mail.net [212.68.149.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMFqI7008649 for ; Tue, 28 Oct 2003 14:15:52 -0800 (PST) (envelope-from poiboy@SAFe-mail.net) Received: from poiboy@SAFe-mail.net by www.safe-mail.net with SAFe-mail (Exim 4.20) id 1AEc7w-0002Jb-Va; Tue, 28 Oct 2003 17:15:48 -0500 Received: from pc ([66.91.42.66]) by mail.SAFe-mail.net Subject: Re: 3rd-party Signatures in a One-Pass Signed Message Date: Tue, 28 Oct 2003 22:15:48 +0000 From: poiboy@SAFe-mail.net To: dshaw@jabberwocky.com CC: ietf-openpgp@imc.org X-SMType: Regular X-SMRef: N1-SvYWhTcM Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> how about just putting the 0x50 signature as an unhashed >> subpacket on the signature that that the 0x50 signature covers? My concern was over the ability to form an "explicitly notarized message." I'd prefer to distinguish a notarized document (meaning "that document whose signatures are collectively notarized") as such rather than determine the degree of notarized-ness using signature subpackets. But I think it's just a question of focus: When will the notarization of signatures deserve more attention (or priority in computation) than the signatures themselves? I'm imagining something like: 10,000 people sign a petition and a notary declares that these signatures were made prior to some deadline. - The notarization is (should be) inseperable from the signature list. - Hierarchical notarizations need target only the last notary packet. Where this special consideration is not deserved I agree that a more general mechanism (like signatures-in-subpackets) should be applied. >> you can trivially generate notary sigs of notary sigs of notary >> sigs as many levels as you care to, AND it shouldn't affect any >> currently deployed code. As I understand the mechanics of the signature-in-a-subpacket: Since a notarization of a [target] signature signs the target's packet body (irrespective of hashed or unhashed portions), the notarization-in-a-subpacket will (once settled) effectively sign everything around itself and must be removed from the packet body string before it can be verified (signatures-in-subpackets used for subkey bindings don't have this feature because the subpacketed signature did not target its own parent). If this is correct and multiple notarizations of a given target body do not happen sequentially using the same (evolving) target body string, then verification will require figuring out the state of the unhashed subpackets at the time the notarization in question was made - a trial and error loop over each permutation. Just wondering if this was to be taken in stride or if I've made a mistake. Mahalo for your suggestion, tha Poiboy PS. Off topic, out of scope, and by the way, it'd be nice to use 'v5' sigs which operate on whole packets no matter what, allowing one-pass notarizations to sign an unbroken string of target signature packets and simplifying 5.2.4. And I should add that my suggestion depends upon the 0x50 definition in 5.2.1 decscribing signatures on "signature packet(s)." Get rid of the '(s)' and wonders will cease. :) From owner-ietf-openpgp@mail.imc.org Tue Oct 28 17:58:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04388 for ; Tue, 28 Oct 2003 17:57:59 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMNuI7009095 for ; Tue, 28 Oct 2003 14:23:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMNuBJ009094 for ietf-openpgp-bks; Tue, 28 Oct 2003 14:23:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMNtI7009089 for ; Tue, 28 Oct 2003 14:23:55 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9SMNum19431 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 17:23:56 -0500 Date: Tue, 28 Oct 2003 17:23:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Back-signatures, part II Message-ID: <20031028222356.GA19100@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (16% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just checked over my notes about back-signatures, and there was a second proposal to solve the same problem. For completeness, here is the other proposal. To repeat the problem: it is possible for an attacker to take a signing subkey from a victim's key and attach this signing subkey to the attacker's own key. The attacker does this by issuing a new binding signature on the subkey from his own primary key. The end result is that a signature issued by this signing subkey may be claimed to be from either the attacker or the victim. Second proposed solution: on all signatures issued by a signing subkey, include a copy of the fingerprint of the primary key that "owns" this subkey. An attacker cannot issue signatures from the stolen subkey at all, so is foiled. The details: 1) Define a new type of signature subpacket that consists of a fingerprint. 2) Include it on all subkey signatures as a hashed subpacket. (It must be hashed to be effective). Comments: 1) Unlike the subkey-signs-primary key solution, old signatures issued before this back-signature protection became available are NOT automatically protected. 2) Like the other solution, this does not require generating a new subkey. 3) Like the other solution, this uses a signature subpacket so there should be no backward compatibility problems. 4) This is simpler than the other solution in several ways (less code to do it, for one, does not require the key to be modified and redistributed, for two). 5) This is likely to be faster than the other solution, as it only requires two signature verifications (the data in question plus the subkey binding signature) rather than three (the data in question, the subkey binding signature, and the back-signature). 6) It will no longer be possible to issue a v3 signature from a signing subkey. I don't see this as a major problem since the older programs that don't understand v4 signatures don't understand signatures from signing subkeys anyway. Comparing the two proposals seems to be a wash. Back-signatures are a bit slower, but protect existing signatures. Including a fingerprint is a bit faster, but does not protect existing signatures. Perhaps speed and simplicity should win out here. Speaking as someone who regularly uses a signing subkey, I don't particularly care if my old signatures are protected or not. I obviously can't speak for everyone using a signing subkey though. Again, comments welcome. David From owner-ietf-openpgp@mail.imc.org Tue Oct 28 18:00:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04560 for ; Tue, 28 Oct 2003 18:00:09 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMTrI7009386 for ; Tue, 28 Oct 2003 14:29:53 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMTr1e009385 for ietf-openpgp-bks; Tue, 28 Oct 2003 14:29:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMTqI7009380 for ; Tue, 28 Oct 2003 14:29:52 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9SMTsF19478 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 17:29:54 -0500 Date: Tue, 28 Oct 2003 17:29:54 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal Message-ID: <20031028222954.GB19100@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20031028163528.GA6792@jabberwocky.com> <3F9EE602.90809@the-youngs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9EE602.90809@the-youngs.org> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (16% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 28, 2003 at 04:56:18PM -0500, Michael Young wrote: > > I like the general proposal, for all of the reasons that David > listed. > > My only question is about the encoding of the cross-signature > subpacket contents. It could be anything from: > a full Signature packet (including packet header); to, > just the Signature packet contents; to, > a leaner form with just the required fields (hash algorithm > and signature MPIs), with the rest being assumed for the > hash computation in order to reuse that. > > I could live with any of these, but I lean toward the middle one. As do I, for reasons given below, as well as for reasons of simplicity. > If we do use a regular Signature packet (with or without header), > then I'd like to see a recommendation on what subpackets it should > contain. The usual rules don't apply: for example, the issuer is > known. I don't see a *need* for any subpackets, even creation time > (but I'm open to arguments). I think it really depends on what the signature-in-a-subpacket is being used for. For the back-signature, it probably doesn't need any subpackets. At the same time, it doesn't hurt to include them. Does it matter very much? I'd like to see the signature-in-a-subpacket used for other things like notary signatures. For that usage, the issuer and timestamp is relevant. David From owner-ietf-openpgp@mail.imc.org Tue Oct 28 18:12:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05855 for ; Tue, 28 Oct 2003 18:12:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMi0I7010021 for ; Tue, 28 Oct 2003 14:44:00 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMi0AI010020 for ietf-openpgp-bks; Tue, 28 Oct 2003 14:44:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMhxI7010015 for ; Tue, 28 Oct 2003 14:43:59 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9SMi0O19610; Tue, 28 Oct 2003 17:44:00 -0500 Date: Tue, 28 Oct 2003 17:44:00 -0500 From: David Shaw To: ietf-openpgp@imc.org Cc: poiboy@SAFe-mail.net Subject: Re: 3rd-party Signatures in a One-Pass Signed Message Message-ID: <20031028224400.GC19100@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org, poiboy@SAFe-mail.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (16% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 28, 2003 at 10:15:48PM +0000, poiboy@SAFe-mail.net wrote: > Since a notarization of a [target] signature signs the target's > packet body (irrespective of hashed or unhashed portions), the > notarization-in-a-subpacket will (once settled) effectively sign > everything around itself and must be removed from the packet body > string before it can be verified (signatures-in-subpackets used for > subkey bindings don't have this feature because the subpacketed > signature did not target its own parent). I had expected that a notarization would not include any of the unhashed data from the original signature. After all, that data is not part of the original signature. Looking at the problem with this in mind, the notary signature doesn't have to be removed before verification since (being located in the unhashed section of the original signature), it isn't really there in the first place. > If this is correct and multiple notarizations of a given target body > do not happen sequentially using the same (evolving) target body > string, then verification will require figuring out the state of the > unhashed subpackets at the time the notarization in question was made > - a trial and error loop over each permutation. Using the methodology above, multiple notarizations of a given target body all have the same target body. David From owner-ietf-openpgp@mail.imc.org Tue Oct 28 22:06:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17802 for ; Tue, 28 Oct 2003 22:06:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T2P2I7018718 for ; Tue, 28 Oct 2003 18:25:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T2P2tC018717 for ietf-openpgp-bks; Tue, 28 Oct 2003 18:25:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T2P1I7018712 for ; Tue, 28 Oct 2003 18:25:02 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Tue, 28 Oct 2003 18:25:00 -0800 Received: from callas.org ([12.129.245.249]) by bletchley.merrymeet.com (PGP Universal service); Tue, 28 Oct 2003 18:25:02 -0800 Date: Tue, 28 Oct 2003 18:25:01 -0800 Subject: Re: Meeting in Minneapolis? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Jon Callas To: OpenPGP Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <18FA135B-09B7-11D8-8107-000A9568596C@callas.org> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Saturday, October 25, 2003, at 07:54 PM, Derek Atkins wrote: > I think we have enough topics to discuss to warrant a meeting in > Minneapolis. I need to request a lot by noon on Tuesday, so let me > know if I'm missing anything. Currently I think we have the following > open issues from my reading of the mailing list: > > - Should we obsolete 1991? #219 > - 3rd party signatures #220 > - IDEA, v3-v4 algo. conflict #221 > - non-text User IDs #222 > - Need to update the charter (milestones) #29 > > Are there other open issues? Are there other PGP-related topics that > people want to discuss in Minneapolis? Let me know ASAP so I can > request a timeslot, and if you want to lead a discussion on some other > topic, please let me know (e.g. pfs, etc.) > > I'd really like to get 2440bis completed, so that's my #1 priority. > I won't be in Minneapolis. I stupidly thought the deadline for getting an I-D in was close of business Monday, and not 9am Monday, so I blew it. Sorry. If anyone wants to see the pre-pre-release -- I'll submit this Nov 10 -- send me email. Jon From owner-ietf-openpgp@mail.imc.org Tue Oct 28 22:58:14 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21967 for ; Tue, 28 Oct 2003 22:58:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3YpI7021461 for ; Tue, 28 Oct 2003 19:34:51 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3YpL3021460 for ietf-openpgp-bks; Tue, 28 Oct 2003 19:34:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta3.adelphia.net (mta3.adelphia.net [68.168.78.181]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3YoI7021453 for ; Tue, 28 Oct 2003 19:34:50 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org ([24.50.162.44]) by mta3.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031029033451.MJZM27221.mta3.adelphia.net@the-youngs.org> for ; Tue, 28 Oct 2003 22:34:51 -0500 Message-ID: <3F9F3539.5000407@the-youngs.org> Date: Tue, 28 Oct 2003 22:34:17 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II References: <20031028222356.GA19100@jabberwocky.com> In-Reply-To: <20031028222356.GA19100@jabberwocky.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't feel all that strongly about this -- in fact, I don't consider the problem all that serious in the first place -- but I do find the properties of the cross-signature subpacket solution more attractive. If I did care about someone claiming my signatures as their own, I think I would care about old signatures as well. Under the per-message scheme, if I cared about old signatures, I'd have to find all of those signatures *and the associated documents* in order to reissue them, and then I'd have to deal with disseminating them. User agents that keep a "key ring" will likely verify a cross-signature only once, at the same time that they verify the subkey binding signature. It need not be a per-message cost. The same is true for the storage and transmission of the extra material. Yes, the cost is higher for a one-time verification... I can live with that. Also, note that the specification already provides a "signer userId" subpacket that could be used to nearly the same effect as a "signer primary fingerprint" subpacket. As I recall, the very first proposal was to recommend/require the use of the existing "signer userId" subpacket. I would have no objection to defining both mechanisms, to account for differing user needs. If I were forced to choose only one, I'd take cross-signatures, as it adds more value beyond what we have now. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP581Gec3iHYL8FknEQKznwCgsEm4POcdbfmEFBuCceZRZizScPMAoJ5R hqISWew9KfD0m1/SLQOHnEtT =L15C -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Oct 28 23:13:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22542 for ; Tue, 28 Oct 2003 23:13:49 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3mWI7022045 for ; Tue, 28 Oct 2003 19:48:32 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3mWwY022044 for ietf-openpgp-bks; Tue, 28 Oct 2003 19:48:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3mUI7022037 for ; Tue, 28 Oct 2003 19:48:31 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org ([24.50.162.44]) by mta11.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031029034831.ZHLR3704.mta11.adelphia.net@the-youngs.org> for ; Tue, 28 Oct 2003 22:48:31 -0500 Message-ID: <3F9F386B.9060600@the-youngs.org> Date: Tue, 28 Oct 2003 22:47:55 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal References: <20031028163528.GA6792@jabberwocky.com> <3F9EE602.90809@the-youngs.org> <20031028222954.GB19100@jabberwocky.com> In-Reply-To: <20031028222954.GB19100@jabberwocky.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think it really depends on what the signature-in-a-subpacket is > being used for. For the back-signature, it probably doesn't need > any subpackets. At the same time, it doesn't hurt to include them. > Does it matter very much? Yes, I was referring specifically to subkey cross-signatures. Including subpackets, particularly issuerId, is just wasteful in this situation. (They're pretty wasteful on binding signatures, too; one might argue that they could help correct a shuffled packet sequence, but that's a stretch.) I'd like to see recommendations for each flavor of signature that reflect real needs. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP584Z+c3iHYL8FknEQIiPwCgm4A5qIQe4+rG/VEK8OLMy7Ee9FAAoNN9 4/c0+JUqyniYgrne5w8E/nTO =KIIn -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Oct 28 23:43:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23761 for ; Tue, 28 Oct 2003 23:43:52 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4IpI7023450 for ; Tue, 28 Oct 2003 20:18:51 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4IpLC023449 for ietf-openpgp-bks; Tue, 28 Oct 2003 20:18:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4InI7023444 for ; Tue, 28 Oct 2003 20:18:49 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-237-131.dsl.pltn13.pacbell.net [68.122.237.131]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h9T4IpA6004518; Tue, 28 Oct 2003 20:18:52 -0800 (PST) Message-Id: <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 20:18:50 -0800 To: David Shaw , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <20031028222356.GA19100@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:23 PM 10/28/2003 -0500, David Shaw wrote: >I just checked over my notes about back-signatures, and there was a >second proposal to solve the same problem. For completeness, here is >the other proposal. > >To repeat the problem: it is possible for an attacker to take a >signing subkey from a victim's key and attach this signing subkey to >the attacker's own key. The attacker does this by issuing a new >binding signature on the subkey from his own primary key. The end >result is that a signature issued by this signing subkey may be >claimed to be from either the attacker or the victim. Does this attack also work if the attacker issues a subkey binding signature on the victim's *primary* key, so as to claim signatures issued by this primary key? >Second proposed solution: on all signatures issued by a signing >subkey, include a copy of the fingerprint of the primary key that >"owns" this subkey. An attacker cannot issue signatures from the >stolen subkey at all, so is foiled. I don't want to re-confuse an issue you've just clarified, but here's a generalization of the second proposal that might be worth considering: You could include in *every* signature a subpacket that contains a hash of *all* enclosing context. By "enclosing context" I mean the key packet for the primary key, along with its self-signatures, and the key packet for the subkey as well (if the signing key is a subkey) along with the subkey binding signature. This would protect against the above attack, and some other manipulations, such as: - A naive user re-uses the same subkey under 2 different primary keys. Signatures performed by the subkey can't be confined to being under one or the other primary key. This problem can be easily avoided: just don't re-use keys, but that caveat would be unnecessary if signatures committed to their enclosing context. - Attacker generates a key that verifies a signature issued by someone else [1], then puts this key on a key server where a victim finds it, and assumes that since it verifies the signature correctly, it must belong to the originator of the message. There's caveats that make this attack hard, and not very useful [1]. Still, it could be avoided entirely if the key used to create a signature was hashed as input to the signature. - Attacker fiddles the timestamp in someone's primary-key packet, so that the key still verifies the signature correctly, but the sender appears to have a different fingerprint than he really does. These aren't a big deal, but it just seems a good principle, in general, for signatures to cover as much context as is needed to properly interpret them. Trevor [1] sci.crypt thread: Choosing key to verify someone else's sig? From owner-ietf-openpgp@mail.imc.org Tue Oct 28 23:58:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24306 for ; Tue, 28 Oct 2003 23:58:38 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4YuI7023971 for ; Tue, 28 Oct 2003 20:34:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4YudD023970 for ietf-openpgp-bks; Tue, 28 Oct 2003 20:34:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4YtI7023956 for ; Tue, 28 Oct 2003 20:34:55 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-237-131.dsl.pltn13.pacbell.net [68.122.237.131]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h9T4YvA6004907; Tue, 28 Oct 2003 20:34:57 -0800 (PST) Message-Id: <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 20:34:55 -0800 To: Michael Young , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <3F9F3539.5000407@the-youngs.org> References: <20031028222356.GA19100@jabberwocky.com> <20031028222356.GA19100@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:34 PM 10/28/2003 -0500, Michael Young wrote: [...] >Also, note that the specification already provides a "signer userId" >subpacket that could be used to nearly the same effect as a "signer >primary fingerprint" subpacket. I think that would prevent the version of this where the attacker tries to convince the verifier that the signed message came from his *name*. It wouldn't prevent the version where the attacker tries to convince the verifier that the signed message came from his *key*, which is what using a key fingerprint adds. Trevor From owner-ietf-openpgp@mail.imc.org Wed Oct 29 00:03:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24505 for ; Wed, 29 Oct 2003 00:03:42 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4l2I7024486 for ; Tue, 28 Oct 2003 20:47:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4l2uR024484 for ietf-openpgp-bks; Tue, 28 Oct 2003 20:47:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4l1I7024479 for ; Tue, 28 Oct 2003 20:47:01 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9T4l4H11593 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 23:47:04 -0500 Date: Tue, 28 Oct 2003 23:47:04 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal Message-ID: <20031029044704.GA20489@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20031028163528.GA6792@jabberwocky.com> <3F9EE602.90809@the-youngs.org> <20031028222954.GB19100@jabberwocky.com> <3F9F386B.9060600@the-youngs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <3F9F386B.9060600@the-youngs.org> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (17% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 28, 2003 at 10:47:55PM -0500, Michael Young wrote: > > > I think it really depends on what the signature-in-a-subpacket is > > being used for. For the back-signature, it probably doesn't need > > any subpackets. At the same time, it doesn't hurt to include them. > > Does it matter very much? > > Yes, I was referring specifically to subkey cross-signatures. > Including subpackets, particularly issuerId, is just wasteful > in this situation. (They're pretty wasteful on binding signatures, > too; one might argue that they could help correct a shuffled > packet sequence, but that's a stretch.) I'd like to see > recommendations for each flavor of signature that reflect > real needs. I think that is straying into overkill. If there is no security or protocol correctness issue at hand, just say nothing. Let's credit implementors with some ability to know which subpackets are useful for a given purpose. We don't need an RFC, written with no knowledge of the internal code of a given implementation, to proclaim that an issuer ID might not be necessary - especially since the presence of that same issuer ID harms nobody. Also, an issuer ID - at worst - is 14 bytes long. If you really want to save some space on keys, we should issue guidelines on how large a photo ID should be ;) David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+fRkgqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJiGYAoIncvQEOycutdXfAJh1jzbN4BxnFAKDR BFyge/Ra52CP7BKdFY4M5+pQPQ== =zuFN -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Oct 29 00:25:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25403 for ; Wed, 29 Oct 2003 00:25:52 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T52kI7025534 for ; Tue, 28 Oct 2003 21:02:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T52k01025533 for ietf-openpgp-bks; Tue, 28 Oct 2003 21:02:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T52iI7025528 for ; Tue, 28 Oct 2003 21:02:45 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9T52lE11796 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 00:02:47 -0500 Date: Wed, 29 Oct 2003 00:02:47 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031029050247.GA11625@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20031028222356.GA19100@jabberwocky.com> <3F9F3539.5000407@the-youngs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <3F9F3539.5000407@the-youngs.org> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (19% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 28, 2003 at 10:34:17PM -0500, Michael Young wrote: > > I don't feel all that strongly about this -- in fact, I don't > consider the problem all that serious in the first place -- but > I do find the properties of the cross-signature subpacket > solution more attractive. I think I do as well. I like that it handles old signatures, and I'm not yet convinced that the include-the-fingerprint covers all of the attacks that the back-signature does. > Also, note that the specification already provides a "signer userId" > subpacket that could be used to nearly the same effect as a "signer > primary fingerprint" subpacket. As I recall, the very first proposal > was to recommend/require the use of the existing "signer userId" > subpacket. Nearly the same effect, yes, but ultimately a different problem. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+fSfcqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJvzsAn1pGb8SPcWHssnbVQKncJRx+hlGFAKDd Kro5CviMXOZpFmfuy4xuQId8fw== =zgtR -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Oct 29 01:05:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26535 for ; Wed, 29 Oct 2003 01:05:13 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T5cxI7026675 for ; Tue, 28 Oct 2003 21:38:59 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T5cxHF026674 for ietf-openpgp-bks; Tue, 28 Oct 2003 21:38:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx1.cryptohill.net (ns1.cryptohill.net [24.244.145.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T5cwI7026669 for ; Tue, 28 Oct 2003 21:38:58 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id C8CFE69A81; Wed, 29 Oct 2003 00:39:00 -0500 (EST) Message-ID: <3F9F51B1.8E8356A4@systemics.com> Date: Wed, 29 Oct 2003 00:35:45 -0500 From: Ian Grigg Reply-To: iang@systemics.com X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Marc Mutz Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP and IDNA/IMAA References: <200310281708.26191@mail.marc-mutz.de> 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 Marc Mutz wrote: ... > OpenPGP UIDs are essentially free-form, Yes, this is one of the advantages of OpenPGP over other PKI contenders. It says nothing about how the UserIds are handled. Which means we are free to design the contents to suit our requirements. It's certainly a key benefit for my company's use. You can't pay enough money to get that sort of design feature! > but with the > Name (Comment) > convention for interop. > > The whole string is in utf-8. This opens up two possible ways to encode > a IDN (or an internationalized email address later) in the UID: > > 1. In ACE form (ASCII compatible encoding) > 2. In UTF-8 ... > In any case, I think that rfc 2440bis as an IETF protocol that uses > UTF-8 needs to include at least a stringprep profile to use. I'm no > IETF expert, though, and it may suffice to reuse whatever comes out of > IMAA, but that's still at least half a year away. > > If nothing is said and it's accepted as such, then the slot is > automatically an IDNA-unaware one, to be filled with the ACE form. I think the key word here is _convention_. If there was a desire to document that and other conventions more clearly, than an adjunct informational track RFC may be a better bet than putting it into the base RFC. That way, applications could be aware of the convention, but can happily know that any other form is also quite acceptable. iang From owner-ietf-openpgp@mail.imc.org Wed Oct 29 01:30:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27383 for ; Wed, 29 Oct 2003 01:30:12 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T5wXI7027480 for ; Tue, 28 Oct 2003 21:58:33 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T5wXDs027479 for ietf-openpgp-bks; Tue, 28 Oct 2003 21:58:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T5wWI7027469 for ; Tue, 28 Oct 2003 21:58:32 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9T5wXR12575; Wed, 29 Oct 2003 00:58:33 -0500 Date: Wed, 29 Oct 2003 00:58:33 -0500 From: David Shaw To: Trevor Perrin Cc: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031029055833.GB20489@jabberwocky.com> Mail-Followup-To: Trevor Perrin , ietf-openpgp@imc.org References: <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (17% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 28, 2003 at 08:18:50PM -0800, Trevor Perrin wrote: > > At 05:23 PM 10/28/2003 -0500, David Shaw wrote: > > >I just checked over my notes about back-signatures, and there was a > >second proposal to solve the same problem. For completeness, here is > >the other proposal. > > > >To repeat the problem: it is possible for an attacker to take a > >signing subkey from a victim's key and attach this signing subkey to > >the attacker's own key. The attacker does this by issuing a new > >binding signature on the subkey from his own primary key. The end > >result is that a signature issued by this signing subkey may be > >claimed to be from either the attacker or the victim. > > Does this attack also work if the attacker issues a subkey binding > signature on the victim's *primary* key, so as to claim signatures issued > by this primary key? You mean take the victim's primary signing key, transform it into a signing subkey and bind it to the attacker's primary key? Yes, the attack would still work, but either of the proposed fixes still prevents it. The back-signature fix prevents this flavor of the attack since the attacker still could not use the stolen key (be it primary or subkey), to issue the back-signature. The include-the-fingerprint fix prevents this flavor of the attack as well. Since the key is a primary, existing signatures from the key would not contain the fingerprint subpacket at all, and would therefore be suspect. There are four basic permutations of this attack: 1) Attacker steals a subkey and keeps it as a subkey. Either fix works here. 2) Attacker steals a primary and makes it into a subkey. Either fix works here. 3) Attacker steals a subkey and makes it into a primary. Neither fix is relevant here since the attacker would be unable to bind a user ID to such a primary key. Without a bound user ID, it would be difficult at best to get such a key trusted. 4) Attacker steals a primary and keeps it as a primary. Neither fix is relevant here either, for the same reason as #3. > >Second proposed solution: on all signatures issued by a signing > >subkey, include a copy of the fingerprint of the primary key that > >"owns" this subkey. An attacker cannot issue signatures from the > >stolen subkey at all, so is foiled. > > I don't want to re-confuse an issue you've just clarified, but here's a > generalization of the second proposal that might be worth considering: > > You could include in *every* signature a subpacket that contains a hash of > *all* enclosing context. By "enclosing context" I mean the key packet for > the primary key, along with its self-signatures, and the key packet for the > subkey as well (if the signing key is a subkey) along with the subkey > binding signature. > > This would protect against the above attack, and some other manipulations, > such as: > > - A naive user re-uses the same subkey under 2 different primary > keys. Signatures performed by the subkey can't be confined to being under > one or the other primary key. This problem can be easily avoided: just > don't re-use keys, but that caveat would be unnecessary if signatures > committed to their enclosing context. I don't see this as a problem, actually. So what if a user uses the same subkey under two different primaries? The user controls the subkey, and so can issue valid back-signatures (or fingerprint subpackets). The owner of a subkey can do what they like with it. > - Attacker generates a key that verifies a signature issued by someone > else [1], then puts this key on a key server where a victim finds it, and > assumes that since it verifies the signature correctly, it must belong to > the originator of the message. There's caveats that make this attack hard, > and not very useful [1]. Still, it could be avoided entirely if the key > used to create a signature was hashed as input to the signature. Hmm. I think I see where you are going with this, but isn't this sort of the same problem as the "stolen primary that is kept as a primary" above? I can steal a primary key and add a user ID and bribe someone to sign it (since I can't sign it myself of course). Just because I've constructed a key that can verify a signature doesn't mean that I issued that signature. Or forget computer trickery at all: I can just get myself a fake ID that says I am "Trevor Perrin" ;) > - Attacker fiddles the timestamp in someone's primary-key packet, so that > the key still verifies the signature correctly, but the sender appears to > have a different fingerprint than he really does. This would break all signatures on the key, including the self-signatures. I think that would give the attack away. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+fVwkqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJ0ioAni/Lsc020UT+NVctLArQCiOILEASAJwP Zag9klK/40ZIkJIpquahISa9Aw== =5Xdy -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Oct 29 02:19:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA14864 for ; Wed, 29 Oct 2003 02:19:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T6xVI7052871 for ; Tue, 28 Oct 2003 22:59:31 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T6xVDH052869 for ietf-openpgp-bks; Tue, 28 Oct 2003 22:59:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T6xUI7052851 for ; Tue, 28 Oct 2003 22:59:30 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-237-131.dsl.pltn13.pacbell.net [68.122.237.131]) by mtaw6.prodigy.net (8.12.9/8.12.3) with ESMTP id h9T6x79e026504; Tue, 28 Oct 2003 22:59:08 -0800 (PST) Message-Id: <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 22:59:31 -0800 To: David Shaw From: Trevor Perrin Subject: Re: Back-signatures, part II Cc: ietf-openpgp@imc.org In-Reply-To: <20031029055833.GB20489@jabberwocky.com> References: <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:58 AM 10/29/2003 -0500, David Shaw wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Tue, Oct 28, 2003 at 08:18:50PM -0800, Trevor Perrin wrote: > > > > At 05:23 PM 10/28/2003 -0500, David Shaw wrote: > > > > >I just checked over my notes about back-signatures, and there was a > > >second proposal to solve the same problem. For completeness, here is > > >the other proposal. > > > > > >To repeat the problem: it is possible for an attacker to take a > > >signing subkey from a victim's key and attach this signing subkey to > > >the attacker's own key. The attacker does this by issuing a new > > >binding signature on the subkey from his own primary key. The end > > >result is that a signature issued by this signing subkey may be > > >claimed to be from either the attacker or the victim. > > > > Does this attack also work if the attacker issues a subkey binding > > signature on the victim's *primary* key, so as to claim signatures issued > > by this primary key? > >You mean take the victim's primary signing key, transform it into a >signing subkey and bind it to the attacker's primary key? Yes, the >attack would still work, but either of the proposed fixes still >prevents it. [...] I think you're right. > > I don't want to re-confuse an issue you've just clarified, but here's a > > generalization of the second proposal that might be worth considering: > > > > You could include in *every* signature a subpacket that contains a hash of > > *all* enclosing context. By "enclosing context" I mean the key packet for > > the primary key, along with its self-signatures, and the key packet for > the > > subkey as well (if the signing key is a subkey) along with the subkey > > binding signature. > > > > This would protect against the above attack, and some other manipulations, > > such as: > > > > - A naive user re-uses the same subkey under 2 different primary > > keys. Signatures performed by the subkey can't be confined to being under > > one or the other primary key. This problem can be easily avoided: just > > don't re-use keys, but that caveat would be unnecessary if signatures > > committed to their enclosing context. > >I don't see this as a problem, actually. So what if a user uses the >same subkey under two different primaries? The user controls the >subkey, and so can issue valid back-signatures (or fingerprint >subpackets). The owner of a subkey can do what they like with it. The problem arises when the user signs a document with the subkey, and wants this signature to be under one of his particular primaries. Say he has Work and Personal primary keys. He signs something and wants to indicate that it's under his Work primary key. He could include the Signer's User ID in the signature, but what if both primaries have the same User ID? If every signature committed to all previous context, then the verifier could always recognize that this signature was performed under a particular primary key, so there wouldn't be ambiguous cases like this. > > - Attacker generates a key that verifies a signature issued by someone > > else [1], then puts this key on a key server where a victim finds it, and > > assumes that since it verifies the signature correctly, it must belong to > > the originator of the message. There's caveats that make this attack > hard, > > and not very useful [1]. Still, it could be avoided entirely if the key > > used to create a signature was hashed as input to the signature. > >Hmm. I think I see where you are going with this, but isn't this sort >of the same problem as the "stolen primary that is kept as a primary" >above? I can steal a primary key and add a user ID and bribe someone >to sign it (since I can't sign it myself of course). Just because >I've constructed a key that can verify a signature doesn't mean that I >issued that signature. You're right, and as long as users keep that in mind, they're safe. But there's the rub. It's unintuitive that you can generate a key that verifies someone else's signature. And when things are unintuitive, there's room for users to screw up. I.e.: a user who receives a signed message through some secure channel (say someone hands them a message on a floppy disk), might then retrieve a key through an *un*secure channel, and attempt to validate the key by verifying the message with it. You can say: the user screwed up, we can't help him. But if the signature covered the public key that produced it, then the user's naive assumption would be correct, and his behavior would be safe. The issuer key ID subpacket makes an attack hard, though, because the attacker would have to try ~ 2^64 trial keys that verify the signature, before discovering one that *also* has the right issuer key ID. But if the signature covered the public key with a full hash, an attack would be even harder. > Or forget computer trickery at all: I can just >get myself a fake ID that says I am "Trevor Perrin" ;) The trickery I'm envisioning is where a naive verifier tries to validate a key by using it to verify a message that was received over some secure channel. > > - Attacker fiddles the timestamp in someone's primary-key packet, so that > > the key still verifies the signature correctly, but the sender appears to > > have a different fingerprint than he really does. > >This would break all signatures on the key, including the >self-signatures. I think that would give the attack away. That's true. As long as primary keys have self-signatures, and verifiers are required to check them before doing anything else with the key, that stops this. Basically, I just like the idea of having signatures cover all relevant context. So I was trying to find some trickery that would justify doing this. The trickery isn't very good, but there's trickier people than me out there.. So I dunno, I'm not sure how to balance the costs and benefits here, I just wanted to toss this out. Trevor From owner-ietf-openpgp@mail.imc.org Wed Oct 29 12:26:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21742 for ; Wed, 29 Oct 2003 12:26:36 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TH6FkT029981 for ; Wed, 29 Oct 2003 09:06:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TH6EIF029980 for ietf-openpgp-bks; Wed, 29 Oct 2003 09:06:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TH6DkT029974 for ; Wed, 29 Oct 2003 09:06:13 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TH5LlP000820; Wed, 29 Oct 2003 12:06:09 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TH3Zak004285; Wed, 29 Oct 2003 12:03:35 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9TH3XEi002726; Wed, 29 Oct 2003 12:03:33 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h9TH3WZc003634; Wed, 29 Oct 2003 12:03:32 -0500 (EST) To: Jon Callas Cc: OpenPGP From: Derek Atkins Subject: Re: Meeting in Minneapolis? References: <18FA135B-09B7-11D8-8107-000A9568596C@callas.org> Date: 29 Oct 2003 12:03:32 -0500 In-Reply-To: <18FA135B-09B7-11D8-8107-000A9568596C@callas.org> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > I won't be in Minneapolis. > > I stupidly thought the deadline for getting an I-D in was close of > business Monday, and not 9am Monday, so I blew it. Sorry. Well, I missed the deadline to request a timeslot, too.. So we wont be meeting in MSP. HOWEVER I think we've been making a lot of progress on the doc here on the list so let's continue along the existing path. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Wed Oct 29 15:28:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04405 for ; Wed, 29 Oct 2003 15:28:38 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TK0BkT039897 for ; Wed, 29 Oct 2003 12:00:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TK0BrP039896 for ietf-openpgp-bks; Wed, 29 Oct 2003 12:00:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TK0AkT039891 for ; Wed, 29 Oct 2003 12:00:10 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Wed, 29 Oct 2003 12:00:10 -0800 Received: from callas.org ([209.75.30.238]) by bletchley.merrymeet.com (PGP Universal service); Wed, 29 Oct 2003 12:00:11 -0800 Date: Wed, 29 Oct 2003 12:00:08 -0800 Subject: Re: Meeting in Minneapolis? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: OpenPGP To: Derek Atkins From: Jon Callas In-Reply-To: Message-Id: <7F0B0CB4-0A4A-11D8-8107-000A9568596C@callas.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On Wednesday, October 29, 2003, at 09:03 AM, Derek Atkins wrote: > Well, I missed the deadline to request a timeslot, too.. So we wont be > meeting in MSP. HOWEVER I think we've been making a lot of progress > on the doc here on the list so let's continue along the existing path. > I think we can do that. Ideally, IETF working groups operate *completely* on the mailing lists. Alas, we do not live in an ideal world, and face-to-face meetings are desirable or necessary. However, this working group has been making progress for years without a meeting, and that, in my opinion, is not a bug, it's a feature. Jon From owner-ietf-openpgp@mail.imc.org Wed Oct 29 15:37:34 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04826 for ; Wed, 29 Oct 2003 15:37:34 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKD8kT041537 for ; Wed, 29 Oct 2003 12:13:08 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKD85Y041536 for ietf-openpgp-bks; Wed, 29 Oct 2003 12:13:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKD6kT041531 for ; Wed, 29 Oct 2003 12:13:07 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9TKD6Y22873; Wed, 29 Oct 2003 15:13:06 -0500 Date: Wed, 29 Oct 2003 15:13:06 -0500 From: David Shaw To: Trevor Perrin Cc: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031029201306.GA22497@jabberwocky.com> Mail-Followup-To: Trevor Perrin , ietf-openpgp@imc.org References: <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 28, 2003 at 10:59:31PM -0800, Trevor Perrin wrote: > >> - A naive user re-uses the same subkey under 2 different primary > >> keys. Signatures performed by the subkey can't be confined to > >> being under one or the other primary key. This problem can be > >> easily avoided: just don't re-use keys, but that caveat would be > >> unnecessary if signatures committed to their enclosing context. > > > >I don't see this as a problem, actually. So what if a user uses the > >same subkey under two different primaries? The user controls the > >subkey, and so can issue valid back-signatures (or fingerprint > >subpackets). The owner of a subkey can do what they like with it. > > The problem arises when the user signs a document with the subkey, and > wants this signature to be under one of his particular primaries. Say he > has Work and Personal primary keys. He signs something and wants to > indicate that it's under his Work primary key. A user can "legally" use the same subkey under two different primaries. I think this is more of a feature request than an attack. The include-the-primary-fingerprint fix for the original attack has a side effect that gives the information you want here, but I still don't think this is an attack on the system. > I.e.: a user who receives a signed message through some secure channel (say > someone hands them a message on a floppy disk), might then retrieve a key > through an *un*secure channel, and attempt to validate the key by verifying > the message with it. > > You can say: the user screwed up, we can't help him. But if the signature > covered the public key that produced it, then the user's naive assumption > would be correct, and his behavior would be safe. > > The issuer key ID subpacket makes an attack hard, though, because the > attacker would have to try ~ 2^64 trial keys that verify the signature, > before discovering one that *also* has the right issuer key ID. But if the > signature covered the public key with a full hash, an attack would be even > harder. Note that most implementations do not store the issuer key ID in the hashed portion of the signature. The issuer ID is thus not part of the signature. David From owner-ietf-openpgp@mail.imc.org Wed Oct 29 15:39:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04958 for ; Wed, 29 Oct 2003 15:39:16 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKK3kT041906 for ; Wed, 29 Oct 2003 12:20:03 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKK3Vd041905 for ietf-openpgp-bks; Wed, 29 Oct 2003 12:20:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKK2kT041900 for ; Wed, 29 Oct 2003 12:20:02 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TKK13k008879; Wed, 29 Oct 2003 15:20:01 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TKK16B005479; Wed, 29 Oct 2003 15:20:01 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9TKK0Ei013045; Wed, 29 Oct 2003 15:20:00 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h9TKJxb7004046; Wed, 29 Oct 2003 15:19:59 -0500 (EST) To: Jon Callas Cc: OpenPGP From: Derek Atkins Subject: Re: Meeting in Minneapolis? References: <7F0B0CB4-0A4A-11D8-8107-000A9568596C@callas.org> Date: 29 Oct 2003 15:19:59 -0500 In-Reply-To: <7F0B0CB4-0A4A-11D8-8107-000A9568596C@callas.org> Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > On Wednesday, October 29, 2003, at 09:03 AM, Derek Atkins wrote: > > > Well, I missed the deadline to request a timeslot, too.. So we wont be > > meeting in MSP. HOWEVER I think we've been making a lot of progress > > on the doc here on the list so let's continue along the existing path. > > I think we can do that. I have no objection.. We SHOULD have meetings periodically, if for no other reason that to get more people involved or at least knowledgable about what we're doing. > Ideally, IETF working groups operate *completely* on the mailing > lists. Alas, we do not live in an ideal world, and face-to-face > meetings are desirable or necessary. True. > However, this working group has been making progress for years without > a meeting, and that, in my opinion, is not a bug, it's a feature. Well, it's been making progress but still hasn't completed 2440bis. We should make that a top priority. > Jon -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Wed Oct 29 16:23:04 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06882 for ; Wed, 29 Oct 2003 16:23:03 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKxxkT044236 for ; Wed, 29 Oct 2003 12:59:59 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKxxeQ044235 for ietf-openpgp-bks; Wed, 29 Oct 2003 12:59:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKxwkT044230 for ; Wed, 29 Oct 2003 12:59:58 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9TKxx423245 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 15:59:59 -0500 Date: Wed, 29 Oct 2003 15:59:59 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Let's finish up 0x50 "notary" signatures Message-ID: <20031029205959.GB22497@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The current state of the 0x50 or notary signature is nearly, but not quite, completed. The main thing missing is a machine-readable transport of a signature and it's notarization. The current language in the draft is: 0x50: Third-Party Confirmation signature. This signature is a signature over some other OpenPGP signature packet(s). It is a notary seal on the signed data. A third-party signature SHOULD include Signature Target subpacket(s) to give easy identification. Note that we really do mean SHOULD. There are plausible uses for this (such a a blind party that only sees the signature, not the key nor source document) that cannot include a target subpacket. Two suggestions: 1) Do not include the unhashed data of the target signature when generating the notary signature. The unhashed data is not part of the original signature. 2) Define a signature-in-a-subpacket where notary signatures can be placed. This allows the notary signature to be attached (as an unhashed subpacket) to the signature that it notarizes, giving a simple and clean transport method. Any number of notary signatures can be attached to the original signature this way (up to the limit on the unhashed data section), and notary signatures may be easily nested (notarizing a notary signature) by placing a notary signature in the unhashed data section of another notary signature. A signature-in-a-subpacket is simply a signature subpacket that contains another signature. The packet headers are not included, but the signature is otherwise complete. Note that one of the possible solutions to the stolen subkey problem also involves signature-in-a-subpacket. This is a different use of the technique, and its use here is not relevant to the stolen subkey problem. David From owner-ietf-openpgp@mail.imc.org Wed Oct 29 16:51:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08826 for ; Wed, 29 Oct 2003 16:51:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLQkkT045526 for ; Wed, 29 Oct 2003 13:26:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLQkGc045525 for ietf-openpgp-bks; Wed, 29 Oct 2003 13:26:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLQikT045519 for ; Wed, 29 Oct 2003 13:26:45 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-196-20.transarc.ibm.com [9.38.196.220]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id QAA20041 for ; Wed, 29 Oct 2003 16:26:45 -0500 (EST) Message-ID: <3FA02ECB.4050303@the-youngs.org> Date: Wed, 29 Oct 2003 16:19:07 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal References: <20031028163528.GA6792@jabberwocky.com> <3F9EE602.90809@the-youngs.org> <20031028222954.GB19100@jabberwocky.com> <3F9F386B.9060600@the-youngs.org> <20031029044704.GA20489@jabberwocky.com> In-Reply-To: <20031029044704.GA20489@jabberwocky.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > On Tue, Oct 28, 2003 at 10:47:55PM -0500, Michael Young wrote: >>I'd like to see >>recommendations for each flavor of signature that reflect >>real needs. > > I think that is straying into overkill. If there is no security or > protocol correctness issue at hand, just say nothing. > > Let's credit implementors with some ability to know which > subpackets I apologize. Earlier drafts specified that creation time and issuer were mandatory subpackets. The current draft no longer carries that language (and is better for it). -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP6Auouc3iHYL8FknEQIKOwCgsYaSOfZtBUwUReM9XzjsGcg6c9gAnjFx MnuUjqxMPhthubAxBX04miFS =0wF+ -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Oct 29 16:55:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08962 for ; Wed, 29 Oct 2003 16:55:04 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLZ4kT045924 for ; Wed, 29 Oct 2003 13:35:04 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLZ43x045923 for ietf-openpgp-bks; Wed, 29 Oct 2003 13:35:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLZ3kT045909 for ; Wed, 29 Oct 2003 13:35:03 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-238-46.dsl.pltn13.pacbell.net [68.122.238.46]) by mta4.rcsntx.swbell.net (8.12.9/8.12.3) with ESMTP id h9TLYvNu020571; Wed, 29 Oct 2003 15:34:59 -0600 (CST) Message-Id: <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 29 Oct 2003 13:33:23 -0800 To: David Shaw From: Trevor Perrin Subject: Re: Back-signatures, part II Cc: ietf-openpgp@imc.org In-Reply-To: <20031029201306.GA22497@jabberwocky.com> References: <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 03:13 PM 10/29/2003 -0500, David Shaw wrote: >On Tue, Oct 28, 2003 at 10:59:31PM -0800, Trevor Perrin wrote: > > > >> - A naive user re-uses the same subkey under 2 different primary > > >> keys. Signatures performed by the subkey can't be confined to > > >> being under one or the other primary key. This problem can be > > >> easily avoided: just don't re-use keys, but that caveat would be > > >> unnecessary if signatures committed to their enclosing context. > > > > > >I don't see this as a problem, actually. So what if a user uses the > > >same subkey under two different primaries? The user controls the > > >subkey, and so can issue valid back-signatures (or fingerprint > > >subpackets). The owner of a subkey can do what they like with it. > > > > The problem arises when the user signs a document with the subkey, and > > wants this signature to be under one of his particular primaries. Say he > > has Work and Personal primary keys. He signs something and wants to > > indicate that it's under his Work primary key. > >A user can "legally" use the same subkey under two different >primaries. yeah, but if he does this, a verifier might assume that the signature was intended under one primary key, when it was really intended under another. > I think this is more of a feature request than an attack. It's only an attack if a bad guy can choose which primary key the signature appears to be under, in a way that tricks the verifier into treating the signature incorrectly. I believe signing subkeys are rare, re-use of signing subkeys is rarer, and re-using them in such a way that an attacker can do this trick, and accomplish something, is pretty unlikely. I'm just trying to point out ways in which signatures can be placed in different contexts than what the signer intended. I view that as the commonality that links these things together - if every signature had a subpacket that contained a hash of: - the key used to perform the signature - the primary key (if the signing key is a subkey) - any self-signatures on the primary key, and the binding signature on the subkey, then I'd feel re-assured that every signature was bound to all relevant context, and no manipulations such as - splicing someone else's key under your primary key, to claim their signatures - fiddling with which primary key a signature appears to be under - presenting a different key that happens to verify a signature would be possible. The one manipulation that *would* still be possible is presenting someone else's key under your primary key, when there's no signature by the victimized key present to give the lie to this. For that, some sort of additional back-signature is unavoidable. But these approaches could be combined - if the back-signature contains the sort of subpacket I'm talking about, that's enough to make it a back-signature. So I guess I'm saying *every* signature should be a back-signature, in that it covers the relevant primary key and sub-keys. But you could also add an extra back-signature just when sub-keys are present. >The include-the-primary-fingerprint fix for the original attack has a >side effect that gives the information you want here, but I still >don't think this is an attack on the system. > > > I.e.: a user who receives a signed message through some secure channel > (say > > someone hands them a message on a floppy disk), might then retrieve a key > > through an *un*secure channel, and attempt to validate the key by > verifying > > the message with it. > > > > You can say: the user screwed up, we can't help him. But if the signature > > covered the public key that produced it, then the user's naive assumption > > would be correct, and his behavior would be safe. > > > > The issuer key ID subpacket makes an attack hard, though, because the > > attacker would have to try ~ 2^64 trial keys that verify the signature, > > before discovering one that *also* has the right issuer key ID. But if > the > > signature covered the public key with a full hash, an attack would be even > > harder. > >Note that most implementations do not store the issuer key ID in the >hashed portion of the signature. The issuer ID is thus not part of >the signature. In the odd case I'm considering, the verifier gets the signed message through some secure channel - someone hands him a signed message on a floppy disk, for example. So even though the issuer key ID isn't part of the signature, an attacker who's trying to make a fake key that verifies the message, still has to match the issuer key ID. So that provides some measure of protection, but if the signing key was hashed as an input to the signature, that would provide even more. Trevor From owner-ietf-openpgp@mail.imc.org Wed Oct 29 17:22:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10781 for ; Wed, 29 Oct 2003 17:22:30 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwFkT046831 for ; Wed, 29 Oct 2003 13:58:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLwFLW046830 for ietf-openpgp-bks; Wed, 29 Oct 2003 13:58:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwEkT046824 for ; Wed, 29 Oct 2003 13:58:14 -0800 (PST) (envelope-from vedaal@hush.com) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.45]) by smtp3.hushmail.com (Postfix) with ESMTP id F13E610E73B for ; Wed, 29 Oct 2003 13:58:14 -0800 (PST) Received: from mailserver3.hushmail.com (localhost [127.0.0.1]) by mailserver3.hushmail.com (8.12.6/8.12.3) with ESMTP id h9TLwEvo005255 for ; Wed, 29 Oct 2003 13:58:14 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.6/8.12.3/Submit) id h9TLwEB9005254 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 13:58:14 -0800 (PST) Message-Id: <200310292158.h9TLwEB9005254@mailserver3.hushmail.com> Date: Wed, 29 Oct 2003 13:58:14 -0800 To: ietf-openpgp@imc.org Subject: Re: Let's finish up 0x50 "notary" signatures From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Oct 2003 12:59:59 -0800 David Shaw wrote: > >The current state of the 0x50 or notary signature is nearly, but >not >quite, completed. The main thing missing is a machine-readable >transport of a signature and it's notarization. > >The current language in the draft is: > > 0x50: Third-Party Confirmation signature. > > This signature is a signature over some other OpenPGP signature > packet(s). It is a notary seal on the signed data. A third- >party > signature SHOULD include Signature Target subpacket(s) to >give > easy identification. can this be extended to be used as notary signature directly on someone's public key? (it would not provide an independent timestamp to the actual signature of the key-holder, but might be able to eventually improve the web-of- trust) with Respect, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From owner-ietf-openpgp@mail.imc.org Wed Oct 29 17:34:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11600 for ; Wed, 29 Oct 2003 17:34:56 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TM4FkT047100 for ; Wed, 29 Oct 2003 14:04:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TM4F7M047099 for ietf-openpgp-bks; Wed, 29 Oct 2003 14:04:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TM4EkT047094 for ; Wed, 29 Oct 2003 14:04:14 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9TM4FN23916 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 17:04:15 -0500 Date: Wed, 29 Oct 2003 17:04:15 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031029220415.GC22497@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 29, 2003 at 01:33:23PM -0800, Trevor Perrin wrote: > >> The problem arises when the user signs a document with the subkey, and > >> wants this signature to be under one of his particular primaries. Say he > >> has Work and Personal primary keys. He signs something and wants to > >> indicate that it's under his Work primary key. > > > >A user can "legally" use the same subkey under two different > >primaries. > > yeah, but if he does this, a verifier might assume that the signature was > intended under one primary key, when it was really intended under another. > > > I think this is more of a feature request than an attack. > > It's only an attack if a bad guy can choose which primary key the signature > appears to be under, in a way that tricks the verifier into treating the > signature incorrectly. The user intentionally chose to use the same subkey in two places. The user intentionally issued the signature. The user shouldn't be surprised that either copy of the same key can verify that signature. If a user wants to be unambiguous as to which hat he was wearing when he issued the signature, he shouldn't use the same key everywhere. This is somewhat similar to a situation where a user has two user IDs on his key: "user at evilcompany.com" and "user at anonymouswhistleblowers.com". If the user sends out whistleblower information and signs it with that key, he shouldn't be surprised when he is fired... David From owner-ietf-openpgp@mail.imc.org Wed Oct 29 17:42:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11833 for ; Wed, 29 Oct 2003 17:42:26 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMPHkT048237 for ; Wed, 29 Oct 2003 14:25:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TMPHxR048236 for ietf-openpgp-bks; Wed, 29 Oct 2003 14:25:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMPGkT048229 for ; Wed, 29 Oct 2003 14:25:16 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9TMPHg24082 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 17:25:17 -0500 Date: Wed, 29 Oct 2003 17:25:17 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Let's finish up 0x50 "notary" signatures Message-ID: <20031029222517.GE22497@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200310292158.h9TLwEB9005254@mailserver3.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310292158.h9TLwEB9005254@mailserver3.hushmail.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 29, 2003 at 01:58:14PM -0800, vedaal@hush.com wrote: > can this be extended to be used as notary signature directly on someone's > public key? A notary can issue a notary signature on any signature, which includes key certifications. Placing the notary signature in a signature-in-a-subpacket on the unhashed area of the original signature would be an effective way of transporting the notary sig around with the key. David From owner-ietf-openpgp@mail.imc.org Wed Oct 29 17:49:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12006 for ; Wed, 29 Oct 2003 17:49:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMLDkT047949 for ; Wed, 29 Oct 2003 14:21:13 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TMLDnk047948 for ietf-openpgp-bks; Wed, 29 Oct 2003 14:21:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMLBkT047940 for ; Wed, 29 Oct 2003 14:21:12 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-196-20.transarc.ibm.com [9.38.196.220]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id RAA20112 for ; Wed, 29 Oct 2003 17:21:12 -0500 (EST) Message-ID: <3FA03A73.90304@the-youngs.org> Date: Wed, 29 Oct 2003 17:08:51 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II References: <20031028222356.GA19100@jabberwocky.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> In-Reply-To: <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trevor Perrin wrote: > At 10:34 PM 10/28/2003 -0500, Michael Young wrote: >> Also, note that the specification already provides a "signer >> userId" subpacket that could be used to nearly the same effect as >> a "signer primary fingerprint" subpacket. > > I think that would prevent the version of this where the attacker > tries to convince the verifier that the signed message came from > his *name*. In practice, I think it's far more interesting to claim that a particular real-world identity signed a document than a particular primary key. But I understand the difference -- that's why I said "nearly". Trevor Perrin wrote (in another message): > I don't want to re-confuse an issue you've just clarified, but > here's a generalization of the second proposal that might be worth > considering: > > You could include in *every* signature a subpacket that contains a > hash of *all* enclosing context. By "enclosing context" I mean > the key packet for the primary key, along with its > self-signatures, and the key packet for the subkey as well (if the > signing key is a subkey) along with the subkey binding signature. This would add yet another impediment to rewriting self-signatures (or binding signatures). To permit rewriting, you'd have to keep all past versions (and try each one at verification time) or copy that material into the signature. Very little of this "context" is relevant for most uses. For special needs, we have notation packets to carry arbitrary additional context. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP6Az6uc3iHYL8FknEQKTzACcCSmnT4PmJTTUrq8Qd+3moODXWXkAoPEk AmymFtI4xHJSl2Jj3/b/EqJy =kZ1K -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Oct 29 18:52:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15439 for ; Wed, 29 Oct 2003 18:52:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNHakT050885 for ; Wed, 29 Oct 2003 15:17:36 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNHZWl050884 for ietf-openpgp-bks; Wed, 29 Oct 2003 15:17:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNHYkT050879 for ; Wed, 29 Oct 2003 15:17:34 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-119-11.dsl.pltn13.pacbell.net [68.122.119.11]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id h9TNHAjp020257; Wed, 29 Oct 2003 15:17:10 -0800 (PST) Message-Id: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 29 Oct 2003 15:17:33 -0800 To: David Shaw , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <20031029220415.GC22497@jabberwocky.com> References: <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:04 PM 10/29/2003 -0500, David Shaw wrote: >On Wed, Oct 29, 2003 at 01:33:23PM -0800, Trevor Perrin wrote: > > > >> The problem arises when the user signs a document with the subkey, and > > >> wants this signature to be under one of his particular > primaries. Say he > > >> has Work and Personal primary keys. He signs something and wants to > > >> indicate that it's under his Work primary key. > > > > > >A user can "legally" use the same subkey under two different > > >primaries. > > > > yeah, but if he does this, a verifier might assume that the signature was > > intended under one primary key, when it was really intended under another. > > > > > I think this is more of a feature request than an attack. > > > > It's only an attack if a bad guy can choose which primary key the > signature > > appears to be under, in a way that tricks the verifier into treating the > > signature incorrectly. > >The user intentionally chose to use the same subkey in two places. >The user intentionally issued the signature. The user shouldn't be >surprised that either copy of the same key can verify that signature. >If a user wants to be unambiguous as to which hat he was wearing when >he issued the signature, he shouldn't use the same key everywhere. Yeah, this is easily avoided if you just don't re-use keys. It would also be avoided if the signature is calculated over the hat the user was wearing, when he issued the signature. Then you can re-use keys without fear that a verifying party will be confused or tricked about which copy of the key you signed with. >This is somewhat similar to a situation where a user has two user IDs >on his key: "user at evilcompany.com" and "user at >anonymouswhistleblowers.com". If the user sends out whistleblower >information and signs it with that key, he shouldn't be surprised when >he is fired... Anonymity throws a different spin on things. The case I was thinking of, where key re-use might occur, is in something like a smartcard, or a delegated signing server. This might have limited key storage, or it might not be able to generate new keys (not enough power, or not enough randomness). If different users share the device, they each might want to certify the device's subkey as belonging under their own primary key. The device would want to make sure each of it's signatures are attributable to the right primary key. If every signature is a back-signature, this is accomplished. Trevor From owner-ietf-openpgp@mail.imc.org Wed Oct 29 19:10:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16311 for ; Wed, 29 Oct 2003 19:10:10 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNimkT052540 for ; Wed, 29 Oct 2003 15:44:48 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNimOY052539 for ietf-openpgp-bks; Wed, 29 Oct 2003 15:44:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNilkT052534 for ; Wed, 29 Oct 2003 15:44:47 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-119-11.dsl.pltn13.pacbell.net [68.122.119.11]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id h9TNiNjp011242; Wed, 29 Oct 2003 15:44:23 -0800 (PST) Message-Id: <5.2.0.9.0.20031029152237.03a83420@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 29 Oct 2003 15:44:46 -0800 To: Michael Young , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <3FA03A73.90304@the-youngs.org> References: <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:08 PM 10/29/2003 -0500, Michael Young wrote: >Trevor Perrin wrote (in another message): > > I don't want to re-confuse an issue you've just clarified, but > > here's a generalization of the second proposal that might be worth > > considering: > > > > You could include in *every* signature a subpacket that contains a > > hash of *all* enclosing context. By "enclosing context" I mean > > the key packet for the primary key, along with its > > self-signatures, and the key packet for the subkey as well (if the > > signing key is a subkey) along with the subkey binding signature. > >This would add yet another impediment to rewriting self-signatures >(or binding signatures). To permit rewriting, you'd have to keep >all past versions (and try each one at verification time) or copy >that material into the signature. Good point - you'd only want to include context that won't get invalidated by re-issued signatures. So I guess we could change the proposal to only cover key packets, not signature packets, without losing too much: Proposal: Include in every signature a hashed subpacket that contains a hash of the relevant key packets. The relevant key packets are the primary key packet if the signing key is a primary key, or the primary key *and* subkey packets if the signing key is a subkey. This stops these 3 manipulations: - issuing a subkey signature to someone else's key, and claiming their signatures - changing the primary key that a signature performed by a re-used subkey belongs under - an attacker generating a new key that verifies someone else's signature Trevor From owner-ietf-openpgp@mail.imc.org Wed Oct 29 19:33:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16967 for ; Wed, 29 Oct 2003 19:33:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNqdkT053031 for ; Wed, 29 Oct 2003 15:52:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNqdIm053030 for ietf-openpgp-bks; Wed, 29 Oct 2003 15:52:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNqckT053022 for ; Wed, 29 Oct 2003 15:52:38 -0800 (PST) (envelope-from vedaal@hush.com) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.45]) by smtp3.hushmail.com (Postfix) with ESMTP id 42BE510E6A2 for ; Wed, 29 Oct 2003 15:52:39 -0800 (PST) Received: from mailserver3.hushmail.com (localhost [127.0.0.1]) by mailserver3.hushmail.com (8.12.6/8.12.3) with ESMTP id h9TNqcvo008950 for ; Wed, 29 Oct 2003 15:52:38 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.6/8.12.3/Submit) id h9TNqcRP008949 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 15:52:38 -0800 (PST) Message-Id: <200310292352.h9TNqcRP008949@mailserver3.hushmail.com> Date: Wed, 29 Oct 2003 15:52:38 -0800 To: ietf-openpgp@imc.org Subject: Re: Let's finish up 0x50 "notary" signatures From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Oct 2003 14:25:17 -0800 David Shaw wrote: >A notary can issue a notary signature on any signature, which includes >key certifications. Placing the notary signature in a >signature-in-a-subpacket on the unhashed area of the original >signature would be an effective way of transporting the notary sig >around with the key. could this be done in a way that existing implementations can just 'ignore' (i.e., not 'choke' on) the notary signature if it can't 'recognize' what it is, when importing a key with a notary signature on the self- signed sig of the key? vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From owner-ietf-openpgp@mail.imc.org Wed Oct 29 20:03:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA17877 for ; Wed, 29 Oct 2003 20:03:14 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U0bKkT055645 for ; Wed, 29 Oct 2003 16:37:20 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U0bKrU055644 for ietf-openpgp-bks; Wed, 29 Oct 2003 16:37:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U0bIkT055638 for ; Wed, 29 Oct 2003 16:37:19 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9U0bLh04279 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 19:37:21 -0500 Date: Wed, 29 Oct 2003 19:37:20 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Let's finish up 0x50 "notary" signatures Message-ID: <20031030003720.GA24888@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200310292352.h9TNqcRP008949@mailserver3.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200310292352.h9TNqcRP008949@mailserver3.hushmail.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (27% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Oct 29, 2003 at 03:52:38PM -0800, vedaal@hush.com wrote: > On Wed, 29 Oct 2003 14:25:17 -0800 David Shaw > wrote: > > >A notary can issue a notary signature on any signature, which includes > >key certifications. Placing the notary signature in a > >signature-in-a-subpacket on the unhashed area of the original > >signature would be an effective way of transporting the notary sig > >around with the key. > > could this be done in a way that existing implementations can just > 'ignore' (i.e., not 'choke' on) the notary signature if it can't > 'recognize' what it is, when importing a key with a notary signature > on the self- signed sig of the key? Yes, existing implementations should ignore and certainly not choke on any unrecognized signature subpacket. If the signer chooses to, they can set the "critical" flag, which requests that an implementation fail the signature verification for unrecognized signature subpackets, but at the same time, they don't have to. It's up to the signer what they want to happen. (It is a different issue altogether whether a critical bit on an *unhashed* subpacket should cause this to happen, though!) David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+gXUAqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJu2wAn1tgsAjREJuw9EMDe6mTGmwTmZb0AKCW d0F3ekMqwCMjmsCe8vNfixM0bQ== =01bo -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Oct 30 01:33:32 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27949 for ; Thu, 30 Oct 2003 01:33:32 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U67ckT073293 for ; Wed, 29 Oct 2003 22:07:38 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U67csH073292 for ietf-openpgp-bks; Wed, 29 Oct 2003 22:07:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.safe-mail.net (tapuz.safe-mail.net [212.68.149.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U67akT073266 for ; Wed, 29 Oct 2003 22:07:36 -0800 (PST) (envelope-from poiboy@SAFe-mail.net) Received: from poiboy@SAFe-mail.net by www.safe-mail.net with SAFe-mail (Exim 4.20) id 1AF5y0-00010o-Gg; Thu, 30 Oct 2003 01:07:32 -0500 Received: from pc ([66.91.42.66]) by mail.SAFe-mail.net Subject: Re: Let's finish up 0x50 "notary" signatures Date: Thu, 30 Oct 2003 06:07:32 +0000 From: poiboy@SAFe-mail.net To: dshaw@jabberwocky.com CC: ietf-openpgp@imc.org X-SMType: Regular X-SMRef: N1-GctKN-78 Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Casting a vote from the cheap seats, I think signatures-in-subpackets are an elegant option for 3rd-party signatures on single signatures. I suggest inserting the following (or something similar) to 5.2.4: > When a signature over a V4 signature is issued as a subpacket, the > body of hash data consists of the same data that the (parent) V4 > signature used to build its own hash, that is, the parent's version, > type, public key algorithm, hash algorithm, and hashed subpacket > material (length header and subpackets). and changing the beginning of the existing signature-on-a-signature paragraph in the same section to make it clear that different rules apply to "sub-signatures": < When a signature is made over a signature, the hash data.. --- > When a signature is issued over a signature packet, the hash data.. Rounding out thoughts on 0x50, Removing the canonical header replacement for external signing of signatures would make it easier to work with many notarized signatures. This probably steps on toes, though. The ability to construct nice (10.2) messages using multiple/nested 0x50 signatures on fixed signature data (I suggest adding functionality to the one-pass packet 'nest') would allow complete expression of 0x50 signatures per 5.2.1 (as opposed to keeping them detached or on a per-signature basis in subpackets). Additionally, I think the "signed and notarized document" deserves the same degree of clout (that only a bona fide message has) as a normal "signed document." Happy days, poiboy From owner-ietf-openpgp@mail.imc.org Thu Oct 30 03:48:33 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA14159 for ; Thu, 30 Oct 2003 03:48:32 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U8RBkT025944 for ; Thu, 30 Oct 2003 00:27:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U8RBIE025943 for ietf-openpgp-bks; Thu, 30 Oct 2003 00:27:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from onaras-pdc.onaras.local ([80.254.174.13]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9U8R9kT025563 for ; Thu, 30 Oct 2003 00:27:09 -0800 (PST) (envelope-from avbidder@fortytwo.ch) Received: (qmail 2773 invoked from network); 30 Oct 2003 08:25:53 -0000 Received: from bugs.onaras.local (192.168.0.63) by 192.168.0.222 with SMTP; 30 Oct 2003 08:25:53 -0000 From: Adrian von Bidder Organization: Onaras AG To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Date: Thu, 30 Oct 2003 09:25:52 +0100 User-Agent: KMail/1.5.4 References: <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> In-Reply-To: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_QsMo/zMRVZGt0Q5"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310300925.52523@fortytwo.ch> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_QsMo/zMRVZGt0Q5 Content-Type: text/plain; charset="iso-8859-1" Content-Description: signed data Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [no cc:s please] On Thursday 30 October 2003 00:17, Trevor Perrin wrote: [subkey signatures - embedding the primary to avoid misattribution] > The case I was thinking of, where key re-use might occur, is in something > like a smartcard, or a delegated signing server. This might have limited > key storage, or it might not be able to generate new keys (not enough > power, or not enough randomness). If different users share the device, > they each might want to certify the device's subkey as belonging under > their own primary key. > > The device would want to make sure each of it's signatures are attributab= le > to the right primary key. If every signature is a back-signature, this is > accomplished. The hash of the primary would be over the public key? So the holder of the= =20 secret subkey can make his subkey signature appear to come from whatever=20 primary he wants, he doesn't need the secret (primary) key. So, in your scenario, sharing the secret subkey will effectively mean that= =20 each can make signatures that will verify with the other's primary. Or do I misunderstand someting here? cheers =2D- vbi =2D-=20 featured product: vim - http://vim.org --Boundary-02=_QsMo/zMRVZGt0Q5 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iKcEABECAGcFAj+gyxBgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6L5AAoJGArtInwxevFaWcvlOCkKiP jm6NAJ4rSS+9B1TRtO8DA1mahhPvaZtCMg== =GTPv -----END PGP SIGNATURE----- --Boundary-02=_QsMo/zMRVZGt0Q5-- From owner-ietf-openpgp@mail.imc.org Thu Oct 30 11:08:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28607 for ; Thu, 30 Oct 2003 11:08:09 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFfUkT068563 for ; Thu, 30 Oct 2003 07:41:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UFfUDd068562 for ietf-openpgp-bks; Thu, 30 Oct 2003 07:41:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFfTkT068555 for ; Thu, 30 Oct 2003 07:41:30 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9UFfU223065 for ietf-openpgp@imc.org; Thu, 30 Oct 2003 10:41:30 -0500 Date: Thu, 30 Oct 2003 10:41:30 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Let's finish up 0x50 "notary" signatures Message-ID: <20031030154129.GC22729@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (33% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Oct 30, 2003 at 06:07:32AM +0000, poiboy@SAFe-mail.net wrote: > Removing the canonical header replacement for external signing of > signatures would make it easier to work with many notarized > signatures. This probably steps on toes, though. I wouldn't remove the canonical header for hashing the original signature. It would be inconsistent with all of the other hashing rules in the draft. The only thing that is necessary here is to specify that the unhashed data in the original signature is not included in the notary signature. Specifically, section 5.2.4 currently says: When a signature is made over a signature, the hash data starts with the octet 0x88, followed by the four-octet length of the signature, and then the body of the signature packet. (Note that this is an old-style packet header for a signature packet with the length-of-length set to zero). I would add a sentence between those two that reads something like: The unhashed subpacket data of the signature packet being hashed is not included in the hash, and the unhashed subpacket data length value is set to zero. The idea here is that the canonical form of a signature to be hashed has no unhashed subpacket data. This addresses your first comment as well. We don't need to specify what gets hashed into the notary signature, since it is clear that the entire target signature, minus its unhashed data, is hashed for the notary signature. David From owner-ietf-openpgp@mail.imc.org Thu Oct 30 14:22:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05491 for ; Thu, 30 Oct 2003 14:22:11 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIbTkT079505 for ; Thu, 30 Oct 2003 10:37:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UIbTx8079504 for ietf-openpgp-bks; Thu, 30 Oct 2003 10:37:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIbRkT079498 for ; Thu, 30 Oct 2003 10:37:28 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-193-42.dsl.pltn13.pacbell.net [68.122.193.42]) by mta4.rcsntx.swbell.net (8.12.10/8.12.10) with ESMTP id h9UIbKxj022484; Thu, 30 Oct 2003 12:37:21 -0600 (CST) Message-Id: <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 30 Oct 2003 10:37:18 -0800 To: Adrian von Bidder , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <200310300925.52523@fortytwo.ch> References: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:25 AM 10/30/2003 +0100, Adrian von Bidder wrote: > >On Thursday 30 October 2003 00:17, Trevor Perrin wrote: > >[subkey signatures - embedding the primary to avoid misattribution] > >> The case I was thinking of, where key re-use might occur, is in something >> like a smartcard, or a delegated signing server. This might have limited >> key storage, or it might not be able to generate new keys (not enough >> power, or not enough randomness). If different users share the device, >> they each might want to certify the device's subkey as belonging under >> their own primary key. >> >> The device would want to make sure each of it's signatures are >>attributable to the right primary key. If every signature is a >>back-signature, this is accomplished. > >The hash of the primary would be over the public key? So the holder of >the secret subkey can make his subkey signature appear to come from >whatever primary he wants, he doesn't need the secret (primary) key. He can make his subkey signature appear to come under any of the primary keys that have trusted him (i.e. any of the primary keys that have issued him a subkey binding signature). > >So, in your scenario, sharing the secret subkey will effectively mean >that each can make signatures that will verify with the other's primary. In my scenario, a bunch of different primary key holders trust a single subkey holder to perform signatures on their behalf. The subkey holder wants to make sure that each signature is attributed to the proper primary key. Maybe this is a use case that subkeys aren't intended to support. But if every signature covered the primary key and subkey it was produced under, this would work. Trevor From owner-ietf-openpgp@mail.imc.org Thu Oct 30 15:42:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10562 for ; Thu, 30 Oct 2003 15:42:08 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UKKGkT084608 for ; Thu, 30 Oct 2003 12:20:16 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UKKGUG084607 for ietf-openpgp-bks; Thu, 30 Oct 2003 12:20:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UKKEkT084602 for ; Thu, 30 Oct 2003 12:20:15 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9UKKGP25239 for ietf-openpgp@imc.org; Thu, 30 Oct 2003 15:20:16 -0500 Date: Thu, 30 Oct 2003 15:20:16 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031030202016.GA23324@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (34% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote: > In my scenario, a bunch of different primary key holders trust a > single subkey holder to perform signatures on their behalf. The > subkey holder wants to make sure that each signature is attributed > to the proper primary key. I'm having trouble seeing the lack of this ability as a problem, much less a problem that needs a fix. It's always possible to come up with a (perhaps convoluted) situation where any feature would be useful, and with all due respect, I think this scenario crosses the convolution line. Sharing signature keys is generally not a good idea. Note in the example that if the trusted subkey holder stops being trusted, he can issue signatures in the name of any of the users. Plus if any of the keyholders has a key compromise, all keyholders must re-key. If and when such a situation develops, I'd support a supplemental RFC to specify the necessary signature subpacket. Until the proposed scenario becomes more concrete, anything we can do about it in 2440bis is apt to be incorrect in some detail. In the meantime, I'm content to say if a user really wants to share keys, he can use a signature notation to include whatever additional information he lines. I don't think this needs to be in 2440bis. David From owner-ietf-openpgp@mail.imc.org Thu Oct 30 17:24:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17190 for ; Thu, 30 Oct 2003 17:24:18 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UM3kkT087922 for ; Thu, 30 Oct 2003 14:03:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UM3kQm087921 for ietf-openpgp-bks; Thu, 30 Oct 2003 14:03:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UM3ikT087916 for ; Thu, 30 Oct 2003 14:03:44 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (ppp-68-122-224-7.dsl.pltn13.pacbell.net [68.122.224.7]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id h9UM3J6q010836; Thu, 30 Oct 2003 14:03:20 -0800 (PST) Message-Id: <5.2.0.9.0.20031030131243.03a6bc38@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 30 Oct 2003 14:03:43 -0800 To: David Shaw , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <20031030202016.GA23324@jabberwocky.com> References: <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 03:20 PM 10/30/2003 -0500, David Shaw wrote: >On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote: > > > In my scenario, a bunch of different primary key holders trust a > > single subkey holder to perform signatures on their behalf. The > > subkey holder wants to make sure that each signature is attributed > > to the proper primary key. > >I'm having trouble seeing the lack of this ability as a problem, much >less a problem that needs a fix. > >It's always possible to come up with a (perhaps convoluted) situation >where any feature would be useful, and with all due respect, I think >this scenario crosses the convolution line. Fair enough. The more useful scenario I was thinking of is where a single primary key is held by a server, which issues short-lived subkeys to different users, so they don't have to bother keeping a primary key secure. But in that case, I think the "Signer's User ID" subpacket is sufficient to differentiate things. Trevor From owner-ietf-openpgp@mail.imc.org Fri Oct 31 11:34:37 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06362 for ; Fri, 31 Oct 2003 11:34:33 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGDikT096467 for ; Fri, 31 Oct 2003 08:13:44 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VGDhNh096466 for ietf-openpgp-bks; Fri, 31 Oct 2003 08:13:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGDekT096456 for ; Fri, 31 Oct 2003 08:13:41 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-196-20.transarc.ibm.com [9.38.196.220]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id LAA22909 for ; Fri, 31 Oct 2003 11:13:21 -0500 (EST) Message-ID: <3FA289F7.20802@the-youngs.org> Date: Fri, 31 Oct 2003 11:12:39 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II References: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> <20031030202016.GA23324@jabberwocky.com> In-Reply-To: <20031030202016.GA23324@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote: >In my scenario, a bunch of different primary key holders trust a >single subkey holder to perform signatures on their behalf. The >subkey holder wants to make sure that each signature is attributed >to the proper primary key. I'd love to have a better framework for publicly expressing trust relationships, but I really don't think this was one of the intended uses of subkeys. [Given where the RFC stands, I think that trust expresion would best be addressed by a new, adjunct RFC.] -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP6KJuOc3iHYL8FknEQLnGwCgrEKS8MGYy1yC1+MM9LnJSLw4lI4Anj7q QkcRcd1BHP6lLO5XpYlsom6U =OIIz -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Oct 31 12:07:44 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08647 for ; Fri, 31 Oct 2003 12:07:43 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGifkT097447 for ; Fri, 31 Oct 2003 08:44:41 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VGifdd097446 for ietf-openpgp-bks; Fri, 31 Oct 2003 08:44:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail1.bllvwa.cablespeed.com (smtp1.bllvwa.cablespeed.com [66.235.59.8]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9VGifkT097434 for ; Fri, 31 Oct 2003 08:44:41 -0800 (PST) (envelope-from cme@acm.org) Received: (qmail 23721 invoked by uid 0); 31 Oct 2003 16:44:29 -0000 Received: from unknown (HELO p4) (66.235.36.35) by 0 with SMTP; 31 Oct 2003 16:44:29 -0000 Message-Id: <3.0.5.32.20031031084439.014a12b8@localhost> X-Sender: cme@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 31 Oct 2003 08:44:39 -0800 To: David Shaw From: Carl Ellison Subject: theory (was Re: Back-signatures proposal) Cc: ietf-openpgp@imc.org In-Reply-To: <20031028163528.GA6792@jabberwocky.com> 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: This concern applies, IMHO, when the keyholder derives power from the thing that is signed, as opposed to the normal course of business in which the thing signed derives power from the key. In the normal case, the key itself gets power because someone certifies it. If it's a subkey and the world knows a keyholder by primary key, then you need a signature from the primary key to the subkey. In this other case, if the source of the power (the thing signed) is capable of signing things, then it needs to sign the subkey, to transmit its power to that key. If the source of the power is not capable of signing things, then there's no way to construct a cryptographic proof. For example, the thing granting power might be a patent application. How would this grant power to a key? If someone wants to sign the patent app while transmitting it to the USPTO, that's fine, but that signature doesn't mean anything. The power comes from having the patent app be signed and time-stamped by the USPTO. If that app includes the hash of the user's signing key, then there is a chain of empowerment established with all the arrow heads pointing in the same direction - and that's the minimum requirement for whatever we're talking about to be meaningful. - Carl +------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://theworld.com/~cme | | PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ From owner-ietf-openpgp@mail.imc.org Fri Oct 31 13:15:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11160 for ; Fri, 31 Oct 2003 13:15:05 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHoVkT099936 for ; Fri, 31 Oct 2003 09:50:31 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VHoVeH099935 for ietf-openpgp-bks; Fri, 31 Oct 2003 09:50:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHoTkT099930 for ; Fri, 31 Oct 2003 09:50:29 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-75-40.dsl.pltn13.pacbell.net [68.122.75.40]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with ESMTP id h9VHoTEb020704; Fri, 31 Oct 2003 09:50:30 -0800 (PST) Message-Id: <5.2.0.9.0.20031031094654.03ad8e38@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Oct 2003 09:50:27 -0800 To: Michael Young , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <3FA289F7.20802@the-youngs.org> References: <20031030202016.GA23324@jabberwocky.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> <20031030202016.GA23324@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:12 AM 10/31/2003 -0500, Michael Young wrote: >Content-Transfer-Encoding: 7bit > > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote: > >In my scenario, a bunch of different primary key holders trust a > >single subkey holder to perform signatures on their behalf. The > >subkey holder wants to make sure that each signature is attributed > >to the proper primary key. > >I'd love to have a better framework for publicly expressing trust >relationships, but I really don't think this was one of the intended >uses of subkeys. [Given where the RFC stands, I think that trust >expresion would best be addressed by a new, adjunct RFC.] Sure, no problem - I was just thinking we could slay these things with the same stone, but in retrospect it seems like it only confuses an issue that David had done a good job clarifying.. Trevor From owner-ietf-openpgp@mail.imc.org Fri Oct 31 14:55:20 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16089 for ; Fri, 31 Oct 2003 14:55:19 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJUakT003595 for ; Fri, 31 Oct 2003 11:30:36 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJUaU6003594 for ietf-openpgp-bks; Fri, 31 Oct 2003 11:30:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJUYkT003587 for ; Fri, 31 Oct 2003 11:30:35 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9VJUYQ12110; Fri, 31 Oct 2003 14:30:34 -0500 Date: Fri, 31 Oct 2003 14:30:34 -0500 From: David Shaw To: ietf-openpgp@imc.org Cc: Carl Ellison Subject: Re: theory (was Re: Back-signatures proposal) Message-ID: <20031031193034.GA11971@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org, Carl Ellison References: <20031028163528.GA6792@jabberwocky.com> <3.0.5.32.20031031084439.014a12b8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.5.32.20031031084439.014a12b8@localhost> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (46% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Oct 31, 2003 at 08:44:39AM -0800, Carl Ellison wrote: > > This concern applies, IMHO, when the keyholder derives power from > the thing that is signed, as opposed to the normal course of > business in which the thing signed derives power from the key. I see the stolen signatures problem as something that naturally follows from your second example. As you say, when I issue a signature on something, I give that something power. At the same time though, I certainly don't want someone else claiming that *they* gave it that power. As the protocol stands now, it is easy for multiple people to claim ownership of a given signature, and produce a valid key to back up that claim. To be sure, there are other (more difficult) ways for an attacker to do the same thing, but either of the proposed fixes raises the bar sufficiently to stop casual exploitation. David From owner-ietf-openpgp@mail.imc.org Fri Oct 31 15:35:47 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19165 for ; Fri, 31 Oct 2003 15:35:46 -0500 (EST) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKE0kT005684 for ; Fri, 31 Oct 2003 12:14:00 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VKE0pZ005683 for ietf-openpgp-bks; Fri, 31 Oct 2003 12:14:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKDxkT005677 for ; Fri, 31 Oct 2003 12:13:59 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-75-40.dsl.pltn13.pacbell.net [68.122.75.40]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id h9VKDwMX028796; Fri, 31 Oct 2003 12:13:58 -0800 (PST) Message-Id: <5.2.0.9.0.20031031103638.03ab7420@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Oct 2003 12:13:55 -0800 To: Carl Ellison From: Trevor Perrin Subject: Re: theory (was Re: Back-signatures proposal) Cc: ietf-openpgp@imc.org In-Reply-To: <3.0.5.32.20031031084439.014a12b8@localhost> References: <20031028163528.GA6792@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 08:44 AM 10/31/2003 -0800, Carl Ellison wrote: [...] >For example, the thing granting power might be a patent application. How >would this grant power to a key? Suppose I download the patent application from USPTO's site, over a secure link. I notice the patent has a signature on it, and I know the USPTO is in the habit of signing pending applications with its own key. I go to a PGP key server and find a key claiming to belong to USPTO. I use it to verify the application. Since it verifies, I jump to the conclusion that the key belongs to the USPTO. This conclusion is unwarranted and dangerous, as things stand - just cause a key verifies a signature, doesn't mean the key made the signature. However, if the signed application contained the key or its hash anywhere, then I *could* use the application to "authenticate" the key. The odd thing is the key or its hash doesn't need to be inside the signature, just attached to the document somewhere, since the only meaningful attack here is one performed by an attacker who can't modify the document - such an active attacker could just re-sign the document himself. Or is that true? I'm not sure. Is it possible that an attacker would be able to fiddle the key hash but not actually re-sign the document? Perhaps not, but it seems safest to put the key-hash inside the signature, just in case. Anyways, if this was done, then users who make the naive assumption that if a key verifies a signature, it must have made the signature, would be safe. --- (stray thought, not related to PGP) --- There's another use for including extra "context" in a signature. I think this use is more important in general, but less important in the particular case of PGP subkeys. But I summarize it here cause it's theoretically interesting. This use is to include extra context in a signature so as to differentiate between multiple instances of the same key. For example, I believe an SPKI signature covers the subject certificate only, not the issuer's certificate. Thus if an issuer has multiple certificates containing the same key, a subject can "re-root" itself under whichever of the issuer's certificates is most to its (the subject's) liking. For example: suppose an issuer certificate is revoked, and the issuer receives a new certificate for the same key. You might assume all certificates issued under the revoked certificate are also revoked, but you'd be wrong: the holders of these certificates could re-root themselves under the issuer's new certificate. Similar things are possible in X.509, which is why a recent book on PKI [1] recommends against re-using keys: "There is a more compelling reason not to put a single public key in multiple certificates, however: It is too easy to "slip up" and not hold all other important aspects of these multiple certificates constant.[...] Such situations may allow an attacker (or even an underhanded certificate subject) to substitute one certificate for another so that what was once merely a signed piece of data now takes on an entirely new meaning. Mandating that different certificates always contain different public keys is a simple way to entirely preclude the risk of such substitution attacks." I dislike that mandate, since there are good reasons for re-using keys (limited key storage, the expense of key generation, etc..). Instead, I think it would be preferable if every signature covers all relevant context needed to differentiate the signing key from the same key used in a different certificate. Granted, in PGP subkeys this may not be worth doing. But at the "theory" level, this seems a good principle for certificate formats. I'm curious if you agree with that (I suspect you don't, or SPKI would be different :-). This is wandering off-topic, though, I know.. Trevor [1] Understanding PKI, 2nd Ed., Carlisle Adams and Steve Lloyd Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKE0kT005684 for ; Fri, 31 Oct 2003 12:14:00 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VKE0pZ005683 for ietf-openpgp-bks; Fri, 31 Oct 2003 12:14:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw4.prodigy.net (mtaw4.prodigy.net [64.164.98.52]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VKDxkT005677 for ; Fri, 31 Oct 2003 12:13:59 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-75-40.dsl.pltn13.pacbell.net [68.122.75.40]) by mtaw4.prodigy.net (8.12.10/8.12.10) with ESMTP id h9VKDwMX028796; Fri, 31 Oct 2003 12:13:58 -0800 (PST) Message-Id: <5.2.0.9.0.20031031103638.03ab7420@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Oct 2003 12:13:55 -0800 To: Carl Ellison From: Trevor Perrin Subject: Re: theory (was Re: Back-signatures proposal) Cc: ietf-openpgp@imc.org In-Reply-To: <3.0.5.32.20031031084439.014a12b8@localhost> References: <20031028163528.GA6792@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 08:44 AM 10/31/2003 -0800, Carl Ellison wrote: [...] >For example, the thing granting power might be a patent application. How >would this grant power to a key? Suppose I download the patent application from USPTO's site, over a secure link. I notice the patent has a signature on it, and I know the USPTO is in the habit of signing pending applications with its own key. I go to a PGP key server and find a key claiming to belong to USPTO. I use it to verify the application. Since it verifies, I jump to the conclusion that the key belongs to the USPTO. This conclusion is unwarranted and dangerous, as things stand - just cause a key verifies a signature, doesn't mean the key made the signature. However, if the signed application contained the key or its hash anywhere, then I *could* use the application to "authenticate" the key. The odd thing is the key or its hash doesn't need to be inside the signature, just attached to the document somewhere, since the only meaningful attack here is one performed by an attacker who can't modify the document - such an active attacker could just re-sign the document himself. Or is that true? I'm not sure. Is it possible that an attacker would be able to fiddle the key hash but not actually re-sign the document? Perhaps not, but it seems safest to put the key-hash inside the signature, just in case. Anyways, if this was done, then users who make the naive assumption that if a key verifies a signature, it must have made the signature, would be safe. --- (stray thought, not related to PGP) --- There's another use for including extra "context" in a signature. I think this use is more important in general, but less important in the particular case of PGP subkeys. But I summarize it here cause it's theoretically interesting. This use is to include extra context in a signature so as to differentiate between multiple instances of the same key. For example, I believe an SPKI signature covers the subject certificate only, not the issuer's certificate. Thus if an issuer has multiple certificates containing the same key, a subject can "re-root" itself under whichever of the issuer's certificates is most to its (the subject's) liking. For example: suppose an issuer certificate is revoked, and the issuer receives a new certificate for the same key. You might assume all certificates issued under the revoked certificate are also revoked, but you'd be wrong: the holders of these certificates could re-root themselves under the issuer's new certificate. Similar things are possible in X.509, which is why a recent book on PKI [1] recommends against re-using keys: "There is a more compelling reason not to put a single public key in multiple certificates, however: It is too easy to "slip up" and not hold all other important aspects of these multiple certificates constant.[...] Such situations may allow an attacker (or even an underhanded certificate subject) to substitute one certificate for another so that what was once merely a signed piece of data now takes on an entirely new meaning. Mandating that different certificates always contain different public keys is a simple way to entirely preclude the risk of such substitution attacks." I dislike that mandate, since there are good reasons for re-using keys (limited key storage, the expense of key generation, etc..). Instead, I think it would be preferable if every signature covers all relevant context needed to differentiate the signing key from the same key used in a different certificate. Granted, in PGP subkeys this may not be worth doing. But at the "theory" level, this seems a good principle for certificate formats. I'm curious if you agree with that (I suspect you don't, or SPKI would be different :-). This is wandering off-topic, though, I know.. Trevor [1] Understanding PKI, 2nd Ed., Carlisle Adams and Steve Lloyd Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJUakT003595 for ; Fri, 31 Oct 2003 11:30:36 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VJUaU6003594 for ietf-openpgp-bks; Fri, 31 Oct 2003 11:30:36 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VJUYkT003587 for ; Fri, 31 Oct 2003 11:30:35 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9VJUYQ12110; Fri, 31 Oct 2003 14:30:34 -0500 Date: Fri, 31 Oct 2003 14:30:34 -0500 From: David Shaw To: ietf-openpgp@imc.org Cc: Carl Ellison Subject: Re: theory (was Re: Back-signatures proposal) Message-ID: <20031031193034.GA11971@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org, Carl Ellison References: <20031028163528.GA6792@jabberwocky.com> <3.0.5.32.20031031084439.014a12b8@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3.0.5.32.20031031084439.014a12b8@localhost> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (46% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Oct 31, 2003 at 08:44:39AM -0800, Carl Ellison wrote: > > This concern applies, IMHO, when the keyholder derives power from > the thing that is signed, as opposed to the normal course of > business in which the thing signed derives power from the key. I see the stolen signatures problem as something that naturally follows from your second example. As you say, when I issue a signature on something, I give that something power. At the same time though, I certainly don't want someone else claiming that *they* gave it that power. As the protocol stands now, it is easy for multiple people to claim ownership of a given signature, and produce a valid key to back up that claim. To be sure, there are other (more difficult) ways for an attacker to do the same thing, but either of the proposed fixes raises the bar sufficiently to stop casual exploitation. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHoVkT099936 for ; Fri, 31 Oct 2003 09:50:31 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VHoVeH099935 for ietf-openpgp-bks; Fri, 31 Oct 2003 09:50:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VHoTkT099930 for ; Fri, 31 Oct 2003 09:50:29 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-75-40.dsl.pltn13.pacbell.net [68.122.75.40]) by mta7.pltn13.pbi.net (8.12.10/8.12.10) with ESMTP id h9VHoTEb020704; Fri, 31 Oct 2003 09:50:30 -0800 (PST) Message-Id: <5.2.0.9.0.20031031094654.03ad8e38@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 31 Oct 2003 09:50:27 -0800 To: Michael Young , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <3FA289F7.20802@the-youngs.org> References: <20031030202016.GA23324@jabberwocky.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> <20031030202016.GA23324@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:12 AM 10/31/2003 -0500, Michael Young wrote: >Content-Transfer-Encoding: 7bit > > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote: > >In my scenario, a bunch of different primary key holders trust a > >single subkey holder to perform signatures on their behalf. The > >subkey holder wants to make sure that each signature is attributed > >to the proper primary key. > >I'd love to have a better framework for publicly expressing trust >relationships, but I really don't think this was one of the intended >uses of subkeys. [Given where the RFC stands, I think that trust >expresion would best be addressed by a new, adjunct RFC.] Sure, no problem - I was just thinking we could slay these things with the same stone, but in retrospect it seems like it only confuses an issue that David had done a good job clarifying.. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGifkT097447 for ; Fri, 31 Oct 2003 08:44:41 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VGifdd097446 for ietf-openpgp-bks; Fri, 31 Oct 2003 08:44:41 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail1.bllvwa.cablespeed.com (smtp1.bllvwa.cablespeed.com [66.235.59.8]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9VGifkT097434 for ; Fri, 31 Oct 2003 08:44:41 -0800 (PST) (envelope-from cme@acm.org) Received: (qmail 23721 invoked by uid 0); 31 Oct 2003 16:44:29 -0000 Received: from unknown (HELO p4) (66.235.36.35) by 0 with SMTP; 31 Oct 2003 16:44:29 -0000 Message-Id: <3.0.5.32.20031031084439.014a12b8@localhost> X-Sender: cme@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Fri, 31 Oct 2003 08:44:39 -0800 To: David Shaw From: Carl Ellison Subject: theory (was Re: Back-signatures proposal) Cc: ietf-openpgp@imc.org In-Reply-To: <20031028163528.GA6792@jabberwocky.com> 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: This concern applies, IMHO, when the keyholder derives power from the thing that is signed, as opposed to the normal course of business in which the thing signed derives power from the key. In the normal case, the key itself gets power because someone certifies it. If it's a subkey and the world knows a keyholder by primary key, then you need a signature from the primary key to the subkey. In this other case, if the source of the power (the thing signed) is capable of signing things, then it needs to sign the subkey, to transmit its power to that key. If the source of the power is not capable of signing things, then there's no way to construct a cryptographic proof. For example, the thing granting power might be a patent application. How would this grant power to a key? If someone wants to sign the patent app while transmitting it to the USPTO, that's fine, but that signature doesn't mean anything. The power comes from having the patent app be signed and time-stamped by the USPTO. If that app includes the hash of the user's signing key, then there is a chain of empowerment established with all the arrow heads pointing in the same direction - and that's the minimum requirement for whatever we're talking about to be meaningful. - Carl +------------------------------------------------------------------+ |Carl M. Ellison cme@acm.org http://theworld.com/~cme | | PGP: 75C5 1814 C3E3 AAA7 3F31 47B9 73F1 7E3C 96E7 2B71 | +---Officer, arrest that man. He's whistling a copyrighted song.---+ Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGDikT096467 for ; Fri, 31 Oct 2003 08:13:44 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9VGDhNh096466 for ietf-openpgp-bks; Fri, 31 Oct 2003 08:13:43 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9VGDekT096456 for ; Fri, 31 Oct 2003 08:13:41 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-196-20.transarc.ibm.com [9.38.196.220]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id LAA22909 for ; Fri, 31 Oct 2003 11:13:21 -0500 (EST) Message-ID: <3FA289F7.20802@the-youngs.org> Date: Fri, 31 Oct 2003 11:12:39 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II References: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> <20031030202016.GA23324@jabberwocky.com> In-Reply-To: <20031030202016.GA23324@jabberwocky.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote: >In my scenario, a bunch of different primary key holders trust a >single subkey holder to perform signatures on their behalf. The >subkey holder wants to make sure that each signature is attributed >to the proper primary key. I'd love to have a better framework for publicly expressing trust relationships, but I really don't think this was one of the intended uses of subkeys. [Given where the RFC stands, I think that trust expresion would best be addressed by a new, adjunct RFC.] -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP6KJuOc3iHYL8FknEQLnGwCgrEKS8MGYy1yC1+MM9LnJSLw4lI4Anj7q QkcRcd1BHP6lLO5XpYlsom6U =OIIz -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UM3kkT087922 for ; Thu, 30 Oct 2003 14:03:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UM3kQm087921 for ietf-openpgp-bks; Thu, 30 Oct 2003 14:03:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UM3ikT087916 for ; Thu, 30 Oct 2003 14:03:44 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (ppp-68-122-224-7.dsl.pltn13.pacbell.net [68.122.224.7]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id h9UM3J6q010836; Thu, 30 Oct 2003 14:03:20 -0800 (PST) Message-Id: <5.2.0.9.0.20031030131243.03a6bc38@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 30 Oct 2003 14:03:43 -0800 To: David Shaw , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <20031030202016.GA23324@jabberwocky.com> References: <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 03:20 PM 10/30/2003 -0500, David Shaw wrote: >On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote: > > > In my scenario, a bunch of different primary key holders trust a > > single subkey holder to perform signatures on their behalf. The > > subkey holder wants to make sure that each signature is attributed > > to the proper primary key. > >I'm having trouble seeing the lack of this ability as a problem, much >less a problem that needs a fix. > >It's always possible to come up with a (perhaps convoluted) situation >where any feature would be useful, and with all due respect, I think >this scenario crosses the convolution line. Fair enough. The more useful scenario I was thinking of is where a single primary key is held by a server, which issues short-lived subkeys to different users, so they don't have to bother keeping a primary key secure. But in that case, I think the "Signer's User ID" subpacket is sufficient to differentiate things. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UKKGkT084608 for ; Thu, 30 Oct 2003 12:20:16 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UKKGUG084607 for ietf-openpgp-bks; Thu, 30 Oct 2003 12:20:16 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UKKEkT084602 for ; Thu, 30 Oct 2003 12:20:15 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9UKKGP25239 for ietf-openpgp@imc.org; Thu, 30 Oct 2003 15:20:16 -0500 Date: Thu, 30 Oct 2003 15:20:16 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031030202016.GA23324@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (34% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Oct 30, 2003 at 10:37:18AM -0800, Trevor Perrin wrote: > In my scenario, a bunch of different primary key holders trust a > single subkey holder to perform signatures on their behalf. The > subkey holder wants to make sure that each signature is attributed > to the proper primary key. I'm having trouble seeing the lack of this ability as a problem, much less a problem that needs a fix. It's always possible to come up with a (perhaps convoluted) situation where any feature would be useful, and with all due respect, I think this scenario crosses the convolution line. Sharing signature keys is generally not a good idea. Note in the example that if the trusted subkey holder stops being trusted, he can issue signatures in the name of any of the users. Plus if any of the keyholders has a key compromise, all keyholders must re-key. If and when such a situation develops, I'd support a supplemental RFC to specify the necessary signature subpacket. Until the proposed scenario becomes more concrete, anything we can do about it in 2440bis is apt to be incorrect in some detail. In the meantime, I'm content to say if a user really wants to share keys, he can use a signature notation to include whatever additional information he lines. I don't think this needs to be in 2440bis. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIbTkT079505 for ; Thu, 30 Oct 2003 10:37:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UIbTx8079504 for ietf-openpgp-bks; Thu, 30 Oct 2003 10:37:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UIbRkT079498 for ; Thu, 30 Oct 2003 10:37:28 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-193-42.dsl.pltn13.pacbell.net [68.122.193.42]) by mta4.rcsntx.swbell.net (8.12.10/8.12.10) with ESMTP id h9UIbKxj022484; Thu, 30 Oct 2003 12:37:21 -0600 (CST) Message-Id: <5.2.0.9.0.20031030102716.03a6bc38@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 30 Oct 2003 10:37:18 -0800 To: Adrian von Bidder , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <200310300925.52523@fortytwo.ch> References: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 09:25 AM 10/30/2003 +0100, Adrian von Bidder wrote: > >On Thursday 30 October 2003 00:17, Trevor Perrin wrote: > >[subkey signatures - embedding the primary to avoid misattribution] > >> The case I was thinking of, where key re-use might occur, is in something >> like a smartcard, or a delegated signing server. This might have limited >> key storage, or it might not be able to generate new keys (not enough >> power, or not enough randomness). If different users share the device, >> they each might want to certify the device's subkey as belonging under >> their own primary key. >> >> The device would want to make sure each of it's signatures are >>attributable to the right primary key. If every signature is a >>back-signature, this is accomplished. > >The hash of the primary would be over the public key? So the holder of >the secret subkey can make his subkey signature appear to come from >whatever primary he wants, he doesn't need the secret (primary) key. He can make his subkey signature appear to come under any of the primary keys that have trusted him (i.e. any of the primary keys that have issued him a subkey binding signature). > >So, in your scenario, sharing the secret subkey will effectively mean >that each can make signatures that will verify with the other's primary. In my scenario, a bunch of different primary key holders trust a single subkey holder to perform signatures on their behalf. The subkey holder wants to make sure that each signature is attributed to the proper primary key. Maybe this is a use case that subkeys aren't intended to support. But if every signature covered the primary key and subkey it was produced under, this would work. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFfUkT068563 for ; Thu, 30 Oct 2003 07:41:30 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9UFfUDd068562 for ietf-openpgp-bks; Thu, 30 Oct 2003 07:41:30 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9UFfTkT068555 for ; Thu, 30 Oct 2003 07:41:30 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9UFfU223065 for ietf-openpgp@imc.org; Thu, 30 Oct 2003 10:41:30 -0500 Date: Thu, 30 Oct 2003 10:41:30 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Let's finish up 0x50 "notary" signatures Message-ID: <20031030154129.GC22729@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (33% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Oct 30, 2003 at 06:07:32AM +0000, poiboy@SAFe-mail.net wrote: > Removing the canonical header replacement for external signing of > signatures would make it easier to work with many notarized > signatures. This probably steps on toes, though. I wouldn't remove the canonical header for hashing the original signature. It would be inconsistent with all of the other hashing rules in the draft. The only thing that is necessary here is to specify that the unhashed data in the original signature is not included in the notary signature. Specifically, section 5.2.4 currently says: When a signature is made over a signature, the hash data starts with the octet 0x88, followed by the four-octet length of the signature, and then the body of the signature packet. (Note that this is an old-style packet header for a signature packet with the length-of-length set to zero). I would add a sentence between those two that reads something like: The unhashed subpacket data of the signature packet being hashed is not included in the hash, and the unhashed subpacket data length value is set to zero. The idea here is that the canonical form of a signature to be hashed has no unhashed subpacket data. This addresses your first comment as well. We don't need to specify what gets hashed into the notary signature, since it is clear that the entire target signature, minus its unhashed data, is hashed for the notary signature. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U8RBkT025944 for ; Thu, 30 Oct 2003 00:27:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U8RBIE025943 for ietf-openpgp-bks; Thu, 30 Oct 2003 00:27:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from onaras-pdc.onaras.local ([80.254.174.13]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9U8R9kT025563 for ; Thu, 30 Oct 2003 00:27:09 -0800 (PST) (envelope-from avbidder@fortytwo.ch) Received: (qmail 2773 invoked from network); 30 Oct 2003 08:25:53 -0000 Received: from bugs.onaras.local (192.168.0.63) by 192.168.0.222 with SMTP; 30 Oct 2003 08:25:53 -0000 From: Adrian von Bidder Organization: Onaras AG To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Date: Thu, 30 Oct 2003 09:25:52 +0100 User-Agent: KMail/1.5.4 References: <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> In-Reply-To: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_QsMo/zMRVZGt0Q5"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200310300925.52523@fortytwo.ch> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_QsMo/zMRVZGt0Q5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Description: signed data Content-Disposition: inline [no cc:s please] On Thursday 30 October 2003 00:17, Trevor Perrin wrote: [subkey signatures - embedding the primary to avoid misattribution] > The case I was thinking of, where key re-use might occur, is in something > like a smartcard, or a delegated signing server. This might have limited > key storage, or it might not be able to generate new keys (not enough > power, or not enough randomness). If different users share the device, > they each might want to certify the device's subkey as belonging under > their own primary key. > > The device would want to make sure each of it's signatures are attributab= le > to the right primary key. If every signature is a back-signature, this is > accomplished. The hash of the primary would be over the public key? So the holder of the= =20 secret subkey can make his subkey signature appear to come from whatever=20 primary he wants, he doesn't need the secret (primary) key. So, in your scenario, sharing the secret subkey will effectively mean that= =20 each can make signatures that will verify with the other's primary. Or do I misunderstand someting here? cheers =2D- vbi =2D-=20 featured product: vim - http://vim.org --Boundary-02=_QsMo/zMRVZGt0Q5 Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iKcEABECAGcFAj+gyxBgGmh0dHA6Ly9mb3J0eXR3by5jaC9sZWdhbC9ncGcvZW1h aWwuMjAwMjA4MjI/dmVyc2lvbj0xLjUmbWQ1c3VtPTVkZmY4NjhkMTE4NDMyNzYw NzFiMjVlYjcwMDZkYTNlAAoJECqqZti935l6L5AAoJGArtInwxevFaWcvlOCkKiP jm6NAJ4rSS+9B1TRtO8DA1mahhPvaZtCMg== =GTPv -----END PGP SIGNATURE----- --Boundary-02=_QsMo/zMRVZGt0Q5-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U67ckT073293 for ; Wed, 29 Oct 2003 22:07:38 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U67csH073292 for ietf-openpgp-bks; Wed, 29 Oct 2003 22:07:38 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.safe-mail.net (tapuz.safe-mail.net [212.68.149.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U67akT073266 for ; Wed, 29 Oct 2003 22:07:36 -0800 (PST) (envelope-from poiboy@SAFe-mail.net) Received: from poiboy@SAFe-mail.net by www.safe-mail.net with SAFe-mail (Exim 4.20) id 1AF5y0-00010o-Gg; Thu, 30 Oct 2003 01:07:32 -0500 Received: from pc ([66.91.42.66]) by mail.SAFe-mail.net Subject: Re: Let's finish up 0x50 "notary" signatures Date: Thu, 30 Oct 2003 06:07:32 +0000 From: poiboy@SAFe-mail.net To: dshaw@jabberwocky.com CC: ietf-openpgp@imc.org X-SMType: Regular X-SMRef: N1-GctKN-78 Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Casting a vote from the cheap seats, I think signatures-in-subpackets are an elegant option for 3rd-party signatures on single signatures. I suggest inserting the following (or something similar) to 5.2.4: > When a signature over a V4 signature is issued as a subpacket, the > body of hash data consists of the same data that the (parent) V4 > signature used to build its own hash, that is, the parent's version, > type, public key algorithm, hash algorithm, and hashed subpacket > material (length header and subpackets). and changing the beginning of the existing signature-on-a-signature paragraph in the same section to make it clear that different rules apply to "sub-signatures": < When a signature is made over a signature, the hash data.. --- > When a signature is issued over a signature packet, the hash data.. Rounding out thoughts on 0x50, Removing the canonical header replacement for external signing of signatures would make it easier to work with many notarized signatures. This probably steps on toes, though. The ability to construct nice (10.2) messages using multiple/nested 0x50 signatures on fixed signature data (I suggest adding functionality to the one-pass packet 'nest') would allow complete expression of 0x50 signatures per 5.2.1 (as opposed to keeping them detached or on a per-signature basis in subpackets). Additionally, I think the "signed and notarized document" deserves the same degree of clout (that only a bona fide message has) as a normal "signed document." Happy days, poiboy Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U0bKkT055645 for ; Wed, 29 Oct 2003 16:37:20 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9U0bKrU055644 for ietf-openpgp-bks; Wed, 29 Oct 2003 16:37:20 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9U0bIkT055638 for ; Wed, 29 Oct 2003 16:37:19 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9U0bLh04279 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 19:37:21 -0500 Date: Wed, 29 Oct 2003 19:37:20 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Let's finish up 0x50 "notary" signatures Message-ID: <20031030003720.GA24888@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200310292352.h9TNqcRP008949@mailserver3.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200310292352.h9TNqcRP008949@mailserver3.hushmail.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (27% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Oct 29, 2003 at 03:52:38PM -0800, vedaal@hush.com wrote: > On Wed, 29 Oct 2003 14:25:17 -0800 David Shaw > wrote: > > >A notary can issue a notary signature on any signature, which includes > >key certifications. Placing the notary signature in a > >signature-in-a-subpacket on the unhashed area of the original > >signature would be an effective way of transporting the notary sig > >around with the key. > > could this be done in a way that existing implementations can just > 'ignore' (i.e., not 'choke' on) the notary signature if it can't > 'recognize' what it is, when importing a key with a notary signature > on the self- signed sig of the key? Yes, existing implementations should ignore and certainly not choke on any unrecognized signature subpacket. If the signer chooses to, they can set the "critical" flag, which requests that an implementation fail the signature verification for unrecognized signature subpackets, but at the same time, they don't have to. It's up to the signer what they want to happen. (It is a different issue altogether whether a critical bit on an *unhashed* subpacket should cause this to happen, though!) David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+gXUAqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJu2wAn1tgsAjREJuw9EMDe6mTGmwTmZb0AKCW d0F3ekMqwCMjmsCe8vNfixM0bQ== =01bo -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNqdkT053031 for ; Wed, 29 Oct 2003 15:52:39 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNqdIm053030 for ietf-openpgp-bks; Wed, 29 Oct 2003 15:52:39 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNqckT053022 for ; Wed, 29 Oct 2003 15:52:38 -0800 (PST) (envelope-from vedaal@hush.com) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.45]) by smtp3.hushmail.com (Postfix) with ESMTP id 42BE510E6A2 for ; Wed, 29 Oct 2003 15:52:39 -0800 (PST) Received: from mailserver3.hushmail.com (localhost [127.0.0.1]) by mailserver3.hushmail.com (8.12.6/8.12.3) with ESMTP id h9TNqcvo008950 for ; Wed, 29 Oct 2003 15:52:38 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.6/8.12.3/Submit) id h9TNqcRP008949 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 15:52:38 -0800 (PST) Message-Id: <200310292352.h9TNqcRP008949@mailserver3.hushmail.com> Date: Wed, 29 Oct 2003 15:52:38 -0800 To: ietf-openpgp@imc.org Cc: Subject: Re: Let's finish up 0x50 "notary" signatures From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Oct 2003 14:25:17 -0800 David Shaw wrote: >A notary can issue a notary signature on any signature, which includes >key certifications. Placing the notary signature in a >signature-in-a-subpacket on the unhashed area of the original >signature would be an effective way of transporting the notary sig >around with the key. could this be done in a way that existing implementations can just 'ignore' (i.e., not 'choke' on) the notary signature if it can't 'recognize' what it is, when importing a key with a notary signature on the self- signed sig of the key? vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNimkT052540 for ; Wed, 29 Oct 2003 15:44:48 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNimOY052539 for ietf-openpgp-bks; Wed, 29 Oct 2003 15:44:48 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNilkT052534 for ; Wed, 29 Oct 2003 15:44:47 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-119-11.dsl.pltn13.pacbell.net [68.122.119.11]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id h9TNiNjp011242; Wed, 29 Oct 2003 15:44:23 -0800 (PST) Message-Id: <5.2.0.9.0.20031029152237.03a83420@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 29 Oct 2003 15:44:46 -0800 To: Michael Young , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <3FA03A73.90304@the-youngs.org> References: <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:08 PM 10/29/2003 -0500, Michael Young wrote: >Trevor Perrin wrote (in another message): > > I don't want to re-confuse an issue you've just clarified, but > > here's a generalization of the second proposal that might be worth > > considering: > > > > You could include in *every* signature a subpacket that contains a > > hash of *all* enclosing context. By "enclosing context" I mean > > the key packet for the primary key, along with its > > self-signatures, and the key packet for the subkey as well (if the > > signing key is a subkey) along with the subkey binding signature. > >This would add yet another impediment to rewriting self-signatures >(or binding signatures). To permit rewriting, you'd have to keep >all past versions (and try each one at verification time) or copy >that material into the signature. Good point - you'd only want to include context that won't get invalidated by re-issued signatures. So I guess we could change the proposal to only cover key packets, not signature packets, without losing too much: Proposal: Include in every signature a hashed subpacket that contains a hash of the relevant key packets. The relevant key packets are the primary key packet if the signing key is a primary key, or the primary key *and* subkey packets if the signing key is a subkey. This stops these 3 manipulations: - issuing a subkey signature to someone else's key, and claiming their signatures - changing the primary key that a signature performed by a re-used subkey belongs under - an attacker generating a new key that verifies someone else's signature Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNHakT050885 for ; Wed, 29 Oct 2003 15:17:36 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TNHZWl050884 for ietf-openpgp-bks; Wed, 29 Oct 2003 15:17:35 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TNHYkT050879 for ; Wed, 29 Oct 2003 15:17:34 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-119-11.dsl.pltn13.pacbell.net [68.122.119.11]) by mtaw6.prodigy.net (8.12.10/8.12.10) with ESMTP id h9TNHAjp020257; Wed, 29 Oct 2003 15:17:10 -0800 (PST) Message-Id: <5.2.0.9.0.20031029145733.03a66338@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 29 Oct 2003 15:17:33 -0800 To: David Shaw , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <20031029220415.GC22497@jabberwocky.com> References: <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:04 PM 10/29/2003 -0500, David Shaw wrote: >On Wed, Oct 29, 2003 at 01:33:23PM -0800, Trevor Perrin wrote: > > > >> The problem arises when the user signs a document with the subkey, and > > >> wants this signature to be under one of his particular > primaries. Say he > > >> has Work and Personal primary keys. He signs something and wants to > > >> indicate that it's under his Work primary key. > > > > > >A user can "legally" use the same subkey under two different > > >primaries. > > > > yeah, but if he does this, a verifier might assume that the signature was > > intended under one primary key, when it was really intended under another. > > > > > I think this is more of a feature request than an attack. > > > > It's only an attack if a bad guy can choose which primary key the > signature > > appears to be under, in a way that tricks the verifier into treating the > > signature incorrectly. > >The user intentionally chose to use the same subkey in two places. >The user intentionally issued the signature. The user shouldn't be >surprised that either copy of the same key can verify that signature. >If a user wants to be unambiguous as to which hat he was wearing when >he issued the signature, he shouldn't use the same key everywhere. Yeah, this is easily avoided if you just don't re-use keys. It would also be avoided if the signature is calculated over the hat the user was wearing, when he issued the signature. Then you can re-use keys without fear that a verifying party will be confused or tricked about which copy of the key you signed with. >This is somewhat similar to a situation where a user has two user IDs >on his key: "user at evilcompany.com" and "user at >anonymouswhistleblowers.com". If the user sends out whistleblower >information and signs it with that key, he shouldn't be surprised when >he is fired... Anonymity throws a different spin on things. The case I was thinking of, where key re-use might occur, is in something like a smartcard, or a delegated signing server. This might have limited key storage, or it might not be able to generate new keys (not enough power, or not enough randomness). If different users share the device, they each might want to certify the device's subkey as belonging under their own primary key. The device would want to make sure each of it's signatures are attributable to the right primary key. If every signature is a back-signature, this is accomplished. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMPHkT048237 for ; Wed, 29 Oct 2003 14:25:17 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TMPHxR048236 for ietf-openpgp-bks; Wed, 29 Oct 2003 14:25:17 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMPGkT048229 for ; Wed, 29 Oct 2003 14:25:16 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9TMPHg24082 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 17:25:17 -0500 Date: Wed, 29 Oct 2003 17:25:17 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Let's finish up 0x50 "notary" signatures Message-ID: <20031029222517.GE22497@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200310292158.h9TLwEB9005254@mailserver3.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200310292158.h9TLwEB9005254@mailserver3.hushmail.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 29, 2003 at 01:58:14PM -0800, vedaal@hush.com wrote: > can this be extended to be used as notary signature directly on someone's > public key? A notary can issue a notary signature on any signature, which includes key certifications. Placing the notary signature in a signature-in-a-subpacket on the unhashed area of the original signature would be an effective way of transporting the notary sig around with the key. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMLDkT047949 for ; Wed, 29 Oct 2003 14:21:13 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TMLDnk047948 for ietf-openpgp-bks; Wed, 29 Oct 2003 14:21:13 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TMLBkT047940 for ; Wed, 29 Oct 2003 14:21:12 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-196-20.transarc.ibm.com [9.38.196.220]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id RAA20112 for ; Wed, 29 Oct 2003 17:21:12 -0500 (EST) Message-ID: <3FA03A73.90304@the-youngs.org> Date: Wed, 29 Oct 2003 17:08:51 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II References: <20031028222356.GA19100@jabberwocky.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> In-Reply-To: <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Trevor Perrin wrote: > At 10:34 PM 10/28/2003 -0500, Michael Young wrote: >> Also, note that the specification already provides a "signer >> userId" subpacket that could be used to nearly the same effect as >> a "signer primary fingerprint" subpacket. > > I think that would prevent the version of this where the attacker > tries to convince the verifier that the signed message came from > his *name*. In practice, I think it's far more interesting to claim that a particular real-world identity signed a document than a particular primary key. But I understand the difference -- that's why I said "nearly". Trevor Perrin wrote (in another message): > I don't want to re-confuse an issue you've just clarified, but > here's a generalization of the second proposal that might be worth > considering: > > You could include in *every* signature a subpacket that contains a > hash of *all* enclosing context. By "enclosing context" I mean > the key packet for the primary key, along with its > self-signatures, and the key packet for the subkey as well (if the > signing key is a subkey) along with the subkey binding signature. This would add yet another impediment to rewriting self-signatures (or binding signatures). To permit rewriting, you'd have to keep all past versions (and try each one at verification time) or copy that material into the signature. Very little of this "context" is relevant for most uses. For special needs, we have notation packets to carry arbitrary additional context. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP6Az6uc3iHYL8FknEQKTzACcCSmnT4PmJTTUrq8Qd+3moODXWXkAoPEk AmymFtI4xHJSl2Jj3/b/EqJy =kZ1K -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TM4FkT047100 for ; Wed, 29 Oct 2003 14:04:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TM4F7M047099 for ietf-openpgp-bks; Wed, 29 Oct 2003 14:04:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TM4EkT047094 for ; Wed, 29 Oct 2003 14:04:14 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9TM4FN23916 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 17:04:15 -0500 Date: Wed, 29 Oct 2003 17:04:15 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031029220415.GC22497@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 29, 2003 at 01:33:23PM -0800, Trevor Perrin wrote: > >> The problem arises when the user signs a document with the subkey, and > >> wants this signature to be under one of his particular primaries. Say he > >> has Work and Personal primary keys. He signs something and wants to > >> indicate that it's under his Work primary key. > > > >A user can "legally" use the same subkey under two different > >primaries. > > yeah, but if he does this, a verifier might assume that the signature was > intended under one primary key, when it was really intended under another. > > > I think this is more of a feature request than an attack. > > It's only an attack if a bad guy can choose which primary key the signature > appears to be under, in a way that tricks the verifier into treating the > signature incorrectly. The user intentionally chose to use the same subkey in two places. The user intentionally issued the signature. The user shouldn't be surprised that either copy of the same key can verify that signature. If a user wants to be unambiguous as to which hat he was wearing when he issued the signature, he shouldn't use the same key everywhere. This is somewhat similar to a situation where a user has two user IDs on his key: "user at evilcompany.com" and "user at anonymouswhistleblowers.com". If the user sends out whistleblower information and signs it with that key, he shouldn't be surprised when he is fired... David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwFkT046831 for ; Wed, 29 Oct 2003 13:58:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLwFLW046830 for ietf-openpgp-bks; Wed, 29 Oct 2003 13:58:15 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.135]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLwEkT046824 for ; Wed, 29 Oct 2003 13:58:14 -0800 (PST) (envelope-from vedaal@hush.com) Received: from mailserver3.hushmail.com (mailserver3.hushmail.com [65.39.178.45]) by smtp3.hushmail.com (Postfix) with ESMTP id F13E610E73B for ; Wed, 29 Oct 2003 13:58:14 -0800 (PST) Received: from mailserver3.hushmail.com (localhost [127.0.0.1]) by mailserver3.hushmail.com (8.12.6/8.12.3) with ESMTP id h9TLwEvo005255 for ; Wed, 29 Oct 2003 13:58:14 -0800 (PST) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver3.hushmail.com (8.12.6/8.12.3/Submit) id h9TLwEB9005254 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 13:58:14 -0800 (PST) Message-Id: <200310292158.h9TLwEB9005254@mailserver3.hushmail.com> Date: Wed, 29 Oct 2003 13:58:14 -0800 To: ietf-openpgp@imc.org Cc: Subject: Re: Let's finish up 0x50 "notary" signatures From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 29 Oct 2003 12:59:59 -0800 David Shaw wrote: > >The current state of the 0x50 or notary signature is nearly, but >not >quite, completed. The main thing missing is a machine-readable >transport of a signature and it's notarization. > >The current language in the draft is: > > 0x50: Third-Party Confirmation signature. > > This signature is a signature over some other OpenPGP signature > packet(s). It is a notary seal on the signed data. A third- >party > signature SHOULD include Signature Target subpacket(s) to >give > easy identification. can this be extended to be used as notary signature directly on someone's public key? (it would not provide an independent timestamp to the actual signature of the key-holder, but might be able to eventually improve the web-of- trust) with Respect, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLZ4kT045924 for ; Wed, 29 Oct 2003 13:35:04 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLZ43x045923 for ietf-openpgp-bks; Wed, 29 Oct 2003 13:35:04 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta4.rcsntx.swbell.net (mta4.rcsntx.swbell.net [151.164.30.28]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLZ3kT045909 for ; Wed, 29 Oct 2003 13:35:03 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-238-46.dsl.pltn13.pacbell.net [68.122.238.46]) by mta4.rcsntx.swbell.net (8.12.9/8.12.3) with ESMTP id h9TLYvNu020571; Wed, 29 Oct 2003 15:34:59 -0600 (CST) Message-Id: <5.2.0.9.0.20031029124120.03a4bdd8@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 29 Oct 2003 13:33:23 -0800 To: David Shaw From: Trevor Perrin Subject: Re: Back-signatures, part II Cc: ietf-openpgp@imc.org In-Reply-To: <20031029201306.GA22497@jabberwocky.com> References: <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 03:13 PM 10/29/2003 -0500, David Shaw wrote: >On Tue, Oct 28, 2003 at 10:59:31PM -0800, Trevor Perrin wrote: > > > >> - A naive user re-uses the same subkey under 2 different primary > > >> keys. Signatures performed by the subkey can't be confined to > > >> being under one or the other primary key. This problem can be > > >> easily avoided: just don't re-use keys, but that caveat would be > > >> unnecessary if signatures committed to their enclosing context. > > > > > >I don't see this as a problem, actually. So what if a user uses the > > >same subkey under two different primaries? The user controls the > > >subkey, and so can issue valid back-signatures (or fingerprint > > >subpackets). The owner of a subkey can do what they like with it. > > > > The problem arises when the user signs a document with the subkey, and > > wants this signature to be under one of his particular primaries. Say he > > has Work and Personal primary keys. He signs something and wants to > > indicate that it's under his Work primary key. > >A user can "legally" use the same subkey under two different >primaries. yeah, but if he does this, a verifier might assume that the signature was intended under one primary key, when it was really intended under another. > I think this is more of a feature request than an attack. It's only an attack if a bad guy can choose which primary key the signature appears to be under, in a way that tricks the verifier into treating the signature incorrectly. I believe signing subkeys are rare, re-use of signing subkeys is rarer, and re-using them in such a way that an attacker can do this trick, and accomplish something, is pretty unlikely. I'm just trying to point out ways in which signatures can be placed in different contexts than what the signer intended. I view that as the commonality that links these things together - if every signature had a subpacket that contained a hash of: - the key used to perform the signature - the primary key (if the signing key is a subkey) - any self-signatures on the primary key, and the binding signature on the subkey, then I'd feel re-assured that every signature was bound to all relevant context, and no manipulations such as - splicing someone else's key under your primary key, to claim their signatures - fiddling with which primary key a signature appears to be under - presenting a different key that happens to verify a signature would be possible. The one manipulation that *would* still be possible is presenting someone else's key under your primary key, when there's no signature by the victimized key present to give the lie to this. For that, some sort of additional back-signature is unavoidable. But these approaches could be combined - if the back-signature contains the sort of subpacket I'm talking about, that's enough to make it a back-signature. So I guess I'm saying *every* signature should be a back-signature, in that it covers the relevant primary key and sub-keys. But you could also add an extra back-signature just when sub-keys are present. >The include-the-primary-fingerprint fix for the original attack has a >side effect that gives the information you want here, but I still >don't think this is an attack on the system. > > > I.e.: a user who receives a signed message through some secure channel > (say > > someone hands them a message on a floppy disk), might then retrieve a key > > through an *un*secure channel, and attempt to validate the key by > verifying > > the message with it. > > > > You can say: the user screwed up, we can't help him. But if the signature > > covered the public key that produced it, then the user's naive assumption > > would be correct, and his behavior would be safe. > > > > The issuer key ID subpacket makes an attack hard, though, because the > > attacker would have to try ~ 2^64 trial keys that verify the signature, > > before discovering one that *also* has the right issuer key ID. But if > the > > signature covered the public key with a full hash, an attack would be even > > harder. > >Note that most implementations do not store the issuer key ID in the >hashed portion of the signature. The issuer ID is thus not part of >the signature. In the odd case I'm considering, the verifier gets the signed message through some secure channel - someone hands him a signed message on a floppy disk, for example. So even though the issuer key ID isn't part of the signature, an attacker who's trying to make a fake key that verifies the message, still has to match the issuer key ID. So that provides some measure of protection, but if the signing key was hashed as an input to the signature, that would provide even more. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLQkkT045526 for ; Wed, 29 Oct 2003 13:26:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TLQkGc045525 for ietf-openpgp-bks; Wed, 29 Oct 2003 13:26:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TLQikT045519 for ; Wed, 29 Oct 2003 13:26:45 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-196-20.transarc.ibm.com [9.38.196.220]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id QAA20041 for ; Wed, 29 Oct 2003 16:26:45 -0500 (EST) Message-ID: <3FA02ECB.4050303@the-youngs.org> Date: Wed, 29 Oct 2003 16:19:07 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal References: <20031028163528.GA6792@jabberwocky.com> <3F9EE602.90809@the-youngs.org> <20031028222954.GB19100@jabberwocky.com> <3F9F386B.9060600@the-youngs.org> <20031029044704.GA20489@jabberwocky.com> In-Reply-To: <20031029044704.GA20489@jabberwocky.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 David Shaw wrote: > On Tue, Oct 28, 2003 at 10:47:55PM -0500, Michael Young wrote: >>I'd like to see >>recommendations for each flavor of signature that reflect >>real needs. > > I think that is straying into overkill. If there is no security or > protocol correctness issue at hand, just say nothing. > > Let's credit implementors with some ability to know which > subpackets I apologize. Earlier drafts specified that creation time and issuer were mandatory subpackets. The current draft no longer carries that language (and is better for it). -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP6Auouc3iHYL8FknEQIKOwCgsYaSOfZtBUwUReM9XzjsGcg6c9gAnjFx MnuUjqxMPhthubAxBX04miFS =0wF+ -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKxxkT044236 for ; Wed, 29 Oct 2003 12:59:59 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKxxeQ044235 for ietf-openpgp-bks; Wed, 29 Oct 2003 12:59:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKxwkT044230 for ; Wed, 29 Oct 2003 12:59:58 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9TKxx423245 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 15:59:59 -0500 Date: Wed, 29 Oct 2003 15:59:59 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Let's finish up 0x50 "notary" signatures Message-ID: <20031029205959.GB22497@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The current state of the 0x50 or notary signature is nearly, but not quite, completed. The main thing missing is a machine-readable transport of a signature and it's notarization. The current language in the draft is: 0x50: Third-Party Confirmation signature. This signature is a signature over some other OpenPGP signature packet(s). It is a notary seal on the signed data. A third-party signature SHOULD include Signature Target subpacket(s) to give easy identification. Note that we really do mean SHOULD. There are plausible uses for this (such a a blind party that only sees the signature, not the key nor source document) that cannot include a target subpacket. Two suggestions: 1) Do not include the unhashed data of the target signature when generating the notary signature. The unhashed data is not part of the original signature. 2) Define a signature-in-a-subpacket where notary signatures can be placed. This allows the notary signature to be attached (as an unhashed subpacket) to the signature that it notarizes, giving a simple and clean transport method. Any number of notary signatures can be attached to the original signature this way (up to the limit on the unhashed data section), and notary signatures may be easily nested (notarizing a notary signature) by placing a notary signature in the unhashed data section of another notary signature. A signature-in-a-subpacket is simply a signature subpacket that contains another signature. The packet headers are not included, but the signature is otherwise complete. Note that one of the possible solutions to the stolen subkey problem also involves signature-in-a-subpacket. This is a different use of the technique, and its use here is not relevant to the stolen subkey problem. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKK3kT041906 for ; Wed, 29 Oct 2003 12:20:03 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKK3Vd041905 for ietf-openpgp-bks; Wed, 29 Oct 2003 12:20:03 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKK2kT041900 for ; Wed, 29 Oct 2003 12:20:02 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TKK13k008879; Wed, 29 Oct 2003 15:20:01 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TKK16B005479; Wed, 29 Oct 2003 15:20:01 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9TKK0Ei013045; Wed, 29 Oct 2003 15:20:00 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h9TKJxb7004046; Wed, 29 Oct 2003 15:19:59 -0500 (EST) To: Jon Callas Cc: OpenPGP From: Derek Atkins Subject: Re: Meeting in Minneapolis? References: <7F0B0CB4-0A4A-11D8-8107-000A9568596C@callas.org> Date: 29 Oct 2003 15:19:59 -0500 In-Reply-To: <7F0B0CB4-0A4A-11D8-8107-000A9568596C@callas.org> Message-ID: Lines: 34 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > On Wednesday, October 29, 2003, at 09:03 AM, Derek Atkins wrote: > > > Well, I missed the deadline to request a timeslot, too.. So we wont be > > meeting in MSP. HOWEVER I think we've been making a lot of progress > > on the doc here on the list so let's continue along the existing path. > > I think we can do that. I have no objection.. We SHOULD have meetings periodically, if for no other reason that to get more people involved or at least knowledgable about what we're doing. > Ideally, IETF working groups operate *completely* on the mailing > lists. Alas, we do not live in an ideal world, and face-to-face > meetings are desirable or necessary. True. > However, this working group has been making progress for years without > a meeting, and that, in my opinion, is not a bug, it's a feature. Well, it's been making progress but still hasn't completed 2440bis. We should make that a top priority. > Jon -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKD8kT041537 for ; Wed, 29 Oct 2003 12:13:08 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TKD85Y041536 for ietf-openpgp-bks; Wed, 29 Oct 2003 12:13:08 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TKD6kT041531 for ; Wed, 29 Oct 2003 12:13:07 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9TKD6Y22873; Wed, 29 Oct 2003 15:13:06 -0500 Date: Wed, 29 Oct 2003 15:13:06 -0500 From: David Shaw To: Trevor Perrin Cc: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031029201306.GA22497@jabberwocky.com> Mail-Followup-To: Trevor Perrin , ietf-openpgp@imc.org References: <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (25% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 28, 2003 at 10:59:31PM -0800, Trevor Perrin wrote: > >> - A naive user re-uses the same subkey under 2 different primary > >> keys. Signatures performed by the subkey can't be confined to > >> being under one or the other primary key. This problem can be > >> easily avoided: just don't re-use keys, but that caveat would be > >> unnecessary if signatures committed to their enclosing context. > > > >I don't see this as a problem, actually. So what if a user uses the > >same subkey under two different primaries? The user controls the > >subkey, and so can issue valid back-signatures (or fingerprint > >subpackets). The owner of a subkey can do what they like with it. > > The problem arises when the user signs a document with the subkey, and > wants this signature to be under one of his particular primaries. Say he > has Work and Personal primary keys. He signs something and wants to > indicate that it's under his Work primary key. A user can "legally" use the same subkey under two different primaries. I think this is more of a feature request than an attack. The include-the-primary-fingerprint fix for the original attack has a side effect that gives the information you want here, but I still don't think this is an attack on the system. > I.e.: a user who receives a signed message through some secure channel (say > someone hands them a message on a floppy disk), might then retrieve a key > through an *un*secure channel, and attempt to validate the key by verifying > the message with it. > > You can say: the user screwed up, we can't help him. But if the signature > covered the public key that produced it, then the user's naive assumption > would be correct, and his behavior would be safe. > > The issuer key ID subpacket makes an attack hard, though, because the > attacker would have to try ~ 2^64 trial keys that verify the signature, > before discovering one that *also* has the right issuer key ID. But if the > signature covered the public key with a full hash, an attack would be even > harder. Note that most implementations do not store the issuer key ID in the hashed portion of the signature. The issuer ID is thus not part of the signature. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TK0BkT039897 for ; Wed, 29 Oct 2003 12:00:11 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TK0BrP039896 for ietf-openpgp-bks; Wed, 29 Oct 2003 12:00:11 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TK0AkT039891 for ; Wed, 29 Oct 2003 12:00:10 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Wed, 29 Oct 2003 12:00:10 -0800 Received: from callas.org ([209.75.30.238]) by bletchley.merrymeet.com (PGP Universal service); Wed, 29 Oct 2003 12:00:11 -0800 Date: Wed, 29 Oct 2003 12:00:08 -0800 Subject: Re: Meeting in Minneapolis? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: OpenPGP To: Derek Atkins From: Jon Callas In-Reply-To: Message-Id: <7F0B0CB4-0A4A-11D8-8107-000A9568596C@callas.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wednesday, October 29, 2003, at 09:03 AM, Derek Atkins wrote: > Well, I missed the deadline to request a timeslot, too.. So we wont be > meeting in MSP. HOWEVER I think we've been making a lot of progress > on the doc here on the list so let's continue along the existing path. > I think we can do that. Ideally, IETF working groups operate *completely* on the mailing lists. Alas, we do not live in an ideal world, and face-to-face meetings are desirable or necessary. However, this working group has been making progress for years without a meeting, and that, in my opinion, is not a bug, it's a feature. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TH6FkT029981 for ; Wed, 29 Oct 2003 09:06:15 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9TH6EIF029980 for ietf-openpgp-bks; Wed, 29 Oct 2003 09:06:14 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9TH6DkT029974 for ; Wed, 29 Oct 2003 09:06:13 -0800 (PST) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TH5LlP000820; Wed, 29 Oct 2003 12:06:09 -0500 (EST) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9TH3Zak004285; Wed, 29 Oct 2003 12:03:35 -0500 (EST) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h9TH3XEi002726; Wed, 29 Oct 2003 12:03:33 -0500 (EST) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h9TH3WZc003634; Wed, 29 Oct 2003 12:03:32 -0500 (EST) To: Jon Callas Cc: OpenPGP From: Derek Atkins Subject: Re: Meeting in Minneapolis? References: <18FA135B-09B7-11D8-8107-000A9568596C@callas.org> Date: 29 Oct 2003 12:03:32 -0500 In-Reply-To: <18FA135B-09B7-11D8-8107-000A9568596C@callas.org> Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > I won't be in Minneapolis. > > I stupidly thought the deadline for getting an I-D in was close of > business Monday, and not 9am Monday, so I blew it. Sorry. Well, I missed the deadline to request a timeslot, too.. So we wont be meeting in MSP. HOWEVER I think we've been making a lot of progress on the doc here on the list so let's continue along the existing path. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T6xVI7052871 for ; Tue, 28 Oct 2003 22:59:31 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T6xVDH052869 for ietf-openpgp-bks; Tue, 28 Oct 2003 22:59:31 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mtaw6.prodigy.net (mtaw6.prodigy.net [64.164.98.56]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T6xUI7052851 for ; Tue, 28 Oct 2003 22:59:30 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-237-131.dsl.pltn13.pacbell.net [68.122.237.131]) by mtaw6.prodigy.net (8.12.9/8.12.3) with ESMTP id h9T6x79e026504; Tue, 28 Oct 2003 22:59:08 -0800 (PST) Message-Id: <5.2.0.9.0.20031028221000.03e6a5f8@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 22:59:31 -0800 To: David Shaw From: Trevor Perrin Subject: Re: Back-signatures, part II Cc: ietf-openpgp@imc.org In-Reply-To: <20031029055833.GB20489@jabberwocky.com> References: <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:58 AM 10/29/2003 -0500, David Shaw wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Tue, Oct 28, 2003 at 08:18:50PM -0800, Trevor Perrin wrote: > > > > At 05:23 PM 10/28/2003 -0500, David Shaw wrote: > > > > >I just checked over my notes about back-signatures, and there was a > > >second proposal to solve the same problem. For completeness, here is > > >the other proposal. > > > > > >To repeat the problem: it is possible for an attacker to take a > > >signing subkey from a victim's key and attach this signing subkey to > > >the attacker's own key. The attacker does this by issuing a new > > >binding signature on the subkey from his own primary key. The end > > >result is that a signature issued by this signing subkey may be > > >claimed to be from either the attacker or the victim. > > > > Does this attack also work if the attacker issues a subkey binding > > signature on the victim's *primary* key, so as to claim signatures issued > > by this primary key? > >You mean take the victim's primary signing key, transform it into a >signing subkey and bind it to the attacker's primary key? Yes, the >attack would still work, but either of the proposed fixes still >prevents it. [...] I think you're right. > > I don't want to re-confuse an issue you've just clarified, but here's a > > generalization of the second proposal that might be worth considering: > > > > You could include in *every* signature a subpacket that contains a hash of > > *all* enclosing context. By "enclosing context" I mean the key packet for > > the primary key, along with its self-signatures, and the key packet for > the > > subkey as well (if the signing key is a subkey) along with the subkey > > binding signature. > > > > This would protect against the above attack, and some other manipulations, > > such as: > > > > - A naive user re-uses the same subkey under 2 different primary > > keys. Signatures performed by the subkey can't be confined to being under > > one or the other primary key. This problem can be easily avoided: just > > don't re-use keys, but that caveat would be unnecessary if signatures > > committed to their enclosing context. > >I don't see this as a problem, actually. So what if a user uses the >same subkey under two different primaries? The user controls the >subkey, and so can issue valid back-signatures (or fingerprint >subpackets). The owner of a subkey can do what they like with it. The problem arises when the user signs a document with the subkey, and wants this signature to be under one of his particular primaries. Say he has Work and Personal primary keys. He signs something and wants to indicate that it's under his Work primary key. He could include the Signer's User ID in the signature, but what if both primaries have the same User ID? If every signature committed to all previous context, then the verifier could always recognize that this signature was performed under a particular primary key, so there wouldn't be ambiguous cases like this. > > - Attacker generates a key that verifies a signature issued by someone > > else [1], then puts this key on a key server where a victim finds it, and > > assumes that since it verifies the signature correctly, it must belong to > > the originator of the message. There's caveats that make this attack > hard, > > and not very useful [1]. Still, it could be avoided entirely if the key > > used to create a signature was hashed as input to the signature. > >Hmm. I think I see where you are going with this, but isn't this sort >of the same problem as the "stolen primary that is kept as a primary" >above? I can steal a primary key and add a user ID and bribe someone >to sign it (since I can't sign it myself of course). Just because >I've constructed a key that can verify a signature doesn't mean that I >issued that signature. You're right, and as long as users keep that in mind, they're safe. But there's the rub. It's unintuitive that you can generate a key that verifies someone else's signature. And when things are unintuitive, there's room for users to screw up. I.e.: a user who receives a signed message through some secure channel (say someone hands them a message on a floppy disk), might then retrieve a key through an *un*secure channel, and attempt to validate the key by verifying the message with it. You can say: the user screwed up, we can't help him. But if the signature covered the public key that produced it, then the user's naive assumption would be correct, and his behavior would be safe. The issuer key ID subpacket makes an attack hard, though, because the attacker would have to try ~ 2^64 trial keys that verify the signature, before discovering one that *also* has the right issuer key ID. But if the signature covered the public key with a full hash, an attack would be even harder. > Or forget computer trickery at all: I can just >get myself a fake ID that says I am "Trevor Perrin" ;) The trickery I'm envisioning is where a naive verifier tries to validate a key by using it to verify a message that was received over some secure channel. > > - Attacker fiddles the timestamp in someone's primary-key packet, so that > > the key still verifies the signature correctly, but the sender appears to > > have a different fingerprint than he really does. > >This would break all signatures on the key, including the >self-signatures. I think that would give the attack away. That's true. As long as primary keys have self-signatures, and verifiers are required to check them before doing anything else with the key, that stops this. Basically, I just like the idea of having signatures cover all relevant context. So I was trying to find some trickery that would justify doing this. The trickery isn't very good, but there's trickier people than me out there.. So I dunno, I'm not sure how to balance the costs and benefits here, I just wanted to toss this out. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T5wXI7027480 for ; Tue, 28 Oct 2003 21:58:33 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T5wXDs027479 for ietf-openpgp-bks; Tue, 28 Oct 2003 21:58:33 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T5wWI7027469 for ; Tue, 28 Oct 2003 21:58:32 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9T5wXR12575; Wed, 29 Oct 2003 00:58:33 -0500 Date: Wed, 29 Oct 2003 00:58:33 -0500 From: David Shaw To: Trevor Perrin Cc: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031029055833.GB20489@jabberwocky.com> Mail-Followup-To: Trevor Perrin , ietf-openpgp@imc.org References: <20031028222356.GA19100@jabberwocky.com> <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (17% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 28, 2003 at 08:18:50PM -0800, Trevor Perrin wrote: > > At 05:23 PM 10/28/2003 -0500, David Shaw wrote: > > >I just checked over my notes about back-signatures, and there was a > >second proposal to solve the same problem. For completeness, here is > >the other proposal. > > > >To repeat the problem: it is possible for an attacker to take a > >signing subkey from a victim's key and attach this signing subkey to > >the attacker's own key. The attacker does this by issuing a new > >binding signature on the subkey from his own primary key. The end > >result is that a signature issued by this signing subkey may be > >claimed to be from either the attacker or the victim. > > Does this attack also work if the attacker issues a subkey binding > signature on the victim's *primary* key, so as to claim signatures issued > by this primary key? You mean take the victim's primary signing key, transform it into a signing subkey and bind it to the attacker's primary key? Yes, the attack would still work, but either of the proposed fixes still prevents it. The back-signature fix prevents this flavor of the attack since the attacker still could not use the stolen key (be it primary or subkey), to issue the back-signature. The include-the-fingerprint fix prevents this flavor of the attack as well. Since the key is a primary, existing signatures from the key would not contain the fingerprint subpacket at all, and would therefore be suspect. There are four basic permutations of this attack: 1) Attacker steals a subkey and keeps it as a subkey. Either fix works here. 2) Attacker steals a primary and makes it into a subkey. Either fix works here. 3) Attacker steals a subkey and makes it into a primary. Neither fix is relevant here since the attacker would be unable to bind a user ID to such a primary key. Without a bound user ID, it would be difficult at best to get such a key trusted. 4) Attacker steals a primary and keeps it as a primary. Neither fix is relevant here either, for the same reason as #3. > >Second proposed solution: on all signatures issued by a signing > >subkey, include a copy of the fingerprint of the primary key that > >"owns" this subkey. An attacker cannot issue signatures from the > >stolen subkey at all, so is foiled. > > I don't want to re-confuse an issue you've just clarified, but here's a > generalization of the second proposal that might be worth considering: > > You could include in *every* signature a subpacket that contains a hash of > *all* enclosing context. By "enclosing context" I mean the key packet for > the primary key, along with its self-signatures, and the key packet for the > subkey as well (if the signing key is a subkey) along with the subkey > binding signature. > > This would protect against the above attack, and some other manipulations, > such as: > > - A naive user re-uses the same subkey under 2 different primary > keys. Signatures performed by the subkey can't be confined to being under > one or the other primary key. This problem can be easily avoided: just > don't re-use keys, but that caveat would be unnecessary if signatures > committed to their enclosing context. I don't see this as a problem, actually. So what if a user uses the same subkey under two different primaries? The user controls the subkey, and so can issue valid back-signatures (or fingerprint subpackets). The owner of a subkey can do what they like with it. > - Attacker generates a key that verifies a signature issued by someone > else [1], then puts this key on a key server where a victim finds it, and > assumes that since it verifies the signature correctly, it must belong to > the originator of the message. There's caveats that make this attack hard, > and not very useful [1]. Still, it could be avoided entirely if the key > used to create a signature was hashed as input to the signature. Hmm. I think I see where you are going with this, but isn't this sort of the same problem as the "stolen primary that is kept as a primary" above? I can steal a primary key and add a user ID and bribe someone to sign it (since I can't sign it myself of course). Just because I've constructed a key that can verify a signature doesn't mean that I issued that signature. Or forget computer trickery at all: I can just get myself a fake ID that says I am "Trevor Perrin" ;) > - Attacker fiddles the timestamp in someone's primary-key packet, so that > the key still verifies the signature correctly, but the sender appears to > have a different fingerprint than he really does. This would break all signatures on the key, including the self-signatures. I think that would give the attack away. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+fVwkqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJ0ioAni/Lsc020UT+NVctLArQCiOILEASAJwP Zag9klK/40ZIkJIpquahISa9Aw== =5Xdy -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T5cxI7026675 for ; Tue, 28 Oct 2003 21:38:59 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T5cxHF026674 for ietf-openpgp-bks; Tue, 28 Oct 2003 21:38:59 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mx1.cryptohill.net (ns1.cryptohill.net [24.244.145.2]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T5cwI7026669 for ; Tue, 28 Oct 2003 21:38:58 -0800 (PST) (envelope-from iang@systemics.com) Received: from systemics.com (localhost [127.0.0.1]) by mx1.cryptohill.net (Postfix) with ESMTP id C8CFE69A81; Wed, 29 Oct 2003 00:39:00 -0500 (EST) Message-ID: <3F9F51B1.8E8356A4@systemics.com> Date: Wed, 29 Oct 2003 00:35:45 -0500 From: Ian Grigg Reply-To: iang@systemics.com X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.2 i386) X-Accept-Language: en MIME-Version: 1.0 To: Marc Mutz Cc: ietf-openpgp@imc.org Subject: Re: OpenPGP and IDNA/IMAA References: <200310281708.26191@mail.marc-mutz.de> 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: Marc Mutz wrote: ... > OpenPGP UIDs are essentially free-form, Yes, this is one of the advantages of OpenPGP over other PKI contenders. It says nothing about how the UserIds are handled. Which means we are free to design the contents to suit our requirements. It's certainly a key benefit for my company's use. You can't pay enough money to get that sort of design feature! > but with the > Name (Comment) > convention for interop. > > The whole string is in utf-8. This opens up two possible ways to encode > a IDN (or an internationalized email address later) in the UID: > > 1. In ACE form (ASCII compatible encoding) > 2. In UTF-8 ... > In any case, I think that rfc 2440bis as an IETF protocol that uses > UTF-8 needs to include at least a stringprep profile to use. I'm no > IETF expert, though, and it may suffice to reuse whatever comes out of > IMAA, but that's still at least half a year away. > > If nothing is said and it's accepted as such, then the slot is > automatically an IDNA-unaware one, to be filled with the ACE form. I think the key word here is _convention_. If there was a desire to document that and other conventions more clearly, than an adjunct informational track RFC may be a better bet than putting it into the base RFC. That way, applications could be aware of the convention, but can happily know that any other form is also quite acceptable. iang Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T52kI7025534 for ; Tue, 28 Oct 2003 21:02:46 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T52k01025533 for ietf-openpgp-bks; Tue, 28 Oct 2003 21:02:46 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T52iI7025528 for ; Tue, 28 Oct 2003 21:02:45 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9T52lE11796 for ietf-openpgp@imc.org; Wed, 29 Oct 2003 00:02:47 -0500 Date: Wed, 29 Oct 2003 00:02:47 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II Message-ID: <20031029050247.GA11625@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20031028222356.GA19100@jabberwocky.com> <3F9F3539.5000407@the-youngs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <3F9F3539.5000407@the-youngs.org> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (19% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 28, 2003 at 10:34:17PM -0500, Michael Young wrote: > > I don't feel all that strongly about this -- in fact, I don't > consider the problem all that serious in the first place -- but > I do find the properties of the cross-signature subpacket > solution more attractive. I think I do as well. I like that it handles old signatures, and I'm not yet convinced that the include-the-fingerprint covers all of the attacks that the back-signature does. > Also, note that the specification already provides a "signer userId" > subpacket that could be used to nearly the same effect as a "signer > primary fingerprint" subpacket. As I recall, the very first proposal > was to recommend/require the use of the existing "signer userId" > subpacket. Nearly the same effect, yes, but ultimately a different problem. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+fSfcqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJvzsAn1pGb8SPcWHssnbVQKncJRx+hlGFAKDd Kro5CviMXOZpFmfuy4xuQId8fw== =zgtR -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4l2I7024486 for ; Tue, 28 Oct 2003 20:47:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4l2uR024484 for ietf-openpgp-bks; Tue, 28 Oct 2003 20:47:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4l1I7024479 for ; Tue, 28 Oct 2003 20:47:01 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9T4l4H11593 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 23:47:04 -0500 Date: Tue, 28 Oct 2003 23:47:04 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal Message-ID: <20031029044704.GA20489@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20031028163528.GA6792@jabberwocky.com> <3F9EE602.90809@the-youngs.org> <20031028222954.GB19100@jabberwocky.com> <3F9F386B.9060600@the-youngs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <3F9F386B.9060600@the-youngs.org> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (17% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Oct 28, 2003 at 10:47:55PM -0500, Michael Young wrote: > > > I think it really depends on what the signature-in-a-subpacket is > > being used for. For the back-signature, it probably doesn't need > > any subpackets. At the same time, it doesn't hurt to include them. > > Does it matter very much? > > Yes, I was referring specifically to subkey cross-signatures. > Including subpackets, particularly issuerId, is just wasteful > in this situation. (They're pretty wasteful on binding signatures, > too; one might argue that they could help correct a shuffled > packet sequence, but that's a stretch.) I'd like to see > recommendations for each flavor of signature that reflect > real needs. I think that is straying into overkill. If there is no security or protocol correctness issue at hand, just say nothing. Let's credit implementors with some ability to know which subpackets are useful for a given purpose. We don't need an RFC, written with no knowledge of the internal code of a given implementation, to proclaim that an issuer ID might not be necessary - especially since the presence of that same issuer ID harms nobody. Also, an issuer ID - at worst - is 14 bytes long. If you really want to save some space on keys, we should issue guidelines on how large a photo ID should be ;) David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+fRkgqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJiGYAoIncvQEOycutdXfAJh1jzbN4BxnFAKDR BFyge/Ra52CP7BKdFY4M5+pQPQ== =zuFN -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4YuI7023971 for ; Tue, 28 Oct 2003 20:34:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4YudD023970 for ietf-openpgp-bks; Tue, 28 Oct 2003 20:34:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4YtI7023956 for ; Tue, 28 Oct 2003 20:34:55 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-237-131.dsl.pltn13.pacbell.net [68.122.237.131]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h9T4YvA6004907; Tue, 28 Oct 2003 20:34:57 -0800 (PST) Message-Id: <5.2.0.9.0.20031028202840.03e6e5e8@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 20:34:55 -0800 To: Michael Young , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <3F9F3539.5000407@the-youngs.org> References: <20031028222356.GA19100@jabberwocky.com> <20031028222356.GA19100@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:34 PM 10/28/2003 -0500, Michael Young wrote: [...] >Also, note that the specification already provides a "signer userId" >subpacket that could be used to nearly the same effect as a "signer >primary fingerprint" subpacket. I think that would prevent the version of this where the attacker tries to convince the verifier that the signed message came from his *name*. It wouldn't prevent the version where the attacker tries to convince the verifier that the signed message came from his *key*, which is what using a key fingerprint adds. Trevor Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4IpI7023450 for ; Tue, 28 Oct 2003 20:18:51 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4IpLC023449 for ietf-openpgp-bks; Tue, 28 Oct 2003 20:18:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta7.pltn13.pbi.net (mta7.pltn13.pbi.net [64.164.98.8]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4InI7023444 for ; Tue, 28 Oct 2003 20:18:49 -0800 (PST) (envelope-from trevp@trevp.net) Received: from TREVOR.trevp.net (adsl-68-122-237-131.dsl.pltn13.pacbell.net [68.122.237.131]) by mta7.pltn13.pbi.net (8.12.9/8.12.3) with ESMTP id h9T4IpA6004518; Tue, 28 Oct 2003 20:18:52 -0800 (PST) Message-Id: <5.2.0.9.0.20031028190402.03e6e5e8@pop.sbcglobal.yahoo.com> X-Sender: trevorperrin@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 28 Oct 2003 20:18:50 -0800 To: David Shaw , ietf-openpgp@imc.org From: Trevor Perrin Subject: Re: Back-signatures, part II In-Reply-To: <20031028222356.GA19100@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 05:23 PM 10/28/2003 -0500, David Shaw wrote: >I just checked over my notes about back-signatures, and there was a >second proposal to solve the same problem. For completeness, here is >the other proposal. > >To repeat the problem: it is possible for an attacker to take a >signing subkey from a victim's key and attach this signing subkey to >the attacker's own key. The attacker does this by issuing a new >binding signature on the subkey from his own primary key. The end >result is that a signature issued by this signing subkey may be >claimed to be from either the attacker or the victim. Does this attack also work if the attacker issues a subkey binding signature on the victim's *primary* key, so as to claim signatures issued by this primary key? >Second proposed solution: on all signatures issued by a signing >subkey, include a copy of the fingerprint of the primary key that >"owns" this subkey. An attacker cannot issue signatures from the >stolen subkey at all, so is foiled. I don't want to re-confuse an issue you've just clarified, but here's a generalization of the second proposal that might be worth considering: You could include in *every* signature a subpacket that contains a hash of *all* enclosing context. By "enclosing context" I mean the key packet for the primary key, along with its self-signatures, and the key packet for the subkey as well (if the signing key is a subkey) along with the subkey binding signature. This would protect against the above attack, and some other manipulations, such as: - A naive user re-uses the same subkey under 2 different primary keys. Signatures performed by the subkey can't be confined to being under one or the other primary key. This problem can be easily avoided: just don't re-use keys, but that caveat would be unnecessary if signatures committed to their enclosing context. - Attacker generates a key that verifies a signature issued by someone else [1], then puts this key on a key server where a victim finds it, and assumes that since it verifies the signature correctly, it must belong to the originator of the message. There's caveats that make this attack hard, and not very useful [1]. Still, it could be avoided entirely if the key used to create a signature was hashed as input to the signature. - Attacker fiddles the timestamp in someone's primary-key packet, so that the key still verifies the signature correctly, but the sender appears to have a different fingerprint than he really does. These aren't a big deal, but it just seems a good principle, in general, for signatures to cover as much context as is needed to properly interpret them. Trevor [1] sci.crypt thread: Choosing key to verify someone else's sig? Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3mWI7022045 for ; Tue, 28 Oct 2003 19:48:32 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3mWwY022044 for ietf-openpgp-bks; Tue, 28 Oct 2003 19:48:32 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta11.adelphia.net (mta11.adelphia.net [68.168.78.205]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3mUI7022037 for ; Tue, 28 Oct 2003 19:48:31 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org ([24.50.162.44]) by mta11.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031029034831.ZHLR3704.mta11.adelphia.net@the-youngs.org> for ; Tue, 28 Oct 2003 22:48:31 -0500 Message-ID: <3F9F386B.9060600@the-youngs.org> Date: Tue, 28 Oct 2003 22:47:55 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal References: <20031028163528.GA6792@jabberwocky.com> <3F9EE602.90809@the-youngs.org> <20031028222954.GB19100@jabberwocky.com> In-Reply-To: <20031028222954.GB19100@jabberwocky.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > I think it really depends on what the signature-in-a-subpacket is > being used for. For the back-signature, it probably doesn't need > any subpackets. At the same time, it doesn't hurt to include them. > Does it matter very much? Yes, I was referring specifically to subkey cross-signatures. Including subpackets, particularly issuerId, is just wasteful in this situation. (They're pretty wasteful on binding signatures, too; one might argue that they could help correct a shuffled packet sequence, but that's a stretch.) I'd like to see recommendations for each flavor of signature that reflect real needs. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP584Z+c3iHYL8FknEQIiPwCgm4A5qIQe4+rG/VEK8OLMy7Ee9FAAoNN9 4/c0+JUqyniYgrne5w8E/nTO =KIIn -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3YpI7021461 for ; Tue, 28 Oct 2003 19:34:51 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T3YpL3021460 for ietf-openpgp-bks; Tue, 28 Oct 2003 19:34:51 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta3.adelphia.net (mta3.adelphia.net [68.168.78.181]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T3YoI7021453 for ; Tue, 28 Oct 2003 19:34:50 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org ([24.50.162.44]) by mta3.adelphia.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20031029033451.MJZM27221.mta3.adelphia.net@the-youngs.org> for ; Tue, 28 Oct 2003 22:34:51 -0500 Message-ID: <3F9F3539.5000407@the-youngs.org> Date: Tue, 28 Oct 2003 22:34:17 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures, part II References: <20031028222356.GA19100@jabberwocky.com> In-Reply-To: <20031028222356.GA19100@jabberwocky.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I don't feel all that strongly about this -- in fact, I don't consider the problem all that serious in the first place -- but I do find the properties of the cross-signature subpacket solution more attractive. If I did care about someone claiming my signatures as their own, I think I would care about old signatures as well. Under the per-message scheme, if I cared about old signatures, I'd have to find all of those signatures *and the associated documents* in order to reissue them, and then I'd have to deal with disseminating them. User agents that keep a "key ring" will likely verify a cross-signature only once, at the same time that they verify the subkey binding signature. It need not be a per-message cost. The same is true for the storage and transmission of the extra material. Yes, the cost is higher for a one-time verification... I can live with that. Also, note that the specification already provides a "signer userId" subpacket that could be used to nearly the same effect as a "signer primary fingerprint" subpacket. As I recall, the very first proposal was to recommend/require the use of the existing "signer userId" subpacket. I would have no objection to defining both mechanisms, to account for differing user needs. If I were forced to choose only one, I'd take cross-signatures, as it adds more value beyond what we have now. -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP581Gec3iHYL8FknEQKznwCgsEm4POcdbfmEFBuCceZRZizScPMAoJ5R hqISWew9KfD0m1/SLQOHnEtT =L15C -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T2P2I7018718 for ; Tue, 28 Oct 2003 18:25:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T2P2tC018717 for ietf-openpgp-bks; Tue, 28 Oct 2003 18:25:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T2P1I7018712 for ; Tue, 28 Oct 2003 18:25:02 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Tue, 28 Oct 2003 18:25:00 -0800 Received: from callas.org ([12.129.245.249]) by bletchley.merrymeet.com (PGP Universal service); Tue, 28 Oct 2003 18:25:02 -0800 Date: Tue, 28 Oct 2003 18:25:01 -0800 Subject: Re: Meeting in Minneapolis? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Jon Callas To: OpenPGP Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <18FA135B-09B7-11D8-8107-000A9568596C@callas.org> X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Saturday, October 25, 2003, at 07:54 PM, Derek Atkins wrote: > I think we have enough topics to discuss to warrant a meeting in > Minneapolis. I need to request a lot by noon on Tuesday, so let me > know if I'm missing anything. Currently I think we have the following > open issues from my reading of the mailing list: > > - Should we obsolete 1991? #219 > - 3rd party signatures #220 > - IDEA, v3-v4 algo. conflict #221 > - non-text User IDs #222 > - Need to update the charter (milestones) #29 > > Are there other open issues? Are there other PGP-related topics that > people want to discuss in Minneapolis? Let me know ASAP so I can > request a timeslot, and if you want to lead a discussion on some other > topic, please let me know (e.g. pfs, etc.) > > I'd really like to get 2440bis completed, so that's my #1 priority. > I won't be in Minneapolis. I stupidly thought the deadline for getting an I-D in was close of business Monday, and not 9am Monday, so I blew it. Sorry. If anyone wants to see the pre-pre-release -- I'll submit this Nov 10 -- send me email. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMi0I7010021 for ; Tue, 28 Oct 2003 14:44:00 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMi0AI010020 for ietf-openpgp-bks; Tue, 28 Oct 2003 14:44:00 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMhxI7010015 for ; Tue, 28 Oct 2003 14:43:59 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9SMi0O19610; Tue, 28 Oct 2003 17:44:00 -0500 Date: Tue, 28 Oct 2003 17:44:00 -0500 From: David Shaw To: ietf-openpgp@imc.org Cc: poiboy@SAFe-mail.net Subject: Re: 3rd-party Signatures in a One-Pass Signed Message Message-ID: <20031028224400.GC19100@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org, poiboy@SAFe-mail.net References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (16% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 28, 2003 at 10:15:48PM +0000, poiboy@SAFe-mail.net wrote: > Since a notarization of a [target] signature signs the target's > packet body (irrespective of hashed or unhashed portions), the > notarization-in-a-subpacket will (once settled) effectively sign > everything around itself and must be removed from the packet body > string before it can be verified (signatures-in-subpackets used for > subkey bindings don't have this feature because the subpacketed > signature did not target its own parent). I had expected that a notarization would not include any of the unhashed data from the original signature. After all, that data is not part of the original signature. Looking at the problem with this in mind, the notary signature doesn't have to be removed before verification since (being located in the unhashed section of the original signature), it isn't really there in the first place. > If this is correct and multiple notarizations of a given target body > do not happen sequentially using the same (evolving) target body > string, then verification will require figuring out the state of the > unhashed subpackets at the time the notarization in question was made > - a trial and error loop over each permutation. Using the methodology above, multiple notarizations of a given target body all have the same target body. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMTrI7009386 for ; Tue, 28 Oct 2003 14:29:53 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMTr1e009385 for ietf-openpgp-bks; Tue, 28 Oct 2003 14:29:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMTqI7009380 for ; Tue, 28 Oct 2003 14:29:52 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9SMTsF19478 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 17:29:54 -0500 Date: Tue, 28 Oct 2003 17:29:54 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal Message-ID: <20031028222954.GB19100@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20031028163528.GA6792@jabberwocky.com> <3F9EE602.90809@the-youngs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F9EE602.90809@the-youngs.org> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (16% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 28, 2003 at 04:56:18PM -0500, Michael Young wrote: > > I like the general proposal, for all of the reasons that David > listed. > > My only question is about the encoding of the cross-signature > subpacket contents. It could be anything from: > a full Signature packet (including packet header); to, > just the Signature packet contents; to, > a leaner form with just the required fields (hash algorithm > and signature MPIs), with the rest being assumed for the > hash computation in order to reuse that. > > I could live with any of these, but I lean toward the middle one. As do I, for reasons given below, as well as for reasons of simplicity. > If we do use a regular Signature packet (with or without header), > then I'd like to see a recommendation on what subpackets it should > contain. The usual rules don't apply: for example, the issuer is > known. I don't see a *need* for any subpackets, even creation time > (but I'm open to arguments). I think it really depends on what the signature-in-a-subpacket is being used for. For the back-signature, it probably doesn't need any subpackets. At the same time, it doesn't hurt to include them. Does it matter very much? I'd like to see the signature-in-a-subpacket used for other things like notary signatures. For that usage, the issuer and timestamp is relevant. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMNuI7009095 for ; Tue, 28 Oct 2003 14:23:56 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMNuBJ009094 for ietf-openpgp-bks; Tue, 28 Oct 2003 14:23:56 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMNtI7009089 for ; Tue, 28 Oct 2003 14:23:55 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9SMNum19431 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 17:23:56 -0500 Date: Tue, 28 Oct 2003 17:23:56 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Back-signatures, part II Message-ID: <20031028222356.GA19100@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (16% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just checked over my notes about back-signatures, and there was a second proposal to solve the same problem. For completeness, here is the other proposal. To repeat the problem: it is possible for an attacker to take a signing subkey from a victim's key and attach this signing subkey to the attacker's own key. The attacker does this by issuing a new binding signature on the subkey from his own primary key. The end result is that a signature issued by this signing subkey may be claimed to be from either the attacker or the victim. Second proposed solution: on all signatures issued by a signing subkey, include a copy of the fingerprint of the primary key that "owns" this subkey. An attacker cannot issue signatures from the stolen subkey at all, so is foiled. The details: 1) Define a new type of signature subpacket that consists of a fingerprint. 2) Include it on all subkey signatures as a hashed subpacket. (It must be hashed to be effective). Comments: 1) Unlike the subkey-signs-primary key solution, old signatures issued before this back-signature protection became available are NOT automatically protected. 2) Like the other solution, this does not require generating a new subkey. 3) Like the other solution, this uses a signature subpacket so there should be no backward compatibility problems. 4) This is simpler than the other solution in several ways (less code to do it, for one, does not require the key to be modified and redistributed, for two). 5) This is likely to be faster than the other solution, as it only requires two signature verifications (the data in question plus the subkey binding signature) rather than three (the data in question, the subkey binding signature, and the back-signature). 6) It will no longer be possible to issue a v3 signature from a signing subkey. I don't see this as a major problem since the older programs that don't understand v4 signatures don't understand signatures from signing subkeys anyway. Comparing the two proposals seems to be a wash. Back-signatures are a bit slower, but protect existing signatures. Including a fingerprint is a bit faster, but does not protect existing signatures. Perhaps speed and simplicity should win out here. Speaking as someone who regularly uses a signing subkey, I don't particularly care if my old signatures are protected or not. I obviously can't speak for everyone using a signing subkey though. Again, comments welcome. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMFsI7008655 for ; Tue, 28 Oct 2003 14:15:54 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SMFrZs008654 for ietf-openpgp-bks; Tue, 28 Oct 2003 14:15:53 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.safe-mail.net (tapuz.safe-mail.net [212.68.149.115]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SMFqI7008649 for ; Tue, 28 Oct 2003 14:15:52 -0800 (PST) (envelope-from poiboy@SAFe-mail.net) Received: from poiboy@SAFe-mail.net by www.safe-mail.net with SAFe-mail (Exim 4.20) id 1AEc7w-0002Jb-Va; Tue, 28 Oct 2003 17:15:48 -0500 Received: from pc ([66.91.42.66]) by mail.SAFe-mail.net Subject: Re: 3rd-party Signatures in a One-Pass Signed Message Date: Tue, 28 Oct 2003 22:15:48 +0000 From: poiboy@SAFe-mail.net To: dshaw@jabberwocky.com CC: ietf-openpgp@imc.org X-SMType: Regular X-SMRef: N1-SvYWhTcM Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> how about just putting the 0x50 signature as an unhashed >> subpacket on the signature that that the 0x50 signature covers? My concern was over the ability to form an "explicitly notarized message." I'd prefer to distinguish a notarized document (meaning "that document whose signatures are collectively notarized") as such rather than determine the degree of notarized-ness using signature subpackets. But I think it's just a question of focus: When will the notarization of signatures deserve more attention (or priority in computation) than the signatures themselves? I'm imagining something like: 10,000 people sign a petition and a notary declares that these signatures were made prior to some deadline. - The notarization is (should be) inseperable from the signature list. - Hierarchical notarizations need target only the last notary packet. Where this special consideration is not deserved I agree that a more general mechanism (like signatures-in-subpackets) should be applied. >> you can trivially generate notary sigs of notary sigs of notary >> sigs as many levels as you care to, AND it shouldn't affect any >> currently deployed code. As I understand the mechanics of the signature-in-a-subpacket: Since a notarization of a [target] signature signs the target's packet body (irrespective of hashed or unhashed portions), the notarization-in-a-subpacket will (once settled) effectively sign everything around itself and must be removed from the packet body string before it can be verified (signatures-in-subpackets used for subkey bindings don't have this feature because the subpacketed signature did not target its own parent). If this is correct and multiple notarizations of a given target body do not happen sequentially using the same (evolving) target body string, then verification will require figuring out the state of the unhashed subpackets at the time the notarization in question was made - a trial and error loop over each permutation. Just wondering if this was to be taken in stride or if I've made a mistake. Mahalo for your suggestion, tha Poiboy PS. Off topic, out of scope, and by the way, it'd be nice to use 'v5' sigs which operate on whole packets no matter what, allowing one-pass notarizations to sign an unbroken string of target signature packets and simplifying 5.2.4. And I should add that my suggestion depends upon the 0x50 definition in 5.2.1 decscribing signatures on "signature packet(s)." Get rid of the '(s)' and wonders will cease. :) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLv2I7007068 for ; Tue, 28 Oct 2003 13:57:02 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SLv2j5007067 for ietf-openpgp-bks; Tue, 28 Oct 2003 13:57:02 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-02pt1.bluebird.ibm.com [129.42.208.182]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SLusI7007059 for ; Tue, 28 Oct 2003 13:57:01 -0800 (PST) (envelope-from mwy-opgp97@the-youngs.org) Received: from the-youngs.org (dhcp-197-43.transarc.ibm.com [9.38.197.43]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with ESMTP id QAA18194 for ; Tue, 28 Oct 2003 16:56:42 -0500 (EST) Message-ID: <3F9EE602.90809@the-youngs.org> Date: Tue, 28 Oct 2003 16:56:18 -0500 From: Michael Young User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Re: Back-signatures proposal References: <20031028163528.GA6792@jabberwocky.com> In-Reply-To: <20031028163528.GA6792@jabberwocky.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I like the general proposal, for all of the reasons that David listed. My only question is about the encoding of the cross-signature subpacket contents. It could be anything from: a full Signature packet (including packet header); to, just the Signature packet contents; to, a leaner form with just the required fields (hash algorithm and signature MPIs), with the rest being assumed for the hash computation in order to reuse that. I could live with any of these, but I lean toward the middle one. We may uncover a need for subpackets in the cross-signature itself, but it's hard to imagine wanting to use a different packet type (as opposed to signature *version*), and the length is absolutely redundant. [Note that the signature computation hashes a canonical header, not the actual one.] If we do use a regular Signature packet (with or without header), then I'd like to see a recommendation on what subpackets it should contain. The usual rules don't apply: for example, the issuer is known. I don't see a *need* for any subpackets, even creation time (but I'm open to arguments). -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBP57l6uc3iHYL8FknEQLpywCg9RM4ZmGdMwymtDmhRByKaMwywQMAn0Qf rnWryiBvTQJ0JA1huQQqCh81 =SW/6 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGZTI7092875 for ; Tue, 28 Oct 2003 08:35:29 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SGZTgN092874 for ietf-openpgp-bks; Tue, 28 Oct 2003 08:35:29 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGZRI7092869 for ; Tue, 28 Oct 2003 08:35:28 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9SGZSt07276 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 11:35:28 -0500 Date: Tue, 28 Oct 2003 11:35:28 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Back-signatures proposal Message-ID: <20031028163528.GA6792@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (14% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We had a fairly extensive discussion of back-signatures a few months back on this list. It seemed (at least to me) that we more or less came to an understanding as to a way to address the problem. I'm planning on writing up the solution more formally, but before I do so, I'd like a sanity check whether the problem and solution as I understand it agrees with the problem and solution as everyone else understands it. The problem: it is possible for an attacker to take a signing subkey from a victim's key and attach this signing subkey to the attacker's own key. The attacker does this by issuing a new binding signature on the subkey from his own primary key. The end result is that a signature issued by this signing subkey may be claimed to be from either the attacker or the victim. Proposed solution: have the signing subkey issue a signature on the primary key. This prevents the attacker stealing the victim's subkey since the attacker could not issue this signature. Any signing subkey without such a "back-signature" should be assumed to be suspect. The details: 1) Define a new type of signature subpacket that consists of a regular signature contained in a subpacket. 2) Define a new signature class (Hal suggested 0x19), that is defined as a subkey signature on a primary key. The hashing rules here are the same as a 0x1F signature - we hash the primary key, and issue a signature from the subkey over this hash. 3) At (sub)key generation time (or later, for existing keys) create this 0x19 signature and store it as a subpacket on the subkey binding signature. It does not matter whether it is a hashed subpacket or not. Some advantages: 1) Old signatures issued before this back-signature protection became available are automatically protected once the back-signature is added to a given key. 2) Storing the back-signature on the subkey binding signatures simplifies key maintenance. If a subkey is deleted, the back-signature does with it automatically, and the implementation doesn't have to search for and delete back-signatures elsewhere on the key. 3) Existing signing subkeys can easily have a back-signature added. It is not necessary to create new subkeys. 4) By storing the data as a signature subpacket (which are generally ignored if not recognized), we minimize the chance of compatibility problems with older implementations. Comments? David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGJwI7091752 for ; Tue, 28 Oct 2003 08:19:58 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9SGJw0a091751 for ietf-openpgp-bks; Tue, 28 Oct 2003 08:19:58 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mail.epost.de (mail.epost.de [193.28.100.187] (may be forged)) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9SGJvI7091744 for ; Tue, 28 Oct 2003 08:19:57 -0800 (PST) (envelope-from mutz@kde.org) Received: from [212.144.7.36] (212.144.7.36) by mail.epost.de (6.7.015) (authenticated as Marc.Mutz@epost.de) id 3F8A95B9001CDAB1 for ietf-openpgp@imc.org; Tue, 28 Oct 2003 17:19:54 +0100 From: Marc Mutz Organization: KDE To: ietf-openpgp@imc.org Subject: OpenPGP and IDNA/IMAA Date: Tue, 28 Oct 2003 17:07:59 +0100 User-Agent: KMail/1.5.93 X-PGP-Key: 0xBDBFE838 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_5Rpn/gghVJkmQy/"; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200310281708.26191@mail.marc-mutz.de> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Boundary-02=_5Rpn/gghVJkmQy/ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi! After getting IDNA (internationalized domain names in applications) out=20 as RFCs, people are now looking at the local-part of email addresses. How is the relevant to the OpenPGP spec? OpenPGP UIDs are essentially free-form, but with the Name (Comment) convention for interop. The whole string is in utf-8. This opens up two possible ways to encode=20 a IDN (or an internationalized email address later) in the UID: 1. In ACE form (ASCII compatible encoding) 2. In UTF-8 The ACE form (obtained from the Unicode form by IDNA's ToAscii=20 transformtion) would look a bit silly given that the slot is=20 Unicode-aware, but it would work out of the box if you enter it in=20 encoded form. The UTF-8 form might or might not work, depending on whether the=20 software used to create the key would validate the address according to=20 rfc 2822 or 2821 or simply encode the whole thing in UTF-8. In any case, I think that rfc 2440bis as an IETF protocol that uses=20 UTF-8 needs to include at least a stringprep profile to use. I'm no=20 IETF expert, though, and it may suffice to reuse whatever comes out of=20 IMAA, but that's still at least half a year away. If nothing is said and it's accepted as such, then the slot is=20 automatically an IDNA-unaware one, to be filled with the ACE form. Some pointers: 3454 Preparation of Internationalized Strings ("stringprep"). P. Hoffman, M. Blanchet. December 2002. (Format: TXT=3D138684 bytes) (Status: PROPOSED STANDARD) 3490 Internationalizing Domain Names in Applications (IDNA). P. Faltstrom, P. Hoffman, A. Costello. March 2003. (Format: TXT=3D51943 bytes) (Status: PROPOSED STANDARD) 3491 Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN). P. Hoffman, M. Blanchet. March 2003. (Format: TXT=3D10316=20 bytes) (Status: PROPOSED STANDARD) 3492 Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA). A. Costello. March 2003. (Format: TXT=3D67439 bytes) (Status: PROPOSED STANDARD) And discussions on ietf-imaa@imc.org and ietf-822@imc.org. Marc =2D-=20 It has become fashionable in the post Cold War world to label opponents as terrorists [...]. By doing so, the authorities instill within society a culture of fear, leading people to accept that their rights (and the rights of others) be trampled on for the sake of the common good. In other words, it justifies the loss of privacy and a state of surveillance they would otherwise not accept. Both communism and fascism were examples of this technique used to perfection. -- John Horvath: The Internet: A Terrorist Network? Telepolis 2001/08/22 (#9350) --Boundary-02=_5Rpn/gghVJkmQy/ Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQA/npR53oWD+L2/6DgRApWlAKCGiroGqthi7THsyyag1vXwW80OmACfWD7T sTcJp7jPdjh5bdvXYzahzoE= =oPwC -----END PGP SIGNATURE----- --Boundary-02=_5Rpn/gghVJkmQy/-- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4TbI7091853 for ; Mon, 27 Oct 2003 20:29:37 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9S4Tbqd091852 for ietf-openpgp-bks; Mon, 27 Oct 2003 20:29:37 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9S4TaI7091846 for ; Mon, 27 Oct 2003 20:29:36 -0800 (PST) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9S4TcS07682 for ietf-openpgp@imc.org; Mon, 27 Oct 2003 23:29:38 -0500 Date: Mon, 27 Oct 2003 23:29:38 -0500 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Meeting in Minneapolis? Message-ID: <20031028042938.GA4255@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (9% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Oct 25, 2003 at 10:54:30PM -0400, Derek Atkins wrote: > > Sorry I've been remiss in my duties as Chair recently. > > I think we have enough topics to discuss to warrant a meeting in > Minneapolis. I need to request a lot by noon on Tuesday, so let me > know if I'm missing anything. Currently I think we have the following > open issues from my reading of the mailing list: > > - Should we obsolete 1991? #219 > - 3rd party signatures #220 > - IDEA, v3-v4 algo. conflict #221 > - non-text User IDs #222 > - Need to update the charter (milestones) #29 > > Are there other open issues? Back-signatures from a signing subkey onto the primary key. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLxeI7076692 for ; Mon, 27 Oct 2003 13:59:40 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLxeUr076691 for ietf-openpgp-bks; Mon, 27 Oct 2003 13:59:40 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLxdI7076686 for ; Mon, 27 Oct 2003 13:59:39 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Mon, 27 Oct 2003 13:59:39 -0800 Received: from callas.org ([63.73.97.180]) by bletchley.merrymeet.com (PGP Universal service); Mon, 27 Oct 2003 13:59:40 -0800 Date: Mon, 27 Oct 2003 13:55:05 -0800 Subject: Re: RFC 3156, status of RFC 2015 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "John W. Noerenberg II" , Bob Braden , OpenPGP mailing list To: Derek Atkins From: Jon Callas In-Reply-To: Message-Id: <39505DF2-08C8-11D8-94B7-000A9568596C@callas.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Saturday, October 25, 2003, at 07:38 PM, Derek Atkins wrote: > Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the > document header on the first page. > Done. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLuLI7076570 for ; Mon, 27 Oct 2003 13:56:21 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLuLqL076569 for ietf-openpgp-bks; Mon, 27 Oct 2003 13:56:21 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLuKI7076564 for ; Mon, 27 Oct 2003 13:56:20 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Mon, 27 Oct 2003 13:56:20 -0800 Received: from callas.org ([63.73.97.180]) by bletchley.merrymeet.com (PGP Universal service); Mon, 27 Oct 2003 13:56:21 -0800 Date: Mon, 27 Oct 2003 13:55:05 -0800 Subject: Re: RFC 3156, status of RFC 2015 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "John W. Noerenberg II" , Bob Braden , OpenPGP mailing list To: Derek Atkins From: Jon Callas In-Reply-To: Message-Id: <39505DF2-08C8-11D8-94B7-000A9568596C@callas.org> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Saturday, October 25, 2003, at 07:38 PM, Derek Atkins wrote: > Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the > document header on the first page. > Done. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLqQI7076380 for ; Mon, 27 Oct 2003 13:52:26 -0800 (PST) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9RLqQRF076379 for ietf-openpgp-bks; Mon, 27 Oct 2003 13:52:26 -0800 (PST) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com ([63.73.97.162]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9RLqLI7076371 for ; Mon, 27 Oct 2003 13:52:21 -0800 (PST) (envelope-from jon@callas.org) Received: from bletchley.merrymeet.com (63.73.97.166) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Mon, 27 Oct 2003 13:52:18 -0800 Received: from callas.org ([63.73.97.180]) by bletchley.merrymeet.com (PGP Universal service); Mon, 27 Oct 2003 13:52:20 -0800 Date: Mon, 27 Oct 2003 13:51:37 -0800 Subject: Re: Non-textual User IDs Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-openpgp@imc.org To: David Shaw From: Jon Callas In-Reply-To: <20031021202427.GA5621@jabberwocky.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tuesday, October 21, 2003, at 01:24 PM, David Shaw wrote: > A User ID packet consists of UTF-8 text that is intended to > represent the name and email address of the key holder. By > convention, it includes an RFC 822 mail name, but there are no > restrictions on its content. The packet length in the header > specifies the length of the user id. > In other words, just removing the line about if it is text.... Done. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q2sYI7025836 for ; Sat, 25 Oct 2003 19:54:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q2sYoJ025835 for ietf-openpgp-bks; Sat, 25 Oct 2003 19:54:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q2sWI7025830 for ; Sat, 25 Oct 2003 19:54:32 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9Q2sYxu007243 for ; Sat, 25 Oct 2003 22:54:34 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9Q2sV9P002874 for ; Sat, 25 Oct 2003 22:54:31 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9Q2sU0I008017 for ; Sat, 25 Oct 2003 22:54:30 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h9Q2sUYv024470; Sat, 25 Oct 2003 22:54:30 -0400 (EDT) To: ietf-openpgp@imc.org Subject: Meeting in Minneapolis? From: Derek Atkins Date: 25 Oct 2003 22:54:30 -0400 Message-ID: Lines: 31 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Sorry I've been remiss in my duties as Chair recently. I think we have enough topics to discuss to warrant a meeting in Minneapolis. I need to request a lot by noon on Tuesday, so let me know if I'm missing anything. Currently I think we have the following open issues from my reading of the mailing list: - Should we obsolete 1991? #219 - 3rd party signatures #220 - IDEA, v3-v4 algo. conflict #221 - non-text User IDs #222 - Need to update the charter (milestones) #29 Are there other open issues? Are there other PGP-related topics that people want to discuss in Minneapolis? Let me know ASAP so I can request a timeslot, and if you want to lead a discussion on some other topic, please let me know (e.g. pfs, etc.) I'd really like to get 2440bis completed, so that's my #1 priority. -derek PS: I've also been asked to start using RT (https://rt.psg.com) to track open issues. I'm still learning the system and I don't (yet) have a process in place to automatically enter new issues. But we'll see how it goes. -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q2cRI7025108 for ; Sat, 25 Oct 2003 19:38:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9Q2cRtg025107 for ietf-openpgp-bks; Sat, 25 Oct 2003 19:38:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9Q2cQI7025102 for ; Sat, 25 Oct 2003 19:38:26 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9Q2cQxu003315; Sat, 25 Oct 2003 22:38:26 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h9Q2cL9P002492; Sat, 25 Oct 2003 22:38:21 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h9Q2cK0I007888; Sat, 25 Oct 2003 22:38:20 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h9Q2cJBp024438; Sat, 25 Oct 2003 22:38:19 -0400 (EDT) To: "John W. Noerenberg II" Cc: Bob Braden , OpenPGP mailing list From: Derek Atkins Subject: Re: Fwd: RFC 3156, status of RFC 2015 References: <200310241638.JAA27692@gra.isi.edu> Date: 25 Oct 2003 22:38:19 -0400 In-Reply-To: Message-ID: Lines: 37 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: "John W. Noerenberg II" writes: > At 9:38 AM -0700 10/24/03, Bob Braden wrote: > >suppose a specification was > >developed by an individual or organization outside the IETF process, > >but published as an Informational RFC. That often happens, in fact. > >Suppose that the IETF then takes this specification into the standards > >track, resulting in publication of a new version of the spec as a > >Proposed Standard. The PS will obsolete the Informational RFC. > > You raise a good point I hadn't considered. However, my original > question is still unanswered: > > "Can the WG chair request the Editor amend 2440 with the note that it > Obsoletes 1991?" It's not worth our time to worry about 2440. We can add the text to 2440bis and do it then. Jon: I believe a simple "Obsoletes: 1991, 2440" is sufficient in the document header on the first page. > Derek, I apologize for not doing so earlier, but I'll send you the > note which originated this discussion. To show how out-of-touch I've > become I didn't discover until today that you'd agreed to take on the > job WG Chair after I asked to step down. No need for you to appologize, John. The person who should really be appologizing is Alfred who completely mis-addressed his original email. -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OMWKI7098523 for ; Fri, 24 Oct 2003 15:32:20 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OMWKMK098522 for ietf-openpgp-bks; Fri, 24 Oct 2003 15:32:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OMWFI7098513 for ; Fri, 24 Oct 2003 15:32:16 -0700 (PDT) (envelope-from jwn2@qualcomm.com) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OMW34t028648; Fri, 24 Oct 2003 15:32:03 -0700 (PDT) Received: from [129.46.76.119] (valinor.qualcomm.com [129.46.76.119]) by mage.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id h9OMVuE2005197; Fri, 24 Oct 2003 15:31:56 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200310241638.JAA27692@gra.isi.edu> References: <200310241638.JAA27692@gra.isi.edu> X-Mailer: eudora61carbon-1023030837 X-Esp-OSX: 0924030905 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 24 Oct 2003 15:20:58 -0700 To: Bob Braden From: "John W. Noerenberg II" Subject: Re: Fwd: RFC 3156, status of RFC 2015 Cc: Derek Atkins , OpenPGP mailing list 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 9:38 AM -0700 10/24/03, Bob Braden wrote: >suppose a specification was >developed by an individual or organization outside the IETF process, >but published as an Informational RFC. That often happens, in fact. >Suppose that the IETF then takes this specification into the standards >track, resulting in publication of a new version of the spec as a >Proposed Standard. The PS will obsolete the Informational RFC. You raise a good point I hadn't considered. However, my original question is still unanswered: "Can the WG chair request the Editor amend 2440 with the note that it Obsoletes 1991?" Derek, I apologize for not doing so earlier, but I'll send you the note which originated this discussion. To show how out-of-touch I've become I didn't discover until today that you'd agreed to take on the job WG Chair after I asked to step down. -- john noerenberg jwn2@qualcomm.com ---------------------------------------------------------------------- A good traveller has no fixed plans and is not intent on arriving. -- Lao Tzu (c. 570-490 B.C.) ---------------------------------------------------------------------- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGsAI7087137 for ; Fri, 24 Oct 2003 09:54:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OGsA8s087136 for ietf-openpgp-bks; Fri, 24 Oct 2003 09:54:10 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGs0I7087129 for ; Fri, 24 Oct 2003 09:54:00 -0700 (PDT) (envelope-from jwn2@qualcomm.com) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OGqG4t008303; Fri, 24 Oct 2003 09:52:16 -0700 (PDT) Received: from [129.46.76.119] (valinor.qualcomm.com [129.46.76.119]) by mage.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id h9OGq9E4016570; Fri, 24 Oct 2003 09:52:13 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: In-Reply-To: <200310230940.LAA20266@TR-Sys.de> References: <200310230940.LAA20266@TR-Sys.de> X-Mailer: eudora61carbon-1023030837 X-Esp-OSX: 0924030905 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 24 Oct 2003 09:48:24 -0700 To: Alfred =?hp-roman8?B?SM5uZXM=?= From: "John W. Noerenberg II" Subject: Re: RFC 3156, status of RFC 2015 Cc: rfc-editor@rfc-editor.org, ddt@openpgp.org, Michael_Elkins@nai.com, raph@acm.org, roessler@does-not-exist.org, OpenPGP mailing list 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 11:40 AM +0200 10/23/03, Alfred =?hp-roman8?B?SM5uZXM=?= wrote: >studying the [Open]PGP RFCs, I found a distracting situation >concerning the status of these RFCs: Regarding 3156 and 2015, marking 2015 as Historic and obsoleted by 3156, and similarly, marking 3156 as obsoleting 2015 is a reasonable action. To be honest, I don't know if the IESG is required to recommend this action or if the RFC Editor can make this change at the WG's request (which I've made on behalf of the WG). In the past, Proposed RFCs that have been superceded by later RFCs linger as Proposed indefinitely instead of becoming Historic. For the sake of clarity your suggestion of marking 2015 as Historic is a good one, which is why I've requested the change. However, the common culture in the IETF is that a Proposed RFC which is obsolete is no longer relevant, so it's status on standards track is relatively harmless. 2440 does pay homage to 1991 in its text, but because 1991 is an Informational RFC and was never standards track, there's nothing for 2440 to obsolete. -- john noerenberg ---------------------------------------------------------------------- A good traveller has no fixed plans and is not intent on arriving. -- Lao Tzu (c. 570-490 B.C.) ---------------------------------------------------------------------- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGqDI7087079 for ; Fri, 24 Oct 2003 09:52:13 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9OGqDlC087078 for ietf-openpgp-bks; Fri, 24 Oct 2003 09:52:13 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from ithilien.qualcomm.com (ithilien.qualcomm.com [129.46.51.59]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9OGqCI7087072 for ; Fri, 24 Oct 2003 09:52:12 -0700 (PDT) (envelope-from jwn2@qualcomm.com) Received: from mage.qualcomm.com (mage.qualcomm.com [129.46.65.64]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id h9OGqC4t008296 for ; Fri, 24 Oct 2003 09:52:12 -0700 (PDT) Received: from [129.46.76.119] (valinor.qualcomm.com [129.46.76.119]) by mage.qualcomm.com (8.12.10/8.12.3/1.0) with ESMTP id h9OGq9E2016570 for ; Fri, 24 Oct 2003 09:52:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: jwn2@mage.qualcomm.com Message-Id: X-Mailer: eudora61carbon-1023030837 X-Esp-OSX: 0924030905 X-PGP-RSA-Fingerprint: EA53 01A6 C076 F9C2 09E8 9480 645A 8857 X-PGP-DH-Fingerprint: 4F5E 56C9 BD4D 0227 331F 6AEE 9590 24F9 6FD7 04F8 Date: Fri, 24 Oct 2003 09:46:15 -0700 To: OpenPGP mailing list From: "John W. Noerenberg II" Subject: Fwd: RFC 3156, status of RFC 2015 Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h9OGqCI7087074 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >From: Alfred =?hp-roman8?B?SM5uZXM=?= >Subject: RFC 3156, status of RFC 2015 >To: jwn2@qualcomm.com, rfc-editor@rfc-editor.org >Date: Thu, 23 Oct 2003 11:40:03 +0200 (MESZ) >Cc: ddt@openpgp.org, Michael_Elkins@nai.com, raph@acm.org, > roessler@does-not-exist.org >X-Mailer: ELM [$Revision: 1.17.214.3 $] >Mime-Version: 1.0 > >studying the [Open]PGP RFCs, I found a distracting situation >concerning the status of these RFCs: > >RFC 3156 is a complete re-write and update of RFC 2015, hence it >effectively "obsoletes" RFC 2015. But, unfortunately, the header >of RFC 2015 states: "Updates: 2015", and not: "Obsoletes: 2015". >Consequentially, the RFC index, "rfc-index.txt", currently contains >the tags > (UPDATED BY 3156) for RFC 2015, and > (UPDATES 2015) for RFC 3156, >which effectively should be > (OBSOLETED BY 3156) for RFC 2015, and > (OBSOLETES 2015) for RFC 3156 . > >Moreover, RFC 2015 effectively makes *normative* reference to >RFC 1991, an INFORMATIONAL RFC. Therefore it should never have >been placed onto the RFC Standards Track and classified as a >PROPOSED STANDARD. > >RFC 1991 in turn actually has been obsoleted by RFC 2440 - another >fact which (unfortunately) was not stated in the header of RFC 2440. > >Obviously, the current proposed OpenPGP standard is specified >in RFC 2440 (Message formats) and RFC 3156 (application of MIME), >which both are PROPOSED STANDARDs. > >Therefore, RFC 2015 should now be removed from the standards >track and the PROPOSED STANDARDS section of "rfcxx00.txt" . > > >Please perform the necessary actions to resolve this situation. > >Best regards, > Alfred H‘nes. > >-- > >+------------------------+--------------------------------------------+ >| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | >| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | >| D-71254 Ditzingen | E-Mail: ah@TR-Sys.de | >+------------------------+--------------------------------------------+ -- john noerenberg ---------------------------------------------------------------------- A good traveller has no fixed plans and is not intent on arriving. -- Lao Tzu (c. 570-490 B.C.) ---------------------------------------------------------------------- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKOWI7038925 for ; Tue, 21 Oct 2003 13:24:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LKOWS3038923 for ietf-openpgp-bks; Tue, 21 Oct 2003 13:24:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LKOUI7038904 for ; Tue, 21 Oct 2003 13:24:31 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9LKORG05943 for ietf-openpgp@imc.org; Tue, 21 Oct 2003 16:24:27 -0400 Date: Tue, 21 Oct 2003 16:24:27 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Non-textual User IDs Message-ID: <20031021202427.GA5621@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Crescent (18% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 2440 defines a User ID (section 5.11) as: A User ID packet consists of data that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 822 mail name, but there are no restrictions on its content. The packet length in the header specifies the length of the user id. If it is text, it is encoded in UTF-8. The various 2440bis drafts keep this same text. Suggestion: change the current specification of contents (which is mostly unspecified) to UTF8 text only. Rationale: The current language was written before the OpenPGP standard got attribute IDs. Attribute IDs are a significantly better way to incorporate arbitrary binary blobs into user IDs. A simple way to look at this is to note that any user ID that isn't UTF8 text is going to be implementation-dependent. Since it is implementation dependent anyway, implementors may as well use attribute packets which won't gum up the programs (all OpenPGP programs I've seen) that more or less do expect user IDs to be text. Suggested language: A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the key holder. By convention, it includes an RFC 822 mail name, but there are no restrictions on its content. The packet length in the header specifies the length of the user id. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHnYI7033314 for ; Tue, 21 Oct 2003 10:49:34 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9LHnYwi033313 for ietf-openpgp-bks; Tue, 21 Oct 2003 10:49:34 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9LHnUI7033303 for ; Tue, 21 Oct 2003 10:49:33 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h9LHnVD27292 for ietf-openpgp@imc.org; Tue, 21 Oct 2003 13:49:31 -0400 Date: Tue, 21 Oct 2003 13:49:31 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: 3rd-party Signatures in a One-Pass Signed Message Message-ID: <20031021174931.GA27199@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Crescent (19% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, Oct 03, 2003 at 06:41:29PM +0000, poiboy@SAFe-mail.net wrote: > > Hello all, > > My assumption: A 3rd-party signature (0x50) is/must be detached and > its handling is implementation-specific. It is true there is currently no language in the draft specifying how a 0x50 3rd-party or notary signature is handled, but I worry about the complexity of the proposed solution (extending the onepass functionality). When I suggested using a signature-in-a-subpacket to handle the need for a back-signature from a signing subkey to a main key, I mentioned that this basic idea could be useful in other places. 0x50 signatures seem to be a good place to use it: rather than extending onepass or parsing literal packets (which violate the idea of a *literal* packet), how about just putting the 0x50 signature as an unhashed subpacket on the signature that that the 0x50 signature covers? This gives a good bit of flexibility - it's clear which signature is being "notarized", and you can trivially generate notary sigs of notary sigs of notary sigs as many levels as you care to, AND it shouldn't affect any currently deployed code. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93JfbKP040364 for ; Fri, 3 Oct 2003 12:41:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h93Jfa4O040363 for ietf-openpgp-bks; Fri, 3 Oct 2003 12:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.safe-mail.net (tapuz.safe-mail.net [212.68.149.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h93JfYKP040357 for ; Fri, 3 Oct 2003 12:41:35 -0700 (PDT) (envelope-from poiboy@SAFe-mail.net) Received: from poiboy@SAFe-mail.net by www.safe-mail.net with SAFe-mail (Exim 4.20) id 1A5Vnt-0003Mx-FD for ietf-openpgp@imc.org; Fri, 03 Oct 2003 21:41:29 +0200 Received: from pc ([24.25.248.53]) by mail.SAFe-mail.net Subject: 3rd-party Signatures in a One-Pass Signed Message Date: Fri, 3 Oct 2003 18:41:29 +0000 From: poiboy@SAFe-mail.net To: ietf-openpgp@imc.org X-SMType: Regular X-SMRef: N1-OxansrD- Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hello all, My assumption: A 3rd-party signature (0x50) is/must be detached and its handling is implementation-specific. * 10.2 does not recognize a sequence of signature packets as a valid message, and 5.2.1 states that the 3rd-party signature is made over such a sequence. * See Mr. Shaw's previous posts (including example sigs, below). I'd like to work with 3rd-party signatures in a bona-fide (standard, accepted) message context. This is handled in one case.. Put the signed key sequence in a literal data packet. This buys message-parsing convenience at the expense of requiring a literal parser to sneak a peek at the "data that is not to be further interpreted." (5.9) ..and could be handled in at least a couple other ways: Accept single (standalone/detached) signature packets as a third type of Signed Message :- Signature Packet | Signature Packet, OpenPGP Message | One-Pass Signed Message. I don't like this because there are a number of signatures (0x10-13, 0x18, ..) which really don't make sense on their own and I don't think that message definitions should start digging into packet body attributes (in this case, the signature type). -or- Add an option to the One-Pass "nested" flag which means "this signature is applied to the signatures on the same level as the next." The nested flag ('n') is only defined for n=0, leaving other n values up to the imagination. In practice, the signature directly bordering the signed message is given n=1 ..effectively stating "this next thing is in my signed nest." I'd like to use an n=2 (n=x, whatever) option declaring "this next thing is in my signed /signature/ nest" - a statement which remains true for all one-pass signatures up to (and including) the one-pass packet with n=1: 1PASS_N(n=2), 1PASS_A(n=0), 1PASS_B(n=1), MSG, SIG_B, SIG_A, SIG_N A and B have independently signed MSG, and N signs the combination SIG_B + SIG_A. The 3rd-party signature needs only the signature sequence (SIG_B, SIG_A) at creation time *but can later be represented* in what amounts to a complete message "history." This method has an "explicit advantage" over hiding signature sequences in literal packets. Thoughts? Kudos? Tomatoes? Aloha, poiboy at safe-mail.net ref: http://www.imc.org/ietf-openpgp/mail-archive/msg04135.html http://www.imc.org/ietf-openpgp/mail-archive/msg04385.html