From owner-ietf-openpgp@mail.imc.org Tue Jul 4 12:40:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28974 for ; Tue, 4 Jul 2000 12:40:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22574 for ietf-openpgp-bks; Tue, 4 Jul 2000 09:20:31 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA22569 for ; Tue, 4 Jul 2000 09:20:29 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 16419 invoked from network); 4 Jul 2000 16:21:37 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 4 Jul 2000 16:21:37 -0000 To: ietf-openpgp@imc.org Subject: Re: Implementation doc. In-Reply-To: <4.3.0.20000630095636.00bae460@mail.comasp.com> References: <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> <4.3.0.20000630095636.00bae460@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000705012144I.1001@eccosys.com> Date: Wed, 05 Jul 2000 01:21:44 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 35 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit sorry for the late response. From: Erron Criddle Subject: Implementation doc. Date: Fri, 30 Jun 2000 10:26:19 +0800 Message-ID: <4.3.0.20000630095636.00bae460@mail.comasp.com> > Although implementation testing is very important and would require 2440bis > to remain reasonably static for the that to happen, it may be possible to > also implement a document in parallel that accompanies 2440 and would be > basically targeted at the implementor. This doc could provide > implementation guidelines in a "summarised" fashion and would refer to 2440 > for further understanding. > > Basically it would be targeted at implementors that are starting > from scratch. i am not so sure of what form the output of such a process should take -- but how about an "annotated rfc 2440" for starters? we can use whatever the latest document (bis or rfc) and provide annotations off of that for clarifying matters. perhaps some of the annotations can be merged in a future rfc if people think there are relevant points made. > One possible way to move ahead with this document is to make an FTP site > available so that anybody could upload their own "summaries" or > implementation notes. From this, we can then consolidate the information > and create another doc that is a basic guideline for implementing OpenPGP. i have no problem w/ the mechanism, but the "consolidator" of these notes may have to be in a position where looking at various implementation notes does not cause any legal difficulties (cf. the discussion of being able to claim that one truly created an independent implementation) -- unless some precautions are taken w.r.t. the content of what is uploaded. From owner-ietf-openpgp@mail.imc.org Wed Jul 5 03:57:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18482 for ; Wed, 5 Jul 2000 03:57:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21697 for ietf-openpgp-bks; Wed, 5 Jul 2000 00:42:26 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21689 for ; Wed, 5 Jul 2000 00:42:24 -0700 (PDT) Received: from [63.73.97.187] (63.73.97.187) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1d11); Wed, 5 Jul 2000 00:43:39 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000629194636M.1001@eccosys.com> References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> Date: Wed, 5 Jul 2000 00:21:38 -0700 To: ietf-openpgp@imc.org, sen_ml@eccosys.com From: Jon Callas Subject: Re: OpenPGP should be called ClosedPGP Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the things to remember about 2440 -- and stated in the document abstract -- is that it isn't a how-to guide for writing an application. It's a description of how the data is laid out, and (more or less) what it means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide." Lots of things are assumed in the document. For example, it's assumed you know what a cipher is. Many of the references to ciphers are pretty terse, and I know I wouldn't want to implement from it and it alone. Just last week, for example, someone pointed out to me that the reference for Triple-DES was dangling. We all looked around for a good reference to 3DES, and didn't come up with one! I was sure there was some RFC for it, myself, and there isn't. This is amusing, since 3DES is the cross-group defacto meta-standard algorithm in the IETF, and yet we don't have a good place to say, "Hey, here's how 3DES is done." I changed the 2440bis reference to point to Schneier, which is better than nothing, but still not great. As we find those things, we'll shoot them. Furthermore, there are things that we have agreed *not* to discuss here. A close reading of 2440 will display references to key servers, trust, and other things that are beyond its scope. Trust, in particular, is something that the working group agreed not to put into 2440. At that time, we agreed to let people write informational RFCs on various trust models. If someone wants to write an informational RFC, that's a good one. We've also discussed having implementation guides. That is also something that would be great to do. But I don't think you should do an annotated 2440 or a re-organized one. We want to get to Standard as quickly as possible, and there's already been a lot of work getting everyone to agree that what we have is reasonable, if not perfect. Jon From owner-ietf-openpgp@mail.imc.org Wed Jul 5 05:26:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18984 for ; Wed, 5 Jul 2000 05:26:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA27059 for ietf-openpgp-bks; Wed, 5 Jul 2000 02:11:11 -0700 (PDT) Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27047 for ; Wed, 5 Jul 2000 02:11:09 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id KAA15732; Wed, 5 Jul 2000 10:20:01 +0100 Message-ID: <3962FC3B.CFF633AC@algroup.co.uk> Date: Wed, 05 Jul 2000 10:13:31 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: Jon Callas CC: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> 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 Jon Callas wrote: > This is amusing, since 3DES is the cross-group defacto > meta-standard algorithm in the IETF, and yet we don't have a good place to > say, "Hey, here's how 3DES is done." I changed the 2440bis reference to > point to Schneier, which is better than nothing, but still not great. As we > find those things, we'll shoot them. If you are going to point at books, you should point at Menezes et al., too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ From owner-ietf-openpgp@mail.imc.org Wed Jul 5 07:17:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19979 for ; Wed, 5 Jul 2000 07:17:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04489 for ietf-openpgp-bks; Wed, 5 Jul 2000 03:57:14 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA04485 for ; Wed, 5 Jul 2000 03:57:13 -0700 (PDT) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Jul 2000 11:58:28 +0100 Message-ID: <3963142F.E8971209@cs.ucl.ac.uk> Date: Wed, 05 Jul 2000 11:55:43 +0100 From: Ian Brown X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Forward secrecy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I don't know how much everyone has seen of the UK government's current attempt to legislate for access to keys, but despite extreme opposition they seem set to push through powers for "information disclosure" orders that allow *any public authority* to demand keys (on pain of two years' imprisonment) and impose a gagging order that prevents you telling anyone but your lawyer (or go to jail for five years). Adam Back, Ben Laurie and I have been working on a draft that would allow OpenPGP software to minimise the damage such a notice could cause to a PGP user. It specifies mechanisms for using short-lifetime and one-time keys to limit the amount of information that becomes vulnerable after key compromise. John Noerenberg suggested we publish it as an informational RFC. We would be grateful for feedback from this group before we take that step. The current version is at http://www.cs.ucl.ac.uk/staff/I.Brown/openpgp-pfs.txt Thanks! Ian :) From owner-ietf-openpgp@mail.imc.org Thu Jul 6 02:29:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08474 for ; Thu, 6 Jul 2000 02:29:57 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA04085 for ietf-openpgp-bks; Wed, 5 Jul 2000 23:09:56 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA04081 for ; Wed, 5 Jul 2000 23:09:54 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 2712 invoked from network); 6 Jul 2000 06:11:06 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Jul 2000 06:11:06 -0000 To: ietf-openpgp@imc.org Subject: priority of clarity of specifications (was Re: OpenPGP should be called ClosedPGP) In-Reply-To: References: <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000706151123R.1001@eccosys.com> Date: Thu, 06 Jul 2000 15:11:23 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 95 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit thanks for the response. sorry for taking so long to reply. From: Jon Callas Subject: Re: OpenPGP should be called ClosedPGP Date: Wed, 5 Jul 2000 00:21:38 -0700 Message-ID: > One of the things to remember about 2440 -- and stated in the document > abstract -- is that it isn't a how-to guide for writing an application. > It's a description of how the data is laid out, and (more or less) what it > means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide." sure. i didn't miss out on that point. the kinds of changes i had in mind have more to do w/ the particular explanations, wording, order of introducing terms, etc. i found parts of the document difficult to understand and could be made easier to understand for others who are still struggling w/ the document and for future readers. i have pointed out some of these things that occurred to me already, but would it help to mention them again? some of the points have gone unaddressed, so i can only guess as to whether the points are irrelevant, ignored, forgotten, etc. as a side note, on other pgp-related mailing lists, i've seen people ask questions about pgp and they are then referred to rfc 2440. i imagine it could be rather tough for many of these folks to understand the rfc (it was for me, at least) -- perhaps some other document should exist for such situations. > Lots of things are assumed in the document. For example, it's assumed you > know what a cipher is. Many of the references to ciphers are pretty terse, > and I know I wouldn't want to implement from it and it alone. that's what i found when i first went through it. after sitting down w/ schneier's book though, i was able to make a lot more sense of the rfc, but even w/ improved understanding, i found sections hard to understand more because of issues such as wording. > Just last week, for example, someone pointed out to me that the > reference for Triple-DES was dangling. We all looked around for a > good reference to 3DES, and didn't come up with one! I was sure > there was some RFC for it, myself, and there isn't. This is amusing, > since 3DES is the cross-group defacto meta-standard algorithm in the > IETF, and yet we don't have a good place to say, "Hey, here's how > 3DES is done." perhaps it's time for an informational rfc for triple des then. but may be that's an issue that is more general than for just this working group... > I changed the 2440bis reference to point to Schneier, which is > better than nothing, but still not great. As we find those things, > we'll shoot them. out of curiosity, if schneier's book were freely available, then would that still be a problem? > Furthermore, there are things that we have agreed *not* to discuss here. A > close reading of 2440 will display references to key servers, trust, and > other things that are beyond its scope. it might be helpful to have a list of what is and isn't in scope in one place (say in the rfc or on among the working group web pages) -- this might make it clearer for those who weren't around for the discussions. i assume that newcomers are not unwelcome. > We've also discussed having implementation guides. That is also something > that would be great to do. i think that would be interesting and worthwhile, but i'm not primarily concerned w/ an implementation guide at this point. > But I don't think you should do an annotated 2440 or a re-organized > one. i hear you, but i guess i don't see why an annotated version would be a bad idea. what kind of downside is there in producing such a thing? > We want to get to Standard as quickly as possible, and there's > already been a lot of work getting everyone to agree that what we > have is reasonable, if not perfect. what concerns me is that the standard that we get may be harder to understand than necessary (i think it already is). as has been pointed out on numerous occasions already, the format is already fairly complex (compared to what might be produced if one were to start from scratch -- i am not suggesting that compatibility issues be ignored, just clarifying my statement). i would think that particularly in an area that is so focused on security that one would want the format to be as simple as possible and the descriptions to be as clear as possible to prevent misunderstandings that might lead to misuse or misimplementation and consequently to security problems. my impression is that this does not appear to be a high priority. am i mistaken? From owner-ietf-openpgp@mail.imc.org Thu Jul 6 04:06:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09394 for ; Thu, 6 Jul 2000 04:06:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA06930 for ietf-openpgp-bks; Thu, 6 Jul 2000 00:48:01 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA06926 for ; Thu, 6 Jul 2000 00:47:59 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 4717 invoked from network); 6 Jul 2000 07:49:12 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Jul 2000 07:49:12 -0000 To: ietf-openpgp@imc.org Subject: Re: Forward secrecy In-Reply-To: <3963142F.E8971209@cs.ucl.ac.uk> References: <3963142F.E8971209@cs.ucl.ac.uk> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000706164929Y.1001@eccosys.com> Date: Thu, 06 Jul 2000 16:49:29 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 66 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Ian Brown Subject: Forward secrecy Date: Wed, 05 Jul 2000 11:55:43 +0100 Message-ID: <3963142F.E8971209@cs.ucl.ac.uk> > John Noerenberg suggested we publish it as an informational RFC. We would > be grateful for feedback from this group before we take that step. here are some comments: -this document seems to be focused on the use of openpgp for mail in particular. is there anything to be said for other uses? (e.g. openpgp key usage in ssh) -section 2.1 says: Key distribution can be eased by submitting new keys to key servers, where they will be available for other users to retrieve. Submission and retrieval SHOULD be performed automatically by software. Expired public encryption keys MUST be deleted by users and keyservers to remove information on old key pairs. Expired private encryption keys MUST be securely deleted to prevent later compromise. i think whether the key distribution should happen automatically should be a matter of policy. some of us have keypairs of which the public portion is not really made widely public, nor do we want it to be made so. perhaps such relevant policy can be expressed in the key and implementations could interpret it appropriately. i wonder how much success one will have w/ convincing the keyserver folks that they should delete expired public keys. i would like the ability to be able to tell a keyserver to remove a public key for which i have the corresponding secret key (or may be even the typically existing email address), but i don't get the impression that it's a popular idea thing among implementors. -section 2.2 says: Before an OpenPGP client exports a private key as plaintext, the associated public key MUST be revoked and redistributed. i think i see a good reason for this, but i wonder whether it is practical. doesn't redistribution of the key require net access? to implement this correctly, when requested to export a private key as plaintext, the implementation first revokes the key, then redistributes the key by sending it to the keyservers, and then exports the private key (perhaps after confirming that the redistribution has been successful). if it cannot contact a keyserver (or verify that redistribution was successful), a correct implementation would not export the private key as plaintext, i presume. perhaps i'm nitpicking... also, which takes precedence, the deletion of expired keys from keyservers or the distribution of revoked keys? is this also a matter of policy that could be reflected in the key? -how about saying "attackers" instead of "hackers" in section 6? -how about some "secure deletion" references in the references section? off-topic: how about you guys write an informational rfc that suggests best practice methods for email message header confidentiality ;-) From owner-ietf-openpgp@mail.imc.org Thu Jul 6 15:11:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23716 for ; Thu, 6 Jul 2000 15:11:57 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA27776 for ietf-openpgp-bks; Thu, 6 Jul 2000 11:49:32 -0700 (PDT) Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27772 for ; Thu, 6 Jul 2000 11:49:30 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA00156; Thu, 6 Jul 2000 19:59:01 +0100 Message-ID: <3964D551.DB1D6179@algroup.co.uk> Date: Thu, 06 Jul 2000 19:52:01 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: sen_ml@eccosys.com CC: ietf-openpgp@imc.org Subject: Re: Forward secrecy References: <3963142F.E8971209@cs.ucl.ac.uk> <20000706164929Y.1001@eccosys.com> 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 sen_ml@eccosys.com wrote: > > From: Ian Brown > Subject: Forward secrecy > Date: Wed, 05 Jul 2000 11:55:43 +0100 > Message-ID: <3963142F.E8971209@cs.ucl.ac.uk> > > > John Noerenberg suggested we publish it as an informational RFC. We would > > be grateful for feedback from this group before we take that step. > > here are some comments: > > -this document seems to be focused on the use of openpgp for mail in > particular. is there anything to be said for other uses? (e.g. > openpgp key usage in ssh) We should certainly extend it to cover other uses. Good idea. > -section 2.1 says: > > Key distribution can be eased by submitting new keys to key > servers, where they will be available for other users to retrieve. > Submission and retrieval SHOULD be performed automatically by > software. Expired public encryption keys MUST be deleted by users > and keyservers to remove information on old key pairs. Expired > private encryption keys MUST be securely deleted to prevent later > compromise. > > i think whether the key distribution should happen automatically > should be a matter of policy. some of us have keypairs of which the > public portion is not really made widely public, nor do we want it to > be made so. perhaps such relevant policy can be expressed in the key > and implementations could interpret it appropriately. It is a SHOULD rather than a MUST so a compliant implementation can choose to not do it. However, we should probably make a specific note to that effect. OTOH, I notice that one of the changes I intended to make has not been: that is that it is not necessary to delete public keys, only private ones. In fact, expired public keys may be required to check the validity of (old) revocations. > i wonder how much success one will have w/ convincing the > keyserver folks that they should delete expired public keys. i would > like the ability to be able to tell a keyserver to remove a public key > for which i have the corresponding secret key (or may be even the > typically existing email address), but i don't get the impression that > it's a popular idea thing among implementors. I have exchanged some mails with (some of) the keyserver folks, and the widespread use of short-lifetime encryption only keys will kill the keyservers if they do not expire them. So, I think they may well wish to do it. > -section 2.2 says: > > Before an OpenPGP client exports a private key as plaintext, the > associated public key MUST be revoked and redistributed. > > i think i see a good reason for this, but i wonder whether it is > practical. doesn't redistribution of the key require net > access? > > to implement this correctly, when requested to export > a private key as plaintext, the implementation first revokes the key, > then redistributes the key by sending it to the keyservers, and > then exports the private key (perhaps after confirming that the > redistribution has been successful). if it cannot contact a keyserver > (or verify that redistribution was successful), a correct > implementation would not export the private key as plaintext, > i presume. perhaps i'm nitpicking... I guess it needs addressing. > also, which takes precedence, the deletion of expired keys from > keyservers or the distribution of revoked keys? is this also a matter > of policy that could be reflected in the key? > > -how about saying "attackers" instead of "hackers" in section 6? Sure. > -how about some "secure deletion" references in the references section? For example? > off-topic: how about you guys write an informational rfc that suggests > best practice methods for email message header confidentiality ;-) I thought someone else was doing that already? Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ From owner-ietf-openpgp@mail.imc.org Fri Jul 7 12:23:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02032 for ; Fri, 7 Jul 2000 12:23:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA21141 for ietf-openpgp-bks; Fri, 7 Jul 2000 09:01:45 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA21133 for ; Fri, 7 Jul 2000 09:01:44 -0700 (PDT) Received: from luke.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 7 Jul 2000 17:02:57 +0100 X-Mailer: exmh version 2.0.2 To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: Forward secrecy In-reply-to: Your message of "Thu, 06 Jul 2000 16:49:29 +0900." <20000706164929Y.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jul 2000 17:02:55 +0100 Message-ID: <1227.962985775@cs.ucl.ac.uk> From: Ian BROWN Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the comments :) > -this document seems to be focused on the use of openpgp for mail in > particular. is there anything to be said for other uses? (e.g. > openpgp key usage in ssh) I have included a new paragraph on the use ofOpenPGP keys with network/transport layer security services: Where OpenPGP keys are used in protocols such as IPSEC [2] or TLS [9], they SHOULD NOT be used to encrypt keying material that can later be decrypted if they are compromised. Ideally, they SHOULD be used only to authenticate a forward-secret key negotiation protocol such as Diffie-Hellman [3]. At the least, new short- lifetime key pairs SHOULD be generated for key encryption use. Sound sensible? > i think whether the key distribution should happen automatically > should be a matter of policy. some of us have keypairs of which the > public portion is not really made widely public, nor do we want it to > be made so. perhaps such relevant policy can be expressed in the key > and implementations could interpret it appropriately. I have changed the paragraph as follows: Key distribution can be eased by submitting new keys to key servers, where they will be available for other users to retrieve. Submission and retrieval of generally-available public keys (those self-signed with an exportable signature) SHOULD be performed automatically by software. Expired public encryption keys MUST be deleted by users and keyservers to remove information on old key pairs. Expired private encryption keys MUST be securely deleted to prevent later compromise. > -how about some "secure deletion" references in the references section? I have something by Markus Jakobsson that can go in: we could also mention the relevant DoD requirements. The "revoke and redistribute" requirement on surrendered keys is tricky: as you say, what happens if the client can't contact a keyserver? I suppose the weak answer is that as more and more people get always-on DSL/cable modem connections, and any one of the keyservers can be contacted, this shouldn't happen often (as long as the police don't catch on). But I suppose we could say something like if keyservers are unavailable, the client may queue the revocation for later distribution then export the key. > also, which takes precedence, the deletion of expired keys from > keyservers or the distribution of revoked keys? is this also a matter > of policy that could be reflected in the key? We were thinking of revoked and expired keys as separate categories. Keyservers certainly shouldn't delete revoked keys *until their expiry date is reached* -- at which point they shouldn't be used anyway. Ian :) From owner-ietf-openpgp@mail.imc.org Fri Jul 7 13:16:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05128 for ; Fri, 7 Jul 2000 13:16:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23948 for ietf-openpgp-bks; Fri, 7 Jul 2000 10:01:46 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23943 for ; Fri, 7 Jul 2000 10:01:45 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA03684; Fri, 7 Jul 2000 10:02:52 -0700 Date: Fri, 7 Jul 2000 10:02:52 -0700 Message-Id: <200007071702.KAA03684@finney.org> To: I.Brown@cs.ucl.ac.uk Subject: Re: Forward secrecy Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Expired public encryption keys MUST be > deleted by users and keyservers to remove information on old key > pairs. Does this really add enough security to be worth a MUST? An expired public key should not significantly threaten the contents of previously encrypted messages. Furthermore, such deletions can provide at most "security by obscurity" since attackers could easily have made their own archives of the public keys on the key servers. Hal From owner-ietf-openpgp@mail.imc.org Fri Jul 7 19:43:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15635 for ; Fri, 7 Jul 2000 19:43:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01763 for ietf-openpgp-bks; Fri, 7 Jul 2000 15:39:18 -0700 (PDT) Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01759 for ; Fri, 7 Jul 2000 15:39:16 -0700 (PDT) Received: from cyphers.net (idea.cyphers.net [205.178.102.83]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id FXCMRJ00.U09; Fri, 7 Jul 2000 15:35:43 -0700 Message-ID: <39665B0E.C946FF1F@cyphers.net> Date: Fri, 07 Jul 2000 15:34:54 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ian BROWN CC: ietf-openpgp@imc.org Subject: Re: Forward secrecy References: <1227.962985775@cs.ucl.ac.uk> 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 IPsec is spelled "IPsec". Not "IPSEC". Ian BROWN wrote: > I have included a new paragraph on the use ofOpenPGP keys with > network/transport layer security services: > > Where OpenPGP keys are used in protocols such as IPSEC [2] or TLS -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ietf-openpgp@mail.imc.org Fri Jul 7 19:49:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15668 for ; Fri, 7 Jul 2000 19:49:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA02830 for ietf-openpgp-bks; Fri, 7 Jul 2000 16:35:52 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02822 for ; Fri, 7 Jul 2000 16:35:49 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id QAA26450; Fri, 7 Jul 2000 16:37:19 -0700 Date: Fri, 7 Jul 2000 16:37:11 -0700 (PDT) From: "L. Sassaman" To: ietf-openpgp@imc.org cc: wk@gnupg.org Subject: Question regarding 2440:5.2.3.16 Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Would anyone like to make a suggestion for a standard HTTP mechanism for doing signed key adds to keyservers? In order for keyservers to take advantage of 2440:5.2.3.16, there must be a way to authenticate the user submitting the add as being the owner of the key. This can be done quite easily using an LDAPS connection, but since most keyservers do not support such a connection, and some clients do not either, I think there should be a standard data format for submitting signed add requests to "HKP" keyservers. Werner Koch and I have been discussing this, and he suggests that we put it into a clear-text signature packet. Would that be suitable? - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5ZmmuPYrxsgmsCmoRAli4AJ4xBu8Vfv3iUVokLY9eJbAHedgS1QCeNTIN NHgFwERh+a6UUZ5V1xRuwes= =NNry -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sat Jul 8 02:29:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03477 for ; Sat, 8 Jul 2000 02:29:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA26376 for ietf-openpgp-bks; Fri, 7 Jul 2000 23:12:50 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA26371 for ; Fri, 7 Jul 2000 23:12:47 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A99F6380288; Sat, 08 Jul 2000 14:14:07 0800 Message-Id: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Jun 2000 14:03:58 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: 5.1 Clarification re padding 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: To all, I noticed in section 5.1 that (third last paragraph): -----BEGIN SECTION----- "This value is then padded as described in PKCS-1 block type 02 [RFC2437] to form the "m" value used in the formulas above." -----END SECTION----- I have looked through RFC2437 and I cannot see any reference to a block type 02 or any specific details on padding. Can someone please point me to a document that details the padding mechanism to use in 5.1 as I wouldn't have a clue at the moment :) TIA. From owner-ietf-openpgp@mail.imc.org Sat Jul 8 06:03:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04514 for ; Sat, 8 Jul 2000 06:03:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA03486 for ietf-openpgp-bks; Sat, 8 Jul 2000 02:49:10 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA03480 for ; Sat, 8 Jul 2000 02:49:08 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 18933 invoked from network); 8 Jul 2000 09:50:24 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 8 Jul 2000 09:50:24 -0000 To: ietf-openpgp@imc.org Subject: Re: 5.1 Clarification re padding In-Reply-To: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> References: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000708185051L.1001@eccosys.com> Date: Sat, 08 Jul 2000 18:50:51 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: 5.1 Clarification re padding Date: Thu, 08 Jun 2000 14:03:58 +0800 Message-ID: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> > To all, > > I noticed in section 5.1 that (third last paragraph): > > -----BEGIN SECTION----- > > "This value is then padded as described in PKCS-1 block type 02 [RFC2437] > to form the "m" value used in the formulas above." > > -----END SECTION----- hmm, that's not what it says in my copy...ah, i see that the quoted part if probably from one of the bis documents. i think that may be an error. > I have looked through RFC2437 and I cannot see any reference to a block > type 02 or any specific details on padding. neither can i ;-) > Can someone please point me to a document that details the padding > mechanism to use in 5.1 as I wouldn't have a clue at the moment :) try rfc 2313. that's the reference made in my copy of rfc 2440, and it does mention a block of type 2. From owner-ietf-openpgp@mail.imc.org Sat Jul 8 07:21:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04811 for ; Sat, 8 Jul 2000 07:21:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA08912 for ietf-openpgp-bks; Sat, 8 Jul 2000 04:06:38 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA08907 for ; Sat, 8 Jul 2000 04:06:36 -0700 (PDT) Received: from donatello.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 8 Jul 2000 12:07:57 +0100 X-Mailer: exmh version 2.0.2 To: wprice@cyphers.net cc: Ian BROWN , ietf-openpgp@imc.org Subject: Re: Forward secrecy In-reply-to: Your message of "Fri, 07 Jul 2000 15:34:54 PDT." <39665B0E.C946FF1F@cyphers.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Jul 2000 12:07:57 +0100 Message-ID: <6047.963054477@cs.ucl.ac.uk> From: Ian BROWN Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Will, >IPsec is spelled "IPsec". Not "IPSEC". grepping through the messages in my ipsec WG folder, I find: IPSEC 113 times IPsec 104 times IPSec 38 times I also see that the IETF Working Group description begins: >Rapid advances in communication technology have >accentuated the need for security in the Internet. >The IP Security Protocol Working Group (IPSEC) >will develop mechanisms to protect client >protocols of IP. A security protocol in the >network layer will be developed to provide >cryptographic security services that will flexibly >support combinations of authentication, integrity, >access control, and confidentiality. Ian. From owner-ietf-openpgp@mail.imc.org Sat Jul 8 07:53:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04976 for ; Sat, 8 Jul 2000 07:53:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id EAA09837 for ietf-openpgp-bks; Sat, 8 Jul 2000 04:39:02 -0700 (PDT) Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09833 for ; Sat, 8 Jul 2000 04:39:01 -0700 (PDT) Received: from cyphers.net (aes.cyphers.net [205.178.102.90]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id FXDMV200.K08; Sat, 8 Jul 2000 04:35:26 -0700 Message-ID: <39671334.7A48CC11@cyphers.net> Date: Sat, 08 Jul 2000 04:40:31 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ian BROWN CC: ietf-openpgp@imc.org Subject: Re: Forward secrecy References: <6047.963054477@cs.ucl.ac.uk> 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 Yes, it's a common error, but there is in fact only one correct way: IPsec. See RFC 2401 or the working group discussion on this topic for more information. Ian BROWN wrote: > >IPsec is spelled "IPsec". Not "IPSEC". > > grepping through the messages in my ipsec WG folder, I find: > > IPSEC 113 times > IPsec 104 times > IPSec 38 times > > I also see that the IETF Working Group description begins: > > >Rapid advances in communication technology have > >accentuated the need for security in the Internet. > >The IP Security Protocol Working Group (IPSEC) > >will develop mechanisms to protect client > >protocols of IP. A security protocol in the > >network layer will be developed to provide > >cryptographic security services that will flexibly > >support combinations of authentication, integrity, > >access control, and confidentiality. -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. From owner-ietf-openpgp@mail.imc.org Sat Jul 8 11:55:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06789 for ; Sat, 8 Jul 2000 11:55:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA18326 for ietf-openpgp-bks; Sat, 8 Jul 2000 08:36:03 -0700 (PDT) Received: from tomts2-srv.bellnexxia.net (tomts2.bellnexxia.net [209.226.175.140]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18318 for ; Sat, 8 Jul 2000 08:36:01 -0700 (PDT) Received: from localhost ([64.228.185.33]) by tomts2-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000708153736.UIYM8045.tomts2-srv.bellnexxia.net@localhost>; Sat, 8 Jul 2000 11:37:36 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13AuKk-00009A-00; Sat, 8 Jul 2000 09:07:50 -0400 Date: Sat, 8 Jul 2000 09:07:46 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: 5.1 Clarification re padding Message-ID: <20000708090745.A418@rho> References: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com>; from ejc@comasp.com on Thu, Jun 08, 2000 at 02:03:58PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 08, 2000 at 02:03:58PM +0800, Erron Criddle wrote: > I noticed in section 5.1 that (third last paragraph): > "This value is then padded as described in PKCS-1 block type 02 [RFC2437] > to form the "m" value used in the formulas above." The OpenPGP RFC refers to RFC 2313. In a later draft, Jon Callas changed the reference to RFC 2437, but failed to update the contents. In terms of RFC 2437, OpenPGP uses EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. From owner-ietf-openpgp@mail.imc.org Sun Jul 9 22:51:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15110 for ; Sun, 9 Jul 2000 22:51:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA07005 for ietf-openpgp-bks; Sun, 9 Jul 2000 19:30:48 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA07001 for ; Sun, 9 Jul 2000 19:30:45 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A896FECA00AC; Mon, 10 Jul 2000 10:32:06 0800 Message-Id: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 10 Jun 2000 10:21:57 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: 5.1 Clarification re padding In-Reply-To: <20000708090745.A418@rho> References: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.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: Ulf, Sen and others, > > I noticed in section 5.1 that (third last paragraph): > > > "This value is then padded as described in PKCS-1 block type 02 [RFC2437] > > to form the "m" value used in the formulas above." > >The OpenPGP RFC refers to RFC 2313. In a later draft, Jon Callas changed >the reference to RFC 2437, but failed to update the contents. > >In terms of RFC 2437, OpenPGP uses EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. I believe I have it worked out now...after reading the "File Formats used by 2.x" document, 2313 and 2437, does the m value look like this?: m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session key) (checksum) The 0x0A represents the Twofish algorithm. TIA. Regards Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 http://www.comasp.com Erron Criddle Tel: 08 9386 9534 ejc@comasp.com Fax: 08 9386 9473 From owner-ietf-openpgp@mail.imc.org Sun Jul 9 23:50:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15977 for ; Sun, 9 Jul 2000 23:50:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11004 for ietf-openpgp-bks; Sun, 9 Jul 2000 20:36:00 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA10999 for ; Sun, 9 Jul 2000 20:35:57 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 12577 invoked from network); 10 Jul 2000 03:37:17 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 03:37:17 -0000 To: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710123746Y.1001@eccosys.com> Date: Mon, 10 Jul 2000 12:37:46 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 36 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: "L. Sassaman" Subject: Question regarding 2440:5.2.3.16 Date: Fri, 7 Jul 2000 16:37:11 -0700 (PDT) Message-ID: > In order for keyservers to take advantage of 2440:5.2.3.16, there must be > a way to authenticate the user submitting the add as being the owner of > the key. so you are suggesting that proof of ownership of the corresponding secret key (via an appropriate signature) should server this purpose, right? > This can be done quite easily using an LDAPS connection, but since most > keyservers do not support such a connection, and some clients do not > either, I think there should be a standard data format for submitting > signed add requests to "HKP" keyservers. > > Werner Koch and I have been discussing this, and he suggests that we put > it into a clear-text signature packet. Would that be suitable? would you mind briefly describing the steps involved for the mechanism you are considering (in terms like "first, the client connects to the server. then the server responds w/..." etc.)? [ i understand what you are saying about the form a signature would take, but i don't see the overall flow of the process of authentication. ] also, is it necessary to consider replay attacks for this kind of scenario? alternatively, would the following scenario be of any concern: an attacker captures a session between a user and a keyserver at some point in time. later, after the user has made several updates to the keyserver, the attacker replays the captured session to set the state of the user's key to an earlier state. From owner-ietf-openpgp@mail.imc.org Mon Jul 10 00:08:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16117 for ; Mon, 10 Jul 2000 00:08:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11691 for ietf-openpgp-bks; Sun, 9 Jul 2000 20:52:06 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11687 for ; Sun, 9 Jul 2000 20:52:04 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 12890 invoked from network); 10 Jul 2000 03:53:25 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 03:53:25 -0000 To: ietf-openpgp@imc.org Subject: Re: 5.1 Clarification re padding In-Reply-To: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> References: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> <20000708090745.A418@rho> <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710125356J.1001@eccosys.com> Date: Mon, 10 Jul 2000 12:53:56 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: Re: 5.1 Clarification re padding Date: Sat, 10 Jun 2000 10:21:57 +0800 Message-ID: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> ... > I believe I have it worked out now...after reading the "File Formats used > by 2.x" document, 2313 and 2437, does the m value look like this?: > > m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session > key) (checksum) > > The 0x0A represents the Twofish algorithm. that's reflects my current understanding. to all: i've been curious about the length of the random padding octets. i presume none of them are allowed to 0x00 (that's what non-zero data means, may be?) and thus the 0x00 value preceding the algorithm-specifying octect can serve as a "marker" to indicate where the random padding ends. is that correct? From owner-ietf-openpgp@mail.imc.org Mon Jul 10 00:55:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16362 for ; Mon, 10 Jul 2000 00:55:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA12330 for ietf-openpgp-bks; Sun, 9 Jul 2000 21:41:23 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA12326 for ; Sun, 9 Jul 2000 21:41:19 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A72D7A700A0; Mon, 10 Jul 2000 12:42:37 0800 Message-Id: <4.3.2.7.0.20000610122529.00b4f188@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 10 Jun 2000 12:32:28 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: 5.1 Clarification re padding Cc: sen_ml@eccosys.com In-Reply-To: <20000710125356J.1001@eccosys.com> References: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> <20000708090745.A418@rho> <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.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:53 PM 10/07/2000 +0900, sen_ml@eccosys.com wrote: >to all: >i've been curious about the length of the random padding octets. i >presume none of them are allowed to 0x00 (that's what non-zero data >means, may be?) and thus the 0x00 value preceding the >algorithm-specifying octect can serve as a "marker" to indicate where >the random padding ends. is that correct? Yes. The doc located at: ftp.pgpi.org/pub/pgp/2.x/doc/pgformat.txt explains that in the section entitled: "Conventional Data Encryption Key (DEK) "packet"" It also notes it in 2437 (with reference to Ulf's pointers to the padding section/s) and 2313, that you have to use NON ZERO values in the random number. Regards Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 http://www.comasp.com Erron Criddle Tel: 08 9386 9534 ejc@comasp.com Fax: 08 9386 9473 From owner-ietf-openpgp@mail.imc.org Mon Jul 10 01:15:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18014 for ; Mon, 10 Jul 2000 01:15:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA12499 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:00:20 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA12495 for ; Sun, 9 Jul 2000 22:00:18 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 14102 invoked from network); 10 Jul 2000 05:01:39 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 05:01:39 -0000 To: ietf-openpgp@imc.org Subject: Re: 5.1 Clarification re padding In-Reply-To: <4.3.2.7.0.20000610122529.00b4f188@mail.comasp.com> References: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> <20000710125356J.1001@eccosys.com> <4.3.2.7.0.20000610122529.00b4f188@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710140209P.1001@eccosys.com> Date: Mon, 10 Jul 2000 14:02:09 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: Re: 5.1 Clarification re padding Date: Sat, 10 Jun 2000 12:32:28 +0800 Message-ID: <4.3.2.7.0.20000610122529.00b4f188@mail.comasp.com> > At 12:53 PM 10/07/2000 +0900, sen_ml@eccosys.com wrote: > > > > > >to all: > >i've been curious about the length of the random padding octets. i > >presume none of them are allowed to 0x00 (that's what non-zero data > >means, may be?) and thus the 0x00 value preceding the > >algorithm-specifying octect can serve as a "marker" to indicate where > >the random padding ends. is that correct? > > Yes. The doc located at: > > ftp.pgpi.org/pub/pgp/2.x/doc/pgformat.txt > > explains that in the section entitled: > > "Conventional Data Encryption Key (DEK) "packet"" > > It also notes it in 2437 (with reference to Ulf's pointers to the padding > section/s) and 2313, that you have to use NON ZERO values in the random number. thanks for the reference! upon closer inspection of rfc2313, i see: The padding string PS shall consist of k-3-||D|| octets. For block type 00, the octets shall have value 00; for block type 01, they shall have value FF; and for block type 02, they shall be pseudorandomly generated and nonzero. This makes the length of the encryption block EB equal to k. sorry for the extra traffic. From owner-ietf-openpgp@mail.imc.org Mon Jul 10 01:21:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA18894 for ; Mon, 10 Jul 2000 01:21:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA12612 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:08:08 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12608 for ; Sun, 9 Jul 2000 22:08:07 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA10764; Sun, 9 Jul 2000 22:09:30 -0700 Date: Sun, 9 Jul 2000 22:09:30 -0700 Message-Id: <200007100509.WAA10764@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: 5.1 Clarification re padding Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I believe I have it worked out now...after reading the "File Formats used > > by 2.x" document, 2313 and 2437, does the m value look like this?: > > > > m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session > > key) (checksum) > > > > The 0x0A represents the Twofish algorithm. > > that's reflects my current understanding. Yes, I believe this is correct. > to all: > > i've been curious about the length of the random padding octets. i > presume none of them are allowed to 0x00 (that's what non-zero data > means, may be?) and thus the 0x00 value preceding the > algorithm-specifying octect can serve as a "marker" to indicate where > the random padding ends. is that correct? Yes. From owner-ietf-openpgp@mail.imc.org Mon Jul 10 02:01:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25196 for ; Mon, 10 Jul 2000 02:01:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA13335 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:47:46 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA13330 for ; Sun, 9 Jul 2000 22:47:43 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A6C8A0F00AC; Mon, 10 Jul 2000 13:49:12 0800 Message-Id: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 10 Jun 2000 13:39:02 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: 2.1, 2.2 and 10.2 Clarification re sigs. 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: To all, -----BEGIN SECTION REFERENCES----- Section 2.1 (last paragraph) notes: "First, a signature is generated for the message and attached to the message. Then the message plus the signature is encrypted using a symmetric session key." Section 2.2 (item 4) notes: "4. The binary signature is attached to the message" Section 10.2 notes: "One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packet" "Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message" -----END SECTION REFERENCES----- To me, "attached" (as in 2.1 and 2.2) means you add it to the end of something and this contradicts 10.2 explanation of a Signed Message (a signed message implies that it is prepended, not attached). By reading section 10.2, it seems that there are two possibilities for signing a literal message: 1) You create a signature packet then prepend it to the literal packet 2) You create a signature packet and a One-Pass Signature Packet then prepend the One-Pass packet to the literal packet and append the signature packet to the literal packet. Therefore, my final questions are: 1) Can you create a simple signature packet and attach it to the end of a literal packet as stated in 2.1 and 2.2 and subsequently contradict 10.2 regarding the definition of a signed message and: 2) Why would you need a One-Pass Signature Packet if we conform to 10.2 and simply prepend a normal signature packet to the literal data with a subpacket of type 16 (key id), thus removing the need for a One-Pass packet in the first place? Cheers for any clarification once again :) Regards Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 http://www.comasp.com Erron Criddle Tel: 08 9386 9534 ejc@comasp.com Fax: 08 9386 9473 From owner-ietf-openpgp@mail.imc.org Mon Jul 10 02:56:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29671 for ; Mon, 10 Jul 2000 02:56:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA14428 for ietf-openpgp-bks; Sun, 9 Jul 2000 23:42:49 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA14423 for ; Sun, 9 Jul 2000 23:42:47 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 16278 invoked from network); 10 Jul 2000 06:44:08 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 06:44:08 -0000 To: ietf-openpgp@imc.org Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. In-Reply-To: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> References: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710154438W.1001@eccosys.com> Date: Mon, 10 Jul 2000 15:44:38 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: 2.1, 2.2 and 10.2 Clarification re sigs. Date: Sat, 10 Jun 2000 13:39:02 +0800 Message-ID: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> ... > "Signed Message :- Signature Packet, OpenPGP Message | One-Pass > Signed Message" may be this was meant to be: Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message ? for reference, looking through the openpgp packets found in pgp messages i have received, the pattern of "literal data packet followed by signature packet" does appear. From owner-ietf-openpgp@mail.imc.org Mon Jul 10 13:37:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19237 for ; Mon, 10 Jul 2000 13:37:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05150 for ietf-openpgp-bks; Mon, 10 Jul 2000 10:18:20 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05146 for ; Mon, 10 Jul 2000 10:18:19 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id KAA09686; Mon, 10 Jul 2000 10:20:00 -0700 Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT) From: "L. Sassaman" To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: <20000710123746Y.1001@eccosys.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 10 Jul 2000 sen_ml@eccosys.com wrote: > so you are suggesting that proof of ownership of the corresponding > secret key (via an appropriate signature) should server this purpose, > right? Yes, because the owner needs to prove he has the secret key, and the public key block that is to be added must be signed to prevent unauthorized signatures being added during this process. > > Werner Koch and I have been discussing this, and he suggests that we put > > it into a clear-text signature packet. Would that be suitable? > > would you mind briefly describing the steps involved for the mechanism > you are considering (in terms like "first, the client connects to the > server. then the server responds w/..." etc.)? > > [ i understand what you are saying about the form a signature would > take, but i don't see the overall flow of the process of > authentication. ] The client takes the public key block, signs it, and submits this signed blob to the server. The server then verifies the signature, trims away that signature, and adds the key. Keys that are added unsigned should always be checked for the existance of the "no-modify" flag, and rejected if it exists. Furthermore, I suggest that we have a "modify" flag added to the spec, so that, if a signature is made at a later date containing this flag, it would superceed a preveous no-modify. But that digresses from this discussion. > also, is it necessary to consider replay attacks for this kind of > scenario? alternatively, would the following scenario be of any concern: > > an attacker captures a session between a user and a keyserver at some > point in time. later, after the user has made several updates to the > keyserver, the attacker replays the captured session to set the > state of the user's key to an earlier state. This scenerio is only partially valid. A signed key that is added to a server does not remove the previous key and replace it with the new one. It is treated like and other add, and is merged with the existing key. So, an attacker could not truly set the key to a previous state. What an attacker *could* do, via a replay attack, is re-add signatures or user-ids to a key on the server that the owner had later deleted. I see this as a minor annoyance, rather than an attack, so I don't think that we need to address it. (Though we could, through the use of server tokens or timestamps, etc. I just think it is more work than is necessary.) - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5agW/PYrxsgmsCmoRAhJhAKCo88zWNgPDz7aQ77qGMv7wmNgVWgCdGfcs 6xQ9X0cE6PywApXO0N0FVRc= =IpeB -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 10 14:50:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22918 for ; Mon, 10 Jul 2000 14:50:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06204 for ietf-openpgp-bks; Mon, 10 Jul 2000 11:08:48 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06200 for ; Mon, 10 Jul 2000 11:08:46 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA11952; Mon, 10 Jul 2000 11:10:11 -0700 Date: Mon, 10 Jul 2000 11:10:11 -0700 Message-Id: <200007101810.LAA11952@finney.org> To: ietf-openpgp@imc.org, rabbi@quickie.net Subject: Re: Question regarding 2440:5.2.3.16 Cc: wk@gnupg.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Len writes: > Would anyone like to make a suggestion for a standard HTTP mechanism for > doing signed key adds to keyservers? > > Werner Koch and I have been discussing this, and he suggests that we put > it into a clear-text signature packet. Would that be suitable? That seems OK, or perhaps you could use an SSL (TLS) session using the PGP key to authenticate the client. In any case I don't think this mechanism should be documented in 2440. Hal From owner-ietf-openpgp@mail.imc.org Mon Jul 10 14:52:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23087 for ; Mon, 10 Jul 2000 14:52:43 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06666 for ietf-openpgp-bks; Mon, 10 Jul 2000 11:27:50 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06662 for ; Mon, 10 Jul 2000 11:27:49 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id LAA10170; Mon, 10 Jul 2000 11:29:13 -0700 Date: Mon, 10 Jul 2000 11:29:05 -0700 (PDT) From: "L. Sassaman" To: hal@finney.org cc: ietf-openpgp@imc.org, wk@gnupg.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: <200007101810.LAA11952@finney.org> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 10 Jul 2000 hal@finney.org wrote: > That seems OK, or perhaps you could use an SSL (TLS) session using the > PGP key to authenticate the client. In any case I don't think this > mechanism should be documented in 2440. That's fine, but I do think that this definately needs to be documented. If 2440 isn't the place, then we need to start work on a keyserver draft. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5ahX4PYrxsgmsCmoRAugzAJ9kXo6sUKvSwNXccAz2neOxYK7xWwCeLeQu rPS3ze/rL2VpE3VOMgw7HFs= =RYem -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 10 16:58:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28130 for ; Mon, 10 Jul 2000 16:58:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA10549 for ietf-openpgp-bks; Mon, 10 Jul 2000 13:31:04 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10545 for ; Mon, 10 Jul 2000 13:30:59 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id NAA25115; Mon, 10 Jul 2000 13:32:01 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id NAA25111; Mon, 10 Jul 2000 13:31:53 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: Date: Mon, 10 Jul 2000 13:31:48 -0700 To: "L. Sassaman" , hal@finney.org From: Jon Callas Subject: Re: Question regarding 2440:5.2.3.16 Cc: ietf-openpgp@imc.org, wk@gnupg.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:29 AM -0700 7/10/00, L. Sassaman wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Mon, 10 Jul 2000 hal@finney.org wrote: > >> That seems OK, or perhaps you could use an SSL (TLS) session using the >> PGP key to authenticate the client. In any case I don't think this >> mechanism should be documented in 2440. > >That's fine, but I do think that this definately needs to be >documented. If 2440 isn't the place, then we need to start work on a >keyserver draft. > Someone should work on a key server document. RFC 2440 is OpenPGP Formats. Key server operation is not a data format. Jon From owner-ietf-openpgp@mail.imc.org Mon Jul 10 18:15:39 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29994 for ; Mon, 10 Jul 2000 18:15:38 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA12208 for ietf-openpgp-bks; Mon, 10 Jul 2000 14:51:04 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12204 for ; Mon, 10 Jul 2000 14:51:02 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id OAA11574; Mon, 10 Jul 2000 14:52:45 -0700 Date: Mon, 10 Jul 2000 14:52:38 -0700 (PDT) From: "L. Sassaman" To: Jon Callas cc: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 5 Jul 2000, Jon Callas wrote: > One of the things to remember about 2440 -- and stated in the document > abstract -- is that it isn't a how-to guide for writing an application. > It's a description of how the data is laid out, and (more or less) what it > means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide." > > Lots of things are assumed in the document. For example, it's assumed you > know what a cipher is. Many of the references to ciphers are pretty terse, > and I know I wouldn't want to implement from it and it alone. Just last > week, for example, someone pointed out to me that the reference for > Triple-DES was dangling. We all looked around for a good reference to 3DES, > and didn't come up with one! I was sure there was some RFC for it, myself, > and there isn't. This is amusing, since 3DES is the cross-group defacto > meta-standard algorithm in the IETF, and yet we don't have a good place to > say, "Hey, here's how 3DES is done." I changed the 2440bis reference to > point to Schneier, which is better than nothing, but still not great. As we > find those things, we'll shoot them. Use X9.52. X9.52 is the ANSI standard for 3DES. Menezes et al. references it when discussing 3DES, and I believe Schneier does as well. - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5akWsPYrxsgmsCmoRArBwAJ9PPMdy0D2NwMgHzNuVq4vOCnKETgCgilCC EASEGruc+B16FO+lxwnLdc0= =B66F -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Jul 11 07:20:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25495 for ; Tue, 11 Jul 2000 07:20:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA29622 for ietf-openpgp-bks; Tue, 11 Jul 2000 03:59:50 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29614 for ; Tue, 11 Jul 2000 03:59:47 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13By3W-0000AG-00; Tue, 11 Jul 2000 13:18:26 +0200 Date: Tue, 11 Jul 2000 13:18:26 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 Message-ID: <20000711131826.D569@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000710123746Y.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: ; from rabbi@quickie.net on Mon, Jul 10, 2000 at 10:19:52AM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 10 Jul 2000, L. Sassaman wrote: > The client takes the public key block, signs it, and submits this signed > blob to the server. The server then verifies the signature, trims away > that signature, and adds the key. Don't forget that the server needs to accept unsigned requests too and allow to add key revocations and certicate revocations. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Tue Jul 11 13:50:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11872 for ; Tue, 11 Jul 2000 13:50:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA21956 for ietf-openpgp-bks; Tue, 11 Jul 2000 10:22:31 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21948 for ; Tue, 11 Jul 2000 10:22:29 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id KAA20476; Tue, 11 Jul 2000 10:24:09 -0700 Date: Tue, 11 Jul 2000 10:24:01 -0700 (PDT) From: "L. Sassaman" To: Werner Koch cc: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: <20000711131826.D569@djebel.gnupg.de> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 11 Jul 2000, Werner Koch wrote: > On Mon, 10 Jul 2000, L. Sassaman wrote: > > > The client takes the public key block, signs it, and submits this signed > > blob to the server. The server then verifies the signature, trims away > > that signature, and adds the key. > > Don't forget that the server needs to accept unsigned requests too and > allow to add key revocations and certicate revocations. Yep. I figured I wouldn't bring that up again, since it looks like we're going to be needing an I-D on keyservers, and that would fit in there. But yes, the owner-update-only flag must be ignored on all types of revocations. - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5a1g4PYrxsgmsCmoRAl89AJ9X6LyWrnawfETOB1Xv6w5zQEsxkQCg3yXr CbFEAeBCXm20kfE9umyp+ks= =X0Ae -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Jul 12 23:57:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24270 for ; Wed, 12 Jul 2000 23:57:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22842 for ietf-openpgp-bks; Wed, 12 Jul 2000 20:41:19 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA22838 for ; Wed, 12 Jul 2000 20:41:17 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ADB012C01CE; Thu, 13 Jul 2000 11:42:56 0800 Message-Id: <4.3.2.7.0.20000613112656.00ae3a98@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 11:32:36 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: q re 5.1; is it m*(y**k) or (m*y)**k ? 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: To all, A couple of q's re 2440: 5.1: Regarding the ElGamal keys and the *m* value, is it: a) (m*y)**k mod p b) m * (y**k) mod p Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Thu Jul 13 00:30:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24734 for ; Thu, 13 Jul 2000 00:30:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25504 for ietf-openpgp-bks; Wed, 12 Jul 2000 21:10:40 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA25483 for ; Wed, 12 Jul 2000 21:10:32 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A49014E018E; Thu, 13 Jul 2000 12:12:16 0800 Message-Id: <4.3.2.7.0.20000613113239.00af78f0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 12:01:55 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: V4 Sig. incomplete? 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: To all concerned: With reference to 5.4; the second last paragraph states that a version 4 signature has a final trailer of 6 octets, being: 0x04 or 0xFF, a four octet big endian number This is only 5 octets...does anybody know what the 6th octet is? ...or is a V4 signature final trailer only 5 octets? TIA for the clarification. PS: Can anyone please confirm the following (hashed data is appended by the | symbol) 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding into the DSA (assuming DSA sig): public DSA keys (this line not hashed) 0x99 | 2 octet length | MPI of DSA prime p | MPI of DSA grooup order q | MPI of DSA group generator g | MPI of DSA public key value y | + user id (this line not hashed) 0xb4 | 4 octet length | username data | version field to end of hashable data | 0x04 | 4 octet length | ? (see previous question re 5.4) | 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding into the DSA (assuming DSA signature keys and ElGamal encryption keys): public DSA keys (this line not hashed) 0x99 | 2 octet length | MPI of DSA prime p | MPI of DSA grooup order q | MPI of DSA group generator g | MPI of DSA public key value y | + public ElGamal keys (this line not hashed) 0x99 | 2 octet length | MPI of ElGamal prime p | MPI of ElGamal grooup order q | MPI of ElGamal public key value y | version field to end of hashable data | 0x04 | 4 octet length | ? (see previous question re 5.4) | Once again, thanks for any clarification. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Thu Jul 13 01:40:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00658 for ; Thu, 13 Jul 2000 01:40:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA29771 for ietf-openpgp-bks; Wed, 12 Jul 2000 22:27:16 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29765 for ; Wed, 12 Jul 2000 22:27:14 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA19939; Wed, 12 Jul 2000 22:28:55 -0700 Date: Wed, 12 Jul 2000 22:28:55 -0700 Message-Id: <200007130528.WAA19939@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: q re 5.1; is it m*(y**k) or (m*y)**k ? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > 5.1: Regarding the ElGamal keys and the *m* value, is it: > > a) (m*y)**k mod p > b) m * (y**k) mod p It is (b). Hal From owner-ietf-openpgp@mail.imc.org Thu Jul 13 01:50:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01548 for ; Thu, 13 Jul 2000 01:50:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00930 for ietf-openpgp-bks; Wed, 12 Jul 2000 22:38:12 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00923 for ; Wed, 12 Jul 2000 22:38:10 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA19969; Wed, 12 Jul 2000 22:39:51 -0700 Date: Wed, 12 Jul 2000 22:39:51 -0700 Message-Id: <200007130539.WAA19969@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: V4 Sig. incomplete? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > With reference to 5.4; the second last paragraph states that a version 4 > signature has a final trailer of 6 octets, being: > > 0x04 or 0xFF, a four octet big endian number > > This is only 5 octets...does anybody know what the 6th octet is? ...or is a > V4 signature final trailer only 5 octets? Where did you get the "or" in "0x04 or 0xFF"? The spec says, V4 signatures also hash in a final trailer of six octets: the version of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian number that is the length of the hashed data from the signature packet (note that this number does not include these final six octets. I don't see an "or". It is 0x04, 0xFF, and the four octets of length. That is six octets. > 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding into > the DSA (assuming DSA sig): I'm not sure what you mean by "hash then concatenate". It would make more sense to say "concatenate then hash", or more simply, just "hash". > public DSA keys (this line not hashed) > > 0x99 | > 2 octet length | At this point you hash the entire public key packet. As described in section 5.5.2 of RFC 2440, in addition to the MPI data below, this includes a version number, creation time, validity period if V3 key, and public key algorithm type. This is then followed by the MPI data: > MPI of DSA prime p | > MPI of DSA grooup order q | > MPI of DSA group generator g | > MPI of DSA public key value y | Of course a DSA signature could be over an RSA key as well. > + > > user id (this line not hashed) > > 0xb4 | > 4 octet length | > username data | > > version field to end of hashable data | Yes, of the signature packet. > > 0x04 | then 0xFF then > 4 octet length | > ? (see previous question re 5.4) | This looks correct, incorporating the changes above. > 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding into > the DSA (assuming DSA signature keys and ElGamal encryption keys): > > public DSA keys (this line not hashed) > > 0x99 | > 2 octet length | As above, other key packet information is hashed here. > MPI of DSA prime p | > MPI of DSA grooup order q | > MPI of DSA group generator g | > MPI of DSA public key value y | > > + > > public ElGamal keys (this line not hashed) > > 0x99 | > 2 octet length | Again, other subkey packet information is hashed here. > MPI of ElGamal prime p | > MPI of ElGamal grooup order q | Actually this is the group generator g, not the group order q. > MPI of ElGamal public key value y | > > version field to end of hashable data | > > 0x04 | As above, 0xFF goes here. > 4 octet length | > ? (see previous question re 5.4) | Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Jul 13 02:46:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08888 for ; Thu, 13 Jul 2000 02:46:21 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA03112 for ietf-openpgp-bks; Wed, 12 Jul 2000 23:26:57 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA03108 for ; Wed, 12 Jul 2000 23:26:54 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A48615501CE; Thu, 13 Jul 2000 14:28:38 0800 Message-Id: <4.3.2.7.0.20000613135617.0244bea0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 14:18:17 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: V4 Sig. incomplete? Cc: hal@finney.org In-Reply-To: <200007130539.WAA19969@finney.org> 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: Hal, Many thanks for your reply - it has certainly made things clearer :) At 10:39 PM 12/07/2000 -0700, hal@finney.org wrote: > > This is only 5 octets...does anybody know what the 6th octet is? ...or > is a > > V4 signature final trailer only 5 octets? > >Where did you get the "or" in "0x04 or 0xFF"? Obviously from some cross-linked neurons - sorry for the wasted b/w. I have also rewritten my original question and answers - hopefully they are correct this time :) : 1) V4 Sig., type 0x10. Concatenate the following data then hash it for input into the DSA (the data to be hashed is terminated with the | char) header data 0x99 | 2 octet length | public DSA keys (version 4) 0x04 (version) | 4 octet time | 0x11 (for DSA signing algorithm) | MPI of DSA prime p | MPI of DSA grooup order q | MPI of DSA group generator g | MPI of DSA public key value y | user id data 0xb4 | 4 octet length | username data | signature trailer version field to end of hashable data | V4 signature trailer 0x04 | 0xFF | 4 octet length | All the above data is concatenated then hashed. The left 16 bits are inserted into the hash check field of the signature and then the hash is fed into the DSA for production of the signature. 2) V4 Sig., type 0x18. Concatenate the following data then hash it for input into the DSA (the data to be hashed is terminated with the | char) header data 0x99 | 2 octet length | public DSA keys (version 4) 0x04 (version) | 4 octet time | 0x11 (for DSA signing algorithm) | MPI of DSA prime p | MPI of DSA grooup order q | MPI of DSA group generator g | MPI of DSA public key value y | header data 0x99 | 2 octet length | public ElGamal keys 0x04 (version) | 4 octet time | 0x10 (for ElGamal enc. algorithm) | MPI of ElGamal prime p | MPI of ElGamal group generator g | MPI of ElGamal public key value y | signature trailer version field to end of hashable data | V4 signature trailer 0x04 | 0xFF | 4 octet length | Once again, all the above data is concatenated then hashed. The left 16 bits are inserted into the hash check field of the signature and then the hash is fed into the DSA for production of the signature. > > 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding > into > > the DSA (assuming DSA sig): > >I'm not sure what you mean by "hash then concatenate". It would make >more sense to say "concatenate then hash", or more simply, just "hash". > > > public DSA keys (this line not hashed) > > > > 0x99 | > > 2 octet length | > >At this point you hash the entire public key packet. As described >in section 5.5.2 of RFC 2440, in addition to the MPI data below, this >includes a version number, creation time, validity period if V3 key, >and public key algorithm type. This is then followed by the MPI data: > > > MPI of DSA prime p | > > MPI of DSA grooup order q | > > MPI of DSA group generator g | > > MPI of DSA public key value y | > >Of course a DSA signature could be over an RSA key as well. > > > + > > > > user id (this line not hashed) > > > > 0xb4 | > > 4 octet length | > > username data | > > > > version field to end of hashable data | > >Yes, of the signature packet. > > > > > 0x04 | > >then 0xFF then > > > 4 octet length | > > ? (see previous question re 5.4) | > >This looks correct, incorporating the changes above. > > > > 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding > into > > the DSA (assuming DSA signature keys and ElGamal encryption keys): > > > > public DSA keys (this line not hashed) > > > > 0x99 | > > 2 octet length | > >As above, other key packet information is hashed here. > > > MPI of DSA prime p | > > MPI of DSA grooup order q | > > MPI of DSA group generator g | > > MPI of DSA public key value y | > > > > + > > > > public ElGamal keys (this line not hashed) > > > > 0x99 | > > 2 octet length | > >Again, other subkey packet information is hashed here. > > > MPI of ElGamal prime p | > > MPI of ElGamal grooup order q | > >Actually this is the group generator g, not the group order q. > > > MPI of ElGamal public key value y | > > > > version field to end of hashable data | > > > > 0x04 | > >As above, 0xFF goes here. > > > 4 octet length | > > ? (see previous question re 5.4) | > >Hal Finney Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Thu Jul 13 02:52:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08935 for ; Thu, 13 Jul 2000 02:52:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA03508 for ietf-openpgp-bks; Wed, 12 Jul 2000 23:34:53 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03502 for ; Wed, 12 Jul 2000 23:34:52 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id XAA20214; Wed, 12 Jul 2000 23:36:32 -0700 Date: Wed, 12 Jul 2000 23:36:32 -0700 Message-Id: <200007130636.XAA20214@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: V4 Sig. incomplete? Cc: hal@finney.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, this all looks fine now. The one thing I'd add is that there is no need to parse out the key and subkey packets as you have done. After the 0x99 and two-octet length, you just hash the key or subkey packet body. The specific contents of the key/subkey packet are irrelevant to the signature algotihm, it's just data to feed the hash. Hal > 1) V4 Sig., type 0x10. Concatenate the following data then hash it for > input into the DSA (the data to be hashed is terminated with the | char) > > header data > > 0x99 | > 2 octet length | > > public DSA keys (version 4) > > 0x04 (version) | > 4 octet time | > 0x11 (for DSA signing algorithm) | > MPI of DSA prime p | > MPI of DSA grooup order q | > MPI of DSA group generator g | > MPI of DSA public key value y | > > user id data > > 0xb4 | > 4 octet length | > username data | > > signature trailer > > version field to end of hashable data | > > V4 signature trailer > > 0x04 | > 0xFF | > 4 octet length | > > All the above data is concatenated then hashed. The left 16 bits are > inserted into the hash check field of the signature and then the hash is > fed into the DSA for production of the signature. > > 2) V4 Sig., type 0x18. Concatenate the following data then hash it for > input into the DSA (the data to be hashed is terminated with the | char) > > header data > > 0x99 | > 2 octet length | > > public DSA keys (version 4) > > 0x04 (version) | > 4 octet time | > 0x11 (for DSA signing algorithm) | > MPI of DSA prime p | > MPI of DSA grooup order q | > MPI of DSA group generator g | > MPI of DSA public key value y | > > header data > > 0x99 | > 2 octet length | > > public ElGamal keys > > 0x04 (version) | > 4 octet time | > 0x10 (for ElGamal enc. algorithm) | > MPI of ElGamal prime p | > MPI of ElGamal group generator g | > MPI of ElGamal public key value y | > > signature trailer > > version field to end of hashable data | > > V4 signature trailer > > 0x04 | > 0xFF | > 4 octet length | > > Once again, all the above data is concatenated then hashed. The left 16 > bits are inserted into the hash check field of the signature and then the > hash is fed into the DSA for production of the signature. From owner-ietf-openpgp@mail.imc.org Thu Jul 13 03:14:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09269 for ; Thu, 13 Jul 2000 03:14:24 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA04556 for ietf-openpgp-bks; Thu, 13 Jul 2000 00:02:08 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA04552 for ; Thu, 13 Jul 2000 00:02:05 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ACC772A01E6; Thu, 13 Jul 2000 15:03:51 0800 Message-Id: <4.3.2.7.0.20000613144451.0244fe20@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 14:53:30 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: V4 Sig. incomplete? Cc: hal@finney.org In-Reply-To: <200007130636.XAA20214@finney.org> 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: Hal, Nearly there (I think)...just need to clarify what you have said: At 11:36 PM 12/07/2000 -0700, hal@finney.org wrote: >Yes, this all looks fine now. The one thing I'd add is that there is no >need to parse out the key and subkey packets as you have done. After the >0x99 and two-octet length, you just hash the key or subkey packet body. >The specific contents of the key/subkey packet are irrelevant to the >signature algotihm, it's just data to feed the hash. So you're saying that (1) is OK, however in the case of 2), it would be best to structure it this way: header data 0x99 | 2 octet length | public ElGamal keys 0x04 (version) | 4 octet time | 0x10 (for ElGamal enc. algorithm) | MPI of ElGamal prime p | MPI of ElGamal group generator g | MPI of ElGamal public key value y | signature trailer version field to end of hashable data | V4 signature trailer 0x04 | 0xFF | 4 octet length | I hope this is OK...or did I totally misunderstand your response? Thanks :) > > 1) V4 Sig., type 0x10. Concatenate the following data then hash it for > > input into the DSA (the data to be hashed is terminated with the | char) > > > > header data > > > > 0x99 | > > 2 octet length | > > > > public DSA keys (version 4) > > > > 0x04 (version) | > > 4 octet time | > > 0x11 (for DSA signing algorithm) | > > MPI of DSA prime p | > > MPI of DSA grooup order q | > > MPI of DSA group generator g | > > MPI of DSA public key value y | > > > > user id data > > > > 0xb4 | > > 4 octet length | > > username data | > > > > signature trailer > > > > version field to end of hashable data | > > > > V4 signature trailer > > > > 0x04 | > > 0xFF | > > 4 octet length | > > > > All the above data is concatenated then hashed. The left 16 bits are > > inserted into the hash check field of the signature and then the hash is > > fed into the DSA for production of the signature. > > > > 2) V4 Sig., type 0x18. Concatenate the following data then hash it for > > input into the DSA (the data to be hashed is terminated with the | char) > > > > header data > > > > 0x99 | > > 2 octet length | > > > > public DSA keys (version 4) > > > > 0x04 (version) | > > 4 octet time | > > 0x11 (for DSA signing algorithm) | > > MPI of DSA prime p | > > MPI of DSA grooup order q | > > MPI of DSA group generator g | > > MPI of DSA public key value y | > > > > header data > > > > 0x99 | > > 2 octet length | > > > > public ElGamal keys > > > > 0x04 (version) | > > 4 octet time | > > 0x10 (for ElGamal enc. algorithm) | > > MPI of ElGamal prime p | > > MPI of ElGamal group generator g | > > MPI of ElGamal public key value y | > > > > signature trailer > > > > version field to end of hashable data | > > > > V4 signature trailer > > > > 0x04 | > > 0xFF | > > 4 octet length | > > > > Once again, all the above data is concatenated then hashed. The left 16 > > bits are inserted into the hash check field of the signature and then the > > hash is fed into the DSA for production of the signature. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Thu Jul 13 12:41:12 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27857 for ; Thu, 13 Jul 2000 12:41:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28806 for ietf-openpgp-bks; Thu, 13 Jul 2000 08:39:38 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28796 for ; Thu, 13 Jul 2000 08:39:36 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA20889; Thu, 13 Jul 2000 08:41:20 -0700 Date: Thu, 13 Jul 2000 08:41:20 -0700 Message-Id: <200007131541.IAA20889@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: V4 Sig. incomplete? Cc: hal@finney.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >Yes, this all looks fine now. The one thing I'd add is that there is no > >need to parse out the key and subkey packets as you have done. After the > >0x99 and two-octet length, you just hash the key or subkey packet body. > >The specific contents of the key/subkey packet are irrelevant to the > >signature algotihm, it's just data to feed the hash. > > So you're saying that (1) is OK, however in the case of 2), it would be > best to structure it this way: No, I didn't mean that. All I meant was that you don't have to worry about the contents of the public key packets, the version and time and MPIs. Just hash the key packet data as a block. It makes it much easier to see what is going on: header data 0x99 | 2 octet length | key packet body data | user id data 0xb4 | 4 octet length | username data | signature trailer version field to end of hashable data | V4 signature trailer 0x04 | 0xFF | 4 octet length | From owner-ietf-openpgp@mail.imc.org Thu Jul 13 19:15:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13112 for ; Thu, 13 Jul 2000 19:15:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10789 for ietf-openpgp-bks; Thu, 13 Jul 2000 15:39:52 -0700 (PDT) Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10785 for ; Thu, 13 Jul 2000 15:39:51 -0700 (PDT) Received: from A261a.pppool.de (A261a.pppool.de [213.6.38.26]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id AAA15786 for ; Fri, 14 Jul 2000 00:41:52 +0200 (MET DST) Date: Thu, 13 Jul 2000 16:34:26 +0200 From: Marcel Zamzow X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Marcel Zamzow X-Priority: 3 (Normal) Message-ID: <8690.000713@zamzow.de> To: ietf-openpgp@imc.org Subject: VPN Systems via OpenPGP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Iserlohn, den 13.07.2000 Hello everybody, currently i´m evaluating the possibility to implement OpenPGP into an Open-Sourced VPN System. Has anybody some good url´s for me pointing to Virtual Private Networks ? All I have found is only pointing to the NAI´s Produkt and is too unprecised. Moreover has somebody already heard about such an implementation, cause this would be my work for my Diploma and so it should be something new. Best regards, Marcel - --- /* Marcel Zamzow, student of Computer Science [University of Applied Sciences Iserlohn] homepage : http://www.zamzow.de mailto : marcel@zamzow.de */ -----BEGIN PGP SIGNATURE----- iQIVAwUAOW3TbfPorQ0Gk425AQFnlA//e73nE6eCNQcDhXGzRTHv8IRQ6ubublPH bIP1sv29V3Xc+runIKWjpP66hur12DizD7gP2RCukLgMmcFCFTw1IDbXrJxtWmMC HN+QWDEY1Fpy9+OeKBIBDcHauSdYMoRk0c7ad+0eGCTuxhQjDl/YDO+qoWzFyYl5 qvq2L705L4AzLiIQSZJL7mR5XdqK3ZqCikgwfMkcEvlcnI369wL7qpoWgJgCM+eQ vDHiMlvfpF8Lm4KMiB/hTdm5SjhG/EJfsxp7KXVTBZrDh2yLuPTnjrn2d6FOa+vc R392NDtiAsi6H4jDthknW87KMHFycwcMYlfcB3J0pF2Td2IIGvQRd0Q34DohmBxk EdFuH7bQLNDhD72EFb2GriyVEBZC9sPt8+8BA7XeWVd3Ttr1AlWmcDGHbgmHRC9R slVK6zyHYFwSmdAtBJZyGp/zyzr2ld7pG0xp0v6WJxsV6WWD4CYJIy1OiWbu7b68 GrIXwntAt/DQ/nSGVuU6MfvYoxgi+k9ERSSzbO3SLxxWYGZTe5SeYXD1CkYu1fCG HpI4RM9JIGom9vF6eT+7dM92DXNPy7nBwkxXVAB6hWZ4VACoQQsuOsZWLYchMhqd 9uxsFuHwkxm9V01Ux7A1OzaFOzvKZ124qRwJGwppHV90b4XLL4ruvq6MPl5px+Z+ AUA3qrC9Pak= =/RbR -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jul 14 02:24:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01219 for ; Fri, 14 Jul 2000 02:24:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA03381 for ietf-openpgp-bks; Thu, 13 Jul 2000 23:01:37 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA03376 for ; Thu, 13 Jul 2000 23:01:34 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A0182530212; Fri, 14 Jul 2000 14:03:20 0800 Message-Id: <4.3.2.7.0.20000614132307.00af5718@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jun 2000 13:52:51 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: q re binding user id's and subkeys 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: To all, Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand how one binds an encryption sub key to a particular user id and the top level signing key? There seems to be no information contained in a sub-key packet that can link it to a user id. Also, the binding signature does not contain info regarding a user id (nor the binding signatures subpackets). By binding an encryption sub key to a primary signing key, you are binding it to multiple user id's (if multiple user id's exist), however if user id (a) wants to encrypt data using sub-key (b) and user id (b) wants to encrypt data using sub-key (a), where do you actually make the bind? My apologies if I've (once again), misread or completely missed something. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jul 14 11:27:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00808 for ; Fri, 14 Jul 2000 11:27:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22602 for ietf-openpgp-bks; Fri, 14 Jul 2000 08:09:33 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22598 for ; Fri, 14 Jul 2000 08:09:29 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA24491; Fri, 14 Jul 2000 08:11:19 -0700 Date: Fri, 14 Jul 2000 08:11:19 -0700 Message-Id: <200007141511.IAA24491@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: q re binding user id's and subkeys Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron writes: > Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand > how one binds an encryption sub key to a particular user id and the top > level signing key? You can't. > There seems to be no information contained in a sub-key packet that can > link it to a user id. Also, the binding signature does not contain info > regarding a user id (nor the binding signatures subpackets). That's right. > By binding an encryption sub key to a primary signing key, you are binding > it to multiple user id's (if multiple user id's exist), however if user id > (a) wants to encrypt data using sub-key (b) and user id (b) wants to > encrypt data using sub-key (a), where do you actually make the bind? There is no way to express this in OpenPGP. Hal From owner-ietf-openpgp@mail.imc.org Fri Jul 14 18:10:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05084 for ; Fri, 14 Jul 2000 18:10:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17121 for ietf-openpgp-bks; Fri, 14 Jul 2000 14:49:16 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17111 for ; Fri, 14 Jul 2000 14:49:14 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id OAA19015; Fri, 14 Jul 2000 14:51:14 -0700 Date: Fri, 14 Jul 2000 14:51:07 -0700 (PDT) From: "L. Sassaman" To: Marcel Zamzow cc: ietf-openpgp@imc.org Subject: Re: VPN Systems via OpenPGP In-Reply-To: <8690.000713@zamzow.de> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id OAA17112 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 13 Jul 2000, Marcel Zamzow wrote: > Iserlohn, den 13.07.2000 > > Hello everybody, > > currently i´m evaluating the possibility to > implement OpenPGP into an Open-Sourced VPN System. > Has anybody some good url´s for me pointing to > Virtual Private Networks ? All I have found is > only pointing to the NAI´s Produkt and is too > unprecised. > Moreover has somebody already heard about such an > implementation, cause this would be my work for > my Diploma and so it should be something new. Both FreeS/WAN and the OpenBSD IPsec products are open sourced. Does your project require you to start from scratch, or could you take a pre-existing VPN system and integrate OpenPGP into it? - --Len. __ L. Sassaman System Administrator | "Every window on Alcatraz has Technology Consultant | a view of San Francisco." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Susanna Kaysen -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5b4tSPYrxsgmsCmoRAjerAJ0UiVstcPKHv1Q9DJQ6UxhuvpVftgCg+rct tqFsJiIuA1BhGCsU1JwHgO4= =2kqu -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sat Jul 15 14:30:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04891 for ; Sat, 15 Jul 2000 14:30:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01790 for ietf-openpgp-bks; Sat, 15 Jul 2000 11:10:31 -0700 (PDT) Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01776 for ; Sat, 15 Jul 2000 11:10:29 -0700 (PDT) Received: from woudt.nl (cudomix.ai [209.88.68.210]) by cypherpunks.ai (Postfix) with ESMTP id D154B4D for ; Sat, 15 Jul 2000 14:12:10 -0400 (AST) Message-ID: <3970A977.D1FA0F2F@woudt.nl> Date: Sat, 15 Jul 2000 14:12:07 -0400 From: Edwin Woudt X-Mailer: Mozilla 4.73 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Signature Subpacket format questions 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 While implementing V4 signature support for a Java OpenPGP library, I encountered a few things with some Signature Subpackets that were not immediately clear to me. I would be very grateful if someone could answer these questions: * The format specified for both 5.2.3.18. 'Preferred key server' and 5.2.3.20. 'Policy URL' is 'String'. Is this string terminated by a null value, like 5.2.3.14. 'Regular expression', or not? * What is the format for 5.2.3.22. 'Signer's User ID'? A String like in the previous question? Edwin -- edwin@cryptix.org http://www.cryptix.org/products/openpgp/ From owner-ietf-openpgp@mail.imc.org Sat Jul 15 23:51:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA28936 for ; Sat, 15 Jul 2000 23:51:58 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19323 for ietf-openpgp-bks; Sat, 15 Jul 2000 20:33:49 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA19319 for ; Sat, 15 Jul 2000 20:33:46 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A07423B01D6; Sun, 16 Jul 2000 11:35:32 0800 Message-Id: <4.3.2.7.0.20000716111425.00aec828@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 16 Jul 2000 11:24:58 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: q re binding user id's and subkeys Cc: hal@finney.org In-Reply-To: <200007141511.IAA24491@finney.org> 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: Hal, At 08:11 AM 14/07/2000 -0700, hal@finney.org wrote: >Erron writes: > > Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand > > how one binds an encryption sub key to a particular user id and the top > > level signing key? > >You can't. > > By binding an encryption sub key to a primary signing key, you are binding > > it to multiple user id's (if multiple user id's exist), however if user id > > (a) wants to encrypt data using sub-key (b) and user id (b) wants to > > encrypt data using sub-key (a), where do you actually make the bind? > >There is no way to express this in OpenPGP. Would it be hard to express that in OpenPGP? Can a signature subkey be added that specifies the top level id that should be linked to the subkey? Accordingly, if the subkey is bound to all upper level id's (as is the case now) then the signature subkey would simply be left blank. If this cannot be done then I would assume that if you want different encryption keys for various user id's /alias's, then you would have to create two separate private keyrings that use different signing keys as well...or can you do this somehow using the same signing key? Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Sun Jul 16 11:50:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10148 for ; Sun, 16 Jul 2000 11:50:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11008 for ietf-openpgp-bks; Sun, 16 Jul 2000 08:33:47 -0700 (PDT) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10997 for ; Sun, 16 Jul 2000 08:33:45 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialup60.ip.lu [208.161.253.60]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id RAA18499; Sun, 16 Jul 2000 17:31:24 +0200 (CEST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 7963A2F033; Sun, 16 Jul 2000 12:30:00 +0200 (CEST) Date: Sun, 16 Jul 2000 12:30:00 +0200 From: Thomas Roessler To: Ian Bell , ietf-openpgp@imc.org, Michael Elkins , Dave Del Torto Subject: PGP/MIME: encoding restrictions. Message-ID: <20000716123000.A26892@sobolev.does-not-exist.org> Mail-Followup-To: Ian Bell , ietf-openpgp@imc.org, Michael Elkins , Dave Del Torto References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.5i In-Reply-To: ; from ianbell@turnpike.com on Thu, May 11, 2000 at 09:44:28AM +0100 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-05-11 09:44:28 +0100, Ian Bell wrote: > Should the issue of binary versus text-mode signatures > be addressed? It should, and I believe the following would be the most robust solution: (1) require clients to create text mode signatures (2) require clients to use either quoted-printable or base64 for any body parts which contain trailing whitespace. Note that this seems to be what most clients do anyway at present. Rationale: MIME has been carefully designed in a way which makes sure that all essential information makes it through gateways which tamper with trailing whitespace. Thus, we should make sure that PGP/MIME signed messages don't lose any information on such paths, either. Not losing any information in the signed body is guaranteed by the use of qp/base64, whenever trailing whitespace is present. Not unnecesarily invalidating signatures is guaranteed by the use of text-mode signatures, since these signatures will ignore any trailing whitespace. Note that this trailing whitespace must be ignored by standard-conforming decoders for qp/base64, too, and doesn't carry any meaning in RFC822 (think about message/rfc822 attachments) or MIME headers, so signature verification will fail if and only if actual content has been modified. Binary-mode signatures would also be invalidated if trailing whitespace is tampered with, even though it doesn't carry any meaning to the MIME encoding used. Comments? -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Sun Jul 16 19:32:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26782 for ; Sun, 16 Jul 2000 19:32:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18789 for ietf-openpgp-bks; Sun, 16 Jul 2000 16:17:24 -0700 (PDT) Received: from alpha.pit.adelphia.net (alpha.pit.adelphia.net [24.48.44.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18784 for ; Sun, 16 Jul 2000 16:17:22 -0700 (PDT) Received: from mwyoung.transarc.com (pa-bethelpark1b-76.pit.adelphia.net [24.48.158.76]) by alpha.pit.adelphia.net (8.9.2/8.9.2) with SMTP id TAA04326 for ; Sun, 16 Jul 2000 19:19:36 -0400 (EDT) Message-ID: <000501bfef7b$a4f070a0$023fa8c0@mwyoung.transarc.com> From: "Michael Young" To: Subject: Resolution on large-block ciphers (e.g., Blowfish), PGP7 Date: Sun, 16 Jul 2000 19:14:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Looking through the archives, I see discussion on how to handle ciphers with block sizes over 8 bytes, but the resolution was not clear. The draft has been updated regarding SE data packets (tag 9). This appears to match the example that Werner Koch posted on April 9, 1999. (My implementation matches that example.) The draft makes no mention of how to encrypt secret keys. It still mentions an 8-byte IV. I didn't see a clear winner in the discussion: an 8-byte IV seems decidedly inadequate; having the IV length depend on the algorithm number would require a table for parsing; using a new version number to allow a length to be inserted wouldn't be too bad. Simply inserting a length (or making the IV an MPI) for algorithms 6 and beyond would be workable. Was there a resolution that I missed, and if so, will it be in an upcoming draft? If the intention is really to stick with an 8-byte IV, can the RFC be updated to discuss exactly how it works in this context? The press releases for PGP version 7 from NAI says that it will include Blowfish support. Can someone from NAI (or a beta customer) confirm that they conform to the current draft? How do they deal with secret key encryption using Blowfish? From owner-ietf-openpgp@mail.imc.org Sun Jul 16 20:12:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26784 for ; Sun, 16 Jul 2000 19:32:22 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18770 for ietf-openpgp-bks; Sun, 16 Jul 2000 16:16:25 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18765 for ; Sun, 16 Jul 2000 16:16:18 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA30461; Sun, 16 Jul 2000 16:18:21 -0700 Date: Sun, 16 Jul 2000 16:18:21 -0700 Message-Id: <200007162318.QAA30461@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: q re binding user id's and subkeys Cc: hal@finney.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron Criddle writes: > > > By binding an encryption sub key to a primary signing key, you are binding > > > it to multiple user id's (if multiple user id's exist), however if user id > > > (a) wants to encrypt data using sub-key (b) and user id (b) wants to > > > encrypt data using sub-key (a), where do you actually make the bind? > > > >There is no way to express this in OpenPGP. > > Would it be hard to express that in OpenPGP? Can a signature subkey be > added that specifies the top level id that should be linked to the subkey? > Accordingly, if the subkey is bound to all upper level id's (as is the case > now) then the signature subkey would simply be left blank. Well, there is no way to express that in OpenPGP. If you are asking, could we add a way to do that, the answer is that it would be technically possible. The question is whether there is sufficient desire to add that. I think if you wanted to do this, it would be better to add a way for a given userid self-sig to say which subkey to use when that userid was chosen as an encryption target, rather than the other way around (subkey to point at userid). Without this mechanism, the main use of multiple subkeys is to make it easy to roll over your encryption keys relatively often, without invalidating the validity of your key. That's an important piece of functionality in itself. We might wish to discuss whether it is worthwhile to go beyond this to also allow the use of different subkeys for different userids. It would add considerable complexity to the UI, and at PGP.com we are if anything trying to simplify the UI. Most users still say encryption is too hard to use. Hal Finney From owner-ietf-openpgp@mail.imc.org Sun Jul 16 23:18:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA20608 for ; Sun, 16 Jul 2000 23:18:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA29002 for ietf-openpgp-bks; Sun, 16 Jul 2000 20:03:14 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28998 for ; Sun, 16 Jul 2000 20:03:12 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id UAA30732; Sun, 16 Jul 2000 20:05:20 -0700 Date: Sun, 16 Jul 2000 20:05:20 -0700 Message-Id: <200007170305.UAA30732@finney.org> To: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Subject: Re: Resolution on large-block ciphers (e.g., Blowfish), PGP7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The press releases for PGP version 7 from NAI says that it will include > Blowfish support. Can someone from NAI (or a beta customer) confirm > that they conform to the current draft? How do they deal with secret key > encryption using Blowfish? You mean Twofish. PGP version 7 will use a 16 byte (128 bit) IV when encrypting secret keys using Twofish. Hal Finney From owner-ietf-openpgp@mail.imc.org Sun Jul 16 23:56:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00849 for ; Sun, 16 Jul 2000 23:56:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA00972 for ietf-openpgp-bks; Sun, 16 Jul 2000 20:43:43 -0700 (PDT) Received: from cypherspace.org (adam@modemcable249.22-201-24.mtl.mc.videotron.net [24.201.22.249]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA00965 for ; Sun, 16 Jul 2000 20:43:42 -0700 (PDT) Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id XAA01334; Sun, 16 Jul 2000 23:47:30 -0500 Date: Sun, 16 Jul 2000 23:47:30 -0500 Message-Id: <200007170447.XAA01334@cypherspace.org> From: Adam Back To: I.Brown@cs.ucl.ac.uk Cc: ietf-openpgp@imc.org In-reply-to: <3963142F.E8971209@cs.ucl.ac.uk> (message from Ian Brown on Wed, 05 Jul 2000 11:55:43 +0100) Subject: Re: Forward secrecy Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Section 3 describes one-time keys, that are sent with messages to allow a the recipient to reply with immediate forward secrecy (immediately after receipt). I wonder if we could use a one-time key server to avoid the need for interactive use of email (need a reply from the recipient to get a key to reply to). Lets say we add a new function to keyservers which is that you submit a whole bunch of keys, and it hands them out on request, and deletes them after they've been received. I guess there's a pretty easy DoS there -- someone just goes and repeatedly downloads all available keys, to deny others the ability to obtain one-time keys. There might be some weak approaches to resist this DoS (eg refuse to provide more than one one-time key per time period to the same IP address), but they are just that -- weak. Adam From owner-ietf-openpgp@mail.imc.org Mon Jul 17 05:21:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA07420 for ; Mon, 17 Jul 2000 05:21:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA06720 for ietf-openpgp-bks; Mon, 17 Jul 2000 02:03:24 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06715 for ; Mon, 17 Jul 2000 02:03:22 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13E77v-0002Oz-00; Mon, 17 Jul 2000 11:23:51 +0200 Date: Mon, 17 Jul 2000 11:23:51 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Resolution on large-block ciphers (e.g., Blowfish), PGP7 Message-ID: <20000717112351.F8949@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <000501bfef7b$a4f070a0$023fa8c0@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <000501bfef7b$a4f070a0$023fa8c0@mwyoung.transarc.com>; from mwy-opgp97@the-youngs.org on Sun, Jul 16, 2000 at 07:14:42PM -0400 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 16 Jul 2000, Michael Young wrote: > The draft makes no mention of how to encrypt secret keys. It still mentions > an 8-byte IV. I didn't see a clear winner in the discussion: an 8-byte IV IIRC it mention 8 byte IV only in the example. The specification should say an IV of the the same size as the blocksize. GnuPG 1.0.2 does exactly this. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Mon Jul 17 08:55:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01754 for ; Mon, 17 Jul 2000 08:55:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA12955 for ietf-openpgp-bks; Mon, 17 Jul 2000 05:33:23 -0700 (PDT) Received: from alpha.pit.adelphia.net (alpha.pit.adelphia.net [24.48.44.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12950 for ; Mon, 17 Jul 2000 05:33:21 -0700 (PDT) Received: from mwyoung.transarc.com (pa-bethelpark1b-76.pit.adelphia.net [24.48.158.76]) by alpha.pit.adelphia.net (8.9.2/8.9.2) with SMTP id IAA24095 for ; Mon, 17 Jul 2000 08:35:41 -0400 (EDT) Message-ID: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Date: Mon, 17 Jul 2000 08:30:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Yes, I meant Twofish, not Blowfish. The draft I found at imc.org still says in section 5.5.3: > - [Optional] If secret data is encrypted, eight-octet Initial > Vector (IV). This should now read "an IV of the same length as the cipher block"? [Is there a more recent draft than that posted at imc.org? That one claims to expire June 2000.] As Werner Koch pointed out last year, this will require an implementation to know the block size simply in order to parse the rest of the packet. Given that the only material after the IV is the encrypted part, and thus won't be readable anyway without support for that cipher, I suppose this isn't all that serious. But is there any intention to make the IV size self-describing for future ciphers, or is this the final plan? Thanks for the quick responses. From owner-ietf-openpgp@mail.imc.org Mon Jul 17 09:42:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12495 for ; Mon, 17 Jul 2000 09:42:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14018 for ietf-openpgp-bks; Mon, 17 Jul 2000 06:28:03 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14013 for ; Mon, 17 Jul 2000 06:28:01 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13EBG5-0002fu-00; Mon, 17 Jul 2000 15:48:33 +0200 Date: Mon, 17 Jul 2000 15:48:33 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Message-ID: <20000717154833.F9590@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com>; from mwy-opgp97@the-youngs.org on Mon, Jul 17, 2000 at 08:30:50AM -0400 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 17 Jul 2000, Michael Young wrote: > The draft I found at imc.org still says in section 5.5.3: > > - [Optional] If secret data is encrypted, eight-octet Initial > > Vector (IV). > > This should now read "an IV of the same length as the cipher block"? 5.7. got it right. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Mon Jul 17 10:16:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26482 for ; Mon, 17 Jul 2000 10:16:39 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14402 for ietf-openpgp-bks; Mon, 17 Jul 2000 06:52:30 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14398 for ; Mon, 17 Jul 2000 06:52:29 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyfv03549; Mon, 17 Jul 2000 13:54:45 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08232; Mon, 17 Jul 00 09:50:52 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA11050; Mon, 17 Jul 2000 09:54:44 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14707.4132.556781.464112@xedia.com> Date: Mon, 17 Jul 2000 09:54:44 -0400 (EDT) To: mwy-opgp97@the-youngs.org Cc: ietf-openpgp@imc.org Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 References: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Michael" == Michael Young writes: Michael> Yes, I meant Twofish, not Blowfish. The draft I found at Michael> imc.org still says in section 5.5.3: >> - [Optional] If secret data is encrypted, eight-octet Initial >> Vector (IV). Michael> This should now read "an IV of the same length as the cipher Michael> block"? Clearly yes. The IV always must be the same size as the blocksize for any block cipher. Michael> As Werner Koch pointed out last year, this will require an Michael> implementation to know the block size simply in order to Michael> parse the rest of the packet. Given that the only material Michael> after the IV is the encrypted part, and thus won't be Michael> readable anyway without support for that cipher, I suppose Michael> this isn't all that serious. But is there any intention to Michael> make the IV size self-describing for future ciphers, or is Michael> this the final plan? Can't see any reason to change that. You only need to know the IV if you're going to decrypt. And to do that clearly you must know the cipher, which includes knowing its blocksize. If you're not going to decrypt, you might as well consider the IV as part of the encrypted message, since it doesn't contain any interesting information. paul From owner-ietf-openpgp@mail.imc.org Mon Jul 17 12:07:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13658 for ; Mon, 17 Jul 2000 12:07:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17225 for ietf-openpgp-bks; Mon, 17 Jul 2000 08:47:43 -0700 (PDT) Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17221 for ; Mon, 17 Jul 2000 08:47:41 -0700 (PDT) Received: from A1ba8.pppool.de (A1ba8.pppool.de [213.6.27.168]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id RAA17212; Mon, 17 Jul 2000 17:49:53 +0200 (MET DST) Date: Mon, 17 Jul 2000 14:38:42 +0200 From: Marcel Zamzow X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Marcel Zamzow X-Priority: 3 (Normal) Message-ID: <15610.000717@zamzow.de> To: "L. Sassaman" Subject: Re[2]: VPN Systems via OpenPGP In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hello! Friday, July 14, 2000, 11:51:07 PM, you wrote: LS> Both FreeS/WAN and the OpenBSD IPsec products are open sourced. Does your LS> project require you to start from scratch, or could you take a LS> pre-existing VPN system and integrate OpenPGP into it? Well, I think I'll first have a close look to those products, but generally I'd like to do it the hard way . My aim isn´t a complete end-user software-package, but instead a nice technology-study. But encryption should already be performed on the tcp/ip level. Best regards, Marcel - --- /* Marcel Zamzow, student of Computer Science [University of Applied Sciences Iserlohn] homepage : http://www.zamzow.de mailto : marcel@zamzow.de */ -----BEGIN PGP SIGNATURE----- iQIVAwUAOXL+DfPorQ0Gk425AQF4uw/9F+JZgG7tdBKbKR5wX1a8ydfuhXVfWMjh hy+btzFb8ZR5RSWJ7Xlt+I21sSFtYhgiJzT4NDdDfjoT32aEMnptv5vS2XQjousf 99GndPmXLVvOcsPYt6+Y8Z6DR2ilKAOYKxw4scNFmSuzkoKLN1TrDDCPDJB6D2YS bLhKBE+9GZtztt9j9PO7j2DjwjutyGKlymlfZzOPuW74CrGpYODdXf0VqQEp56DF Svt7xdyWtnDVCYeP96oWH1aCyz8U7Eafuk7j2G0j//LNAYPBuAVtdJHvCeELAV/e 9EQyRndUwyJ7Bz6rp8cv0sQT+3ikc+9IImmSzTjq9t8J9axXhAwRZIT4ZM4//nF0 O6c4UYUFSsj/wOBc8uETVXnEwH0xOVg/UEks+k3NZxxUFiFY3IkK4Ug6xnVyBoPH WhbS2nG6NxAiIg+0Nvntz37r/JZWw+Km47HzS26kneJ4idT5vccukVEByrJMtQEi jTXRpgV1sleh8dSqtSZLu9zKC4ukWskFXvFhpYRch6KmPNeornGPlLAGICrgnSER GPOxvW40763jwjW/YNs34fVynR5zVEnM+absFpUf6JSD/lqx9psHGY02mTpS3wOu X7s3iH5XtxsRH14pdohw+em1igMl2OSDizv4f4x3+KDEwURMjzohzP7PDhg2LYpy TULaBkjD8NE= =ZX+L -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 17 12:55:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29075 for ; Mon, 17 Jul 2000 12:55:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18076 for ietf-openpgp-bks; Mon, 17 Jul 2000 09:29:55 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18068 for ; Mon, 17 Jul 2000 09:29:53 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA31966; Mon, 17 Jul 2000 09:32:05 -0700 Date: Mon, 17 Jul 2000 09:32:05 -0700 Message-Id: <200007171632.JAA31966@finney.org> To: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From owner-ietf-openpgp@mail.imc.org Mon Jul 17 06:29:39 2000 > From: "Michael Young" > To: > Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 > Date: Mon, 17 Jul 2000 08:30:50 -0400 > X-Priority: 3 > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 > List-Archive: > List-ID: > > Yes, I meant Twofish, not Blowfish. > > The draft I found at imc.org still says in section 5.5.3: > > - [Optional] If secret data is encrypted, eight-octet Initial > > Vector (IV). > > This should now read "an IV of the same length as the cipher block"? I suppose so. > [Is there a more recent draft than that posted at imc.org? That one > claims to expire June 2000.] I don't know. > As Werner Koch pointed out last year, this will require an implementation > to know the block size simply in order to parse the rest of the packet. > Given that the only material after the IV is the encrypted part, and thus > won't be readable anyway without support for that cipher, I suppose this > isn't all that serious. But is there any intention to make the IV size > self-describing for future ciphers, or is this the final plan? We already have this problem, because StringToKey structures also do not have their length self-describing. Hitting an unknown S2K identifier leaves you in the same boat. Luckily it never matters, as in all cases, there is nothing left in the packet to parse if you don't know how to decode it. Hal From owner-ietf-openpgp@mail.imc.org Mon Jul 17 19:23:48 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15556 for ; Mon, 17 Jul 2000 19:23:47 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA25628 for ietf-openpgp-bks; Mon, 17 Jul 2000 16:06:03 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25624 for ; Mon, 17 Jul 2000 16:06:02 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id TAA26169; Mon, 17 Jul 2000 19:08:16 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id TAA16183; Mon, 17 Jul 2000 19:07:49 -0400 Date: Mon, 17 Jul 2000 19:07:49 -0400 From: Tom Zerucha To: hal@finney.org Cc: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Message-ID: <20000717190749.A16084@deimos.mw.mediaone.net> References: <200007171632.JAA31966@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007171632.JAA31966@finney.org>; from hal@finney.org on Mon, Jul 17, 2000 at 09:32:05AM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jul 17, 2000 at 09:32:05AM -0700, hal@finney.org wrote: > > From owner-ietf-openpgp@mail.imc.org Mon Jul 17 06:29:39 2000 > > From: "Michael Young" > > Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 > > > > Yes, I meant Twofish, not Blowfish. > > > > The draft I found at imc.org still says in section 5.5.3: > > > - [Optional] If secret data is encrypted, eight-octet Initial > > > Vector (IV). > > > > This should now read "an IV of the same length as the cipher block"? > > I suppose so. And... 3.6.2.1... These are followed by an 8-octet Initial Vector for the decryption of the secret values, if they are encrypted, and then the secret key values themselves. Do you do the CFB resets on MPI boundaries with V3 keys? (I asked about this in an earlier post noting all the places where the PGP-CFB and the reset were done - I'll see if I can easily repost it). From owner-ietf-openpgp@mail.imc.org Mon Jul 17 19:56:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27907 for ; Mon, 17 Jul 2000 19:56:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA26320 for ietf-openpgp-bks; Mon, 17 Jul 2000 16:35:35 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26316 for ; Mon, 17 Jul 2000 16:35:27 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA01170; Mon, 17 Jul 2000 16:37:39 -0700 Date: Mon, 17 Jul 2000 16:37:39 -0700 Message-Id: <200007172337.QAA01170@finney.org> To: hal@finney.org, tz@execpc.com Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Cc: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Do you do the CFB resets on MPI boundaries with V3 keys? Yes. Hal From owner-ietf-openpgp@mail.imc.org Mon Jul 17 20:40:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA13998 for ; Mon, 17 Jul 2000 20:40:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27709 for ietf-openpgp-bks; Mon, 17 Jul 2000 17:19:59 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27705 for ; Mon, 17 Jul 2000 17:19:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA26176; Mon, 17 Jul 2000 17:21:51 -0700 (PDT) Received: from [63.73.97.183] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA26172; Mon, 17 Jul 2000 17:21:49 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> References: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> Date: Mon, 17 Jul 2000 17:21:28 -0700 To: "Michael Young" , From: Jon Callas Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:30 AM -0400 7/17/00, Michael Young wrote: >This should now read "an IV of the same length as the cipher block"? > Fixed. Jon From owner-ietf-openpgp@mail.imc.org Mon Jul 17 20:46:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16800 for ; Mon, 17 Jul 2000 20:46:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27817 for ietf-openpgp-bks; Mon, 17 Jul 2000 17:22:34 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27813 for ; Mon, 17 Jul 2000 17:22:34 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA26208; Mon, 17 Jul 2000 17:23:43 -0700 (PDT) Received: from [63.73.97.183] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA26204; Mon, 17 Jul 2000 17:23:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000717190749.A16084@deimos.mw.mediaone.net> References: <200007171632.JAA31966@finney.org> <20000717190749.A16084@deimos.mw.mediaone.net> Date: Mon, 17 Jul 2000 17:23:35 -0700 To: Tom Zerucha , hal@finney.org From: Jon Callas Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Cc: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:07 PM -0400 7/17/00, Tom Zerucha wrote: >3.6.2.1... > > These are followed by an 8-octet Initial Vector for the decryption of > the secret values, if they are encrypted, and then the secret key > values themselves. > Also fixed. Thank you, folks. Jon From owner-ietf-openpgp@mail.imc.org Tue Jul 18 02:12:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05325 for ; Tue, 18 Jul 2000 02:12:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21141 for ietf-openpgp-bks; Mon, 17 Jul 2000 22:48:58 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21136 for ; Mon, 17 Jul 2000 22:48:55 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A33D51702A2; Tue, 18 Jul 2000 13:51:09 0800 Message-Id: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 13:40:26 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: CFB Mode correction in 12.8? 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: To all, Regarding previous posts and block sizes etc etc, should 12.8 (part 10) read: FROM: 10) FR is loaded with C11 to C18 TO: 10) FR is loaded with C[BS+3] to C[BS + (BS+2)] Cheers. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Tue Jul 18 05:04:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13539 for ; Tue, 18 Jul 2000 05:04:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02089 for ietf-openpgp-bks; Tue, 18 Jul 2000 01:42:51 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02083 for ; Tue, 18 Jul 2000 01:42:49 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA14223; Tue, 18 Jul 2000 09:45:12 +0100 (BST) Message-ID: <7aMvAWASiBd5IAKr@turnpike.com> Date: Tue, 18 Jul 2000 09:42:58 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME: encoding restrictions. References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> <20000716123000.A26892@sobolev.does-not-exist.org> In-Reply-To: <20000716123000.A26892@sobolev.does-not-exist.org> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 16 Jul 2000, Thomas Roessler wrote: >On 2000-05-11 09:44:28 +0100, Ian Bell wrote: > >> Should the issue of binary versus text-mode signatures >> be addressed? > >It should, and I believe the following would be the most >robust solution: > >(1) require clients to create text mode signatures >(2) require clients to use either quoted-printable or > base64 for any body parts which contain trailing > whitespace. > >Note that this seems to be what most clients do anyway at >present. [snip rationale] This also satisfies the design objective of RFC1847 for single-pass processing of the hashes (whether or not there are clients that rely on that) without inventing new parameters. I would suggest: clients MUST create text mode signature though clients MAY verify binary-mode signatures However, I'm not so sure about (2). At most: clients SHOULD use qp or base64 whenever there is significant white space (i.e. _not_ MUST). The cost of not using qp is that trailing whitespace is not protected, but if clients have "good" reasons for not using qp they should be allowed to consider that option. For example, in draft-ietf-usefor-article-02 (USEFOR) it says "Posting agents SHOULD NOT use the encoding method quoted-printable". Since USEFOR articles will usually contain trailing whitespace (personal signatures MUST be delimited by "-- "), clients will be unable to post RFC2015bis articles to UseNet without breaking one RFC or another. -- Ian Bell T U R N P I K E Ltd From owner-ietf-openpgp@mail.imc.org Tue Jul 18 06:03:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02830 for ; Tue, 18 Jul 2000 06:03:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA04499 for ietf-openpgp-bks; Tue, 18 Jul 2000 02:36:55 -0700 (PDT) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA04495 for ; Tue, 18 Jul 2000 02:36:53 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialup20.ip.lu [208.161.253.20]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id LAA05257 for ; Tue, 18 Jul 2000 11:39:16 +0200 (CEST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id CD3642F032; Tue, 18 Jul 2000 11:39:14 +0200 (CEST) Date: Tue, 18 Jul 2000 11:39:14 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: PGP/MIME: encoding restrictions. Message-ID: <20000718113914.B14695@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> <20000716123000.A26892@sobolev.does-not-exist.org> <7aMvAWASiBd5IAKr@turnpike.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.5i In-Reply-To: <7aMvAWASiBd5IAKr@turnpike.com>; from ianbell@turnpike.com on Tue, Jul 18, 2000 at 09:42:58AM +0100 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-07-18 09:42:58 +0100, Ian Bell wrote: > For example, in draft-ietf-usefor-article-02 (USEFOR) > it says "Posting agents SHOULD NOT use the encoding > method quoted-printable". Since USEFOR articles will > usually contain trailing whitespace (personal > signatures MUST be delimited by "-- "), clients will be > unable to post RFC2015bis articles to UseNet without > breaking one RFC or another. If you happen to be on the USEFOR list, it would be nice if you could ask them to add an exception for cryptographically signed messages just like the one in the "text/plain; format=flowed" RFC. After all, a restriction like the one you quote only makes sense in a context where MIME is avoided. People using multipart/signed bother recipients with MIME anyway, so the content-transfer-encoding of the text transmitted isn't really an issue any more. -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Tue Jul 18 11:18:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15148 for ; Tue, 18 Jul 2000 11:18:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23398 for ietf-openpgp-bks; Tue, 18 Jul 2000 08:01:25 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23385 for ; Tue, 18 Jul 2000 08:01:23 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA08281; Tue, 18 Jul 2000 11:03:44 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id LAA15925; Tue, 18 Jul 2000 11:03:02 -0400 Date: Tue, 18 Jul 2000 11:03:02 -0400 From: Tom Zerucha To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: CFB Mode correction in 12.8? Message-ID: <20000718110302.A15919@deimos.mw.mediaone.net> References: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com>; from ejc@comasp.com on Tue, Jul 18, 2000 at 01:40:26PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jul 18, 2000 at 01:40:26PM +0800, Erron Criddle wrote: > To all, > > Regarding previous posts and block sizes etc etc, should 12.8 (part 10) read: > > FROM: > > 10) FR is loaded with C11 to C18 > > TO: > > 10) FR is loaded with C[BS+3] to C[BS + (BS+2)] Yes and no. The earlier paragraph (the third one in the section) explains about block sizes <> 8 bytes. It should say that the procedure/example is using an 8 byte cipher, and perhaps note your modification to 10 above. If you describe everything (in this case examples) with mathematical equations that are correct in all situations, the spec becomes even harder to understand. The exact details are described precisely elsewhere, but because of that complexity this section attempts to explain it more like pseudocode. I am not adverse to any adjustment, but I would prefer it in the form of footnotes or parenthesis just to keep the instructions simpler. From owner-ietf-openpgp@mail.imc.org Tue Jul 18 17:05:17 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20156 for ; Tue, 18 Jul 2000 17:05:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id NAA08055 for ietf-openpgp-bks; Tue, 18 Jul 2000 13:48:19 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08051 for ; Tue, 18 Jul 2000 13:48:18 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id NAA07706; Tue, 18 Jul 2000 13:50:16 -0700 (PDT) Received: from [63.73.97.186] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id NAA07702; Tue, 18 Jul 2000 13:50:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> References: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> Date: Tue, 18 Jul 2000 13:22:48 -0700 To: Erron Criddle , ietf-openpgp@imc.org From: Jon Callas Subject: Re: CFB Mode correction in 12.8? Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:40 PM +0800 7/18/00, Erron Criddle wrote: >FROM: > >10) FR is loaded with C11 to C18 > >TO: > >10) FR is loaded with C[BS+3] to C[BS + (BS+2)] > I changed it to: FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an 8-octet block). I think this addresses all the concerns? Thanks. Jon From owner-ietf-openpgp@mail.imc.org Tue Jul 18 22:18:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11144 for ; Tue, 18 Jul 2000 22:18:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA19994 for ietf-openpgp-bks; Tue, 18 Jul 2000 18:59:35 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA19983 for ; Tue, 18 Jul 2000 18:59:31 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AEFF5F00216; Wed, 19 Jul 2000 10:01:51 0800 Message-Id: <4.3.2.7.0.20000719094751.00b42ab0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 09:51:06 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: CFB Mode correction in 12.8? Cc: Jon Callas In-Reply-To: References: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.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 01:22 PM 18/07/2000 -0700, Jon Callas wrote: >At 1:40 PM +0800 7/18/00, Erron Criddle wrote: > > >FROM: > > > >10) FR is loaded with C11 to C18 > > > >TO: > > > >10) FR is loaded with C[BS+3] to C[BS + (BS+2)] > > > >I changed it to: > >FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an >8-octet block). > >I think this addresses all the concerns? Yes - the more well defined the RFC is, the easier it will be for others to understand in the future. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Wed Jul 19 03:43:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21973 for ; Wed, 19 Jul 2000 03:43:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09384 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:29:42 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09375 for ; Wed, 19 Jul 2000 00:29:37 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 9189 invoked from network); 19 Jul 2000 07:31:14 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:31:14 -0000 To: ietf-openpgp@imc.org Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. In-Reply-To: <20000710154438W.1001@eccosys.com> References: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> <20000710154438W.1001@eccosys.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719163226I.1001@eccosys.com> Date: Wed, 19 Jul 2000 16:32:26 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 12 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit i didn't see any other responses to this thread. was there a verdict on this issue? that is, should the specification say: Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message or Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message ? From owner-ietf-openpgp@mail.imc.org Wed Jul 19 03:43:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22208 for ; Wed, 19 Jul 2000 03:43:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09109 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:26:05 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09097 for ; Wed, 19 Jul 2000 00:25:57 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 9097 invoked from network); 19 Jul 2000 07:27:25 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:27:25 -0000 To: ietf-openpgp@imc.org Subject: Re: Signature Subpacket format questions In-Reply-To: <3970A977.D1FA0F2F@woudt.nl> References: <3970A977.D1FA0F2F@woudt.nl> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719162830J.1001@eccosys.com> Date: Wed, 19 Jul 2000 16:28:30 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Edwin Woudt Subject: Signature Subpacket format questions Date: Sat, 15 Jul 2000 14:12:07 -0400 Message-ID: <3970A977.D1FA0F2F@woudt.nl> > While implementing V4 signature support for a Java OpenPGP library, I > encountered a few things with some Signature Subpackets that were not > immediately clear to me. I would be very grateful if someone could > answer these questions: i wouldn't take the following as definitive answers, but here's some feedback anyway. > * The format specified for both 5.2.3.18. 'Preferred key server' and > 5.2.3.20. 'Policy URL' is 'String'. Is this string terminated by a > null value, like 5.2.3.14. 'Regular expression', or not? since there does not appear to be any mention of null-termination in the section on text (3.4), i interpreted "String" to mean that there is no null-termination. [ also because many of the field boundaries can be determined by various lengths that are explicitly spelled out as well as length definitions. ] > * What is the format for 5.2.3.22. 'Signer's User ID'? A String like in > the previous question? i interpreted this to refer to what is stored in the body of a user id packet (5.11) -- so, if the contents of the body are text, it's encoded in utf-8. since 5.11 doesn't really say much about non-text, i don't know about that case ;-) From owner-ietf-openpgp@mail.imc.org Wed Jul 19 03:58:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27882 for ; Wed, 19 Jul 2000 03:58:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09913 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:38:47 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09909 for ; Wed, 19 Jul 2000 00:38:45 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 9318 invoked from network); 19 Jul 2000 07:40:22 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:40:22 -0000 To: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: References: <200007101810.LAA11952@finney.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719164134K.1001@eccosys.com> Date: Wed, 19 Jul 2000 16:41:34 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: "L. Sassaman" Subject: Re: Question regarding 2440:5.2.3.16 Date: Mon, 10 Jul 2000 11:29:05 -0700 (PDT) Message-ID: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 10 Jul 2000 hal@finney.org wrote: > > > That seems OK, or perhaps you could use an SSL (TLS) session using the > > PGP key to authenticate the client. In any case I don't think this > > mechanism should be documented in 2440. > > That's fine, but I do think that this definately needs to be > documented. If 2440 isn't the place, then we need to start work on a > keyserver draft. have you started a draft? From owner-ietf-openpgp@mail.imc.org Wed Jul 19 03:58:40 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA28058 for ; Wed, 19 Jul 2000 03:58:40 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA09884 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:38:16 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09879 for ; Wed, 19 Jul 2000 00:38:13 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 9310 invoked from network); 19 Jul 2000 07:39:50 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:39:50 -0000 To: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: References: <20000710123746Y.1001@eccosys.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719164101S.1001@eccosys.com> Date: Wed, 19 Jul 2000 16:41:01 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 80 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit sorry for the horribly slow response. From: "L. Sassaman" Subject: Re: Question regarding 2440:5.2.3.16 Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT) Message-ID: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 10 Jul 2000 sen_ml@eccosys.com wrote: > > > so you are suggesting that proof of ownership of the corresponding > > secret key (via an appropriate signature) should server this purpose, > > right? > > Yes, because the owner needs to prove he has the secret key, and the > public key block that is to be added must be signed to prevent > unauthorized signatures being added during this process. sure, i was just making sure i followed your statements. > > > Werner Koch and I have been discussing this, and he suggests that we put > > > it into a clear-text signature packet. Would that be suitable? > > > > would you mind briefly describing the steps involved for the mechanism > > you are considering (in terms like "first, the client connects to the > > server. then the server responds w/..." etc.)? > > > > [ i understand what you are saying about the form a signature would > > take, but i don't see the overall flow of the process of > > authentication. ] > > The client takes the public key block, signs it, and submits this signed > blob to the server. The server then verifies the signature, trims away > that signature, and adds the key. thanks for the explanation. > Keys that are added unsigned should always be checked for the existance of > the "no-modify" flag, and rejected if it exists. > > Furthermore, I suggest that we have a "modify" flag added to the spec, so > that, if a signature is made at a later date containing this flag, it > would superceed a preveous no-modify. But that digresses from this > discussion. that makes sense. > > also, is it necessary to consider replay attacks for this kind of > > scenario? alternatively, would the following scenario be of any concern: > > > > an attacker captures a session between a user and a keyserver at some > > point in time. later, after the user has made several updates to the > > keyserver, the attacker replays the captured session to set the > > state of the user's key to an earlier state. > > This scenerio is only partially valid. A signed key that is added to a > server does not remove the previous key and replace it with the new > one. It is treated like and other add, and is merged with the existing > key. So, an attacker could not truly set the key to a previous state. is there a reason why it is not replacement? from the standpoint of a user, i think i prefer replacement as that goes along w/ being able to delete. > What an attacker *could* do, via a replay attack, is re-add signatures or > user-ids to a key on the server that the owner had later deleted. I see > this as a minor annoyance, rather than an attack, so I don't think that we > need to address it. (Though we could, through the use of server tokens or > timestamps, etc. I just think it is more work than is necessary.) i guess i'd prefer to have the ability to delete things and then not have other people be able to add things back later. whether the annoyance is minor or major is in the eye of the beholder, imo. i don't consider it minor. i would prefer to have a timestamp / server token kind of a set-up. if some people don't care about this and others do, i suppose it could also be expressed as policy as part of a user's key. From owner-ietf-openpgp@mail.imc.org Wed Jul 19 04:01:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28924 for ; Wed, 19 Jul 2000 04:01:11 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA10184 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:47:17 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA10176 for ; Wed, 19 Jul 2000 00:47:12 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A07D2AF0182; Wed, 19 Jul 2000 15:49:33 0800 Message-Id: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 15:38:46 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: sig. subpacket & length conflicts? 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: To all, I think I have found another area that *may* be contradictory. Regarding V4 sigs the two octet scalar octet count for hashable and unhashable packets conflicts with the signature subpacket lengths. As stated in 5.2.3.1, signature subpackets can contain lengths up to 0xFFFFFFFF, however the maximum length as defined for ALL hashable (or unhashable) subpackets is a maximum of 8383 bytes (as indicated by a two octet scalar). So, do we limit the subpacket length to two bytes or redefine that maximum allowed total length for all subpackets (of type hashable or unhashable) as 0xFFFFFFFF ( up to 5 bytes)? TIA. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Wed Jul 19 04:41:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12710 for ; Wed, 19 Jul 2000 04:41:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA11469 for ietf-openpgp-bks; Wed, 19 Jul 2000 01:26:53 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA11463 for ; Wed, 19 Jul 2000 01:26:50 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 10152 invoked from network); 19 Jul 2000 08:28:27 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 08:28:27 -0000 To: ietf-openpgp@imc.org Subject: Re: sig. subpacket & length conflicts? In-Reply-To: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> References: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719172936N.1001@eccosys.com> Date: Wed, 19 Jul 2000 17:29:36 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: sig. subpacket & length conflicts? Date: Wed, 19 Jul 2000 15:38:46 +0800 Message-ID: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> > As stated in 5.2.3.1, signature subpackets can contain lengths up to > 0xFFFFFFFF, however the maximum length as defined for ALL hashable (or > unhashable) subpackets is a maximum of 8383 bytes (as indicated by a two > octet scalar). i took "Two-octet scalar octet count" in section 5.2.3 to mean 0 to 255, as the text says: - Two-octet scalar octet count for following hashed subpacket data. Note that this is the length in octets of all of the hashed subpackets; a pointer incremented by this number will skip over the hashed subpackets. i took the word "scalar" to mean that i should think about section 3.1 (Scalar numbers). also, in section 5.2.3.1, it is explicitly pointed out that the subpacket length is: similar to the "new" format packet header lengths and since 5.2.3 itself didn't mention anything, i didn't think to interpret "two-octet scalar" as similar to the "new" format packet header length. to all: is this interpretation (0 - 255) correct? > So, do we limit the subpacket length to two bytes or redefine that > maximum allowed total length for all subpackets (of type hashable or > unhashable) as 0xFFFFFFFF ( up to 5 bytes)? my guess would be that although you can express length of over 255 (or 8383, whichever is correct) using 2 or 5 octets, that you don't do so in practice in this context. if that interpretation is correct, perhaps a note pointing this out in the text would be helpful for future readers. From owner-ietf-openpgp@mail.imc.org Wed Jul 19 06:03:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10472 for ; Wed, 19 Jul 2000 06:03:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA16656 for ietf-openpgp-bks; Wed, 19 Jul 2000 02:41:59 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA16639 for ; Wed, 19 Jul 2000 02:41:56 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB597080256; Wed, 19 Jul 2000 17:44:09 0800 Message-Id: <4.3.2.7.0.20000719172727.00b3f418@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 17:33:22 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: sig. subpacket & length conflicts? Cc: sen_ml@eccosys.com In-Reply-To: <20000719172936N.1001@eccosys.com> References: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> <4.3.2.7.0.20000719153136.00b34610@mail.comasp.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:29 PM 19/07/2000 +0900, sen_ml@eccosys.com wrote: >i took "Two-octet scalar octet count" in section 5.2.3 to mean 0 to 255, >as the text says: > > - Two-octet scalar octet count for following hashed subpacket > data. Note that this is the length in octets of all of the > hashed subpackets; a pointer incremented by this number will > skip over the hashed subpackets. > >i took the word "scalar" to mean that i should think about section 3.1 >(Scalar numbers). Duh...yes, you are right regarding scalars - I must have been asleep when reading the doc once again. > also, in section 5.2.3.1, it is explicitly pointed >out that the subpacket length is: > > similar to the "new" format packet header lengths > >and since 5.2.3 itself didn't mention anything, i didn't think to >interpret "two-octet scalar" as similar to the "new" format packet >header length. > >to all: is this interpretation (0 - 255) correct? Actually, a two octet scalar is equal to a maximum length of 65535 bytes. > > So, do we limit the subpacket length to two bytes or redefine that > > maximum allowed total length for all subpackets (of type hashable or > > unhashable) as 0xFFFFFFFF ( up to 5 bytes)? > >my guess would be that although you can express length of over 255 (or >8383, whichever is correct) using 2 or 5 octets, that you don't do so >in practice in this context. if that interpretation is correct, >perhaps a note pointing this out in the text would be helpful for >future readers. From reading the archive, it looks like this is known - that the total of the un/hashed subpackets is a maximum of 65535 bytes and that each subpacket can have a max length of 0xFFFFFFFF. I didn't find a final decision on this issue though, however I think I did see mention of a version 5.0 signature solving this "minor" problem. I suppose the practical thing to do is NOT use extremely large subpackets (of which I don't think we will anyway :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Wed Jul 19 06:10:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12592 for ; Wed, 19 Jul 2000 06:10:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17875 for ietf-openpgp-bks; Wed, 19 Jul 2000 02:50:53 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17871 for ; Wed, 19 Jul 2000 02:50:50 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 11579 invoked from network); 19 Jul 2000 09:52:28 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 09:52:28 -0000 To: ietf-openpgp@imc.org Subject: Re: sig. subpacket & length conflicts? In-Reply-To: <4.3.2.7.0.20000719172727.00b3f418@mail.comasp.com> References: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> <20000719172936N.1001@eccosys.com> <4.3.2.7.0.20000719172727.00b3f418@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719185337O.1001@eccosys.com> Date: Wed, 19 Jul 2000 18:53:37 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: Re: sig. subpacket & length conflicts? Date: Wed, 19 Jul 2000 17:33:22 +0800 Message-ID: <4.3.2.7.0.20000719172727.00b3f418@mail.comasp.com> > > also, in section 5.2.3.1, it is explicitly pointed > >out that the subpacket length is: > > > > similar to the "new" format packet header lengths > > > >and since 5.2.3 itself didn't mention anything, i didn't think to > >interpret "two-octet scalar" as similar to the "new" format packet > >header length. > > > >to all: is this interpretation (0 - 255) correct? > > Actually, a two octet scalar is equal to a maximum length of 65535 bytes. ack, duh! silly me. i must have been asleep when writing ;-) thanks for pointing that out. > > > So, do we limit the subpacket length to two bytes or redefine that > > > maximum allowed total length for all subpackets (of type hashable or > > > unhashable) as 0xFFFFFFFF ( up to 5 bytes)? > > > >my guess would be that although you can express length of over 255 (or > >8383, whichever is correct) using 2 or 5 octets, that you don't do so > >in practice in this context. if that interpretation is correct, > >perhaps a note pointing this out in the text would be helpful for > >future readers. > > From reading the archive, it looks like this is known - that the total of > the un/hashed subpackets is a maximum of 65535 bytes and that each > subpacket can have a max length of 0xFFFFFFFF. > > I didn't find a final decision on this issue though, however I think I did > see mention of a version 5.0 signature solving this "minor" problem. I > suppose the practical thing to do is NOT use extremely large subpackets (of > which I don't think we will anyway :) hmmm, so no resolution yet. to all: what's the verdict? From owner-ietf-openpgp@mail.imc.org Wed Jul 19 12:27:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12339 for ; Wed, 19 Jul 2000 12:27:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14566 for ietf-openpgp-bks; Wed, 19 Jul 2000 09:08:59 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14562 for ; Wed, 19 Jul 2000 09:08:58 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA02285; Wed, 19 Jul 2000 09:10:09 -0700 Date: Wed, 19 Jul 2000 09:10:09 -0700 Message-Id: <200007191610.JAA02285@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: sig. subpacket & length conflicts? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > to all: what's the verdict? The "verdict" is that there is a limit of 65535 on the length of each of the hashed and unhashed segments. That's what the spec says, that's what you do. Obviously this implies that each individual subpacket has to be no larger than this. You can express the subpacket length using any of the permitted encoding methods. There is no ambiguity that I can see. The only "issue" was whether we might want to make a new signature version in the future to hold larger subpackets, but the consensus seemed to be that this would be a misuse of signature subpackets; such large amounts of data should not be hidden within sigs, but should be expressed on their own somewhere. Hal From owner-ietf-openpgp@mail.imc.org Wed Jul 19 12:59:25 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26920 for ; Wed, 19 Jul 2000 12:59:24 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA15340 for ietf-openpgp-bks; Wed, 19 Jul 2000 09:34:10 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15336 for ; Wed, 19 Jul 2000 09:34:09 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA02429; Wed, 19 Jul 2000 09:35:18 -0700 Date: Wed, 19 Jul 2000 09:35:18 -0700 Message-Id: <200007191635.JAA02429@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > that is, should the specification say: > > Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message > > or > > Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message The spec is correct; it is the latter. Signature packets have *always* come at the front, since back in PGP 1.0. If you have seen messages that were different (and not one-pass signed messages), you have seen invalid messages. With regard to Erron Criddle's earlier question: > To me, "attached" (as in 2.1 and 2.2) means you add it to the end of > something and this contradicts 10.2 explanation of a Signed Message (a > signed message implies that it is prepended, not attached). Not to me. That word would be "appended". "Attached" is not meant to imply any ordering. 2.1 and 2.2 are meant to give a very rough overview of the steps involved in creating an OpenPGP message, not to be a detailed specification of the process. That is for the rest of the document. > By reading section 10.2, it seems that there are two possibilities for > signing a literal message: > > 1) You create a signature packet then prepend it to the literal packet > > 2) You create a signature packet and a One-Pass Signature Packet then > prepend the One-Pass packet to the literal packet and append the signature > packet to the literal packet. > > Therefore, my final questions are: > > 1) Can you create a simple signature packet and attach it to the end of a > literal packet as stated in 2.1 and 2.2 and subsequently contradict 10.2 > regarding the definition of a signed message and: 2.1 and 2.2 don't say that, and you can't do this. > 2) Why would you need a One-Pass Signature Packet if we conform to 10.2 and > simply prepend a normal signature packet to the literal data with a > subpacket of type 16 (key id), thus removing the need for a One-Pass packet > in the first place? This is so that the signer can process the message in one pass. He doesn't know the hash until he comes to the end of the message, so he can't compute the signature until that time. With the old-style signature packets he would then have to go back to the beginning of the message and put the sig there, preventing one-pass processing. Hal From owner-ietf-openpgp@mail.imc.org Wed Jul 19 18:15:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04879 for ; Wed, 19 Jul 2000 18:15:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23467 for ietf-openpgp-bks; Wed, 19 Jul 2000 14:59:37 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23463 for ; Wed, 19 Jul 2000 14:59:36 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA23391; Wed, 19 Jul 2000 15:02:09 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA23387; Wed, 19 Jul 2000 15:02:08 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000719162830J.1001@eccosys.com> References: <3970A977.D1FA0F2F@woudt.nl> <20000719162830J.1001@eccosys.com> Date: Wed, 19 Jul 2000 14:38:42 -0700 To: sen_ml@eccosys.com, ietf-openpgp@imc.org From: Jon Callas Subject: Re: Signature Subpacket format questions Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:28 PM +0900 7/19/00, sen_ml@eccosys.com wrote: >since there does not appear to be any mention of null-termination in >the section on text (3.4), i interpreted "String" to mean that there >is no null-termination. [ also because many of the field boundaries >can be determined by various lengths that are explicitly spelled out >as well as length definitions. ] > You're correct -- there's no null termination on any of the strings. Jon From owner-ietf-openpgp@mail.imc.org Wed Jul 19 21:12:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05319 for ; Wed, 19 Jul 2000 21:12:50 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA04499 for ietf-openpgp-bks; Wed, 19 Jul 2000 17:55:39 -0700 (PDT) Received: from yahoo.com (216-164-132-57.s311.tnt2.lnhva.md.dialup.rcn.com [216.164.132.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA04429; Wed, 19 Jul 2000 17:55:29 -0700 (PDT) From: Subject: Tuition-Free Computer and IT Training for Non-Profit Employees Date: Wed, 19 Jul 2000 21:01:39 Message-Id: <447.455052.875471@yahoo.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: Tuition-Free Computer and IT Training for Non-Profit Employees Dear Non-Profit Employee, Most non-profit employees want to improve their computer skills. However, high cost of training and a busy schedule have held them back. Now, the National Education Foundation (NEF) CyberLearning, a non-profit organization, dedicated to bridging the "Digital Divide," offers the Nation's non-profit employees a unique opportunity. With the support of Microsoft and others, NEF CyberLearning is now able to offer full tuition scholarships of $2,000 to the first 10,000 applicants, thus enabling them to take any or all of the 400+ Internet-based online personal computing and computer professional courses from anywhere at any time. The high-quality, user-friendly courses are either self-study or instructor-led. They cover all levels and almost all topics, including Computer Basics, Internet Basics, Web Design Basics, Networking Basics, Programming Basics, A+, Network+, MCSE, CNE, Microsoft Office, MOUS, WordPerfect, Lotus, Operating Systems, Windows, Windows 2000, Linux, Unix, Networking, WAN, LAN, Programming, Java, C++, Visual Basics, Internet, Web Design, Web Applications, Web Master, E-commerce, Databases, Oracle and Cisco. To sign up, just visit www.cyberlearning.org, click on "Free IT Training," complete the application and pay a nominal registration fee of $75 with an organization/personal credit card. This $75 is your only cost, since the tuition is free for you. Many non-profit organizations reimburse the $75. You can receive immediate access to all 400+ online courses, an online library of the latest 1,000+ computer/information technology books, instructor assistance, course-specific chat areas and round the clock technical support. Please feel free to forward this information to interested colleagues and others in non-profit organizations. If your department or division wants to sign up a group of employees, please indicate so in your reply and provide contact information. If you received this e-mail, it is because you are listed as a contact person or employee of a non-profit organization. If you do not wish to receive any further scholarship information from us, please reply with the message, "remove" in the Subject line. Thank you. The non-profit National Education Foundation (NEF) CyberLearning has provided tuition-free IT training to thousands of students, teachers, government and non-profit employees and disadvantaged individuals. It has earned many distinctions including "The Ivy League of IT Training," "1995 Fairfax Human Rights Award Winner," and " A Leader in Bridging the Digital Divide." "You are helping to empower America. I salute you for your ongoing commitment to creating a better America," --- President Clinton "This is an awesome opportunity." --- Washingtonjobs.com "Microsoft is pleased to play a part ... NEF can make a positive difference in the lives of a great number of individuals." --- Microsoft "I have found the CyberLearning online courses to be extremely easy and useful. I liked pre-course self-assessment and IT books online and available 24/7. The course screens were interactive and made me feel as if I was in the application itself. The site looks and feels very professional. The list of courses is huge. It includes something for almost everyone. I find this to be a very worthy cause." --- Ken Horowitz, IT Training Coordinator. From owner-ietf-openpgp@mail.imc.org Wed Jul 19 22:08:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA25463 for ; Wed, 19 Jul 2000 22:08:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA13760 for ietf-openpgp-bks; Wed, 19 Jul 2000 18:52:49 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA13751 for ; Wed, 19 Jul 2000 18:52:47 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AEEA5B201E4; Thu, 20 Jul 2000 09:55:06 0800 Message-Id: <4.3.2.7.0.20000720094139.00ae91f0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 09:44:19 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. Cc: hal@finney.org In-Reply-To: <200007191635.JAA02429@finney.org> 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:35 AM 19/07/2000 -0700, hal@finney.org wrote: > > 2) Why would you need a One-Pass Signature Packet if we conform to 10.2 > and simply prepend a normal signature packet to the literal data with a > > subpacket of type 16 (key id), thus removing the need for a One-Pass > packet > > in the first place? > >This is so that the signer can process the message in one pass. >He doesn't know the hash until he comes to the end of the message, >so he can't compute the signature until that time. With the old-style >signature packets he would then have to go back to the beginning of the >message and put the sig there, preventing one-pass processing. Thanks Hal. Also looked at 2.1 and saw I assumed that "attached" meant "appended" - sorry for the wasted bandwidth. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Wed Jul 19 22:10:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26484 for ; Wed, 19 Jul 2000 22:10:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA14272 for ietf-openpgp-bks; Wed, 19 Jul 2000 18:55:06 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA14258 for ; Wed, 19 Jul 2000 18:55:05 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AF7C5B801E4; Thu, 20 Jul 2000 09:57:32 0800 Message-Id: <4.3.2.7.0.20000720094441.00ae91f0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 09:46:45 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: sig. subpacket & length conflicts? Cc: hal@finney.org In-Reply-To: <200007191610.JAA02285@finney.org> 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: Hal, At 09:10 AM 19/07/2000 -0700, hal@finney.org wrote: > > to all: what's the verdict? > >The "verdict" is that there is a limit of 65535 on the length of each >of the hashed and unhashed segments. That's what the spec says, that's >what you do. Obviously this implies that each individual subpacket has >to be no larger than this. You can express the subpacket length using any >of the permitted encoding methods. There is no ambiguity that I can see. > >The only "issue" was whether we might want to make a new signature version >in the future to hold larger subpackets, but the consensus seemed to be >that this would be a misuse of signature subpackets; such large amounts >of data should not be hidden within sigs, but should be expressed on >their own somewhere. Maybe in a version 5 sig., simply make the signature subpacket length definition packet equal to a two octet scalar - this would then marry with the total length of all un/hashed subpackets and would also reduce the amount of processing required to determine the length of a signature subpacket. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Wed Jul 19 22:40:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08008 for ; Wed, 19 Jul 2000 22:40:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA16750 for ietf-openpgp-bks; Wed, 19 Jul 2000 19:23:49 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA16746 for ; Wed, 19 Jul 2000 19:23:47 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 22221 invoked from network); 20 Jul 2000 02:25:25 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jul 2000 02:25:25 -0000 To: ietf-openpgp@imc.org Subject: Re: sig. subpacket & length conflicts? In-Reply-To: <200007191610.JAA02285@finney.org> References: <200007191610.JAA02285@finney.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000720112637A.1001@eccosys.com> Date: Thu, 20 Jul 2000 11:26:37 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 42 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit thanks for the response. From: hal@finney.org Subject: Re: sig. subpacket & length conflicts? Date: Wed, 19 Jul 2000 09:10:09 -0700 Message-ID: <200007191610.JAA02285@finney.org> > > to all: what's the verdict? > > The "verdict" is that there is a limit of 65535 on the length of each > of the hashed and unhashed segments. That's what the spec says, that's > what you do. Obviously this implies that each individual subpacket has > to be no larger than this. You can express the subpacket length using any > of the permitted encoding methods. There is no ambiguity that I can see. from a clarity perspective, i think it would be helpful to make a note in section 5.2.3.1 saying something like: "but note the length restriction imposed by the two octet scalar length specified in section 5.2.3". something like this text could appear directly after the following text: Each subpacket consists of a subpacket header and a body. The header consists of: - the subpacket length (1, 2, or 5 octets) - the subpacket type (1 octet) and is followed by the subpacket specific data. [ since Erron has asked about it, it seems to me that it isn't necessarily obvious in the absolute (if there is such a thing). i agree that it is obvious if you know which details to focus on when you are thinking about the matter. ] > The only "issue" was whether we might want to make a new signature version > in the future to hold larger subpackets, but the consensus seemed to be > that this would be a misuse of signature subpackets; such large amounts > of data should not be hidden within sigs, but should be expressed on > their own somewhere. thanks for the clarification. From owner-ietf-openpgp@mail.imc.org Wed Jul 19 22:45:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09979 for ; Wed, 19 Jul 2000 22:45:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA17215 for ietf-openpgp-bks; Wed, 19 Jul 2000 19:29:56 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA17211 for ; Wed, 19 Jul 2000 19:29:54 -0700 (PDT) From: sen@eccosys.com Received: (qmail 22248 invoked from network); 20 Jul 2000 02:31:33 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jul 2000 02:31:33 -0000 To: ietf-openpgp@imc.org Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. In-Reply-To: <200007191635.JAA02429@finney.org> References: <200007191635.JAA02429@finney.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000720113245M.1001@eccosys.com> Date: Thu, 20 Jul 2000 11:32:45 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. Date: Wed, 19 Jul 2000 09:35:18 -0700 Message-ID: <200007191635.JAA02429@finney.org> > > that is, should the specification say: > > > > Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message > > > > or > > > > Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message > > The spec is correct; it is the latter. Signature packets have *always* > come at the front, since back in PGP 1.0. If you have seen messages > that were different (and not one-pass signed messages), you have seen > invalid messages. i think i must have been looking at a one-pass signed message. yes, it looks like that's what i did. sorry for that, and thanks for the clarification. From owner-ietf-openpgp@mail.imc.org Thu Jul 20 01:00:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA27333 for ; Thu, 20 Jul 2000 01:00:18 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24181 for ietf-openpgp-bks; Wed, 19 Jul 2000 21:18:07 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24174 for ; Wed, 19 Jul 2000 21:18:05 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id VAA04221; Wed, 19 Jul 2000 21:19:04 -0700 Date: Wed, 19 Jul 2000 21:19:04 -0700 Message-Id: <200007200419.VAA04221@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: sig. subpacket & length conflicts? Cc: hal@finney.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron writes: > Maybe in a version 5 sig., simply make the signature subpacket length > definition packet equal to a two octet scalar - this would then marry with > the total length of all un/hashed subpackets and would also reduce the > amount of processing required to determine the length of a signature subpacket. Maybe so. We have had many complaints that the current variable-length packet-length mechanism is somewhat over-engineered for the purpose. Still, almost all subpackets are short enough that one byte is enough for the length, so you do save a few bytes by using the compressed length encoding. Hal From owner-ietf-openpgp@mail.imc.org Thu Jul 20 03:32:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18571 for ; Thu, 20 Jul 2000 03:32:02 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA02070 for ietf-openpgp-bks; Thu, 20 Jul 2000 00:18:34 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA02059 for ; Thu, 20 Jul 2000 00:18:31 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB512D801B8; Thu, 20 Jul 2000 15:21:05 0800 Message-Id: <4.3.2.7.0.20000720141703.00b24500@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 15:10:14 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: dash escaped text and cleartext sig. q 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: To all, Just to clarify: If a cleartext signed message is sent to a recipient and the message body originally contained a "-" at the start of a line, would the recipient receive that same line prepended with a "- "? I am asking this because I have just received a message that has been cleartext signed using GnuPG 1.0.1, however there are whole lines of "-" in them and they are not received as "- -------------------..."??? Does anyone know what is going on here or, once again, have I missed something? TIA. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Thu Jul 20 13:19:44 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07646 for ; Thu, 20 Jul 2000 13:19:43 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03459 for ietf-openpgp-bks; Thu, 20 Jul 2000 10:03:39 -0700 (PDT) Received: from fs3.freedom.net (fs3.freedom.net [209.5.124.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03455 for ; Thu, 20 Jul 2000 10:03:38 -0700 (PDT) From: kryptobunny@freedom.net Received: (from freedom@localhost) by fs3.freedom.net (8.9.2/8.9.2) id NAA14948 for ietf-openpgp@imc.org; Thu, 20 Jul 2000 13:06:15 -0400 (EDT) Message-Id: <200007201706.NAA14948@fs3.freedom.net> Comments: This message was processed by the Freedom Mail Gateway X-ZKS-Freedom-Hdr-Sig: AQGDdthjQcbiLoVCBULujs57t30dEPeKR0acWZw0jSRx9+y7P8KosB0E X-ZKS-Freedom-Auth-Date: Thu, 20 Jul 2000 13:05:33 -0400 X-ZKS-Freedom-Auth-Cc: coderpunks@toad.com X-ZKS-Freedom-Auth-To: ietf-openpgp@imc.org X-ZKS-Freedom-Auth-From: kryptobunny@freedom.net Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset = "us-ascii" Subject: Y2K is over CC: coderpunks@toad.com To: ietf-openpgp@imc.org MIME-Version: 1.0 Date: Thu, 20 Jul 2000 13:05:33 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > Hal wrote on the ietf-openpgp@imc.org list: > > ... We have had many complaints that the current variable-length > packet-length mechanism is somewhat over-engineered for the purpose. > Still, almost all subpackets are short enough that one byte is enough > for the length, so you do save a few bytes by using the compressed > length encoding. Benefits from saving a few bytes in PGP sigs: PGP users 4 M (original business plan claim) bytes saved per sig 3 sigs per user 100 --- total bytes saved 1.2 G Costs of saving a few bytes in PGP sigs: Cost of coding weird length field 1 Maintenance factor of complex code 5 Independant implementations 10 -- total hours spent 50 balance sheet value of 1.6 G bytes ($200 IBM 20Gb drive, y2k) $12 value of 50 hours programming ($100 per hour, y2k) $5000 net gain (loss) to society from the Zimm Buddism ("every byte is sacred"): ($4988) The 2nd millenium is over. Save programmers, not bytes. kryptoBunny From owner-ietf-openpgp@mail.imc.org Thu Jul 20 14:45:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22387 for ; Thu, 20 Jul 2000 14:45:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05330 for ietf-openpgp-bks; Thu, 20 Jul 2000 11:21:27 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05326 for ; Thu, 20 Jul 2000 11:21:26 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA01530; Thu, 20 Jul 2000 11:22:37 -0700 Date: Thu, 20 Jul 2000 11:22:37 -0700 Message-Id: <200007201822.LAA01530@finney.org> To: ietf-openpgp@imc.org, kryptobunny@freedom.net Subject: Re: Y2K is over Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive, y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k) $5000 > > net gain (loss) to society > from the Zimm Buddism > ("every byte is sacred"): ($4988) > > The 2nd millenium is over. Save programmers, not bytes. This is a misleading comparsion. There are circumstances where bytes can be extremely costly, such as in the new wave of wireless devices, smart cards, and other forms of portable electronics where every byte counts, both for storage and for transmission. Not all uses of signatures will have access to a 20 GB hard drive and megabit data transmission rates. Furthermore, although any given optimization may save only a few bytes, the net result of multiple such choices based on a philosophy of space savings can add up to a substantial percentage reduction. This is especially true when contrasted with the philosophy that space doesn't matter any more. The end result of that philosophical approach would be something like XML, with ascii rendering of data and verbose tags to identify each field. PGP's signatures are probably 1/3 the size you'd get if you used straightforward XML to represent the data. So, yes, the second millennium is over, but no, there are still situations where saving bytes makes sense. Having said that, you can still look at the various optimizations in the OpenPGP spec to see which give you the most space-saving bang for the programmer-effort buck. Obviously using untagged binary data is the biggest win. Beyond that, some of the optimizations, like the string-to-key iteration count, are probably a lot more effort than they are worth, since they're not used much. Hal From owner-ietf-openpgp@mail.imc.org Thu Jul 20 14:58:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28926 for ; Thu, 20 Jul 2000 14:58:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05950 for ietf-openpgp-bks; Thu, 20 Jul 2000 11:38:47 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05946 for ; Thu, 20 Jul 2000 11:38:46 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id LAA04600; Thu, 20 Jul 2000 11:41:23 -0700 (PDT) Received: from [63.73.97.181] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id LAA04596; Thu, 20 Jul 2000 11:41:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200007201706.NAA14948@fs3.freedom.net> References: <200007201706.NAA14948@fs3.freedom.net> Date: Thu, 20 Jul 2000 11:38:05 -0700 To: kryptobunny@freedom.net, ietf-openpgp@imc.org From: Jon Callas Subject: Re: Y2K is over Cc: coderpunks@toad.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The byte savings you put assumes that you have a disk with a 1 byte block size. Typically, block sizes on disks are larger. Suppose you have a disk with an 8K block size. Changing a file from 3000 bytes to 2999 bytes saves nothing. You only really save space if the file that contains a structure changes the block count of the file. There's another effect, too. And that is the code size. Saving 1 byte of data at the cost of 200 bytes of code is probably not cost effective because memory is more expensive than disk, and a large code size may preclude using small devices, like pagers, iButtons, etc. Data is transient, code is resident. So yeah, what you said. Saving a byte isn't worth it. If it were up to me, I would deprecate anything but the 5-byte lengths. Small devices are better served by only using 5-byte lengths. Jon From owner-ietf-openpgp@mail.imc.org Thu Jul 20 20:42:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06651 for ; Thu, 20 Jul 2000 20:42:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA14325 for ietf-openpgp-bks; Thu, 20 Jul 2000 17:22:33 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14321 for ; Thu, 20 Jul 2000 17:22:31 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id UAA24121; Thu, 20 Jul 2000 20:25:08 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id UAA07758; Thu, 20 Jul 2000 20:25:11 -0400 Date: Thu, 20 Jul 2000 20:25:10 -0400 From: Tom Zerucha To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: The price of the one v.s. the price of the many Message-ID: <20000720202510.B7749@deimos.mw.mediaone.net> References: <200007201822.LAA01530@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007201822.LAA01530@finney.org>; from hal@finney.org on Thu, Jul 20, 2000 at 11:22:37AM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jul 20, 2000 at 11:22:37AM -0700, hal@finney.org wrote: > > balance sheet > > > > value of 1.6 G bytes > > ($200 IBM 20Gb drive, y2k) $12 > > > > value of 50 hours programming > > ($100 per hour, y2k) $5000 > > > > net gain (loss) to society > > from the Zimm Buddism > > ("every byte is sacred"): ($4988) > > > > The 2nd millenium is over. Save programmers, not bytes. > > This is a misleading comparsion. There are circumstances where bytes can > be extremely costly, such as in the new wave of wireless devices, smart You miss the biggest point. Value of 50 hours programming - $5000. value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE. Assuming it will be installed on more than 416 drives it is cheaper to pay a programmer to shrink the application. You may have noticed this if you had to upgrade CPU, Memory, or Disk when going from Windows 3.1 to Windows 2000. (and if you use a Palm Pilot's ram as an example the cost goes way up) From owner-ietf-openpgp@mail.imc.org Fri Jul 21 00:03:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18629 for ; Fri, 21 Jul 2000 00:03:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA01524 for ietf-openpgp-bks; Thu, 20 Jul 2000 20:46:00 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA01520 for ; Thu, 20 Jul 2000 20:45:57 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AAF88ED018E; Fri, 21 Jul 2000 11:48:24 0800 Message-Id: <4.3.2.7.0.20000721113303.00b2efa0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 11:37:32 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Correction reqd. in 5.5.2 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: To all, You may have already noticed, but in 5.5.2 the MPI values for y (for DSA and ElGamal) have been stated as: MPI of ... public key value y (=g**x where x is secret) This should read: MPI of ... public key value y (=g**x mod p where x is secret) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jul 21 00:30:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28176 for ; Fri, 21 Jul 2000 00:30:26 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02916 for ietf-openpgp-bks; Thu, 20 Jul 2000 21:10:26 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA02912 for ; Thu, 20 Jul 2000 21:10:24 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A0BE909022C; Fri, 21 Jul 2000 12:13:02 0800 Message-Id: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:02:10 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Correction reqd. in 5.2 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: To all, Another one (trivial but may confuse newcomers): section 5.2 starts off with: "A signature packet describes a binding between some public key and some data." should read: "A signature packet describes a binding between a private key and some data." Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jul 21 00:46:35 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04898 for ; Fri, 21 Jul 2000 00:46:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA03290 for ietf-openpgp-bks; Thu, 20 Jul 2000 21:31:29 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA03283 for ; Thu, 20 Jul 2000 21:31:26 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5AD4520182; Fri, 21 Jul 2000 12:34:05 0800 Message-Id: <4.3.2.7.0.20000721121106.00ae5330@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:23:13 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Recommended 5.3 wording change 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: To all, The paragraph in section 5.3 (the one following the definition of the packet body) reads as follows: "The data being signed is hashed, and then the signature data from the version number through the hashed sub-packet data (inclusive) is hashed. The..." From my previous e-mails regarding signatures, it seems it should read something like: "To produce a signature, the data to be signed has the signature data from the version number through to the hashed sub-packet data (inclusive) appended to it. This data is then hashed and the resulting hash value is signed. The..." Is that right? Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jul 21 01:22:27 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA23298 for ; Fri, 21 Jul 2000 01:22:27 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05177 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:05:43 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05173 for ; Thu, 20 Jul 2000 22:05:40 -0700 (PDT) Received: from [63.73.97.181] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1d11); Thu, 20 Jul 2000 22:08:13 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> References: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> Date: Thu, 20 Jul 2000 21:52:45 -0700 To: Erron Criddle , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Correction reqd. in 5.2 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Correction reqd. in 5.2", shown on 7/21/00), Erron Criddle said: >To all, > >Another one (trivial but may confuse newcomers): > >section 5.2 starts off with: > >"A signature packet describes a binding between some public key and some >data." > >should read: > >"A signature packet describes a binding between a private key and some data." > I disagree. A signature binds the public key and the data. Signature verification is done with the public key only, and that is the whole point of the exercise. Jon From owner-ietf-openpgp@mail.imc.org Fri Jul 21 01:23:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA24230 for ; Fri, 21 Jul 2000 01:23:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05205 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:06:06 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05199 for ; Thu, 20 Jul 2000 22:06:04 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ADBE7D00216; Fri, 21 Jul 2000 13:08:30 0800 Message-Id: <4.3.2.7.0.20000721125459.00b1b6d0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:57:38 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: Correction reqd. in 5.2 Cc: sen_ml@eccosys.com In-Reply-To: <20000721135101X.1001@eccosys.com> References: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.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 01:51 PM 21/07/2000 +0900, sen_ml@eccosys.com wrote: >hi- > >From: Erron Criddle >Subject: Correction reqd. in 5.2 >Date: Fri, 21 Jul 2000 12:02:10 +0800 >Message-ID: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> > > > Another one (trivial but may confuse newcomers): > > > > section 5.2 starts off with: > > > > "A signature packet describes a binding between some public key and > some data." > > > > should read: > > > > "A signature packet describes a binding between a private key and some > data." > >isn't the binding really between "the keypair" and "some data"? I believe that would be a better description. It could read: "A signature packet describes a binding between a public key pair and some data." or thereabouts :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jul 21 01:34:30 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01852 for ; Fri, 21 Jul 2000 01:34:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05484 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:13:44 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05480 for ; Thu, 20 Jul 2000 22:13:43 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA02718; Thu, 20 Jul 2000 22:14:51 -0700 Date: Thu, 20 Jul 2000 22:14:51 -0700 Message-Id: <200007210514.WAA02718@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: Correction reqd. in 5.2 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron writes: > section 5.2 starts off with: > > "A signature packet describes a binding between some public key and some data." > > should read: > > "A signature packet describes a binding between a private key and some data." I don't agree. It is equally as valid to consider a signature as being bound to the verification public key as to the signing private key. Hal From owner-ietf-openpgp@mail.imc.org Fri Jul 21 01:39:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05380 for ; Fri, 21 Jul 2000 01:39:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05722 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:10 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05717 for ; Thu, 20 Jul 2000 22:22:08 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 10756 invoked from network); 21 Jul 2000 05:23:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 21 Jul 2000 05:23:45 -0000 To: ietf-openpgp@imc.org Subject: Re: Recommended 5.3 wording change In-Reply-To: <4.3.2.7.0.20000721121106.00ae5330@mail.comasp.com> References: <4.3.2.7.0.20000721121106.00ae5330@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000721142500W.1001@eccosys.com> Date: Fri, 21 Jul 2000 14:25:00 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: Recommended 5.3 wording change Date: Fri, 21 Jul 2000 12:23:13 +0800 Message-ID: <4.3.2.7.0.20000721121106.00ae5330@mail.comasp.com> > The paragraph in section 5.3 (the one following the definition of the > packet body) reads as follows: > > "The data being signed is hashed, and then the signature data from the > version number through the hashed sub-packet data (inclusive) is hashed. > The..." > > From my previous e-mails regarding signatures, it seems it should read > something like: > > "To produce a signature, the data to be signed has the signature data from > the version number through to the hashed sub-packet data (inclusive) > appended to it. This data is then hashed and the resulting hash value is > signed. The..." i think this phrasing is easier to understand. [ the original phrasing sounds to me like describing a particular implementation. ] > Is that right? it agrees w/ my understanding. From owner-ietf-openpgp@mail.imc.org Fri Jul 21 01:39:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05549 for ; Fri, 21 Jul 2000 01:39:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05715 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:07 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05709 for ; Thu, 20 Jul 2000 22:22:06 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA02739; Thu, 20 Jul 2000 22:23:16 -0700 Date: Thu, 20 Jul 2000 22:23:16 -0700 Message-Id: <200007210523.WAA02739@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: Recommended 5.3 wording change Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The paragraph in section 5.3 (the one following the definition of the > packet body) reads as follows: > > "The data being signed is hashed, and then the signature data from the > version number through the hashed sub-packet data (inclusive) is hashed. > The..." > > From my previous e-mails regarding signatures, it seems it should read > something like: > > "To produce a signature, the data to be signed has the signature data from > the version number through to the hashed sub-packet data (inclusive) > appended to it. This data is then hashed and the resulting hash value is > signed. The..." > > Is that right? This is from 5.2.2 in the RFC. Neither description is all that great, IMO. "First this data is hashed, then that data is hashed" may not make it clear that all the data is feeding into one hash context. And the language about appending to the data may be taken literally by a naive implementer who thinks he has to construct a buffer holding this data all appended together nicely before feeding it to the hash function. Furthermore the corresponding language in 5.2.3, which describes what is hashed for V4 signature packets, is missing the description of the five byte postscript, which is wrong. I think it would be best in each case simply to refer to section 5.2.4, Computing Signatures, which gives a more complete description of exactly what is hashed. You might want to look there and see if the language is unclear. Hal From owner-ietf-openpgp@mail.imc.org Fri Jul 21 01:39:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05636 for ; Fri, 21 Jul 2000 01:39:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05755 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:58 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05751 for ; Thu, 20 Jul 2000 22:22:56 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A1B146E0182; Fri, 21 Jul 2000 13:25:21 0800 Message-Id: <4.3.2.7.0.20000721131005.00b39ee0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 13:14:29 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: Correction reqd. in 5.2 Cc: jon@callas.org In-Reply-To: References: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.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:52 PM 20/07/2000 -0700, Jon Callas wrote: >I disagree. A signature binds the public key and the data. Isn't the private key used as well to create the sig? > Signature verification is done with the public key only, and that is the > whole point >of the exercise. > > Jon Agreed. It should read key pair as the signature is bound to both the private and public keys. Anyhow, you decide - I understood it, however someone else *may* get confused. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jul 21 03:58:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00697 for ; Fri, 21 Jul 2000 03:58:44 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA10893 for ietf-openpgp-bks; Fri, 21 Jul 2000 00:32:42 -0700 (PDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA10889 for ; Fri, 21 Jul 2000 00:32:39 -0700 (PDT) Received: from [199.174.205.25] (user-33qtj8p.dialup.mindspring.com [199.174.205.25]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id DAA31968; Fri, 21 Jul 2000 03:35:07 -0400 (EDT) Message-Id: In-Reply-To: References: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jul 2000 00:33:04 -0700 To: Jon Callas , Erron Criddle , ietf-openpgp@imc.org From: Bill Frantz Subject: Re: Correction reqd. in 5.2 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:52 PM -0700 7/20/00, Jon Callas wrote: >In our last episode ("Correction reqd. in 5.2", shown on 7/21/00), Erron >Criddle said: > >>To all, >> >>Another one (trivial but may confuse newcomers): >> >>section 5.2 starts off with: >> >>"A signature packet describes a binding between some public key and some >>data." >> >>should read: >> >>"A signature packet describes a binding between a private key and some data." >> > >I disagree. A signature binds the public key and the data. Signature >verification is done with the public key only, and that is the whole point >of the exercise. > > Jon Well, really there are two bindings. The signature binds the public key and the data. The public key and the private key are bound by their mathematical relationship. However, the real binding people are usually interested in is the binding between the holder of the private key and the data. The two bindings let us get between the private key and the data, but the next step is still only conjecture. ------------------------------------------------------------------------- Bill Frantz | Microsoft Outlook, the | Periwinkle -- Consulting (408)356-8506 | hacker's path to your | 16345 Englewood Ave. frantz@netcom.com | hard disk. | Los Gatos, CA 95032, USA From owner-ietf-openpgp@mail.imc.org Fri Jul 21 05:21:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18993 for ; Fri, 21 Jul 2000 05:21:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA13867 for ietf-openpgp-bks; Fri, 21 Jul 2000 01:53:27 -0700 (PDT) Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13856 for ; Fri, 21 Jul 2000 01:53:21 -0700 (PDT) From: wolfgang@redtenbacher.de Received: from [195.20.224.208] (helo=mrvdom01.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 13FYbA-0003Bn-00 for ietf-openpgp@imc.org; Fri, 21 Jul 2000 10:56:00 +0200 Received: from fra-pci-lai-vty57.as.wcom.net ([212.211.70.57]) by mrvdom01.kundenserver.de with smtp (Exim 2.12 #2) id 13FYav-0008LD-00 for ietf-openpgp@imc.org; Fri, 21 Jul 2000 10:55:46 +0200 Subject: Re: Y2K is over Message-Id: Date: Fri, 21 Jul 2000 10:55:46 +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive, y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k) $5000 > > net gain (loss) to society > from the Zimm Buddism > ("every byte is sacred"): ($4988) > > The 2nd millenium is over. Save programmers, not bytes. I would rather say: "Save user ressources, and then save hardware and program maintainance ressources". The attitude "Size is no longer important as RAM and disks are so cheap!" is the reason behind Reiser's "law": "The speed increase of hardware is slower than the speed loss of software." ("Die Hardware wird langsamer schneller als die Software langsamer.") Experience shows that programmers who stop to worry about the ressources their programs eat up, have a tendency to more bugs and poorer code design than the "good old byte savers". So don't throw out the ideals of good programming just because in certain areas the hardware prices have gone down. Let us face it: First time creation of new programs is _not_ any real bottleneck. Evolution of programs to improve their quality and usability, however, _is_ a bottleneck. And outside the wonderful world of universities and research labs, hardware ressources _always_ show up as bottlenecks earlier or later, too. Therefore, don't overdo "byte saving" at the cost of poor program maintainability. But if byte saving can be achieved by a simple sub-routine that is coded once and can be ignored throughout the remainder of a program's life time (as in the case of PGP packet lengths), then, for God's sake, save those bytes! - Wolfgang Redtenbacher Chairman DIN NI-22.13 "Programming languages, M2" D/Chairman DIN NI-Erg/UA5 "Software ergonomics" (DIN = German Standards Institute) From owner-ietf-openpgp@mail.imc.org Fri Jul 21 10:32:23 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15538 for ; Fri, 21 Jul 2000 10:32:23 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA29841 for ietf-openpgp-bks; Fri, 21 Jul 2000 07:11:56 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29837 for ; Fri, 21 Jul 2000 07:11:54 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyuq15570; Fri, 21 Jul 2000 14:14:34 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26321; Fri, 21 Jul 00 10:10:39 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA09110; Fri, 21 Jul 2000 10:14:33 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14712.23240.923710.211525@xedia.com> Date: Fri, 21 Jul 2000 10:14:32 -0400 (EDT) To: tz@execpc.com Cc: hal@finney.org, ietf-openpgp@imc.org Subject: Re: The price of the one v.s. the price of the many References: <200007201822.LAA01530@finney.org> <20000720202510.B7749@deimos.mw.mediaone.net> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>>>> "Tom" == Tom Zerucha writes: Tom> On Thu, Jul 20, 2000 at 11:22:37AM -0700, hal@finney.org wrote: >> > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive, >> y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k) >> $5000 > > net gain (loss) to society > from the Zimm Buddism > >> ("every byte is sacred"): ($4988) > > The 2nd millenium is over. >> Save programmers, not bytes. >> >> This is a misleading comparsion. There are circumstances where >> bytes can be extremely costly, such as in the new wave of wireless >> devices, smart Tom> You miss the biggest point. Tom> Value of 50 hours programming - $5000. Tom> value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE. Um, no. Right now drives are about $10 per GB. So 0.6 MB cost less than a penny. It takes nearly a million drives to break even. Not only that, but the cost of extra programming is not just time spent, but also quality reduced, which can be a lot more expensive. In fact, if it introduces just one more bug that causes 1% of the users $1 worth of extra hassle, you've already paid for the extra bits. paul From owner-ietf-openpgp@mail.imc.org Fri Jul 21 11:50:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07917 for ; Fri, 21 Jul 2000 11:50:57 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA04743 for ietf-openpgp-bks; Fri, 21 Jul 2000 08:29:55 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04733 for ; Fri, 21 Jul 2000 08:29:53 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA24797; Fri, 21 Jul 2000 11:32:33 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id LAA10943; Fri, 21 Jul 2000 11:32:28 -0400 Date: Fri, 21 Jul 2000 11:32:28 -0400 From: Tom Zerucha To: Paul Koning Cc: tz@execpc.com, hal@finney.org, ietf-openpgp@imc.org Subject: Re: The price of the one v.s. the price of the many Message-ID: <20000721113228.A10940@deimos.mw.mediaone.net> References: <200007201822.LAA01530@finney.org> <20000720202510.B7749@deimos.mw.mediaone.net> <14712.23240.923710.211525@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <14712.23240.923710.211525@xedia.com>; from pkoning@xedia.com on Fri, Jul 21, 2000 at 10:14:32AM -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is getting a little off topic, but I think OpenPGP has a programming philosophy of elegance and simplicity, so it isn't too far off. So I apologize in advance but will still respond ;). On Fri, Jul 21, 2000 at 10:14:32AM -0400, Paul Koning wrote: > >>>>> "Tom" == Tom Zerucha writes: > > Tom> On Thu, Jul 20, 2000 at 11:22:37AM -0700, hal@finney.org wrote: > >> > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive, > >> y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k) > >> $5000 > > net gain (loss) to society > from the Zimm Buddism > > >> ("every byte is sacred"): ($4988) > > The 2nd millenium is over. > >> Save programmers, not bytes. > >> > >> This is a misleading comparsion. There are circumstances where > >> bytes can be extremely costly, such as in the new wave of wireless > >> devices, smart > > Tom> You miss the biggest point. > > Tom> Value of 50 hours programming - $5000. > > Tom> value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE. > > Um, no. > > Right now drives are about $10 per GB. So 0.6 MB cost less than a > penny. It takes nearly a million drives to break even. And it drops each year. Just wait and we will all have 10GHz processors with a terabyte drive connected by high speed optical... The cost of Palm RAM is around $4000/GB. And it doesn't have a hard drive port. The cost of extra kilopackets on the VII if you don't have unlimited is quite high. If you want to embed something in 1M devices, the difference between a $15 and a $20 chip will pay for a lot of engineering time. In one sense your argument says that the US cars of the late '60s and early '70s were optimal because steel and fuel were cheap and getting cheaper, so 4-5K pounds wasn't a problem and maybe an asset in an accident. > Not only that, but the cost of extra programming is not just time > spent, but also quality reduced, which can be a lot more expensive. This assumes it reduces quality. Normally collapsing a complex (and big) interface into something which is both smaller and simpler increases quality. In my experience, the number of bugs is inversely proportional to the complexity of the system, and simple systems don't produce a lot of extra bytes. In the original context, I think the argument was "We could add this feature although it will take extra memory". Arguing your point, we shouldn't add such extra features because the cost won't simply be the extra memory, but the programmer, tester, and fixup time due to bugs or other incompatibilities said feature would introduce. Also, such things tax other programmers who want to interface with the software. That extra byte might cause hundreds of other programmers hours of grief. > In fact, if it introduces just one more bug that causes 1% of the > users $1 worth of extra hassle, you've already paid for the extra > bits. There is a point of diminishing returns, but I know of very little software that isn't 60% extra junk and gratuitous changes when new versions come out with all the problems you note - and I am not even talking about actual bugs. Bloat is something that is anti-quality - more interfaces, more code, more structures, more bytes that can be misinterpreted. Most of this applies to W32, less so for Mac, far less for Unicies where you get complaints about being too simplistic to be usable. The desire to reduce memory requirements is an indirect way to prevent bloat, and as such is probably inefficient or even wrong in some cases. From owner-ietf-openpgp@mail.imc.org Sun Jul 23 08:57:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19056 for ; Sun, 23 Jul 2000 08:57:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA20267 for ietf-openpgp-bks; Sun, 23 Jul 2000 05:30:19 -0700 (PDT) Received: from mailserver1.hrz.tu-darmstadt.de (root@mailserver1.hrz.tu-darmstadt.de [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20263 for ; Sun, 23 Jul 2000 05:30:17 -0700 (PDT) Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id OAA21608; Sun, 23 Jul 2000 14:30:45 +0200 (MET DST) Received: from ppp310.stud.tu-darmstadt.de (ppp310.stud.tu-darmstadt.de [130.83.176.61]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id OAA12538; Sun, 23 Jul 2000 14:32:35 +0200 (MET DST) Received: id ; Sun, 23 Jul 2000 14:44:17 +0200 (CEST) Message-Id: Date: Sun, 23 Jul 2000 14:44:17 +0200 (CEST) From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: ietf-openpgp@imc.org, Jon Callas , kryptobunny@freedom.net, coderpunks@toad.com Subject: Re: Y2K is over In-Reply-To: References: <200007201706.NAA14948@fs3.freedom.net> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas : > kryptobunny@freedom.net: >> Benefits from saving a few bytes in PGP sigs: >> >> PGP users 4 M >> (original business plan claim) >> bytes saved per sig 3 >> sigs per user 100 >> --- >> total bytes saved 1.2 G > The byte savings you put assumes that you have a disk with a 1 byte block > size. Typically, block sizes on disks are larger. Suppose you have a disk > with an 8K block size. Changing a file from 3000 bytes to 2999 bytes saves > nothing. You only really save space if the file that contains a structure > changes the block count of the file. But in this case you save 8K bytes at once. If the file size modulo the block size is roughly uniformly distributed, then you have expected savings of one actual byte of disk space for each byte of file size. (Actually it's the fragment size, not the block size, that counts. Since 4.3 BSD, file sytems don't waste a complete block for the final bytes of a file. Instead a block can be shared for the final fragments of multiple files. This is more likely to be 1K than 8K, so even if you usually have rather short messages you will often use more than one fragment.) Also there can be multiple signatures in the same file (mbox for example). And some folks even back up their disks (often using compression so that block sizes are not an issue). Tapes are cheaper per GB than hard disks, but there'll usually be multiple copies of the same files. From owner-ietf-openpgp@mail.imc.org Mon Jul 24 00:08:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17251 for ; Mon, 24 Jul 2000 00:08:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19195 for ietf-openpgp-bks; Sun, 23 Jul 2000 20:14:01 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA19163 for ; Sun, 23 Jul 2000 20:13:57 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A8144050070; Mon, 24 Jul 2000 11:16:52 PDT Message-Id: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 11:05:50 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: final q re sigs. 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: To all, One final clarifying question re 2440: After looking at 5.2.3 and 5.2.4 regarding "what" is hashed and "how" it is hashed before being fed into the DSA, I'm still slightly confused. -----BEGIN QUOTES----- 5.2.3 states: "The data being signed is hashed, and then the signature data from the version number through the hashed subpacket data (inclusive) is hashed." 5.2.4 states: "Once the data body is hashed, then a trailer is hashed. . A version 4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data." "V4 signatures also hash in a final trailer of six octets:..." "After all this has been hashed , the resulting hash field is used in the signature algorithm,..." -----END QUOTES----- Let's assume: (a) = actual data, (b) = signature data to be hashed (incl. subpackets), (c) = last six octets My question is, for a version 4 sig using DSA and SHA1, do we: 1) H(a) + H(b) + H(c) = 480 bit value, then hash this to produce the final hash value (before sig. alg.) 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. 3) i) Initialise the SHA1 hashing alg. with the values A=0x67452301, B=0xEFCDAB89, C=0x98BADCFE, D=0x10325476, E=0xC3D2E1F0 ii) Hash (a) then split the 160 bit result into 5x 32 bit values, representing the next five 32 bit initialization numbers (A,B, C, D, E) for the hashing algorithm. iii) Hash (b) then split the 160 bit result into 5x 32 bit values, representing the next five 32 bit initialization numbers (A,B, C, D, E) for the hashing algorithm. iv) Hash (c) then use the 160 bit result in the signature algorithm (DSA). Thanks for any replies as I am reading these three possibilities from the doc and I'm not sure which one to use. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Mon Jul 24 01:20:14 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04566 for ; Mon, 24 Jul 2000 01:20:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21225 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:04:07 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21218 for ; Sun, 23 Jul 2000 22:04:02 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 22056 invoked from network); 24 Jul 2000 05:05:46 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Jul 2000 05:05:46 -0000 In-Reply-To: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> References: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> Subject: Re: final q re sigs. To: ietf-openpgp@imc.org X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000724140708H.1001@eccosys.com> Date: Mon, 24 Jul 2000 14:07:08 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 42 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: Erron Criddle Subject: final q re sigs. Date: Mon, 24 Jul 2000 11:05:50 +0800 Message-ID: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> ... > Let's assume: (a) = actual data, (b) = signature data to be hashed (incl. > subpackets), (c) = last six octets > > My question is, for a version 4 sig using DSA and SHA1, do we: > > 1) H(a) + H(b) + H(c) = 480 bit value, then hash this to produce the final > hash value (before sig. alg.) i don't think it is this. as Hal mentioned in an earlier post, a "more complete description of exactly what is hashed" is given in section 5.2.4. you'll note that in his post, he suggested that other sections might refer to section 5.2.4. that seems like a good idea to me. > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. i think it's closest to this. my interpretation is: H(actual data + version + signature type + pubkey algo + hash algo + hashed subpacket length + hashed subpackets + 0x04 + 0xff + length of hashed data from sig packet) or H(actual data + fields of sig packet from version through hashed subpackets + trailer of six octets a la section 5.2.4) perhaps someone else can confirm ;-) note that your definition of (b) says "incl. subpackets", but actually, you don't include unhashed subpackets...but you probably meant that anyway, right? From owner-ietf-openpgp@mail.imc.org Mon Jul 24 01:55:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22918 for ; Mon, 24 Jul 2000 01:55:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21991 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:39:43 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21986 for ; Sun, 23 Jul 2000 22:39:40 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA3E1B701E8; Mon, 24 Jul 2000 13:42:38 0800 Message-Id: <4.3.2.7.0.20000724132919.00b75ca8@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 13:31:21 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: final q re sigs. Cc: sen_ml@eccosys.com In-Reply-To: <20000724140708H.1001@eccosys.com> References: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.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 02:07 PM 24/07/2000 +0900, sen_ml@eccosys.com wrote: > > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. > >i think it's closest to this. I also thought this, however I needed confirmation...can anyone else confirm? > my interpretation is: > >H(actual data + > version + signature type + pubkey algo + hash algo + > hashed subpacket length + hashed subpackets + > 0x04 + 0xff + length of hashed data from sig packet) > >or > >H(actual data + > fields of sig packet from version through hashed subpackets + > trailer of six octets a la section 5.2.4) > >perhaps someone else can confirm ;-) > >note that your definition of (b) says "incl. subpackets", but >actually, you don't include unhashed subpackets...but you probably >meant that anyway, right? Yes :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Mon Jul 24 02:05:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03160 for ; Mon, 24 Jul 2000 02:05:12 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22215 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:49:27 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22210 for ; Sun, 23 Jul 2000 22:49:25 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA09707; Sun, 23 Jul 2000 22:50:44 -0700 Date: Sun, 23 Jul 2000 22:50:44 -0700 Message-Id: <200007240550.WAA09707@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: final q re sigs. Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > My question is, for a version 4 sig using DSA and SHA1, do we: > > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. It is this one, where the "+" means concatenation. Most implementations of hash functions do not require you to literally concatenate the data, but rather you can pass the data in pieces, so you first pass in a, then b, then c. In the spec we write this as "first hash a, then hash b, then hash c," and so on. Hal From owner-ietf-openpgp@mail.imc.org Mon Jul 24 02:15:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07800 for ; Mon, 24 Jul 2000 02:15:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22427 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:58:41 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA22423 for ; Sun, 23 Jul 2000 22:58:39 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 23268 invoked from network); 24 Jul 2000 06:00:26 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Jul 2000 06:00:26 -0000 To: ietf-openpgp@imc.org Subject: Re: Recommended 5.3 wording change In-Reply-To: <200007210523.WAA02739@finney.org> References: <200007210523.WAA02739@finney.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000724150149L.1001@eccosys.com> Date: Mon, 24 Jul 2000 15:01:49 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit From: hal@finney.org Subject: Re: Recommended 5.3 wording change Date: Thu, 20 Jul 2000 22:23:16 -0700 Message-ID: <200007210523.WAA02739@finney.org> ... > Furthermore the corresponding language in 5.2.3, which describes what is > hashed for V4 signature packets, is missing the description of the five > byte postscript, which is wrong. > > I think it would be best in each case simply to refer to section 5.2.4, > Computing Signatures, which gives a more complete description of exactly > what is hashed. You might want to look there and see if the language > is unclear. i think these are good points. section 5.2.4 reads much more clearly to me than the earlier sections. i think adding appropriate references to section 5.2.4 in relevant locations would be a good improvement. From owner-ietf-openpgp@mail.imc.org Mon Jul 24 02:15:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08018 for ; Mon, 24 Jul 2000 02:15:36 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22384 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:57:11 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA22379 for ; Sun, 23 Jul 2000 22:57:09 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AE5E31801E8; Mon, 24 Jul 2000 14:00:14 0800 Message-Id: <4.3.2.7.0.20000724134705.00b2f6a8@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 13:48:57 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: final q re sigs. Cc: hal@finney.org In-Reply-To: <200007240550.WAA09707@finney.org> 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: Hal, At 10:50 PM 23/07/2000 -0700, hal@finney.org wrote: > > My question is, for a version 4 sig using DSA and SHA1, do we: > > > > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. > >It is this one, where the "+" means concatenation. Most implementations >of hash functions do not require you to literally concatenate the data, >but rather you can pass the data in pieces, so you first pass in a, then >b, then c. In the spec we write this as "first hash a, then hash b, then >hash c," and so on. Aahhh...this is where I was getting confused (re the *then* words) Thanks :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Tue Jul 25 04:13:59 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20259 for ; Tue, 25 Jul 2000 04:13:59 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA23741 for ietf-openpgp-bks; Tue, 25 Jul 2000 00:54:19 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA23737 for ; Tue, 25 Jul 2000 00:54:16 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB4A34610140; Tue, 25 Jul 2000 15:57:14 0800 Message-Id: <4.3.2.7.0.20000725154130.00b3f340@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jul 2000 15:45:52 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: dash escaped text and cleartext sig. q Cc: Tom Zerucha In-Reply-To: <20000720112745.A6173@deimos.mw.mediaone.net> References: <4.3.2.7.0.20000720141703.00b24500@mail.comasp.com> <4.3.2.7.0.20000720141703.00b24500@mail.comasp.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: Tom, At 11:27 AM 20/07/2000 -0400, Tom Zerucha wrote: >On Thu, Jul 20, 2000 at 03:10:14PM +0800, Erron Criddle wrote: > > To all, > > > > Just to clarify: > > > > If a cleartext signed message is sent to a recipient and the message body > > originally contained a "-" at the start of a line, would the recipient > > receive that same line prepended with a "- "? > > > > I am asking this because I have just received a message that has been > > cleartext signed using GnuPG 1.0.1, however there are whole lines of > "-" in > > them and they are not received as "- -------------------..."??? > > > > Does anyone know what is going on here or, once again, have I missed > something? > >My opgp will insert the extra dashes on any line beginning with a dash >(and hash the thus escaped text). I have just read 7.1, paragraph 2 and it states "...The message digest is computed using the cleartext itself, not the dash escaped form." You say "(and hash the thus escaped text)", however they say different... What way is the right way - to hash the dash escaped text or not? Also, does the receiver of a dash-escaped email receive text as "- ---------" or "---------"? TIA. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Tue Jul 25 13:07:20 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29934 for ; Tue, 25 Jul 2000 13:07:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09067 for ietf-openpgp-bks; Tue, 25 Jul 2000 09:41:40 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09062 for ; Tue, 25 Jul 2000 09:41:38 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA26349; Tue, 25 Jul 2000 12:44:33 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id MAA16198; Tue, 25 Jul 2000 12:44:09 -0400 Date: Tue, 25 Jul 2000 12:44:09 -0400 From: Tom Zerucha To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: dash escaped text and cleartext sig. q Message-ID: <20000725124409.A16188@deimos.mw.mediaone.net> References: <4.3.2.7.0.20000720141703.00b24500@mail.comasp.com> <4.3.2.7.0.20000720141703.00b24500@mail.comasp.com> <20000720112745.A6173@deimos.mw.mediaone.net> <4.3.2.7.0.20000725154130.00b3f340@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.0.20000725154130.00b3f340@mail.comasp.com>; from ejc@comasp.com on Tue, Jul 25, 2000 at 03:45:52PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jul 25, 2000 at 03:45:52PM +0800, Erron Criddle wrote: > Tom, > > At 11:27 AM 20/07/2000 -0400, Tom Zerucha wrote: > > >My opgp will insert the extra dashes on any line beginning with a dash > >(and hash the thus escaped text). OOPS! I was wrong... > I have just read 7.1, paragraph 2 and it states "...The message digest is > computed using the cleartext itself, not the dash escaped form." I should have looked at my code more carefully. I insert a dash/space, but I call my text line canonicalizer which strips it. > You say "(and hash the thus escaped text)", however they say different... > > What way is the right way - to hash the dash escaped text or not? > Also, does the receiver of a dash-escaped email receive text as "- > ---------" or "---------"? Good question.. I think they are supposed to receive: - ------------ But my implementation doesn't do this, though it probably should From owner-ietf-openpgp@mail.imc.org Fri Jul 28 05:40:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19730 for ; Fri, 28 Jul 2000 05:40:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA29069 for ietf-openpgp-bks; Fri, 28 Jul 2000 02:15:15 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA29061 for ; Fri, 28 Jul 2000 02:15:10 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A2E399101CA; Fri, 28 Jul 2000 17:18:43 0800 Message-Id: <4.3.2.7.0.20000728163033.00b5d050@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Jul 2000 17:07:10 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: CFB padding q 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: To all, I have noticed that in the RFC, it says to use PKCS-1 padding for "Public Key Encrypted Session key Packets", however, I was wondering what padding to use for symmetrical encryption using OpenPGP's version of CFB? I can't seem to find any references anywhere. Cheers. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Jul 28 09:53:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22515 for ; Fri, 28 Jul 2000 09:53:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA20463 for ietf-openpgp-bks; Fri, 28 Jul 2000 06:37:37 -0700 (PDT) Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20457 for ; Fri, 28 Jul 2000 06:37:35 -0700 (PDT) Received: from woudt.nl (diziliks.ai [209.88.68.211]) by cypherpunks.ai (Postfix) with ESMTP id B4BD44C; Fri, 28 Jul 2000 09:40:21 -0400 (AST) Message-ID: <39818D45.620416EF@woudt.nl> Date: Fri, 28 Jul 2000 09:40:21 -0400 From: Edwin Woudt X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: nl, en MIME-Version: 1.0 To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: CFB padding q References: <4.3.2.7.0.20000728163033.00b5d050@mail.comasp.com> 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 Erron Criddle wrote: > > To all, > > I have noticed that in the RFC, it says to use PKCS-1 padding for "Public > Key Encrypted Session key Packets", however, I was wondering what padding > to use for symmetrical encryption using OpenPGP's version of CFB? > > I can't seem to find any references anywhere. You do not need padding with CFB and OpenPGP CFB. CFB turns a block cipher into a stream cipher. Edwin From owner-ietf-openpgp@mail.imc.org Sat Jul 29 00:17:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19105 for ; Sat, 29 Jul 2000 00:17:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA07830 for ietf-openpgp-bks; Fri, 28 Jul 2000 20:59:35 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA07824 for ; Fri, 28 Jul 2000 20:59:33 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA6F7E110220; Sat, 29 Jul 2000 12:03:11 0800 Message-Id: <4.3.2.7.0.20000729112747.00b3c420@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 29 Jul 2000 11:51:37 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: CFB padding q Cc: Edwin Woudt In-Reply-To: <39818D45.620416EF@woudt.nl> References: <4.3.2.7.0.20000728163033.00b5d050@mail.comasp.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: Edwin, At 09:40 AM 28/07/2000 -0400, Edwin Woudt wrote: >Erron Criddle wrote: > > > > To all, > > > > I have noticed that in the RFC, it says to use PKCS-1 padding for "Public > > Key Encrypted Session key Packets", however, I was wondering what padding > > to use for symmetrical encryption using OpenPGP's version of CFB? > > > > I can't seem to find any references anywhere. > > >You do not need padding with CFB and OpenPGP CFB. >CFB turns a block cipher into a stream cipher. I'm not sure what you're saying Edwin. From section 12.8, item 12, it says; "FRE is xored with the next BS octets." From this, I read that the CFB requires the plaintext to be a multiple of the blocksize of the symmetrical algorithm. My question is, then, how do you pad the plaintext to make it equal to the blocksize of the symmetrical algorithm? For example, if we are using twofish that has a blocksize of 128 bits and we only have 96 bits of plaintext, what/how do I pad the plaintext up to 128 bits? Cheers. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Sat Jul 29 10:09:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29464 for ; Sat, 29 Jul 2000 10:09:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA12163 for ietf-openpgp-bks; Sat, 29 Jul 2000 06:50:22 -0700 (PDT) Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12143 for ; Sat, 29 Jul 2000 06:50:10 -0700 (PDT) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id 8B01949; Sat, 29 Jul 2000 09:53:01 -0400 (AST) Message-ID: <3982E1BD.3B18F17@vangelderen.org> Date: Sat, 29 Jul 2000 09:53:01 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Erron Criddle Cc: ietf-openpgp@imc.org, Edwin Woudt Subject: Re: CFB padding q References: <4.3.2.7.0.20000728163033.00b5d050@mail.comasp.com> <4.3.2.7.0.20000729112747.00b3c420@mail.comasp.com> 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 Erron Criddle wrote: [...] > From section 12.8, item 12, it says; "FRE is xored with the next BS octets." > > From this, I read that the CFB requires the plaintext to be a multiple of > the blocksize of the symmetrical algorithm. I guess that strictly speaking the RFC is not correct. It should read: if( BS < remainder ): FRE is xored with the next 'BS' octets. go to step 12 else: FRE is xored with the next 'remainder' octets. exit Have a look at Bruce Schneier's description of standard CFB mode on page 200 of Applied Cryptography, 2nd Edition. The only difference between openpgpCFB and CFB mode is that the openpgpCFB sometimes does an encryption before the shift register is full. > For example, if we are using twofish that has a blocksize of 128 bits and > we only have 96 bits of plaintext, what/how do I pad the plaintext up to > 128 bits? You prefix 18 bytes as per RFC 2440, giving you 30 bytes to encrypt. Initialize the shift register with an IV of all zeros. Encrypt the shift register, which gives you 16 bytes of key stream. Encrypt the first 16 bytes by xor-ing 'em with the 16 bytes of key stream and shift the encrypted bytes into the shift register as you go. (The shift register holds 16 bytes so all the old bytes fall off the left end.) Now encrypt the shift register again, which gives you the next 16 bytes of key stream. Encrypt the next *two* bytes by xor-ing with the first two key stream bytes and shift the encrypted two bytes into the shift register. (Only two bytes fall off the left end.) Encrypt the shift register again (yes, you just threw away 14 of your key stream bytes unused) giving you the next 16 bytes of key stream. Encrypt next 12 bytes by xor-ing and throw away the unused 4 bytes of your keystream. No padding needed. A working implementation can be found at: http://anoncvs.cryptix.org/cgi-bin/cvsweb.cgi/projects/ \ jce/src/cryptix.jce.provider.cipher/ \ ModeCFB.java?rev=1.2&content-type=text/x-cvsweb-markup HTH, Jeroen -- Jeroen C. van Gelderen o _ _ _ jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_ \_| \ _|/' \/ (_)>(_) (_) (_) (_) (_)' _\o_ From owner-ietf-openpgp@mail.imc.org Sat Jul 29 14:15:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28719 for ; Sat, 29 Jul 2000 14:15:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24947 for ietf-openpgp-bks; Sat, 29 Jul 2000 10:59:30 -0700 (PDT) Received: from altavistausa.com (max1-3.newyork.corecomm.net [209.81.238.131]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24929; Sat, 29 Jul 2000 10:59:26 -0700 (PDT) From: Subject: Re: From Lorraine,as promised,I can lower your bill Date: Sat, 29 Jul 2000 14:59:12 Message-Id: <894.14814.93337@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

Received: by ns.secondary.com (8.9.3/8.9.3) id KAA24947 for ietf-openpgp-bks; Sat, 29 Jul 2000 10:59:30 -0700 (PDT) Received: from altavistausa.com (max1-3.newyork.corecomm.net [209.81.238.131]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA24929; Sat, 29 Jul 2000 10:59:26 -0700 (PDT) From: Subject: Re: From Lorraine,as promised,I can lower your bill Date: Sat, 29 Jul 2000 14:59:12 Message-Id: <894.14814.93337@altavistausa.com> Mime-Version: 1.0 Content-Type: text/html; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Untitled Document


Today, everyone knows the impact of the Internet.
But not everyone nows how to cut their phone bill in 1/2. Just a Few examples!!!!

Uk $.04     France $.06    UAE  $.31    Saudi Arabia $.59     Denmark $.04      Sweden $.05

Click Here Now.

If you do not have flash please go to
www.macromedia.com
to download it.

Received: by ns.secondary.com (8.9.3/8.9.3) id GAA12163 for ietf-openpgp-bks; Sat, 29 Jul 2000 06:50:22 -0700 (PDT) Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA12143 for ; Sat, 29 Jul 2000 06:50:10 -0700 (PDT) Received: from vangelderen.org (grolsch.ai [209.88.68.214]) by cypherpunks.ai (Postfix) with ESMTP id 8B01949; Sat, 29 Jul 2000 09:53:01 -0400 (AST) Message-ID: <3982E1BD.3B18F17@vangelderen.org> Date: Sat, 29 Jul 2000 09:53:01 -0400 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Erron Criddle Cc: ietf-openpgp@imc.org, Edwin Woudt Subject: Re: CFB padding q References: <4.3.2.7.0.20000728163033.00b5d050@mail.comasp.com> <4.3.2.7.0.20000729112747.00b3c420@mail.comasp.com> 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: Erron Criddle wrote: [...] > From section 12.8, item 12, it says; "FRE is xored with the next BS octets." > > From this, I read that the CFB requires the plaintext to be a multiple of > the blocksize of the symmetrical algorithm. I guess that strictly speaking the RFC is not correct. It should read: if( BS < remainder ): FRE is xored with the next 'BS' octets. go to step 12 else: FRE is xored with the next 'remainder' octets. exit Have a look at Bruce Schneier's description of standard CFB mode on page 200 of Applied Cryptography, 2nd Edition. The only difference between openpgpCFB and CFB mode is that the openpgpCFB sometimes does an encryption before the shift register is full. > For example, if we are using twofish that has a blocksize of 128 bits and > we only have 96 bits of plaintext, what/how do I pad the plaintext up to > 128 bits? You prefix 18 bytes as per RFC 2440, giving you 30 bytes to encrypt. Initialize the shift register with an IV of all zeros. Encrypt the shift register, which gives you 16 bytes of key stream. Encrypt the first 16 bytes by xor-ing 'em with the 16 bytes of key stream and shift the encrypted bytes into the shift register as you go. (The shift register holds 16 bytes so all the old bytes fall off the left end.) Now encrypt the shift register again, which gives you the next 16 bytes of key stream. Encrypt the next *two* bytes by xor-ing with the first two key stream bytes and shift the encrypted two bytes into the shift register. (Only two bytes fall off the left end.) Encrypt the shift register again (yes, you just threw away 14 of your key stream bytes unused) giving you the next 16 bytes of key stream. Encrypt next 12 bytes by xor-ing and throw away the unused 4 bytes of your keystream. No padding needed. A working implementation can be found at: http://anoncvs.cryptix.org/cgi-bin/cvsweb.cgi/projects/ \ jce/src/cryptix.jce.provider.cipher/ \ ModeCFB.java?rev=1.2&content-type=text/x-cvsweb-markup HTH, Jeroen -- Jeroen C. van Gelderen o _ _ _ jeroen@vangelderen.org _o /\_ _ \\o (_)\__/o (_) _< \_ _>(_) (_)/<_ \_| \ _|/' \/ (_)>(_) (_) (_) (_) (_)' _\o_ Received: by ns.secondary.com (8.9.3/8.9.3) id UAA07830 for ietf-openpgp-bks; Fri, 28 Jul 2000 20:59:35 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA07824 for ; Fri, 28 Jul 2000 20:59:33 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA6F7E110220; Sat, 29 Jul 2000 12:03:11 0800 Message-Id: <4.3.2.7.0.20000729112747.00b3c420@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 29 Jul 2000 11:51:37 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: CFB padding q Cc: Edwin Woudt In-Reply-To: <39818D45.620416EF@woudt.nl> References: <4.3.2.7.0.20000728163033.00b5d050@mail.comasp.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: Edwin, At 09:40 AM 28/07/2000 -0400, Edwin Woudt wrote: >Erron Criddle wrote: > > > > To all, > > > > I have noticed that in the RFC, it says to use PKCS-1 padding for "Public > > Key Encrypted Session key Packets", however, I was wondering what padding > > to use for symmetrical encryption using OpenPGP's version of CFB? > > > > I can't seem to find any references anywhere. > > >You do not need padding with CFB and OpenPGP CFB. >CFB turns a block cipher into a stream cipher. I'm not sure what you're saying Edwin. From section 12.8, item 12, it says; "FRE is xored with the next BS octets." From this, I read that the CFB requires the plaintext to be a multiple of the blocksize of the symmetrical algorithm. My question is, then, how do you pad the plaintext to make it equal to the blocksize of the symmetrical algorithm? For example, if we are using twofish that has a blocksize of 128 bits and we only have 96 bits of plaintext, what/how do I pad the plaintext up to 128 bits? Cheers. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id GAA20463 for ietf-openpgp-bks; Fri, 28 Jul 2000 06:37:37 -0700 (PDT) Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA20457 for ; Fri, 28 Jul 2000 06:37:35 -0700 (PDT) Received: from woudt.nl (diziliks.ai [209.88.68.211]) by cypherpunks.ai (Postfix) with ESMTP id B4BD44C; Fri, 28 Jul 2000 09:40:21 -0400 (AST) Message-ID: <39818D45.620416EF@woudt.nl> Date: Fri, 28 Jul 2000 09:40:21 -0400 From: Edwin Woudt X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: nl, en MIME-Version: 1.0 To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: CFB padding q References: <4.3.2.7.0.20000728163033.00b5d050@mail.comasp.com> 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: Erron Criddle wrote: > > To all, > > I have noticed that in the RFC, it says to use PKCS-1 padding for "Public > Key Encrypted Session key Packets", however, I was wondering what padding > to use for symmetrical encryption using OpenPGP's version of CFB? > > I can't seem to find any references anywhere. You do not need padding with CFB and OpenPGP CFB. CFB turns a block cipher into a stream cipher. Edwin Received: by ns.secondary.com (8.9.3/8.9.3) id CAA29069 for ietf-openpgp-bks; Fri, 28 Jul 2000 02:15:15 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA29061 for ; Fri, 28 Jul 2000 02:15:10 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A2E399101CA; Fri, 28 Jul 2000 17:18:43 0800 Message-Id: <4.3.2.7.0.20000728163033.00b5d050@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 28 Jul 2000 17:07:10 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: CFB padding q 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: To all, I have noticed that in the RFC, it says to use PKCS-1 padding for "Public Key Encrypted Session key Packets", however, I was wondering what padding to use for symmetrical encryption using OpenPGP's version of CFB? I can't seem to find any references anywhere. Cheers. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id JAA09067 for ietf-openpgp-bks; Tue, 25 Jul 2000 09:41:40 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA09062 for ; Tue, 25 Jul 2000 09:41:38 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA26349; Tue, 25 Jul 2000 12:44:33 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id MAA16198; Tue, 25 Jul 2000 12:44:09 -0400 Date: Tue, 25 Jul 2000 12:44:09 -0400 From: Tom Zerucha To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: dash escaped text and cleartext sig. q Message-ID: <20000725124409.A16188@deimos.mw.mediaone.net> References: <4.3.2.7.0.20000720141703.00b24500@mail.comasp.com> <4.3.2.7.0.20000720141703.00b24500@mail.comasp.com> <20000720112745.A6173@deimos.mw.mediaone.net> <4.3.2.7.0.20000725154130.00b3f340@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.0.20000725154130.00b3f340@mail.comasp.com>; from ejc@comasp.com on Tue, Jul 25, 2000 at 03:45:52PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jul 25, 2000 at 03:45:52PM +0800, Erron Criddle wrote: > Tom, > > At 11:27 AM 20/07/2000 -0400, Tom Zerucha wrote: > > >My opgp will insert the extra dashes on any line beginning with a dash > >(and hash the thus escaped text). OOPS! I was wrong... > I have just read 7.1, paragraph 2 and it states "...The message digest is > computed using the cleartext itself, not the dash escaped form." I should have looked at my code more carefully. I insert a dash/space, but I call my text line canonicalizer which strips it. > You say "(and hash the thus escaped text)", however they say different... > > What way is the right way - to hash the dash escaped text or not? > Also, does the receiver of a dash-escaped email receive text as "- > ---------" or "---------"? Good question.. I think they are supposed to receive: - ------------ But my implementation doesn't do this, though it probably should Received: by ns.secondary.com (8.9.3/8.9.3) id AAA23741 for ietf-openpgp-bks; Tue, 25 Jul 2000 00:54:19 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA23737 for ; Tue, 25 Jul 2000 00:54:16 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB4A34610140; Tue, 25 Jul 2000 15:57:14 0800 Message-Id: <4.3.2.7.0.20000725154130.00b3f340@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 25 Jul 2000 15:45:52 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: dash escaped text and cleartext sig. q Cc: Tom Zerucha In-Reply-To: <20000720112745.A6173@deimos.mw.mediaone.net> References: <4.3.2.7.0.20000720141703.00b24500@mail.comasp.com> <4.3.2.7.0.20000720141703.00b24500@mail.comasp.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: Tom, At 11:27 AM 20/07/2000 -0400, Tom Zerucha wrote: >On Thu, Jul 20, 2000 at 03:10:14PM +0800, Erron Criddle wrote: > > To all, > > > > Just to clarify: > > > > If a cleartext signed message is sent to a recipient and the message body > > originally contained a "-" at the start of a line, would the recipient > > receive that same line prepended with a "- "? > > > > I am asking this because I have just received a message that has been > > cleartext signed using GnuPG 1.0.1, however there are whole lines of > "-" in > > them and they are not received as "- -------------------..."??? > > > > Does anyone know what is going on here or, once again, have I missed > something? > >My opgp will insert the extra dashes on any line beginning with a dash >(and hash the thus escaped text). I have just read 7.1, paragraph 2 and it states "...The message digest is computed using the cleartext itself, not the dash escaped form." You say "(and hash the thus escaped text)", however they say different... What way is the right way - to hash the dash escaped text or not? Also, does the receiver of a dash-escaped email receive text as "- ---------" or "---------"? TIA. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22427 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:58:41 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA22423 for ; Sun, 23 Jul 2000 22:58:39 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 23268 invoked from network); 24 Jul 2000 06:00:26 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Jul 2000 06:00:26 -0000 To: ietf-openpgp@imc.org Subject: Re: Recommended 5.3 wording change In-Reply-To: <200007210523.WAA02739@finney.org> References: <200007210523.WAA02739@finney.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000724150149L.1001@eccosys.com> Date: Mon, 24 Jul 2000 15:01:49 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 20 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: Recommended 5.3 wording change Date: Thu, 20 Jul 2000 22:23:16 -0700 Message-ID: <200007210523.WAA02739@finney.org> ... > Furthermore the corresponding language in 5.2.3, which describes what is > hashed for V4 signature packets, is missing the description of the five > byte postscript, which is wrong. > > I think it would be best in each case simply to refer to section 5.2.4, > Computing Signatures, which gives a more complete description of exactly > what is hashed. You might want to look there and see if the language > is unclear. i think these are good points. section 5.2.4 reads much more clearly to me than the earlier sections. i think adding appropriate references to section 5.2.4 in relevant locations would be a good improvement. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22384 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:57:11 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA22379 for ; Sun, 23 Jul 2000 22:57:09 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AE5E31801E8; Mon, 24 Jul 2000 14:00:14 0800 Message-Id: <4.3.2.7.0.20000724134705.00b2f6a8@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 13:48:57 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: final q re sigs. Cc: hal@finney.org In-Reply-To: <200007240550.WAA09707@finney.org> 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: Hal, At 10:50 PM 23/07/2000 -0700, hal@finney.org wrote: > > My question is, for a version 4 sig using DSA and SHA1, do we: > > > > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. > >It is this one, where the "+" means concatenation. Most implementations >of hash functions do not require you to literally concatenate the data, >but rather you can pass the data in pieces, so you first pass in a, then >b, then c. In the spec we write this as "first hash a, then hash b, then >hash c," and so on. Aahhh...this is where I was getting confused (re the *then* words) Thanks :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id WAA22215 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:49:27 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA22210 for ; Sun, 23 Jul 2000 22:49:25 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA09707; Sun, 23 Jul 2000 22:50:44 -0700 Date: Sun, 23 Jul 2000 22:50:44 -0700 Message-Id: <200007240550.WAA09707@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: final q re sigs. Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > My question is, for a version 4 sig using DSA and SHA1, do we: > > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. It is this one, where the "+" means concatenation. Most implementations of hash functions do not require you to literally concatenate the data, but rather you can pass the data in pieces, so you first pass in a, then b, then c. In the spec we write this as "first hash a, then hash b, then hash c," and so on. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21991 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:39:43 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21986 for ; Sun, 23 Jul 2000 22:39:40 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA3E1B701E8; Mon, 24 Jul 2000 13:42:38 0800 Message-Id: <4.3.2.7.0.20000724132919.00b75ca8@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 13:31:21 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: final q re sigs. Cc: sen_ml@eccosys.com In-Reply-To: <20000724140708H.1001@eccosys.com> References: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.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 02:07 PM 24/07/2000 +0900, sen_ml@eccosys.com wrote: > > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. > >i think it's closest to this. I also thought this, however I needed confirmation...can anyone else confirm? > my interpretation is: > >H(actual data + > version + signature type + pubkey algo + hash algo + > hashed subpacket length + hashed subpackets + > 0x04 + 0xff + length of hashed data from sig packet) > >or > >H(actual data + > fields of sig packet from version through hashed subpackets + > trailer of six octets a la section 5.2.4) > >perhaps someone else can confirm ;-) > >note that your definition of (b) says "incl. subpackets", but >actually, you don't include unhashed subpackets...but you probably >meant that anyway, right? Yes :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21225 for ietf-openpgp-bks; Sun, 23 Jul 2000 22:04:07 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21218 for ; Sun, 23 Jul 2000 22:04:02 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 22056 invoked from network); 24 Jul 2000 05:05:46 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Jul 2000 05:05:46 -0000 In-Reply-To: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> References: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> Subject: Re: final q re sigs. To: ietf-openpgp@imc.org X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000724140708H.1001@eccosys.com> Date: Mon, 24 Jul 2000 14:07:08 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 42 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: final q re sigs. Date: Mon, 24 Jul 2000 11:05:50 +0800 Message-ID: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> ... > Let's assume: (a) = actual data, (b) = signature data to be hashed (incl. > subpackets), (c) = last six octets > > My question is, for a version 4 sig using DSA and SHA1, do we: > > 1) H(a) + H(b) + H(c) = 480 bit value, then hash this to produce the final > hash value (before sig. alg.) i don't think it is this. as Hal mentioned in an earlier post, a "more complete description of exactly what is hashed" is given in section 5.2.4. you'll note that in his post, he suggested that other sections might refer to section 5.2.4. that seems like a good idea to me. > 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. i think it's closest to this. my interpretation is: H(actual data + version + signature type + pubkey algo + hash algo + hashed subpacket length + hashed subpackets + 0x04 + 0xff + length of hashed data from sig packet) or H(actual data + fields of sig packet from version through hashed subpackets + trailer of six octets a la section 5.2.4) perhaps someone else can confirm ;-) note that your definition of (b) says "incl. subpackets", but actually, you don't include unhashed subpackets...but you probably meant that anyway, right? Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19195 for ietf-openpgp-bks; Sun, 23 Jul 2000 20:14:01 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA19163 for ; Sun, 23 Jul 2000 20:13:57 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A8144050070; Mon, 24 Jul 2000 11:16:52 PDT Message-Id: <4.3.2.7.0.20000724104343.00b30ed0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 24 Jul 2000 11:05:50 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: final q re sigs. 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: To all, One final clarifying question re 2440: After looking at 5.2.3 and 5.2.4 regarding "what" is hashed and "how" it is hashed before being fed into the DSA, I'm still slightly confused. -----BEGIN QUOTES----- 5.2.3 states: "The data being signed is hashed, and then the signature data from the version number through the hashed subpacket data (inclusive) is hashed." 5.2.4 states: "Once the data body is hashed, then a trailer is hashed. . A version 4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data." "V4 signatures also hash in a final trailer of six octets:..." "After all this has been hashed , the resulting hash field is used in the signature algorithm,..." -----END QUOTES----- Let's assume: (a) = actual data, (b) = signature data to be hashed (incl. subpackets), (c) = last six octets My question is, for a version 4 sig using DSA and SHA1, do we: 1) H(a) + H(b) + H(c) = 480 bit value, then hash this to produce the final hash value (before sig. alg.) 2) H(a + b + c) = 160 bit value to be fed into the sig. alg. 3) i) Initialise the SHA1 hashing alg. with the values A=0x67452301, B=0xEFCDAB89, C=0x98BADCFE, D=0x10325476, E=0xC3D2E1F0 ii) Hash (a) then split the 160 bit result into 5x 32 bit values, representing the next five 32 bit initialization numbers (A,B, C, D, E) for the hashing algorithm. iii) Hash (b) then split the 160 bit result into 5x 32 bit values, representing the next five 32 bit initialization numbers (A,B, C, D, E) for the hashing algorithm. iv) Hash (c) then use the 160 bit result in the signature algorithm (DSA). Thanks for any replies as I am reading these three possibilities from the doc and I'm not sure which one to use. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id FAA20267 for ietf-openpgp-bks; Sun, 23 Jul 2000 05:30:19 -0700 (PDT) Received: from mailserver1.hrz.tu-darmstadt.de (root@mailserver1.hrz.tu-darmstadt.de [130.83.126.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA20263 for ; Sun, 23 Jul 2000 05:30:17 -0700 (PDT) Received: from sun14.hrz.tu-darmstadt.de (sun14.hrz.tu-darmstadt.de [130.83.126.11]) by mailserver1.hrz.tu-darmstadt.de (8.9.1a/8.9.1) with ESMTP id OAA21608; Sun, 23 Jul 2000 14:30:45 +0200 (MET DST) Received: from ppp310.stud.tu-darmstadt.de (ppp310.stud.tu-darmstadt.de [130.83.176.61]) by sun14.hrz.tu-darmstadt.de (8.7.1/8.7.1.2pm+udb) with SMTP id OAA12538; Sun, 23 Jul 2000 14:32:35 +0200 (MET DST) Received: id ; Sun, 23 Jul 2000 14:44:17 +0200 (CEST) Message-Id: Date: Sun, 23 Jul 2000 14:44:17 +0200 (CEST) From: bmoeller@hrzpub.tu-darmstadt.de (Bodo Moeller) To: ietf-openpgp@imc.org, Jon Callas , kryptobunny@freedom.net, coderpunks@toad.com Subject: Re: Y2K is over In-Reply-To: References: <200007201706.NAA14948@fs3.freedom.net> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas : > kryptobunny@freedom.net: >> Benefits from saving a few bytes in PGP sigs: >> >> PGP users 4 M >> (original business plan claim) >> bytes saved per sig 3 >> sigs per user 100 >> --- >> total bytes saved 1.2 G > The byte savings you put assumes that you have a disk with a 1 byte block > size. Typically, block sizes on disks are larger. Suppose you have a disk > with an 8K block size. Changing a file from 3000 bytes to 2999 bytes saves > nothing. You only really save space if the file that contains a structure > changes the block count of the file. But in this case you save 8K bytes at once. If the file size modulo the block size is roughly uniformly distributed, then you have expected savings of one actual byte of disk space for each byte of file size. (Actually it's the fragment size, not the block size, that counts. Since 4.3 BSD, file sytems don't waste a complete block for the final bytes of a file. Instead a block can be shared for the final fragments of multiple files. This is more likely to be 1K than 8K, so even if you usually have rather short messages you will often use more than one fragment.) Also there can be multiple signatures in the same file (mbox for example). And some folks even back up their disks (often using compression so that block sizes are not an issue). Tapes are cheaper per GB than hard disks, but there'll usually be multiple copies of the same files. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id IAA04743 for ietf-openpgp-bks; Fri, 21 Jul 2000 08:29:55 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA04733 for ; Fri, 21 Jul 2000 08:29:53 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA24797; Fri, 21 Jul 2000 11:32:33 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id LAA10943; Fri, 21 Jul 2000 11:32:28 -0400 Date: Fri, 21 Jul 2000 11:32:28 -0400 From: Tom Zerucha To: Paul Koning Cc: tz@execpc.com, hal@finney.org, ietf-openpgp@imc.org Subject: Re: The price of the one v.s. the price of the many Message-ID: <20000721113228.A10940@deimos.mw.mediaone.net> References: <200007201822.LAA01530@finney.org> <20000720202510.B7749@deimos.mw.mediaone.net> <14712.23240.923710.211525@xedia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <14712.23240.923710.211525@xedia.com>; from pkoning@xedia.com on Fri, Jul 21, 2000 at 10:14:32AM -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is getting a little off topic, but I think OpenPGP has a programming philosophy of elegance and simplicity, so it isn't too far off. So I apologize in advance but will still respond ;). On Fri, Jul 21, 2000 at 10:14:32AM -0400, Paul Koning wrote: > >>>>> "Tom" == Tom Zerucha writes: > > Tom> On Thu, Jul 20, 2000 at 11:22:37AM -0700, hal@finney.org wrote: > >> > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive, > >> y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k) > >> $5000 > > net gain (loss) to society > from the Zimm Buddism > > >> ("every byte is sacred"): ($4988) > > The 2nd millenium is over. > >> Save programmers, not bytes. > >> > >> This is a misleading comparsion. There are circumstances where > >> bytes can be extremely costly, such as in the new wave of wireless > >> devices, smart > > Tom> You miss the biggest point. > > Tom> Value of 50 hours programming - $5000. > > Tom> value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE. > > Um, no. > > Right now drives are about $10 per GB. So 0.6 MB cost less than a > penny. It takes nearly a million drives to break even. And it drops each year. Just wait and we will all have 10GHz processors with a terabyte drive connected by high speed optical... The cost of Palm RAM is around $4000/GB. And it doesn't have a hard drive port. The cost of extra kilopackets on the VII if you don't have unlimited is quite high. If you want to embed something in 1M devices, the difference between a $15 and a $20 chip will pay for a lot of engineering time. In one sense your argument says that the US cars of the late '60s and early '70s were optimal because steel and fuel were cheap and getting cheaper, so 4-5K pounds wasn't a problem and maybe an asset in an accident. > Not only that, but the cost of extra programming is not just time > spent, but also quality reduced, which can be a lot more expensive. This assumes it reduces quality. Normally collapsing a complex (and big) interface into something which is both smaller and simpler increases quality. In my experience, the number of bugs is inversely proportional to the complexity of the system, and simple systems don't produce a lot of extra bytes. In the original context, I think the argument was "We could add this feature although it will take extra memory". Arguing your point, we shouldn't add such extra features because the cost won't simply be the extra memory, but the programmer, tester, and fixup time due to bugs or other incompatibilities said feature would introduce. Also, such things tax other programmers who want to interface with the software. That extra byte might cause hundreds of other programmers hours of grief. > In fact, if it introduces just one more bug that causes 1% of the > users $1 worth of extra hassle, you've already paid for the extra > bits. There is a point of diminishing returns, but I know of very little software that isn't 60% extra junk and gratuitous changes when new versions come out with all the problems you note - and I am not even talking about actual bugs. Bloat is something that is anti-quality - more interfaces, more code, more structures, more bytes that can be misinterpreted. Most of this applies to W32, less so for Mac, far less for Unicies where you get complaints about being too simplistic to be usable. The desire to reduce memory requirements is an indirect way to prevent bloat, and as such is probably inefficient or even wrong in some cases. Received: by ns.secondary.com (8.9.3/8.9.3) id HAA29841 for ietf-openpgp-bks; Fri, 21 Jul 2000 07:11:56 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA29837 for ; Fri, 21 Jul 2000 07:11:54 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyuq15570; Fri, 21 Jul 2000 14:14:34 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA26321; Fri, 21 Jul 00 10:10:39 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id KAA09110; Fri, 21 Jul 2000 10:14:33 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14712.23240.923710.211525@xedia.com> Date: Fri, 21 Jul 2000 10:14:32 -0400 (EDT) To: tz@execpc.com Cc: hal@finney.org, ietf-openpgp@imc.org Subject: Re: The price of the one v.s. the price of the many References: <200007201822.LAA01530@finney.org> <20000720202510.B7749@deimos.mw.mediaone.net> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Tom" == Tom Zerucha writes: Tom> On Thu, Jul 20, 2000 at 11:22:37AM -0700, hal@finney.org wrote: >> > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive, >> y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k) >> $5000 > > net gain (loss) to society > from the Zimm Buddism > >> ("every byte is sacred"): ($4988) > > The 2nd millenium is over. >> Save programmers, not bytes. >> >> This is a misleading comparsion. There are circumstances where >> bytes can be extremely costly, such as in the new wave of wireless >> devices, smart Tom> You miss the biggest point. Tom> Value of 50 hours programming - $5000. Tom> value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE. Um, no. Right now drives are about $10 per GB. So 0.6 MB cost less than a penny. It takes nearly a million drives to break even. Not only that, but the cost of extra programming is not just time spent, but also quality reduced, which can be a lot more expensive. In fact, if it introduces just one more bug that causes 1% of the users $1 worth of extra hassle, you've already paid for the extra bits. paul Received: by ns.secondary.com (8.9.3/8.9.3) id BAA13867 for ietf-openpgp-bks; Fri, 21 Jul 2000 01:53:27 -0700 (PDT) Received: from moutvdom00.kundenserver.de (moutvdom00.kundenserver.de [195.20.224.149]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA13856 for ; Fri, 21 Jul 2000 01:53:21 -0700 (PDT) From: wolfgang@redtenbacher.de Received: from [195.20.224.208] (helo=mrvdom01.kundenserver.de) by moutvdom00.kundenserver.de with esmtp (Exim 2.12 #2) id 13FYbA-0003Bn-00 for ietf-openpgp@imc.org; Fri, 21 Jul 2000 10:56:00 +0200 Received: from fra-pci-lai-vty57.as.wcom.net ([212.211.70.57]) by mrvdom01.kundenserver.de with smtp (Exim 2.12 #2) id 13FYav-0008LD-00 for ietf-openpgp@imc.org; Fri, 21 Jul 2000 10:55:46 +0200 Subject: Re: Y2K is over Message-Id: Bcc: Date: Fri, 21 Jul 2000 10:55:46 +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive, y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k) $5000 > > net gain (loss) to society > from the Zimm Buddism > ("every byte is sacred"): ($4988) > > The 2nd millenium is over. Save programmers, not bytes. I would rather say: "Save user ressources, and then save hardware and program maintainance ressources". The attitude "Size is no longer important as RAM and disks are so cheap!" is the reason behind Reiser's "law": "The speed increase of hardware is slower than the speed loss of software." ("Die Hardware wird langsamer schneller als die Software langsamer.") Experience shows that programmers who stop to worry about the ressources their programs eat up, have a tendency to more bugs and poorer code design than the "good old byte savers". So don't throw out the ideals of good programming just because in certain areas the hardware prices have gone down. Let us face it: First time creation of new programs is _not_ any real bottleneck. Evolution of programs to improve their quality and usability, however, _is_ a bottleneck. And outside the wonderful world of universities and research labs, hardware ressources _always_ show up as bottlenecks earlier or later, too. Therefore, don't overdo "byte saving" at the cost of poor program maintainability. But if byte saving can be achieved by a simple sub-routine that is coded once and can be ignored throughout the remainder of a program's life time (as in the case of PGP packet lengths), then, for God's sake, save those bytes! - Wolfgang Redtenbacher Chairman DIN NI-22.13 "Programming languages, M2" D/Chairman DIN NI-Erg/UA5 "Software ergonomics" (DIN = German Standards Institute) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA10893 for ietf-openpgp-bks; Fri, 21 Jul 2000 00:32:42 -0700 (PDT) Received: from granger.mail.mindspring.net (granger.mail.mindspring.net [207.69.200.148]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA10889 for ; Fri, 21 Jul 2000 00:32:39 -0700 (PDT) Received: from [199.174.205.25] (user-33qtj8p.dialup.mindspring.com [199.174.205.25]) by granger.mail.mindspring.net (8.9.3/8.8.5) with ESMTP id DAA31968; Fri, 21 Jul 2000 03:35:07 -0400 (EDT) Message-Id: In-Reply-To: References: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 21 Jul 2000 00:33:04 -0700 To: Jon Callas , Erron Criddle , ietf-openpgp@imc.org From: Bill Frantz Subject: Re: Correction reqd. in 5.2 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:52 PM -0700 7/20/00, Jon Callas wrote: >In our last episode ("Correction reqd. in 5.2", shown on 7/21/00), Erron >Criddle said: > >>To all, >> >>Another one (trivial but may confuse newcomers): >> >>section 5.2 starts off with: >> >>"A signature packet describes a binding between some public key and some >>data." >> >>should read: >> >>"A signature packet describes a binding between a private key and some data." >> > >I disagree. A signature binds the public key and the data. Signature >verification is done with the public key only, and that is the whole point >of the exercise. > > Jon Well, really there are two bindings. The signature binds the public key and the data. The public key and the private key are bound by their mathematical relationship. However, the real binding people are usually interested in is the binding between the holder of the private key and the data. The two bindings let us get between the private key and the data, but the next step is still only conjecture. ------------------------------------------------------------------------- Bill Frantz | Microsoft Outlook, the | Periwinkle -- Consulting (408)356-8506 | hacker's path to your | 16345 Englewood Ave. frantz@netcom.com | hard disk. | Los Gatos, CA 95032, USA Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05755 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:58 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05751 for ; Thu, 20 Jul 2000 22:22:56 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A1B146E0182; Fri, 21 Jul 2000 13:25:21 0800 Message-Id: <4.3.2.7.0.20000721131005.00b39ee0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 13:14:29 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: Correction reqd. in 5.2 Cc: jon@callas.org In-Reply-To: References: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.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:52 PM 20/07/2000 -0700, Jon Callas wrote: >I disagree. A signature binds the public key and the data. Isn't the private key used as well to create the sig? > Signature verification is done with the public key only, and that is the > whole point >of the exercise. > > Jon Agreed. It should read key pair as the signature is bound to both the private and public keys. Anyhow, you decide - I understood it, however someone else *may* get confused. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05722 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:10 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05717 for ; Thu, 20 Jul 2000 22:22:08 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 10756 invoked from network); 21 Jul 2000 05:23:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 21 Jul 2000 05:23:45 -0000 To: ietf-openpgp@imc.org Subject: Re: Recommended 5.3 wording change In-Reply-To: <4.3.2.7.0.20000721121106.00ae5330@mail.comasp.com> References: <4.3.2.7.0.20000721121106.00ae5330@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000721142500W.1001@eccosys.com> Date: Fri, 21 Jul 2000 14:25:00 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 26 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: Recommended 5.3 wording change Date: Fri, 21 Jul 2000 12:23:13 +0800 Message-ID: <4.3.2.7.0.20000721121106.00ae5330@mail.comasp.com> > The paragraph in section 5.3 (the one following the definition of the > packet body) reads as follows: > > "The data being signed is hashed, and then the signature data from the > version number through the hashed sub-packet data (inclusive) is hashed. > The..." > > From my previous e-mails regarding signatures, it seems it should read > something like: > > "To produce a signature, the data to be signed has the signature data from > the version number through to the hashed sub-packet data (inclusive) > appended to it. This data is then hashed and the resulting hash value is > signed. The..." i think this phrasing is easier to understand. [ the original phrasing sounds to me like describing a particular implementation. ] > Is that right? it agrees w/ my understanding. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05715 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:22:07 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05709 for ; Thu, 20 Jul 2000 22:22:06 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA02739; Thu, 20 Jul 2000 22:23:16 -0700 Date: Thu, 20 Jul 2000 22:23:16 -0700 Message-Id: <200007210523.WAA02739@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: Recommended 5.3 wording change Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The paragraph in section 5.3 (the one following the definition of the > packet body) reads as follows: > > "The data being signed is hashed, and then the signature data from the > version number through the hashed sub-packet data (inclusive) is hashed. > The..." > > From my previous e-mails regarding signatures, it seems it should read > something like: > > "To produce a signature, the data to be signed has the signature data from > the version number through to the hashed sub-packet data (inclusive) > appended to it. This data is then hashed and the resulting hash value is > signed. The..." > > Is that right? This is from 5.2.2 in the RFC. Neither description is all that great, IMO. "First this data is hashed, then that data is hashed" may not make it clear that all the data is feeding into one hash context. And the language about appending to the data may be taken literally by a naive implementer who thinks he has to construct a buffer holding this data all appended together nicely before feeding it to the hash function. Furthermore the corresponding language in 5.2.3, which describes what is hashed for V4 signature packets, is missing the description of the five byte postscript, which is wrong. I think it would be best in each case simply to refer to section 5.2.4, Computing Signatures, which gives a more complete description of exactly what is hashed. You might want to look there and see if the language is unclear. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05484 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:13:44 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05480 for ; Thu, 20 Jul 2000 22:13:43 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA02718; Thu, 20 Jul 2000 22:14:51 -0700 Date: Thu, 20 Jul 2000 22:14:51 -0700 Message-Id: <200007210514.WAA02718@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: Correction reqd. in 5.2 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron writes: > section 5.2 starts off with: > > "A signature packet describes a binding between some public key and some data." > > should read: > > "A signature packet describes a binding between a private key and some data." I don't agree. It is equally as valid to consider a signature as being bound to the verification public key as to the signing private key. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05205 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:06:06 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA05199 for ; Thu, 20 Jul 2000 22:06:04 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ADBE7D00216; Fri, 21 Jul 2000 13:08:30 0800 Message-Id: <4.3.2.7.0.20000721125459.00b1b6d0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:57:38 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: Correction reqd. in 5.2 Cc: sen_ml@eccosys.com In-Reply-To: <20000721135101X.1001@eccosys.com> References: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.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 01:51 PM 21/07/2000 +0900, sen_ml@eccosys.com wrote: >hi- > >From: Erron Criddle >Subject: Correction reqd. in 5.2 >Date: Fri, 21 Jul 2000 12:02:10 +0800 >Message-ID: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> > > > Another one (trivial but may confuse newcomers): > > > > section 5.2 starts off with: > > > > "A signature packet describes a binding between some public key and > some data." > > > > should read: > > > > "A signature packet describes a binding between a private key and some > data." > >isn't the binding really between "the keypair" and "some data"? I believe that would be a better description. It could read: "A signature packet describes a binding between a public key pair and some data." or thereabouts :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id WAA05177 for ietf-openpgp-bks; Thu, 20 Jul 2000 22:05:43 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA05173 for ; Thu, 20 Jul 2000 22:05:40 -0700 (PDT) Received: from [63.73.97.181] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1d11); Thu, 20 Jul 2000 22:08:13 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> References: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> Date: Thu, 20 Jul 2000 21:52:45 -0700 To: Erron Criddle , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Correction reqd. in 5.2 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Correction reqd. in 5.2", shown on 7/21/00), Erron Criddle said: >To all, > >Another one (trivial but may confuse newcomers): > >section 5.2 starts off with: > >"A signature packet describes a binding between some public key and some >data." > >should read: > >"A signature packet describes a binding between a private key and some data." > I disagree. A signature binds the public key and the data. Signature verification is done with the public key only, and that is the whole point of the exercise. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id VAA03290 for ietf-openpgp-bks; Thu, 20 Jul 2000 21:31:29 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA03283 for ; Thu, 20 Jul 2000 21:31:26 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5AD4520182; Fri, 21 Jul 2000 12:34:05 0800 Message-Id: <4.3.2.7.0.20000721121106.00ae5330@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:23:13 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Recommended 5.3 wording change 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: To all, The paragraph in section 5.3 (the one following the definition of the packet body) reads as follows: "The data being signed is hashed, and then the signature data from the version number through the hashed sub-packet data (inclusive) is hashed. The..." From my previous e-mails regarding signatures, it seems it should read something like: "To produce a signature, the data to be signed has the signature data from the version number through to the hashed sub-packet data (inclusive) appended to it. This data is then hashed and the resulting hash value is signed. The..." Is that right? Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02916 for ietf-openpgp-bks; Thu, 20 Jul 2000 21:10:26 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA02912 for ; Thu, 20 Jul 2000 21:10:24 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A0BE909022C; Fri, 21 Jul 2000 12:13:02 0800 Message-Id: <4.3.2.7.0.20000721115942.00b16ab0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 12:02:10 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Correction reqd. in 5.2 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: To all, Another one (trivial but may confuse newcomers): section 5.2 starts off with: "A signature packet describes a binding between some public key and some data." should read: "A signature packet describes a binding between a private key and some data." Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id UAA01524 for ietf-openpgp-bks; Thu, 20 Jul 2000 20:46:00 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA01520 for ; Thu, 20 Jul 2000 20:45:57 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AAF88ED018E; Fri, 21 Jul 2000 11:48:24 0800 Message-Id: <4.3.2.7.0.20000721113303.00b2efa0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 21 Jul 2000 11:37:32 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Correction reqd. in 5.5.2 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: To all, You may have already noticed, but in 5.5.2 the MPI values for y (for DSA and ElGamal) have been stated as: MPI of ... public key value y (=g**x where x is secret) This should read: MPI of ... public key value y (=g**x mod p where x is secret) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id RAA14325 for ietf-openpgp-bks; Thu, 20 Jul 2000 17:22:33 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA14321 for ; Thu, 20 Jul 2000 17:22:31 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id UAA24121; Thu, 20 Jul 2000 20:25:08 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id UAA07758; Thu, 20 Jul 2000 20:25:11 -0400 Date: Thu, 20 Jul 2000 20:25:10 -0400 From: Tom Zerucha To: hal@finney.org Cc: ietf-openpgp@imc.org Subject: The price of the one v.s. the price of the many Message-ID: <20000720202510.B7749@deimos.mw.mediaone.net> References: <200007201822.LAA01530@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007201822.LAA01530@finney.org>; from hal@finney.org on Thu, Jul 20, 2000 at 11:22:37AM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jul 20, 2000 at 11:22:37AM -0700, hal@finney.org wrote: > > balance sheet > > > > value of 1.6 G bytes > > ($200 IBM 20Gb drive, y2k) $12 > > > > value of 50 hours programming > > ($100 per hour, y2k) $5000 > > > > net gain (loss) to society > > from the Zimm Buddism > > ("every byte is sacred"): ($4988) > > > > The 2nd millenium is over. Save programmers, not bytes. > > This is a misleading comparsion. There are circumstances where bytes can > be extremely costly, such as in the new wave of wireless devices, smart You miss the biggest point. Value of 50 hours programming - $5000. value of 0.6 Mb (I assume this is the number) - $12 PER DRIVE. Assuming it will be installed on more than 416 drives it is cheaper to pay a programmer to shrink the application. You may have noticed this if you had to upgrade CPU, Memory, or Disk when going from Windows 3.1 to Windows 2000. (and if you use a Palm Pilot's ram as an example the cost goes way up) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05950 for ietf-openpgp-bks; Thu, 20 Jul 2000 11:38:47 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05946 for ; Thu, 20 Jul 2000 11:38:46 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id LAA04600; Thu, 20 Jul 2000 11:41:23 -0700 (PDT) Received: from [63.73.97.181] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id LAA04596; Thu, 20 Jul 2000 11:41:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200007201706.NAA14948@fs3.freedom.net> References: <200007201706.NAA14948@fs3.freedom.net> Date: Thu, 20 Jul 2000 11:38:05 -0700 To: kryptobunny@freedom.net, ietf-openpgp@imc.org From: Jon Callas Subject: Re: Y2K is over Cc: coderpunks@toad.com Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The byte savings you put assumes that you have a disk with a 1 byte block size. Typically, block sizes on disks are larger. Suppose you have a disk with an 8K block size. Changing a file from 3000 bytes to 2999 bytes saves nothing. You only really save space if the file that contains a structure changes the block count of the file. There's another effect, too. And that is the code size. Saving 1 byte of data at the cost of 200 bytes of code is probably not cost effective because memory is more expensive than disk, and a large code size may preclude using small devices, like pagers, iButtons, etc. Data is transient, code is resident. So yeah, what you said. Saving a byte isn't worth it. If it were up to me, I would deprecate anything but the 5-byte lengths. Small devices are better served by only using 5-byte lengths. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id LAA05330 for ietf-openpgp-bks; Thu, 20 Jul 2000 11:21:27 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA05326 for ; Thu, 20 Jul 2000 11:21:26 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id LAA01530; Thu, 20 Jul 2000 11:22:37 -0700 Date: Thu, 20 Jul 2000 11:22:37 -0700 Message-Id: <200007201822.LAA01530@finney.org> To: ietf-openpgp@imc.org, kryptobunny@freedom.net Subject: Re: Y2K is over Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > balance sheet > > value of 1.6 G bytes > ($200 IBM 20Gb drive, y2k) $12 > > value of 50 hours programming > ($100 per hour, y2k) $5000 > > net gain (loss) to society > from the Zimm Buddism > ("every byte is sacred"): ($4988) > > The 2nd millenium is over. Save programmers, not bytes. This is a misleading comparsion. There are circumstances where bytes can be extremely costly, such as in the new wave of wireless devices, smart cards, and other forms of portable electronics where every byte counts, both for storage and for transmission. Not all uses of signatures will have access to a 20 GB hard drive and megabit data transmission rates. Furthermore, although any given optimization may save only a few bytes, the net result of multiple such choices based on a philosophy of space savings can add up to a substantial percentage reduction. This is especially true when contrasted with the philosophy that space doesn't matter any more. The end result of that philosophical approach would be something like XML, with ascii rendering of data and verbose tags to identify each field. PGP's signatures are probably 1/3 the size you'd get if you used straightforward XML to represent the data. So, yes, the second millennium is over, but no, there are still situations where saving bytes makes sense. Having said that, you can still look at the various optimizations in the OpenPGP spec to see which give you the most space-saving bang for the programmer-effort buck. Obviously using untagged binary data is the biggest win. Beyond that, some of the optimizations, like the string-to-key iteration count, are probably a lot more effort than they are worth, since they're not used much. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id KAA03459 for ietf-openpgp-bks; Thu, 20 Jul 2000 10:03:39 -0700 (PDT) Received: from fs3.freedom.net (fs3.freedom.net [209.5.124.67]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA03455 for ; Thu, 20 Jul 2000 10:03:38 -0700 (PDT) From: kryptobunny@freedom.net Received: (from freedom@localhost) by fs3.freedom.net (8.9.2/8.9.2) id NAA14948 for ietf-openpgp@imc.org; Thu, 20 Jul 2000 13:06:15 -0400 (EDT) Message-Id: <200007201706.NAA14948@fs3.freedom.net> Comments: This message was processed by the Freedom Mail Gateway X-ZKS-Freedom-Hdr-Sig: AQGDdthjQcbiLoVCBULujs57t30dEPeKR0acWZw0jSRx9+y7P8KosB0E X-ZKS-Freedom-Auth-Date: Thu, 20 Jul 2000 13:05:33 -0400 X-ZKS-Freedom-Auth-Cc: coderpunks@toad.com X-ZKS-Freedom-Auth-To: ietf-openpgp@imc.org X-ZKS-Freedom-Auth-From: kryptobunny@freedom.net Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset = "us-ascii" Subject: Y2K is over CC: coderpunks@toad.com To: ietf-openpgp@imc.org MIME-Version: 1.0 Date: Thu, 20 Jul 2000 13:05:33 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Hal wrote on the ietf-openpgp@imc.org list: > > ... We have had many complaints that the current variable-length > packet-length mechanism is somewhat over-engineered for the purpose. > Still, almost all subpackets are short enough that one byte is enough > for the length, so you do save a few bytes by using the compressed > length encoding. Benefits from saving a few bytes in PGP sigs: PGP users 4 M (original business plan claim) bytes saved per sig 3 sigs per user 100 --- total bytes saved 1.2 G Costs of saving a few bytes in PGP sigs: Cost of coding weird length field 1 Maintenance factor of complex code 5 Independant implementations 10 -- total hours spent 50 balance sheet value of 1.6 G bytes ($200 IBM 20Gb drive, y2k) $12 value of 50 hours programming ($100 per hour, y2k) $5000 net gain (loss) to society from the Zimm Buddism ("every byte is sacred"): ($4988) The 2nd millenium is over. Save programmers, not bytes. kryptoBunny Received: by ns.secondary.com (8.9.3/8.9.3) id AAA02070 for ietf-openpgp-bks; Thu, 20 Jul 2000 00:18:34 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA02059 for ; Thu, 20 Jul 2000 00:18:31 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB512D801B8; Thu, 20 Jul 2000 15:21:05 0800 Message-Id: <4.3.2.7.0.20000720141703.00b24500@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 15:10:14 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: dash escaped text and cleartext sig. q 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: To all, Just to clarify: If a cleartext signed message is sent to a recipient and the message body originally contained a "-" at the start of a line, would the recipient receive that same line prepended with a "- "? I am asking this because I have just received a message that has been cleartext signed using GnuPG 1.0.1, however there are whole lines of "-" in them and they are not received as "- -------------------..."??? Does anyone know what is going on here or, once again, have I missed something? TIA. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24181 for ietf-openpgp-bks; Wed, 19 Jul 2000 21:18:07 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24174 for ; Wed, 19 Jul 2000 21:18:05 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id VAA04221; Wed, 19 Jul 2000 21:19:04 -0700 Date: Wed, 19 Jul 2000 21:19:04 -0700 Message-Id: <200007200419.VAA04221@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: sig. subpacket & length conflicts? Cc: hal@finney.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron writes: > Maybe in a version 5 sig., simply make the signature subpacket length > definition packet equal to a two octet scalar - this would then marry with > the total length of all un/hashed subpackets and would also reduce the > amount of processing required to determine the length of a signature subpacket. Maybe so. We have had many complaints that the current variable-length packet-length mechanism is somewhat over-engineered for the purpose. Still, almost all subpackets are short enough that one byte is enough for the length, so you do save a few bytes by using the compressed length encoding. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id TAA17215 for ietf-openpgp-bks; Wed, 19 Jul 2000 19:29:56 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA17211 for ; Wed, 19 Jul 2000 19:29:54 -0700 (PDT) From: sen@eccosys.com Received: (qmail 22248 invoked from network); 20 Jul 2000 02:31:33 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jul 2000 02:31:33 -0000 To: ietf-openpgp@imc.org Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. In-Reply-To: <200007191635.JAA02429@finney.org> References: <200007191635.JAA02429@finney.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000720113245M.1001@eccosys.com> Date: Thu, 20 Jul 2000 11:32:45 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 22 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: hal@finney.org Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. Date: Wed, 19 Jul 2000 09:35:18 -0700 Message-ID: <200007191635.JAA02429@finney.org> > > that is, should the specification say: > > > > Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message > > > > or > > > > Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message > > The spec is correct; it is the latter. Signature packets have *always* > come at the front, since back in PGP 1.0. If you have seen messages > that were different (and not one-pass signed messages), you have seen > invalid messages. i think i must have been looking at a one-pass signed message. yes, it looks like that's what i did. sorry for that, and thanks for the clarification. Received: by ns.secondary.com (8.9.3/8.9.3) id TAA16750 for ietf-openpgp-bks; Wed, 19 Jul 2000 19:23:49 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA16746 for ; Wed, 19 Jul 2000 19:23:47 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 22221 invoked from network); 20 Jul 2000 02:25:25 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jul 2000 02:25:25 -0000 To: ietf-openpgp@imc.org Subject: Re: sig. subpacket & length conflicts? In-Reply-To: <200007191610.JAA02285@finney.org> References: <200007191610.JAA02285@finney.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000720112637A.1001@eccosys.com> Date: Thu, 20 Jul 2000 11:26:37 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 42 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: thanks for the response. From: hal@finney.org Subject: Re: sig. subpacket & length conflicts? Date: Wed, 19 Jul 2000 09:10:09 -0700 Message-ID: <200007191610.JAA02285@finney.org> > > to all: what's the verdict? > > The "verdict" is that there is a limit of 65535 on the length of each > of the hashed and unhashed segments. That's what the spec says, that's > what you do. Obviously this implies that each individual subpacket has > to be no larger than this. You can express the subpacket length using any > of the permitted encoding methods. There is no ambiguity that I can see. from a clarity perspective, i think it would be helpful to make a note in section 5.2.3.1 saying something like: "but note the length restriction imposed by the two octet scalar length specified in section 5.2.3". something like this text could appear directly after the following text: Each subpacket consists of a subpacket header and a body. The header consists of: - the subpacket length (1, 2, or 5 octets) - the subpacket type (1 octet) and is followed by the subpacket specific data. [ since Erron has asked about it, it seems to me that it isn't necessarily obvious in the absolute (if there is such a thing). i agree that it is obvious if you know which details to focus on when you are thinking about the matter. ] > The only "issue" was whether we might want to make a new signature version > in the future to hold larger subpackets, but the consensus seemed to be > that this would be a misuse of signature subpackets; such large amounts > of data should not be hidden within sigs, but should be expressed on > their own somewhere. thanks for the clarification. Received: by ns.secondary.com (8.9.3/8.9.3) id SAA14272 for ietf-openpgp-bks; Wed, 19 Jul 2000 18:55:06 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA14258 for ; Wed, 19 Jul 2000 18:55:05 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AF7C5B801E4; Thu, 20 Jul 2000 09:57:32 0800 Message-Id: <4.3.2.7.0.20000720094441.00ae91f0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 09:46:45 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: sig. subpacket & length conflicts? Cc: hal@finney.org In-Reply-To: <200007191610.JAA02285@finney.org> 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: Hal, At 09:10 AM 19/07/2000 -0700, hal@finney.org wrote: > > to all: what's the verdict? > >The "verdict" is that there is a limit of 65535 on the length of each >of the hashed and unhashed segments. That's what the spec says, that's >what you do. Obviously this implies that each individual subpacket has >to be no larger than this. You can express the subpacket length using any >of the permitted encoding methods. There is no ambiguity that I can see. > >The only "issue" was whether we might want to make a new signature version >in the future to hold larger subpackets, but the consensus seemed to be >that this would be a misuse of signature subpackets; such large amounts >of data should not be hidden within sigs, but should be expressed on >their own somewhere. Maybe in a version 5 sig., simply make the signature subpacket length definition packet equal to a two octet scalar - this would then marry with the total length of all un/hashed subpackets and would also reduce the amount of processing required to determine the length of a signature subpacket. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id SAA13760 for ietf-openpgp-bks; Wed, 19 Jul 2000 18:52:49 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA13751 for ; Wed, 19 Jul 2000 18:52:47 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AEEA5B201E4; Thu, 20 Jul 2000 09:55:06 0800 Message-Id: <4.3.2.7.0.20000720094139.00ae91f0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 20 Jul 2000 09:44:19 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. Cc: hal@finney.org In-Reply-To: <200007191635.JAA02429@finney.org> 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:35 AM 19/07/2000 -0700, hal@finney.org wrote: > > 2) Why would you need a One-Pass Signature Packet if we conform to 10.2 > and simply prepend a normal signature packet to the literal data with a > > subpacket of type 16 (key id), thus removing the need for a One-Pass > packet > > in the first place? > >This is so that the signer can process the message in one pass. >He doesn't know the hash until he comes to the end of the message, >so he can't compute the signature until that time. With the old-style >signature packets he would then have to go back to the beginning of the >message and put the sig there, preventing one-pass processing. Thanks Hal. Also looked at 2.1 and saw I assumed that "attached" meant "appended" - sorry for the wasted bandwidth. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id RAA04499 for ietf-openpgp-bks; Wed, 19 Jul 2000 17:55:39 -0700 (PDT) Received: from yahoo.com (216-164-132-57.s311.tnt2.lnhva.md.dialup.rcn.com [216.164.132.57]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA04429; Wed, 19 Jul 2000 17:55:29 -0700 (PDT) From: Subject: Tuition-Free Computer and IT Training for Non-Profit Employees Date: Wed, 19 Jul 2000 21:01:39 Message-Id: <447.455052.875471@yahoo.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: Tuition-Free Computer and IT Training for Non-Profit Employees Dear Non-Profit Employee, Most non-profit employees want to improve their computer skills. However, high cost of training and a busy schedule have held them back. Now, the National Education Foundation (NEF) CyberLearning, a non-profit organization, dedicated to bridging the "Digital Divide," offers the Nation's non-profit employees a unique opportunity. With the support of Microsoft and others, NEF CyberLearning is now able to offer full tuition scholarships of $2,000 to the first 10,000 applicants, thus enabling them to take any or all of the 400+ Internet-based online personal computing and computer professional courses from anywhere at any time. The high-quality, user-friendly courses are either self-study or instructor-led. They cover all levels and almost all topics, including Computer Basics, Internet Basics, Web Design Basics, Networking Basics, Programming Basics, A+, Network+, MCSE, CNE, Microsoft Office, MOUS, WordPerfect, Lotus, Operating Systems, Windows, Windows 2000, Linux, Unix, Networking, WAN, LAN, Programming, Java, C++, Visual Basics, Internet, Web Design, Web Applications, Web Master, E-commerce, Databases, Oracle and Cisco. To sign up, just visit www.cyberlearning.org, click on "Free IT Training," complete the application and pay a nominal registration fee of $75 with an organization/personal credit card. This $75 is your only cost, since the tuition is free for you. Many non-profit organizations reimburse the $75. You can receive immediate access to all 400+ online courses, an online library of the latest 1,000+ computer/information technology books, instructor assistance, course-specific chat areas and round the clock technical support. Please feel free to forward this information to interested colleagues and others in non-profit organizations. If your department or division wants to sign up a group of employees, please indicate so in your reply and provide contact information. If you received this e-mail, it is because you are listed as a contact person or employee of a non-profit organization. If you do not wish to receive any further scholarship information from us, please reply with the message, "remove" in the Subject line. Thank you. The non-profit National Education Foundation (NEF) CyberLearning has provided tuition-free IT training to thousands of students, teachers, government and non-profit employees and disadvantaged individuals. It has earned many distinctions including "The Ivy League of IT Training," "1995 Fairfax Human Rights Award Winner," and " A Leader in Bridging the Digital Divide." "You are helping to empower America. I salute you for your ongoing commitment to creating a better America," --- President Clinton "This is an awesome opportunity." --- Washingtonjobs.com "Microsoft is pleased to play a part ... NEF can make a positive difference in the lives of a great number of individuals." --- Microsoft "I have found the CyberLearning online courses to be extremely easy and useful. I liked pre-course self-assessment and IT books online and available 24/7. The course screens were interactive and made me feel as if I was in the application itself. The site looks and feels very professional. The list of courses is huge. It includes something for almost everyone. I find this to be a very worthy cause." --- Ken Horowitz, IT Training Coordinator. Received: by ns.secondary.com (8.9.3/8.9.3) id OAA23467 for ietf-openpgp-bks; Wed, 19 Jul 2000 14:59:37 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA23463 for ; Wed, 19 Jul 2000 14:59:36 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA23391; Wed, 19 Jul 2000 15:02:09 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA23387; Wed, 19 Jul 2000 15:02:08 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000719162830J.1001@eccosys.com> References: <3970A977.D1FA0F2F@woudt.nl> <20000719162830J.1001@eccosys.com> Date: Wed, 19 Jul 2000 14:38:42 -0700 To: sen_ml@eccosys.com, ietf-openpgp@imc.org From: Jon Callas Subject: Re: Signature Subpacket format questions Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 4:28 PM +0900 7/19/00, sen_ml@eccosys.com wrote: >since there does not appear to be any mention of null-termination in >the section on text (3.4), i interpreted "String" to mean that there >is no null-termination. [ also because many of the field boundaries >can be determined by various lengths that are explicitly spelled out >as well as length definitions. ] > You're correct -- there's no null termination on any of the strings. Jon Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id JAA15340 for ietf-openpgp-bks; Wed, 19 Jul 2000 09:34:10 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15336 for ; Wed, 19 Jul 2000 09:34:09 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA02429; Wed, 19 Jul 2000 09:35:18 -0700 Date: Wed, 19 Jul 2000 09:35:18 -0700 Message-Id: <200007191635.JAA02429@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > that is, should the specification say: > > Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message > > or > > Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message The spec is correct; it is the latter. Signature packets have *always* come at the front, since back in PGP 1.0. If you have seen messages that were different (and not one-pass signed messages), you have seen invalid messages. With regard to Erron Criddle's earlier question: > To me, "attached" (as in 2.1 and 2.2) means you add it to the end of > something and this contradicts 10.2 explanation of a Signed Message (a > signed message implies that it is prepended, not attached). Not to me. That word would be "appended". "Attached" is not meant to imply any ordering. 2.1 and 2.2 are meant to give a very rough overview of the steps involved in creating an OpenPGP message, not to be a detailed specification of the process. That is for the rest of the document. > By reading section 10.2, it seems that there are two possibilities for > signing a literal message: > > 1) You create a signature packet then prepend it to the literal packet > > 2) You create a signature packet and a One-Pass Signature Packet then > prepend the One-Pass packet to the literal packet and append the signature > packet to the literal packet. > > Therefore, my final questions are: > > 1) Can you create a simple signature packet and attach it to the end of a > literal packet as stated in 2.1 and 2.2 and subsequently contradict 10.2 > regarding the definition of a signed message and: 2.1 and 2.2 don't say that, and you can't do this. > 2) Why would you need a One-Pass Signature Packet if we conform to 10.2 and > simply prepend a normal signature packet to the literal data with a > subpacket of type 16 (key id), thus removing the need for a One-Pass packet > in the first place? This is so that the signer can process the message in one pass. He doesn't know the hash until he comes to the end of the message, so he can't compute the signature until that time. With the old-style signature packets he would then have to go back to the beginning of the message and put the sig there, preventing one-pass processing. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id JAA14566 for ietf-openpgp-bks; Wed, 19 Jul 2000 09:08:59 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA14562 for ; Wed, 19 Jul 2000 09:08:58 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA02285; Wed, 19 Jul 2000 09:10:09 -0700 Date: Wed, 19 Jul 2000 09:10:09 -0700 Message-Id: <200007191610.JAA02285@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: sig. subpacket & length conflicts? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > to all: what's the verdict? The "verdict" is that there is a limit of 65535 on the length of each of the hashed and unhashed segments. That's what the spec says, that's what you do. Obviously this implies that each individual subpacket has to be no larger than this. You can express the subpacket length using any of the permitted encoding methods. There is no ambiguity that I can see. The only "issue" was whether we might want to make a new signature version in the future to hold larger subpackets, but the consensus seemed to be that this would be a misuse of signature subpackets; such large amounts of data should not be hidden within sigs, but should be expressed on their own somewhere. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id CAA17875 for ietf-openpgp-bks; Wed, 19 Jul 2000 02:50:53 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA17871 for ; Wed, 19 Jul 2000 02:50:50 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 11579 invoked from network); 19 Jul 2000 09:52:28 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 09:52:28 -0000 To: ietf-openpgp@imc.org Subject: Re: sig. subpacket & length conflicts? In-Reply-To: <4.3.2.7.0.20000719172727.00b3f418@mail.comasp.com> References: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> <20000719172936N.1001@eccosys.com> <4.3.2.7.0.20000719172727.00b3f418@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719185337O.1001@eccosys.com> Date: Wed, 19 Jul 2000 18:53:37 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 43 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: Re: sig. subpacket & length conflicts? Date: Wed, 19 Jul 2000 17:33:22 +0800 Message-ID: <4.3.2.7.0.20000719172727.00b3f418@mail.comasp.com> > > also, in section 5.2.3.1, it is explicitly pointed > >out that the subpacket length is: > > > > similar to the "new" format packet header lengths > > > >and since 5.2.3 itself didn't mention anything, i didn't think to > >interpret "two-octet scalar" as similar to the "new" format packet > >header length. > > > >to all: is this interpretation (0 - 255) correct? > > Actually, a two octet scalar is equal to a maximum length of 65535 bytes. ack, duh! silly me. i must have been asleep when writing ;-) thanks for pointing that out. > > > So, do we limit the subpacket length to two bytes or redefine that > > > maximum allowed total length for all subpackets (of type hashable or > > > unhashable) as 0xFFFFFFFF ( up to 5 bytes)? > > > >my guess would be that although you can express length of over 255 (or > >8383, whichever is correct) using 2 or 5 octets, that you don't do so > >in practice in this context. if that interpretation is correct, > >perhaps a note pointing this out in the text would be helpful for > >future readers. > > From reading the archive, it looks like this is known - that the total of > the un/hashed subpackets is a maximum of 65535 bytes and that each > subpacket can have a max length of 0xFFFFFFFF. > > I didn't find a final decision on this issue though, however I think I did > see mention of a version 5.0 signature solving this "minor" problem. I > suppose the practical thing to do is NOT use extremely large subpackets (of > which I don't think we will anyway :) hmmm, so no resolution yet. to all: what's the verdict? Received: by ns.secondary.com (8.9.3/8.9.3) id CAA16656 for ietf-openpgp-bks; Wed, 19 Jul 2000 02:41:59 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA16639 for ; Wed, 19 Jul 2000 02:41:56 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AB597080256; Wed, 19 Jul 2000 17:44:09 0800 Message-Id: <4.3.2.7.0.20000719172727.00b3f418@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 17:33:22 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: sig. subpacket & length conflicts? Cc: sen_ml@eccosys.com In-Reply-To: <20000719172936N.1001@eccosys.com> References: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> <4.3.2.7.0.20000719153136.00b34610@mail.comasp.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:29 PM 19/07/2000 +0900, sen_ml@eccosys.com wrote: >i took "Two-octet scalar octet count" in section 5.2.3 to mean 0 to 255, >as the text says: > > - Two-octet scalar octet count for following hashed subpacket > data. Note that this is the length in octets of all of the > hashed subpackets; a pointer incremented by this number will > skip over the hashed subpackets. > >i took the word "scalar" to mean that i should think about section 3.1 >(Scalar numbers). Duh...yes, you are right regarding scalars - I must have been asleep when reading the doc once again. > also, in section 5.2.3.1, it is explicitly pointed >out that the subpacket length is: > > similar to the "new" format packet header lengths > >and since 5.2.3 itself didn't mention anything, i didn't think to >interpret "two-octet scalar" as similar to the "new" format packet >header length. > >to all: is this interpretation (0 - 255) correct? Actually, a two octet scalar is equal to a maximum length of 65535 bytes. > > So, do we limit the subpacket length to two bytes or redefine that > > maximum allowed total length for all subpackets (of type hashable or > > unhashable) as 0xFFFFFFFF ( up to 5 bytes)? > >my guess would be that although you can express length of over 255 (or >8383, whichever is correct) using 2 or 5 octets, that you don't do so >in practice in this context. if that interpretation is correct, >perhaps a note pointing this out in the text would be helpful for >future readers. From reading the archive, it looks like this is known - that the total of the un/hashed subpackets is a maximum of 65535 bytes and that each subpacket can have a max length of 0xFFFFFFFF. I didn't find a final decision on this issue though, however I think I did see mention of a version 5.0 signature solving this "minor" problem. I suppose the practical thing to do is NOT use extremely large subpackets (of which I don't think we will anyway :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id BAA11469 for ietf-openpgp-bks; Wed, 19 Jul 2000 01:26:53 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA11463 for ; Wed, 19 Jul 2000 01:26:50 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 10152 invoked from network); 19 Jul 2000 08:28:27 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 08:28:27 -0000 To: ietf-openpgp@imc.org Subject: Re: sig. subpacket & length conflicts? In-Reply-To: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> References: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719172936N.1001@eccosys.com> Date: Wed, 19 Jul 2000 17:29:36 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: sig. subpacket & length conflicts? Date: Wed, 19 Jul 2000 15:38:46 +0800 Message-ID: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> > As stated in 5.2.3.1, signature subpackets can contain lengths up to > 0xFFFFFFFF, however the maximum length as defined for ALL hashable (or > unhashable) subpackets is a maximum of 8383 bytes (as indicated by a two > octet scalar). i took "Two-octet scalar octet count" in section 5.2.3 to mean 0 to 255, as the text says: - Two-octet scalar octet count for following hashed subpacket data. Note that this is the length in octets of all of the hashed subpackets; a pointer incremented by this number will skip over the hashed subpackets. i took the word "scalar" to mean that i should think about section 3.1 (Scalar numbers). also, in section 5.2.3.1, it is explicitly pointed out that the subpacket length is: similar to the "new" format packet header lengths and since 5.2.3 itself didn't mention anything, i didn't think to interpret "two-octet scalar" as similar to the "new" format packet header length. to all: is this interpretation (0 - 255) correct? > So, do we limit the subpacket length to two bytes or redefine that > maximum allowed total length for all subpackets (of type hashable or > unhashable) as 0xFFFFFFFF ( up to 5 bytes)? my guess would be that although you can express length of over 255 (or 8383, whichever is correct) using 2 or 5 octets, that you don't do so in practice in this context. if that interpretation is correct, perhaps a note pointing this out in the text would be helpful for future readers. Received: by ns.secondary.com (8.9.3/8.9.3) id AAA10184 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:47:17 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA10176 for ; Wed, 19 Jul 2000 00:47:12 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A07D2AF0182; Wed, 19 Jul 2000 15:49:33 0800 Message-Id: <4.3.2.7.0.20000719153136.00b34610@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 15:38:46 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: sig. subpacket & length conflicts? 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: To all, I think I have found another area that *may* be contradictory. Regarding V4 sigs the two octet scalar octet count for hashable and unhashable packets conflicts with the signature subpacket lengths. As stated in 5.2.3.1, signature subpackets can contain lengths up to 0xFFFFFFFF, however the maximum length as defined for ALL hashable (or unhashable) subpackets is a maximum of 8383 bytes (as indicated by a two octet scalar). So, do we limit the subpacket length to two bytes or redefine that maximum allowed total length for all subpackets (of type hashable or unhashable) as 0xFFFFFFFF ( up to 5 bytes)? TIA. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09913 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:38:47 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09909 for ; Wed, 19 Jul 2000 00:38:45 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 9318 invoked from network); 19 Jul 2000 07:40:22 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:40:22 -0000 To: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: References: <200007101810.LAA11952@finney.org> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719164134K.1001@eccosys.com> Date: Wed, 19 Jul 2000 16:41:34 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: "L. Sassaman" Subject: Re: Question regarding 2440:5.2.3.16 Date: Mon, 10 Jul 2000 11:29:05 -0700 (PDT) Message-ID: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 10 Jul 2000 hal@finney.org wrote: > > > That seems OK, or perhaps you could use an SSL (TLS) session using the > > PGP key to authenticate the client. In any case I don't think this > > mechanism should be documented in 2440. > > That's fine, but I do think that this definately needs to be > documented. If 2440 isn't the place, then we need to start work on a > keyserver draft. have you started a draft? Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA09884 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:38:16 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09879 for ; Wed, 19 Jul 2000 00:38:13 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 9310 invoked from network); 19 Jul 2000 07:39:50 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:39:50 -0000 To: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: References: <20000710123746Y.1001@eccosys.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719164101S.1001@eccosys.com> Date: Wed, 19 Jul 2000 16:41:01 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 80 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sorry for the horribly slow response. From: "L. Sassaman" Subject: Re: Question regarding 2440:5.2.3.16 Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT) Message-ID: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Mon, 10 Jul 2000 sen_ml@eccosys.com wrote: > > > so you are suggesting that proof of ownership of the corresponding > > secret key (via an appropriate signature) should server this purpose, > > right? > > Yes, because the owner needs to prove he has the secret key, and the > public key block that is to be added must be signed to prevent > unauthorized signatures being added during this process. sure, i was just making sure i followed your statements. > > > Werner Koch and I have been discussing this, and he suggests that we put > > > it into a clear-text signature packet. Would that be suitable? > > > > would you mind briefly describing the steps involved for the mechanism > > you are considering (in terms like "first, the client connects to the > > server. then the server responds w/..." etc.)? > > > > [ i understand what you are saying about the form a signature would > > take, but i don't see the overall flow of the process of > > authentication. ] > > The client takes the public key block, signs it, and submits this signed > blob to the server. The server then verifies the signature, trims away > that signature, and adds the key. thanks for the explanation. > Keys that are added unsigned should always be checked for the existance of > the "no-modify" flag, and rejected if it exists. > > Furthermore, I suggest that we have a "modify" flag added to the spec, so > that, if a signature is made at a later date containing this flag, it > would superceed a preveous no-modify. But that digresses from this > discussion. that makes sense. > > also, is it necessary to consider replay attacks for this kind of > > scenario? alternatively, would the following scenario be of any concern: > > > > an attacker captures a session between a user and a keyserver at some > > point in time. later, after the user has made several updates to the > > keyserver, the attacker replays the captured session to set the > > state of the user's key to an earlier state. > > This scenerio is only partially valid. A signed key that is added to a > server does not remove the previous key and replace it with the new > one. It is treated like and other add, and is merged with the existing > key. So, an attacker could not truly set the key to a previous state. is there a reason why it is not replacement? from the standpoint of a user, i think i prefer replacement as that goes along w/ being able to delete. > What an attacker *could* do, via a replay attack, is re-add signatures or > user-ids to a key on the server that the owner had later deleted. I see > this as a minor annoyance, rather than an attack, so I don't think that we > need to address it. (Though we could, through the use of server tokens or > timestamps, etc. I just think it is more work than is necessary.) i guess i'd prefer to have the ability to delete things and then not have other people be able to add things back later. whether the annoyance is minor or major is in the eye of the beholder, imo. i don't consider it minor. i would prefer to have a timestamp / server token kind of a set-up. if some people don't care about this and others do, i suppose it could also be expressed as policy as part of a user's key. Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09384 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:29:42 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09375 for ; Wed, 19 Jul 2000 00:29:37 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 9189 invoked from network); 19 Jul 2000 07:31:14 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:31:14 -0000 To: ietf-openpgp@imc.org Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. In-Reply-To: <20000710154438W.1001@eccosys.com> References: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> <20000710154438W.1001@eccosys.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719163226I.1001@eccosys.com> Date: Wed, 19 Jul 2000 16:32:26 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 12 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: i didn't see any other responses to this thread. was there a verdict on this issue? that is, should the specification say: Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message or Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message ? Received: by ns.secondary.com (8.9.3/8.9.3) id AAA09109 for ietf-openpgp-bks; Wed, 19 Jul 2000 00:26:05 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA09097 for ; Wed, 19 Jul 2000 00:25:57 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 9097 invoked from network); 19 Jul 2000 07:27:25 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jul 2000 07:27:25 -0000 To: ietf-openpgp@imc.org Subject: Re: Signature Subpacket format questions In-Reply-To: <3970A977.D1FA0F2F@woudt.nl> References: <3970A977.D1FA0F2F@woudt.nl> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000719162830J.1001@eccosys.com> Date: Wed, 19 Jul 2000 16:28:30 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 31 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Edwin Woudt Subject: Signature Subpacket format questions Date: Sat, 15 Jul 2000 14:12:07 -0400 Message-ID: <3970A977.D1FA0F2F@woudt.nl> > While implementing V4 signature support for a Java OpenPGP library, I > encountered a few things with some Signature Subpackets that were not > immediately clear to me. I would be very grateful if someone could > answer these questions: i wouldn't take the following as definitive answers, but here's some feedback anyway. > * The format specified for both 5.2.3.18. 'Preferred key server' and > 5.2.3.20. 'Policy URL' is 'String'. Is this string terminated by a > null value, like 5.2.3.14. 'Regular expression', or not? since there does not appear to be any mention of null-termination in the section on text (3.4), i interpreted "String" to mean that there is no null-termination. [ also because many of the field boundaries can be determined by various lengths that are explicitly spelled out as well as length definitions. ] > * What is the format for 5.2.3.22. 'Signer's User ID'? A String like in > the previous question? i interpreted this to refer to what is stored in the body of a user id packet (5.11) -- so, if the contents of the body are text, it's encoded in utf-8. since 5.11 doesn't really say much about non-text, i don't know about that case ;-) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA19994 for ietf-openpgp-bks; Tue, 18 Jul 2000 18:59:35 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id SAA19983 for ; Tue, 18 Jul 2000 18:59:31 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AEFF5F00216; Wed, 19 Jul 2000 10:01:51 0800 Message-Id: <4.3.2.7.0.20000719094751.00b42ab0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 19 Jul 2000 09:51:06 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: CFB Mode correction in 12.8? Cc: Jon Callas In-Reply-To: References: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.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 01:22 PM 18/07/2000 -0700, Jon Callas wrote: >At 1:40 PM +0800 7/18/00, Erron Criddle wrote: > > >FROM: > > > >10) FR is loaded with C11 to C18 > > > >TO: > > > >10) FR is loaded with C[BS+3] to C[BS + (BS+2)] > > > >I changed it to: > >FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an >8-octet block). > >I think this addresses all the concerns? Yes - the more well defined the RFC is, the easier it will be for others to understand in the future. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id NAA08055 for ietf-openpgp-bks; Tue, 18 Jul 2000 13:48:19 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA08051 for ; Tue, 18 Jul 2000 13:48:18 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id NAA07706; Tue, 18 Jul 2000 13:50:16 -0700 (PDT) Received: from [63.73.97.186] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id NAA07702; Tue, 18 Jul 2000 13:50:14 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> References: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> Date: Tue, 18 Jul 2000 13:22:48 -0700 To: Erron Criddle , ietf-openpgp@imc.org From: Jon Callas Subject: Re: CFB Mode correction in 12.8? Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:40 PM +0800 7/18/00, Erron Criddle wrote: >FROM: > >10) FR is loaded with C11 to C18 > >TO: > >10) FR is loaded with C[BS+3] to C[BS + (BS+2)] > I changed it to: FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for an 8-octet block). I think this addresses all the concerns? Thanks. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id IAA23398 for ietf-openpgp-bks; Tue, 18 Jul 2000 08:01:25 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA23385 for ; Tue, 18 Jul 2000 08:01:23 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id LAA08281; Tue, 18 Jul 2000 11:03:44 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id LAA15925; Tue, 18 Jul 2000 11:03:02 -0400 Date: Tue, 18 Jul 2000 11:03:02 -0400 From: Tom Zerucha To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: CFB Mode correction in 12.8? Message-ID: <20000718110302.A15919@deimos.mw.mediaone.net> References: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com>; from ejc@comasp.com on Tue, Jul 18, 2000 at 01:40:26PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Jul 18, 2000 at 01:40:26PM +0800, Erron Criddle wrote: > To all, > > Regarding previous posts and block sizes etc etc, should 12.8 (part 10) read: > > FROM: > > 10) FR is loaded with C11 to C18 > > TO: > > 10) FR is loaded with C[BS+3] to C[BS + (BS+2)] Yes and no. The earlier paragraph (the third one in the section) explains about block sizes <> 8 bytes. It should say that the procedure/example is using an 8 byte cipher, and perhaps note your modification to 10 above. If you describe everything (in this case examples) with mathematical equations that are correct in all situations, the spec becomes even harder to understand. The exact details are described precisely elsewhere, but because of that complexity this section attempts to explain it more like pseudocode. I am not adverse to any adjustment, but I would prefer it in the form of footnotes or parenthesis just to keep the instructions simpler. Received: by ns.secondary.com (8.9.3/8.9.3) id CAA04499 for ietf-openpgp-bks; Tue, 18 Jul 2000 02:36:55 -0700 (PDT) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA04495 for ; Tue, 18 Jul 2000 02:36:53 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialup20.ip.lu [208.161.253.20]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id LAA05257 for ; Tue, 18 Jul 2000 11:39:16 +0200 (CEST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id CD3642F032; Tue, 18 Jul 2000 11:39:14 +0200 (CEST) Date: Tue, 18 Jul 2000 11:39:14 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: PGP/MIME: encoding restrictions. Message-ID: <20000718113914.B14695@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> <20000716123000.A26892@sobolev.does-not-exist.org> <7aMvAWASiBd5IAKr@turnpike.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.5i In-Reply-To: <7aMvAWASiBd5IAKr@turnpike.com>; from ianbell@turnpike.com on Tue, Jul 18, 2000 at 09:42:58AM +0100 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-07-18 09:42:58 +0100, Ian Bell wrote: > For example, in draft-ietf-usefor-article-02 (USEFOR) > it says "Posting agents SHOULD NOT use the encoding > method quoted-printable". Since USEFOR articles will > usually contain trailing whitespace (personal > signatures MUST be delimited by "-- "), clients will be > unable to post RFC2015bis articles to UseNet without > breaking one RFC or another. If you happen to be on the USEFOR list, it would be nice if you could ask them to add an exception for cryptographically signed messages just like the one in the "text/plain; format=flowed" RFC. After all, a restriction like the one you quote only makes sense in a context where MIME is avoided. People using multipart/signed bother recipients with MIME anyway, so the content-transfer-encoding of the text transmitted isn't really an issue any more. -- Thomas Roessler Received: by ns.secondary.com (8.9.3/8.9.3) id BAA02089 for ietf-openpgp-bks; Tue, 18 Jul 2000 01:42:51 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA02083 for ; Tue, 18 Jul 2000 01:42:49 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id JAA14223; Tue, 18 Jul 2000 09:45:12 +0100 (BST) Message-ID: <7aMvAWASiBd5IAKr@turnpike.com> Date: Tue, 18 Jul 2000 09:42:58 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME: encoding restrictions. References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> <20000716123000.A26892@sobolev.does-not-exist.org> In-Reply-To: <20000716123000.A26892@sobolev.does-not-exist.org> MIME-Version: 1.0 X-Mailer: Turnpike Integrated Version 5.01 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 16 Jul 2000, Thomas Roessler wrote: >On 2000-05-11 09:44:28 +0100, Ian Bell wrote: > >> Should the issue of binary versus text-mode signatures >> be addressed? > >It should, and I believe the following would be the most >robust solution: > >(1) require clients to create text mode signatures >(2) require clients to use either quoted-printable or > base64 for any body parts which contain trailing > whitespace. > >Note that this seems to be what most clients do anyway at >present. [snip rationale] This also satisfies the design objective of RFC1847 for single-pass processing of the hashes (whether or not there are clients that rely on that) without inventing new parameters. I would suggest: clients MUST create text mode signature though clients MAY verify binary-mode signatures However, I'm not so sure about (2). At most: clients SHOULD use qp or base64 whenever there is significant white space (i.e. _not_ MUST). The cost of not using qp is that trailing whitespace is not protected, but if clients have "good" reasons for not using qp they should be allowed to consider that option. For example, in draft-ietf-usefor-article-02 (USEFOR) it says "Posting agents SHOULD NOT use the encoding method quoted-printable". Since USEFOR articles will usually contain trailing whitespace (personal signatures MUST be delimited by "-- "), clients will be unable to post RFC2015bis articles to UseNet without breaking one RFC or another. -- Ian Bell T U R N P I K E Ltd Received: by ns.secondary.com (8.9.3/8.9.3) id WAA21141 for ietf-openpgp-bks; Mon, 17 Jul 2000 22:48:58 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA21136 for ; Mon, 17 Jul 2000 22:48:55 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A33D51702A2; Tue, 18 Jul 2000 13:51:09 0800 Message-Id: <4.3.2.7.0.20000718133448.00b27bb0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 18 Jul 2000 13:40:26 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: CFB Mode correction in 12.8? 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: To all, Regarding previous posts and block sizes etc etc, should 12.8 (part 10) read: FROM: 10) FR is loaded with C11 to C18 TO: 10) FR is loaded with C[BS+3] to C[BS + (BS+2)] Cheers. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27817 for ietf-openpgp-bks; Mon, 17 Jul 2000 17:22:34 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27813 for ; Mon, 17 Jul 2000 17:22:34 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA26208; Mon, 17 Jul 2000 17:23:43 -0700 (PDT) Received: from [63.73.97.183] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA26204; Mon, 17 Jul 2000 17:23:43 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000717190749.A16084@deimos.mw.mediaone.net> References: <200007171632.JAA31966@finney.org> <20000717190749.A16084@deimos.mw.mediaone.net> Date: Mon, 17 Jul 2000 17:23:35 -0700 To: Tom Zerucha , hal@finney.org From: Jon Callas Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Cc: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:07 PM -0400 7/17/00, Tom Zerucha wrote: >3.6.2.1... > > These are followed by an 8-octet Initial Vector for the decryption of > the secret values, if they are encrypted, and then the secret key > values themselves. > Also fixed. Thank you, folks. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id RAA27709 for ietf-openpgp-bks; Mon, 17 Jul 2000 17:19:59 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA27705 for ; Mon, 17 Jul 2000 17:19:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id RAA26176; Mon, 17 Jul 2000 17:21:51 -0700 (PDT) Received: from [63.73.97.183] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id RAA26172; Mon, 17 Jul 2000 17:21:49 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> References: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> Date: Mon, 17 Jul 2000 17:21:28 -0700 To: "Michael Young" , From: Jon Callas Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:30 AM -0400 7/17/00, Michael Young wrote: >This should now read "an IV of the same length as the cipher block"? > Fixed. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id QAA26320 for ietf-openpgp-bks; Mon, 17 Jul 2000 16:35:35 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA26316 for ; Mon, 17 Jul 2000 16:35:27 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA01170; Mon, 17 Jul 2000 16:37:39 -0700 Date: Mon, 17 Jul 2000 16:37:39 -0700 Message-Id: <200007172337.QAA01170@finney.org> To: hal@finney.org, tz@execpc.com Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Cc: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Do you do the CFB resets on MPI boundaries with V3 keys? Yes. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id QAA25628 for ietf-openpgp-bks; Mon, 17 Jul 2000 16:06:03 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA25624 for ; Mon, 17 Jul 2000 16:06:02 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id TAA26169; Mon, 17 Jul 2000 19:08:16 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id TAA16183; Mon, 17 Jul 2000 19:07:49 -0400 Date: Mon, 17 Jul 2000 19:07:49 -0400 From: Tom Zerucha To: hal@finney.org Cc: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Message-ID: <20000717190749.A16084@deimos.mw.mediaone.net> References: <200007171632.JAA31966@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200007171632.JAA31966@finney.org>; from hal@finney.org on Mon, Jul 17, 2000 at 09:32:05AM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Jul 17, 2000 at 09:32:05AM -0700, hal@finney.org wrote: > > From owner-ietf-openpgp@mail.imc.org Mon Jul 17 06:29:39 2000 > > From: "Michael Young" > > Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 > > > > Yes, I meant Twofish, not Blowfish. > > > > The draft I found at imc.org still says in section 5.5.3: > > > - [Optional] If secret data is encrypted, eight-octet Initial > > > Vector (IV). > > > > This should now read "an IV of the same length as the cipher block"? > > I suppose so. And... 3.6.2.1... These are followed by an 8-octet Initial Vector for the decryption of the secret values, if they are encrypted, and then the secret key values themselves. Do you do the CFB resets on MPI boundaries with V3 keys? (I asked about this in an earlier post noting all the places where the PGP-CFB and the reset were done - I'll see if I can easily repost it). Received: by ns.secondary.com (8.9.3/8.9.3) id JAA18076 for ietf-openpgp-bks; Mon, 17 Jul 2000 09:29:55 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA18068 for ; Mon, 17 Jul 2000 09:29:53 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id JAA31966; Mon, 17 Jul 2000 09:32:05 -0700 Date: Mon, 17 Jul 2000 09:32:05 -0700 Message-Id: <200007171632.JAA31966@finney.org> To: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From owner-ietf-openpgp@mail.imc.org Mon Jul 17 06:29:39 2000 > From: "Michael Young" > To: > Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 > Date: Mon, 17 Jul 2000 08:30:50 -0400 > X-Priority: 3 > X-MSMail-Priority: Normal > X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 > List-Archive: > List-ID: > > Yes, I meant Twofish, not Blowfish. > > The draft I found at imc.org still says in section 5.5.3: > > - [Optional] If secret data is encrypted, eight-octet Initial > > Vector (IV). > > This should now read "an IV of the same length as the cipher block"? I suppose so. > [Is there a more recent draft than that posted at imc.org? That one > claims to expire June 2000.] I don't know. > As Werner Koch pointed out last year, this will require an implementation > to know the block size simply in order to parse the rest of the packet. > Given that the only material after the IV is the encrypted part, and thus > won't be readable anyway without support for that cipher, I suppose this > isn't all that serious. But is there any intention to make the IV size > self-describing for future ciphers, or is this the final plan? We already have this problem, because StringToKey structures also do not have their length self-describing. Hitting an unknown S2K identifier leaves you in the same boat. Luckily it never matters, as in all cases, there is nothing left in the packet to parse if you don't know how to decode it. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id IAA17225 for ietf-openpgp-bks; Mon, 17 Jul 2000 08:47:43 -0700 (PDT) Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA17221 for ; Mon, 17 Jul 2000 08:47:41 -0700 (PDT) Received: from A1ba8.pppool.de (A1ba8.pppool.de [213.6.27.168]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id RAA17212; Mon, 17 Jul 2000 17:49:53 +0200 (MET DST) Date: Mon, 17 Jul 2000 14:38:42 +0200 From: Marcel Zamzow X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Marcel Zamzow X-Priority: 3 (Normal) Message-ID: <15610.000717@zamzow.de> To: "L. Sassaman" Subject: Re[2]: VPN Systems via OpenPGP In-reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hello! Friday, July 14, 2000, 11:51:07 PM, you wrote: LS> Both FreeS/WAN and the OpenBSD IPsec products are open sourced. Does your LS> project require you to start from scratch, or could you take a LS> pre-existing VPN system and integrate OpenPGP into it? Well, I think I'll first have a close look to those products, but generally I'd like to do it the hard way . My aim isn´t a complete end-user software-package, but instead a nice technology-study. But encryption should already be performed on the tcp/ip level. Best regards, Marcel - --- /* Marcel Zamzow, student of Computer Science [University of Applied Sciences Iserlohn] homepage : http://www.zamzow.de mailto : marcel@zamzow.de */ -----BEGIN PGP SIGNATURE----- iQIVAwUAOXL+DfPorQ0Gk425AQF4uw/9F+JZgG7tdBKbKR5wX1a8ydfuhXVfWMjh hy+btzFb8ZR5RSWJ7Xlt+I21sSFtYhgiJzT4NDdDfjoT32aEMnptv5vS2XQjousf 99GndPmXLVvOcsPYt6+Y8Z6DR2ilKAOYKxw4scNFmSuzkoKLN1TrDDCPDJB6D2YS bLhKBE+9GZtztt9j9PO7j2DjwjutyGKlymlfZzOPuW74CrGpYODdXf0VqQEp56DF Svt7xdyWtnDVCYeP96oWH1aCyz8U7Eafuk7j2G0j//LNAYPBuAVtdJHvCeELAV/e 9EQyRndUwyJ7Bz6rp8cv0sQT+3ikc+9IImmSzTjq9t8J9axXhAwRZIT4ZM4//nF0 O6c4UYUFSsj/wOBc8uETVXnEwH0xOVg/UEks+k3NZxxUFiFY3IkK4Ug6xnVyBoPH WhbS2nG6NxAiIg+0Nvntz37r/JZWw+Km47HzS26kneJ4idT5vccukVEByrJMtQEi jTXRpgV1sleh8dSqtSZLu9zKC4ukWskFXvFhpYRch6KmPNeornGPlLAGICrgnSER GPOxvW40763jwjW/YNs34fVynR5zVEnM+absFpUf6JSD/lqx9psHGY02mTpS3wOu X7s3iH5XtxsRH14pdohw+em1igMl2OSDizv4f4x3+KDEwURMjzohzP7PDhg2LYpy TULaBkjD8NE= =ZX+L -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14402 for ietf-openpgp-bks; Mon, 17 Jul 2000 06:52:30 -0700 (PDT) Received: from dfw7-1.relay.mail.uu.net (dfw7-1.relay.mail.uu.net [199.171.54.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14398 for ; Mon, 17 Jul 2000 06:52:29 -0700 (PDT) Received: from xedia.com by dfw7sosrv11.alter.net with SMTP (peer crosschecked as: madway.xedia.com [198.202.232.199]) id QQiyfv03549; Mon, 17 Jul 2000 13:54:45 GMT Received: from tonga.xedia.com by xedia.com (4.1/SMI-4.1) id AA08232; Mon, 17 Jul 00 09:50:52 EDT Received: by tonga.xedia.com (SMI-8.6/SMI-SVR4) id JAA11050; Mon, 17 Jul 2000 09:54:44 -0400 From: Paul Koning Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <14707.4132.556781.464112@xedia.com> Date: Mon, 17 Jul 2000 09:54:44 -0400 (EDT) To: mwy-opgp97@the-youngs.org Cc: ietf-openpgp@imc.org Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 References: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> X-Mailer: VM 6.72 under 21.1 (patch 9) "Canyonlands" XEmacs Lucid Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>>>> "Michael" == Michael Young writes: Michael> Yes, I meant Twofish, not Blowfish. The draft I found at Michael> imc.org still says in section 5.5.3: >> - [Optional] If secret data is encrypted, eight-octet Initial >> Vector (IV). Michael> This should now read "an IV of the same length as the cipher Michael> block"? Clearly yes. The IV always must be the same size as the blocksize for any block cipher. Michael> As Werner Koch pointed out last year, this will require an Michael> implementation to know the block size simply in order to Michael> parse the rest of the packet. Given that the only material Michael> after the IV is the encrypted part, and thus won't be Michael> readable anyway without support for that cipher, I suppose Michael> this isn't all that serious. But is there any intention to Michael> make the IV size self-describing for future ciphers, or is Michael> this the final plan? Can't see any reason to change that. You only need to know the IV if you're going to decrypt. And to do that clearly you must know the cipher, which includes knowing its blocksize. If you're not going to decrypt, you might as well consider the IV as part of the encrypted message, since it doesn't contain any interesting information. paul Received: by ns.secondary.com (8.9.3/8.9.3) id GAA14018 for ietf-openpgp-bks; Mon, 17 Jul 2000 06:28:03 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA14013 for ; Mon, 17 Jul 2000 06:28:01 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13EBG5-0002fu-00; Mon, 17 Jul 2000 15:48:33 +0200 Date: Mon, 17 Jul 2000 15:48:33 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Message-ID: <20000717154833.F9590@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com>; from mwy-opgp97@the-youngs.org on Mon, Jul 17, 2000 at 08:30:50AM -0400 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 17 Jul 2000, Michael Young wrote: > The draft I found at imc.org still says in section 5.5.3: > > - [Optional] If secret data is encrypted, eight-octet Initial > > Vector (IV). > > This should now read "an IV of the same length as the cipher block"? 5.7. got it right. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id FAA12955 for ietf-openpgp-bks; Mon, 17 Jul 2000 05:33:23 -0700 (PDT) Received: from alpha.pit.adelphia.net (alpha.pit.adelphia.net [24.48.44.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA12950 for ; Mon, 17 Jul 2000 05:33:21 -0700 (PDT) Received: from mwyoung.transarc.com (pa-bethelpark1b-76.pit.adelphia.net [24.48.158.76]) by alpha.pit.adelphia.net (8.9.2/8.9.2) with SMTP id IAA24095 for ; Mon, 17 Jul 2000 08:35:41 -0400 (EDT) Message-ID: <003a01bfefea$d87e3a00$023fa8c0@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: Resolution on large-block ciphers (e.g., TWOFISH), PGP7 Date: Mon, 17 Jul 2000 08:30:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, I meant Twofish, not Blowfish. The draft I found at imc.org still says in section 5.5.3: > - [Optional] If secret data is encrypted, eight-octet Initial > Vector (IV). This should now read "an IV of the same length as the cipher block"? [Is there a more recent draft than that posted at imc.org? That one claims to expire June 2000.] As Werner Koch pointed out last year, this will require an implementation to know the block size simply in order to parse the rest of the packet. Given that the only material after the IV is the encrypted part, and thus won't be readable anyway without support for that cipher, I suppose this isn't all that serious. But is there any intention to make the IV size self-describing for future ciphers, or is this the final plan? Thanks for the quick responses. Received: by ns.secondary.com (8.9.3/8.9.3) id CAA06720 for ietf-openpgp-bks; Mon, 17 Jul 2000 02:03:24 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA06715 for ; Mon, 17 Jul 2000 02:03:22 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13E77v-0002Oz-00; Mon, 17 Jul 2000 11:23:51 +0200 Date: Mon, 17 Jul 2000 11:23:51 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Resolution on large-block ciphers (e.g., Blowfish), PGP7 Message-ID: <20000717112351.F8949@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <000501bfef7b$a4f070a0$023fa8c0@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: <000501bfef7b$a4f070a0$023fa8c0@mwyoung.transarc.com>; from mwy-opgp97@the-youngs.org on Sun, Jul 16, 2000 at 07:14:42PM -0400 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 16 Jul 2000, Michael Young wrote: > The draft makes no mention of how to encrypt secret keys. It still mentions > an 8-byte IV. I didn't see a clear winner in the discussion: an 8-byte IV IIRC it mention 8 byte IV only in the example. The specification should say an IV of the the same size as the blocksize. GnuPG 1.0.2 does exactly this. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id UAA00972 for ietf-openpgp-bks; Sun, 16 Jul 2000 20:43:43 -0700 (PDT) Received: from cypherspace.org (adam@modemcable249.22-201-24.mtl.mc.videotron.net [24.201.22.249]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA00965 for ; Sun, 16 Jul 2000 20:43:42 -0700 (PDT) Received: (from adam@localhost) by cypherspace.org (8.8.3/8.6.12) id XAA01334; Sun, 16 Jul 2000 23:47:30 -0500 Date: Sun, 16 Jul 2000 23:47:30 -0500 Message-Id: <200007170447.XAA01334@cypherspace.org> From: Adam Back To: I.Brown@cs.ucl.ac.uk Cc: ietf-openpgp@imc.org In-reply-to: <3963142F.E8971209@cs.ucl.ac.uk> (message from Ian Brown on Wed, 05 Jul 2000 11:55:43 +0100) Subject: Re: Forward secrecy Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Section 3 describes one-time keys, that are sent with messages to allow a the recipient to reply with immediate forward secrecy (immediately after receipt). I wonder if we could use a one-time key server to avoid the need for interactive use of email (need a reply from the recipient to get a key to reply to). Lets say we add a new function to keyservers which is that you submit a whole bunch of keys, and it hands them out on request, and deletes them after they've been received. I guess there's a pretty easy DoS there -- someone just goes and repeatedly downloads all available keys, to deny others the ability to obtain one-time keys. There might be some weak approaches to resist this DoS (eg refuse to provide more than one one-time key per time period to the same IP address), but they are just that -- weak. Adam Received: by ns.secondary.com (8.9.3/8.9.3) id UAA29002 for ietf-openpgp-bks; Sun, 16 Jul 2000 20:03:14 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA28998 for ; Sun, 16 Jul 2000 20:03:12 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id UAA30732; Sun, 16 Jul 2000 20:05:20 -0700 Date: Sun, 16 Jul 2000 20:05:20 -0700 Message-Id: <200007170305.UAA30732@finney.org> To: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Subject: Re: Resolution on large-block ciphers (e.g., Blowfish), PGP7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > The press releases for PGP version 7 from NAI says that it will include > Blowfish support. Can someone from NAI (or a beta customer) confirm > that they conform to the current draft? How do they deal with secret key > encryption using Blowfish? You mean Twofish. PGP version 7 will use a 16 byte (128 bit) IV when encrypting secret keys using Twofish. Hal Finney Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18789 for ietf-openpgp-bks; Sun, 16 Jul 2000 16:17:24 -0700 (PDT) Received: from alpha.pit.adelphia.net (alpha.pit.adelphia.net [24.48.44.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18784 for ; Sun, 16 Jul 2000 16:17:22 -0700 (PDT) Received: from mwyoung.transarc.com (pa-bethelpark1b-76.pit.adelphia.net [24.48.158.76]) by alpha.pit.adelphia.net (8.9.2/8.9.2) with SMTP id TAA04326 for ; Sun, 16 Jul 2000 19:19:36 -0400 (EDT) Message-ID: <000501bfef7b$a4f070a0$023fa8c0@mwyoung.transarc.com> From: "Michael Young" To: Subject: Resolution on large-block ciphers (e.g., Blowfish), PGP7 Date: Sun, 16 Jul 2000 19:14:42 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Looking through the archives, I see discussion on how to handle ciphers with block sizes over 8 bytes, but the resolution was not clear. The draft has been updated regarding SE data packets (tag 9). This appears to match the example that Werner Koch posted on April 9, 1999. (My implementation matches that example.) The draft makes no mention of how to encrypt secret keys. It still mentions an 8-byte IV. I didn't see a clear winner in the discussion: an 8-byte IV seems decidedly inadequate; having the IV length depend on the algorithm number would require a table for parsing; using a new version number to allow a length to be inserted wouldn't be too bad. Simply inserting a length (or making the IV an MPI) for algorithms 6 and beyond would be workable. Was there a resolution that I missed, and if so, will it be in an upcoming draft? If the intention is really to stick with an 8-byte IV, can the RFC be updated to discuss exactly how it works in this context? The press releases for PGP version 7 from NAI says that it will include Blowfish support. Can someone from NAI (or a beta customer) confirm that they conform to the current draft? How do they deal with secret key encryption using Blowfish? Received: by ns.secondary.com (8.9.3/8.9.3) id QAA18770 for ietf-openpgp-bks; Sun, 16 Jul 2000 16:16:25 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA18765 for ; Sun, 16 Jul 2000 16:16:18 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA30461; Sun, 16 Jul 2000 16:18:21 -0700 Date: Sun, 16 Jul 2000 16:18:21 -0700 Message-Id: <200007162318.QAA30461@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: q re binding user id's and subkeys Cc: hal@finney.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron Criddle writes: > > > By binding an encryption sub key to a primary signing key, you are binding > > > it to multiple user id's (if multiple user id's exist), however if user id > > > (a) wants to encrypt data using sub-key (b) and user id (b) wants to > > > encrypt data using sub-key (a), where do you actually make the bind? > > > >There is no way to express this in OpenPGP. > > Would it be hard to express that in OpenPGP? Can a signature subkey be > added that specifies the top level id that should be linked to the subkey? > Accordingly, if the subkey is bound to all upper level id's (as is the case > now) then the signature subkey would simply be left blank. Well, there is no way to express that in OpenPGP. If you are asking, could we add a way to do that, the answer is that it would be technically possible. The question is whether there is sufficient desire to add that. I think if you wanted to do this, it would be better to add a way for a given userid self-sig to say which subkey to use when that userid was chosen as an encryption target, rather than the other way around (subkey to point at userid). Without this mechanism, the main use of multiple subkeys is to make it easy to roll over your encryption keys relatively often, without invalidating the validity of your key. That's an important piece of functionality in itself. We might wish to discuss whether it is worthwhile to go beyond this to also allow the use of different subkeys for different userids. It would add considerable complexity to the UI, and at PGP.com we are if anything trying to simplify the UI. Most users still say encryption is too hard to use. Hal Finney Received: by ns.secondary.com (8.9.3/8.9.3) id IAA11008 for ietf-openpgp-bks; Sun, 16 Jul 2000 08:33:47 -0700 (PDT) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA10997 for ; Sun, 16 Jul 2000 08:33:45 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialup60.ip.lu [208.161.253.60]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id RAA18499; Sun, 16 Jul 2000 17:31:24 +0200 (CEST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 7963A2F033; Sun, 16 Jul 2000 12:30:00 +0200 (CEST) Date: Sun, 16 Jul 2000 12:30:00 +0200 From: Thomas Roessler To: Ian Bell , ietf-openpgp@imc.org, Michael Elkins , Dave Del Torto Subject: PGP/MIME: encoding restrictions. Message-ID: <20000716123000.A26892@sobolev.does-not-exist.org> Mail-Followup-To: Ian Bell , ietf-openpgp@imc.org, Michael Elkins , Dave Del Torto References: <20000510123254.J30366@sobolev.tlr-net.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.5i In-Reply-To: ; from ianbell@turnpike.com on Thu, May 11, 2000 at 09:44:28AM +0100 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-05-11 09:44:28 +0100, Ian Bell wrote: > Should the issue of binary versus text-mode signatures > be addressed? It should, and I believe the following would be the most robust solution: (1) require clients to create text mode signatures (2) require clients to use either quoted-printable or base64 for any body parts which contain trailing whitespace. Note that this seems to be what most clients do anyway at present. Rationale: MIME has been carefully designed in a way which makes sure that all essential information makes it through gateways which tamper with trailing whitespace. Thus, we should make sure that PGP/MIME signed messages don't lose any information on such paths, either. Not losing any information in the signed body is guaranteed by the use of qp/base64, whenever trailing whitespace is present. Not unnecesarily invalidating signatures is guaranteed by the use of text-mode signatures, since these signatures will ignore any trailing whitespace. Note that this trailing whitespace must be ignored by standard-conforming decoders for qp/base64, too, and doesn't carry any meaning in RFC822 (think about message/rfc822 attachments) or MIME headers, so signature verification will fail if and only if actual content has been modified. Binary-mode signatures would also be invalidated if trailing whitespace is tampered with, even though it doesn't carry any meaning to the MIME encoding used. Comments? -- Thomas Roessler Received: by ns.secondary.com (8.9.3/8.9.3) id UAA19323 for ietf-openpgp-bks; Sat, 15 Jul 2000 20:33:49 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA19319 for ; Sat, 15 Jul 2000 20:33:46 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A07423B01D6; Sun, 16 Jul 2000 11:35:32 0800 Message-Id: <4.3.2.7.0.20000716111425.00aec828@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 16 Jul 2000 11:24:58 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: q re binding user id's and subkeys Cc: hal@finney.org In-Reply-To: <200007141511.IAA24491@finney.org> 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: Hal, At 08:11 AM 14/07/2000 -0700, hal@finney.org wrote: >Erron writes: > > Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand > > how one binds an encryption sub key to a particular user id and the top > > level signing key? > >You can't. > > By binding an encryption sub key to a primary signing key, you are binding > > it to multiple user id's (if multiple user id's exist), however if user id > > (a) wants to encrypt data using sub-key (b) and user id (b) wants to > > encrypt data using sub-key (a), where do you actually make the bind? > >There is no way to express this in OpenPGP. Would it be hard to express that in OpenPGP? Can a signature subkey be added that specifies the top level id that should be linked to the subkey? Accordingly, if the subkey is bound to all upper level id's (as is the case now) then the signature subkey would simply be left blank. If this cannot be done then I would assume that if you want different encryption keys for various user id's /alias's, then you would have to create two separate private keyrings that use different signing keys as well...or can you do this somehow using the same signing key? Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id LAA01790 for ietf-openpgp-bks; Sat, 15 Jul 2000 11:10:31 -0700 (PDT) Received: from cypherpunks.ai (cypherpunks.ai [209.88.68.47]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA01776 for ; Sat, 15 Jul 2000 11:10:29 -0700 (PDT) Received: from woudt.nl (cudomix.ai [209.88.68.210]) by cypherpunks.ai (Postfix) with ESMTP id D154B4D for ; Sat, 15 Jul 2000 14:12:10 -0400 (AST) Message-ID: <3970A977.D1FA0F2F@woudt.nl> Date: Sat, 15 Jul 2000 14:12:07 -0400 From: Edwin Woudt X-Mailer: Mozilla 4.73 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Signature Subpacket format questions 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: While implementing V4 signature support for a Java OpenPGP library, I encountered a few things with some Signature Subpackets that were not immediately clear to me. I would be very grateful if someone could answer these questions: * The format specified for both 5.2.3.18. 'Preferred key server' and 5.2.3.20. 'Policy URL' is 'String'. Is this string terminated by a null value, like 5.2.3.14. 'Regular expression', or not? * What is the format for 5.2.3.22. 'Signer's User ID'? A String like in the previous question? Edwin -- edwin@cryptix.org http://www.cryptix.org/products/openpgp/ Received: by ns.secondary.com (8.9.3/8.9.3) id OAA17121 for ietf-openpgp-bks; Fri, 14 Jul 2000 14:49:16 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA17111 for ; Fri, 14 Jul 2000 14:49:14 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id OAA19015; Fri, 14 Jul 2000 14:51:14 -0700 Date: Fri, 14 Jul 2000 14:51:07 -0700 (PDT) From: "L. Sassaman" To: Marcel Zamzow cc: ietf-openpgp@imc.org Subject: Re: VPN Systems via OpenPGP In-Reply-To: <8690.000713@zamzow.de> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ns.secondary.com id OAA17112 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 13 Jul 2000, Marcel Zamzow wrote: > Iserlohn, den 13.07.2000 > > Hello everybody, > > currently i´m evaluating the possibility to > implement OpenPGP into an Open-Sourced VPN System. > Has anybody some good url´s for me pointing to > Virtual Private Networks ? All I have found is > only pointing to the NAI´s Produkt and is too > unprecised. > Moreover has somebody already heard about such an > implementation, cause this would be my work for > my Diploma and so it should be something new. Both FreeS/WAN and the OpenBSD IPsec products are open sourced. Does your project require you to start from scratch, or could you take a pre-existing VPN system and integrate OpenPGP into it? - --Len. __ L. Sassaman System Administrator | "Every window on Alcatraz has Technology Consultant | a view of San Francisco." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Susanna Kaysen -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5b4tSPYrxsgmsCmoRAjerAJ0UiVstcPKHv1Q9DJQ6UxhuvpVftgCg+rct tqFsJiIuA1BhGCsU1JwHgO4= =2kqu -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id IAA22602 for ietf-openpgp-bks; Fri, 14 Jul 2000 08:09:33 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA22598 for ; Fri, 14 Jul 2000 08:09:29 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA24491; Fri, 14 Jul 2000 08:11:19 -0700 Date: Fri, 14 Jul 2000 08:11:19 -0700 Message-Id: <200007141511.IAA24491@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: q re binding user id's and subkeys Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron writes: > Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand > how one binds an encryption sub key to a particular user id and the top > level signing key? You can't. > There seems to be no information contained in a sub-key packet that can > link it to a user id. Also, the binding signature does not contain info > regarding a user id (nor the binding signatures subpackets). That's right. > By binding an encryption sub key to a primary signing key, you are binding > it to multiple user id's (if multiple user id's exist), however if user id > (a) wants to encrypt data using sub-key (b) and user id (b) wants to > encrypt data using sub-key (a), where do you actually make the bind? There is no way to express this in OpenPGP. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id XAA03381 for ietf-openpgp-bks; Thu, 13 Jul 2000 23:01:37 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA03376 for ; Thu, 13 Jul 2000 23:01:34 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A0182530212; Fri, 14 Jul 2000 14:03:20 0800 Message-Id: <4.3.2.7.0.20000614132307.00af5718@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 14 Jun 2000 13:52:51 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: q re binding user id's and subkeys 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: To all, Regarding 5.5.1.1 and 5.5.1.2; I am having a problem trying to understand how one binds an encryption sub key to a particular user id and the top level signing key? There seems to be no information contained in a sub-key packet that can link it to a user id. Also, the binding signature does not contain info regarding a user id (nor the binding signatures subpackets). By binding an encryption sub key to a primary signing key, you are binding it to multiple user id's (if multiple user id's exist), however if user id (a) wants to encrypt data using sub-key (b) and user id (b) wants to encrypt data using sub-key (a), where do you actually make the bind? My apologies if I've (once again), misread or completely missed something. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id PAA10789 for ietf-openpgp-bks; Thu, 13 Jul 2000 15:39:52 -0700 (PDT) Received: from post.webmailer.de (natmail2.webmailer.de [192.67.198.65]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA10785 for ; Thu, 13 Jul 2000 15:39:51 -0700 (PDT) Received: from A261a.pppool.de (A261a.pppool.de [213.6.38.26]) by post.webmailer.de (8.9.3/8.8.7) with ESMTP id AAA15786 for ; Fri, 14 Jul 2000 00:41:52 +0200 (MET DST) Date: Thu, 13 Jul 2000 16:34:26 +0200 From: Marcel Zamzow X-Mailer: The Bat! (v1.41) REG'D / CD5BF9353B3B7091 Reply-To: Marcel Zamzow X-Priority: 3 (Normal) Message-ID: <8690.000713@zamzow.de> To: ietf-openpgp@imc.org Subject: VPN Systems via OpenPGP Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Iserlohn, den 13.07.2000 Hello everybody, currently i´m evaluating the possibility to implement OpenPGP into an Open-Sourced VPN System. Has anybody some good url´s for me pointing to Virtual Private Networks ? All I have found is only pointing to the NAI´s Produkt and is too unprecised. Moreover has somebody already heard about such an implementation, cause this would be my work for my Diploma and so it should be something new. Best regards, Marcel - --- /* Marcel Zamzow, student of Computer Science [University of Applied Sciences Iserlohn] homepage : http://www.zamzow.de mailto : marcel@zamzow.de */ -----BEGIN PGP SIGNATURE----- iQIVAwUAOW3TbfPorQ0Gk425AQFnlA//e73nE6eCNQcDhXGzRTHv8IRQ6ubublPH bIP1sv29V3Xc+runIKWjpP66hur12DizD7gP2RCukLgMmcFCFTw1IDbXrJxtWmMC HN+QWDEY1Fpy9+OeKBIBDcHauSdYMoRk0c7ad+0eGCTuxhQjDl/YDO+qoWzFyYl5 qvq2L705L4AzLiIQSZJL7mR5XdqK3ZqCikgwfMkcEvlcnI369wL7qpoWgJgCM+eQ vDHiMlvfpF8Lm4KMiB/hTdm5SjhG/EJfsxp7KXVTBZrDh2yLuPTnjrn2d6FOa+vc R392NDtiAsi6H4jDthknW87KMHFycwcMYlfcB3J0pF2Td2IIGvQRd0Q34DohmBxk EdFuH7bQLNDhD72EFb2GriyVEBZC9sPt8+8BA7XeWVd3Ttr1AlWmcDGHbgmHRC9R slVK6zyHYFwSmdAtBJZyGp/zyzr2ld7pG0xp0v6WJxsV6WWD4CYJIy1OiWbu7b68 GrIXwntAt/DQ/nSGVuU6MfvYoxgi+k9ERSSzbO3SLxxWYGZTe5SeYXD1CkYu1fCG HpI4RM9JIGom9vF6eT+7dM92DXNPy7nBwkxXVAB6hWZ4VACoQQsuOsZWLYchMhqd 9uxsFuHwkxm9V01Ux7A1OzaFOzvKZ124qRwJGwppHV90b4XLL4ruvq6MPl5px+Z+ AUA3qrC9Pak= =/RbR -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28806 for ietf-openpgp-bks; Thu, 13 Jul 2000 08:39:38 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28796 for ; Thu, 13 Jul 2000 08:39:36 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA20889; Thu, 13 Jul 2000 08:41:20 -0700 Date: Thu, 13 Jul 2000 08:41:20 -0700 Message-Id: <200007131541.IAA20889@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: V4 Sig. incomplete? Cc: hal@finney.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > >Yes, this all looks fine now. The one thing I'd add is that there is no > >need to parse out the key and subkey packets as you have done. After the > >0x99 and two-octet length, you just hash the key or subkey packet body. > >The specific contents of the key/subkey packet are irrelevant to the > >signature algotihm, it's just data to feed the hash. > > So you're saying that (1) is OK, however in the case of 2), it would be > best to structure it this way: No, I didn't mean that. All I meant was that you don't have to worry about the contents of the public key packets, the version and time and MPIs. Just hash the key packet data as a block. It makes it much easier to see what is going on: header data 0x99 | 2 octet length | key packet body data | user id data 0xb4 | 4 octet length | username data | signature trailer version field to end of hashable data | V4 signature trailer 0x04 | 0xFF | 4 octet length | Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA04556 for ietf-openpgp-bks; Thu, 13 Jul 2000 00:02:08 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA04552 for ; Thu, 13 Jul 2000 00:02:05 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ACC772A01E6; Thu, 13 Jul 2000 15:03:51 0800 Message-Id: <4.3.2.7.0.20000613144451.0244fe20@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 14:53:30 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: V4 Sig. incomplete? Cc: hal@finney.org In-Reply-To: <200007130636.XAA20214@finney.org> 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: Hal, Nearly there (I think)...just need to clarify what you have said: At 11:36 PM 12/07/2000 -0700, hal@finney.org wrote: >Yes, this all looks fine now. The one thing I'd add is that there is no >need to parse out the key and subkey packets as you have done. After the >0x99 and two-octet length, you just hash the key or subkey packet body. >The specific contents of the key/subkey packet are irrelevant to the >signature algotihm, it's just data to feed the hash. So you're saying that (1) is OK, however in the case of 2), it would be best to structure it this way: header data 0x99 | 2 octet length | public ElGamal keys 0x04 (version) | 4 octet time | 0x10 (for ElGamal enc. algorithm) | MPI of ElGamal prime p | MPI of ElGamal group generator g | MPI of ElGamal public key value y | signature trailer version field to end of hashable data | V4 signature trailer 0x04 | 0xFF | 4 octet length | I hope this is OK...or did I totally misunderstand your response? Thanks :) > > 1) V4 Sig., type 0x10. Concatenate the following data then hash it for > > input into the DSA (the data to be hashed is terminated with the | char) > > > > header data > > > > 0x99 | > > 2 octet length | > > > > public DSA keys (version 4) > > > > 0x04 (version) | > > 4 octet time | > > 0x11 (for DSA signing algorithm) | > > MPI of DSA prime p | > > MPI of DSA grooup order q | > > MPI of DSA group generator g | > > MPI of DSA public key value y | > > > > user id data > > > > 0xb4 | > > 4 octet length | > > username data | > > > > signature trailer > > > > version field to end of hashable data | > > > > V4 signature trailer > > > > 0x04 | > > 0xFF | > > 4 octet length | > > > > All the above data is concatenated then hashed. The left 16 bits are > > inserted into the hash check field of the signature and then the hash is > > fed into the DSA for production of the signature. > > > > 2) V4 Sig., type 0x18. Concatenate the following data then hash it for > > input into the DSA (the data to be hashed is terminated with the | char) > > > > header data > > > > 0x99 | > > 2 octet length | > > > > public DSA keys (version 4) > > > > 0x04 (version) | > > 4 octet time | > > 0x11 (for DSA signing algorithm) | > > MPI of DSA prime p | > > MPI of DSA grooup order q | > > MPI of DSA group generator g | > > MPI of DSA public key value y | > > > > header data > > > > 0x99 | > > 2 octet length | > > > > public ElGamal keys > > > > 0x04 (version) | > > 4 octet time | > > 0x10 (for ElGamal enc. algorithm) | > > MPI of ElGamal prime p | > > MPI of ElGamal group generator g | > > MPI of ElGamal public key value y | > > > > signature trailer > > > > version field to end of hashable data | > > > > V4 signature trailer > > > > 0x04 | > > 0xFF | > > 4 octet length | > > > > Once again, all the above data is concatenated then hashed. The left 16 > > bits are inserted into the hash check field of the signature and then the > > hash is fed into the DSA for production of the signature. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id XAA03508 for ietf-openpgp-bks; Wed, 12 Jul 2000 23:34:53 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA03502 for ; Wed, 12 Jul 2000 23:34:52 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id XAA20214; Wed, 12 Jul 2000 23:36:32 -0700 Date: Wed, 12 Jul 2000 23:36:32 -0700 Message-Id: <200007130636.XAA20214@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: V4 Sig. incomplete? Cc: hal@finney.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Yes, this all looks fine now. The one thing I'd add is that there is no need to parse out the key and subkey packets as you have done. After the 0x99 and two-octet length, you just hash the key or subkey packet body. The specific contents of the key/subkey packet are irrelevant to the signature algotihm, it's just data to feed the hash. Hal > 1) V4 Sig., type 0x10. Concatenate the following data then hash it for > input into the DSA (the data to be hashed is terminated with the | char) > > header data > > 0x99 | > 2 octet length | > > public DSA keys (version 4) > > 0x04 (version) | > 4 octet time | > 0x11 (for DSA signing algorithm) | > MPI of DSA prime p | > MPI of DSA grooup order q | > MPI of DSA group generator g | > MPI of DSA public key value y | > > user id data > > 0xb4 | > 4 octet length | > username data | > > signature trailer > > version field to end of hashable data | > > V4 signature trailer > > 0x04 | > 0xFF | > 4 octet length | > > All the above data is concatenated then hashed. The left 16 bits are > inserted into the hash check field of the signature and then the hash is > fed into the DSA for production of the signature. > > 2) V4 Sig., type 0x18. Concatenate the following data then hash it for > input into the DSA (the data to be hashed is terminated with the | char) > > header data > > 0x99 | > 2 octet length | > > public DSA keys (version 4) > > 0x04 (version) | > 4 octet time | > 0x11 (for DSA signing algorithm) | > MPI of DSA prime p | > MPI of DSA grooup order q | > MPI of DSA group generator g | > MPI of DSA public key value y | > > header data > > 0x99 | > 2 octet length | > > public ElGamal keys > > 0x04 (version) | > 4 octet time | > 0x10 (for ElGamal enc. algorithm) | > MPI of ElGamal prime p | > MPI of ElGamal group generator g | > MPI of ElGamal public key value y | > > signature trailer > > version field to end of hashable data | > > V4 signature trailer > > 0x04 | > 0xFF | > 4 octet length | > > Once again, all the above data is concatenated then hashed. The left 16 > bits are inserted into the hash check field of the signature and then the > hash is fed into the DSA for production of the signature. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA03112 for ietf-openpgp-bks; Wed, 12 Jul 2000 23:26:57 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA03108 for ; Wed, 12 Jul 2000 23:26:54 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A48615501CE; Thu, 13 Jul 2000 14:28:38 0800 Message-Id: <4.3.2.7.0.20000613135617.0244bea0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 14:18:17 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: V4 Sig. incomplete? Cc: hal@finney.org In-Reply-To: <200007130539.WAA19969@finney.org> 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: Hal, Many thanks for your reply - it has certainly made things clearer :) At 10:39 PM 12/07/2000 -0700, hal@finney.org wrote: > > This is only 5 octets...does anybody know what the 6th octet is? ...or > is a > > V4 signature final trailer only 5 octets? > >Where did you get the "or" in "0x04 or 0xFF"? Obviously from some cross-linked neurons - sorry for the wasted b/w. I have also rewritten my original question and answers - hopefully they are correct this time :) : 1) V4 Sig., type 0x10. Concatenate the following data then hash it for input into the DSA (the data to be hashed is terminated with the | char) header data 0x99 | 2 octet length | public DSA keys (version 4) 0x04 (version) | 4 octet time | 0x11 (for DSA signing algorithm) | MPI of DSA prime p | MPI of DSA grooup order q | MPI of DSA group generator g | MPI of DSA public key value y | user id data 0xb4 | 4 octet length | username data | signature trailer version field to end of hashable data | V4 signature trailer 0x04 | 0xFF | 4 octet length | All the above data is concatenated then hashed. The left 16 bits are inserted into the hash check field of the signature and then the hash is fed into the DSA for production of the signature. 2) V4 Sig., type 0x18. Concatenate the following data then hash it for input into the DSA (the data to be hashed is terminated with the | char) header data 0x99 | 2 octet length | public DSA keys (version 4) 0x04 (version) | 4 octet time | 0x11 (for DSA signing algorithm) | MPI of DSA prime p | MPI of DSA grooup order q | MPI of DSA group generator g | MPI of DSA public key value y | header data 0x99 | 2 octet length | public ElGamal keys 0x04 (version) | 4 octet time | 0x10 (for ElGamal enc. algorithm) | MPI of ElGamal prime p | MPI of ElGamal group generator g | MPI of ElGamal public key value y | signature trailer version field to end of hashable data | V4 signature trailer 0x04 | 0xFF | 4 octet length | Once again, all the above data is concatenated then hashed. The left 16 bits are inserted into the hash check field of the signature and then the hash is fed into the DSA for production of the signature. > > 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding > into > > the DSA (assuming DSA sig): > >I'm not sure what you mean by "hash then concatenate". It would make >more sense to say "concatenate then hash", or more simply, just "hash". > > > public DSA keys (this line not hashed) > > > > 0x99 | > > 2 octet length | > >At this point you hash the entire public key packet. As described >in section 5.5.2 of RFC 2440, in addition to the MPI data below, this >includes a version number, creation time, validity period if V3 key, >and public key algorithm type. This is then followed by the MPI data: > > > MPI of DSA prime p | > > MPI of DSA grooup order q | > > MPI of DSA group generator g | > > MPI of DSA public key value y | > >Of course a DSA signature could be over an RSA key as well. > > > + > > > > user id (this line not hashed) > > > > 0xb4 | > > 4 octet length | > > username data | > > > > version field to end of hashable data | > >Yes, of the signature packet. > > > > > 0x04 | > >then 0xFF then > > > 4 octet length | > > ? (see previous question re 5.4) | > >This looks correct, incorporating the changes above. > > > > 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding > into > > the DSA (assuming DSA signature keys and ElGamal encryption keys): > > > > public DSA keys (this line not hashed) > > > > 0x99 | > > 2 octet length | > >As above, other key packet information is hashed here. > > > MPI of DSA prime p | > > MPI of DSA grooup order q | > > MPI of DSA group generator g | > > MPI of DSA public key value y | > > > > + > > > > public ElGamal keys (this line not hashed) > > > > 0x99 | > > 2 octet length | > >Again, other subkey packet information is hashed here. > > > MPI of ElGamal prime p | > > MPI of ElGamal grooup order q | > >Actually this is the group generator g, not the group order q. > > > MPI of ElGamal public key value y | > > > > version field to end of hashable data | > > > > 0x04 | > >As above, 0xFF goes here. > > > 4 octet length | > > ? (see previous question re 5.4) | > >Hal Finney Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id WAA00930 for ietf-openpgp-bks; Wed, 12 Jul 2000 22:38:12 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA00923 for ; Wed, 12 Jul 2000 22:38:10 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA19969; Wed, 12 Jul 2000 22:39:51 -0700 Date: Wed, 12 Jul 2000 22:39:51 -0700 Message-Id: <200007130539.WAA19969@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: V4 Sig. incomplete? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > With reference to 5.4; the second last paragraph states that a version 4 > signature has a final trailer of 6 octets, being: > > 0x04 or 0xFF, a four octet big endian number > > This is only 5 octets...does anybody know what the 6th octet is? ...or is a > V4 signature final trailer only 5 octets? Where did you get the "or" in "0x04 or 0xFF"? The spec says, V4 signatures also hash in a final trailer of six octets: the version of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian number that is the length of the hashed data from the signature packet (note that this number does not include these final six octets. I don't see an "or". It is 0x04, 0xFF, and the four octets of length. That is six octets. > 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding into > the DSA (assuming DSA sig): I'm not sure what you mean by "hash then concatenate". It would make more sense to say "concatenate then hash", or more simply, just "hash". > public DSA keys (this line not hashed) > > 0x99 | > 2 octet length | At this point you hash the entire public key packet. As described in section 5.5.2 of RFC 2440, in addition to the MPI data below, this includes a version number, creation time, validity period if V3 key, and public key algorithm type. This is then followed by the MPI data: > MPI of DSA prime p | > MPI of DSA grooup order q | > MPI of DSA group generator g | > MPI of DSA public key value y | Of course a DSA signature could be over an RSA key as well. > + > > user id (this line not hashed) > > 0xb4 | > 4 octet length | > username data | > > version field to end of hashable data | Yes, of the signature packet. > > 0x04 | then 0xFF then > 4 octet length | > ? (see previous question re 5.4) | This looks correct, incorporating the changes above. > 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding into > the DSA (assuming DSA signature keys and ElGamal encryption keys): > > public DSA keys (this line not hashed) > > 0x99 | > 2 octet length | As above, other key packet information is hashed here. > MPI of DSA prime p | > MPI of DSA grooup order q | > MPI of DSA group generator g | > MPI of DSA public key value y | > > + > > public ElGamal keys (this line not hashed) > > 0x99 | > 2 octet length | Again, other subkey packet information is hashed here. > MPI of ElGamal prime p | > MPI of ElGamal grooup order q | Actually this is the group generator g, not the group order q. > MPI of ElGamal public key value y | > > version field to end of hashable data | > > 0x04 | As above, 0xFF goes here. > 4 octet length | > ? (see previous question re 5.4) | Hal Finney Received: by ns.secondary.com (8.9.3/8.9.3) id WAA29771 for ietf-openpgp-bks; Wed, 12 Jul 2000 22:27:16 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA29765 for ; Wed, 12 Jul 2000 22:27:14 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA19939; Wed, 12 Jul 2000 22:28:55 -0700 Date: Wed, 12 Jul 2000 22:28:55 -0700 Message-Id: <200007130528.WAA19939@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: q re 5.1; is it m*(y**k) or (m*y)**k ? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > 5.1: Regarding the ElGamal keys and the *m* value, is it: > > a) (m*y)**k mod p > b) m * (y**k) mod p It is (b). Hal Received: by ns.secondary.com (8.9.3/8.9.3) id VAA25504 for ietf-openpgp-bks; Wed, 12 Jul 2000 21:10:40 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA25483 for ; Wed, 12 Jul 2000 21:10:32 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A49014E018E; Thu, 13 Jul 2000 12:12:16 0800 Message-Id: <4.3.2.7.0.20000613113239.00af78f0@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 12:01:55 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: V4 Sig. incomplete? 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: To all concerned: With reference to 5.4; the second last paragraph states that a version 4 signature has a final trailer of 6 octets, being: 0x04 or 0xFF, a four octet big endian number This is only 5 octets...does anybody know what the 6th octet is? ...or is a V4 signature final trailer only 5 octets? TIA for the clarification. PS: Can anyone please confirm the following (hashed data is appended by the | symbol) 1) V4 Sig., type 0x10. Hash then concatenate the following for feeding into the DSA (assuming DSA sig): public DSA keys (this line not hashed) 0x99 | 2 octet length | MPI of DSA prime p | MPI of DSA grooup order q | MPI of DSA group generator g | MPI of DSA public key value y | + user id (this line not hashed) 0xb4 | 4 octet length | username data | version field to end of hashable data | 0x04 | 4 octet length | ? (see previous question re 5.4) | 2) V4 Sig., type 0x18. Hash then concatenate the following for feeding into the DSA (assuming DSA signature keys and ElGamal encryption keys): public DSA keys (this line not hashed) 0x99 | 2 octet length | MPI of DSA prime p | MPI of DSA grooup order q | MPI of DSA group generator g | MPI of DSA public key value y | + public ElGamal keys (this line not hashed) 0x99 | 2 octet length | MPI of ElGamal prime p | MPI of ElGamal grooup order q | MPI of ElGamal public key value y | version field to end of hashable data | 0x04 | 4 octet length | ? (see previous question re 5.4) | Once again, thanks for any clarification. Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22842 for ietf-openpgp-bks; Wed, 12 Jul 2000 20:41:19 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA22838 for ; Wed, 12 Jul 2000 20:41:17 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id ADB012C01CE; Thu, 13 Jul 2000 11:42:56 0800 Message-Id: <4.3.2.7.0.20000613112656.00ae3a98@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 13 Jun 2000 11:32:36 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: q re 5.1; is it m*(y**k) or (m*y)**k ? 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: To all, A couple of q's re 2440: 5.1: Regarding the ElGamal keys and the *m* value, is it: a) (m*y)**k mod p b) m * (y**k) mod p Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Fax: 08 9386 9473 Tel: 08 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id KAA21956 for ietf-openpgp-bks; Tue, 11 Jul 2000 10:22:31 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA21948 for ; Tue, 11 Jul 2000 10:22:29 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id KAA20476; Tue, 11 Jul 2000 10:24:09 -0700 Date: Tue, 11 Jul 2000 10:24:01 -0700 (PDT) From: "L. Sassaman" To: Werner Koch cc: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: <20000711131826.D569@djebel.gnupg.de> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 11 Jul 2000, Werner Koch wrote: > On Mon, 10 Jul 2000, L. Sassaman wrote: > > > The client takes the public key block, signs it, and submits this signed > > blob to the server. The server then verifies the signature, trims away > > that signature, and adds the key. > > Don't forget that the server needs to accept unsigned requests too and > allow to add key revocations and certicate revocations. Yep. I figured I wouldn't bring that up again, since it looks like we're going to be needing an I-D on keyservers, and that would fit in there. But yes, the owner-update-only flag must be ignored on all types of revocations. - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5a1g4PYrxsgmsCmoRAl89AJ9X6LyWrnawfETOB1Xv6w5zQEsxkQCg3yXr CbFEAeBCXm20kfE9umyp+ks= =X0Ae -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id DAA29622 for ietf-openpgp-bks; Tue, 11 Jul 2000 03:59:50 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA29614 for ; Tue, 11 Jul 2000 03:59:47 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 13By3W-0000AG-00; Tue, 11 Jul 2000 13:18:26 +0200 Date: Tue, 11 Jul 2000 13:18:26 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 Message-ID: <20000711131826.D569@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20000710123746Y.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.8i In-Reply-To: ; from rabbi@quickie.net on Mon, Jul 10, 2000 at 10:19:52AM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 10 Jul 2000, L. Sassaman wrote: > The client takes the public key block, signs it, and submits this signed > blob to the server. The server then verifies the signature, trims away > that signature, and adds the key. Don't forget that the server needs to accept unsigned requests too and allow to add key revocations and certicate revocations. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@OpenIT.de D-40233 Duesseldorf http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id OAA12208 for ietf-openpgp-bks; Mon, 10 Jul 2000 14:51:04 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA12204 for ; Mon, 10 Jul 2000 14:51:02 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id OAA11574; Mon, 10 Jul 2000 14:52:45 -0700 Date: Mon, 10 Jul 2000 14:52:38 -0700 (PDT) From: "L. Sassaman" To: Jon Callas cc: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: OpenPGP should be called ClosedPGP In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 5 Jul 2000, Jon Callas wrote: > One of the things to remember about 2440 -- and stated in the document > abstract -- is that it isn't a how-to guide for writing an application. > It's a description of how the data is laid out, and (more or less) what it > means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide." > > Lots of things are assumed in the document. For example, it's assumed you > know what a cipher is. Many of the references to ciphers are pretty terse, > and I know I wouldn't want to implement from it and it alone. Just last > week, for example, someone pointed out to me that the reference for > Triple-DES was dangling. We all looked around for a good reference to 3DES, > and didn't come up with one! I was sure there was some RFC for it, myself, > and there isn't. This is amusing, since 3DES is the cross-group defacto > meta-standard algorithm in the IETF, and yet we don't have a good place to > say, "Hey, here's how 3DES is done." I changed the 2440bis reference to > point to Schneier, which is better than nothing, but still not great. As we > find those things, we'll shoot them. Use X9.52. X9.52 is the ANSI standard for 3DES. Menezes et al. references it when discussing 3DES, and I believe Schneier does as well. - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5akWsPYrxsgmsCmoRArBwAJ9PPMdy0D2NwMgHzNuVq4vOCnKETgCgilCC EASEGruc+B16FO+lxwnLdc0= =B66F -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id NAA10549 for ietf-openpgp-bks; Mon, 10 Jul 2000 13:31:04 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id NAA10545 for ; Mon, 10 Jul 2000 13:30:59 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id NAA25115; Mon, 10 Jul 2000 13:32:01 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id NAA25111; Mon, 10 Jul 2000 13:31:53 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: Date: Mon, 10 Jul 2000 13:31:48 -0700 To: "L. Sassaman" , hal@finney.org From: Jon Callas Subject: Re: Question regarding 2440:5.2.3.16 Cc: ietf-openpgp@imc.org, wk@gnupg.org Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:29 AM -0700 7/10/00, L. Sassaman wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Mon, 10 Jul 2000 hal@finney.org wrote: > >> That seems OK, or perhaps you could use an SSL (TLS) session using the >> PGP key to authenticate the client. In any case I don't think this >> mechanism should be documented in 2440. > >That's fine, but I do think that this definately needs to be >documented. If 2440 isn't the place, then we need to start work on a >keyserver draft. > Someone should work on a key server document. RFC 2440 is OpenPGP Formats. Key server operation is not a data format. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06666 for ietf-openpgp-bks; Mon, 10 Jul 2000 11:27:50 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06662 for ; Mon, 10 Jul 2000 11:27:49 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id LAA10170; Mon, 10 Jul 2000 11:29:13 -0700 Date: Mon, 10 Jul 2000 11:29:05 -0700 (PDT) From: "L. Sassaman" To: hal@finney.org cc: ietf-openpgp@imc.org, wk@gnupg.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: <200007101810.LAA11952@finney.org> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 10 Jul 2000 hal@finney.org wrote: > That seems OK, or perhaps you could use an SSL (TLS) session using the > PGP key to authenticate the client. In any case I don't think this > mechanism should be documented in 2440. That's fine, but I do think that this definately needs to be documented. If 2440 isn't the place, then we need to start work on a keyserver draft. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5ahX4PYrxsgmsCmoRAugzAJ9kXo6sUKvSwNXccAz2neOxYK7xWwCeLeQu rPS3ze/rL2VpE3VOMgw7HFs= =RYem -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05150 for ietf-openpgp-bks; Mon, 10 Jul 2000 10:18:20 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05146 for ; Mon, 10 Jul 2000 10:18:19 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id KAA09686; Mon, 10 Jul 2000 10:20:00 -0700 Date: Mon, 10 Jul 2000 10:19:52 -0700 (PDT) From: "L. Sassaman" To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: <20000710123746Y.1001@eccosys.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, 10 Jul 2000 sen_ml@eccosys.com wrote: > so you are suggesting that proof of ownership of the corresponding > secret key (via an appropriate signature) should server this purpose, > right? Yes, because the owner needs to prove he has the secret key, and the public key block that is to be added must be signed to prevent unauthorized signatures being added during this process. > > Werner Koch and I have been discussing this, and he suggests that we put > > it into a clear-text signature packet. Would that be suitable? > > would you mind briefly describing the steps involved for the mechanism > you are considering (in terms like "first, the client connects to the > server. then the server responds w/..." etc.)? > > [ i understand what you are saying about the form a signature would > take, but i don't see the overall flow of the process of > authentication. ] The client takes the public key block, signs it, and submits this signed blob to the server. The server then verifies the signature, trims away that signature, and adds the key. Keys that are added unsigned should always be checked for the existance of the "no-modify" flag, and rejected if it exists. Furthermore, I suggest that we have a "modify" flag added to the spec, so that, if a signature is made at a later date containing this flag, it would superceed a preveous no-modify. But that digresses from this discussion. > also, is it necessary to consider replay attacks for this kind of > scenario? alternatively, would the following scenario be of any concern: > > an attacker captures a session between a user and a keyserver at some > point in time. later, after the user has made several updates to the > keyserver, the attacker replays the captured session to set the > state of the user's key to an earlier state. This scenerio is only partially valid. A signed key that is added to a server does not remove the previous key and replace it with the new one. It is treated like and other add, and is merged with the existing key. So, an attacker could not truly set the key to a previous state. What an attacker *could* do, via a replay attack, is re-add signatures or user-ids to a key on the server that the owner had later deleted. I see this as a minor annoyance, rather than an attack, so I don't think that we need to address it. (Though we could, through the use of server tokens or timestamps, etc. I just think it is more work than is necessary.) - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5agW/PYrxsgmsCmoRAhJhAKCo88zWNgPDz7aQ77qGMv7wmNgVWgCdGfcs 6xQ9X0cE6PywApXO0N0FVRc= =IpeB -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id XAA14428 for ietf-openpgp-bks; Sun, 9 Jul 2000 23:42:49 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA14423 for ; Sun, 9 Jul 2000 23:42:47 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 16278 invoked from network); 10 Jul 2000 06:44:08 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 06:44:08 -0000 To: ietf-openpgp@imc.org Subject: Re: 2.1, 2.2 and 10.2 Clarification re sigs. In-Reply-To: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> References: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710154438W.1001@eccosys.com> Date: Mon, 10 Jul 2000 15:44:38 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 19 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: 2.1, 2.2 and 10.2 Clarification re sigs. Date: Sat, 10 Jun 2000 13:39:02 +0800 Message-ID: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> ... > "Signed Message :- Signature Packet, OpenPGP Message | One-Pass > Signed Message" may be this was meant to be: Signed Message :- OpenPGP Message, Signature Packet | One-Pass Signed Message ? for reference, looking through the openpgp packets found in pgp messages i have received, the pattern of "literal data packet followed by signature packet" does appear. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA13335 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:47:46 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA13330 for ; Sun, 9 Jul 2000 22:47:43 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A6C8A0F00AC; Mon, 10 Jul 2000 13:49:12 0800 Message-Id: <4.3.2.7.0.20000610123516.00b52f78@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 10 Jun 2000 13:39:02 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: 2.1, 2.2 and 10.2 Clarification re sigs. 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: To all, -----BEGIN SECTION REFERENCES----- Section 2.1 (last paragraph) notes: "First, a signature is generated for the message and attached to the message. Then the message plus the signature is encrypted using a symmetric session key." Section 2.2 (item 4) notes: "4. The binary signature is attached to the message" Section 10.2 notes: "One-Pass Signed Message :- One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packet" "Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message" -----END SECTION REFERENCES----- To me, "attached" (as in 2.1 and 2.2) means you add it to the end of something and this contradicts 10.2 explanation of a Signed Message (a signed message implies that it is prepended, not attached). By reading section 10.2, it seems that there are two possibilities for signing a literal message: 1) You create a signature packet then prepend it to the literal packet 2) You create a signature packet and a One-Pass Signature Packet then prepend the One-Pass packet to the literal packet and append the signature packet to the literal packet. Therefore, my final questions are: 1) Can you create a simple signature packet and attach it to the end of a literal packet as stated in 2.1 and 2.2 and subsequently contradict 10.2 regarding the definition of a signed message and: 2) Why would you need a One-Pass Signature Packet if we conform to 10.2 and simply prepend a normal signature packet to the literal data with a subpacket of type 16 (key id), thus removing the need for a One-Pass packet in the first place? Cheers for any clarification once again :) Regards Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 http://www.comasp.com Erron Criddle Tel: 08 9386 9534 ejc@comasp.com Fax: 08 9386 9473 Received: by ns.secondary.com (8.9.3/8.9.3) id WAA12612 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:08:08 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA12608 for ; Sun, 9 Jul 2000 22:08:07 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id WAA10764; Sun, 9 Jul 2000 22:09:30 -0700 Date: Sun, 9 Jul 2000 22:09:30 -0700 Message-Id: <200007100509.WAA10764@finney.org> To: ietf-openpgp@imc.org, sen_ml@eccosys.com Subject: Re: 5.1 Clarification re padding Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > > I believe I have it worked out now...after reading the "File Formats used > > by 2.x" document, 2313 and 2437, does the m value look like this?: > > > > m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session > > key) (checksum) > > > > The 0x0A represents the Twofish algorithm. > > that's reflects my current understanding. Yes, I believe this is correct. > to all: > > i've been curious about the length of the random padding octets. i > presume none of them are allowed to 0x00 (that's what non-zero data > means, may be?) and thus the 0x00 value preceding the > algorithm-specifying octect can serve as a "marker" to indicate where > the random padding ends. is that correct? Yes. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA12499 for ietf-openpgp-bks; Sun, 9 Jul 2000 22:00:20 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA12495 for ; Sun, 9 Jul 2000 22:00:18 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 14102 invoked from network); 10 Jul 2000 05:01:39 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 05:01:39 -0000 To: ietf-openpgp@imc.org Subject: Re: 5.1 Clarification re padding In-Reply-To: <4.3.2.7.0.20000610122529.00b4f188@mail.comasp.com> References: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> <20000710125356J.1001@eccosys.com> <4.3.2.7.0.20000610122529.00b4f188@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710140209P.1001@eccosys.com> Date: Mon, 10 Jul 2000 14:02:09 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 39 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: Re: 5.1 Clarification re padding Date: Sat, 10 Jun 2000 12:32:28 +0800 Message-ID: <4.3.2.7.0.20000610122529.00b4f188@mail.comasp.com> > At 12:53 PM 10/07/2000 +0900, sen_ml@eccosys.com wrote: > > > > > >to all: > >i've been curious about the length of the random padding octets. i > >presume none of them are allowed to 0x00 (that's what non-zero data > >means, may be?) and thus the 0x00 value preceding the > >algorithm-specifying octect can serve as a "marker" to indicate where > >the random padding ends. is that correct? > > Yes. The doc located at: > > ftp.pgpi.org/pub/pgp/2.x/doc/pgformat.txt > > explains that in the section entitled: > > "Conventional Data Encryption Key (DEK) "packet"" > > It also notes it in 2437 (with reference to Ulf's pointers to the padding > section/s) and 2313, that you have to use NON ZERO values in the random number. thanks for the reference! upon closer inspection of rfc2313, i see: The padding string PS shall consist of k-3-||D|| octets. For block type 00, the octets shall have value 00; for block type 01, they shall have value FF; and for block type 02, they shall be pseudorandomly generated and nonzero. This makes the length of the encryption block EB equal to k. sorry for the extra traffic. Received: by ns.secondary.com (8.9.3/8.9.3) id VAA12330 for ietf-openpgp-bks; Sun, 9 Jul 2000 21:41:23 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id VAA12326 for ; Sun, 9 Jul 2000 21:41:19 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A72D7A700A0; Mon, 10 Jul 2000 12:42:37 0800 Message-Id: <4.3.2.7.0.20000610122529.00b4f188@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 10 Jun 2000 12:32:28 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: 5.1 Clarification re padding Cc: sen_ml@eccosys.com In-Reply-To: <20000710125356J.1001@eccosys.com> References: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> <20000708090745.A418@rho> <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.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:53 PM 10/07/2000 +0900, sen_ml@eccosys.com wrote: >to all: >i've been curious about the length of the random padding octets. i >presume none of them are allowed to 0x00 (that's what non-zero data >means, may be?) and thus the 0x00 value preceding the >algorithm-specifying octect can serve as a "marker" to indicate where >the random padding ends. is that correct? Yes. The doc located at: ftp.pgpi.org/pub/pgp/2.x/doc/pgformat.txt explains that in the section entitled: "Conventional Data Encryption Key (DEK) "packet"" It also notes it in 2437 (with reference to Ulf's pointers to the padding section/s) and 2313, that you have to use NON ZERO values in the random number. Regards Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 http://www.comasp.com Erron Criddle Tel: 08 9386 9534 ejc@comasp.com Fax: 08 9386 9473 Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11691 for ietf-openpgp-bks; Sun, 9 Jul 2000 20:52:06 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11687 for ; Sun, 9 Jul 2000 20:52:04 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 12890 invoked from network); 10 Jul 2000 03:53:25 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 03:53:25 -0000 To: ietf-openpgp@imc.org Subject: Re: 5.1 Clarification re padding In-Reply-To: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> References: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> <20000708090745.A418@rho> <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710125356J.1001@eccosys.com> Date: Mon, 10 Jul 2000 12:53:56 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 24 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: Re: 5.1 Clarification re padding Date: Sat, 10 Jun 2000 10:21:57 +0800 Message-ID: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> ... > I believe I have it worked out now...after reading the "File Formats used > by 2.x" document, 2313 and 2437, does the m value look like this?: > > m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session > key) (checksum) > > The 0x0A represents the Twofish algorithm. that's reflects my current understanding. to all: i've been curious about the length of the random padding octets. i presume none of them are allowed to 0x00 (that's what non-zero data means, may be?) and thus the 0x00 value preceding the algorithm-specifying octect can serve as a "marker" to indicate where the random padding ends. is that correct? Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11004 for ietf-openpgp-bks; Sun, 9 Jul 2000 20:36:00 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA10999 for ; Sun, 9 Jul 2000 20:35:57 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 12577 invoked from network); 10 Jul 2000 03:37:17 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 10 Jul 2000 03:37:17 -0000 To: ietf-openpgp@imc.org Subject: Re: Question regarding 2440:5.2.3.16 In-Reply-To: References: X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000710123746Y.1001@eccosys.com> Date: Mon, 10 Jul 2000 12:37:46 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 36 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: "L. Sassaman" Subject: Question regarding 2440:5.2.3.16 Date: Fri, 7 Jul 2000 16:37:11 -0700 (PDT) Message-ID: > In order for keyservers to take advantage of 2440:5.2.3.16, there must be > a way to authenticate the user submitting the add as being the owner of > the key. so you are suggesting that proof of ownership of the corresponding secret key (via an appropriate signature) should server this purpose, right? > This can be done quite easily using an LDAPS connection, but since most > keyservers do not support such a connection, and some clients do not > either, I think there should be a standard data format for submitting > signed add requests to "HKP" keyservers. > > Werner Koch and I have been discussing this, and he suggests that we put > it into a clear-text signature packet. Would that be suitable? would you mind briefly describing the steps involved for the mechanism you are considering (in terms like "first, the client connects to the server. then the server responds w/..." etc.)? [ i understand what you are saying about the form a signature would take, but i don't see the overall flow of the process of authentication. ] also, is it necessary to consider replay attacks for this kind of scenario? alternatively, would the following scenario be of any concern: an attacker captures a session between a user and a keyserver at some point in time. later, after the user has made several updates to the keyserver, the attacker replays the captured session to set the state of the user's key to an earlier state. Received: by ns.secondary.com (8.9.3/8.9.3) id TAA07005 for ietf-openpgp-bks; Sun, 9 Jul 2000 19:30:48 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id TAA07001 for ; Sun, 9 Jul 2000 19:30:45 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A896FECA00AC; Mon, 10 Jul 2000 10:32:06 0800 Message-Id: <4.3.2.7.0.20000610101735.00b5f808@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 10 Jun 2000 10:21:57 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: 5.1 Clarification re padding In-Reply-To: <20000708090745.A418@rho> References: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.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: Ulf, Sen and others, > > I noticed in section 5.1 that (third last paragraph): > > > "This value is then padded as described in PKCS-1 block type 02 [RFC2437] > > to form the "m" value used in the formulas above." > >The OpenPGP RFC refers to RFC 2313. In a later draft, Jon Callas changed >the reference to RFC 2437, but failed to update the contents. > >In terms of RFC 2437, OpenPGP uses EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. I believe I have it worked out now...after reading the "File Formats used by 2.x" document, 2313 and 2437, does the m value look like this?: m = 0x00 0x02 (random non zero data - 8 bytes minimum) 0x00 0x0A (session key) (checksum) The 0x0A represents the Twofish algorithm. TIA. Regards Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 http://www.comasp.com Erron Criddle Tel: 08 9386 9534 ejc@comasp.com Fax: 08 9386 9473 Received: by ns.secondary.com (8.9.3/8.9.3) id IAA18326 for ietf-openpgp-bks; Sat, 8 Jul 2000 08:36:03 -0700 (PDT) Received: from tomts2-srv.bellnexxia.net (tomts2.bellnexxia.net [209.226.175.140]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA18318 for ; Sat, 8 Jul 2000 08:36:01 -0700 (PDT) Received: from localhost ([64.228.185.33]) by tomts2-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20000708153736.UIYM8045.tomts2-srv.bellnexxia.net@localhost>; Sat, 8 Jul 2000 11:37:36 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13AuKk-00009A-00; Sat, 8 Jul 2000 09:07:50 -0400 Date: Sat, 8 Jul 2000 09:07:46 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: 5.1 Clarification re padding Message-ID: <20000708090745.A418@rho> References: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com>; from ejc@comasp.com on Thu, Jun 08, 2000 at 02:03:58PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, Jun 08, 2000 at 02:03:58PM +0800, Erron Criddle wrote: > I noticed in section 5.1 that (third last paragraph): > "This value is then padded as described in PKCS-1 block type 02 [RFC2437] > to form the "m" value used in the formulas above." The OpenPGP RFC refers to RFC 2313. In a later draft, Jon Callas changed the reference to RFC 2437, but failed to update the contents. In terms of RFC 2437, OpenPGP uses EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. Received: by ns.secondary.com (8.9.3/8.9.3) id EAA09837 for ietf-openpgp-bks; Sat, 8 Jul 2000 04:39:02 -0700 (PDT) Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09833 for ; Sat, 8 Jul 2000 04:39:01 -0700 (PDT) Received: from cyphers.net (aes.cyphers.net [205.178.102.90]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id FXDMV200.K08; Sat, 8 Jul 2000 04:35:26 -0700 Message-ID: <39671334.7A48CC11@cyphers.net> Date: Sat, 08 Jul 2000 04:40:31 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.73 (Macintosh; U; PPC) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ian BROWN CC: ietf-openpgp@imc.org Subject: Re: Forward secrecy References: <6047.963054477@cs.ucl.ac.uk> 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: Yes, it's a common error, but there is in fact only one correct way: IPsec. See RFC 2401 or the working group discussion on this topic for more information. Ian BROWN wrote: > >IPsec is spelled "IPsec". Not "IPSEC". > > grepping through the messages in my ipsec WG folder, I find: > > IPSEC 113 times > IPsec 104 times > IPSec 38 times > > I also see that the IETF Working Group description begins: > > >Rapid advances in communication technology have > >accentuated the need for security in the Internet. > >The IP Security Protocol Working Group (IPSEC) > >will develop mechanisms to protect client > >protocols of IP. A security protocol in the > >network layer will be developed to provide > >cryptographic security services that will flexibly > >support combinations of authentication, integrity, > >access control, and confidentiality. -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. Received: by ns.secondary.com (8.9.3/8.9.3) id EAA08912 for ietf-openpgp-bks; Sat, 8 Jul 2000 04:06:38 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id EAA08907 for ; Sat, 8 Jul 2000 04:06:36 -0700 (PDT) Received: from donatello.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 8 Jul 2000 12:07:57 +0100 X-Mailer: exmh version 2.0.2 To: wprice@cyphers.net cc: Ian BROWN , ietf-openpgp@imc.org Subject: Re: Forward secrecy In-reply-to: Your message of "Fri, 07 Jul 2000 15:34:54 PDT." <39665B0E.C946FF1F@cyphers.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 08 Jul 2000 12:07:57 +0100 Message-ID: <6047.963054477@cs.ucl.ac.uk> From: Ian BROWN Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Will, >IPsec is spelled "IPsec". Not "IPSEC". grepping through the messages in my ipsec WG folder, I find: IPSEC 113 times IPsec 104 times IPSec 38 times I also see that the IETF Working Group description begins: >Rapid advances in communication technology have >accentuated the need for security in the Internet. >The IP Security Protocol Working Group (IPSEC) >will develop mechanisms to protect client >protocols of IP. A security protocol in the >network layer will be developed to provide >cryptographic security services that will flexibly >support combinations of authentication, integrity, >access control, and confidentiality. Ian. Received: by ns.secondary.com (8.9.3/8.9.3) id CAA03486 for ietf-openpgp-bks; Sat, 8 Jul 2000 02:49:10 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA03480 for ; Sat, 8 Jul 2000 02:49:08 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 18933 invoked from network); 8 Jul 2000 09:50:24 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 8 Jul 2000 09:50:24 -0000 To: ietf-openpgp@imc.org Subject: Re: 5.1 Clarification re padding In-Reply-To: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> References: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000708185051L.1001@eccosys.com> Date: Sat, 08 Jul 2000 18:50:51 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 30 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Erron Criddle Subject: 5.1 Clarification re padding Date: Thu, 08 Jun 2000 14:03:58 +0800 Message-ID: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> > To all, > > I noticed in section 5.1 that (third last paragraph): > > -----BEGIN SECTION----- > > "This value is then padded as described in PKCS-1 block type 02 [RFC2437] > to form the "m" value used in the formulas above." > > -----END SECTION----- hmm, that's not what it says in my copy...ah, i see that the quoted part if probably from one of the bis documents. i think that may be an error. > I have looked through RFC2437 and I cannot see any reference to a block > type 02 or any specific details on padding. neither can i ;-) > Can someone please point me to a document that details the padding > mechanism to use in 5.1 as I wouldn't have a clue at the moment :) try rfc 2313. that's the reference made in my copy of rfc 2440, and it does mention a block of type 2. Received: by ns.secondary.com (8.9.3/8.9.3) id XAA26376 for ietf-openpgp-bks; Fri, 7 Jul 2000 23:12:50 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA26371 for ; Fri, 7 Jul 2000 23:12:47 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A99F6380288; Sat, 08 Jul 2000 14:14:07 0800 Message-Id: <4.3.2.7.0.20000608134958.00b43e48@mail.comasp.com> X-Sender: ejc@mail.comasp.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 08 Jun 2000 14:03:58 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: 5.1 Clarification re padding 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: To all, I noticed in section 5.1 that (third last paragraph): -----BEGIN SECTION----- "This value is then padded as described in PKCS-1 block type 02 [RFC2437] to form the "m" value used in the formulas above." -----END SECTION----- I have looked through RFC2437 and I cannot see any reference to a block type 02 or any specific details on padding. Can someone please point me to a document that details the padding mechanism to use in 5.1 as I wouldn't have a clue at the moment :) TIA. Received: by ns.secondary.com (8.9.3/8.9.3) id QAA02830 for ietf-openpgp-bks; Fri, 7 Jul 2000 16:35:52 -0700 (PDT) Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA02822 for ; Fri, 7 Jul 2000 16:35:49 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id QAA26450; Fri, 7 Jul 2000 16:37:19 -0700 Date: Fri, 7 Jul 2000 16:37:11 -0700 (PDT) From: "L. Sassaman" To: ietf-openpgp@imc.org cc: wk@gnupg.org Subject: Question regarding 2440:5.2.3.16 Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Would anyone like to make a suggestion for a standard HTTP mechanism for doing signed key adds to keyservers? In order for keyservers to take advantage of 2440:5.2.3.16, there must be a way to authenticate the user submitting the add as being the owner of the key. This can be done quite easily using an LDAPS connection, but since most keyservers do not support such a connection, and some clients do not either, I think there should be a standard data format for submitting signed add requests to "HKP" keyservers. Werner Koch and I have been discussing this, and he suggests that we put it into a clear-text signature packet. Would that be suitable? - --Len. __ L. Sassaman System Administrator | Technology Consultant | "Credo quia absurdum." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Tertullian -----BEGIN PGP SIGNATURE----- Comment: OpenPGP Encrypted Email Preferred. iD8DBQE5ZmmuPYrxsgmsCmoRAli4AJ4xBu8Vfv3iUVokLY9eJbAHedgS1QCeNTIN NHgFwERh+a6UUZ5V1xRuwes= =NNry -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01763 for ietf-openpgp-bks; Fri, 7 Jul 2000 15:39:18 -0700 (PDT) Received: from enigma.cyphers.net (enigma.cyphers.net [205.178.102.88]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01759 for ; Fri, 7 Jul 2000 15:39:16 -0700 (PDT) Received: from cyphers.net (idea.cyphers.net [205.178.102.83]) by enigma.cyphers.net (Netscape Messaging Server 4.15) with ESMTP id FXCMRJ00.U09; Fri, 7 Jul 2000 15:35:43 -0700 Message-ID: <39665B0E.C946FF1F@cyphers.net> Date: Fri, 07 Jul 2000 15:34:54 -0700 From: Will Price Reply-To: wprice@cyphers.net X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U) X-Accept-Language: en,pdf MIME-Version: 1.0 To: Ian BROWN CC: ietf-openpgp@imc.org Subject: Re: Forward secrecy References: <1227.962985775@cs.ucl.ac.uk> 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: IPsec is spelled "IPsec". Not "IPSEC". Ian BROWN wrote: > I have included a new paragraph on the use ofOpenPGP keys with > network/transport layer security services: > > Where OpenPGP keys are used in protocols such as IPSEC [2] or TLS -- Will Price, Director of Engineering PGP Security, Inc. a division of Network Associates, Inc. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA23948 for ietf-openpgp-bks; Fri, 7 Jul 2000 10:01:46 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA23943 for ; Fri, 7 Jul 2000 10:01:45 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA03684; Fri, 7 Jul 2000 10:02:52 -0700 Date: Fri, 7 Jul 2000 10:02:52 -0700 Message-Id: <200007071702.KAA03684@finney.org> To: I.Brown@cs.ucl.ac.uk Subject: Re: Forward secrecy Cc: ietf-openpgp@imc.org Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > Expired public encryption keys MUST be > deleted by users and keyservers to remove information on old key > pairs. Does this really add enough security to be worth a MUST? An expired public key should not significantly threaten the contents of previously encrypted messages. Furthermore, such deletions can provide at most "security by obscurity" since attackers could easily have made their own archives of the public keys on the key servers. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id JAA21141 for ietf-openpgp-bks; Fri, 7 Jul 2000 09:01:45 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA21133 for ; Fri, 7 Jul 2000 09:01:44 -0700 (PDT) Received: from luke.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 7 Jul 2000 17:02:57 +0100 X-Mailer: exmh version 2.0.2 To: sen_ml@eccosys.com cc: ietf-openpgp@imc.org Subject: Re: Forward secrecy In-reply-to: Your message of "Thu, 06 Jul 2000 16:49:29 +0900." <20000706164929Y.1001@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 07 Jul 2000 17:02:55 +0100 Message-ID: <1227.962985775@cs.ucl.ac.uk> From: Ian BROWN Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the comments :) > -this document seems to be focused on the use of openpgp for mail in > particular. is there anything to be said for other uses? (e.g. > openpgp key usage in ssh) I have included a new paragraph on the use ofOpenPGP keys with network/transport layer security services: Where OpenPGP keys are used in protocols such as IPSEC [2] or TLS [9], they SHOULD NOT be used to encrypt keying material that can later be decrypted if they are compromised. Ideally, they SHOULD be used only to authenticate a forward-secret key negotiation protocol such as Diffie-Hellman [3]. At the least, new short- lifetime key pairs SHOULD be generated for key encryption use. Sound sensible? > i think whether the key distribution should happen automatically > should be a matter of policy. some of us have keypairs of which the > public portion is not really made widely public, nor do we want it to > be made so. perhaps such relevant policy can be expressed in the key > and implementations could interpret it appropriately. I have changed the paragraph as follows: Key distribution can be eased by submitting new keys to key servers, where they will be available for other users to retrieve. Submission and retrieval of generally-available public keys (those self-signed with an exportable signature) SHOULD be performed automatically by software. Expired public encryption keys MUST be deleted by users and keyservers to remove information on old key pairs. Expired private encryption keys MUST be securely deleted to prevent later compromise. > -how about some "secure deletion" references in the references section? I have something by Markus Jakobsson that can go in: we could also mention the relevant DoD requirements. The "revoke and redistribute" requirement on surrendered keys is tricky: as you say, what happens if the client can't contact a keyserver? I suppose the weak answer is that as more and more people get always-on DSL/cable modem connections, and any one of the keyservers can be contacted, this shouldn't happen often (as long as the police don't catch on). But I suppose we could say something like if keyservers are unavailable, the client may queue the revocation for later distribution then export the key. > also, which takes precedence, the deletion of expired keys from > keyservers or the distribution of revoked keys? is this also a matter > of policy that could be reflected in the key? We were thinking of revoked and expired keys as separate categories. Keyservers certainly shouldn't delete revoked keys *until their expiry date is reached* -- at which point they shouldn't be used anyway. Ian :) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA27776 for ietf-openpgp-bks; Thu, 6 Jul 2000 11:49:32 -0700 (PDT) Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id LAA27772 for ; Thu, 6 Jul 2000 11:49:30 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id TAA00156; Thu, 6 Jul 2000 19:59:01 +0100 Message-ID: <3964D551.DB1D6179@algroup.co.uk> Date: Thu, 06 Jul 2000 19:52:01 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: sen_ml@eccosys.com CC: ietf-openpgp@imc.org Subject: Re: Forward secrecy References: <3963142F.E8971209@cs.ucl.ac.uk> <20000706164929Y.1001@eccosys.com> 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: sen_ml@eccosys.com wrote: > > From: Ian Brown > Subject: Forward secrecy > Date: Wed, 05 Jul 2000 11:55:43 +0100 > Message-ID: <3963142F.E8971209@cs.ucl.ac.uk> > > > John Noerenberg suggested we publish it as an informational RFC. We would > > be grateful for feedback from this group before we take that step. > > here are some comments: > > -this document seems to be focused on the use of openpgp for mail in > particular. is there anything to be said for other uses? (e.g. > openpgp key usage in ssh) We should certainly extend it to cover other uses. Good idea. > -section 2.1 says: > > Key distribution can be eased by submitting new keys to key > servers, where they will be available for other users to retrieve. > Submission and retrieval SHOULD be performed automatically by > software. Expired public encryption keys MUST be deleted by users > and keyservers to remove information on old key pairs. Expired > private encryption keys MUST be securely deleted to prevent later > compromise. > > i think whether the key distribution should happen automatically > should be a matter of policy. some of us have keypairs of which the > public portion is not really made widely public, nor do we want it to > be made so. perhaps such relevant policy can be expressed in the key > and implementations could interpret it appropriately. It is a SHOULD rather than a MUST so a compliant implementation can choose to not do it. However, we should probably make a specific note to that effect. OTOH, I notice that one of the changes I intended to make has not been: that is that it is not necessary to delete public keys, only private ones. In fact, expired public keys may be required to check the validity of (old) revocations. > i wonder how much success one will have w/ convincing the > keyserver folks that they should delete expired public keys. i would > like the ability to be able to tell a keyserver to remove a public key > for which i have the corresponding secret key (or may be even the > typically existing email address), but i don't get the impression that > it's a popular idea thing among implementors. I have exchanged some mails with (some of) the keyserver folks, and the widespread use of short-lifetime encryption only keys will kill the keyservers if they do not expire them. So, I think they may well wish to do it. > -section 2.2 says: > > Before an OpenPGP client exports a private key as plaintext, the > associated public key MUST be revoked and redistributed. > > i think i see a good reason for this, but i wonder whether it is > practical. doesn't redistribution of the key require net > access? > > to implement this correctly, when requested to export > a private key as plaintext, the implementation first revokes the key, > then redistributes the key by sending it to the keyservers, and > then exports the private key (perhaps after confirming that the > redistribution has been successful). if it cannot contact a keyserver > (or verify that redistribution was successful), a correct > implementation would not export the private key as plaintext, > i presume. perhaps i'm nitpicking... I guess it needs addressing. > also, which takes precedence, the deletion of expired keys from > keyservers or the distribution of revoked keys? is this also a matter > of policy that could be reflected in the key? > > -how about saying "attackers" instead of "hackers" in section 6? Sure. > -how about some "secure deletion" references in the references section? For example? > off-topic: how about you guys write an informational rfc that suggests > best practice methods for email message header confidentiality ;-) I thought someone else was doing that already? Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ Received: by ns.secondary.com (8.9.3/8.9.3) id AAA06930 for ietf-openpgp-bks; Thu, 6 Jul 2000 00:48:01 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA06926 for ; Thu, 6 Jul 2000 00:47:59 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 4717 invoked from network); 6 Jul 2000 07:49:12 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Jul 2000 07:49:12 -0000 To: ietf-openpgp@imc.org Subject: Re: Forward secrecy In-Reply-To: <3963142F.E8971209@cs.ucl.ac.uk> References: <3963142F.E8971209@cs.ucl.ac.uk> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000706164929Y.1001@eccosys.com> Date: Thu, 06 Jul 2000 16:49:29 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 66 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: From: Ian Brown Subject: Forward secrecy Date: Wed, 05 Jul 2000 11:55:43 +0100 Message-ID: <3963142F.E8971209@cs.ucl.ac.uk> > John Noerenberg suggested we publish it as an informational RFC. We would > be grateful for feedback from this group before we take that step. here are some comments: -this document seems to be focused on the use of openpgp for mail in particular. is there anything to be said for other uses? (e.g. openpgp key usage in ssh) -section 2.1 says: Key distribution can be eased by submitting new keys to key servers, where they will be available for other users to retrieve. Submission and retrieval SHOULD be performed automatically by software. Expired public encryption keys MUST be deleted by users and keyservers to remove information on old key pairs. Expired private encryption keys MUST be securely deleted to prevent later compromise. i think whether the key distribution should happen automatically should be a matter of policy. some of us have keypairs of which the public portion is not really made widely public, nor do we want it to be made so. perhaps such relevant policy can be expressed in the key and implementations could interpret it appropriately. i wonder how much success one will have w/ convincing the keyserver folks that they should delete expired public keys. i would like the ability to be able to tell a keyserver to remove a public key for which i have the corresponding secret key (or may be even the typically existing email address), but i don't get the impression that it's a popular idea thing among implementors. -section 2.2 says: Before an OpenPGP client exports a private key as plaintext, the associated public key MUST be revoked and redistributed. i think i see a good reason for this, but i wonder whether it is practical. doesn't redistribution of the key require net access? to implement this correctly, when requested to export a private key as plaintext, the implementation first revokes the key, then redistributes the key by sending it to the keyservers, and then exports the private key (perhaps after confirming that the redistribution has been successful). if it cannot contact a keyserver (or verify that redistribution was successful), a correct implementation would not export the private key as plaintext, i presume. perhaps i'm nitpicking... also, which takes precedence, the deletion of expired keys from keyservers or the distribution of revoked keys? is this also a matter of policy that could be reflected in the key? -how about saying "attackers" instead of "hackers" in section 6? -how about some "secure deletion" references in the references section? off-topic: how about you guys write an informational rfc that suggests best practice methods for email message header confidentiality ;-) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id XAA04085 for ietf-openpgp-bks; Wed, 5 Jul 2000 23:09:56 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA04081 for ; Wed, 5 Jul 2000 23:09:54 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 2712 invoked from network); 6 Jul 2000 06:11:06 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 6 Jul 2000 06:11:06 -0000 To: ietf-openpgp@imc.org Subject: priority of clarity of specifications (was Re: OpenPGP should be called ClosedPGP) In-Reply-To: References: <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000706151123R.1001@eccosys.com> Date: Thu, 06 Jul 2000 15:11:23 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 95 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: thanks for the response. sorry for taking so long to reply. From: Jon Callas Subject: Re: OpenPGP should be called ClosedPGP Date: Wed, 5 Jul 2000 00:21:38 -0700 Message-ID: > One of the things to remember about 2440 -- and stated in the document > abstract -- is that it isn't a how-to guide for writing an application. > It's a description of how the data is laid out, and (more or less) what it > means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide." sure. i didn't miss out on that point. the kinds of changes i had in mind have more to do w/ the particular explanations, wording, order of introducing terms, etc. i found parts of the document difficult to understand and could be made easier to understand for others who are still struggling w/ the document and for future readers. i have pointed out some of these things that occurred to me already, but would it help to mention them again? some of the points have gone unaddressed, so i can only guess as to whether the points are irrelevant, ignored, forgotten, etc. as a side note, on other pgp-related mailing lists, i've seen people ask questions about pgp and they are then referred to rfc 2440. i imagine it could be rather tough for many of these folks to understand the rfc (it was for me, at least) -- perhaps some other document should exist for such situations. > Lots of things are assumed in the document. For example, it's assumed you > know what a cipher is. Many of the references to ciphers are pretty terse, > and I know I wouldn't want to implement from it and it alone. that's what i found when i first went through it. after sitting down w/ schneier's book though, i was able to make a lot more sense of the rfc, but even w/ improved understanding, i found sections hard to understand more because of issues such as wording. > Just last week, for example, someone pointed out to me that the > reference for Triple-DES was dangling. We all looked around for a > good reference to 3DES, and didn't come up with one! I was sure > there was some RFC for it, myself, and there isn't. This is amusing, > since 3DES is the cross-group defacto meta-standard algorithm in the > IETF, and yet we don't have a good place to say, "Hey, here's how > 3DES is done." perhaps it's time for an informational rfc for triple des then. but may be that's an issue that is more general than for just this working group... > I changed the 2440bis reference to point to Schneier, which is > better than nothing, but still not great. As we find those things, > we'll shoot them. out of curiosity, if schneier's book were freely available, then would that still be a problem? > Furthermore, there are things that we have agreed *not* to discuss here. A > close reading of 2440 will display references to key servers, trust, and > other things that are beyond its scope. it might be helpful to have a list of what is and isn't in scope in one place (say in the rfc or on among the working group web pages) -- this might make it clearer for those who weren't around for the discussions. i assume that newcomers are not unwelcome. > We've also discussed having implementation guides. That is also something > that would be great to do. i think that would be interesting and worthwhile, but i'm not primarily concerned w/ an implementation guide at this point. > But I don't think you should do an annotated 2440 or a re-organized > one. i hear you, but i guess i don't see why an annotated version would be a bad idea. what kind of downside is there in producing such a thing? > We want to get to Standard as quickly as possible, and there's > already been a lot of work getting everyone to agree that what we > have is reasonable, if not perfect. what concerns me is that the standard that we get may be harder to understand than necessary (i think it already is). as has been pointed out on numerous occasions already, the format is already fairly complex (compared to what might be produced if one were to start from scratch -- i am not suggesting that compatibility issues be ignored, just clarifying my statement). i would think that particularly in an area that is so focused on security that one would want the format to be as simple as possible and the descriptions to be as clear as possible to prevent misunderstandings that might lead to misuse or misimplementation and consequently to security problems. my impression is that this does not appear to be a high priority. am i mistaken? Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04489 for ietf-openpgp-bks; Wed, 5 Jul 2000 03:57:14 -0700 (PDT) Received: from bells.cs.ucl.ac.uk (bells.cs.ucl.ac.uk [128.16.5.31]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id DAA04485 for ; Wed, 5 Jul 2000 03:57:13 -0700 (PDT) Received: from dopey.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 5 Jul 2000 11:58:28 +0100 Message-ID: <3963142F.E8971209@cs.ucl.ac.uk> Date: Wed, 05 Jul 2000 11:55:43 +0100 From: Ian Brown X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openpgp@imc.org Subject: Forward secrecy Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I don't know how much everyone has seen of the UK government's current attempt to legislate for access to keys, but despite extreme opposition they seem set to push through powers for "information disclosure" orders that allow *any public authority* to demand keys (on pain of two years' imprisonment) and impose a gagging order that prevents you telling anyone but your lawyer (or go to jail for five years). Adam Back, Ben Laurie and I have been working on a draft that would allow OpenPGP software to minimise the damage such a notice could cause to a PGP user. It specifies mechanisms for using short-lifetime and one-time keys to limit the amount of information that becomes vulnerable after key compromise. John Noerenberg suggested we publish it as an informational RFC. We would be grateful for feedback from this group before we take that step. The current version is at http://www.cs.ucl.ac.uk/staff/I.Brown/openpgp-pfs.txt Thanks! Ian :) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA27059 for ietf-openpgp-bks; Wed, 5 Jul 2000 02:11:11 -0700 (PDT) Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id CAA27047 for ; Wed, 5 Jul 2000 02:11:09 -0700 (PDT) Received: from algroup.co.uk (naughty.ben.algroup.co.uk [193.133.15.107]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id KAA15732; Wed, 5 Jul 2000 10:20:01 +0100 Message-ID: <3962FC3B.CFF633AC@algroup.co.uk> Date: Wed, 05 Jul 2000 10:13:31 +0100 From: Ben Laurie Organization: A.L. Group plc X-Mailer: Mozilla 4.7 [en] (WinNT; I) MIME-Version: 1.0 To: Jon Callas CC: ietf-openpgp@imc.org Subject: Re: OpenPGP should be called ClosedPGP References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> 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: Jon Callas wrote: > This is amusing, since 3DES is the cross-group defacto > meta-standard algorithm in the IETF, and yet we don't have a good place to > say, "Hey, here's how 3DES is done." I changed the 2440bis reference to > point to Schneier, which is better than nothing, but still not great. As we > find those things, we'll shoot them. If you are going to point at books, you should point at Menezes et al., too. Cheers, Ben. -- http://www.apache-ssl.org/ben.html Coming to ApacheCon Europe 2000? http://apachecon.com/ Received: by ns.secondary.com (8.9.3/8.9.3) id AAA21697 for ietf-openpgp-bks; Wed, 5 Jul 2000 00:42:26 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA21689 for ; Wed, 5 Jul 2000 00:42:24 -0700 (PDT) Received: from [63.73.97.187] (63.73.97.187) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1d11); Wed, 5 Jul 2000 00:43:39 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000629194636M.1001@eccosys.com> References: <20000628194342Q.1001@eccosys.com> <20000628190322.A1351@rho> <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> Date: Wed, 5 Jul 2000 00:21:38 -0700 To: ietf-openpgp@imc.org, sen_ml@eccosys.com From: Jon Callas Subject: Re: OpenPGP should be called ClosedPGP Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: One of the things to remember about 2440 -- and stated in the document abstract -- is that it isn't a how-to guide for writing an application. It's a description of how the data is laid out, and (more or less) what it means. It is "OpenPGP Formats" not "OpenPGP Implementation Guide." Lots of things are assumed in the document. For example, it's assumed you know what a cipher is. Many of the references to ciphers are pretty terse, and I know I wouldn't want to implement from it and it alone. Just last week, for example, someone pointed out to me that the reference for Triple-DES was dangling. We all looked around for a good reference to 3DES, and didn't come up with one! I was sure there was some RFC for it, myself, and there isn't. This is amusing, since 3DES is the cross-group defacto meta-standard algorithm in the IETF, and yet we don't have a good place to say, "Hey, here's how 3DES is done." I changed the 2440bis reference to point to Schneier, which is better than nothing, but still not great. As we find those things, we'll shoot them. Furthermore, there are things that we have agreed *not* to discuss here. A close reading of 2440 will display references to key servers, trust, and other things that are beyond its scope. Trust, in particular, is something that the working group agreed not to put into 2440. At that time, we agreed to let people write informational RFCs on various trust models. If someone wants to write an informational RFC, that's a good one. We've also discussed having implementation guides. That is also something that would be great to do. But I don't think you should do an annotated 2440 or a re-organized one. We want to get to Standard as quickly as possible, and there's already been a lot of work getting everyone to agree that what we have is reasonable, if not perfect. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id JAA22574 for ietf-openpgp-bks; Tue, 4 Jul 2000 09:20:31 -0700 (PDT) Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA22569 for ; Tue, 4 Jul 2000 09:20:29 -0700 (PDT) From: sen_ml@eccosys.com Received: (qmail 16419 invoked from network); 4 Jul 2000 16:21:37 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 4 Jul 2000 16:21:37 -0000 To: ietf-openpgp@imc.org Subject: Re: Implementation doc. In-Reply-To: <4.3.0.20000630095636.00bae460@mail.comasp.com> References: <20000629113155.C3610@djebel.gnupg.de> <20000629194636M.1001@eccosys.com> <4.3.0.20000630095636.00bae460@mail.comasp.com> X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000705012144I.1001@eccosys.com> Date: Wed, 05 Jul 2000 01:21:44 +0900 X-Dispatcher: imput version 20000228(IM140) Lines: 35 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: sorry for the late response. From: Erron Criddle Subject: Implementation doc. Date: Fri, 30 Jun 2000 10:26:19 +0800 Message-ID: <4.3.0.20000630095636.00bae460@mail.comasp.com> > Although implementation testing is very important and would require 2440bis > to remain reasonably static for the that to happen, it may be possible to > also implement a document in parallel that accompanies 2440 and would be > basically targeted at the implementor. This doc could provide > implementation guidelines in a "summarised" fashion and would refer to 2440 > for further understanding. > > Basically it would be targeted at implementors that are starting > from scratch. i am not so sure of what form the output of such a process should take -- but how about an "annotated rfc 2440" for starters? we can use whatever the latest document (bis or rfc) and provide annotations off of that for clarifying matters. perhaps some of the annotations can be merged in a future rfc if people think there are relevant points made. > One possible way to move ahead with this document is to make an FTP site > available so that anybody could upload their own "summaries" or > implementation notes. From this, we can then consolidate the information > and create another doc that is a basic guideline for implementing OpenPGP. i have no problem w/ the mechanism, but the "consolidator" of these notes may have to be in a position where looking at various implementation notes does not cause any legal difficulties (cf. the discussion of being able to claim that one truly created an independent implementation) -- unless some precautions are taken w.r.t. the content of what is uploaded.