From owner-ietf-openpgp@mail.imc.org Tue Jul 1 04:15:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA02497 for ; Tue, 1 Jul 2003 04:15:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h617vUFK019713 for ; Tue, 1 Jul 2003 00:57:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h617vUYE019710 for ietf-openpgp-bks; Tue, 1 Jul 2003 00:57:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h617vTFK019698 for ; Tue, 1 Jul 2003 00:57:29 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.182] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2) for ; Tue, 1 Jul 2003 00:57:25 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 01 Jul 2003 00:57:29 -0700 Subject: Re: key flag for authentication From: Jon Callas To: OpenPGP Message-ID: In-Reply-To: <003901c33356$4e3e0fc0$c23fa8c0@transarc.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Is there a consensus for this? I'm happy with anything, myself. Jon From owner-ietf-openpgp@mail.imc.org Tue Jul 1 11:14:43 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04139 for ; Tue, 1 Jul 2003 11:14:43 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61EkCFK058673 for ; Tue, 1 Jul 2003 07:46:12 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61EkC9p058672 for ietf-openpgp-bks; Tue, 1 Jul 2003 07:46:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from lake.cyberia.net.lb (lake.cyberia.net.lb [195.112.195.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61Ek9FK058655 for ; Tue, 1 Jul 2003 07:46:10 -0700 (PDT) (envelope-from matic@cyberia.net.lb) Received: from ppp-07-23.cyberia.net.lb ([195.112.205.121]) by lake.cyberia.net.lb with SMTP id <20030701143549.GBRD9885.lake@ppp-07-23.cyberia.net.lb>; Tue, 1 Jul 2003 17:35:49 +0300 From: "Imad R. Faiad" To: ietf-openpgp@imc.org Cc: Ian Brown Subject: Re: Suggestion for the signing subkey problem Date: Tue, 01 Jul 2003 16:45:51 +0200 Message-ID: References: <047b01c33e89$fd852930$39632352@happy> In-Reply-To: <047b01c33e89$fd852930$39632352@happy> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h61EkBFK058668 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 Hello Ian, Alice and Bob use OpenPGP to securely communicate with each other. They both are prolific with their use of subkeys for signing and encryption. 1) Eve obtains Alice's public key. 2) Generates a Master Key with as many of the attributes as Alice's master key. 3) She then extracts all the public subkey which are Alice's key and binds them to the Master Key generated in 1). 4) She generates a signing subkey. 5) She then generates an encryption subkey, in such a way so that it will be the most likely one to be used by an OpenPGP implementation. 6) She performs steps 1) through 5), with Bob's key in mind. 7) Both fake keys are then submitted to the keyserver. 8) She sit in the middle intercepting and forwarding Alice's messages to Bob and vise versa. 9) She sends a message to Bob, which is at least signed with the signing subkey of Alice's fake key. Does the same with Alice using the signing subkey in Bob's fake key. 10) Alice and Bob thinking that the other party must have generated yet another subkey update their copy from the servers. 11) In both cases the message authenticates, giving credence to the respective fake keys. 12) In the worst case scenario, Alice and Bob, will start using the other's fake key, while each is ignorant that the other party is using his fake key. Since, Eve is in the middle, decrypting the messages, then re-encrypting and forwarding them to the other party. I know that the above may not be the best. But, I am sure, that someone, with better skills than mine, can refine, or come up with one which is a lot more effective than the above. The above sounds implausible to you? Think again, while you think that you know what you are doing, most OpenPGP users don't, so don't trust that they do. No fool is going to attack the cryptographic aspect of OpenPGP. Subkeys, used incorrectly, gives yet another avenue for a would be attacker, to exploit the vulnerabilities of the user. Please read this:- http://home.earthlink.net/~cortana/johnny.pdf The users are finding hard to understand the simple aspects of OpenPGP. The user interface has yet to evolve to present such simple aspects to the user in an easily understood manner. I wish that someone from say the PGP team, can comment on the impact of the prolific use of subkeys on the user interface of their software. OpenPGP is not a Diffie-Hellman key exchange protocol, people are in the middle of it, and they do err... Now, which you do you prefer, more bells and whistles, which will be mis-understood, and mis-used, or less which is better understood, and more likely to be used in a more idiot proof manner. There are a spectrum of solutions. On the one extreme there is the scalpel school of thought which believes that if something is questionable, you get rid of it altogether, to put my suggestion on the Master key/ one subkey restriction, into perspective. It does not mean that I belong to the "scalpel school of thought". Nor do I profess such a proposed solution as a religion... I could care less what the adopted solution is, as long as it addresses the root of the problem to my satisfaction. David Shaw's patch, does not solve the problem. Why shouldn't subkeys be regarded like any other keys. What applies to key, should apply to them too. my 2c Best Regards Imad R. Faiad On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: > >> >I am amazed that this thread is still running several weeks >> after you >> >started it, with virtually every response refuting your arguments... >> > >> And what amazes me, is that you have yet to grasp what we are >> talking about! Please re-read the thread, some issues have >> been addressed. I sincerely hope that you re-read each and >> every message in that thread, because, you are taylor made >> for the kind of attacks which can be inflicted to your OpenPGP keys. > >I've read all the messages. Your request that subkey capability be >essentially removed has been rejected by all of them. > >> >RFC 2440 was published five years ago. I look forward to your draft >> >removing multiple subkey capability from it. >> I am no paper pusher, and do not have the funding or >> time/ability to publish RFC's > >So I guess this thread is at an end then, with the capability remaining. > > -----BEGIN PGP SIGNATURE----- Version: 8.0.2irf Comment: KeyID: 0xBCC31718833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBPwGdvrzDFxiDPxutAQKy3gf/Vt7ZfERneXijPcN2LqvxKQXKG7QO44R/ Yh7jKigtTVU2MYNV5/htjaFXtg4pdL/syndT4uq4o5SzfenXK1zzgQFgesZrhakw B8JzHzhWibDJIiURKnSJgaxoxPASkyhaAPzcE8Z/d1oZexXhRhqbQw3Hlrtrn3+g zt/ZrnjukYMkPUYGKuSWmLI7ps8A5Hd4XWjmBGh+hV2kFUV6S3q1Du65zmWSvvdX h1FkQjCc5xczkBcmoVUP0hyMgUG7p7V7F65sX8BePTh2HB/sVd6gASUDjIERtd2k EXcP1ipt4xeoCpxGv5WcRYyJBPaelYbZzumxw3gbeGy7oV8sb7DBig== =Tfpn -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Jul 1 12:20:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06373 for ; Tue, 1 Jul 2003 12:20:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61G07FK066320 for ; Tue, 1 Jul 2003 09:00:07 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61G07Fa066319 for ietf-openpgp-bks; Tue, 1 Jul 2003 09:00:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61G03FK066296 for ; Tue, 1 Jul 2003 09:00:04 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61FxoKl024580; Tue, 1 Jul 2003 11:59:59 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61FvEjO018614; Tue, 1 Jul 2003 11:57:16 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h61FvDU8017556; Tue, 1 Jul 2003 11:57:14 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h61FvDY5026607; Tue, 1 Jul 2003 11:57:13 -0400 (EDT) To: "Imad R. Faiad" Cc: ietf-openpgp@imc.org, Ian Brown From: Derek Atkins Subject: Re: Suggestion for the signing subkey problem References: <047b01c33e89$fd852930$39632352@happy> Date: 01 Jul 2003 11:57:13 -0400 In-Reply-To: Message-ID: Lines: 126 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ok, putting my chair hat on. Removing subkeys from 2440bis is OUT OF SCOPE. Fixing security problems with subkeys is IN SCOPE. The goal of 2440bis is to fix security and interop issues, not remove functionality just because some people have minimalist views. While minimalism is a virtue, it (like all things) should be applied in moderation. Having said that, and taking my chair hat off.... "Imad R. Faiad" writes: > 9) She sends a message to Bob, which > is at least signed with the signing > subkey of Alice's fake key. Does > the same with Alice using the signing > subkey in Bob's fake key. Except there is no subkey-signature from the signing subkey on the fake-Alice master key, so Bob wont accept it as a valid subkey. > 10) Alice and Bob thinking that the other > party must have generated yet another > subkey update their copy from the servers. Except they wont think this, because the subkey wont validate on Eve's replacement keys. > 11) In both cases the message authenticates, > giving credence to the respective fake keys. > 12) In the worst case scenario, Alice > and Bob, will start using the other's > fake key, while each is ignorant > that the other party is using his fake > key. Since, Eve is in the middle, > decrypting the messages, then > re-encrypting and forwarding them to > the other party. Well, first, if Alice and Bob have signed each other's master key, then they wont use the fake keys. > The above sounds implausible to you? It sounds implausible in the face of a real WoT between Alice and Bob. It also sounds implausible once Alice and Bob have keys in the local keyright. It is certainly plausible on a first-contact basis without a real WoT. I will note that UI issues are out of scope here. The UI issue is an implementation issue and has nothing to do with interop. The purpose of 2440bis is to fix security and interop problems; how that is translated to a UI is implementation dependent and has little to do with the protocol. > There are a spectrum of solutions. > On the one extreme there is the scalpel school of > thought which believes that if something > is questionable, you get rid of it altogether, > to put my suggestion on the Master key/ one > subkey restriction, into perspective. It does > not mean that I belong to the "scalpel school of > thought". Nor do I profess such a proposed solution > as a religion... I could care less what the adopted > solution is, as long as it addresses the root of > the problem to my satisfaction. As I have already stated, removing subkeys is out of scope. > David Shaw's patch, does not solve the problem. Can you please show an example where David's patch does not work? In particular, the approach where the master key and subkey cross-sign each other seems to protect against all the attacks you've proposed so far... The case where Alice does not know Bob's master key is a WoT issue and has nothing to do with subkeys -- the subkey issue is knowing what master key a subkey belongs to. > Why shouldn't subkeys be regarded like any other > keys. What applies to key, should apply to them > too. In what way are subkeys not regarded like master keys? > my 2c > > Best Regards > > Imad R. Faiad -derek > On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: > > > > >> >I am amazed that this thread is still running several weeks > >> after you > >> >started it, with virtually every response refuting your arguments... > >> > > >> And what amazes me, is that you have yet to grasp what we are > >> talking about! Please re-read the thread, some issues have > >> been addressed. I sincerely hope that you re-read each and > >> every message in that thread, because, you are taylor made > >> for the kind of attacks which can be inflicted to your OpenPGP keys. > > > >I've read all the messages. Your request that subkey capability be > >essentially removed has been rejected by all of them. > > > >> >RFC 2440 was published five years ago. I look forward to your draft > >> >removing multiple subkey capability from it. > >> I am no paper pusher, and do not have the funding or > >> time/ability to publish RFC's > > > >So I guess this thread is at an end then, with the capability remaining. > > > > > > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Tue Jul 1 14:41:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10441 for ; Tue, 1 Jul 2003 14:41:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJBFK074231 for ; Tue, 1 Jul 2003 11:19:11 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61IJB8x074230 for ietf-openpgp-bks; Tue, 1 Jul 2003 11:19:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from lake.cyberia.net.lb (lake.cyberia.net.lb [195.112.195.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJ8FK074217 for ; Tue, 1 Jul 2003 11:19:08 -0700 (PDT) (envelope-from matic@cyberia.net.lb) Received: from ppp-12-83.cyberia.net.lb ([195.112.203.84]) by lake.cyberia.net.lb with SMTP id <20030701180852.GEPX9885.lake@ppp-12-83.cyberia.net.lb>; Tue, 1 Jul 2003 21:08:52 +0300 From: "Imad R. Faiad" To: ietf-openpgp@imc.org Cc: Derek Atkins Subject: Re: Suggestion for the signing subkey problem Date: Tue, 01 Jul 2003 20:18:55 +0200 Message-ID: References: <047b01c33e89$fd852930$39632352@happy> In-Reply-To: X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h61IJAFK074226 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 Greetings, Except that the human psyche does not function in the manner in which your protocol thinks it should. And that may be it's shortcomings. Packets, protocols, and RFC's are meaningless, when the limitations of the human mind are not taken into consideration. By UI, I do not mean an implementation, I mean, the UI of your RFC, yes, RFC's have a UI... UI does not only stand for "User Interface", it is also what I call "Human Element". You talk about the WoT, but, isn't that broken with subkeys... That is all I have to say, and only time will prove me right. If you do find me obnoxious, then, by all means do let me know, I will then refrain for posting anything to this forum. Best Regards Imad R. Faiad On 01 Jul 2003 11:57:13 -0400, you wrote: >Ok, putting my chair hat on. > >Removing subkeys from 2440bis is OUT OF SCOPE. Fixing security >problems with subkeys is IN SCOPE. The goal of 2440bis is to fix >security and interop issues, not remove functionality just because >some people have minimalist views. > >While minimalism is a virtue, it (like all things) should be applied >in moderation. > >Having said that, and taking my chair hat off.... > >"Imad R. Faiad" writes: > >> 9) She sends a message to Bob, which >> is at least signed with the signing >> subkey of Alice's fake key. Does >> the same with Alice using the signing >> subkey in Bob's fake key. > >Except there is no subkey-signature from the signing subkey on the >fake-Alice master key, so Bob wont accept it as a valid subkey. > >> 10) Alice and Bob thinking that the other >> party must have generated yet another >> subkey update their copy from the servers. > >Except they wont think this, because the subkey wont validate on >Eve's replacement keys. > >> 11) In both cases the message authenticates, >> giving credence to the respective fake keys. >> 12) In the worst case scenario, Alice >> and Bob, will start using the other's >> fake key, while each is ignorant >> that the other party is using his fake >> key. Since, Eve is in the middle, >> decrypting the messages, then >> re-encrypting and forwarding them to >> the other party. > >Well, first, if Alice and Bob have signed each other's master key, >then they wont use the fake keys. > >> The above sounds implausible to you? > >It sounds implausible in the face of a real WoT between >Alice and Bob. It also sounds implausible once Alice and >Bob have keys in the local keyright. It is certainly plausible >on a first-contact basis without a real WoT. > >I will note that UI issues are out of scope here. The UI issue >is an implementation issue and has nothing to do with interop. >The purpose of 2440bis is to fix security and interop problems; >how that is translated to a UI is implementation dependent and has >little to do with the protocol. > >> There are a spectrum of solutions. >> On the one extreme there is the scalpel school of >> thought which believes that if something >> is questionable, you get rid of it altogether, >> to put my suggestion on the Master key/ one >> subkey restriction, into perspective. It does >> not mean that I belong to the "scalpel school of >> thought". Nor do I profess such a proposed solution >> as a religion... I could care less what the adopted >> solution is, as long as it addresses the root of >> the problem to my satisfaction. > >As I have already stated, removing subkeys is out of scope. > >> David Shaw's patch, does not solve the problem. > >Can you please show an example where David's patch does not work? >In particular, the approach where the master key and subkey cross-sign >each other seems to protect against all the attacks you've proposed so >far... The case where Alice does not know Bob's master key is a WoT >issue and has nothing to do with subkeys -- the subkey issue is knowing >what master key a subkey belongs to. > >> Why shouldn't subkeys be regarded like any other >> keys. What applies to key, should apply to them >> too. > >In what way are subkeys not regarded like master keys? > >> my 2c >> >> Best Regards >> >> Imad R. Faiad > >-derek > >> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: >> >> > >> >> >I am amazed that this thread is still running several weeks >> >> after you >> >> >started it, with virtually every response refuting your arguments... >> >> > >> >> And what amazes me, is that you have yet to grasp what we are >> >> talking about! Please re-read the thread, some issues have >> >> been addressed. I sincerely hope that you re-read each and >> >> every message in that thread, because, you are taylor made >> >> for the kind of attacks which can be inflicted to your OpenPGP keys. >> > >> >I've read all the messages. Your request that subkey capability be >> >essentially removed has been rejected by all of them. >> > >> >> >RFC 2440 was published five years ago. I look forward to your draft >> >> >removing multiple subkey capability from it. >> >> I am no paper pusher, and do not have the funding or >> >> time/ability to publish RFC's >> > >> >So I guess this thread is at an end then, with the capability >> >remaining. -----BEGIN PGP SIGNATURE----- Version: 8.0.2irf Comment: KeyID: 0xBCC31718833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBPwHP/LzDFxiDPxutAQJMwQf/UNKORxZfDApb5sZWItwkl7bkvJEkOECh SphQ5B5+YWOdm6zjWaK0GKISA7LIwsrOBIWZ7VEpbNHZznbyHMa7pM9iedy3s0p4 29twTgSf7XEGBX0GuJSvsgt8Oh1aJoLQYGXUWS+GJ7rqPzjFuXQKv6h6+fvWMNzf At+9M49H+zrAGFaiWWWX4gErpV74XmaZS63ARyro0taWTHlJY1Flm9OPhbGsA4kQ undI200hv1Z1f4zfCfGqNeyknRQz5dRqQnJ6D1ZwUu1fPtHGCsAaVmL9Mf+kGZ2Q 3gSI0hnYH3MhZWXgMFc1cYxgIhiFqbn/BDLS0isS/9EjG5GGWLJ0qw== =cDhw -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Jul 1 15:24:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13439 for ; Tue, 1 Jul 2003 15:24:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61J0iFK078793 for ; Tue, 1 Jul 2003 12:00:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61J0iXN078792 for ietf-openpgp-bks; Tue, 1 Jul 2003 12:00:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61J0gFK078785 for ; Tue, 1 Jul 2003 12:00:43 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h61J0XgW010993; Tue, 1 Jul 2003 15:00:38 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61IviYj011497; Tue, 1 Jul 2003 14:57:44 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h61IvfU8013096; Tue, 1 Jul 2003 14:57:41 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h61Ivfkm026953; Tue, 1 Jul 2003 14:57:41 -0400 (EDT) To: "Imad R. Faiad" Cc: ietf-openpgp@imc.org From: Derek Atkins Subject: Re: Suggestion for the signing subkey problem References: <047b01c33e89$fd852930$39632352@happy> Date: 01 Jul 2003 14:57:41 -0400 In-Reply-To: Message-ID: Lines: 243 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, "Imad R. Faiad" writes: > Greetings, > > Except that the human psyche does not function in the > manner in which your protocol thinks it should. > And that may be it's shortcomings. The human psyche also doesn't remember 1024-bit numbers or perform RSA encryptions. That's why we have computers, to do a lot of work that the human brain cannot do itself. The point is that the computer does the hard work and presents the information in a form that the human psyche can understand. > Packets, protocols, and RFC's are meaningless, when > the limitations of the human mind are not taken into > consideration. By UI, I do not mean an implementation, > I mean, the UI of your RFC, yes, RFC's have a UI... > UI does not only stand for "User Interface", it is > also what I call "Human Element". Uh, no. Sorry. RFCs certainly have "operational requirements" but there is no UI to an RFC. An RFC is a description of a protocol. Different implementations can present that protocol to users in VERY different ways. Except in very limited ways the RFC does not say how information should be presented to users, and this is a Good Thing. Yes, there is a "human element" in terms of usage constraints, operational considerations, and even security implications, and yes, the RFC can point implementors at a "best current practice" to presenting information. However that is all ancillary information; the RFC is in general a protocol document. > You talk about the WoT, but, isn't that broken > with subkeys... In general, no, it is not. There is a particular problem with signing subkeys not being able to securely refer to the master key (which is what the current proposal is trying to fix), but no, in general there is not a WoT problem with subkeys. Walking through a normal WoT (in one direction -- the other is just a mirror image). Alice wants to send a message to Bob. Alice gets Bob's key and see's that Charlie has signed it. Alice knows Charlie, has verified Charlie's key, and trusts Charlie to properly verify keys, so through the WoT Alice can now trust Bob's key. Alice can now encrypt a message to Bob's key and have some level of assurance that it is correct. An attacker could supply another key on a keyserver with Bob's name, but it wouldn't have Charlie's signature Now, let's look at encryption subkeys. The beginning of the story remains the same, except Charlie is signing Bob's master key. Bob's master key signs the encryption subkey, so Alice knows that Bob wants to use that subkey. An attacker couldn't add another encryption key because it wouldn't be signed by Bob's master key. An attacker could claim an encryption key as their own, but to what end -- they couldn't read the message anyways? At best it provides plausible deniability for the actual recipient of an encrypted message. So we're perfectly safe so far. Let's look at Bob signing messages to Alice. In a normal single-key (RSA or DSA) case we're in the same boat at the first case. Nothing new here. The question is what happens when you introduce signature subkeys? Alice receives a message signed with 'key X'. Bob's "keychain" contains subkey X signed with his master key. So, Alice knows that Bob claims X is his key. Alice knows the master key belongs to Bob from Charlie's signature, so the master key is verified. However, there is a problem here (and in RFC2440). Eve could strip out subkey X from Bob's keychain, put it onto her own and self-sign the subkey with Eve's master key. Now (following 2440) Alice does not know whether key X belongs to Bob or Eve. HOWEVER, if we take a step forward in time and look at the current proposal, where the master key and sub-key co-sign the binding. With the co-signature, key X signs "I belong to Bob's master key B" and Bob's master key signs "key X belongs to me". Now, just having key X you can back-track to Bob's master key and the existing WoT for verification. Even if Eve extracts subkey X and puts it on her keychain a 2440bis-compliant implementation wont accept it, because the subkey wont be co-signed. So signing subkeys are safe (with the change to cosign). > That is all I have to say, and only time > will prove me right. Perhaps, but you have not provided the math to back yourself up. Please, if you see a problem with this proposal please explain it... Please provide the math showing how it doesn't work, or the use cases where the key-bindings are insufficient. We want to make 2440bis complete, and all input is welcome. But please keep the topic to "fixing the subkey problem" instead of "subkeys are bad -- get rid of them". The latter is both unhelpful and derailing, neither of which helps make forward progress. > If you do find me obnoxious, then, by all means > do let me know, I will then refrain for posting > anything to this forum. I have not asked you to refrain from posting. I have asked that posts remain on topic and in-scope. I do not feel that is an unreasonable request. > Best Regards > > Imad R. Faiad -derek > On 01 Jul 2003 11:57:13 -0400, you wrote: > > >Ok, putting my chair hat on. > > > >Removing subkeys from 2440bis is OUT OF SCOPE. Fixing security > >problems with subkeys is IN SCOPE. The goal of 2440bis is to fix > >security and interop issues, not remove functionality just because > >some people have minimalist views. > > > >While minimalism is a virtue, it (like all things) should be applied > >in moderation. > > > >Having said that, and taking my chair hat off.... > > > >"Imad R. Faiad" writes: > > > >> 9) She sends a message to Bob, which > >> is at least signed with the signing > >> subkey of Alice's fake key. Does > >> the same with Alice using the signing > >> subkey in Bob's fake key. > > > >Except there is no subkey-signature from the signing subkey on the > >fake-Alice master key, so Bob wont accept it as a valid subkey. > > > >> 10) Alice and Bob thinking that the other > >> party must have generated yet another > >> subkey update their copy from the servers. > > > >Except they wont think this, because the subkey wont validate on > >Eve's replacement keys. > > > >> 11) In both cases the message authenticates, > >> giving credence to the respective fake keys. > >> 12) In the worst case scenario, Alice > >> and Bob, will start using the other's > >> fake key, while each is ignorant > >> that the other party is using his fake > >> key. Since, Eve is in the middle, > >> decrypting the messages, then > >> re-encrypting and forwarding them to > >> the other party. > > > >Well, first, if Alice and Bob have signed each other's master key, > >then they wont use the fake keys. > > > >> The above sounds implausible to you? > > > >It sounds implausible in the face of a real WoT between > >Alice and Bob. It also sounds implausible once Alice and > >Bob have keys in the local keyright. It is certainly plausible > >on a first-contact basis without a real WoT. > > > >I will note that UI issues are out of scope here. The UI issue > >is an implementation issue and has nothing to do with interop. > >The purpose of 2440bis is to fix security and interop problems; > >how that is translated to a UI is implementation dependent and has > >little to do with the protocol. > > > >> There are a spectrum of solutions. > >> On the one extreme there is the scalpel school of > >> thought which believes that if something > >> is questionable, you get rid of it altogether, > >> to put my suggestion on the Master key/ one > >> subkey restriction, into perspective. It does > >> not mean that I belong to the "scalpel school of > >> thought". Nor do I profess such a proposed solution > >> as a religion... I could care less what the adopted > >> solution is, as long as it addresses the root of > >> the problem to my satisfaction. > > > >As I have already stated, removing subkeys is out of scope. > > > >> David Shaw's patch, does not solve the problem. > > > >Can you please show an example where David's patch does not work? > >In particular, the approach where the master key and subkey cross-sign > >each other seems to protect against all the attacks you've proposed so > >far... The case where Alice does not know Bob's master key is a WoT > >issue and has nothing to do with subkeys -- the subkey issue is knowing > >what master key a subkey belongs to. > > > >> Why shouldn't subkeys be regarded like any other > >> keys. What applies to key, should apply to them > >> too. > > > >In what way are subkeys not regarded like master keys? > > > >> my 2c > >> > >> Best Regards > >> > >> Imad R. Faiad > > > >-derek > > > >> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: > >> > >> > > >> >> >I am amazed that this thread is still running several weeks > >> >> after you > >> >> >started it, with virtually every response refuting your arguments... > >> >> > > >> >> And what amazes me, is that you have yet to grasp what we are > >> >> talking about! Please re-read the thread, some issues have > >> >> been addressed. I sincerely hope that you re-read each and > >> >> every message in that thread, because, you are taylor made > >> >> for the kind of attacks which can be inflicted to your OpenPGP keys. > >> > > >> >I've read all the messages. Your request that subkey capability be > >> >essentially removed has been rejected by all of them. > >> > > >> >> >RFC 2440 was published five years ago. I look forward to your draft > >> >> >removing multiple subkey capability from it. > >> >> I am no paper pusher, and do not have the funding or > >> >> time/ability to publish RFC's > >> > > >> >So I guess this thread is at an end then, with the capability > >> >remaining. > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Tue Jul 1 15:34:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10442 for ; Tue, 1 Jul 2003 14:41:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJZFK074246 for ; Tue, 1 Jul 2003 11:19:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61IJZvj074245 for ietf-openpgp-bks; Tue, 1 Jul 2003 11:19:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from lake.cyberia.net.lb (lake.cyberia.net.lb [195.112.195.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJRFK074236 for ; Tue, 1 Jul 2003 11:19:28 -0700 (PDT) (envelope-from matic@cyberia.net.lb) Received: from ppp-12-83.cyberia.net.lb ([195.112.203.84]) by lake.cyberia.net.lb with SMTP id <20030701180916.GEQC9885.lake@ppp-12-83.cyberia.net.lb>; Tue, 1 Jul 2003 21:09:16 +0300 From: "Imad R. Faiad" To: ietf-openpgp@imc.org Cc: Derek Atkins Subject: Re: Suggestion for the signing subkey problem Date: Tue, 01 Jul 2003 20:19:21 +0200 Message-ID: <75k3gv4vvqi2b0eccqobbp13d3j6jhe4c5@4ax.com> References: <047b01c33e89$fd852930$39632352@happy> In-Reply-To: X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h61IJYFK074240 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 Greetings, Except that the human psyche does not function in the manner in which your protocol thinks it should. And that may be it's shortcomings. Packets, protocols, and RFC's are meaningless, when the limitations of the human mind are not taken into consideration. By UI, I do not mean an implementation, I mean, the UI of your RFC, yes, RFC's have a UI... UI does not only stand for "User Interface", it is also what I call "Human Element". You talk about the WoT, but, isn't that broken with subkeys... That is all I have to say, and only time will prove me right. If you do find me obnoxious, then, by all means do let me know, I will then refrain for posting anything to this forum. Best Regards Imad R. Faiad On 01 Jul 2003 11:57:13 -0400, you wrote: >Ok, putting my chair hat on. > >Removing subkeys from 2440bis is OUT OF SCOPE. Fixing security >problems with subkeys is IN SCOPE. The goal of 2440bis is to fix >security and interop issues, not remove functionality just because >some people have minimalist views. > >While minimalism is a virtue, it (like all things) should be applied >in moderation. > >Having said that, and taking my chair hat off.... > >"Imad R. Faiad" writes: > >> 9) She sends a message to Bob, which >> is at least signed with the signing >> subkey of Alice's fake key. Does >> the same with Alice using the signing >> subkey in Bob's fake key. > >Except there is no subkey-signature from the signing subkey on the >fake-Alice master key, so Bob wont accept it as a valid subkey. > >> 10) Alice and Bob thinking that the other >> party must have generated yet another >> subkey update their copy from the servers. > >Except they wont think this, because the subkey wont validate on >Eve's replacement keys. > >> 11) In both cases the message authenticates, >> giving credence to the respective fake keys. >> 12) In the worst case scenario, Alice >> and Bob, will start using the other's >> fake key, while each is ignorant >> that the other party is using his fake >> key. Since, Eve is in the middle, >> decrypting the messages, then >> re-encrypting and forwarding them to >> the other party. > >Well, first, if Alice and Bob have signed each other's master key, >then they wont use the fake keys. > >> The above sounds implausible to you? > >It sounds implausible in the face of a real WoT between >Alice and Bob. It also sounds implausible once Alice and >Bob have keys in the local keyright. It is certainly plausible >on a first-contact basis without a real WoT. > >I will note that UI issues are out of scope here. The UI issue >is an implementation issue and has nothing to do with interop. >The purpose of 2440bis is to fix security and interop problems; >how that is translated to a UI is implementation dependent and has >little to do with the protocol. > >> There are a spectrum of solutions. >> On the one extreme there is the scalpel school of >> thought which believes that if something >> is questionable, you get rid of it altogether, >> to put my suggestion on the Master key/ one >> subkey restriction, into perspective. It does >> not mean that I belong to the "scalpel school of >> thought". Nor do I profess such a proposed solution >> as a religion... I could care less what the adopted >> solution is, as long as it addresses the root of >> the problem to my satisfaction. > >As I have already stated, removing subkeys is out of scope. > >> David Shaw's patch, does not solve the problem. > >Can you please show an example where David's patch does not work? >In particular, the approach where the master key and subkey cross-sign >each other seems to protect against all the attacks you've proposed so >far... The case where Alice does not know Bob's master key is a WoT >issue and has nothing to do with subkeys -- the subkey issue is knowing >what master key a subkey belongs to. > >> Why shouldn't subkeys be regarded like any other >> keys. What applies to key, should apply to them >> too. > >In what way are subkeys not regarded like master keys? > >> my 2c >> >> Best Regards >> >> Imad R. Faiad > >-derek > >> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: >> >> > >> >> >I am amazed that this thread is still running several weeks >> >> after you >> >> >started it, with virtually every response refuting your arguments... >> >> > >> >> And what amazes me, is that you have yet to grasp what we are >> >> talking about! Please re-read the thread, some issues have >> >> been addressed. I sincerely hope that you re-read each and >> >> every message in that thread, because, you are taylor made >> >> for the kind of attacks which can be inflicted to your OpenPGP keys. >> > >> >I've read all the messages. Your request that subkey capability be >> >essentially removed has been rejected by all of them. >> > >> >> >RFC 2440 was published five years ago. I look forward to your draft >> >> >removing multiple subkey capability from it. >> >> I am no paper pusher, and do not have the funding or >> >> time/ability to publish RFC's >> > >> >So I guess this thread is at an end then, with the capability >> >remaining. -----BEGIN PGP SIGNATURE----- Version: 8.0.2irf Comment: KeyID: 0xBCC31718833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBPwHP/LzDFxiDPxutAQJMwQf/UNKORxZfDApb5sZWItwkl7bkvJEkOECh SphQ5B5+YWOdm6zjWaK0GKISA7LIwsrOBIWZ7VEpbNHZznbyHMa7pM9iedy3s0p4 29twTgSf7XEGBX0GuJSvsgt8Oh1aJoLQYGXUWS+GJ7rqPzjFuXQKv6h6+fvWMNzf At+9M49H+zrAGFaiWWWX4gErpV74XmaZS63ARyro0taWTHlJY1Flm9OPhbGsA4kQ undI200hv1Z1f4zfCfGqNeyknRQz5dRqQnJ6D1ZwUu1fPtHGCsAaVmL9Mf+kGZ2Q 3gSI0hnYH3MhZWXgMFc1cYxgIhiFqbn/BDLS0isS/9EjG5GGWLJ0qw== =cDhw -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jul 3 20:13:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA27879 for ; Thu, 3 Jul 2003 20:13:56 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Nlpqt028487 for ; Thu, 3 Jul 2003 16:47:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63NlpTx028486 for ietf-openpgp-bks; Thu, 3 Jul 2003 16:47:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Nloqt028481 for ; Thu, 3 Jul 2003 16:47:50 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.182] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2) for ; Thu, 3 Jul 2003 16:47:50 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Jul 2003 16:47:52 -0700 Subject: Adding in BZ2 compression? From: Jon Callas To: OpenPGP Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I have a request for an algorithm number for bz2 compression. The implementer in question has promised on a stack of holy books only to use it along with compression prefs. Anyone object strongly? Jon From owner-ietf-openpgp@mail.imc.org Thu Jul 3 22:16:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00339 for ; Thu, 3 Jul 2003 22:16:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h641usqt031663 for ; Thu, 3 Jul 2003 18:56:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h641uspa031662 for ietf-openpgp-bks; Thu, 3 Jul 2003 18:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h641uqqt031656 for ; Thu, 3 Jul 2003 18:56:53 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h641uo2J028482; Thu, 3 Jul 2003 21:56:50 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h641uoxG027530; Thu, 3 Jul 2003 21:56:50 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h641unFJ020495; Thu, 3 Jul 2003 21:56:49 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h641unI9002704; Thu, 3 Jul 2003 21:56:49 -0400 (EDT) To: Jon Callas Cc: OpenPGP Subject: Re: Adding in BZ2 compression? References: From: Derek Atkins Date: 03 Jul 2003 21:56:49 -0400 In-Reply-To: Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just to play devil's advocate, why do we need yet another compression algorithm? -derek Jon Callas writes: > I have a request for an algorithm number for bz2 compression. The > implementer in question has promised on a stack of holy books only to use it > along with compression prefs. Anyone object strongly? > > Jon > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Thu Jul 3 22:24:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00512 for ; Thu, 3 Jul 2003 22:24:52 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6426eqt031971 for ; Thu, 3 Jul 2003 19:06:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6426eUq031970 for ietf-openpgp-bks; Thu, 3 Jul 2003 19:06:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6426cqt031965 for ; Thu, 3 Jul 2003 19:06:38 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h6425GJ13374; Thu, 3 Jul 2003 19:05:16 -0700 Date: Thu, 3 Jul 2003 19:05:16 -0700 From: "Hal Finney" Message-Id: <200307040205.h6425GJ13374@finney.org> To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Adding in BZ2 compression? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > I have a request for an algorithm number for bz2 compression. The > implementer in question has promised on a stack of holy books only to use it > along with compression prefs. Anyone object strongly? I don't see a need to add another compression algorithm unless there is something wrong with the ones we already have. Adding a new one can only hurt interoperability in the long run. What is the reason for adding it? Hal Finney From owner-ietf-openpgp@mail.imc.org Fri Jul 4 00:53:40 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA03834 for ; Fri, 4 Jul 2003 00:53:40 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h644Ltqt035614 for ; Thu, 3 Jul 2003 21:21:55 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h644Lt3M035613 for ietf-openpgp-bks; Thu, 3 Jul 2003 21:21:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h644Lsqt035607 for ; Thu, 3 Jul 2003 21:21:54 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h644Lpw01017 for ietf-openpgp@imc.org; Fri, 4 Jul 2003 00:21:51 -0400 Date: Fri, 4 Jul 2003 00:21:50 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Adding in BZ2 compression? Message-ID: <20030704042150.GY8086@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200307040205.h6425GJ13374@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200307040205.h6425GJ13374@finney.org> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (5% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 03, 2003 at 07:05:16PM -0700, Hal Finney wrote: > > Jon Callas writes: > > I have a request for an algorithm number for bz2 compression. The > > implementer in question has promised on a stack of holy books only > > to use it along with compression prefs. Anyone object strongly? > > I don't see a need to add another compression algorithm unless there is > something wrong with the ones we already have. Adding a new one can only > hurt interoperability in the long run. What is the reason for adding it? I don't have strong feelings for or against adding bz2, but your comment about interoperability raises a related issue. In theory, the preference system would prevent the use of bz2 except when it can be properly handled by the recipient so there should be no interoperability issues. Of course, that's theory. The preference system works quite well on paper, but unfortunately fails in the case where a key is generated in an implementation that can use bz2 and the public key is distributed. Later, the user changes their implementation to one that cannot use bz2. Anyone sending a message to that public key has the belief that bz2 can be safely used, and may well use it, causing a problem since the user's new implementation cannot handle bz2 (even though their key claims they can). I have already seen a few examples of this problem (a PGP-generated key with an IDEA pref being used on GnuPG, and a GnuPG-generated key with a ZLIB pref being used on PGP). I don't think the answer here is to restrict the use of new algorithms. 2440 has this to say, which pretty much eliminates the problem in the design: Since a self-signature contains important information about the key's use, an implementation SHOULD allow the user to rewrite the self-signature, and important information in it, such as preferences and key expiration. I don't advocate making any severe changes in the preference system, but perhaps the language here could be made a bit stronger? Something like "Note that without the ability to rewrite a self-signature, interoperability issues may occur when the same key is used in more than one implementation." would be great. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/BQDe4mZch0nhy8kRAsLRAJsF+Zc8fD85cjGV4JIT8Kv7QJLg5wCffisr U+65IozEBIVm+SznfIwniDk= =9xSE -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jul 4 01:09:28 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04135 for ; Fri, 4 Jul 2003 01:09:27 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h644lbqt036116 for ; Thu, 3 Jul 2003 21:47:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h644lbcJ036115 for ietf-openpgp-bks; Thu, 3 Jul 2003 21:47:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h644laqt036108 for ; Thu, 3 Jul 2003 21:47:36 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h644lXT01295 for ietf-openpgp@imc.org; Fri, 4 Jul 2003 00:47:33 -0400 Date: Fri, 4 Jul 2003 00:47:33 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Two clarifications Message-ID: <20030704044733.GB1023@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (20% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I did a closer read of bis08, and have two minor questions for clarification. Nothing terribly controversial ;) 1) Is the ASCII armor checksum optional? Sections 6 and 6.2 seem to imply that is isn't (they never say "optional" or "if used" or anything like that), but section 6 also says that it MAY be used. 2) Is the 1F direct key signature always a self-signature? Nothing else in the draft seems to say so, and a non-self-signature 1F seems useful, but the grammar in section 11.1 (Key Structures) includes only a "Direct Key Self Signature". Perhaps dropping the word "Self" would make this clearer. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/BQbl4mZch0nhy8kRAgDQAKCCJuLFaouOg8M6KRwz+iZwl2GpZACdED1J IHGqJhvrRyARMcWg8lCOySo= =nmuo -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jul 4 06:13:49 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22256 for ; Fri, 4 Jul 2003 06:13:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h649tNqt073160 for ; Fri, 4 Jul 2003 02:55:23 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h649tNd3073159 for ietf-openpgp-bks; Fri, 4 Jul 2003 02:55:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h649tKqt073144 for ; Fri, 4 Jul 2003 02:55:21 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 19YNBW-0006Jx-00 for ; Fri, 04 Jul 2003 11:48:54 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 19YMOP-00074G-00; Fri, 04 Jul 2003 10:58:09 +0200 To: Jon Callas Cc: OpenPGP Subject: Re: Adding in BZ2 compression? References: From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Fri, 04 Jul 2003 10:58:09 +0200 In-Reply-To: (Jon Callas's message of "Thu, 03 Jul 2003 16:47:52 -0700") Message-ID: <87he621xem.fsf@alberti.g10code.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 03 Jul 2003 16:47:52 -0700, Jon Callas said: > I have a request for an algorithm number for bz2 compression. The > implementer in question has promised on a stack of holy books only to use it > along with compression prefs. Anyone object strongly? I don't see a real advantage. bz2 does only make sense for large files and thus it won't hurt to first but the bz2 compressed data into an appropriate MIME container and then apply OpenPGP. If it is a problem that the signature can only be applied on the compressed data, one should use the PGP/MIME approach and don't combine signature and encryption in one OpenPGP message. Decompressing bz2 requires huge amounts of memory and thus it can't be implemented for small devices. If we assume that people are going to use their keys also on PDAs, we will run into problems with the preferences. Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org From owner-ietf-openpgp@mail.imc.org Fri Jul 4 12:57:03 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01987 for ; Fri, 4 Jul 2003 12:57:03 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64GW3qt002076 for ; Fri, 4 Jul 2003 09:32:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64GW3Ek002075 for ietf-openpgp-bks; Fri, 4 Jul 2003 09:32:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta7.adelphia.net (mta7.adelphia.net [64.8.50.193]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64GVtqt001991 for ; Fri, 4 Jul 2003 09:31:56 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung ([68.168.179.202]) by mta7.adelphia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP id <20030704163151.PQAH1347.mta7.adelphia.net@mwyoung> for ; Fri, 4 Jul 2003 12:31:51 -0400 Message-ID: <002401c34249$96c14440$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: "OpenPGP" References: Subject: Re: Adding in BZ2 compression? Date: Fri, 4 Jul 2003 12:30:26 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: "Derek Atkins" > Just to play devil's advocate, why do we need yet another compression > algorithm? OK... I'll argue the other side for you ;-). Why did we need any more ciphers after adding 3DES? Performance, for one. BZ2 produces smaller output for many common forms of input. If it didn't have any obvious advantage, I'd agree with you; but, it does. It's certainly more useful than two stylistic variants of the same thing, which is what we have now. Turning the question around: what's the harm? Adding another optional compression algorithm won't create any problems we don't already have. (ZLIB is supported by GnuPG but not PGP.) The preference system is the architected solution to this problem. As David notes, moving from one implementation to another requires being able to rewrite preferences, but that's always been the case. Now, given that compression can be done by the end-user, it's hard to argue that *any* algorithm is a have-to-have. (This seems to be the essence of Werner's argument, although he makes it in terms of PGP/MIME, which I don't find compelling for the pure OpenPGP spec.) But since the architecture includes compression, I'd say that including a popular and more powerful algorithm is worthwhile. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPwWrnec3iHYL8FknEQK+kgCfatRR21tyFSM5Oy0T5XO9hr7fTB0An14+ 5fVxGAopM2XWaJY5E/OlodxJ =l/o7 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jul 4 13:33:26 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02663 for ; Fri, 4 Jul 2003 13:33:26 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64H7Rqt004923 for ; Fri, 4 Jul 2003 10:07:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64H7R9s004922 for ietf-openpgp-bks; Fri, 4 Jul 2003 10:07:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64H7Pqt004913 for ; Fri, 4 Jul 2003 10:07:25 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 19YTvn-0008Qu-00 for ; Fri, 04 Jul 2003 19:01:07 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 19YU2M-0007zK-00; Fri, 04 Jul 2003 19:07:54 +0200 To: "Michael Young" Cc: "OpenPGP" Subject: Re: Adding in BZ2 compression? References: <002401c34249$96c14440$c23fa8c0@transarc.ibm.com> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Fri, 04 Jul 2003 19:07:54 +0200 In-Reply-To: <002401c34249$96c14440$c23fa8c0@transarc.ibm.com> (Michael Young's message of "Fri, 4 Jul 2003 12:30:26 -0400") Message-ID: <87u1a2z0d1.fsf@alberti.g10code.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 4 Jul 2003 12:30:26 -0400, Michael Young said: > If it didn't have any obvious advantage, I'd agree with you; but, it does. > It's certainly more useful than two stylistic variants of the same thing, > which is what we have now. Yep, I'd prefer to drop compression algo 1 because 2 is better defined and provides a clean way to specify the used window size. For backward compatibility it can not be done though. > essence of Werner's argument, although he makes it in terms of > PGP/MIME, which I don't find compelling for the pure OpenPGP spec.) OpenPGP is mostly used for email, so PGP/MIME makes a lot of sense. The encapsulation provided by MIME is much more flexible than that of OpenPGP. -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org From owner-ietf-openpgp@mail.imc.org Fri Jul 4 15:24:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06133 for ; Fri, 4 Jul 2003 15:24:35 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64J2Jqt009683 for ; Fri, 4 Jul 2003 12:02:19 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64J2J0U009682 for ietf-openpgp-bks; Fri, 4 Jul 2003 12:02:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64J2Hqt009674 for ; Fri, 4 Jul 2003 12:02:18 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h64J2EH08151 for ietf-openpgp@imc.org; Fri, 4 Jul 2003 15:02:14 -0400 Date: Fri, 4 Jul 2003 15:02:14 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: bis-08 notes Message-ID: <20030704190213.GH1023@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (20% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are the rest of my notes on bis-08. There shouldn't be anything terribly controversial here. This is mostly just language and phrasing stuff. David ======================================== In the IESG Note at the head of the document, there is the phrase "(say for new encryption algorithms for example)". I suggest removing the "for example", as using both "say..." and "...for example" is redundant. ======================================== Section 1.1 (Terms) refers to GnuPG once as "GNUpg". ======================================== Section 3.7.1.3 (Iterated and Salted S2K) contains an extra space before the sentence beginning "Then the salt, followed..." ======================================== Section 5.1 (Public-Key Encrypted Session Key Packet) contains the sentence "An implementation should accept, but not generate a version of 2, which is equivalent to V3 in all other respects.". I suggest rephrasing with RFC-2119 keywords as "An implementation SHOULD accept, but MUST NOT generate a version of 2....". Actually, this whole sentence may be better in the Implementation Nits section where there already is an item for V2 public keys. ======================================== Section 5.2.3.2 (Signature Subpacket Type) contains the sentence "Subpackets that are found on a self-signature are placed on a User ID certification made by the key itself." I suggest removing the words "User ID" as there are other types of self-signatures than User ID certifications (i.e. 1F signatures). ======================================== Section 5.2.3.3 (Notes on Self-Signatures) contains the sentence "If the key is located by key id, then algorithm of the default User ID of the key provides the default symmetric algorithm." "then algorithm" should be "the algorithm". Also, what is a "default User ID"? Is this intended to be an implementation defined default, or was this supposed to say "primary User ID"? ======================================== Section 5.2.3.23 (Reason for Revocation) ends with "A revoked certification no longer is a part of validity calculations." That's a little odd grammar-wise. I suggest "A revoked certification is no longer a part of validity calculations." ======================================== Section 5.2.4 (Computing Signatures) says "A V3 certification hashes the contents of the name packet, without any header." "name packet" should probably be "User ID or attribute packet". ======================================== Section 5.10 (Trust Packet) should probably have some text noting that the format of trust packets are implementation defined. ======================================== Section 6 (Radix-64 Conversions) discusses Radix-64 (and calls it Radix-64) throughout, and then adds "An OpenPGP implementation MAY use ASCII Armor to protect the raw binary data". This statement comes before the format of ASCII Armor is introduced in section 6.2, and Radix-64 isn't equivalent to ASCII Armor anyway (it is a *part* of ASCII Armor, but armor includes the headers and tail as well). I suggest moving that sentence to section 6.2. ======================================== Section 7 (Cleartext signature framework) implies that the only armor header line that may be used in clear signatures is "Hash", which isn't true in practice (Version and Comment are common). Adding an item for "zero or more lines of armor headers" would help. ======================================== Section 7 (Cleartext signature framework) says "If the "Hash" armor header is given, the specified message digest algorithm is used for the signature." "algorithm is" should be "algorithm(s) are" as more than one hash algorithm can be provided on a given Hash line, and more than one Hash line can be given. ======================================== Section 9 (Constants) says "Note that these tables are not exhaustive lists; an implementation MAY implement an algorithm not on these lists." I suggest adding "so long as the algorithm number is chosen from the private or experimental algorithm range." ======================================== Section 10.1 (Transferable Public Keys) says "After the User ID packets there may be one or more Subkey packets." I suggest changing "User ID packets" to "User ID or Attribute packets". ======================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/Bc814mZch0nhy8kRAk/uAKDSKvjI6/41eQIhHCU934fk5hqw5QCeO5Nb GYKFWuYH0RBVXqAU2GqzJsw= =sTMD -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 7 17:48:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17549 for ; Mon, 7 Jul 2003 17:48:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67LN7qt093212 for ; Mon, 7 Jul 2003 14:23:07 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67LN7or093211 for ietf-openpgp-bks; Mon, 7 Jul 2003 14:23:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67LN6qt093195 for ; Mon, 7 Jul 2003 14:23:06 -0700 (PDT) (envelope-from frantz@pwpconsult.com) Received: from h-69-3-26-10.snvacaid.covad.net ([69.3.26.10] helo=[192.168.1.5]) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19ZdRv-0003VF-00 for ietf-openpgp@imc.org; Mon, 07 Jul 2003 14:23:03 -0700 X-Sender: frantz%pwpconsult.com@pop.business.earthlink.net Message-Id: In-Reply-To: <20030704042150.GY8086@jabberwocky.com> References: <200307040205.h6425GJ13374@finney.org> <200307040205.h6425GJ13374@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Jul 2003 11:58:57 -0700 To: ietf-openpgp@imc.org From: Bill Frantz Subject: Re: Adding in BZ2 compression? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:21 PM -0700 7/3/03, David Shaw wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Thu, Jul 03, 2003 at 07:05:16PM -0700, Hal Finney wrote: >> >> Jon Callas writes: >> > I have a request for an algorithm number for bz2 compression. The >> > implementer in question has promised on a stack of holy books only >> > to use it along with compression prefs. Anyone object strongly? >> >> I don't see a need to add another compression algorithm unless there is >> something wrong with the ones we already have. Adding a new one can only >> hurt interoperability in the long run. What is the reason for adding it? > >I don't have strong feelings for or against adding bz2, but your >comment about interoperability raises a related issue. In theory, the >preference system would prevent the use of bz2 except when it can be >properly handled by the recipient so there should be no >interoperability issues. > >... > >I have already seen a few examples of this problem (a PGP-generated >key with an IDEA pref being used on GnuPG, and a GnuPG-generated key >with a ZLIB pref being used on PGP). > >I don't think the answer here is to restrict the use of new >algorithms. 2440 has this to say, which pretty much eliminates the >problem in the design: > > Since a self-signature contains important information about the > key's use, an implementation SHOULD allow the user to rewrite the > self-signature, and important information in it, such as > preferences and key expiration. > >I don't advocate making any severe changes in the preference system, >but perhaps the language here could be made a bit stronger? Something >like "Note that without the ability to rewrite a self-signature, >interoperability issues may occur when the same key is used in more >than one implementation." would be great. I realize this suggestion is getting into UI issues, but... Perhaps implementations should also warn the user if the user's public key includes features that are not supported by the implementation, and offer to generate a new self-signature that does not include those features. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | "A Jobless Recovery is | Periwinkle -- Consulting (408)356-8506 | like a Breadless Sand- | 16345 Englewood Ave. frantz@pwpconsult.com | wich." -- Steve Schear | Los Gatos, CA 95032, USA From owner-ietf-openpgp@mail.imc.org Mon Jul 7 18:51:09 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20526 for ; Mon, 7 Jul 2003 18:51:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67MYwqt097993 for ; Mon, 7 Jul 2003 15:34:58 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67MYwDf097991 for ietf-openpgp-bks; Mon, 7 Jul 2003 15:34:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67MYuqt097982 for ; Mon, 7 Jul 2003 15:34:56 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 127EC45067; Mon, 7 Jul 2003 15:34:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id F292648030; Mon, 7 Jul 2003 15:34:56 -0700 (PDT) Date: Mon, 7 Jul 2003 15:34:56 -0700 (PDT) From: Len Sassaman X-Sender: To: David Shaw Cc: Subject: Re: PoP & Signer's User ID subpacket? In-Reply-To: <20030617033611.GF20267@jabberwocky.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 16 Jun 2003, David Shaw wrote: > This raises a 2440bis question: given all the recent deprecation of > PGP 2.x stuff, is it worth requiring self-signatures on user IDs now? > If I recall, the only reason that user ID self-signatures are not > currently required was for 2.x compatibility. Certainly every modern > implementation (5.0+, any GnuPG) generates user ID self-signatures > automatically when a user ID is created. I think this is a marvelous idea. From owner-ietf-openpgp@mail.imc.org Mon Jul 7 21:23:45 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA23802 for ; Mon, 7 Jul 2003 21:23:44 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6813xqt004001 for ; Mon, 7 Jul 2003 18:03:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6813xeM004000 for ietf-openpgp-bks; Mon, 7 Jul 2003 18:03:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6813vqt003993 for ; Mon, 7 Jul 2003 18:03:58 -0700 (PDT) (envelope-from jon@callas.org) Received: from [192.168.1.37] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2) for ; Mon, 7 Jul 2003 18:03:57 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 07 Jul 2003 18:03:58 -0700 Subject: Re: Adding in BZ2 compression? From: Jon Callas To: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7/3/03 6:56 PM, "Derek Atkins" wrote: > Just to play devil's advocate, why do we need yet another compression > algorithm? I'm not the person asking for them, so I may be inadequately explaining this. Nonetheless, here goes. The argument of "no new algorithms unless one is broken" makes more sense for things like ciphers than it does for compression. Compression in OpenPGP doesn't have the same sort of security implications that a cipher does, and so one doesn't need to be as conservative about it. The practical technical reason for bz2 is that it compresses better. In a test I saw, it compresses 12% better than Deflate, and 7% better than zlib. That test was with a backup of a server. Here's the actual results: Original tar file: 1,739,950,080 bytes (1.62 GB) 100% .tar.pgp file : 730,450,065 bytes (696.6 MB) 43% .tar.gz file : 694,085,841 bytes (661.9 MB) 40% .tar.bz2 file : 648,270,622 bytes (618.2 MB) 38% The practical product reason is that there are a number of storage archival systems that are adding in crypto. Many are encrypting some compressed data with PKCS7 or some home-brew thing. I've been getting questions about using OpenPGP as an archival primitive, especially since it includes compression. I would like to be responsive to this, and say that OpenPGP is a great system to use for encryption and compression, and why sure, just code it up this way. It would similarly pain me to have to say that OpenPGP isn't suitable for encryption and compression of large amounts of data, please go shop at Gimble's. Yes, I know that there are potential interoperability issues when keys get migrated around, but I also of the opinion that when an implementation imports a key, it should make sure that the preferences reflect what it supports. Jon From owner-ietf-openpgp@mail.imc.org Tue Jul 8 00:12:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26096 for ; Tue, 8 Jul 2003 00:12:28 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h683stqt009969 for ; Mon, 7 Jul 2003 20:54:55 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h683stH1009968 for ietf-openpgp-bks; Mon, 7 Jul 2003 20:54:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h683ssqt009962 for ; Mon, 7 Jul 2003 20:54:54 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h683spK01124 for ietf-openpgp@imc.org; Mon, 7 Jul 2003 23:54:51 -0400 Date: Mon, 7 Jul 2003 23:54:51 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Adding in BZ2 compression? Message-ID: <20030708035451.GA31450@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200307040205.h6425GJ13374@finney.org> <200307040205.h6425GJ13374@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (60% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 07, 2003 at 11:58:57AM -0700, Bill Frantz wrote: > >I don't advocate making any severe changes in the preference system, > >but perhaps the language here could be made a bit stronger? Something > >like "Note that without the ability to rewrite a self-signature, > >interoperability issues may occur when the same key is used in more > >than one implementation." would be great. > > I realize this suggestion is getting into UI issues, but... > > Perhaps implementations should also warn the user if the user's > public key includes features that are not supported by the > implementation, and offer to generate a new self-signature that does > not include those features. It's a good idea, and in fact has been on my todo list for GnuPG for a little while now. It's one of those things that sounds easy, but is actually pretty fussy to do (What if there is more than one self-sig? What if the user later removes a self-sig with safe permissions, leaving a self-sig with unsafe permissions? Etc). Nothing unsolvable, but there are a lot of corner cases. That said, should such a thing be mentioned in 2440bis? I'm not sure. I certainly wouldn't be against something like "Implementations MAY wish to warn the user when importing a key that has preferences that contradict the capabilities of the implementation". David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/CkCL4mZch0nhy8kRAkFkAKCV4N6AsONC11H4MqExgNDkMwZ6oACgqk6T de02ELd0rqdgD+myEBjV0Jg= =SON4 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Jul 9 10:54:56 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03666 for ; Wed, 9 Jul 2003 10:54:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69EObqt098875 for ; Wed, 9 Jul 2003 07:24:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h69EOb1v098874 for ietf-openpgp-bks; Wed, 9 Jul 2003 07:24:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69EOaqt098867 for ; Wed, 9 Jul 2003 07:24:36 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h69EOQn19010 for ietf-openpgp@imc.org; Wed, 9 Jul 2003 10:24:26 -0400 Date: Wed, 9 Jul 2003 10:24:26 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Two more items Message-ID: <20030709142426.GH9193@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (69% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My apologies. I missed these two items when I last proofread: **************************** Sections 5.6 (Compressed Data Packet), 5.7 (Symmetrically Encrypted Data Packet), 5.13 (Sym. Encrypted Integrity Protected Data Packet) all indicate that they can contain more than one literal packet. This makes sense for encrypting multiple files together, and both PGP and GnuPG correctly handle messages with multiple literal packets. However, the grammar in section 10.2 defines a "Literal Message" as a single literal packet: Literal Message :- Literal Data Packet. I suggest a small change to make the grammar match the rest of the document (and reality): Literal Message :- Literal Data Packet | Literal Message, Literal Data Packet. **************************** Section 10.2 (OpenPGP Messages) has a blank line in the middle of the paragraph beginning "In addition, decrypting a Symmetrically Encrypted Data Packet". **************************** David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD4DBQE/DCWa4mZch0nhy8kRAom6AJ4k/V9gE/4h99UGQ8qxxcVh/bA6VACY3tPg uInYth+nGCdgYt5QPNt4rQ== =y1pn -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun Jul 13 10:39:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25873 for ; Sun, 13 Jul 2003 10:39:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEKaqt085218 for ; Sun, 13 Jul 2003 07:20:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6DEKaS4085216 for ietf-openpgp-bks; Sun, 13 Jul 2003 07:20:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEKZqt085206 for ; Sun, 13 Jul 2003 07:20:35 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (pcp04279524pcs.union01.nj.comcast.net [68.39.101.89]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6DEKLR30204 for ; Sun, 13 Jul 2003 10:20:31 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6DDV9a14471 for ietf-openpgp@imc.org; Sun, 13 Jul 2003 09:31:09 -0400 Date: Sun, 13 Jul 2003 09:31:09 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Two more items Message-ID: <20030713133109.GC1901@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030709142426.GH9193@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20030709142426.GH9193@jabberwocky.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Full User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 09, 2003 at 10:24:26AM -0400, David Shaw wrote: > My apologies. I missed these two items when I last proofread: > > **************************** > > Sections 5.6 (Compressed Data Packet), 5.7 (Symmetrically Encrypted > Data Packet), 5.13 (Sym. Encrypted Integrity Protected Data Packet) > all indicate that they can contain more than one literal packet. This > makes sense for encrypting multiple files together, and both PGP and > GnuPG correctly handle messages with multiple literal packets. > > However, the grammar in section 10.2 defines a "Literal Message" as a > single literal packet: I should clarify exactly what I tested here. Both PGP (8) and GnuPG worked properly with an encrypted message that contained two literal packets. That is to say, a regular public key encrypted message except that the encrypted data packet contained two literal packets instead of one. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/EV8d4mZch0nhy8kRAp/AAKCraFUEyIbsAA90XgX9MNkxBcJBbgCfZvp8 P5aIbJfoeoHM3ddy0Lun7s0= =0uha -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun Jul 13 10:40:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25938 for ; Sun, 13 Jul 2003 10:40:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEKbqt085224 for ; Sun, 13 Jul 2003 07:20:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6DEKbqN085223 for ietf-openpgp-bks; Sun, 13 Jul 2003 07:20:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEKZqt085207 for ; Sun, 13 Jul 2003 07:20:36 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (pcp04279524pcs.union01.nj.comcast.net [68.39.101.89]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6DEKWR30210; Sun, 13 Jul 2003 10:20:32 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6DDIh605883; Sun, 13 Jul 2003 09:18:43 -0400 Date: Sun, 13 Jul 2003 09:18:42 -0400 From: David Shaw To: Len Sassaman Cc: ietf-openpgp@imc.org Subject: Re: PoP & Signer's User ID subpacket? Message-ID: <20030713131842.GB1901@jabberwocky.com> Mail-Followup-To: Len Sassaman , ietf-openpgp@imc.org References: <20030617033611.GF20267@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Full User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 07, 2003 at 03:34:56PM -0700, Len Sassaman wrote: > > On Mon, 16 Jun 2003, David Shaw wrote: > > > This raises a 2440bis question: given all the recent deprecation of > > PGP 2.x stuff, is it worth requiring self-signatures on user IDs now? > > If I recall, the only reason that user ID self-signatures are not > > currently required was for 2.x compatibility. Certainly every modern > > implementation (5.0+, any GnuPG) generates user ID self-signatures > > automatically when a user ID is created. > > I think this is a marvelous idea. The only thing that really troubles me about the idea is that it raises problems for the (legal, to my reading of 2440) encrypt-only v4 key. A true encrypt-only key would have a problem issuing the self-signature. Of course, Hal's comments about encryption keys issuing signatures apply here as well. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/EVwy4mZch0nhy8kRAqi7AJ9/6CK8tnKlVi0hf83ZJD/cTFqaSACeNr1J lHTbEJAkp49+QSqZ9WpW6Xg= =KoEp -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 14 00:01:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13199 for ; Mon, 14 Jul 2003 00:01:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E3cmqt020155 for ; Sun, 13 Jul 2003 20:38:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6E3cmIL020154 for ietf-openpgp-bks; Sun, 13 Jul 2003 20:38:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta8.adelphia.net (mta8.adelphia.net [64.8.50.196]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E3ckqt020148 for ; Sun, 13 Jul 2003 20:38:47 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung ([68.168.179.202]) by mta8.adelphia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP id <20030714033844.YNTH20782.mta8.adelphia.net@mwyoung> for ; Sun, 13 Jul 2003 23:38:44 -0400 Message-ID: <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> Subject: Re: PoP & Signer's User ID subpacket? Date: Sun, 13 Jul 2003 23:37:24 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "David Shaw" writes: > The only thing that really troubles me about the idea is that it > raises problems for the (legal, to my reading of 2440) encrypt-only v4 > key. This doesn't trouble me... I strongly believe that we should remove the loophole that allows encrypt-only top-level v4 keys, for exactly this reason. (I was astounded when David pointed out the seemingly permissive language in another forum.) Why is it important to be able to generate such a thing? Is it such a burden to have to generate a signing key? [If you don't care about uid validity, which you mustn't if you're using an encrypt-only top-level key now, then you could even attach a bogus top-level key, which would take virtually no time to generate.] -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPxIlcec3iHYL8FknEQJ1BgCffGpWfOixvtgCkH4FSJsYt7eN/dIAn1A1 EPdheuZMUvnXH1K52Aj5URAe =nPI9 -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 14 02:44:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28156 for ; Mon, 14 Jul 2003 02:44:20 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E6FUqt026412 for ; Sun, 13 Jul 2003 23:15:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6E6FUQq026410 for ietf-openpgp-bks; Sun, 13 Jul 2003 23:15:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E6FSqt026384 for ; Sun, 13 Jul 2003 23:15:29 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (pcp04282046pcs.union01.nj.comcast.net [68.39.111.63]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6E6FTR32157 for ; Mon, 14 Jul 2003 02:15:29 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6E67Rp16267 for ietf-openpgp@imc.org; Mon, 14 Jul 2003 02:07:27 -0400 Date: Mon, 14 Jul 2003 02:07:27 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: PoP & Signer's User ID subpacket? Message-ID: <20030714060727.GA15755@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Full User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jul 13, 2003 at 11:37:24PM -0400, Michael Young wrote: > > "David Shaw" writes: > > The only thing that really troubles me about the idea is that it > > raises problems for the (legal, to my reading of 2440) encrypt-only v4 > > key. > > This doesn't trouble me... I strongly believe that we should > remove the loophole that allows encrypt-only top-level v4 keys, > for exactly this reason. (I was astounded when David pointed out > the seemingly permissive language in another forum.) Just so we're all clear, Michael and I had been discussing the legality of a v4 encrypt-only primary WITHOUT any subkeys. An encrypt-only key WITH subkeys is clearly forbidden in 2440 both implicitly (an encrypt-only primary key could not issue the non-optional subkey binding signatures) and explicitly ("In a key that has a main key and subkeys, the primary key MUST be a key capable of certification."). This is just a primary key that happens to be of an encrypt-only algorithm (presumably #16, since there is no way to express an encrypt-only primary key with algorithm #1 (you would need to use #2, which is deprecated)). David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/Ekif4mZch0nhy8kRAsNVAJ9ZgvUVZnrGFm07uMzgdTmeBansagCfeIC5 IX3KeeSgLEuFe0nfbZz6lHU= =JUAl -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 14 11:23:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27896 for ; Mon, 14 Jul 2003 11:23:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEtsqt079599 for ; Mon, 14 Jul 2003 07:55:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EEtrNJ079598 for ietf-openpgp-bks; Mon, 14 Jul 2003 07:55:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEtqqt079592 for ; Mon, 14 Jul 2003 07:55:53 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (pcp04278829pcs.union01.nj.comcast.net [68.39.98.162]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6EEtnR01054 for ; Mon, 14 Jul 2003 10:55:49 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6EEnwY17582 for ietf-openpgp@imc.org; Mon, 14 Jul 2003 10:49:58 -0400 Date: Mon, 14 Jul 2003 10:49:58 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: PoP & Signer's User ID subpacket? Message-ID: <20030714144958.GC17025@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20030714060727.GA15755@jabberwocky.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (99% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 14, 2003 at 02:07:27AM -0400, David Shaw wrote: > On Sun, Jul 13, 2003 at 11:37:24PM -0400, Michael Young wrote: > > > > "David Shaw" writes: > > > The only thing that really troubles me about the idea is that it > > > raises problems for the (legal, to my reading of 2440) encrypt-only v4 > > > key. > > > > This doesn't trouble me... I strongly believe that we should > > remove the loophole that allows encrypt-only top-level v4 keys, > > for exactly this reason. (I was astounded when David pointed out > > the seemingly permissive language in another forum.) > > Just so we're all clear, Michael and I had been discussing the > legality of a v4 encrypt-only primary WITHOUT any subkeys. An > encrypt-only key WITH subkeys is clearly forbidden in 2440 both > implicitly (an encrypt-only primary key could not issue the > non-optional subkey binding signatures) and explicitly ("In a key that > has a main key and subkeys, the primary key MUST be a key capable of > certification."). > > This is just a primary key that happens to be of an encrypt-only > algorithm (presumably #16, since there is no way to express an > encrypt-only primary key with algorithm #1 (you would need to use #2, > which is deprecated)). I should add, though, that I don't really understand the objection to an encrypt-only primary. OpenPGP is a collection of various tools that can be combined in different ways for different uses. Some combinations are more useful than others, and some make no sense, but I don't see why (in the absence of an actual problem) one particular combination should be considered a "loophole" and removed. Do I strongly care about encrypt-only primaries in particular? Not really. I do care about clean design, though, and adding a special additional "no encrypt-only primaries" rule on top of the current clean primary/subkey design seems without clear benefit. Can you explain what troubles you about encrypt-only primaries? David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/EsMW4mZch0nhy8kRAhl9AKCAnW30D4l+W+pC/hhLEXs9TONulQCfeOnP +0pShRqWTG3OCdbC42bje9U= =iQ9h -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 14 14:02:55 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09372 for ; Mon, 14 Jul 2003 14:02:55 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EHexqt089535 for ; Mon, 14 Jul 2003 10:40:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EHexiS089534 for ietf-openpgp-bks; Mon, 14 Jul 2003 10:40:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EHeqqt089523 for ; Mon, 14 Jul 2003 10:40:55 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA24173 for ; Mon, 14 Jul 2003 13:40:40 -0400 (EDT) Message-ID: <000601c34a2e$da604880$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> Subject: Re: PoP & Signer's User ID subpacket? Date: Mon, 14 Jul 2003 13:39:04 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "David Shaw" writes: > Do I strongly care about encrypt-only primaries in particular? Not > really. I do care about clean design, though, and adding a special > additional "no encrypt-only primaries" rule on top of the current > clean primary/subkey design seems without clear benefit. I think that the rules are cleaner without encrypt-only standalone keys: "Every key has a primary that can sign and any number of subkeys (of any type)." Just one rule, no special cases, nothing "on top". I find it strange that you'd use the term "primary" for a top-level encrypt-only key. It can't have subkeys; there is no "secondary". > Can you explain what troubles you about encrypt-only primaries? Aside from being an unclean exception to a simple model :-? I think there is value in requiring uids to be self-signed. To allow encrypt-only top-level keys, one has to make a special case. Given that they are only very limitedly useful, I'd rather not have the special case. I recognize that requiring self-signatures on uids restricts some otherwise valid uses, and that it doesn't provide any additional security given a strong trust model and a proper understanding of its limitations. I still think it's worthwhile. [Note that the same is true of the signing-subkey problem. I acknowledge that the problem was more serious there, and the uses of non-owned subkeys are more limited. (By the way, I like David's signature-in-a-subpacket solution.) The same is also true of the requirement that a key have at least one uid.] Hal observed that all *existing* encrypt-only algorithms really can support signing anyway. Who knows whether that will hold up over time? If we're convinced that it will, I'd rather remove the encrypt-only notion from the algorithm entirely (putting it in the key preferences instead). -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPxLeSec3iHYL8FknEQJ3AwCg5iBkjpc3bAff3WIyd2pzdUMS4kMAoN3t ATq2/ZgYie7m5H7NwDIZMsUm =igGD -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 14 14:05:50 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09473 for ; Mon, 14 Jul 2003 14:05:49 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EHexqt089536 for ; Mon, 14 Jul 2003 10:40:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EHexQs089533 for ietf-openpgp-bks; Mon, 14 Jul 2003 10:40:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EHeqqt089522 for ; Mon, 14 Jul 2003 10:40:55 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA24170 for ; Mon, 14 Jul 2003 13:40:40 -0400 (EDT) Message-ID: <000501c34a2e$d9fb9340$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> Subject: Re: PoP & Signer's User ID subpacket? Date: Mon, 14 Jul 2003 12:46:11 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "David Shaw" writes: > Do I strongly care about encrypt-only primaries in particular? Not > really. I do care about clean design, though, and adding a special > additional "no encrypt-only primaries" rule on top of the current > clean primary/subkey design seems without clear benefit. I think that the rules are cleaner without encrypt-only standalone keys: "Every key has a primary that can sign and any number of subkeys (of any type)." Just one rule, no special cases, nothing "on top". I find it strange that you'd use the term "primary" for a top-level encrypt-only key. It can't have subkeys; there is no "secondary". > Can you explain what troubles you about encrypt-only primaries? Aside from being an unclean exception to a simple model :-? I think there is value in requiring uids to be self-signed. To allow encrypt-only top-level keys, one has to make a special case. Given that they are only very limitedly useful, I'd rather not have the special case. I recognize that requiring self-signatures on uids restricts some otherwise valid uses, and that it doesn't provide any additional security given a strong trust model and a proper understanding of its limitations. I still think it's worthwhile. [Note that the same is true of the signing-subkey problem. I acknowledge that the problem was more serious there, and the uses of non-owned subkeys are more limited. (By the way, I like David's signature-in-a-subpacket solution.) The same is also true of the requirement that a key have at least one uid.] Hal observed that all *existing* encrypt-only algorithms really can support signing anyway. Who knows whether that will hold up over time? If we're convinced that it will, I'd rather remove the encrypt-only notion from the algorithm entirely (putting it in the key preferences instead). -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPxLeSec3iHYL8FknEQJ3AwCg5iBkjpc3bAff3WIyd2pzdUMS4kMAoN3t ATq2/ZgYie7m5H7NwDIZMsUm =igGD -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Mon Jul 14 21:32:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16345 for ; Mon, 14 Jul 2003 21:32:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F19hqt016063 for ; Mon, 14 Jul 2003 18:09:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6F19hAR016062 for ietf-openpgp-bks; Mon, 14 Jul 2003 18:09:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F19fqt016055 for ; Mon, 14 Jul 2003 18:09:42 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (claude.jabberwocky.com [172.24.84.27]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6F19eR03499 for ; Mon, 14 Jul 2003 21:09:41 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6F19dY02778 for ietf-openpgp@imc.org; Mon, 14 Jul 2003 21:09:39 -0400 Date: Mon, 14 Jul 2003 21:09:38 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030715010938.GA1241@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> <000601c34a2e$da604880$2ac52609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <000601c34a2e$da604880$2ac52609@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (98% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 14, 2003 at 01:39:04PM -0400, Michael Young wrote: > I find it strange that you'd use the term "primary" for a top-level > encrypt-only key. It can't have subkeys; there is no "secondary". I call it primary because 2440 calls it primary. It doesn't matter if there are no subkeys on it. That's just wording. I think we all know what I am talking about when I say encrypt-only primary: a version 4 public key (tag 6) that is of an encrypt-only algorithm. > > Can you explain what troubles you about encrypt-only primaries? > > Aside from being an unclean exception to a simple model :-? I don't see exceptions here. The model is quite clearly and simply stated in 2440. Any key can be of any type. There are no exceptions. Does this mean that there are possible arrangements of packets that make no sense? Sure, so don't do that. I see your suggestion as adding an exception: any key can be of any type, except that the primary must be able to certify. > I think there is value in requiring uids to be self-signed. To allow > encrypt-only top-level keys, one has to make a special case. Given > that they are only very limitedly useful, I'd rather not have the > special case. Keep in mind that this renders valid 2440 keys invalid under 2440bis. I can't imagine why we'd do such a thing just to gain the ability to require self-signed user IDs. To be honest, I've never seen an encrypt-only primary in nature. I know of no program that generates them. I've never used one except to test. But who am I to dictate - in the absence of an actual security-related reason - to someone else what type of key they may have? Note that GnuPG doesn't have any special support for encrypt-only primary keys, but because of the nice general design of v4 keys, where any key (primary or subkey) can be of any type, encrypt-only primaries work just fine. I don't have a copy of PGP handy (I'm traveling), but I suspect that they'll "just plain work" in PGP as well. My point here is that it would take additional code and additional complexity to *prevent* encrypt-only primaries from working... so why mess around with this, especially since there is no security-related reason for it? > I recognize that requiring self-signatures on uids restricts some > otherwise valid uses, and that it doesn't provide any additional > security given a strong trust model and a proper understanding of > its limitations. I still think it's worthwhile. Allow me to restate the original problem that spawned this thread: It would be nice to require self-signatures on user IDs. We cannot do that since an encrypt-only primary is unable to issue such a self-signature. So, as a solution, rather than ripping into the key construction rules, why not just put in a line saying "user IDs and user attributes SHOULD have a self-signature", and call it a day? This has a few nice details: * It doesn't render perfectly valid 2440 encrypt-only primary keys invalid with the swipe of a pen. * It doesn't render perfectly valid 2440 non-self-signed keys invalid with the swipe of a pen. * It accomplishes the intent of pointing out that implementations should really be self-signing user IDs (which they are already doing anyway). David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/E1RS4mZch0nhy8kRAvIcAKDBrriAl95R+I9w93/C62i67HTiXQCglsBK xDKiWu0MMeNqKsLbYpDrWdk= =clPi -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Jul 15 14:07:07 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28240 for ; Tue, 15 Jul 2003 14:07:06 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FHb0qt091470 for ; Tue, 15 Jul 2003 10:37:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FHb0lI091469 for ietf-openpgp-bks; Tue, 15 Jul 2003 10:37:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from possum.cryptohill.net (cambist.cryptohill.net [24.244.145.35]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FHavqt091464 for ; Tue, 15 Jul 2003 10:37:00 -0700 (PDT) (envelope-from edwin@woudt.nl) Received: from ABC1234567890 (unknown [24.244.145.60]) by possum.cryptohill.net (Postfix) with ESMTP id 384CDAE300 for ; Tue, 15 Jul 2003 13:36:58 -0400 (EDT) Date: Tue, 15 Jul 2003 13:37:34 -0400 From: Edwin Woudt To: ietf-openpgp@imc.org Subject: Location of 'key expiration time' signature subpacket Message-ID: <127733008.1058276254@ABC1234567890> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit While implementing key expiration, I noticed that the 'key expiration time' signature subpacket (#9) is put in self certification signatures instead of in (self signed) direct key signature. Why is that? I find it more logical to put it in a direct key signature, as it says nothing about the user id that is self signed. In fact, given multiple user id's, putting it in self certification signatures could even result in conflicting information. Edwin From owner-ietf-openpgp@mail.imc.org Thu Jul 17 18:19:31 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25493 for ; Thu, 17 Jul 2003 18:19:31 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HLqOqt030280 for ; Thu, 17 Jul 2003 14:52:25 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HLqOKT030279 for ietf-openpgp-bks; Thu, 17 Jul 2003 14:52:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HLqMqt030270 for ; Thu, 17 Jul 2003 14:52:23 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA28419 for ; Thu, 17 Jul 2003 17:52:11 -0400 (EDT) Message-ID: <002f01c34cad$7c5b0960$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> <000601c34a2e$da604880$2ac52609@transarc.ibm.com> <20030715010938.GA1241@jabberwocky.com> Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Date: Thu, 17 Jul 2003 17:50:49 -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 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "David Shaw" writes: > Allow me to restate the original problem that spawned this thread: It > would be nice to require self-signatures on user IDs. We cannot do > that since an encrypt-only primary is unable to issue such a > self-signature. It seems that we all agree that it would be "nice" to *require* self-signatures. > So, as a solution, rather than ripping into the key construction > rules, why not just put in a line saying "user IDs and user attributes > SHOULD have a self-signature", and call it a day? I think it's suitably "nice" to merit "ripping into" a key construction rule that I have always thought was wrong. Despite your attempts to paint the current rule as cleaner, simpler, or more natural, I still disagree -- I think the current rule is more convoluted. It *is* the current rule, though, and I understand that we'd be invalidating some currently valid keys "with the swipe of a pen". As you've noted, no known software generates encrypt-only top-level keys (except perhaps for testing). Anyone with a usable signing key can generate a self-signature to make any intended uids valid. With those facts in mind, I'm quite willing to take a swipe to correct a mistake. Perhaps one of the original authors can offer some insight here. Why was it important to allow encrypt-only "primary" keys? -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPxcaN+c3iHYL8FknEQKIRwCeKmbyVMTXwb5uoiQjFZ8vud33I+gAoLCG DXPnhQ0f/u9cqccD+/TTr+64 =il1i -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jul 17 18:30:02 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25664 for ; Thu, 17 Jul 2003 18:30:02 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMDbqt031349 for ; Thu, 17 Jul 2003 15:13:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HMDbcZ031348 for ietf-openpgp-bks; Thu, 17 Jul 2003 15:13:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMDaqt031341 for ; Thu, 17 Jul 2003 15:13:36 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 212A845023; Thu, 17 Jul 2003 15:13:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 0C66E48034; Thu, 17 Jul 2003 15:13:33 -0700 (PDT) Date: Thu, 17 Jul 2003 15:13:32 -0700 (PDT) From: Len Sassaman X-Sender: To: Jon Callas Cc: OpenPGP Subject: Re: Adding in BZ2 compression? In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 7 Jul 2003, Jon Callas wrote: > I'm not the person asking for them, so I may be inadequately explaining > this. Nonetheless, here goes. > > The argument of "no new algorithms unless one is broken" makes more sense > for things like ciphers than it does for compression. Compression in OpenPGP > doesn't have the same sort of security implications that a cipher does, and > so one doesn't need to be as conservative about it. Putting multiple options for anything into a protocol does practical implications in the context of an anonymity system, however. (I'm not saying this should prevent adding a new compression algorithm if it serves a purpose -- it's just something to keep in mind.) > Yes, I know that there are potential interoperability issues when keys get > migrated around, but I also of the opinion that when an implementation > imports a key, it should make sure that the preferences reflect what it > supports. Amen. Can that be explicitly stated in the next draft? (And does PGP do this yet?) --Len. From owner-ietf-openpgp@mail.imc.org Thu Jul 17 18:31:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25710 for ; Thu, 17 Jul 2003 18:31:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMEjqt031371 for ; Thu, 17 Jul 2003 15:14:45 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HMEi35031370 for ietf-openpgp-bks; Thu, 17 Jul 2003 15:14:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMEhqt031365 for ; Thu, 17 Jul 2003 15:14:43 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 39D6E45095; Thu, 17 Jul 2003 15:14:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 251F748034; Thu, 17 Jul 2003 15:14:41 -0700 (PDT) Date: Thu, 17 Jul 2003 15:14:41 -0700 (PDT) From: Len Sassaman X-Sender: To: Michael Young Cc: Subject: Re: PoP & Signer's User ID subpacket? In-Reply-To: <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 13 Jul 2003, Michael Young wrote: > "David Shaw" writes: > > The only thing that really troubles me about the idea is that it > > raises problems for the (legal, to my reading of 2440) encrypt-only v4 > > key. > > This doesn't trouble me... I strongly believe that we should > remove the loophole that allows encrypt-only top-level v4 keys, > for exactly this reason. (I was astounded when David pointed out > the seemingly permissive language in another forum.) Agreed. > Why is it important to be able to generate such a thing? Is it such a > burden to have to generate a signing key? > > [If you don't care about uid validity, which you mustn't if you're > using an encrypt-only top-level key now, then you could even attach a > bogus top-level key, which would take virtually no time to generate.] From owner-ietf-openpgp@mail.imc.org Thu Jul 17 18:36:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25788 for ; Thu, 17 Jul 2003 18:36:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMKUqt031491 for ; Thu, 17 Jul 2003 15:20:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HMKULh031490 for ietf-openpgp-bks; Thu, 17 Jul 2003 15:20:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMKSqt031485 for ; Thu, 17 Jul 2003 15:20:28 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 7D56345095; Thu, 17 Jul 2003 15:20:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 5F96C48034; Thu, 17 Jul 2003 15:20:26 -0700 (PDT) Date: Thu, 17 Jul 2003 15:20:26 -0700 (PDT) From: Len Sassaman X-Sender: To: David Shaw Cc: Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) In-Reply-To: <20030715010938.GA1241@jabberwocky.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 14 Jul 2003, David Shaw wrote: > > I think there is value in requiring uids to be self-signed. To allow > > encrypt-only top-level keys, one has to make a special case. Given > > that they are only very limitedly useful, I'd rather not have the > > special case. > > Keep in mind that this renders valid 2440 keys invalid under 2440bis. > I can't imagine why we'd do such a thing just to gain the ability to > require self-signed user IDs. To be honest, I've never seen an I am surprised that there have not been widespread attacks on OpenPGP keys as a result of the permitted non-self-signed UIDs. I think this really must be fixed. (And for users to add self-signatures to their existing unsigned uids is trivial.) > encrypt-only primary in nature. I know of no program that generates > them. I've never used one except to test. But who am I to dictate - > in the absence of an actual security-related reason - to someone else > what type of key they may have? That's what making an interoperable protocol is all about. (I'll also argue that interoperability is a security-related reason in and of itself.) > Note that GnuPG doesn't have any special support for encrypt-only > primary keys, but because of the nice general design of v4 keys, where > any key (primary or subkey) can be of any type, encrypt-only primaries > work just fine. I don't have a copy of PGP handy (I'm traveling), but > I suspect that they'll "just plain work" in PGP as well. My point > here is that it would take additional code and additional complexity > to *prevent* encrypt-only primaries from working... so why mess around > with this, especially since there is no security-related reason for > it? Simplicity is a good reason, as is the robustness of the OpenPGP system. From owner-ietf-openpgp@mail.imc.org Thu Jul 17 21:08:38 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29260 for ; Thu, 17 Jul 2003 21:08:37 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0oWqt036943 for ; Thu, 17 Jul 2003 17:50:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I0oWjm036942 for ietf-openpgp-bks; Thu, 17 Jul 2003 17:50:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0oVqt036936 for ; Thu, 17 Jul 2003 17:50:31 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6I0oR003700; Thu, 17 Jul 2003 20:50:27 -0400 Date: Thu, 17 Jul 2003 20:50:27 -0400 From: David Shaw To: ietf-openpgp@imc.org Cc: Michael Young Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030718005027.GC32097@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org, Michael Young References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> <000601c34a2e$da604880$2ac52609@transarc.ibm.com> <20030715010938.GA1241@jabberwocky.com> <002f01c34cad$7c5b0960$2ac52609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <002f01c34cad$7c5b0960$2ac52609@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (83% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 17, 2003 at 05:50:49PM -0400, Michael Young wrote: > > "David Shaw" writes: > > So, as a solution, rather than ripping into the key construction > > rules, why not just put in a line saying "user IDs and user attributes > > SHOULD have a self-signature", and call it a day? > > I think it's suitably "nice" to merit "ripping into" a key construction > rule that I have always thought was wrong. Despite your attempts to > paint the current rule as cleaner, simpler, or more natural, I still > disagree "Despite your attempts to paint the current rule"? Yikes. We're all working towards the same goal here. Remember who suggested dealing with this in 2440bis. If I liked the no-required-self-sigs status quo, I wouldn't have brought it up. Although it might seem I'm arguing against required self-sigs, I'm actually fairly torn. One problem is that combining this change with the encrypt-only key change implies a number of subtle and not so subtle changes, and I'm not (yet) convinced that this is the right thing to do. I understand that you see the removal of encrypt-only keys as an advantage (as you seem to be arguing against encrypt-only keys almost more than you are arguing for a required self-signature), but I don't see things that way. Despite what I said earlier in this thread, requiring self-sigs does not depend on removing encrypt-only keys. Since there seems to be widespread agreement for the former, and not for the latter, perhaps it would be better to resolve the self-sigs question and then discuss encrypt-only keys as a suppurate issue. Discussing the two issues tied together seems to be leading nowhere. I propose "Self-signatures are REQUIRED for all user IDs and user attribute IDs on any key that has a primary capable of certification". This handles the self-sig issue without changing the key construction rules at all. If there is consensus on this, then a different discussion can be opened on the matter of encrypt-only keys. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/F0RT4mZch0nhy8kRApWuAKC1nGMxvf6i26tMxHJ/gHZ3qMY6hQCfUO8V CsPgFfLT2nQbuVAd4HA1ki0= =qfjQ -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jul 17 21:11:54 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29309 for ; Thu, 17 Jul 2003 21:11:54 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0vTqt037193 for ; Thu, 17 Jul 2003 17:57:29 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I0vT6k037192 for ietf-openpgp-bks; Thu, 17 Jul 2003 17:57:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0vSqt037185 for ; Thu, 17 Jul 2003 17:57:28 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6I0vOu03761; Thu, 17 Jul 2003 20:57:24 -0400 Date: Thu, 17 Jul 2003 20:57:24 -0400 From: David Shaw To: Len Sassaman Cc: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030718005724.GD32097@jabberwocky.com> Mail-Followup-To: Len Sassaman , ietf-openpgp@imc.org References: <20030715010938.GA1241@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (83% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 17, 2003 at 03:20:26PM -0700, Len Sassaman wrote: > > On Mon, 14 Jul 2003, David Shaw wrote: > > > > I think there is value in requiring uids to be self-signed. To allow > > > encrypt-only top-level keys, one has to make a special case. Given > > > that they are only very limitedly useful, I'd rather not have the > > > special case. > > > > Keep in mind that this renders valid 2440 keys invalid under 2440bis. > > I can't imagine why we'd do such a thing just to gain the ability to > > require self-signed user IDs. To be honest, I've never seen an > > I am surprised that there have not been widespread attacks on OpenPGP keys > as a result of the permitted non-self-signed UIDs. I think this really > must be fixed. (And for users to add self-signatures to their existing > unsigned uids is trivial.) No question. I just object to tying the self-signature fix to removing encrypt-only keys. It's my own fault since I mentioned them together, but I was wrong. There is no need to tie the two together. > > Note that GnuPG doesn't have any special support for encrypt-only > > primary keys, but because of the nice general design of v4 keys, where > > any key (primary or subkey) can be of any type, encrypt-only primaries > > work just fine. I don't have a copy of PGP handy (I'm traveling), but > > I suspect that they'll "just plain work" in PGP as well. My point > > here is that it would take additional code and additional complexity > > to *prevent* encrypt-only primaries from working... so why mess around > > with this, especially since there is no security-related reason for > > it? > > Simplicity is a good reason, as is the robustness of the OpenPGP system. I'm afraid I don't understand your response. Simplicity is a good reason to add complexity? (??) David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/F0X04mZch0nhy8kRAg6AAJ9TFmsEeI3kYjF/rjnV0KvzM3aUWgCdFkEf PyYawQG859AUnnG0HmilddY= =E91L -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jul 17 21:14:58 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29363 for ; Thu, 17 Jul 2003 21:14:58 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0xoqt037273 for ; Thu, 17 Jul 2003 17:59:50 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I0xo7i037272 for ietf-openpgp-bks; Thu, 17 Jul 2003 17:59:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0xnqt037266 for ; Thu, 17 Jul 2003 17:59:49 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6I0wkG03780; Thu, 17 Jul 2003 20:58:46 -0400 Date: Thu, 17 Jul 2003 20:58:46 -0400 From: David Shaw To: Len Sassaman Cc: Jon Callas , OpenPGP Subject: Re: Adding in BZ2 compression? Message-ID: <20030718005846.GE32097@jabberwocky.com> Mail-Followup-To: Len Sassaman , Jon Callas , OpenPGP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (83% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 17, 2003 at 03:13:32PM -0700, Len Sassaman wrote: > > Yes, I know that there are potential interoperability issues when keys get > > migrated around, but I also of the opinion that when an implementation > > imports a key, it should make sure that the preferences reflect what it > > supports. > > Amen. Can that be explicitly stated in the next draft? Yes, please. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/F0ZG4mZch0nhy8kRAgXiAKCglNsielY5l+GddZZVfD5+JGF0pACfZSyq Zx7ePyEobFstdZIEw2D2dZ8= =VeVu -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Thu Jul 17 21:29:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29584 for ; Thu, 17 Jul 2003 21:29:17 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I1Ejqt039354 for ; Thu, 17 Jul 2003 18:14:45 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I1EjhN039353 for ietf-openpgp-bks; Thu, 17 Jul 2003 18:14:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I1Eiqt039348 for ; Thu, 17 Jul 2003 18:14:44 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6I1DfV03945; Thu, 17 Jul 2003 21:13:41 -0400 Date: Thu, 17 Jul 2003 21:13:41 -0400 From: David Shaw To: Jon Callas Cc: OpenPGP Subject: Re: key flag for authentication Message-ID: <20030718011341.GF32097@jabberwocky.com> Mail-Followup-To: Jon Callas , OpenPGP References: <003901c33356$4e3e0fc0$c23fa8c0@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (83% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Jul 01, 2003 at 12:57:29AM -0700, Jon Callas wrote: > > Is there a consensus for this? I'm happy with anything, myself. I support it. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/F0nF4mZch0nhy8kRAluDAJ4uojC6mKKpU5Q/Do/0xy1WNa9PqACg3aiI kk3p+8QfxeVEV3pejdO8G9E= =vxOX -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jul 18 05:15:05 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24161 for ; Fri, 18 Jul 2003 05:15:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I8r5qt072859 for ; Fri, 18 Jul 2003 01:53:05 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I8r4Od072858 for ietf-openpgp-bks; Fri, 18 Jul 2003 01:53:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I8r2qt072836 for ; Fri, 18 Jul 2003 01:53:03 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 19dQsc-0002Fq-00 for ; Fri, 18 Jul 2003 10:46:18 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 19dR0N-0002pT-00; Fri, 18 Jul 2003 10:54:19 +0200 To: Jon Callas Cc: OpenPGP Subject: Re: key flag for authentication References: <003901c33356$4e3e0fc0$c23fa8c0@transarc.ibm.com> <20030718011341.GF32097@jabberwocky.com> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Fri, 18 Jul 2003 10:54:18 +0200 In-Reply-To: <20030718011341.GF32097@jabberwocky.com> (David Shaw's message of "Thu, 17 Jul 2003 21:13:41 -0400") Message-ID: <87znjc8bb9.fsf@alberti.g10code.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 17 Jul 2003 21:13:41 -0400, David Shaw said: >> Is there a consensus for this? I'm happy with anything, myself. > I support it. Me too of course. -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org From owner-ietf-openpgp@mail.imc.org Fri Jul 18 12:39:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05061 for ; Fri, 18 Jul 2003 12:39:10 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGDiqt006708 for ; Fri, 18 Jul 2003 09:13:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IGDio1006707 for ietf-openpgp-bks; Fri, 18 Jul 2003 09:13:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGDgqt006701 for ; Fri, 18 Jul 2003 09:13:42 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 0BDB6450A9; Fri, 18 Jul 2003 09:13:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id EAD9B48034; Fri, 18 Jul 2003 09:13:41 -0700 (PDT) Date: Fri, 18 Jul 2003 09:13:41 -0700 (PDT) From: Len Sassaman X-Sender: To: David Shaw Cc: Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) In-Reply-To: <20030718005724.GD32097@jabberwocky.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 17 Jul 2003, David Shaw wrote: > > Simplicity is a good reason, as is the robustness of the OpenPGP system. > > I'm afraid I don't understand your response. Simplicity is a good > reason to add complexity? (??) I think that saying "all v4 primary keys are signature keys" actually simplifies things. You may disagree. From owner-ietf-openpgp@mail.imc.org Fri Jul 18 13:39:23 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06117 for ; Fri, 18 Jul 2003 13:39:23 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IHAhqt008394 for ; Fri, 18 Jul 2003 10:10:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IHAgcp008393 for ietf-openpgp-bks; Fri, 18 Jul 2003 10:10:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IHAfqt008368 for ; Fri, 18 Jul 2003 10:10:42 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6IHAbD13439; Fri, 18 Jul 2003 13:10:37 -0400 Date: Fri, 18 Jul 2003 13:10:37 -0400 From: David Shaw To: Len Sassaman Cc: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030718171037.GA12613@jabberwocky.com> Mail-Followup-To: Len Sassaman , ietf-openpgp@imc.org References: <20030718005724.GD32097@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (75% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jul 18, 2003 at 09:13:41AM -0700, Len Sassaman wrote: > On Thu, 17 Jul 2003, David Shaw wrote: > > > > Simplicity is a good reason, as is the robustness of the OpenPGP system. > > > > I'm afraid I don't understand your response. Simplicity is a good > > reason to add complexity? (??) > > I think that saying "all v4 primary keys are signature keys" actually > simplifies things. You may disagree. Ah, ok. I didn't parse your response properly. I'm of mixed feelings on the primary is a signing key issue. There is definite appeal to having all non-signature items in a key be bound there by signatures. As things stand now, subkeys are bound, but user IDs/attributes might not be. There is a nice annoyance attack in the wait there. I do wonder what this case would mean in regards to the discussion though: 1) Generate a RSA sign+encrypt key. Naturally the user ID on that key should have a self-signature. 2) Now change the key flags so that the primary is encrypt-only. Is that an "encrypt-only" key? David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/GCoN4mZch0nhy8kRAhyYAKC8qaI6HL4aPy1/xJJi04nM8ISc1QCdHs3X NWg2+tNJl1n48jzhofMOTE0= =mm0s -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jul 18 14:45:01 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08044 for ; Fri, 18 Jul 2003 14:45:01 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IIMCqt012972 for ; Fri, 18 Jul 2003 11:22:12 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IIMCHW012971 for ietf-openpgp-bks; Fri, 18 Jul 2003 11:22:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IIMBqt012966 for ; Fri, 18 Jul 2003 11:22:11 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id 8A6F56237 for ; Fri, 18 Jul 2003 11:22:05 -0700 (PDT) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id h6IIM5Ks028728 for ; Fri, 18 Jul 2003 11:22:05 -0700 (PDT) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id h6IIM5rn028727 for ietf-openpgp@imc.org; Fri, 18 Jul 2003 11:22:05 -0700 (PDT) Message-Id: <200307181822.h6IIM5rn028727@mailserver2.hushmail.com> Date: Fri, 18 Jul 2003 11:22:05 -0700 To: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 18 Jul 2003 10:10:37 -0700 David Shaw wrote: [...] >I do wonder what this case would mean in regards to the discussion >though: > >1) Generate a RSA sign+encrypt key. Naturally the user ID on that >key > should have a self-signature. > >2) Now change the key flags so that the primary is encrypt-only. > >Is that an "encrypt-only" key? [...] in the olden days of pgp 2.x, some people would make two keypairs, and would use one only for signing and one only for encrypting, so, if someone now were to generate a v4 rsa key and flag it as encrypt only, it might be (?mis)taken in exactly the v3 context, that the user intended it as an encrypt-only key, and, for whatever reason, might prefer to do it this way and not deal with subkeys the only problem would be if it could be flagged this way *un-intentionally*, which doesn't seem to be the case with Respect, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From owner-ietf-openpgp@mail.imc.org Fri Jul 18 18:32:52 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16574 for ; Fri, 18 Jul 2003 18:32:51 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IM6Hqt028850 for ; Fri, 18 Jul 2003 15:06:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IM6HW5028849 for ietf-openpgp-bks; Fri, 18 Jul 2003 15:06:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from lake.cyberia.net.lb (lake.cyberia.net.lb [195.112.195.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IM6Eqt028840 for ; Fri, 18 Jul 2003 15:06:15 -0700 (PDT) (envelope-from matic@cyberia.net.lb) Received: from ppp-11-96.cyberia.net.lb ([195.112.214.97]) by lake.cyberia.net.lb with SMTP id <20030718215544.BFMI18697.lake@ppp-11-96.cyberia.net.lb> for ; Sat, 19 Jul 2003 00:55:44 +0300 From: "Imad R. Faiad" To: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Date: Sat, 19 Jul 2003 00:06:01 +0200 Message-ID: References: <20030718005724.GD32097@jabberwocky.com> <20030718171037.GA12613@jabberwocky.com> In-Reply-To: <20030718171037.GA12613@jabberwocky.com> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6IM6Gqt028845 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 Hello David, If it's an RSA key, then I guess that it is both, unless the implementation honors the use flags, and the OpenPGP's implied use of the public key algorithm. All of the public key algorithms support signing, therefore, until a time when there is a public key algorithm which does not, one can say that all OpenPGP keys can be signing keys. One can generalize that and say, that all OpenPGP key are encrypt enabled also, with the exception of DSA keys. While you control with what key/subkey you sign with, you cannot control what key will be used when encrypted messages are sent to you. I personally, will always prefer to encrypt to a signing key, if at all the public key algorithm supports encryption. If there are any subkeys, I will chose the oldest, or a signing subkey, just to have some "PHUN", regardless of whether it is revoked or not. And there is nothing that you can do about it! And I would recommend that every OpenPGP user does the same. Binding is not sufficient, all it implies is that the one who had the secret part of the primary key at the time chose to sign that subkey. A key or subkey should be self signed, this is an indication that whoever purports to have issued it had the secret part at the time. A UID has to be signed by the primary key. In short:- 1) A primary key with no self signature is meaningless. 2) A UID with no signature from the primary key is meaningless. 3) A subkey with no self signature and no binding signature from the primary key is meaningless also. Hope the above helps, Best regards Imad R. Faiad On Fri, 18 Jul 2003 13:10:37 -0400, you wrote: > >[F651E0D5]*** PGP SIGNATURE VERIFICATION *** >[F651E0D5]*** Hash: SHA1 >[F651E0D5]*** Status: Good Signature from Invalid Key >[F651E0D5]*** Alert: Please verify signer's key before trusting signature. >[F651E0D5]*** Signer: David M. Shaw >[F651E0D5]*** Note: Signing Key is a Sub-Key! >[F651E0D5]*** Key ID: 0x49E1CBC9 >[F651E0D5]*** Fingerprint: FC2A 0E9B 5122 7D7B 5923 2CE6 E266 5C87 49E1 >CBC9 [F651E0D5]*** Signed: 7/18/2003 7:10:37 PM >[F651E0D5]*** Verified: 7/18/2003 9:53:22 PM >[F651E0D5]*** BEGIN PGP VERIFIED MESSAGE *** > >On Fri, Jul 18, 2003 at 09:13:41AM -0700, Len Sassaman wrote: >> On Thu, 17 Jul 2003, David Shaw wrote: >> >> > > Simplicity is a good reason, as is the robustness of the OpenPGP >> > > system. >> > >> > I'm afraid I don't understand your response. Simplicity is a good >> > reason to add complexity? (??) >> >> I think that saying "all v4 primary keys are signature keys" actually >> simplifies things. You may disagree. > >Ah, ok. I didn't parse your response properly. > >I'm of mixed feelings on the primary is a signing key issue. There is >definite appeal to having all non-signature items in a key be bound >there by signatures. As things stand now, subkeys are bound, but user >IDs/attributes might not be. There is a nice annoyance attack in the >wait there. > >I do wonder what this case would mean in regards to the discussion >though: > >1) Generate a RSA sign+encrypt key. Naturally the user ID on that key > should have a self-signature. > >2) Now change the key flags so that the primary is encrypt-only. > >Is that an "encrypt-only" key? > >David > >[F651E0D5]*** END PGP VERIFIED MESSAGE *** -----BEGIN PGP SIGNATURE----- Version: 8.0.2irf Comment: KeyID: 0x833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBPxhu+LzDFxiDPxutAQIIagf/UqAZ1t+7gEcAO5jiYn/61KK7oXv4qmsr 5nFikx4aPco1TTcLsmjMEUPC55fxlothpVTvB2ofvng5a/r9CLag930Pcz2hIuOZ brMJPUHNuE19N4JdPoX/WU2aXFo1JONSM+30b7JS2tT88y09K3otNRF8I5JNQzIr fr2QucRLNqgs0Sgma4s04Ylq8JyaCySqoluZyS7bY6IyEhzpXPTXV/YXLK8QZdbh sJjfNtpr5Jgi0RcVK8HP8Mbe9QTflr11ClUC9h/xipFLYDzZpLqfoksfUqC4gB91 +7ntAm7w9WZNvWo/ocL/8T1DKV7KjBhTTKgexq1OfXdMWEt2vhQhDA== =n4Us -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jul 18 23:43:42 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22111 for ; Fri, 18 Jul 2003 23:43:42 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J3N6qt039119 for ; Fri, 18 Jul 2003 20:23:06 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6J3N6tR039118 for ietf-openpgp-bks; Fri, 18 Jul 2003 20:23:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J3N4qt039097 for ; Fri, 18 Jul 2003 20:23:05 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6J3N2k19400 for ietf-openpgp@imc.org; Fri, 18 Jul 2003 23:23:02 -0400 Date: Fri, 18 Jul 2003 23:23:02 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030719032302.GF12613@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030718005724.GD32097@jabberwocky.com> <20030718171037.GA12613@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (75% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jul 19, 2003 at 12:06:01AM +0200, Imad R. Faiad wrote: > I personally, will always prefer to > encrypt to a signing key, if at all > the public key algorithm supports > encryption. If there are any subkeys, > I will chose the oldest, or a signing > subkey, just to have some "PHUN", regardless > of whether it is revoked or not. > And there is nothing that you can do > about it! And I would recommend that > every OpenPGP user does the same. Not me. I just pick a random person from the keyserver and encrypt to them. Now that's really phun. David From subs-reminder@imc.org Sat Jul 19 20:09:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26279 for ; Sat, 19 Jul 2003 20:09:38 -0400 (EDT) From: subs-reminder@imc.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K09cqt039658 for ; Sat, 19 Jul 2003 17:09:38 -0700 (PDT) (envelope-from subs-reminder@imc.org) Received: (from root@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6K09cAg039657; Sat, 19 Jul 2003 17:09:38 -0700 (PDT) Date: Sat, 19 Jul 2003 17:09:38 -0700 (PDT) Message-Id: <200307200009.h6K09cAg039657@above.proper.com> To: openpgp-archive@ietf.org Subject: [[471301210]] Subscription to ietf-openpgp for openpgp-archive@lists.ietf.org Greetings. This message is a periodic reminder that openpgp-archive@lists.ietf.org is subscribed to the ietf-openpgp mailing list. *** SEE BELOW: PLEASE DO NOT RESPOND TO THIS MESSAGE. *** There are two purposes for this message: - If this message is bounced by your mail server, I can remove you from the mailing list and reduce waste of bandwidth and resources. (If you are reading this message, it clearly didn't get bounced!) - Some people stay subscribed to mailing lists even though they do not want to because they do not know how to unsubscribe. If you want to stay subscribed to the ietf-openpgp mailing list, you do not need to do anything. Feel free to delete this message. On the other hand, if you want to unsubscribe from this list, simply go to the following link: If for some reason you cannot go to that web site, you can also unsubscribe by email; however, doing so is not as likely to get you unsubscribed as the web site is. To unsubscribe using email, you can respond to this message and I will unsubscribe you by hand in the next few days. Again, this is not assured to work because your mail system may make it impossible for me to determine who you are or what you want to unsubscribe to. Alternatively, you can send a plain-text message to: ietf-openpgp-request@imc.org with the single word unsubscribe in the body of the message. This last method assumes that the "From:" address in your mail is "openpgp-archive@lists.ietf.org". Again, using the web site above is more likely to work than this method (due to limitations in Majordomo, the mailing list software we currently use). If you have any questions, feel free to contact me. --Paul Hoffman, list administrator From owner-ietf-openpgp@mail.imc.org Sun Jul 20 06:02:08 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15885 for ; Sun, 20 Jul 2003 06:02:08 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K9faqt018119 for ; Sun, 20 Jul 2003 02:41:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6K9fadi018118 for ietf-openpgp-bks; Sun, 20 Jul 2003 02:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K9fZqt018113 for ; Sun, 20 Jul 2003 02:41:36 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Sun, 20 Jul 2003 02:41:34 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 20 Jul 2003 02:41:39 -0700 Subject: Re: Adding in BZ2 compression? From: Jon Callas To: Len Sassaman CC: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7/17/03 3:13 PM, "Len Sassaman" wrote: > Putting multiple options for anything into a protocol does practical > implications in the context of an anonymity system, however. (I'm not > saying this should prevent adding a new compression algorithm if it serves > a purpose -- it's just something to keep in mind.) > I was basically against it until it was explained to me why people wanted it, and I ended up thinking, "Hmmm, we don't have a compression system in there that's newer than 1977, and customers are often right." >> Yes, I know that there are potential interoperability issues when keys get >> migrated around, but I also of the opinion that when an implementation >> imports a key, it should make sure that the preferences reflect what it >> supports. > > Amen. Can that be explicitly stated in the next draft? > I'm under the impression that it already says "SHOULD" in there. I don't think it should be any stronger. It's a feature of OpenPGP that it's small. I don't want to force someone who wants to embed OpenPGP in something like a pager network (yeah, yeah, these days pagers play videos) to have to do everything in PGP or GPG. OpenPGP is not supposed to mandate all the features a good desktop program should have. Jon From owner-ietf-openpgp@mail.imc.org Sun Jul 20 06:20:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16037 for ; Sun, 20 Jul 2003 06:20:12 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KA5Bqt020301 for ; Sun, 20 Jul 2003 03:05:11 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KA5BDU020300 for ietf-openpgp-bks; Sun, 20 Jul 2003 03:05:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KA5Aqt020293 for ; Sun, 20 Jul 2003 03:05:10 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Sun, 20 Jul 2003 03:05:08 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 20 Jul 2003 03:05:14 -0700 Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) From: Jon Callas To: OpenPGP Message-ID: In-Reply-To: <20030715010938.GA1241@jabberwocky.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >>> Can you explain what troubles you about encrypt-only primaries? >> >> Aside from being an unclean exception to a simple model :-? > > I don't see exceptions here. The model is quite clearly and simply > stated in 2440. Any key can be of any type. There are no exceptions. > Does this mean that there are possible arrangements of packets that > make no sense? Sure, so don't do that. > > I see your suggestion as adding an exception: any key can be of any > type, except that the primary must be able to certify. 2440 already says that a top-level key must be able to sign. Getting, however to the issue in the subject line, I don't think 2440 should require self-signed user ids. Consider the following statements: "Call me Ishmael." "Call him Ishmael." The first corresponds to a self-signed UID. The latter to an introducer signature. I think that PGP UIDs can be SDSI names. More than that, they should be. I would like to be able to add a user id to someone's key because I want to, and I sign it myself, and let it go at that. Here's my real-world example. A person I work with, call this person "John Doe," has a PGP key with the UID "jdoe@pgp.com" on it. However, this person *always* sends mail from "john.doe@pgp.com" and I am constantly having to cancel keyserver searches and then go manually select the right key. It drive me up the blinking wall. I have asked said person to add in the proper user name on a number of occasions, and am still waiting. It would make me eternally happy if I can add the user name I want to that key. It isn't self-signed, it's signed my *me*. Why should *my* software accept UIDs as valid that are signed by me? Now then, we get into a small bit of interesting protocol if I export that key. But I don't see why that protocol has to be in 2440. Here are some issues: * What happens when I export that key? Should my software not export UIDs that aren't self-signed? I don't care. Well, perhaps more to the point, I consider that a bit of software design, not standards work. * What happens if I import a key that has a UID that isn't self-signed? Should it strip it? Should it strip it if it is signed by someone who is a trusted introducer? Again, I consider that software design. * What happens if a key is placed on a server? Should all non-self-signed UIDs be stripped? I think that's a matter for the server owner, but "Yes" is a fine answer. If an implementation didn't export these "SDSI UIDs" I could live with it. It might be nice to be able to import a SDSI UID that was signed by entities I trust. But I could live without that. But -- I consider all this to be software design issues, not standards issues. The standard should allow gentlepersons to disagree on some facets of design and use -- especially when the standard punts the whole issue of trust. Jon From owner-ietf-openpgp@mail.imc.org Sun Jul 20 08:52:00 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17978 for ; Sun, 20 Jul 2003 08:52:00 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KCYQqt029385 for ; Sun, 20 Jul 2003 05:34:26 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KCYPtU029384 for ietf-openpgp-bks; Sun, 20 Jul 2003 05:34:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KCYOqt029375 for ; Sun, 20 Jul 2003 05:34:25 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6KCYHh13722; Sun, 20 Jul 2003 08:34:17 -0400 Date: Sun, 20 Jul 2003 08:34:17 -0400 From: David Shaw To: Jon Callas Cc: OpenPGP Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030720123417.GC29073@jabberwocky.com> Mail-Followup-To: Jon Callas , OpenPGP References: <20030715010938.GA1241@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (64% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jul 20, 2003 at 03:05:14AM -0700, Jon Callas wrote: > > >>> Can you explain what troubles you about encrypt-only primaries? > >> > >> Aside from being an unclean exception to a simple model :-? > > > > I don't see exceptions here. The model is quite clearly and simply > > stated in 2440. Any key can be of any type. There are no exceptions. > > Does this mean that there are possible arrangements of packets that > > make no sense? Sure, so don't do that. > > > > I see your suggestion as adding an exception: any key can be of any > > type, except that the primary must be able to certify. > > 2440 already says that a top-level key must be able to sign. I'm not sure 2440 says that. The relevant bit is in section 11.1, which says "In a key that has a main key and subkeys, the primary key MUST be a key capable of signing." I took this, perhaps wrongly, at face value - that is, if a key had subkeys, the primary had to be able to sign (for the binding signatures, presumably). The flip side of this is that if a key does not have subkeys (and there is nothing wrong with a V4 key without subkeys), the primary did not have to be able to sign. Did I misinterpret the intent in 2440 there? If "a key that has a main key and subkeys" was intended to mean "V4 key", then I strongly suggest changing it to say "V4 key" explicitly to avoid the confusion that spawned a good bit of this thread. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/GoxJ4mZch0nhy8kRAiK6AKC88In7Cidl9koc6/RpUNMtr6tCYgCfdlaO LbD2O+VjN0IyT2Rb1zEC7z4= =zqVR -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun Jul 20 12:08:48 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22034 for ; Sun, 20 Jul 2003 12:08:48 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KFmGqt042488 for ; Sun, 20 Jul 2003 08:48:16 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KFmGNR042487 for ietf-openpgp-bks; Sun, 20 Jul 2003 08:48:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KFmFqt042480 for ; Sun, 20 Jul 2003 08:48:15 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6KFm8X15522; Sun, 20 Jul 2003 11:48:08 -0400 Date: Sun, 20 Jul 2003 11:48:07 -0400 From: David Shaw To: Jon Callas Cc: Len Sassaman , OpenPGP Subject: Re: Adding in BZ2 compression? Message-ID: <20030720154807.GD29073@jabberwocky.com> Mail-Followup-To: Jon Callas , Len Sassaman , OpenPGP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (64% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jul 20, 2003 at 02:41:39AM -0700, Jon Callas wrote: > I was basically against it until it was explained to me why people > wanted it, and I ended up thinking, "Hmmm, we don't have a > compression system in there that's newer than 1977, and customers > are often right." I rather like the idea of OpenPGP as an archival primitive. > >> Yes, I know that there are potential interoperability issues when keys get > >> migrated around, but I also of the opinion that when an implementation > >> imports a key, it should make sure that the preferences reflect what it > >> supports. > > > > Amen. Can that be explicitly stated in the next draft? > > > > I'm under the impression that it already says "SHOULD" in there. I > don't think it should be any stronger. It's a feature of OpenPGP > that it's small. I don't want to force someone who wants to embed > OpenPGP in something like a pager network (yeah, yeah, these days > pagers play videos) to have to do everything in PGP or GPG. > > OpenPGP is not supposed to mandate all the features a good desktop > program should have. The current draft says: Since a self-signature contains important information about the key's use, an implementation SHOULD allow the user to rewrite the self-signature, and important information in it, such as preferences and key expiration. How about adding: Note that without the ability to rewrite a self-signature, interoperability issues may occur when the same key is used in more than one implementation. Implementations may wish to check keys upon import to ensure that the preferences on the key match the reality of the implementation. That doesn't mandate anything, but does call attention to the problem. I guess the last line could be a SHOULD if there was a desire to make it stronger. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/Grm34mZch0nhy8kRArTVAJ0QEy6D4gNSk36D7yYsEMZ7SO49RQCfTKvL KVT6B0DW1k3jjmjLlQcU0io= =/PoE -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sun Jul 20 17:42:39 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28164 for ; Sun, 20 Jul 2003 17:42:38 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLMfqt069480 for ; Sun, 20 Jul 2003 14:22:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLMeAw069479 for ietf-openpgp-bks; Sun, 20 Jul 2003 14:22:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLMaqt069469 for ; Sun, 20 Jul 2003 14:22:37 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Sun, 20 Jul 2003 14:22:34 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 20 Jul 2003 14:22:42 -0700 Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) From: Jon Callas To: David Shaw CC: OpenPGP Message-ID: In-Reply-To: <20030720123417.GC29073@jabberwocky.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7/20/03 5:34 AM, "David Shaw" wrote: > I'm not sure 2440 says that. The relevant bit is in section 11.1, > which says "In a key that has a main key and subkeys, the primary key > MUST be a key capable of signing." > > I took this, perhaps wrongly, at face value - that is, if a key had > subkeys, the primary had to be able to sign (for the binding > signatures, presumably). The flip side of this is that if a key does > not have subkeys (and there is nothing wrong with a V4 key without > subkeys), the primary did not have to be able to sign. > > Did I misinterpret the intent in 2440 there? If "a key that has a > main key and subkeys" was intended to mean "V4 key", then I strongly > suggest changing it to say "V4 key" explicitly to avoid the confusion > that spawned a good bit of this thread. Uh, I thought that meant that the top-level key can't be an encrypt-only key. So yes, I was quite sure that 2440 said what you wanted. Jon From owner-ietf-openpgp@mail.imc.org Sun Jul 20 17:48:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28235 for ; Sun, 20 Jul 2003 17:48:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLZ9qt070150 for ; Sun, 20 Jul 2003 14:35:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLZ915070149 for ietf-openpgp-bks; Sun, 20 Jul 2003 14:35:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLZ8qt070143 for ; Sun, 20 Jul 2003 14:35:09 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Sun, 20 Jul 2003 14:35:06 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 20 Jul 2003 14:35:14 -0700 Subject: Re: Adding in BZ2 compression? From: Jon Callas To: David Shaw CC: Len Sassaman , OpenPGP Message-ID: In-Reply-To: <20030720154807.GD29073@jabberwocky.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7/20/03 8:48 AM, "David Shaw" wrote: >> I was basically against it until it was explained to me why people >> wanted it, and I ended up thinking, "Hmmm, we don't have a >> compression system in there that's newer than 1977, and customers >> are often right." > > I rather like the idea of OpenPGP as an archival primitive. > That's what sold me, too. > How about adding: > > Note that without the ability to rewrite a self-signature, > interoperability issues may occur when the same key is used in more > than one implementation. Implementations may wish to check keys > upon import to ensure that the preferences on the key match the > reality of the implementation. > > That doesn't mandate anything, but does call attention to the problem. > I guess the last line could be a SHOULD if there was a desire to make > it stronger. I put in: It is good practice to verify that a self-signature imported into an implementation doesn't advertise features that the implementation doesn't support, rewriting the signature as appropriate. Jon From owner-ietf-openpgp@mail.imc.org Mon Jul 21 13:42:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04940 for ; Mon, 21 Jul 2003 13:42:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LGcKqt051687 for ; Mon, 21 Jul 2003 09:38:20 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6LGcKsC051686 for ietf-openpgp-bks; Mon, 21 Jul 2003 09:38:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LGcJqt051680 for ; Mon, 21 Jul 2003 09:38:19 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6LGc6T09830; Mon, 21 Jul 2003 12:38:06 -0400 Date: Mon, 21 Jul 2003 12:38:06 -0400 From: David Shaw To: Jon Callas Cc: Len Sassaman , OpenPGP Subject: Re: Adding in BZ2 compression? Message-ID: <20030721163806.GG29969@jabberwocky.com> Mail-Followup-To: Jon Callas , Len Sassaman , OpenPGP References: <20030720154807.GD29073@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (52% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jul 20, 2003 at 02:35:14PM -0700, Jon Callas wrote: > > How about adding: > > > > Note that without the ability to rewrite a self-signature, > > interoperability issues may occur when the same key is used in more > > than one implementation. Implementations may wish to check keys > > upon import to ensure that the preferences on the key match the > > reality of the implementation. > > > > That doesn't mandate anything, but does call attention to the problem. > > I guess the last line could be a SHOULD if there was a desire to make > > it stronger. > > I put in: > > It is good practice to verify that a self-signature imported into an > implementation doesn't advertise features that the implementation doesn't > support, rewriting the signature as appropriate. Excellent. That works for me. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/HBbu4mZch0nhy8kRAoIUAKCkx6H6DqxCw3OoWRWAUqjGOfe+owCgowJW 5E9hwKXFBzbRf4M1hP95T/o= =udOS -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Jul 22 14:10:53 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21275 for ; Tue, 22 Jul 2003 14:10:53 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHlUqt060618 for ; Tue, 22 Jul 2003 10:47:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MHlUni060617 for ietf-openpgp-bks; Tue, 22 Jul 2003 10:47:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHlRqt060604 for ; Tue, 22 Jul 2003 10:47:28 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6MHlP7B023619; Tue, 22 Jul 2003 13:47:25 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6MHlNCQ025166; Tue, 22 Jul 2003 13:47:24 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h6MHlNFJ015752; Tue, 22 Jul 2003 13:47:23 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h6MHlNuV014275; Tue, 22 Jul 2003 13:47:23 -0400 (EDT) To: Werner Koch Cc: Jon Callas , OpenPGP Subject: Re: key flag for authentication References: <003901c33356$4e3e0fc0$c23fa8c0@transarc.ibm.com> <20030718011341.GF32097@jabberwocky.com> <87znjc8bb9.fsf@alberti.g10code.de> From: Derek Atkins Date: 22 Jul 2003 13:47:22 -0400 In-Reply-To: <87znjc8bb9.fsf@alberti.g10code.de> Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > On Thu, 17 Jul 2003 21:13:41 -0400, David Shaw said: > > >> Is there a consensus for this? I'm happy with anything, myself. > > > I support it. > > Me too of course. Ok, looks like we've got concensus on this... -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Tue Jul 22 14:11:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21299 for ; Tue, 22 Jul 2003 14:11:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHs9qt061424 for ; Tue, 22 Jul 2003 10:54:09 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MHs9Qb061423 for ietf-openpgp-bks; Tue, 22 Jul 2003 10:54:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHs4qt061413 for ; Tue, 22 Jul 2003 10:54:04 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6MHs37B025840; Tue, 22 Jul 2003 13:54:03 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6MHs2CQ025622; Tue, 22 Jul 2003 13:54:02 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h6MHs2FJ016244; Tue, 22 Jul 2003 13:54:02 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h6MHs19g014296; Tue, 22 Jul 2003 13:54:01 -0400 (EDT) To: Jon Callas Cc: David Shaw , Len Sassaman , OpenPGP From: Derek Atkins Subject: Re: Adding in BZ2 compression? References: Date: 22 Jul 2003 13:54:01 -0400 In-Reply-To: Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > On 7/20/03 8:48 AM, "David Shaw" wrote: > > >> I was basically against it until it was explained to me why people > >> wanted it, and I ended up thinking, "Hmmm, we don't have a > >> compression system in there that's newer than 1977, and customers > >> are often right." > > > > I rather like the idea of OpenPGP as an archival primitive. > > > > That's what sold me, too. Ok. I have no real objections to adding the algo -- I'm just worried about the interop issues. Also, we still need to show multiple implementations to progress to DRAFT standard, so if we're adding new features it might take longer to do so. Have we had any OpenPGP Bakeoffs? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant From owner-ietf-openpgp@mail.imc.org Wed Jul 23 10:36:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15245 for ; Wed, 23 Jul 2003 10:36:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NE5aqt047030 for ; Wed, 23 Jul 2003 07:05:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NE5apP047029 for ietf-openpgp-bks; Wed, 23 Jul 2003 07:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NE5Yqt046981 for ; Wed, 23 Jul 2003 07:05:35 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6NE5T713126 for ietf-openpgp@imc.org; Wed, 23 Jul 2003 10:05:29 -0400 Date: Wed, 23 Jul 2003 10:05:29 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Text "attributes" Message-ID: <20030723140529.GA12889@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Crescent (29% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An interesting problem came up on one of the GnuPG mailing lists a little while ago, and I thought I'd mention it here. A vision-impaired user was using GnuPG via a text reader and mentioned that photo IDs were obviously not going to be that useful to him. The idea came up of using an additional attribute subpacket to include a textual user ID together with the photo attribute subpacket (both inside a single attribute ID), rather like the HTML "alt" tag is used to provide a text string for when an image can not be displayed. It would be easy enough to do: just define attribute subpacket 2 as a UTF8 string type. Implementations could handle it however they chose. Note that I'm not necessarily suggesting this for 2440bis. Just something to think about in the future. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/HpYp4mZch0nhy8kRAqdhAKCYj2srvCxclI/UctclFH7ox9aavwCgpN+H 26OPYOnHgJI8Vpl87LKtKag= =d/++ -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Jul 23 14:19:22 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22262 for ; Wed, 23 Jul 2003 14:19:21 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NHewqt056232 for ; Wed, 23 Jul 2003 10:40:58 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NHew2K056231 for ietf-openpgp-bks; Wed, 23 Jul 2003 10:40:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NHeuqt056225 for ; Wed, 23 Jul 2003 10:40:57 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from mailserver1.hushmail.com (mailserver1.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP id 4EF7F6EB9 for ; Wed, 23 Jul 2003 10:40:51 -0700 (PDT) Received: from mailserver1.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver1.hushmail.com (8.12.6/8.12.3) with ESMTP id h6NHepC4057333 for ; Wed, 23 Jul 2003 10:40:51 -0700 (PDT) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver1.hushmail.com (8.12.6/8.12.3/Submit) id h6NHepjh057332 for ietf-openpgp@imc.org; Wed, 23 Jul 2003 10:40:51 -0700 (PDT) Message-Id: <200307231740.h6NHepjh057332@mailserver1.hushmail.com> Date: Wed, 23 Jul 2003 10:40:51 -0700 To: ietf-openpgp@imc.org Subject: Re: Text "attributes" From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 23 Jul 2003 07:05:29 -0700 David Shaw wrote: >An interesting problem came up on one of the GnuPG mailing lists >a >little while ago, and I thought I'd mention it here. > >A vision-impaired user was using GnuPG via a text reader and mentioned >that photo IDs were obviously not going to be that useful to him. > The >idea came up of using an additional attribute subpacket to include >a >textual user ID together with the photo attribute subpacket (both >inside a single attribute ID), rather like the HTML "alt" tag is >used >to provide a text string for when an image can not be displayed. > >It would be easy enough to do: just define attribute subpacket 2 >as a >UTF8 string type. Implementations could handle it however they >chose. > >Note that I'm not necessarily suggesting this for 2440bis. Just >something to think about in the future. along those lines, it might be helpful to such users to have an 'audio id' (the key signer's greeting in his/her own voice, [possibly together with a few other spoken sounds, enough to enable a text-to-speech synthesis in that voice, so that the receiver can hear each pgp message read in the voice of that sender]), the text reader can do the implementation from the saved audio id attribute (which can display the 'text' only attribute for deaf users who have no use for the audio component) for anyone interested in implementation specifically with the needs of the disabled in mind, here is a good site of helpful links: http://www.wata.org/resource/highlighted_links.htm with Respect, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From owner-ietf-openpgp@mail.imc.org Wed Jul 23 17:24:16 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03359 for ; Wed, 23 Jul 2003 17:24:15 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NL20qt069883 for ; Wed, 23 Jul 2003 14:02:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NL1xnY069882 for ietf-openpgp-bks; Wed, 23 Jul 2003 14:01:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NL1uqt069877 for ; Wed, 23 Jul 2003 14:01:56 -0700 (PDT) (envelope-from jon@callas.org) Received: from [192.168.1.29] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Wed, 23 Jul 2003 14:01:52 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 23 Jul 2003 14:01:56 -0700 Subject: Re: Adding in BZ2 compression? From: Jon Callas To: Derek Atkins CC: David Shaw , Len Sassaman , OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 7/22/03 10:54 AM, "Derek Atkins" wrote: > Ok. I have no real objections to adding the algo -- I'm just worried > about the interop issues. > There are no interop issues because it's a MAY feature that presently no one implements. :-) Implementations are already supposed to handle both ZIP and zlib prefs, so it shouldn't be an issue. (Incidentally, here at PGP, we presently implement only ZIP, but decided to add in both zlib and bz2 for a future major relase.) > Also, we still need to show multiple implementations to progress to > DRAFT standard, so if we're adding new features it might take longer > to do so. Have we had any OpenPGP Bakeoffs? I think so, but I wasn't on top of this for a while. I'm willing to help push this now. Jon From owner-ietf-openpgp@mail.imc.org Thu Jul 24 02:52:12 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA26668 for ; Thu, 24 Jul 2003 02:52:11 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O6P4qt098771 for ; Wed, 23 Jul 2003 23:25:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6O6P4nM098770 for ietf-openpgp-bks; Wed, 23 Jul 2003 23:25:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O6P2qt098761 for ; Wed, 23 Jul 2003 23:25:03 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.181] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Wed, 23 Jul 2003 23:25:02 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 23 Jul 2003 23:25:00 -0700 Subject: Re: PoP & Signer's User ID subpacket? From: Jon Callas To: Derek Atkins , David Shaw CC: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit On 6/17/03 8:02 AM, "Derek Atkins" wrote: > > Sure, this is fine... Theoretically the real key owner should have > access to both private keys at the same time, so this shouldn't be an > issue. Using a subpacket is fine. I still belive this is a MUST ;) I'm happy with any suitable solution, but I have a grumbly thing to add in. The general case of this is something we've called "signature stealing" and is always possible in a system that involves administrative processes. All you have to do is take someone else's signing key and start shopping around for someone who is careless enough (or bribable enough) to certify it. You can then claim that you made any signature made by the victim of that attack. This is not a flaw in OpenPGP, it is a flaw in the very nature of digital signatures. It is a flaw that can be narrowed, but not solved, period end of sentence. Furthermore, there is a sense in which it's bad security practice to worry about it too much. The reason is that it creates an opportunity for attack escalation; it makes the system more brittle. In simple words, the harder it is to steal a signature, then the more valuable a bogus cert is, and the more devastating such an attack is to the victim. Please note that I'm not suggesting we do nothing here. Anything we do to improve the bindings is good. I'm merely pointing out that we shouldn't get wrapped around the axle over an issue that is unsolvable. A clever signature thief can claim possession of those signatures, and refuse to make more on the grounds that they have retired that key and are now using *this* one. This is merely another place where sticky human issues can't be obviated by mathematics. Jon From owner-ietf-openpgp@mail.imc.org Thu Jul 24 11:45:57 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11486 for ; Thu, 24 Jul 2003 11:45:57 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OFJ8qt055343 for ; Thu, 24 Jul 2003 08:19:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OFJ8TS055342 for ietf-openpgp-bks; Thu, 24 Jul 2003 08:19:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OFJ6qt055337 for ; Thu, 24 Jul 2003 08:19:06 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6OFJ50L002459; Thu, 24 Jul 2003 11:19:05 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6OFJ43n005710; Thu, 24 Jul 2003 11:19:05 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h6OFJ3U8016125; Thu, 24 Jul 2003 11:19:03 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h6OFJ3iC018950; Thu, 24 Jul 2003 11:19:03 -0400 (EDT) To: Jon Callas Cc: David Shaw , OpenPGP Subject: Re: PoP & Signer's User ID subpacket? References: From: Derek Atkins Date: 24 Jul 2003 11:19:03 -0400 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > On 6/17/03 8:02 AM, "Derek Atkins" wrote: > > > > > Sure, this is fine... Theoretically the real key owner should have > > access to both private keys at the same time, so this shouldn't be an > > issue. Using a subpacket is fine. I still belive this is a MUST ;) > > I'm happy with any suitable solution, but I have a grumbly thing to add in. > > The general case of this is something we've called "signature stealing" and > is always possible in a system that involves administrative processes. All > you have to do is take someone else's signing key and start shopping around > for someone who is careless enough (or bribable enough) to certify it. You > can then claim that you made any signature made by the victim of that > attack. How does this attack work if the signature subkey _REQUIRES_ cross certification? If I wanted to assume your signature key, how am I supposed to get your signature subkey to sign my primary key in order to perform the (to-be-required) cross-certification? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Fri Jul 25 08:45:19 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03435 for ; Fri, 25 Jul 2003 08:45:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PCMjqt044249 for ; Fri, 25 Jul 2003 05:22:45 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PCMj1X044248 for ietf-openpgp-bks; Fri, 25 Jul 2003 05:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PCMiqt044239 for ; Fri, 25 Jul 2003 05:22:44 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6PCMYS16643 for ietf-openpgp@imc.org; Fri, 25 Jul 2003 08:22:34 -0400 Date: Fri, 25 Jul 2003 08:22:34 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Text "attributes" Message-ID: <20030725122234.GA16520@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200307231740.h6NHepjh057332@mailserver1.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200307231740.h6NHepjh057332@mailserver1.hushmail.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Crescent (14% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 23, 2003 at 10:40:51AM -0700, vedaal@hush.com wrote: > On Wed, 23 Jul 2003 07:05:29 -0700 David Shaw > wrote: > > >An interesting problem came up on one of the GnuPG mailing lists a > >little while ago, and I thought I'd mention it here. > > > >A vision-impaired user was using GnuPG via a text reader and > >mentioned that photo IDs were obviously not going to be that useful > >to him. The idea came up of using an additional attribute > >subpacket to include a textual user ID together with the photo > >attribute subpacket (both inside a single attribute ID), rather > >like the HTML "alt" tag is used to provide a text string for when > >an image can not be displayed. > > > >It would be easy enough to do: just define attribute subpacket 2 as > >a UTF8 string type. Implementations could handle it however they > >chose. > > > >Note that I'm not necessarily suggesting this for 2440bis. Just > >something to think about in the future. > > along those lines, it might be helpful to such users to have an > 'audio id' (the key signer's greeting in his/her own voice, > [possibly together with a few other spoken sounds, enough to enable > a text-to-speech synthesis in that voice, so that the receiver can > hear each pgp message read in the voice of that sender]), I don't think that including speech sounds to enable text-to-speech is appropriate in a OpenPGP key, but I'm not against a generic sound attribute. I imagine it could be used (among other things) as a "Hi there, this is David, and my fingerprint is ABCD..." It is of course more complex than text since we'd need to pick at least one sound format to use (WAV? AU? MP3? something else?) It is also large. (Again, just speculating idly about the future - not talking about 2440bis here). David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.3-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj8hIQoqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJmm0An0EivrfQrPUg2kRw9z6U84oT8R8BAJ0W dgWya6Ihjyx0owGIpc9FqAMBqA== =aYvm -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Fri Jul 25 17:27:17 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26814 for ; Fri, 25 Jul 2003 17:27:16 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PL6lqt087140 for ; Fri, 25 Jul 2003 14:06:47 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PL6lpD087139 for ietf-openpgp-bks; Fri, 25 Jul 2003 14:06:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PL6jqt087134 for ; Fri, 25 Jul 2003 14:06:45 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA10069 for ; Fri, 25 Jul 2003 17:06:34 -0400 (EDT) Message-ID: <004a01c352f0$232ebc80$2ac52609@transarc.ibm.com> From: "Michael Young" To: "OpenPGP" References: Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User IDsubpacket?) Date: Fri, 25 Jul 2003 17:03:02 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Jon Callas" writes: > 2440 already says that a top-level key must be able to sign. That was my interpretation, but David read it another way and his reading was not unreasonable. I'd ask that we clarify the language. Someone suggested saying "V4" rather than "that has a main key and subkeys"; that works for me. > I would like to be able to add a user id to someone's key because I want to, > and I sign it myself, and let it go at that. Jon presents a very reasonable example. If it's for his personal use, then it can be encapsulated in user agents (not the protocol), much the way trust is today. (In fact, the value in signing such a local alias is debatable.) I sorely wish that user agents offered this already. If you feel that this is something that should be exportable, then indeed, we need to allow non-selfsigned identities. I considered this use, and had decided that I could live without it (in the protocol) in order to impose a strict self-signature rule. But I'm willing to relent. As Jon points out, keyservers and user agents can (and probably should) impose their own restrictions at storage/import time. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPyGbAuc3iHYL8FknEQIN/gCcD7Wtg2CX0/Nm2zuN/HsgrNqe6BMAnjAb miYM1gtkVTRqzxkbEel4qCRH =/lRt -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Tue Jul 29 14:30:15 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03928 for ; Tue, 29 Jul 2003 14:30:14 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TI2hqt074700 for ; Tue, 29 Jul 2003 11:02:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TI2hhU074699 for ietf-openpgp-bks; Tue, 29 Jul 2003 11:02:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TI2fqt074694 for ; Tue, 29 Jul 2003 11:02:42 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h6TI0xm05862 for ietf-openpgp@imc.org; Tue, 29 Jul 2003 11:00:59 -0700 Date: Tue, 29 Jul 2003 11:00:59 -0700 From: "Hal Finney" Message-Id: <200307291800.h6TI0xm05862@finney.org> To: ietf-openpgp@imc.org Subject: Incompatibility between NAI command line and PGP 8.0 keys Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, at NAI we have a report that some PGP 8.0 keys can't be imported into the NAI "E-Business Server" command line version 7.1.1. Can someone post an 8.0-generated key and I will see if there are any problems importing it? We want to be sure and retain compatibility between the various OpenPGP implementations if possible. Hal Finney From owner-ietf-openpgp@mail.imc.org Wed Jul 30 01:15:10 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22979 for ; Wed, 30 Jul 2003 01:15:09 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U4rlqt008608 for ; Tue, 29 Jul 2003 21:53:47 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6U4rltO008607 for ietf-openpgp-bks; Tue, 29 Jul 2003 21:53:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from cyphers.net (mail.cyphers.net [64.220.173.146]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U4rjqt008599 for ; Tue, 29 Jul 2003 21:53:45 -0700 (PDT) (envelope-from wprice@cyphers.net) Received: from [63.251.255.202] (account wprice HELO cyphers.net) by cyphers.net (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 1024728; Tue, 29 Jul 2003 21:53:48 -0700 Date: Tue, 29 Jul 2003 21:53:47 -0700 Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-openpgp@imc.org To: "Hal Finney" From: Will Price In-Reply-To: <200307291800.h6TI0xm05862@finney.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit This sounds to me very much like a private key format issue and not a general public key issue. We made many changes in PGP 8 to adhere to the OpenPGP RFC more closely and improve compatibility with other OpenPGP implementations. As part of this, changing the passphrase of a key or generating a new key in PGP 8.0.2+ will use the newer 0xFE private key format from the Secret Key Packet Formats section of the draft. As we have already published this source, these changes are on our website. The affected files are: libs2/pgpsdk/priv/crypto/hash/pgpHash.c libs2/pgpsdk/priv/crypto/hash/pgpHashPriv.h libs2/pgpsdk/priv/crypto/hash/pgpChecksum.c libs2/pgpsdk/priv/crypto/hash/pgpChecksum.h libs2/pgpsdk/priv/crypto/keys/pgpKeyMan.c libs2/pgpsdk/priv/crypto/pubkey/pgpDSAKey.c libs2/pgpsdk/priv/crypto/pubkey/pgpKeyMisc.c libs2/pgpsdk/priv/crypto/pubkey/pgpKeyMisc.h libs2/pgpsdk/priv/crypto/pubkey/pgpRSAKey.c Thanks! -- Will Will Price, VP Engineering PGP Corporation On Tuesday, July 29, 2003, at 11:00 AM, Hal Finney wrote: > Hi, at NAI we have a report that some PGP 8.0 keys can't be imported > into the NAI "E-Business Server" command line version 7.1.1. Can > someone post an 8.0-generated key and I will see if there are any > problems importing it? We want to be sure and retain compatibility > between the various OpenPGP implementations if possible. From owner-ietf-openpgp@mail.imc.org Wed Jul 30 13:31:36 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09618 for ; Wed, 30 Jul 2003 13:31:36 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UH6Wqt081210 for ; Wed, 30 Jul 2003 10:06:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UH6WWC081209 for ietf-openpgp-bks; Wed, 30 Jul 2003 10:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UH6Uqt081201 for ; Wed, 30 Jul 2003 10:06:30 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id E381B5B00 for ; Wed, 30 Jul 2003 10:06:24 -0700 (PDT) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id h6UH6OKs077342 for ; Wed, 30 Jul 2003 10:06:24 -0700 (PDT) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id h6UH6Oj9077341 for ietf-openpgp@imc.org; Wed, 30 Jul 2003 10:06:24 -0700 (PDT) Message-Id: <200307301706.h6UH6Oj9077341@mailserver2.hushmail.com> Date: Wed, 30 Jul 2003 10:06:24 -0700 To: ietf-openpgp@imc.org Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 29 Jul 2003 11:00:59 -0700 Hal Finney wrote: > >Hi, at NAI we have a report that some PGP 8.0 keys can't be imported >into the NAI "E-Business Server" command line version 7.1.1. Can >someone post an 8.0-generated key and I will see if there are any >problems importing it? We want to be sure and retain compatibility >between the various OpenPGP implementations if possible. i posted two keys generated in pgp 8.02, here: http://www.angelfire.com/pr/pgpf/pgp802keypairs.html the first key, 'rsav4pgp8' was generated with a passphrase the same as the name: rsav4pgp8 and by default, uses aes-256 as the protect cipher the second key, 'dhpgp8', was generated without a passphrase both are usable in pgp pre-8 versions the incompatibility you referred to was present in pgp 8.0, when it was made compatible with the newer gnupg secret key format, and keys that were exported from that version of pgp 8, could not be used in pre-8 versions, hth, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From owner-ietf-openpgp@mail.imc.org Wed Jul 30 14:10:13 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11334 for ; Wed, 30 Jul 2003 14:10:13 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UHZ3qt083608 for ; Wed, 30 Jul 2003 10:35:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UHZ3ci083607 for ietf-openpgp-bks; Wed, 30 Jul 2003 10:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UHZ2qt083591 for ; Wed, 30 Jul 2003 10:35:02 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6UHYwp04868 for ietf-openpgp@imc.org; Wed, 30 Jul 2003 13:34:58 -0400 Date: Wed, 30 Jul 2003 13:34:58 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Clarification needed on compressed messages Message-ID: <20030730173458.GH614@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (2% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was sent an interesting interoperability problem today with a signed message that wouldn't verify in GnuPG. After some examination, and once the encryption was stripped off, it seemed that it was a message of the form: signature packet + compressed packet (literal packet) That is, a signature packet, followed by a compressed packet which contained a literal packet. In the grammar, the latest draft (and 2440 also) say that a "Signed Message" is: Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message GnuPG (and it seems the new PGP) generate the One-Pass method, but still accept the common SIG+LITERAL construction. No problems there. However, since a valid "OpenPGP Message" may be a "Compressed Message", that would also make the message I received a legal construction. Is this the intent? And if so, in a SIG+COMPRESSED(LITERAL) message, is the SIG issued over COMPRESSED(LITERAL) or LITERAL ? David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc2 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iEYEARECAAYFAj8oAcIACgkQ4mZch0nhy8nJDwCfSJWF6kyPCftYxSxt8XrpFI/I oIsAoNsuRokjGOdrBu1lKlUUnBJnCXb5 =4pFJ -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Jul 30 16:23:21 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16513 for ; Wed, 30 Jul 2003 16:23:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UJoXqt092005 for ; Wed, 30 Jul 2003 12:50:33 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UJoWKf092004 for ietf-openpgp-bks; Wed, 30 Jul 2003 12:50:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UJoVqt091992 for ; Wed, 30 Jul 2003 12:50:31 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6UJoSVF018138; Wed, 30 Jul 2003 15:50:32 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6UJjOUu000631; Wed, 30 Jul 2003 15:45:24 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h6UJjNU8006697; Wed, 30 Jul 2003 15:45:23 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h6UJjNu4008415; Wed, 30 Jul 2003 15:45:23 -0400 (EDT) To: David Shaw Cc: ietf-openpgp@imc.org Subject: Re: Clarification needed on compressed messages References: <20030730173458.GH614@jabberwocky.com> From: Derek Atkins Date: 30 Jul 2003 15:45:23 -0400 In-Reply-To: <20030730173458.GH614@jabberwocky.com> Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > I was sent an interesting interoperability problem today with a signed > message that wouldn't verify in GnuPG. After some examination, and > once the encryption was stripped off, it seemed that it was a message > of the form: > > signature packet + compressed packet (literal packet) > > That is, a signature packet, followed by a compressed packet which > contained a literal packet. This should be legal. Strange, but legal.. > In the grammar, the latest draft (and 2440 also) say that a "Signed > Message" is: > > Signed Message :- Signature Packet, OpenPGP Message | > One-Pass Signed Message That's sounds right... > GnuPG (and it seems the new PGP) generate the One-Pass method, but > still accept the common SIG+LITERAL construction. No problems there. > > However, since a valid "OpenPGP Message" may be a "Compressed > Message", that would also make the message I received a legal > construction. > > Is this the intent? And if so, in a SIG+COMPRESSED(LITERAL) message, > is the SIG issued over COMPRESSED(LITERAL) or LITERAL ? I believe it is the intent, and in the SIG+(COMPRESSED(LITERAL) the SIG should be issued over the COMPRESSED(LITERAL). The only special case that I know of is SIG+LITERAL, where the SIG is over the data inside the literal and doesn't include the literal packet itself. However, all other constructions should build the SIG over the underlying PGP message object. Just my $0.02. > David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available From owner-ietf-openpgp@mail.imc.org Wed Jul 30 18:35:18 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22139 for ; Wed, 30 Jul 2003 18:35:18 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UMApqt000268 for ; Wed, 30 Jul 2003 15:10:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UMApnX000267 for ietf-openpgp-bks; Wed, 30 Jul 2003 15:10:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UMAoqt000261 for ; Wed, 30 Jul 2003 15:10:50 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id 7B14F7506 for ; Wed, 30 Jul 2003 15:10:45 -0700 (PDT) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id h6UMAjKs085267 for ; Wed, 30 Jul 2003 15:10:45 -0700 (PDT) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id h6UMAjxl085266 for ietf-openpgp@imc.org; Wed, 30 Jul 2003 15:10:45 -0700 (PDT) Message-Id: <200307302210.h6UMAjxl085266@mailserver2.hushmail.com> Date: Wed, 30 Jul 2003 15:10:45 -0700 To: ietf-openpgp@imc.org Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 29 Jul 2003 21:53:47 -0700 Will Price wrote: > >This sounds to me very much like a private key format issue and not >a >general public key issue. We made many changes in PGP 8 to adhere >to >the OpenPGP RFC more closely and improve compatibility with other >> >OpenPGP implementations. As part of this, changing the passphrase >of a >key or generating a new key in PGP 8.0.2+ will use the newer 0xFE >> >private key format from the Secret Key Packet Formats section of >the >draft. this is very interesting ! i just tried it out by exporting a key generated in gnupg 1.2.2 with the new s2k hash protection, which does not work in pre-8 pgp (except for ckt build 9), but does work without any problems in pgp 8.0.2 now here is where it becomes sort of surprising: [1] if the imported gnupg key which works in pgp 8.0.2, is exported from pgp 8.0.2, it will still not work in pre-8 pgp [2] if the passphrase is changed in pgp 8.0.2, and then exported, it still does not work in pre-8 [3] if the passphrase is removed in 8.0.2, and exported without a passphrase, then it 'does' work, in pre-8 [4] if the passphrase is removed in 8.0.2, and then then changed in 8.0.2, and then exported, it still acts like the original gnupg and does 'not' work in pre-8 (even though the passphrase is changed in 8.0.2 after the passphrase has been removed, the new pgp 8.0.2 one is still not a simple s2k hash) *but* [5] if the key is imported from 8.0.2 into pre-8 with the passphrase removed in 8.0.2, and the passphrase then changed in pre-8, then it does work (probably since pre-8 does not have the capacity to produce the complex s2k hash, so it does not, whereas pgp 8.0.2 does have this capacity, so it produces it by default for this type of key, but not for other keys generated de-novo in pgp 8.0.2) these different key import/export variations can become very hard to keep track of ;-) would suggest/request: (a) pgp 8.0.x have something in the key properties that identifies the s2k hash type (simple or complex-gnupg-type) (b) pgp 8.0.x allow the user to choose the s2k hash type when changing the passphrase, {and in the interests of maximum intercompatibility, have the default be the simple s2k hash, which can be then be changed in gnupg to the more complex one if desired, but will stillbe compatible in pre-8 pgp by default} with Respect, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 From owner-ietf-openpgp@mail.imc.org Thu Jul 31 20:33:35 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20006 for ; Thu, 31 Jul 2003 20:33:34 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VNtUqt023928 for ; Thu, 31 Jul 2003 16:55:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VNtUDw023927 for ietf-openpgp-bks; Thu, 31 Jul 2003 16:55:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.safe-mail.net (www.safe-mail.net [66.193.85.68]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VNtSqt023920 for ; Thu, 31 Jul 2003 16:55:29 -0700 (PDT) (envelope-from poiboy@SAFe-mail.net) Received: from poiboy@SAFe-mail.net by www.safe-mail.net with SAFe-mail (Exim 4.20) id 19iNGa-0007lF-2u for ietf-openpgp@imc.org; Thu, 31 Jul 2003 19:55:28 -0400 Received: from pc ([66.91.160.52]) by mail.SAFe-mail.net Subject: signature woes and reconciliation, examples appreciated Date: Thu, 31 Jul 2003 23:55:28 +0000 From: poiboy@SAFe-mail.net To: ietf-openpgp@imc.org X-SMType: Regular X-SMRef: N1-UmfCVgDT Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I recently ran into trouble trying to calculate the hash needed to verify a GnuPG (1.2.2) v3 DSA one-pass signature with my pet Python hopeful-implementation-to-be. From bis-08: (V3 sigs) 5.2.2 The data being signed is hashed, and then the signature type and creation time from the signature packet are hashed (5 additional octets). The resulting hash value is used in the signature algorithm. (sigs in general) 5.2.4 Once the data body is hashed, then a trailer is hashed. This led me to assume (+: concatenate): h = HASH( data body ) + HASH( trailer ) # based on the above final = HASH( h ) # inferred from 160-bit DSA requirement ..which didn't work, sending me back to Google and eventually to the GnuPG source. Long source-searching story shortened, I ended up with: final = HASH( data body + trailer ) ..which didn't feel right, even though it evidently worked for gpg and definitely worked for me. Things were somewhat reconciled when I found a file named 'pgpformat.txt' from a PGP 2.x archive: pgformat.txt "Signature packet" section: Offset Length Meaning 4 1 Length of following material that is implicitly included in MD calculation (=5). 5 1 Signature classification field (see below). Implicitly append this to message for MD calculation. 6 4 32-bit timestamp of when signature was made. Implicitly append this to message for MD calculation. pgformat.txt "Literal data packet, with filename and mode": Whne calculating a signature on a literal packet, the signature calculation only includes the raw literal plaintext data that begins AFTER the header fields.. Probabilities being what they are, I'm going to assume I'm on the right track and grant myself an attaboy. Up until this point I had been working *exclusively* with bis-08 and had no trouble at all working out packet structure, MPIs, etc.. Code and pseudo-code examples helped out enormously. Just thought that this might be one area where something blatantly obvious to the gurus might leave the wannabes a little perplexed (color me perplexed). I suggest adding pseudo code to more (if not all) operations in the spec (which I'd be happy to contribute as I continue along). Aloha, the poiboy From owner-ietf-openpgp@mail.imc.org Thu Jul 31 20:49:06 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20238 for ; Thu, 31 Jul 2003 20:49:05 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h710Gsqt024803 for ; Thu, 31 Jul 2003 17:16:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h710GsS7024802 for ietf-openpgp-bks; Thu, 31 Jul 2003 17:16:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h710Grqt024797 for ; Thu, 31 Jul 2003 17:16:53 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h710FG825349; Thu, 31 Jul 2003 17:15:16 -0700 Date: Thu, 31 Jul 2003 17:15:16 -0700 From: "Hal Finney" Message-Id: <200308010015.h710FG825349@finney.org> To: ietf-openpgp@imc.org, poiboy@SAFe-mail.net Subject: Re: signature woes and reconciliation, examples appreciated Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: poiboy@SAFe-mail.net > I recently ran into trouble trying to calculate the hash needed to > verify a GnuPG (1.2.2) v3 DSA one-pass signature with my pet Python > hopeful-implementation-to-be. I've had someone else run into the same problem interpreting this part of the spec. The language about "first you hash this, then you hash that, then you hash this other thing" seems very natural to me (I wrote much of it after all), working with a programming interface where you pass data incrementally into a hash context object. But other people interpret it as you did, that you produce a hash of the first part, then a hash of the second part, then a hash of the third part, and somehow combine these hashes together to get the final signature. Hal Finney From owner-ietf-openpgp@mail.imc.org Thu Jul 31 23:50:29 2003 Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23445 for ; Thu, 31 Jul 2003 23:50:29 -0400 (EDT) Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h713JLqt034262 for ; Thu, 31 Jul 2003 20:19:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h713JL55034261 for ietf-openpgp-bks; Thu, 31 Jul 2003 20:19:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h713JKqt034255 for ; Thu, 31 Jul 2003 20:19:20 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h713JH226611 for ietf-openpgp@imc.org; Thu, 31 Jul 2003 23:19:17 -0400 Date: Thu, 31 Jul 2003 23:19:17 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Clarification needed on compressed messages Message-ID: <20030801031917.GA24835@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030730173458.GH614@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (8% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 30, 2003 at 03:45:23PM -0400, Derek Atkins wrote: > David Shaw writes: > > Is this the intent? And if so, in a SIG+COMPRESSED(LITERAL) message, > > is the SIG issued over COMPRESSED(LITERAL) or LITERAL ? > > I believe it is the intent, and in the SIG+(COMPRESSED(LITERAL) the > SIG should be issued over the COMPRESSED(LITERAL). The only special > case that I know of is SIG+LITERAL, where the SIG is over the data > inside the literal and doesn't include the literal packet itself. ONEPASS+LITERAL+SIG is another case. > However, all other constructions should build the SIG over the > underlying PGP message object. This sounds very reasonable to me. I think a word or two to make that clear in the draft would be helpful: something that indicates that "bare" literal packets should have their contents hashed, but anything else should be hashed whole. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc2 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iEYEARECAAYFAj8p3DUACgkQ4mZch0nhy8kypwCfYdiXIoUPIKW55TEhUKlyFVWc YdMAoIQZtyNI8OoqXC0uI+PJ/7+7El++ =9IWM -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h713JLqt034262 for ; Thu, 31 Jul 2003 20:19:21 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h713JL55034261 for ietf-openpgp-bks; Thu, 31 Jul 2003 20:19:21 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h713JKqt034255 for ; Thu, 31 Jul 2003 20:19:20 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h713JH226611 for ietf-openpgp@imc.org; Thu, 31 Jul 2003 23:19:17 -0400 Date: Thu, 31 Jul 2003 23:19:17 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Clarification needed on compressed messages Message-ID: <20030801031917.GA24835@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030730173458.GH614@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (8% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 30, 2003 at 03:45:23PM -0400, Derek Atkins wrote: > David Shaw writes: > > Is this the intent? And if so, in a SIG+COMPRESSED(LITERAL) message, > > is the SIG issued over COMPRESSED(LITERAL) or LITERAL ? > > I believe it is the intent, and in the SIG+(COMPRESSED(LITERAL) the > SIG should be issued over the COMPRESSED(LITERAL). The only special > case that I know of is SIG+LITERAL, where the SIG is over the data > inside the literal and doesn't include the literal packet itself. ONEPASS+LITERAL+SIG is another case. > However, all other constructions should build the SIG over the > underlying PGP message object. This sounds very reasonable to me. I think a word or two to make that clear in the draft would be helpful: something that indicates that "bare" literal packets should have their contents hashed, but anything else should be hashed whole. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc2 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iEYEARECAAYFAj8p3DUACgkQ4mZch0nhy8kypwCfYdiXIoUPIKW55TEhUKlyFVWc YdMAoIQZtyNI8OoqXC0uI+PJ/7+7El++ =9IWM -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h710Gsqt024803 for ; Thu, 31 Jul 2003 17:16:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h710GsS7024802 for ietf-openpgp-bks; Thu, 31 Jul 2003 17:16:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h710Grqt024797 for ; Thu, 31 Jul 2003 17:16:53 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h710FG825349; Thu, 31 Jul 2003 17:15:16 -0700 Date: Thu, 31 Jul 2003 17:15:16 -0700 From: "Hal Finney" Message-Id: <200308010015.h710FG825349@finney.org> To: ietf-openpgp@imc.org, poiboy@SAFe-mail.net Subject: Re: signature woes and reconciliation, examples appreciated Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > From: poiboy@SAFe-mail.net > I recently ran into trouble trying to calculate the hash needed to > verify a GnuPG (1.2.2) v3 DSA one-pass signature with my pet Python > hopeful-implementation-to-be. I've had someone else run into the same problem interpreting this part of the spec. The language about "first you hash this, then you hash that, then you hash this other thing" seems very natural to me (I wrote much of it after all), working with a programming interface where you pass data incrementally into a hash context object. But other people interpret it as you did, that you produce a hash of the first part, then a hash of the second part, then a hash of the third part, and somehow combine these hashes together to get the final signature. Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VNtUqt023928 for ; Thu, 31 Jul 2003 16:55:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6VNtUDw023927 for ietf-openpgp-bks; Thu, 31 Jul 2003 16:55:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from www.safe-mail.net (www.safe-mail.net [66.193.85.68]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6VNtSqt023920 for ; Thu, 31 Jul 2003 16:55:29 -0700 (PDT) (envelope-from poiboy@SAFe-mail.net) Received: from poiboy@SAFe-mail.net by www.safe-mail.net with SAFe-mail (Exim 4.20) id 19iNGa-0007lF-2u for ietf-openpgp@imc.org; Thu, 31 Jul 2003 19:55:28 -0400 Received: from pc ([66.91.160.52]) by mail.SAFe-mail.net Subject: signature woes and reconciliation, examples appreciated Date: Thu, 31 Jul 2003 23:55:28 +0000 From: poiboy@SAFe-mail.net To: ietf-openpgp@imc.org X-SMType: Regular X-SMRef: N1-UmfCVgDT Message-Id: MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I recently ran into trouble trying to calculate the hash needed to verify a GnuPG (1.2.2) v3 DSA one-pass signature with my pet Python hopeful-implementation-to-be. >From bis-08: (V3 sigs) 5.2.2 The data being signed is hashed, and then the signature type and creation time from the signature packet are hashed (5 additional octets). The resulting hash value is used in the signature algorithm. (sigs in general) 5.2.4 Once the data body is hashed, then a trailer is hashed. This led me to assume (+: concatenate): h = HASH( data body ) + HASH( trailer ) # based on the above final = HASH( h ) # inferred from 160-bit DSA requirement ..which didn't work, sending me back to Google and eventually to the GnuPG source. Long source-searching story shortened, I ended up with: final = HASH( data body + trailer ) ..which didn't feel right, even though it evidently worked for gpg and definitely worked for me. Things were somewhat reconciled when I found a file named 'pgpformat.txt' from a PGP 2.x archive: pgformat.txt "Signature packet" section: Offset Length Meaning 4 1 Length of following material that is implicitly included in MD calculation (=5). 5 1 Signature classification field (see below). Implicitly append this to message for MD calculation. 6 4 32-bit timestamp of when signature was made. Implicitly append this to message for MD calculation. pgformat.txt "Literal data packet, with filename and mode": Whne calculating a signature on a literal packet, the signature calculation only includes the raw literal plaintext data that begins AFTER the header fields.. Probabilities being what they are, I'm going to assume I'm on the right track and grant myself an attaboy. Up until this point I had been working *exclusively* with bis-08 and had no trouble at all working out packet structure, MPIs, etc.. Code and pseudo-code examples helped out enormously. Just thought that this might be one area where something blatantly obvious to the gurus might leave the wannabes a little perplexed (color me perplexed). I suggest adding pseudo code to more (if not all) operations in the spec (which I'd be happy to contribute as I continue along). Aloha, the poiboy Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UMApqt000268 for ; Wed, 30 Jul 2003 15:10:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UMApnX000267 for ietf-openpgp-bks; Wed, 30 Jul 2003 15:10:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UMAoqt000261 for ; Wed, 30 Jul 2003 15:10:50 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id 7B14F7506 for ; Wed, 30 Jul 2003 15:10:45 -0700 (PDT) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id h6UMAjKs085267 for ; Wed, 30 Jul 2003 15:10:45 -0700 (PDT) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id h6UMAjxl085266 for ietf-openpgp@imc.org; Wed, 30 Jul 2003 15:10:45 -0700 (PDT) Message-Id: <200307302210.h6UMAjxl085266@mailserver2.hushmail.com> Date: Wed, 30 Jul 2003 15:10:45 -0700 To: ietf-openpgp@imc.org Cc: Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 29 Jul 2003 21:53:47 -0700 Will Price wrote: > >This sounds to me very much like a private key format issue and not >a >general public key issue. We made many changes in PGP 8 to adhere >to >the OpenPGP RFC more closely and improve compatibility with other >> >OpenPGP implementations. As part of this, changing the passphrase >of a >key or generating a new key in PGP 8.0.2+ will use the newer 0xFE >> >private key format from the Secret Key Packet Formats section of >the >draft. this is very interesting ! i just tried it out by exporting a key generated in gnupg 1.2.2 with the new s2k hash protection, which does not work in pre-8 pgp (except for ckt build 9), but does work without any problems in pgp 8.0.2 now here is where it becomes sort of surprising: [1] if the imported gnupg key which works in pgp 8.0.2, is exported from pgp 8.0.2, it will still not work in pre-8 pgp [2] if the passphrase is changed in pgp 8.0.2, and then exported, it still does not work in pre-8 [3] if the passphrase is removed in 8.0.2, and exported without a passphrase, then it 'does' work, in pre-8 [4] if the passphrase is removed in 8.0.2, and then then changed in 8.0.2, and then exported, it still acts like the original gnupg and does 'not' work in pre-8 (even though the passphrase is changed in 8.0.2 after the passphrase has been removed, the new pgp 8.0.2 one is still not a simple s2k hash) *but* [5] if the key is imported from 8.0.2 into pre-8 with the passphrase removed in 8.0.2, and the passphrase then changed in pre-8, then it does work (probably since pre-8 does not have the capacity to produce the complex s2k hash, so it does not, whereas pgp 8.0.2 does have this capacity, so it produces it by default for this type of key, but not for other keys generated de-novo in pgp 8.0.2) these different key import/export variations can become very hard to keep track of ;-) would suggest/request: (a) pgp 8.0.x have something in the key properties that identifies the s2k hash type (simple or complex-gnupg-type) (b) pgp 8.0.x allow the user to choose the s2k hash type when changing the passphrase, {and in the interests of maximum intercompatibility, have the default be the simple s2k hash, which can be then be changed in gnupg to the more complex one if desired, but will stillbe compatible in pre-8 pgp by default} with Respect, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UJoXqt092005 for ; Wed, 30 Jul 2003 12:50:33 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UJoWKf092004 for ietf-openpgp-bks; Wed, 30 Jul 2003 12:50:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UJoVqt091992 for ; Wed, 30 Jul 2003 12:50:31 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6UJoSVF018138; Wed, 30 Jul 2003 15:50:32 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6UJjOUu000631; Wed, 30 Jul 2003 15:45:24 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h6UJjNU8006697; Wed, 30 Jul 2003 15:45:23 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h6UJjNu4008415; Wed, 30 Jul 2003 15:45:23 -0400 (EDT) To: David Shaw Cc: ietf-openpgp@imc.org Subject: Re: Clarification needed on compressed messages References: <20030730173458.GH614@jabberwocky.com> From: Derek Atkins Date: 30 Jul 2003 15:45:23 -0400 In-Reply-To: <20030730173458.GH614@jabberwocky.com> Message-ID: Lines: 51 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: David Shaw writes: > I was sent an interesting interoperability problem today with a signed > message that wouldn't verify in GnuPG. After some examination, and > once the encryption was stripped off, it seemed that it was a message > of the form: > > signature packet + compressed packet (literal packet) > > That is, a signature packet, followed by a compressed packet which > contained a literal packet. This should be legal. Strange, but legal.. > In the grammar, the latest draft (and 2440 also) say that a "Signed > Message" is: > > Signed Message :- Signature Packet, OpenPGP Message | > One-Pass Signed Message That's sounds right... > GnuPG (and it seems the new PGP) generate the One-Pass method, but > still accept the common SIG+LITERAL construction. No problems there. > > However, since a valid "OpenPGP Message" may be a "Compressed > Message", that would also make the message I received a legal > construction. > > Is this the intent? And if so, in a SIG+COMPRESSED(LITERAL) message, > is the SIG issued over COMPRESSED(LITERAL) or LITERAL ? I believe it is the intent, and in the SIG+(COMPRESSED(LITERAL) the SIG should be issued over the COMPRESSED(LITERAL). The only special case that I know of is SIG+LITERAL, where the SIG is over the data inside the literal and doesn't include the literal packet itself. However, all other constructions should build the SIG over the underlying PGP message object. Just my $0.02. > David -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UHZ3qt083608 for ; Wed, 30 Jul 2003 10:35:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UHZ3ci083607 for ietf-openpgp-bks; Wed, 30 Jul 2003 10:35:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.132.70]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UHZ2qt083591 for ; Wed, 30 Jul 2003 10:35:02 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6UHYwp04868 for ietf-openpgp@imc.org; Wed, 30 Jul 2003 13:34:58 -0400 Date: Wed, 30 Jul 2003 13:34:58 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Clarification needed on compressed messages Message-ID: <20030730173458.GH614@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (2% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was sent an interesting interoperability problem today with a signed message that wouldn't verify in GnuPG. After some examination, and once the encryption was stripped off, it seemed that it was a message of the form: signature packet + compressed packet (literal packet) That is, a signature packet, followed by a compressed packet which contained a literal packet. In the grammar, the latest draft (and 2440 also) say that a "Signed Message" is: Signed Message :- Signature Packet, OpenPGP Message | One-Pass Signed Message GnuPG (and it seems the new PGP) generate the One-Pass method, but still accept the common SIG+LITERAL construction. No problems there. However, since a valid "OpenPGP Message" may be a "Compressed Message", that would also make the message I received a legal construction. Is this the intent? And if so, in a SIG+COMPRESSED(LITERAL) message, is the SIG issued over COMPRESSED(LITERAL) or LITERAL ? David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc2 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iEYEARECAAYFAj8oAcIACgkQ4mZch0nhy8nJDwCfSJWF6kyPCftYxSxt8XrpFI/I oIsAoNsuRokjGOdrBu1lKlUUnBJnCXb5 =4pFJ -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UH6Wqt081210 for ; Wed, 30 Jul 2003 10:06:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6UH6WWC081209 for ietf-openpgp-bks; Wed, 30 Jul 2003 10:06:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6UH6Uqt081201 for ; Wed, 30 Jul 2003 10:06:30 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id E381B5B00 for ; Wed, 30 Jul 2003 10:06:24 -0700 (PDT) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id h6UH6OKs077342 for ; Wed, 30 Jul 2003 10:06:24 -0700 (PDT) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id h6UH6Oj9077341 for ietf-openpgp@imc.org; Wed, 30 Jul 2003 10:06:24 -0700 (PDT) Message-Id: <200307301706.h6UH6Oj9077341@mailserver2.hushmail.com> Date: Wed, 30 Jul 2003 10:06:24 -0700 To: ietf-openpgp@imc.org Cc: Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 29 Jul 2003 11:00:59 -0700 Hal Finney wrote: > >Hi, at NAI we have a report that some PGP 8.0 keys can't be imported >into the NAI "E-Business Server" command line version 7.1.1. Can >someone post an 8.0-generated key and I will see if there are any >problems importing it? We want to be sure and retain compatibility >between the various OpenPGP implementations if possible. i posted two keys generated in pgp 8.02, here: http://www.angelfire.com/pr/pgpf/pgp802keypairs.html the first key, 'rsav4pgp8' was generated with a passphrase the same as the name: rsav4pgp8 and by default, uses aes-256 as the protect cipher the second key, 'dhpgp8', was generated without a passphrase both are usable in pgp pre-8 versions the incompatibility you referred to was present in pgp 8.0, when it was made compatible with the newer gnupg secret key format, and keys that were exported from that version of pgp 8, could not be used in pre-8 versions, hth, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U4rlqt008608 for ; Tue, 29 Jul 2003 21:53:47 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6U4rltO008607 for ietf-openpgp-bks; Tue, 29 Jul 2003 21:53:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from cyphers.net (mail.cyphers.net [64.220.173.146]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6U4rjqt008599 for ; Tue, 29 Jul 2003 21:53:45 -0700 (PDT) (envelope-from wprice@cyphers.net) Received: from [63.251.255.202] (account wprice HELO cyphers.net) by cyphers.net (CommuniGate Pro SMTP 4.0.6) with ESMTP-TLS id 1024728; Tue, 29 Jul 2003 21:53:48 -0700 Date: Tue, 29 Jul 2003 21:53:47 -0700 Subject: Re: Incompatibility between NAI command line and PGP 8.0 keys Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: ietf-openpgp@imc.org To: "Hal Finney" From: Will Price In-Reply-To: <200307291800.h6TI0xm05862@finney.org> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This sounds to me very much like a private key format issue and not a general public key issue. We made many changes in PGP 8 to adhere to the OpenPGP RFC more closely and improve compatibility with other OpenPGP implementations. As part of this, changing the passphrase of a key or generating a new key in PGP 8.0.2+ will use the newer 0xFE private key format from the Secret Key Packet Formats section of the draft. As we have already published this source, these changes are on our website. The affected files are: libs2/pgpsdk/priv/crypto/hash/pgpHash.c libs2/pgpsdk/priv/crypto/hash/pgpHashPriv.h libs2/pgpsdk/priv/crypto/hash/pgpChecksum.c libs2/pgpsdk/priv/crypto/hash/pgpChecksum.h libs2/pgpsdk/priv/crypto/keys/pgpKeyMan.c libs2/pgpsdk/priv/crypto/pubkey/pgpDSAKey.c libs2/pgpsdk/priv/crypto/pubkey/pgpKeyMisc.c libs2/pgpsdk/priv/crypto/pubkey/pgpKeyMisc.h libs2/pgpsdk/priv/crypto/pubkey/pgpRSAKey.c Thanks! -- Will Will Price, VP Engineering PGP Corporation On Tuesday, July 29, 2003, at 11:00 AM, Hal Finney wrote: > Hi, at NAI we have a report that some PGP 8.0 keys can't be imported > into the NAI "E-Business Server" command line version 7.1.1. Can > someone post an 8.0-generated key and I will see if there are any > problems importing it? We want to be sure and retain compatibility > between the various OpenPGP implementations if possible. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TI2hqt074700 for ; Tue, 29 Jul 2003 11:02:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6TI2hhU074699 for ietf-openpgp-bks; Tue, 29 Jul 2003 11:02:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6TI2fqt074694 for ; Tue, 29 Jul 2003 11:02:42 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h6TI0xm05862 for ietf-openpgp@imc.org; Tue, 29 Jul 2003 11:00:59 -0700 Date: Tue, 29 Jul 2003 11:00:59 -0700 From: "Hal Finney" Message-Id: <200307291800.h6TI0xm05862@finney.org> To: ietf-openpgp@imc.org Subject: Incompatibility between NAI command line and PGP 8.0 keys Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, at NAI we have a report that some PGP 8.0 keys can't be imported into the NAI "E-Business Server" command line version 7.1.1. Can someone post an 8.0-generated key and I will see if there are any problems importing it? We want to be sure and retain compatibility between the various OpenPGP implementations if possible. Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PL6lqt087140 for ; Fri, 25 Jul 2003 14:06:47 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PL6lpD087139 for ietf-openpgp-bks; Fri, 25 Jul 2003 14:06:47 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PL6jqt087134 for ; Fri, 25 Jul 2003 14:06:45 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA10069 for ; Fri, 25 Jul 2003 17:06:34 -0400 (EDT) Message-ID: <004a01c352f0$232ebc80$2ac52609@transarc.ibm.com> From: "Michael Young" To: "OpenPGP" References: Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User IDsubpacket?) Date: Fri, 25 Jul 2003 17:03:02 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Jon Callas" writes: > 2440 already says that a top-level key must be able to sign. That was my interpretation, but David read it another way and his reading was not unreasonable. I'd ask that we clarify the language. Someone suggested saying "V4" rather than "that has a main key and subkeys"; that works for me. > I would like to be able to add a user id to someone's key because I want to, > and I sign it myself, and let it go at that. Jon presents a very reasonable example. If it's for his personal use, then it can be encapsulated in user agents (not the protocol), much the way trust is today. (In fact, the value in signing such a local alias is debatable.) I sorely wish that user agents offered this already. If you feel that this is something that should be exportable, then indeed, we need to allow non-selfsigned identities. I considered this use, and had decided that I could live without it (in the protocol) in order to impose a strict self-signature rule. But I'm willing to relent. As Jon points out, keyservers and user agents can (and probably should) impose their own restrictions at storage/import time. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPyGbAuc3iHYL8FknEQIN/gCcD7Wtg2CX0/Nm2zuN/HsgrNqe6BMAnjAb miYM1gtkVTRqzxkbEel4qCRH =/lRt -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PCMjqt044249 for ; Fri, 25 Jul 2003 05:22:45 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6PCMj1X044248 for ietf-openpgp-bks; Fri, 25 Jul 2003 05:22:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6PCMiqt044239 for ; Fri, 25 Jul 2003 05:22:44 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6PCMYS16643 for ietf-openpgp@imc.org; Fri, 25 Jul 2003 08:22:34 -0400 Date: Fri, 25 Jul 2003 08:22:34 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Text "attributes" Message-ID: <20030725122234.GA16520@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200307231740.h6NHepjh057332@mailserver1.hushmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200307231740.h6NHepjh057332@mailserver1.hushmail.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Crescent (14% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 23, 2003 at 10:40:51AM -0700, vedaal@hush.com wrote: > On Wed, 23 Jul 2003 07:05:29 -0700 David Shaw > wrote: > > >An interesting problem came up on one of the GnuPG mailing lists a > >little while ago, and I thought I'd mention it here. > > > >A vision-impaired user was using GnuPG via a text reader and > >mentioned that photo IDs were obviously not going to be that useful > >to him. The idea came up of using an additional attribute > >subpacket to include a textual user ID together with the photo > >attribute subpacket (both inside a single attribute ID), rather > >like the HTML "alt" tag is used to provide a text string for when > >an image can not be displayed. > > > >It would be easy enough to do: just define attribute subpacket 2 as > >a UTF8 string type. Implementations could handle it however they > >chose. > > > >Note that I'm not necessarily suggesting this for 2440bis. Just > >something to think about in the future. > > along those lines, it might be helpful to such users to have an > 'audio id' (the key signer's greeting in his/her own voice, > [possibly together with a few other spoken sounds, enough to enable > a text-to-speech synthesis in that voice, so that the receiver can > hear each pgp message read in the voice of that sender]), I don't think that including speech sounds to enable text-to-speech is appropriate in a OpenPGP key, but I'm not against a generic sound attribute. I imagine it could be used (among other things) as a "Hi there, this is David, and my fingerprint is ABCD..." It is of course more complex than text since we'd need to pick at least one sound format to use (WAV? AU? MP3? something else?) It is also large. (Again, just speculating idly about the future - not talking about 2440bis here). David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.3-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj8hIQoqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJmm0An0EivrfQrPUg2kRw9z6U84oT8R8BAJ0W dgWya6Ihjyx0owGIpc9FqAMBqA== =aYvm -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OFJ8qt055343 for ; Thu, 24 Jul 2003 08:19:08 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6OFJ8TS055342 for ietf-openpgp-bks; Thu, 24 Jul 2003 08:19:08 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6OFJ6qt055337 for ; Thu, 24 Jul 2003 08:19:06 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6OFJ50L002459; Thu, 24 Jul 2003 11:19:05 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6OFJ43n005710; Thu, 24 Jul 2003 11:19:05 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h6OFJ3U8016125; Thu, 24 Jul 2003 11:19:03 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h6OFJ3iC018950; Thu, 24 Jul 2003 11:19:03 -0400 (EDT) To: Jon Callas Cc: David Shaw , OpenPGP Subject: Re: PoP & Signer's User ID subpacket? References: From: Derek Atkins Date: 24 Jul 2003 11:19:03 -0400 In-Reply-To: Message-ID: Lines: 29 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > On 6/17/03 8:02 AM, "Derek Atkins" wrote: > > > > > Sure, this is fine... Theoretically the real key owner should have > > access to both private keys at the same time, so this shouldn't be an > > issue. Using a subpacket is fine. I still belive this is a MUST ;) > > I'm happy with any suitable solution, but I have a grumbly thing to add in. > > The general case of this is something we've called "signature stealing" and > is always possible in a system that involves administrative processes. All > you have to do is take someone else's signing key and start shopping around > for someone who is careless enough (or bribable enough) to certify it. You > can then claim that you made any signature made by the victim of that > attack. How does this attack work if the signature subkey _REQUIRES_ cross certification? If I wanted to assume your signature key, how am I supposed to get your signature subkey to sign my primary key in order to perform the (to-be-required) cross-certification? -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O6P4qt098771 for ; Wed, 23 Jul 2003 23:25:04 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6O6P4nM098770 for ietf-openpgp-bks; Wed, 23 Jul 2003 23:25:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6O6P2qt098761 for ; Wed, 23 Jul 2003 23:25:03 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.181] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Wed, 23 Jul 2003 23:25:02 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 23 Jul 2003 23:25:00 -0700 Subject: Re: PoP & Signer's User ID subpacket? From: Jon Callas To: Derek Atkins , David Shaw CC: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 6/17/03 8:02 AM, "Derek Atkins" wrote: > > Sure, this is fine... Theoretically the real key owner should have > access to both private keys at the same time, so this shouldn't be an > issue. Using a subpacket is fine. I still belive this is a MUST ;) I'm happy with any suitable solution, but I have a grumbly thing to add in. The general case of this is something we've called "signature stealing" and is always possible in a system that involves administrative processes. All you have to do is take someone else's signing key and start shopping around for someone who is careless enough (or bribable enough) to certify it. You can then claim that you made any signature made by the victim of that attack. This is not a flaw in OpenPGP, it is a flaw in the very nature of digital signatures. It is a flaw that can be narrowed, but not solved, period end of sentence. Furthermore, there is a sense in which it's bad security practice to worry about it too much. The reason is that it creates an opportunity for attack escalation; it makes the system more brittle. In simple words, the harder it is to steal a signature, then the more valuable a bogus cert is, and the more devastating such an attack is to the victim. Please note that I'm not suggesting we do nothing here. Anything we do to improve the bindings is good. I'm merely pointing out that we shouldn't get wrapped around the axle over an issue that is unsolvable. A clever signature thief can claim possession of those signatures, and refuse to make more on the grounds that they have retired that key and are now using *this* one. This is merely another place where sticky human issues can't be obviated by mathematics. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NL20qt069883 for ; Wed, 23 Jul 2003 14:02:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NL1xnY069882 for ietf-openpgp-bks; Wed, 23 Jul 2003 14:01:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NL1uqt069877 for ; Wed, 23 Jul 2003 14:01:56 -0700 (PDT) (envelope-from jon@callas.org) Received: from [192.168.1.29] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Wed, 23 Jul 2003 14:01:52 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 23 Jul 2003 14:01:56 -0700 Subject: Re: Adding in BZ2 compression? From: Jon Callas To: Derek Atkins CC: David Shaw , Len Sassaman , OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 7/22/03 10:54 AM, "Derek Atkins" wrote: > Ok. I have no real objections to adding the algo -- I'm just worried > about the interop issues. > There are no interop issues because it's a MAY feature that presently no one implements. :-) Implementations are already supposed to handle both ZIP and zlib prefs, so it shouldn't be an issue. (Incidentally, here at PGP, we presently implement only ZIP, but decided to add in both zlib and bz2 for a future major relase.) > Also, we still need to show multiple implementations to progress to > DRAFT standard, so if we're adding new features it might take longer > to do so. Have we had any OpenPGP Bakeoffs? I think so, but I wasn't on top of this for a while. I'm willing to help push this now. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NHewqt056232 for ; Wed, 23 Jul 2003 10:40:58 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NHew2K056231 for ietf-openpgp-bks; Wed, 23 Jul 2003 10:40:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NHeuqt056225 for ; Wed, 23 Jul 2003 10:40:57 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from mailserver1.hushmail.com (mailserver1.hushmail.com [65.39.178.20]) by smtp3.hushmail.com (Postfix) with ESMTP id 4EF7F6EB9 for ; Wed, 23 Jul 2003 10:40:51 -0700 (PDT) Received: from mailserver1.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver1.hushmail.com (8.12.6/8.12.3) with ESMTP id h6NHepC4057333 for ; Wed, 23 Jul 2003 10:40:51 -0700 (PDT) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver1.hushmail.com (8.12.6/8.12.3/Submit) id h6NHepjh057332 for ietf-openpgp@imc.org; Wed, 23 Jul 2003 10:40:51 -0700 (PDT) Message-Id: <200307231740.h6NHepjh057332@mailserver1.hushmail.com> Date: Wed, 23 Jul 2003 10:40:51 -0700 To: ietf-openpgp@imc.org Cc: Subject: Re: Text "attributes" From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 23 Jul 2003 07:05:29 -0700 David Shaw wrote: >An interesting problem came up on one of the GnuPG mailing lists >a >little while ago, and I thought I'd mention it here. > >A vision-impaired user was using GnuPG via a text reader and mentioned >that photo IDs were obviously not going to be that useful to him. > The >idea came up of using an additional attribute subpacket to include >a >textual user ID together with the photo attribute subpacket (both >inside a single attribute ID), rather like the HTML "alt" tag is >used >to provide a text string for when an image can not be displayed. > >It would be easy enough to do: just define attribute subpacket 2 >as a >UTF8 string type. Implementations could handle it however they >chose. > >Note that I'm not necessarily suggesting this for 2440bis. Just >something to think about in the future. along those lines, it might be helpful to such users to have an 'audio id' (the key signer's greeting in his/her own voice, [possibly together with a few other spoken sounds, enough to enable a text-to-speech synthesis in that voice, so that the receiver can hear each pgp message read in the voice of that sender]), the text reader can do the implementation from the saved audio id attribute (which can display the 'text' only attribute for deaf users who have no use for the audio component) for anyone interested in implementation specifically with the needs of the disabled in mind, here is a good site of helpful links: http://www.wata.org/resource/highlighted_links.htm with Respect, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NE5aqt047030 for ; Wed, 23 Jul 2003 07:05:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6NE5apP047029 for ietf-openpgp-bks; Wed, 23 Jul 2003 07:05:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6NE5Yqt046981 for ; Wed, 23 Jul 2003 07:05:35 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6NE5T713126 for ietf-openpgp@imc.org; Wed, 23 Jul 2003 10:05:29 -0400 Date: Wed, 23 Jul 2003 10:05:29 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Text "attributes" Message-ID: <20030723140529.GA12889@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Crescent (29% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An interesting problem came up on one of the GnuPG mailing lists a little while ago, and I thought I'd mention it here. A vision-impaired user was using GnuPG via a text reader and mentioned that photo IDs were obviously not going to be that useful to him. The idea came up of using an additional attribute subpacket to include a textual user ID together with the photo attribute subpacket (both inside a single attribute ID), rather like the HTML "alt" tag is used to provide a text string for when an image can not be displayed. It would be easy enough to do: just define attribute subpacket 2 as a UTF8 string type. Implementations could handle it however they chose. Note that I'm not necessarily suggesting this for 2440bis. Just something to think about in the future. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/HpYp4mZch0nhy8kRAqdhAKCYj2srvCxclI/UctclFH7ox9aavwCgpN+H 26OPYOnHgJI8Vpl87LKtKag= =d/++ -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHs9qt061424 for ; Tue, 22 Jul 2003 10:54:09 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MHs9Qb061423 for ietf-openpgp-bks; Tue, 22 Jul 2003 10:54:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHs4qt061413 for ; Tue, 22 Jul 2003 10:54:04 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6MHs37B025840; Tue, 22 Jul 2003 13:54:03 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6MHs2CQ025622; Tue, 22 Jul 2003 13:54:02 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h6MHs2FJ016244; Tue, 22 Jul 2003 13:54:02 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h6MHs19g014296; Tue, 22 Jul 2003 13:54:01 -0400 (EDT) To: Jon Callas Cc: David Shaw , Len Sassaman , OpenPGP From: Derek Atkins Subject: Re: Adding in BZ2 compression? References: Date: 22 Jul 2003 13:54:01 -0400 In-Reply-To: Message-ID: Lines: 26 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > On 7/20/03 8:48 AM, "David Shaw" wrote: > > >> I was basically against it until it was explained to me why people > >> wanted it, and I ended up thinking, "Hmmm, we don't have a > >> compression system in there that's newer than 1977, and customers > >> are often right." > > > > I rather like the idea of OpenPGP as an archival primitive. > > > > That's what sold me, too. Ok. I have no real objections to adding the algo -- I'm just worried about the interop issues. Also, we still need to show multiple implementations to progress to DRAFT standard, so if we're adding new features it might take longer to do so. Have we had any OpenPGP Bakeoffs? -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHlUqt060618 for ; Tue, 22 Jul 2003 10:47:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6MHlUni060617 for ietf-openpgp-bks; Tue, 22 Jul 2003 10:47:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6MHlRqt060604 for ; Tue, 22 Jul 2003 10:47:28 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h6MHlP7B023619; Tue, 22 Jul 2003 13:47:25 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.12.4/8.9.2) with ESMTP id h6MHlNCQ025166; Tue, 22 Jul 2003 13:47:24 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h6MHlNFJ015752; Tue, 22 Jul 2003 13:47:23 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h6MHlNuV014275; Tue, 22 Jul 2003 13:47:23 -0400 (EDT) To: Werner Koch Cc: Jon Callas , OpenPGP Subject: Re: key flag for authentication References: <003901c33356$4e3e0fc0$c23fa8c0@transarc.ibm.com> <20030718011341.GF32097@jabberwocky.com> <87znjc8bb9.fsf@alberti.g10code.de> From: Derek Atkins Date: 22 Jul 2003 13:47:22 -0400 In-Reply-To: <87znjc8bb9.fsf@alberti.g10code.de> Message-ID: Lines: 18 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch writes: > On Thu, 17 Jul 2003 21:13:41 -0400, David Shaw said: > > >> Is there a consensus for this? I'm happy with anything, myself. > > > I support it. > > Me too of course. Ok, looks like we've got concensus on this... -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LGcKqt051687 for ; Mon, 21 Jul 2003 09:38:20 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6LGcKsC051686 for ietf-openpgp-bks; Mon, 21 Jul 2003 09:38:20 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6LGcJqt051680 for ; Mon, 21 Jul 2003 09:38:19 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6LGc6T09830; Mon, 21 Jul 2003 12:38:06 -0400 Date: Mon, 21 Jul 2003 12:38:06 -0400 From: David Shaw To: Jon Callas Cc: Len Sassaman , OpenPGP Subject: Re: Adding in BZ2 compression? Message-ID: <20030721163806.GG29969@jabberwocky.com> Mail-Followup-To: Jon Callas , Len Sassaman , OpenPGP References: <20030720154807.GD29073@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (52% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jul 20, 2003 at 02:35:14PM -0700, Jon Callas wrote: > > How about adding: > > > > Note that without the ability to rewrite a self-signature, > > interoperability issues may occur when the same key is used in more > > than one implementation. Implementations may wish to check keys > > upon import to ensure that the preferences on the key match the > > reality of the implementation. > > > > That doesn't mandate anything, but does call attention to the problem. > > I guess the last line could be a SHOULD if there was a desire to make > > it stronger. > > I put in: > > It is good practice to verify that a self-signature imported into an > implementation doesn't advertise features that the implementation doesn't > support, rewriting the signature as appropriate. Excellent. That works for me. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/HBbu4mZch0nhy8kRAoIUAKCkx6H6DqxCw3OoWRWAUqjGOfe+owCgowJW 5E9hwKXFBzbRf4M1hP95T/o= =udOS -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLZ9qt070150 for ; Sun, 20 Jul 2003 14:35:10 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLZ915070149 for ietf-openpgp-bks; Sun, 20 Jul 2003 14:35:09 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLZ8qt070143 for ; Sun, 20 Jul 2003 14:35:09 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Sun, 20 Jul 2003 14:35:06 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 20 Jul 2003 14:35:14 -0700 Subject: Re: Adding in BZ2 compression? From: Jon Callas To: David Shaw CC: Len Sassaman , OpenPGP Message-ID: In-Reply-To: <20030720154807.GD29073@jabberwocky.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 7/20/03 8:48 AM, "David Shaw" wrote: >> I was basically against it until it was explained to me why people >> wanted it, and I ended up thinking, "Hmmm, we don't have a >> compression system in there that's newer than 1977, and customers >> are often right." > > I rather like the idea of OpenPGP as an archival primitive. > That's what sold me, too. > How about adding: > > Note that without the ability to rewrite a self-signature, > interoperability issues may occur when the same key is used in more > than one implementation. Implementations may wish to check keys > upon import to ensure that the preferences on the key match the > reality of the implementation. > > That doesn't mandate anything, but does call attention to the problem. > I guess the last line could be a SHOULD if there was a desire to make > it stronger. I put in: It is good practice to verify that a self-signature imported into an implementation doesn't advertise features that the implementation doesn't support, rewriting the signature as appropriate. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLMfqt069480 for ; Sun, 20 Jul 2003 14:22:41 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KLMeAw069479 for ietf-openpgp-bks; Sun, 20 Jul 2003 14:22:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KLMaqt069469 for ; Sun, 20 Jul 2003 14:22:37 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Sun, 20 Jul 2003 14:22:34 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 20 Jul 2003 14:22:42 -0700 Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) From: Jon Callas To: David Shaw CC: OpenPGP Message-ID: In-Reply-To: <20030720123417.GC29073@jabberwocky.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 7/20/03 5:34 AM, "David Shaw" wrote: > I'm not sure 2440 says that. The relevant bit is in section 11.1, > which says "In a key that has a main key and subkeys, the primary key > MUST be a key capable of signing." > > I took this, perhaps wrongly, at face value - that is, if a key had > subkeys, the primary had to be able to sign (for the binding > signatures, presumably). The flip side of this is that if a key does > not have subkeys (and there is nothing wrong with a V4 key without > subkeys), the primary did not have to be able to sign. > > Did I misinterpret the intent in 2440 there? If "a key that has a > main key and subkeys" was intended to mean "V4 key", then I strongly > suggest changing it to say "V4 key" explicitly to avoid the confusion > that spawned a good bit of this thread. Uh, I thought that meant that the top-level key can't be an encrypt-only key. So yes, I was quite sure that 2440 said what you wanted. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KFmGqt042488 for ; Sun, 20 Jul 2003 08:48:16 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KFmGNR042487 for ietf-openpgp-bks; Sun, 20 Jul 2003 08:48:16 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KFmFqt042480 for ; Sun, 20 Jul 2003 08:48:15 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6KFm8X15522; Sun, 20 Jul 2003 11:48:08 -0400 Date: Sun, 20 Jul 2003 11:48:07 -0400 From: David Shaw To: Jon Callas Cc: Len Sassaman , OpenPGP Subject: Re: Adding in BZ2 compression? Message-ID: <20030720154807.GD29073@jabberwocky.com> Mail-Followup-To: Jon Callas , Len Sassaman , OpenPGP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (64% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jul 20, 2003 at 02:41:39AM -0700, Jon Callas wrote: > I was basically against it until it was explained to me why people > wanted it, and I ended up thinking, "Hmmm, we don't have a > compression system in there that's newer than 1977, and customers > are often right." I rather like the idea of OpenPGP as an archival primitive. > >> Yes, I know that there are potential interoperability issues when keys get > >> migrated around, but I also of the opinion that when an implementation > >> imports a key, it should make sure that the preferences reflect what it > >> supports. > > > > Amen. Can that be explicitly stated in the next draft? > > > > I'm under the impression that it already says "SHOULD" in there. I > don't think it should be any stronger. It's a feature of OpenPGP > that it's small. I don't want to force someone who wants to embed > OpenPGP in something like a pager network (yeah, yeah, these days > pagers play videos) to have to do everything in PGP or GPG. > > OpenPGP is not supposed to mandate all the features a good desktop > program should have. The current draft says: Since a self-signature contains important information about the key's use, an implementation SHOULD allow the user to rewrite the self-signature, and important information in it, such as preferences and key expiration. How about adding: Note that without the ability to rewrite a self-signature, interoperability issues may occur when the same key is used in more than one implementation. Implementations may wish to check keys upon import to ensure that the preferences on the key match the reality of the implementation. That doesn't mandate anything, but does call attention to the problem. I guess the last line could be a SHOULD if there was a desire to make it stronger. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/Grm34mZch0nhy8kRArTVAJ0QEy6D4gNSk36D7yYsEMZ7SO49RQCfTKvL KVT6B0DW1k3jjmjLlQcU0io= =/PoE -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KCYQqt029385 for ; Sun, 20 Jul 2003 05:34:26 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KCYPtU029384 for ietf-openpgp-bks; Sun, 20 Jul 2003 05:34:25 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KCYOqt029375 for ; Sun, 20 Jul 2003 05:34:25 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6KCYHh13722; Sun, 20 Jul 2003 08:34:17 -0400 Date: Sun, 20 Jul 2003 08:34:17 -0400 From: David Shaw To: Jon Callas Cc: OpenPGP Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030720123417.GC29073@jabberwocky.com> Mail-Followup-To: Jon Callas , OpenPGP References: <20030715010938.GA1241@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (64% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jul 20, 2003 at 03:05:14AM -0700, Jon Callas wrote: > > >>> Can you explain what troubles you about encrypt-only primaries? > >> > >> Aside from being an unclean exception to a simple model :-? > > > > I don't see exceptions here. The model is quite clearly and simply > > stated in 2440. Any key can be of any type. There are no exceptions. > > Does this mean that there are possible arrangements of packets that > > make no sense? Sure, so don't do that. > > > > I see your suggestion as adding an exception: any key can be of any > > type, except that the primary must be able to certify. > > 2440 already says that a top-level key must be able to sign. I'm not sure 2440 says that. The relevant bit is in section 11.1, which says "In a key that has a main key and subkeys, the primary key MUST be a key capable of signing." I took this, perhaps wrongly, at face value - that is, if a key had subkeys, the primary had to be able to sign (for the binding signatures, presumably). The flip side of this is that if a key does not have subkeys (and there is nothing wrong with a V4 key without subkeys), the primary did not have to be able to sign. Did I misinterpret the intent in 2440 there? If "a key that has a main key and subkeys" was intended to mean "V4 key", then I strongly suggest changing it to say "V4 key" explicitly to avoid the confusion that spawned a good bit of this thread. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/GoxJ4mZch0nhy8kRAiK6AKC88In7Cidl9koc6/RpUNMtr6tCYgCfdlaO LbD2O+VjN0IyT2Rb1zEC7z4= =zqVR -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KA5Bqt020301 for ; Sun, 20 Jul 2003 03:05:11 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6KA5BDU020300 for ietf-openpgp-bks; Sun, 20 Jul 2003 03:05:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6KA5Aqt020293 for ; Sun, 20 Jul 2003 03:05:10 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1) for ; Sun, 20 Jul 2003 03:05:08 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 20 Jul 2003 03:05:14 -0700 Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) From: Jon Callas To: OpenPGP Message-ID: In-Reply-To: <20030715010938.GA1241@jabberwocky.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >>> Can you explain what troubles you about encrypt-only primaries? >> >> Aside from being an unclean exception to a simple model :-? > > I don't see exceptions here. The model is quite clearly and simply > stated in 2440. Any key can be of any type. There are no exceptions. > Does this mean that there are possible arrangements of packets that > make no sense? Sure, so don't do that. > > I see your suggestion as adding an exception: any key can be of any > type, except that the primary must be able to certify. 2440 already says that a top-level key must be able to sign. Getting, however to the issue in the subject line, I don't think 2440 should require self-signed user ids. Consider the following statements: "Call me Ishmael." "Call him Ishmael." The first corresponds to a self-signed UID. The latter to an introducer signature. I think that PGP UIDs can be SDSI names. More than that, they should be. I would like to be able to add a user id to someone's key because I want to, and I sign it myself, and let it go at that. Here's my real-world example. A person I work with, call this person "John Doe," has a PGP key with the UID "jdoe@pgp.com" on it. However, this person *always* sends mail from "john.doe@pgp.com" and I am constantly having to cancel keyserver searches and then go manually select the right key. It drive me up the blinking wall. I have asked said person to add in the proper user name on a number of occasions, and am still waiting. It would make me eternally happy if I can add the user name I want to that key. It isn't self-signed, it's signed my *me*. Why should *my* software accept UIDs as valid that are signed by me? Now then, we get into a small bit of interesting protocol if I export that key. But I don't see why that protocol has to be in 2440. Here are some issues: * What happens when I export that key? Should my software not export UIDs that aren't self-signed? I don't care. Well, perhaps more to the point, I consider that a bit of software design, not standards work. * What happens if I import a key that has a UID that isn't self-signed? Should it strip it? Should it strip it if it is signed by someone who is a trusted introducer? Again, I consider that software design. * What happens if a key is placed on a server? Should all non-self-signed UIDs be stripped? I think that's a matter for the server owner, but "Yes" is a fine answer. If an implementation didn't export these "SDSI UIDs" I could live with it. It might be nice to be able to import a SDSI UID that was signed by entities I trust. But I could live without that. But -- I consider all this to be software design issues, not standards issues. The standard should allow gentlepersons to disagree on some facets of design and use -- especially when the standard punts the whole issue of trust. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K9faqt018119 for ; Sun, 20 Jul 2003 02:41:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6K9fadi018118 for ietf-openpgp-bks; Sun, 20 Jul 2003 02:41:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6K9fZqt018113 for ; Sun, 20 Jul 2003 02:41:36 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.180] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2.1); Sun, 20 Jul 2003 02:41:34 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Sun, 20 Jul 2003 02:41:39 -0700 Subject: Re: Adding in BZ2 compression? From: Jon Callas To: Len Sassaman CC: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 7/17/03 3:13 PM, "Len Sassaman" wrote: > Putting multiple options for anything into a protocol does practical > implications in the context of an anonymity system, however. (I'm not > saying this should prevent adding a new compression algorithm if it serves > a purpose -- it's just something to keep in mind.) > I was basically against it until it was explained to me why people wanted it, and I ended up thinking, "Hmmm, we don't have a compression system in there that's newer than 1977, and customers are often right." >> Yes, I know that there are potential interoperability issues when keys get >> migrated around, but I also of the opinion that when an implementation >> imports a key, it should make sure that the preferences reflect what it >> supports. > > Amen. Can that be explicitly stated in the next draft? > I'm under the impression that it already says "SHOULD" in there. I don't think it should be any stronger. It's a feature of OpenPGP that it's small. I don't want to force someone who wants to embed OpenPGP in something like a pager network (yeah, yeah, these days pagers play videos) to have to do everything in PGP or GPG. OpenPGP is not supposed to mandate all the features a good desktop program should have. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J3N6qt039119 for ; Fri, 18 Jul 2003 20:23:06 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6J3N6tR039118 for ietf-openpgp-bks; Fri, 18 Jul 2003 20:23:06 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6J3N4qt039097 for ; Fri, 18 Jul 2003 20:23:05 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6J3N2k19400 for ietf-openpgp@imc.org; Fri, 18 Jul 2003 23:23:02 -0400 Date: Fri, 18 Jul 2003 23:23:02 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030719032302.GF12613@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030718005724.GD32097@jabberwocky.com> <20030718171037.GA12613@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (75% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, Jul 19, 2003 at 12:06:01AM +0200, Imad R. Faiad wrote: > I personally, will always prefer to > encrypt to a signing key, if at all > the public key algorithm supports > encryption. If there are any subkeys, > I will chose the oldest, or a signing > subkey, just to have some "PHUN", regardless > of whether it is revoked or not. > And there is nothing that you can do > about it! And I would recommend that > every OpenPGP user does the same. Not me. I just pick a random person from the keyserver and encrypt to them. Now that's really phun. David Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IM6Hqt028850 for ; Fri, 18 Jul 2003 15:06:17 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IM6HW5028849 for ietf-openpgp-bks; Fri, 18 Jul 2003 15:06:17 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from lake.cyberia.net.lb (lake.cyberia.net.lb [195.112.195.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IM6Eqt028840 for ; Fri, 18 Jul 2003 15:06:15 -0700 (PDT) (envelope-from matic@cyberia.net.lb) Received: from ppp-11-96.cyberia.net.lb ([195.112.214.97]) by lake.cyberia.net.lb with SMTP id <20030718215544.BFMI18697.lake@ppp-11-96.cyberia.net.lb> for ; Sat, 19 Jul 2003 00:55:44 +0300 From: "Imad R. Faiad" To: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Date: Sat, 19 Jul 2003 00:06:01 +0200 Message-ID: References: <20030718005724.GD32097@jabberwocky.com> <20030718171037.GA12613@jabberwocky.com> In-Reply-To: <20030718171037.GA12613@jabberwocky.com> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h6IM6Gqt028845 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello David, If it's an RSA key, then I guess that it is both, unless the implementation honors the use flags, and the OpenPGP's implied use of the public key algorithm. All of the public key algorithms support signing, therefore, until a time when there is a public key algorithm which does not, one can say that all OpenPGP keys can be signing keys. One can generalize that and say, that all OpenPGP key are encrypt enabled also, with the exception of DSA keys. While you control with what key/subkey you sign with, you cannot control what key will be used when encrypted messages are sent to you. I personally, will always prefer to encrypt to a signing key, if at all the public key algorithm supports encryption. If there are any subkeys, I will chose the oldest, or a signing subkey, just to have some "PHUN", regardless of whether it is revoked or not. And there is nothing that you can do about it! And I would recommend that every OpenPGP user does the same. Binding is not sufficient, all it implies is that the one who had the secret part of the primary key at the time chose to sign that subkey. A key or subkey should be self signed, this is an indication that whoever purports to have issued it had the secret part at the time. A UID has to be signed by the primary key. In short:- 1) A primary key with no self signature is meaningless. 2) A UID with no signature from the primary key is meaningless. 3) A subkey with no self signature and no binding signature from the primary key is meaningless also. Hope the above helps, Best regards Imad R. Faiad On Fri, 18 Jul 2003 13:10:37 -0400, you wrote: > >[F651E0D5]*** PGP SIGNATURE VERIFICATION *** >[F651E0D5]*** Hash: SHA1 >[F651E0D5]*** Status: Good Signature from Invalid Key >[F651E0D5]*** Alert: Please verify signer's key before trusting signature. >[F651E0D5]*** Signer: David M. Shaw >[F651E0D5]*** Note: Signing Key is a Sub-Key! >[F651E0D5]*** Key ID: 0x49E1CBC9 >[F651E0D5]*** Fingerprint: FC2A 0E9B 5122 7D7B 5923 2CE6 E266 5C87 49E1 >CBC9 [F651E0D5]*** Signed: 7/18/2003 7:10:37 PM >[F651E0D5]*** Verified: 7/18/2003 9:53:22 PM >[F651E0D5]*** BEGIN PGP VERIFIED MESSAGE *** > >On Fri, Jul 18, 2003 at 09:13:41AM -0700, Len Sassaman wrote: >> On Thu, 17 Jul 2003, David Shaw wrote: >> >> > > Simplicity is a good reason, as is the robustness of the OpenPGP >> > > system. >> > >> > I'm afraid I don't understand your response. Simplicity is a good >> > reason to add complexity? (??) >> >> I think that saying "all v4 primary keys are signature keys" actually >> simplifies things. You may disagree. > >Ah, ok. I didn't parse your response properly. > >I'm of mixed feelings on the primary is a signing key issue. There is >definite appeal to having all non-signature items in a key be bound >there by signatures. As things stand now, subkeys are bound, but user >IDs/attributes might not be. There is a nice annoyance attack in the >wait there. > >I do wonder what this case would mean in regards to the discussion >though: > >1) Generate a RSA sign+encrypt key. Naturally the user ID on that key > should have a self-signature. > >2) Now change the key flags so that the primary is encrypt-only. > >Is that an "encrypt-only" key? > >David > >[F651E0D5]*** END PGP VERIFIED MESSAGE *** -----BEGIN PGP SIGNATURE----- Version: 8.0.2irf Comment: KeyID: 0x833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBPxhu+LzDFxiDPxutAQIIagf/UqAZ1t+7gEcAO5jiYn/61KK7oXv4qmsr 5nFikx4aPco1TTcLsmjMEUPC55fxlothpVTvB2ofvng5a/r9CLag930Pcz2hIuOZ brMJPUHNuE19N4JdPoX/WU2aXFo1JONSM+30b7JS2tT88y09K3otNRF8I5JNQzIr fr2QucRLNqgs0Sgma4s04Ylq8JyaCySqoluZyS7bY6IyEhzpXPTXV/YXLK8QZdbh sJjfNtpr5Jgi0RcVK8HP8Mbe9QTflr11ClUC9h/xipFLYDzZpLqfoksfUqC4gB91 +7ntAm7w9WZNvWo/ocL/8T1DKV7KjBhTTKgexq1OfXdMWEt2vhQhDA== =n4Us -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IIMCqt012972 for ; Fri, 18 Jul 2003 11:22:12 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IIMCHW012971 for ietf-openpgp-bks; Fri, 18 Jul 2003 11:22:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.33]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IIMBqt012966 for ; Fri, 18 Jul 2003 11:22:11 -0700 (PDT) (envelope-from vedaal@hush.com) Received: from mailserver2.hushmail.com (mailserver2.hushmail.com [65.39.178.21]) by smtp3.hushmail.com (Postfix) with ESMTP id 8A6F56237 for ; Fri, 18 Jul 2003 11:22:05 -0700 (PDT) Received: from mailserver2.hushmail.com (localhost.hushmail.com [127.0.0.1]) by mailserver2.hushmail.com (8.12.6/8.12.3) with ESMTP id h6IIM5Ks028728 for ; Fri, 18 Jul 2003 11:22:05 -0700 (PDT) (envelope-from vedaal@hush.com) Received: (from nobody@localhost) by mailserver2.hushmail.com (8.12.6/8.12.3/Submit) id h6IIM5rn028727 for ietf-openpgp@imc.org; Fri, 18 Jul 2003 11:22:05 -0700 (PDT) Message-Id: <200307181822.h6IIM5rn028727@mailserver2.hushmail.com> Date: Fri, 18 Jul 2003 11:22:05 -0700 To: ietf-openpgp@imc.org Cc: Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) From: Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 18 Jul 2003 10:10:37 -0700 David Shaw wrote: [...] >I do wonder what this case would mean in regards to the discussion >though: > >1) Generate a RSA sign+encrypt key. Naturally the user ID on that >key > should have a self-signature. > >2) Now change the key flags so that the primary is encrypt-only. > >Is that an "encrypt-only" key? [...] in the olden days of pgp 2.x, some people would make two keypairs, and would use one only for signing and one only for encrypting, so, if someone now were to generate a v4 rsa key and flag it as encrypt only, it might be (?mis)taken in exactly the v3 context, that the user intended it as an encrypt-only key, and, for whatever reason, might prefer to do it this way and not deal with subkeys the only problem would be if it could be flagged this way *un-intentionally*, which doesn't seem to be the case with Respect, vedaal Concerned about your privacy? Follow this link to get FREE encrypted email: https://www.hushmail.com/?l=2 Free, ultra-private instant messaging with Hush Messenger https://www.hushmail.com/services.php?subloc=messenger&l=434 Promote security and make money with the Hushmail Affiliate Program: https://www.hushmail.com/about.php?subloc=affiliate&l=427 Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IHAhqt008394 for ; Fri, 18 Jul 2003 10:10:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IHAgcp008393 for ietf-openpgp-bks; Fri, 18 Jul 2003 10:10:42 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IHAfqt008368 for ; Fri, 18 Jul 2003 10:10:42 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6IHAbD13439; Fri, 18 Jul 2003 13:10:37 -0400 Date: Fri, 18 Jul 2003 13:10:37 -0400 From: David Shaw To: Len Sassaman Cc: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030718171037.GA12613@jabberwocky.com> Mail-Followup-To: Len Sassaman , ietf-openpgp@imc.org References: <20030718005724.GD32097@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (75% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Fri, Jul 18, 2003 at 09:13:41AM -0700, Len Sassaman wrote: > On Thu, 17 Jul 2003, David Shaw wrote: > > > > Simplicity is a good reason, as is the robustness of the OpenPGP system. > > > > I'm afraid I don't understand your response. Simplicity is a good > > reason to add complexity? (??) > > I think that saying "all v4 primary keys are signature keys" actually > simplifies things. You may disagree. Ah, ok. I didn't parse your response properly. I'm of mixed feelings on the primary is a signing key issue. There is definite appeal to having all non-signature items in a key be bound there by signatures. As things stand now, subkeys are bound, but user IDs/attributes might not be. There is a nice annoyance attack in the wait there. I do wonder what this case would mean in regards to the discussion though: 1) Generate a RSA sign+encrypt key. Naturally the user ID on that key should have a self-signature. 2) Now change the key flags so that the primary is encrypt-only. Is that an "encrypt-only" key? David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/GCoN4mZch0nhy8kRAhyYAKC8qaI6HL4aPy1/xJJi04nM8ISc1QCdHs3X NWg2+tNJl1n48jzhofMOTE0= =mm0s -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGDiqt006708 for ; Fri, 18 Jul 2003 09:13:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6IGDio1006707 for ietf-openpgp-bks; Fri, 18 Jul 2003 09:13:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6IGDgqt006701 for ; Fri, 18 Jul 2003 09:13:42 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 0BDB6450A9; Fri, 18 Jul 2003 09:13:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id EAD9B48034; Fri, 18 Jul 2003 09:13:41 -0700 (PDT) Date: Fri, 18 Jul 2003 09:13:41 -0700 (PDT) From: Len Sassaman X-Sender: To: David Shaw Cc: Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) In-Reply-To: <20030718005724.GD32097@jabberwocky.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 17 Jul 2003, David Shaw wrote: > > Simplicity is a good reason, as is the robustness of the OpenPGP system. > > I'm afraid I don't understand your response. Simplicity is a good > reason to add complexity? (??) I think that saying "all v4 primary keys are signature keys" actually simplifies things. You may disagree. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I8r5qt072859 for ; Fri, 18 Jul 2003 01:53:05 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I8r4Od072858 for ietf-openpgp-bks; Fri, 18 Jul 2003 01:53:04 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I8r2qt072836 for ; Fri, 18 Jul 2003 01:53:03 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 19dQsc-0002Fq-00 for ; Fri, 18 Jul 2003 10:46:18 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 19dR0N-0002pT-00; Fri, 18 Jul 2003 10:54:19 +0200 To: Jon Callas Cc: OpenPGP Subject: Re: key flag for authentication References: <003901c33356$4e3e0fc0$c23fa8c0@transarc.ibm.com> <20030718011341.GF32097@jabberwocky.com> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Fri, 18 Jul 2003 10:54:18 +0200 In-Reply-To: <20030718011341.GF32097@jabberwocky.com> (David Shaw's message of "Thu, 17 Jul 2003 21:13:41 -0400") Message-ID: <87znjc8bb9.fsf@alberti.g10code.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 17 Jul 2003 21:13:41 -0400, David Shaw said: >> Is there a consensus for this? I'm happy with anything, myself. > I support it. Me too of course. -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I1Ejqt039354 for ; Thu, 17 Jul 2003 18:14:45 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I1EjhN039353 for ietf-openpgp-bks; Thu, 17 Jul 2003 18:14:45 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I1Eiqt039348 for ; Thu, 17 Jul 2003 18:14:44 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6I1DfV03945; Thu, 17 Jul 2003 21:13:41 -0400 Date: Thu, 17 Jul 2003 21:13:41 -0400 From: David Shaw To: Jon Callas Cc: OpenPGP Subject: Re: key flag for authentication Message-ID: <20030718011341.GF32097@jabberwocky.com> Mail-Followup-To: Jon Callas , OpenPGP References: <003901c33356$4e3e0fc0$c23fa8c0@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (83% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, Jul 01, 2003 at 12:57:29AM -0700, Jon Callas wrote: > > Is there a consensus for this? I'm happy with anything, myself. I support it. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/F0nF4mZch0nhy8kRAluDAJ4uojC6mKKpU5Q/Do/0xy1WNa9PqACg3aiI kk3p+8QfxeVEV3pejdO8G9E= =vxOX -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0xoqt037273 for ; Thu, 17 Jul 2003 17:59:50 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I0xo7i037272 for ietf-openpgp-bks; Thu, 17 Jul 2003 17:59:50 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0xnqt037266 for ; Thu, 17 Jul 2003 17:59:49 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6I0wkG03780; Thu, 17 Jul 2003 20:58:46 -0400 Date: Thu, 17 Jul 2003 20:58:46 -0400 From: David Shaw To: Len Sassaman Cc: Jon Callas , OpenPGP Subject: Re: Adding in BZ2 compression? Message-ID: <20030718005846.GE32097@jabberwocky.com> Mail-Followup-To: Len Sassaman , Jon Callas , OpenPGP References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (83% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 17, 2003 at 03:13:32PM -0700, Len Sassaman wrote: > > Yes, I know that there are potential interoperability issues when keys get > > migrated around, but I also of the opinion that when an implementation > > imports a key, it should make sure that the preferences reflect what it > > supports. > > Amen. Can that be explicitly stated in the next draft? Yes, please. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/F0ZG4mZch0nhy8kRAgXiAKCglNsielY5l+GddZZVfD5+JGF0pACfZSyq Zx7ePyEobFstdZIEw2D2dZ8= =VeVu -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0vTqt037193 for ; Thu, 17 Jul 2003 17:57:29 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I0vT6k037192 for ietf-openpgp-bks; Thu, 17 Jul 2003 17:57:29 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0vSqt037185 for ; Thu, 17 Jul 2003 17:57:28 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6I0vOu03761; Thu, 17 Jul 2003 20:57:24 -0400 Date: Thu, 17 Jul 2003 20:57:24 -0400 From: David Shaw To: Len Sassaman Cc: ietf-openpgp@imc.org Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030718005724.GD32097@jabberwocky.com> Mail-Followup-To: Len Sassaman , ietf-openpgp@imc.org References: <20030715010938.GA1241@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (83% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 17, 2003 at 03:20:26PM -0700, Len Sassaman wrote: > > On Mon, 14 Jul 2003, David Shaw wrote: > > > > I think there is value in requiring uids to be self-signed. To allow > > > encrypt-only top-level keys, one has to make a special case. Given > > > that they are only very limitedly useful, I'd rather not have the > > > special case. > > > > Keep in mind that this renders valid 2440 keys invalid under 2440bis. > > I can't imagine why we'd do such a thing just to gain the ability to > > require self-signed user IDs. To be honest, I've never seen an > > I am surprised that there have not been widespread attacks on OpenPGP keys > as a result of the permitted non-self-signed UIDs. I think this really > must be fixed. (And for users to add self-signatures to their existing > unsigned uids is trivial.) No question. I just object to tying the self-signature fix to removing encrypt-only keys. It's my own fault since I mentioned them together, but I was wrong. There is no need to tie the two together. > > Note that GnuPG doesn't have any special support for encrypt-only > > primary keys, but because of the nice general design of v4 keys, where > > any key (primary or subkey) can be of any type, encrypt-only primaries > > work just fine. I don't have a copy of PGP handy (I'm traveling), but > > I suspect that they'll "just plain work" in PGP as well. My point > > here is that it would take additional code and additional complexity > > to *prevent* encrypt-only primaries from working... so why mess around > > with this, especially since there is no security-related reason for > > it? > > Simplicity is a good reason, as is the robustness of the OpenPGP system. I'm afraid I don't understand your response. Simplicity is a good reason to add complexity? (??) David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/F0X04mZch0nhy8kRAg6AAJ9TFmsEeI3kYjF/rjnV0KvzM3aUWgCdFkEf PyYawQG859AUnnG0HmilddY= =E91L -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0oWqt036943 for ; Thu, 17 Jul 2003 17:50:32 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6I0oWjm036942 for ietf-openpgp-bks; Thu, 17 Jul 2003 17:50:32 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6I0oVqt036936 for ; Thu, 17 Jul 2003 17:50:31 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6I0oR003700; Thu, 17 Jul 2003 20:50:27 -0400 Date: Thu, 17 Jul 2003 20:50:27 -0400 From: David Shaw To: ietf-openpgp@imc.org Cc: Michael Young Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030718005027.GC32097@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org, Michael Young References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> <000601c34a2e$da604880$2ac52609@transarc.ibm.com> <20030715010938.GA1241@jabberwocky.com> <002f01c34cad$7c5b0960$2ac52609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <002f01c34cad$7c5b0960$2ac52609@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (83% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 17, 2003 at 05:50:49PM -0400, Michael Young wrote: > > "David Shaw" writes: > > So, as a solution, rather than ripping into the key construction > > rules, why not just put in a line saying "user IDs and user attributes > > SHOULD have a self-signature", and call it a day? > > I think it's suitably "nice" to merit "ripping into" a key construction > rule that I have always thought was wrong. Despite your attempts to > paint the current rule as cleaner, simpler, or more natural, I still > disagree "Despite your attempts to paint the current rule"? Yikes. We're all working towards the same goal here. Remember who suggested dealing with this in 2440bis. If I liked the no-required-self-sigs status quo, I wouldn't have brought it up. Although it might seem I'm arguing against required self-sigs, I'm actually fairly torn. One problem is that combining this change with the encrypt-only key change implies a number of subtle and not so subtle changes, and I'm not (yet) convinced that this is the right thing to do. I understand that you see the removal of encrypt-only keys as an advantage (as you seem to be arguing against encrypt-only keys almost more than you are arguing for a required self-signature), but I don't see things that way. Despite what I said earlier in this thread, requiring self-sigs does not depend on removing encrypt-only keys. Since there seems to be widespread agreement for the former, and not for the latter, perhaps it would be better to resolve the self-sigs question and then discuss encrypt-only keys as a suppurate issue. Discussing the two issues tied together seems to be leading nowhere. I propose "Self-signatures are REQUIRED for all user IDs and user attribute IDs on any key that has a primary capable of certification". This handles the self-sig issue without changing the key construction rules at all. If there is consensus on this, then a different discussion can be opened on the matter of encrypt-only keys. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/F0RT4mZch0nhy8kRApWuAKC1nGMxvf6i26tMxHJ/gHZ3qMY6hQCfUO8V CsPgFfLT2nQbuVAd4HA1ki0= =qfjQ -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMKUqt031491 for ; Thu, 17 Jul 2003 15:20:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HMKULh031490 for ietf-openpgp-bks; Thu, 17 Jul 2003 15:20:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMKSqt031485 for ; Thu, 17 Jul 2003 15:20:28 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 7D56345095; Thu, 17 Jul 2003 15:20:26 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 5F96C48034; Thu, 17 Jul 2003 15:20:26 -0700 (PDT) Date: Thu, 17 Jul 2003 15:20:26 -0700 (PDT) From: Len Sassaman X-Sender: To: David Shaw Cc: Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) In-Reply-To: <20030715010938.GA1241@jabberwocky.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 14 Jul 2003, David Shaw wrote: > > I think there is value in requiring uids to be self-signed. To allow > > encrypt-only top-level keys, one has to make a special case. Given > > that they are only very limitedly useful, I'd rather not have the > > special case. > > Keep in mind that this renders valid 2440 keys invalid under 2440bis. > I can't imagine why we'd do such a thing just to gain the ability to > require self-signed user IDs. To be honest, I've never seen an I am surprised that there have not been widespread attacks on OpenPGP keys as a result of the permitted non-self-signed UIDs. I think this really must be fixed. (And for users to add self-signatures to their existing unsigned uids is trivial.) > encrypt-only primary in nature. I know of no program that generates > them. I've never used one except to test. But who am I to dictate - > in the absence of an actual security-related reason - to someone else > what type of key they may have? That's what making an interoperable protocol is all about. (I'll also argue that interoperability is a security-related reason in and of itself.) > Note that GnuPG doesn't have any special support for encrypt-only > primary keys, but because of the nice general design of v4 keys, where > any key (primary or subkey) can be of any type, encrypt-only primaries > work just fine. I don't have a copy of PGP handy (I'm traveling), but > I suspect that they'll "just plain work" in PGP as well. My point > here is that it would take additional code and additional complexity > to *prevent* encrypt-only primaries from working... so why mess around > with this, especially since there is no security-related reason for > it? Simplicity is a good reason, as is the robustness of the OpenPGP system. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMEjqt031371 for ; Thu, 17 Jul 2003 15:14:45 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HMEi35031370 for ietf-openpgp-bks; Thu, 17 Jul 2003 15:14:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMEhqt031365 for ; Thu, 17 Jul 2003 15:14:43 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 39D6E45095; Thu, 17 Jul 2003 15:14:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 251F748034; Thu, 17 Jul 2003 15:14:41 -0700 (PDT) Date: Thu, 17 Jul 2003 15:14:41 -0700 (PDT) From: Len Sassaman X-Sender: To: Michael Young Cc: Subject: Re: PoP & Signer's User ID subpacket? In-Reply-To: <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 13 Jul 2003, Michael Young wrote: > "David Shaw" writes: > > The only thing that really troubles me about the idea is that it > > raises problems for the (legal, to my reading of 2440) encrypt-only v4 > > key. > > This doesn't trouble me... I strongly believe that we should > remove the loophole that allows encrypt-only top-level v4 keys, > for exactly this reason. (I was astounded when David pointed out > the seemingly permissive language in another forum.) Agreed. > Why is it important to be able to generate such a thing? Is it such a > burden to have to generate a signing key? > > [If you don't care about uid validity, which you mustn't if you're > using an encrypt-only top-level key now, then you could even attach a > bogus top-level key, which would take virtually no time to generate.] Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMDbqt031349 for ; Thu, 17 Jul 2003 15:13:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HMDbcZ031348 for ietf-openpgp-bks; Thu, 17 Jul 2003 15:13:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HMDaqt031341 for ; Thu, 17 Jul 2003 15:13:36 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 212A845023; Thu, 17 Jul 2003 15:13:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id 0C66E48034; Thu, 17 Jul 2003 15:13:33 -0700 (PDT) Date: Thu, 17 Jul 2003 15:13:32 -0700 (PDT) From: Len Sassaman X-Sender: To: Jon Callas Cc: OpenPGP Subject: Re: Adding in BZ2 compression? In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 7 Jul 2003, Jon Callas wrote: > I'm not the person asking for them, so I may be inadequately explaining > this. Nonetheless, here goes. > > The argument of "no new algorithms unless one is broken" makes more sense > for things like ciphers than it does for compression. Compression in OpenPGP > doesn't have the same sort of security implications that a cipher does, and > so one doesn't need to be as conservative about it. Putting multiple options for anything into a protocol does practical implications in the context of an anonymity system, however. (I'm not saying this should prevent adding a new compression algorithm if it serves a purpose -- it's just something to keep in mind.) > Yes, I know that there are potential interoperability issues when keys get > migrated around, but I also of the opinion that when an implementation > imports a key, it should make sure that the preferences reflect what it > supports. Amen. Can that be explicitly stated in the next draft? (And does PGP do this yet?) --Len. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HLqOqt030280 for ; Thu, 17 Jul 2003 14:52:25 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6HLqOKT030279 for ietf-openpgp-bks; Thu, 17 Jul 2003 14:52:24 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6HLqMqt030270 for ; Thu, 17 Jul 2003 14:52:23 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id RAA28419 for ; Thu, 17 Jul 2003 17:52:11 -0400 (EDT) Message-ID: <002f01c34cad$7c5b0960$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> <000601c34a2e$da604880$2ac52609@transarc.ibm.com> <20030715010938.GA1241@jabberwocky.com> Subject: Re: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Date: Thu, 17 Jul 2003 17:50:49 -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 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "David Shaw" writes: > Allow me to restate the original problem that spawned this thread: It > would be nice to require self-signatures on user IDs. We cannot do > that since an encrypt-only primary is unable to issue such a > self-signature. It seems that we all agree that it would be "nice" to *require* self-signatures. > So, as a solution, rather than ripping into the key construction > rules, why not just put in a line saying "user IDs and user attributes > SHOULD have a self-signature", and call it a day? I think it's suitably "nice" to merit "ripping into" a key construction rule that I have always thought was wrong. Despite your attempts to paint the current rule as cleaner, simpler, or more natural, I still disagree -- I think the current rule is more convoluted. It *is* the current rule, though, and I understand that we'd be invalidating some currently valid keys "with the swipe of a pen". As you've noted, no known software generates encrypt-only top-level keys (except perhaps for testing). Anyone with a usable signing key can generate a self-signature to make any intended uids valid. With those facts in mind, I'm quite willing to take a swipe to correct a mistake. Perhaps one of the original authors can offer some insight here. Why was it important to allow encrypt-only "primary" keys? -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPxcaN+c3iHYL8FknEQKIRwCeKmbyVMTXwb5uoiQjFZ8vud33I+gAoLCG DXPnhQ0f/u9cqccD+/TTr+64 =il1i -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FHb0qt091470 for ; Tue, 15 Jul 2003 10:37:00 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6FHb0lI091469 for ietf-openpgp-bks; Tue, 15 Jul 2003 10:37:00 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from possum.cryptohill.net (cambist.cryptohill.net [24.244.145.35]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6FHavqt091464 for ; Tue, 15 Jul 2003 10:37:00 -0700 (PDT) (envelope-from edwin@woudt.nl) Received: from ABC1234567890 (unknown [24.244.145.60]) by possum.cryptohill.net (Postfix) with ESMTP id 384CDAE300 for ; Tue, 15 Jul 2003 13:36:58 -0400 (EDT) Date: Tue, 15 Jul 2003 13:37:34 -0400 From: Edwin Woudt To: ietf-openpgp@imc.org Subject: Location of 'key expiration time' signature subpacket Message-ID: <127733008.1058276254@ABC1234567890> X-Mailer: Mulberry/2.2.1 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: While implementing key expiration, I noticed that the 'key expiration time' signature subpacket (#9) is put in self certification signatures instead of in (self signed) direct key signature. Why is that? I find it more logical to put it in a direct key signature, as it says nothing about the user id that is self signed. In fact, given multiple user id's, putting it in self certification signatures could even result in conflicting information. Edwin Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F19hqt016063 for ; Mon, 14 Jul 2003 18:09:43 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6F19hAR016062 for ietf-openpgp-bks; Mon, 14 Jul 2003 18:09:43 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6F19fqt016055 for ; Mon, 14 Jul 2003 18:09:42 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (claude.jabberwocky.com [172.24.84.27]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6F19eR03499 for ; Mon, 14 Jul 2003 21:09:41 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6F19dY02778 for ietf-openpgp@imc.org; Mon, 14 Jul 2003 21:09:39 -0400 Date: Mon, 14 Jul 2003 21:09:38 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Requiring self-signed uids? (was Re: PoP & Signer's User ID subpacket?) Message-ID: <20030715010938.GA1241@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> <000601c34a2e$da604880$2ac52609@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <000601c34a2e$da604880$2ac52609@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (98% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 14, 2003 at 01:39:04PM -0400, Michael Young wrote: > I find it strange that you'd use the term "primary" for a top-level > encrypt-only key. It can't have subkeys; there is no "secondary". I call it primary because 2440 calls it primary. It doesn't matter if there are no subkeys on it. That's just wording. I think we all know what I am talking about when I say encrypt-only primary: a version 4 public key (tag 6) that is of an encrypt-only algorithm. > > Can you explain what troubles you about encrypt-only primaries? > > Aside from being an unclean exception to a simple model :-? I don't see exceptions here. The model is quite clearly and simply stated in 2440. Any key can be of any type. There are no exceptions. Does this mean that there are possible arrangements of packets that make no sense? Sure, so don't do that. I see your suggestion as adding an exception: any key can be of any type, except that the primary must be able to certify. > I think there is value in requiring uids to be self-signed. To allow > encrypt-only top-level keys, one has to make a special case. Given > that they are only very limitedly useful, I'd rather not have the > special case. Keep in mind that this renders valid 2440 keys invalid under 2440bis. I can't imagine why we'd do such a thing just to gain the ability to require self-signed user IDs. To be honest, I've never seen an encrypt-only primary in nature. I know of no program that generates them. I've never used one except to test. But who am I to dictate - in the absence of an actual security-related reason - to someone else what type of key they may have? Note that GnuPG doesn't have any special support for encrypt-only primary keys, but because of the nice general design of v4 keys, where any key (primary or subkey) can be of any type, encrypt-only primaries work just fine. I don't have a copy of PGP handy (I'm traveling), but I suspect that they'll "just plain work" in PGP as well. My point here is that it would take additional code and additional complexity to *prevent* encrypt-only primaries from working... so why mess around with this, especially since there is no security-related reason for it? > I recognize that requiring self-signatures on uids restricts some > otherwise valid uses, and that it doesn't provide any additional > security given a strong trust model and a proper understanding of > its limitations. I still think it's worthwhile. Allow me to restate the original problem that spawned this thread: It would be nice to require self-signatures on user IDs. We cannot do that since an encrypt-only primary is unable to issue such a self-signature. So, as a solution, rather than ripping into the key construction rules, why not just put in a line saying "user IDs and user attributes SHOULD have a self-signature", and call it a day? This has a few nice details: * It doesn't render perfectly valid 2440 encrypt-only primary keys invalid with the swipe of a pen. * It doesn't render perfectly valid 2440 non-self-signed keys invalid with the swipe of a pen. * It accomplishes the intent of pointing out that implementations should really be self-signing user IDs (which they are already doing anyway). David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/E1RS4mZch0nhy8kRAvIcAKDBrriAl95R+I9w93/C62i67HTiXQCglsBK xDKiWu0MMeNqKsLbYpDrWdk= =clPi -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EHexqt089535 for ; Mon, 14 Jul 2003 10:40:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EHexiS089534 for ietf-openpgp-bks; Mon, 14 Jul 2003 10:40:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EHeqqt089523 for ; Mon, 14 Jul 2003 10:40:55 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA24173 for ; Mon, 14 Jul 2003 13:40:40 -0400 (EDT) Message-ID: <000601c34a2e$da604880$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> Subject: Re: PoP & Signer's User ID subpacket? Date: Mon, 14 Jul 2003 13:39:04 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "David Shaw" writes: > Do I strongly care about encrypt-only primaries in particular? Not > really. I do care about clean design, though, and adding a special > additional "no encrypt-only primaries" rule on top of the current > clean primary/subkey design seems without clear benefit. I think that the rules are cleaner without encrypt-only standalone keys: "Every key has a primary that can sign and any number of subkeys (of any type)." Just one rule, no special cases, nothing "on top". I find it strange that you'd use the term "primary" for a top-level encrypt-only key. It can't have subkeys; there is no "secondary". > Can you explain what troubles you about encrypt-only primaries? Aside from being an unclean exception to a simple model :-? I think there is value in requiring uids to be self-signed. To allow encrypt-only top-level keys, one has to make a special case. Given that they are only very limitedly useful, I'd rather not have the special case. I recognize that requiring self-signatures on uids restricts some otherwise valid uses, and that it doesn't provide any additional security given a strong trust model and a proper understanding of its limitations. I still think it's worthwhile. [Note that the same is true of the signing-subkey problem. I acknowledge that the problem was more serious there, and the uses of non-owned subkeys are more limited. (By the way, I like David's signature-in-a-subpacket solution.) The same is also true of the requirement that a key have at least one uid.] Hal observed that all *existing* encrypt-only algorithms really can support signing anyway. Who knows whether that will hold up over time? If we're convinced that it will, I'd rather remove the encrypt-only notion from the algorithm entirely (putting it in the key preferences instead). -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPxLeSec3iHYL8FknEQJ3AwCg5iBkjpc3bAff3WIyd2pzdUMS4kMAoN3t ATq2/ZgYie7m5H7NwDIZMsUm =igGD -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EHexqt089536 for ; Mon, 14 Jul 2003 10:40:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EHexQs089533 for ietf-openpgp-bks; Mon, 14 Jul 2003 10:40:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mailhost.transarc.ibm.com (bi-03pt1.bluebird.ibm.com [129.42.208.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EHeqqt089522 for ; Mon, 14 Jul 2003 10:40:55 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung (dhcp-197-42.transarc.ibm.com [9.38.197.42]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id NAA24170 for ; Mon, 14 Jul 2003 13:40:40 -0400 (EDT) Message-ID: <000501c34a2e$d9fb9340$2ac52609@transarc.ibm.com> From: "Michael Young" To: References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> <20030714144958.GC17025@jabberwocky.com> Subject: Re: PoP & Signer's User ID subpacket? Date: Mon, 14 Jul 2003 12:46:11 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "David Shaw" writes: > Do I strongly care about encrypt-only primaries in particular? Not > really. I do care about clean design, though, and adding a special > additional "no encrypt-only primaries" rule on top of the current > clean primary/subkey design seems without clear benefit. I think that the rules are cleaner without encrypt-only standalone keys: "Every key has a primary that can sign and any number of subkeys (of any type)." Just one rule, no special cases, nothing "on top". I find it strange that you'd use the term "primary" for a top-level encrypt-only key. It can't have subkeys; there is no "secondary". > Can you explain what troubles you about encrypt-only primaries? Aside from being an unclean exception to a simple model :-? I think there is value in requiring uids to be self-signed. To allow encrypt-only top-level keys, one has to make a special case. Given that they are only very limitedly useful, I'd rather not have the special case. I recognize that requiring self-signatures on uids restricts some otherwise valid uses, and that it doesn't provide any additional security given a strong trust model and a proper understanding of its limitations. I still think it's worthwhile. [Note that the same is true of the signing-subkey problem. I acknowledge that the problem was more serious there, and the uses of non-owned subkeys are more limited. (By the way, I like David's signature-in-a-subpacket solution.) The same is also true of the requirement that a key have at least one uid.] Hal observed that all *existing* encrypt-only algorithms really can support signing anyway. Who knows whether that will hold up over time? If we're convinced that it will, I'd rather remove the encrypt-only notion from the algorithm entirely (putting it in the key preferences instead). -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPxLeSec3iHYL8FknEQJ3AwCg5iBkjpc3bAff3WIyd2pzdUMS4kMAoN3t ATq2/ZgYie7m5H7NwDIZMsUm =igGD -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEtsqt079599 for ; Mon, 14 Jul 2003 07:55:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6EEtrNJ079598 for ietf-openpgp-bks; Mon, 14 Jul 2003 07:55:53 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6EEtqqt079592 for ; Mon, 14 Jul 2003 07:55:53 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (pcp04278829pcs.union01.nj.comcast.net [68.39.98.162]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6EEtnR01054 for ; Mon, 14 Jul 2003 10:55:49 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6EEnwY17582 for ietf-openpgp@imc.org; Mon, 14 Jul 2003 10:49:58 -0400 Date: Mon, 14 Jul 2003 10:49:58 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: PoP & Signer's User ID subpacket? Message-ID: <20030714144958.GC17025@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> <20030714060727.GA15755@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20030714060727.GA15755@jabberwocky.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waning Gibbous (99% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 14, 2003 at 02:07:27AM -0400, David Shaw wrote: > On Sun, Jul 13, 2003 at 11:37:24PM -0400, Michael Young wrote: > > > > "David Shaw" writes: > > > The only thing that really troubles me about the idea is that it > > > raises problems for the (legal, to my reading of 2440) encrypt-only v4 > > > key. > > > > This doesn't trouble me... I strongly believe that we should > > remove the loophole that allows encrypt-only top-level v4 keys, > > for exactly this reason. (I was astounded when David pointed out > > the seemingly permissive language in another forum.) > > Just so we're all clear, Michael and I had been discussing the > legality of a v4 encrypt-only primary WITHOUT any subkeys. An > encrypt-only key WITH subkeys is clearly forbidden in 2440 both > implicitly (an encrypt-only primary key could not issue the > non-optional subkey binding signatures) and explicitly ("In a key that > has a main key and subkeys, the primary key MUST be a key capable of > certification."). > > This is just a primary key that happens to be of an encrypt-only > algorithm (presumably #16, since there is no way to express an > encrypt-only primary key with algorithm #1 (you would need to use #2, > which is deprecated)). I should add, though, that I don't really understand the objection to an encrypt-only primary. OpenPGP is a collection of various tools that can be combined in different ways for different uses. Some combinations are more useful than others, and some make no sense, but I don't see why (in the absence of an actual problem) one particular combination should be considered a "loophole" and removed. Do I strongly care about encrypt-only primaries in particular? Not really. I do care about clean design, though, and adding a special additional "no encrypt-only primaries" rule on top of the current clean primary/subkey design seems without clear benefit. Can you explain what troubles you about encrypt-only primaries? David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/EsMW4mZch0nhy8kRAhl9AKCAnW30D4l+W+pC/hhLEXs9TONulQCfeOnP +0pShRqWTG3OCdbC42bje9U= =iQ9h -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E6FUqt026412 for ; Sun, 13 Jul 2003 23:15:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6E6FUQq026410 for ietf-openpgp-bks; Sun, 13 Jul 2003 23:15:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E6FSqt026384 for ; Sun, 13 Jul 2003 23:15:29 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (pcp04282046pcs.union01.nj.comcast.net [68.39.111.63]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6E6FTR32157 for ; Mon, 14 Jul 2003 02:15:29 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6E67Rp16267 for ietf-openpgp@imc.org; Mon, 14 Jul 2003 02:07:27 -0400 Date: Mon, 14 Jul 2003 02:07:27 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: PoP & Signer's User ID subpacket? Message-ID: <20030714060727.GA15755@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Full User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, Jul 13, 2003 at 11:37:24PM -0400, Michael Young wrote: > > "David Shaw" writes: > > The only thing that really troubles me about the idea is that it > > raises problems for the (legal, to my reading of 2440) encrypt-only v4 > > key. > > This doesn't trouble me... I strongly believe that we should > remove the loophole that allows encrypt-only top-level v4 keys, > for exactly this reason. (I was astounded when David pointed out > the seemingly permissive language in another forum.) Just so we're all clear, Michael and I had been discussing the legality of a v4 encrypt-only primary WITHOUT any subkeys. An encrypt-only key WITH subkeys is clearly forbidden in 2440 both implicitly (an encrypt-only primary key could not issue the non-optional subkey binding signatures) and explicitly ("In a key that has a main key and subkeys, the primary key MUST be a key capable of certification."). This is just a primary key that happens to be of an encrypt-only algorithm (presumably #16, since there is no way to express an encrypt-only primary key with algorithm #1 (you would need to use #2, which is deprecated)). David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/Ekif4mZch0nhy8kRAsNVAJ9ZgvUVZnrGFm07uMzgdTmeBansagCfeIC5 IX3KeeSgLEuFe0nfbZz6lHU= =JUAl -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E3cmqt020155 for ; Sun, 13 Jul 2003 20:38:48 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6E3cmIL020154 for ietf-openpgp-bks; Sun, 13 Jul 2003 20:38:48 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta8.adelphia.net (mta8.adelphia.net [64.8.50.196]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6E3ckqt020148 for ; Sun, 13 Jul 2003 20:38:47 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung ([68.168.179.202]) by mta8.adelphia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP id <20030714033844.YNTH20782.mta8.adelphia.net@mwyoung> for ; Sun, 13 Jul 2003 23:38:44 -0400 Message-ID: <000a01c349b9$3df43da0$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: References: <20030617033611.GF20267@jabberwocky.com> <20030713131842.GB1901@jabberwocky.com> Subject: Re: PoP & Signer's User ID subpacket? Date: Sun, 13 Jul 2003 23:37:24 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "David Shaw" writes: > The only thing that really troubles me about the idea is that it > raises problems for the (legal, to my reading of 2440) encrypt-only v4 > key. This doesn't trouble me... I strongly believe that we should remove the loophole that allows encrypt-only top-level v4 keys, for exactly this reason. (I was astounded when David pointed out the seemingly permissive language in another forum.) Why is it important to be able to generate such a thing? Is it such a burden to have to generate a signing key? [If you don't care about uid validity, which you mustn't if you're using an encrypt-only top-level key now, then you could even attach a bogus top-level key, which would take virtually no time to generate.] -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPxIlcec3iHYL8FknEQJ1BgCffGpWfOixvtgCkH4FSJsYt7eN/dIAn1A1 EPdheuZMUvnXH1K52Aj5URAe =nPI9 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEKbqt085224 for ; Sun, 13 Jul 2003 07:20:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6DEKbqN085223 for ietf-openpgp-bks; Sun, 13 Jul 2003 07:20:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEKZqt085207 for ; Sun, 13 Jul 2003 07:20:36 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (pcp04279524pcs.union01.nj.comcast.net [68.39.101.89]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6DEKWR30210; Sun, 13 Jul 2003 10:20:32 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6DDIh605883; Sun, 13 Jul 2003 09:18:43 -0400 Date: Sun, 13 Jul 2003 09:18:42 -0400 From: David Shaw To: Len Sassaman Cc: ietf-openpgp@imc.org Subject: Re: PoP & Signer's User ID subpacket? Message-ID: <20030713131842.GB1901@jabberwocky.com> Mail-Followup-To: Len Sassaman , ietf-openpgp@imc.org References: <20030617033611.GF20267@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Full User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 07, 2003 at 03:34:56PM -0700, Len Sassaman wrote: > > On Mon, 16 Jun 2003, David Shaw wrote: > > > This raises a 2440bis question: given all the recent deprecation of > > PGP 2.x stuff, is it worth requiring self-signatures on user IDs now? > > If I recall, the only reason that user ID self-signatures are not > > currently required was for 2.x compatibility. Certainly every modern > > implementation (5.0+, any GnuPG) generates user ID self-signatures > > automatically when a user ID is created. > > I think this is a marvelous idea. The only thing that really troubles me about the idea is that it raises problems for the (legal, to my reading of 2440) encrypt-only v4 key. A true encrypt-only key would have a problem issuing the self-signature. Of course, Hal's comments about encryption keys issuing signatures apply here as well. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/EVwy4mZch0nhy8kRAqi7AJ9/6CK8tnKlVi0hf83ZJD/cTFqaSACeNr1J lHTbEJAkp49+QSqZ9WpW6Xg= =KoEp -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEKaqt085218 for ; Sun, 13 Jul 2003 07:20:36 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6DEKaS4085216 for ietf-openpgp-bks; Sun, 13 Jul 2003 07:20:36 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from walrus.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6DEKZqt085206 for ; Sun, 13 Jul 2003 07:20:35 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: from claude.jabberwocky.com (pcp04279524pcs.union01.nj.comcast.net [68.39.101.89]) by walrus.jabberwocky.com (8.11.6/8.11.6) with ESMTP id h6DEKLR30204 for ; Sun, 13 Jul 2003 10:20:31 -0400 Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h6DDV9a14471 for ietf-openpgp@imc.org; Sun, 13 Jul 2003 09:31:09 -0400 Date: Sun, 13 Jul 2003 09:31:09 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Two more items Message-ID: <20030713133109.GC1901@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <20030709142426.GH9193@jabberwocky.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <20030709142426.GH9193@jabberwocky.com> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Full User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, Jul 09, 2003 at 10:24:26AM -0400, David Shaw wrote: > My apologies. I missed these two items when I last proofread: > > **************************** > > Sections 5.6 (Compressed Data Packet), 5.7 (Symmetrically Encrypted > Data Packet), 5.13 (Sym. Encrypted Integrity Protected Data Packet) > all indicate that they can contain more than one literal packet. This > makes sense for encrypting multiple files together, and both PGP and > GnuPG correctly handle messages with multiple literal packets. > > However, the grammar in section 10.2 defines a "Literal Message" as a > single literal packet: I should clarify exactly what I tested here. Both PGP (8) and GnuPG worked properly with an encrypted message that contained two literal packets. That is to say, a regular public key encrypted message except that the encrypted data packet contained two literal packets instead of one. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/EV8d4mZch0nhy8kRAp/AAKCraFUEyIbsAA90XgX9MNkxBcJBbgCfZvp8 P5aIbJfoeoHM3ddy0Lun7s0= =0uha -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69EObqt098875 for ; Wed, 9 Jul 2003 07:24:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h69EOb1v098874 for ietf-openpgp-bks; Wed, 9 Jul 2003 07:24:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h69EOaqt098867 for ; Wed, 9 Jul 2003 07:24:36 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h69EOQn19010 for ietf-openpgp@imc.org; Wed, 9 Jul 2003 10:24:26 -0400 Date: Wed, 9 Jul 2003 10:24:26 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Two more items Message-ID: <20030709142426.GH9193@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (69% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 My apologies. I missed these two items when I last proofread: **************************** Sections 5.6 (Compressed Data Packet), 5.7 (Symmetrically Encrypted Data Packet), 5.13 (Sym. Encrypted Integrity Protected Data Packet) all indicate that they can contain more than one literal packet. This makes sense for encrypting multiple files together, and both PGP and GnuPG correctly handle messages with multiple literal packets. However, the grammar in section 10.2 defines a "Literal Message" as a single literal packet: Literal Message :- Literal Data Packet. I suggest a small change to make the grammar match the rest of the document (and reality): Literal Message :- Literal Data Packet | Literal Message, Literal Data Packet. **************************** Section 10.2 (OpenPGP Messages) has a blank line in the middle of the paragraph beginning "In addition, decrypting a Symmetrically Encrypted Data Packet". **************************** David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD4DBQE/DCWa4mZch0nhy8kRAom6AJ4k/V9gE/4h99UGQ8qxxcVh/bA6VACY3tPg uInYth+nGCdgYt5QPNt4rQ== =y1pn -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h683stqt009969 for ; Mon, 7 Jul 2003 20:54:55 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h683stH1009968 for ietf-openpgp-bks; Mon, 7 Jul 2003 20:54:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h683ssqt009962 for ; Mon, 7 Jul 2003 20:54:54 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h683spK01124 for ietf-openpgp@imc.org; Mon, 7 Jul 2003 23:54:51 -0400 Date: Mon, 7 Jul 2003 23:54:51 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Adding in BZ2 compression? Message-ID: <20030708035451.GA31450@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200307040205.h6425GJ13374@finney.org> <200307040205.h6425GJ13374@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Gibbous (60% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Mon, Jul 07, 2003 at 11:58:57AM -0700, Bill Frantz wrote: > >I don't advocate making any severe changes in the preference system, > >but perhaps the language here could be made a bit stronger? Something > >like "Note that without the ability to rewrite a self-signature, > >interoperability issues may occur when the same key is used in more > >than one implementation." would be great. > > I realize this suggestion is getting into UI issues, but... > > Perhaps implementations should also warn the user if the user's > public key includes features that are not supported by the > implementation, and offer to generate a new self-signature that does > not include those features. It's a good idea, and in fact has been on my todo list for GnuPG for a little while now. It's one of those things that sounds easy, but is actually pretty fussy to do (What if there is more than one self-sig? What if the user later removes a self-sig with safe permissions, leaving a self-sig with unsafe permissions? Etc). Nothing unsolvable, but there are a lot of corner cases. That said, should such a thing be mentioned in 2440bis? I'm not sure. I certainly wouldn't be against something like "Implementations MAY wish to warn the user when importing a key that has preferences that contradict the capabilities of the implementation". David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/CkCL4mZch0nhy8kRAkFkAKCV4N6AsONC11H4MqExgNDkMwZ6oACgqk6T de02ELd0rqdgD+myEBjV0Jg= =SON4 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6813xqt004001 for ; Mon, 7 Jul 2003 18:03:59 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6813xeM004000 for ietf-openpgp-bks; Mon, 7 Jul 2003 18:03:59 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6813vqt003993 for ; Mon, 7 Jul 2003 18:03:58 -0700 (PDT) (envelope-from jon@callas.org) Received: from [192.168.1.37] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2) for ; Mon, 7 Jul 2003 18:03:57 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Mon, 07 Jul 2003 18:03:58 -0700 Subject: Re: Adding in BZ2 compression? From: Jon Callas To: OpenPGP Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 7/3/03 6:56 PM, "Derek Atkins" wrote: > Just to play devil's advocate, why do we need yet another compression > algorithm? I'm not the person asking for them, so I may be inadequately explaining this. Nonetheless, here goes. The argument of "no new algorithms unless one is broken" makes more sense for things like ciphers than it does for compression. Compression in OpenPGP doesn't have the same sort of security implications that a cipher does, and so one doesn't need to be as conservative about it. The practical technical reason for bz2 is that it compresses better. In a test I saw, it compresses 12% better than Deflate, and 7% better than zlib. That test was with a backup of a server. Here's the actual results: Original tar file: 1,739,950,080 bytes (1.62 GB) 100% .tar.pgp file : 730,450,065 bytes (696.6 MB) 43% .tar.gz file : 694,085,841 bytes (661.9 MB) 40% .tar.bz2 file : 648,270,622 bytes (618.2 MB) 38% The practical product reason is that there are a number of storage archival systems that are adding in crypto. Many are encrypting some compressed data with PKCS7 or some home-brew thing. I've been getting questions about using OpenPGP as an archival primitive, especially since it includes compression. I would like to be responsive to this, and say that OpenPGP is a great system to use for encryption and compression, and why sure, just code it up this way. It would similarly pain me to have to say that OpenPGP isn't suitable for encryption and compression of large amounts of data, please go shop at Gimble's. Yes, I know that there are potential interoperability issues when keys get migrated around, but I also of the opinion that when an implementation imports a key, it should make sure that the preferences reflect what it supports. Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67MYwqt097993 for ; Mon, 7 Jul 2003 15:34:58 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67MYwDf097991 for ietf-openpgp-bks; Mon, 7 Jul 2003 15:34:58 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67MYuqt097982 for ; Mon, 7 Jul 2003 15:34:56 -0700 (PDT) (envelope-from rabbi@abditum.com) Received: by thetis.deor.org (Postfix, from userid 500) id 127EC45067; Mon, 7 Jul 2003 15:34:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by thetis.deor.org (Postfix) with ESMTP id F292648030; Mon, 7 Jul 2003 15:34:56 -0700 (PDT) Date: Mon, 7 Jul 2003 15:34:56 -0700 (PDT) From: Len Sassaman X-Sender: To: David Shaw Cc: Subject: Re: PoP & Signer's User ID subpacket? In-Reply-To: <20030617033611.GF20267@jabberwocky.com> Message-ID: X-AIM: Elom777 X-icq: 10735603 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 16 Jun 2003, David Shaw wrote: > This raises a 2440bis question: given all the recent deprecation of > PGP 2.x stuff, is it worth requiring self-signatures on user IDs now? > If I recall, the only reason that user ID self-signatures are not > currently required was for 2.x compatibility. Certainly every modern > implementation (5.0+, any GnuPG) generates user ID self-signatures > automatically when a user ID is created. I think this is a marvelous idea. Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67LN7qt093212 for ; Mon, 7 Jul 2003 14:23:07 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h67LN7or093211 for ietf-openpgp-bks; Mon, 7 Jul 2003 14:23:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from hawk.mail.pas.earthlink.net (hawk.mail.pas.earthlink.net [207.217.120.22]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h67LN6qt093195 for ; Mon, 7 Jul 2003 14:23:06 -0700 (PDT) (envelope-from frantz@pwpconsult.com) Received: from h-69-3-26-10.snvacaid.covad.net ([69.3.26.10] helo=[192.168.1.5]) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19ZdRv-0003VF-00 for ietf-openpgp@imc.org; Mon, 07 Jul 2003 14:23:03 -0700 X-Sender: frantz%pwpconsult.com@pop.business.earthlink.net Message-Id: In-Reply-To: <20030704042150.GY8086@jabberwocky.com> References: <200307040205.h6425GJ13374@finney.org> <200307040205.h6425GJ13374@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 7 Jul 2003 11:58:57 -0700 To: ietf-openpgp@imc.org From: Bill Frantz Subject: Re: Adding in BZ2 compression? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:21 PM -0700 7/3/03, David Shaw wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >On Thu, Jul 03, 2003 at 07:05:16PM -0700, Hal Finney wrote: >> >> Jon Callas writes: >> > I have a request for an algorithm number for bz2 compression. The >> > implementer in question has promised on a stack of holy books only >> > to use it along with compression prefs. Anyone object strongly? >> >> I don't see a need to add another compression algorithm unless there is >> something wrong with the ones we already have. Adding a new one can only >> hurt interoperability in the long run. What is the reason for adding it? > >I don't have strong feelings for or against adding bz2, but your >comment about interoperability raises a related issue. In theory, the >preference system would prevent the use of bz2 except when it can be >properly handled by the recipient so there should be no >interoperability issues. > >... > >I have already seen a few examples of this problem (a PGP-generated >key with an IDEA pref being used on GnuPG, and a GnuPG-generated key >with a ZLIB pref being used on PGP). > >I don't think the answer here is to restrict the use of new >algorithms. 2440 has this to say, which pretty much eliminates the >problem in the design: > > Since a self-signature contains important information about the > key's use, an implementation SHOULD allow the user to rewrite the > self-signature, and important information in it, such as > preferences and key expiration. > >I don't advocate making any severe changes in the preference system, >but perhaps the language here could be made a bit stronger? Something >like "Note that without the ability to rewrite a self-signature, >interoperability issues may occur when the same key is used in more >than one implementation." would be great. I realize this suggestion is getting into UI issues, but... Perhaps implementations should also warn the user if the user's public key includes features that are not supported by the implementation, and offer to generate a new self-signature that does not include those features. Cheers - Bill ------------------------------------------------------------------------- Bill Frantz | "A Jobless Recovery is | Periwinkle -- Consulting (408)356-8506 | like a Breadless Sand- | 16345 Englewood Ave. frantz@pwpconsult.com | wich." -- Steve Schear | Los Gatos, CA 95032, USA Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64J2Jqt009683 for ; Fri, 4 Jul 2003 12:02:19 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64J2J0U009682 for ietf-openpgp-bks; Fri, 4 Jul 2003 12:02:19 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64J2Hqt009674 for ; Fri, 4 Jul 2003 12:02:18 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h64J2EH08151 for ietf-openpgp@imc.org; Fri, 4 Jul 2003 15:02:14 -0400 Date: Fri, 4 Jul 2003 15:02:14 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: bis-08 notes Message-ID: <20030704190213.GH1023@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (20% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here are the rest of my notes on bis-08. There shouldn't be anything terribly controversial here. This is mostly just language and phrasing stuff. David ======================================== In the IESG Note at the head of the document, there is the phrase "(say for new encryption algorithms for example)". I suggest removing the "for example", as using both "say..." and "...for example" is redundant. ======================================== Section 1.1 (Terms) refers to GnuPG once as "GNUpg". ======================================== Section 3.7.1.3 (Iterated and Salted S2K) contains an extra space before the sentence beginning "Then the salt, followed..." ======================================== Section 5.1 (Public-Key Encrypted Session Key Packet) contains the sentence "An implementation should accept, but not generate a version of 2, which is equivalent to V3 in all other respects.". I suggest rephrasing with RFC-2119 keywords as "An implementation SHOULD accept, but MUST NOT generate a version of 2....". Actually, this whole sentence may be better in the Implementation Nits section where there already is an item for V2 public keys. ======================================== Section 5.2.3.2 (Signature Subpacket Type) contains the sentence "Subpackets that are found on a self-signature are placed on a User ID certification made by the key itself." I suggest removing the words "User ID" as there are other types of self-signatures than User ID certifications (i.e. 1F signatures). ======================================== Section 5.2.3.3 (Notes on Self-Signatures) contains the sentence "If the key is located by key id, then algorithm of the default User ID of the key provides the default symmetric algorithm." "then algorithm" should be "the algorithm". Also, what is a "default User ID"? Is this intended to be an implementation defined default, or was this supposed to say "primary User ID"? ======================================== Section 5.2.3.23 (Reason for Revocation) ends with "A revoked certification no longer is a part of validity calculations." That's a little odd grammar-wise. I suggest "A revoked certification is no longer a part of validity calculations." ======================================== Section 5.2.4 (Computing Signatures) says "A V3 certification hashes the contents of the name packet, without any header." "name packet" should probably be "User ID or attribute packet". ======================================== Section 5.10 (Trust Packet) should probably have some text noting that the format of trust packets are implementation defined. ======================================== Section 6 (Radix-64 Conversions) discusses Radix-64 (and calls it Radix-64) throughout, and then adds "An OpenPGP implementation MAY use ASCII Armor to protect the raw binary data". This statement comes before the format of ASCII Armor is introduced in section 6.2, and Radix-64 isn't equivalent to ASCII Armor anyway (it is a *part* of ASCII Armor, but armor includes the headers and tail as well). I suggest moving that sentence to section 6.2. ======================================== Section 7 (Cleartext signature framework) implies that the only armor header line that may be used in clear signatures is "Hash", which isn't true in practice (Version and Comment are common). Adding an item for "zero or more lines of armor headers" would help. ======================================== Section 7 (Cleartext signature framework) says "If the "Hash" armor header is given, the specified message digest algorithm is used for the signature." "algorithm is" should be "algorithm(s) are" as more than one hash algorithm can be provided on a given Hash line, and more than one Hash line can be given. ======================================== Section 9 (Constants) says "Note that these tables are not exhaustive lists; an implementation MAY implement an algorithm not on these lists." I suggest adding "so long as the algorithm number is chosen from the private or experimental algorithm range." ======================================== Section 10.1 (Transferable Public Keys) says "After the User ID packets there may be one or more Subkey packets." I suggest changing "User ID packets" to "User ID or Attribute packets". ======================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/Bc814mZch0nhy8kRAk/uAKDSKvjI6/41eQIhHCU934fk5hqw5QCeO5Nb GYKFWuYH0RBVXqAU2GqzJsw= =sTMD -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64H7Rqt004923 for ; Fri, 4 Jul 2003 10:07:27 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64H7R9s004922 for ietf-openpgp-bks; Fri, 4 Jul 2003 10:07:27 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64H7Pqt004913 for ; Fri, 4 Jul 2003 10:07:25 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 19YTvn-0008Qu-00 for ; Fri, 04 Jul 2003 19:01:07 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 19YU2M-0007zK-00; Fri, 04 Jul 2003 19:07:54 +0200 To: "Michael Young" Cc: "OpenPGP" Subject: Re: Adding in BZ2 compression? References: <002401c34249$96c14440$c23fa8c0@transarc.ibm.com> From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Fri, 04 Jul 2003 19:07:54 +0200 In-Reply-To: <002401c34249$96c14440$c23fa8c0@transarc.ibm.com> (Michael Young's message of "Fri, 4 Jul 2003 12:30:26 -0400") Message-ID: <87u1a2z0d1.fsf@alberti.g10code.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 4 Jul 2003 12:30:26 -0400, Michael Young said: > If it didn't have any obvious advantage, I'd agree with you; but, it does. > It's certainly more useful than two stylistic variants of the same thing, > which is what we have now. Yep, I'd prefer to drop compression algo 1 because 2 is better defined and provides a clean way to specify the used window size. For backward compatibility it can not be done though. > essence of Werner's argument, although he makes it in terms of > PGP/MIME, which I don't find compelling for the pure OpenPGP spec.) OpenPGP is mostly used for email, so PGP/MIME makes a lot of sense. The encapsulation provided by MIME is much more flexible than that of OpenPGP. -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64GW3qt002076 for ; Fri, 4 Jul 2003 09:32:03 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h64GW3Ek002075 for ietf-openpgp-bks; Fri, 4 Jul 2003 09:32:03 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from mta7.adelphia.net (mta7.adelphia.net [64.8.50.193]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h64GVtqt001991 for ; Fri, 4 Jul 2003 09:31:56 -0700 (PDT) (envelope-from mwy-opgp97@the-youngs.org) Received: from mwyoung ([68.168.179.202]) by mta7.adelphia.net (InterMail vM.5.01.05.32 201-253-122-126-132-20030307) with SMTP id <20030704163151.PQAH1347.mta7.adelphia.net@mwyoung> for ; Fri, 4 Jul 2003 12:31:51 -0400 Message-ID: <002401c34249$96c14440$c23fa8c0@transarc.ibm.com> From: "Michael Young" To: "OpenPGP" References: Subject: Re: Adding in BZ2 compression? Date: Fri, 4 Jul 2003 12:30:26 -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 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 From: "Derek Atkins" > Just to play devil's advocate, why do we need yet another compression > algorithm? OK... I'll argue the other side for you ;-). Why did we need any more ciphers after adding 3DES? Performance, for one. BZ2 produces smaller output for many common forms of input. If it didn't have any obvious advantage, I'd agree with you; but, it does. It's certainly more useful than two stylistic variants of the same thing, which is what we have now. Turning the question around: what's the harm? Adding another optional compression algorithm won't create any problems we don't already have. (ZLIB is supported by GnuPG but not PGP.) The preference system is the architected solution to this problem. As David notes, moving from one implementation to another requires being able to rewrite preferences, but that's always been the case. Now, given that compression can be done by the end-user, it's hard to argue that *any* algorithm is a have-to-have. (This seems to be the essence of Werner's argument, although he makes it in terms of PGP/MIME, which I don't find compelling for the pure OpenPGP spec.) But since the architecture includes compression, I'd say that including a popular and more powerful algorithm is worthwhile. -----BEGIN PGP SIGNATURE----- Version: PGP Personal Privacy 6.5.3 iQA/AwUBPwWrnec3iHYL8FknEQK+kgCfatRR21tyFSM5Oy0T5XO9hr7fTB0An14+ 5fVxGAopM2XWaJY5E/OlodxJ =l/o7 -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h649tNqt073160 for ; Fri, 4 Jul 2003 02:55:23 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h649tNd3073159 for ietf-openpgp-bks; Fri, 4 Jul 2003 02:55:23 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h649tKqt073144 for ; Fri, 4 Jul 2003 02:55:21 -0700 (PDT) (envelope-from wk@gnupg.org) Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 3.35 #1 (Debian)) id 19YNBW-0006Jx-00 for ; Fri, 04 Jul 2003 11:48:54 +0200 Received: from wk by alberti.g10code.de with local (Exim 3.36 #1 (Debian)) id 19YMOP-00074G-00; Fri, 04 Jul 2003 10:58:09 +0200 To: Jon Callas Cc: OpenPGP Subject: Re: Adding in BZ2 compression? References: From: Werner Koch Organisation: g10 Code GmbH X-Request-PGP: finger:wk@g10code.com X-PGP-KeyID: 621CC013 Date: Fri, 04 Jul 2003 10:58:09 +0200 In-Reply-To: (Jon Callas's message of "Thu, 03 Jul 2003 16:47:52 -0700") Message-ID: <87he621xem.fsf@alberti.g10code.de> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/20.7 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 03 Jul 2003 16:47:52 -0700, Jon Callas said: > I have a request for an algorithm number for bz2 compression. The > implementer in question has promised on a stack of holy books only to use it > along with compression prefs. Anyone object strongly? I don't see a real advantage. bz2 does only make sense for large files and thus it won't hurt to first but the bz2 compressed data into an appropriate MIME container and then apply OpenPGP. If it is a problem that the signature can only be applied on the compressed data, one should use the PGP/MIME approach and don't combine signature and encryption in one OpenPGP message. Decompressing bz2 requires huge amounts of memory and thus it can't be implemented for small devices. If we assume that people are going to use their keys also on PDAs, we will run into problems with the preferences. Shalom-Salam, Werner -- Werner Koch The GnuPG Experts http://g10code.com Free Software Foundation Europe http://fsfeurope.org Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h644lbqt036116 for ; Thu, 3 Jul 2003 21:47:37 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h644lbcJ036115 for ietf-openpgp-bks; Thu, 3 Jul 2003 21:47:37 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h644laqt036108 for ; Thu, 3 Jul 2003 21:47:36 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h644lXT01295 for ietf-openpgp@imc.org; Fri, 4 Jul 2003 00:47:33 -0400 Date: Fri, 4 Jul 2003 00:47:33 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Two clarifications Message-ID: <20030704044733.GB1023@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (20% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I did a closer read of bis08, and have two minor questions for clarification. Nothing terribly controversial ;) 1) Is the ASCII armor checksum optional? Sections 6 and 6.2 seem to imply that is isn't (they never say "optional" or "if used" or anything like that), but section 6 also says that it MAY be used. 2) Is the 1F direct key signature always a self-signature? Nothing else in the draft seems to say so, and a non-self-signature 1F seems useful, but the grammar in section 11.1 (Key Structures) includes only a "Direct Key Self Signature". Perhaps dropping the word "Self" would make this clearer. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/BQbl4mZch0nhy8kRAgDQAKCCJuLFaouOg8M6KRwz+iZwl2GpZACdED1J IHGqJhvrRyARMcWg8lCOySo= =nmuo -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h644Ltqt035614 for ; Thu, 3 Jul 2003 21:21:55 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h644Lt3M035613 for ietf-openpgp-bks; Thu, 3 Jul 2003 21:21:55 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from claude.jabberwocky.com (walrus.ne.client2.attbi.com [24.60.130.129]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h644Lsqt035607 for ; Thu, 3 Jul 2003 21:21:54 -0700 (PDT) (envelope-from dshaw@jabberwocky.com) Received: (from dshaw@localhost) by claude.jabberwocky.com (8.11.6/8.11.6) id h644Lpw01017 for ietf-openpgp@imc.org; Fri, 4 Jul 2003 00:21:51 -0400 Date: Fri, 4 Jul 2003 00:21:50 -0400 From: David Shaw To: ietf-openpgp@imc.org Subject: Re: Adding in BZ2 compression? Message-ID: <20030704042150.GY8086@jabberwocky.com> Mail-Followup-To: ietf-openpgp@imc.org References: <200307040205.h6425GJ13374@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; x-action=pgp-signed Content-Disposition: inline In-Reply-To: <200307040205.h6425GJ13374@finney.org> X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560 X-Request-PGP: http://www.jabberwocky.com/david/keys.asc X-Phase-Of-Moon: The Moon is Waxing Crescent (5% of Full) User-Agent: Mutt/1.5.4i Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, Jul 03, 2003 at 07:05:16PM -0700, Hal Finney wrote: > > Jon Callas writes: > > I have a request for an algorithm number for bz2 compression. The > > implementer in question has promised on a stack of holy books only > > to use it along with compression prefs. Anyone object strongly? > > I don't see a need to add another compression algorithm unless there is > something wrong with the ones we already have. Adding a new one can only > hurt interoperability in the long run. What is the reason for adding it? I don't have strong feelings for or against adding bz2, but your comment about interoperability raises a related issue. In theory, the preference system would prevent the use of bz2 except when it can be properly handled by the recipient so there should be no interoperability issues. Of course, that's theory. The preference system works quite well on paper, but unfortunately fails in the case where a key is generated in an implementation that can use bz2 and the public key is distributed. Later, the user changes their implementation to one that cannot use bz2. Anyone sending a message to that public key has the belief that bz2 can be safely used, and may well use it, causing a problem since the user's new implementation cannot handle bz2 (even though their key claims they can). I have already seen a few examples of this problem (a PGP-generated key with an IDEA pref being used on GnuPG, and a GnuPG-generated key with a ZLIB pref being used on PGP). I don't think the answer here is to restrict the use of new algorithms. 2440 has this to say, which pretty much eliminates the problem in the design: Since a self-signature contains important information about the key's use, an implementation SHOULD allow the user to rewrite the self-signature, and important information in it, such as preferences and key expiration. I don't advocate making any severe changes in the preference system, but perhaps the language here could be made a bit stronger? Something like "Note that without the ability to rewrite a self-signature, interoperability issues may occur when the same key is used in more than one implementation." would be great. David -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3rc1 (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iD8DBQE/BQDe4mZch0nhy8kRAsLRAJsF+Zc8fD85cjGV4JIT8Kv7QJLg5wCffisr U+65IozEBIVm+SznfIwniDk= =9xSE -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6426eqt031971 for ; Thu, 3 Jul 2003 19:06:40 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h6426eUq031970 for ietf-openpgp-bks; Thu, 3 Jul 2003 19:06:40 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h6426cqt031965 for ; Thu, 3 Jul 2003 19:06:38 -0700 (PDT) (envelope-from hal@finney.org) Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id h6425GJ13374; Thu, 3 Jul 2003 19:05:16 -0700 Date: Thu, 3 Jul 2003 19:05:16 -0700 From: "Hal Finney" Message-Id: <200307040205.h6425GJ13374@finney.org> To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Adding in BZ2 compression? Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: > I have a request for an algorithm number for bz2 compression. The > implementer in question has promised on a stack of holy books only to use it > along with compression prefs. Anyone object strongly? I don't see a need to add another compression algorithm unless there is something wrong with the ones we already have. Adding a new one can only hurt interoperability in the long run. What is the reason for adding it? Hal Finney Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h641usqt031663 for ; Thu, 3 Jul 2003 18:56:54 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h641uspa031662 for ietf-openpgp-bks; Thu, 3 Jul 2003 18:56:54 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h641uqqt031656 for ; Thu, 3 Jul 2003 18:56:53 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h641uo2J028482; Thu, 3 Jul 2003 21:56:50 -0400 (EDT) Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h641uoxG027530; Thu, 3 Jul 2003 21:56:50 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by manawatu-mail-centre.mit.edu (8.12.4/8.12.4) with ESMTP id h641unFJ020495; Thu, 3 Jul 2003 21:56:49 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h641unI9002704; Thu, 3 Jul 2003 21:56:49 -0400 (EDT) To: Jon Callas Cc: OpenPGP Subject: Re: Adding in BZ2 compression? References: From: Derek Atkins Date: 03 Jul 2003 21:56:49 -0400 In-Reply-To: Message-ID: Lines: 19 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Just to play devil's advocate, why do we need yet another compression algorithm? -derek Jon Callas writes: > I have a request for an algorithm number for bz2 compression. The > implementer in question has promised on a stack of holy books only to use it > along with compression prefs. Anyone object strongly? > > Jon > -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord@MIT.EDU PGP key available Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Nlpqt028487 for ; Thu, 3 Jul 2003 16:47:51 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h63NlpTx028486 for ietf-openpgp-bks; Thu, 3 Jul 2003 16:47:51 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h63Nloqt028481 for ; Thu, 3 Jul 2003 16:47:50 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.182] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2) for ; Thu, 3 Jul 2003 16:47:50 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Thu, 03 Jul 2003 16:47:52 -0700 Subject: Adding in BZ2 compression? From: Jon Callas To: OpenPGP Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have a request for an algorithm number for bz2 compression. The implementer in question has promised on a stack of holy books only to use it along with compression prefs. Anyone object strongly? Jon Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61J0iFK078793 for ; Tue, 1 Jul 2003 12:00:44 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61J0iXN078792 for ietf-openpgp-bks; Tue, 1 Jul 2003 12:00:44 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61J0gFK078785 for ; Tue, 1 Jul 2003 12:00:43 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.12.4/8.9.2) with ESMTP id h61J0XgW010993; Tue, 1 Jul 2003 15:00:38 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61IviYj011497; Tue, 1 Jul 2003 14:57:44 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h61IvfU8013096; Tue, 1 Jul 2003 14:57:41 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h61Ivfkm026953; Tue, 1 Jul 2003 14:57:41 -0400 (EDT) To: "Imad R. Faiad" Cc: ietf-openpgp@imc.org From: Derek Atkins Subject: Re: Suggestion for the signing subkey problem References: <047b01c33e89$fd852930$39632352@happy> Date: 01 Jul 2003 14:57:41 -0400 In-Reply-To: Message-ID: Lines: 243 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, "Imad R. Faiad" writes: > Greetings, > > Except that the human psyche does not function in the > manner in which your protocol thinks it should. > And that may be it's shortcomings. The human psyche also doesn't remember 1024-bit numbers or perform RSA encryptions. That's why we have computers, to do a lot of work that the human brain cannot do itself. The point is that the computer does the hard work and presents the information in a form that the human psyche can understand. > Packets, protocols, and RFC's are meaningless, when > the limitations of the human mind are not taken into > consideration. By UI, I do not mean an implementation, > I mean, the UI of your RFC, yes, RFC's have a UI... > UI does not only stand for "User Interface", it is > also what I call "Human Element". Uh, no. Sorry. RFCs certainly have "operational requirements" but there is no UI to an RFC. An RFC is a description of a protocol. Different implementations can present that protocol to users in VERY different ways. Except in very limited ways the RFC does not say how information should be presented to users, and this is a Good Thing. Yes, there is a "human element" in terms of usage constraints, operational considerations, and even security implications, and yes, the RFC can point implementors at a "best current practice" to presenting information. However that is all ancillary information; the RFC is in general a protocol document. > You talk about the WoT, but, isn't that broken > with subkeys... In general, no, it is not. There is a particular problem with signing subkeys not being able to securely refer to the master key (which is what the current proposal is trying to fix), but no, in general there is not a WoT problem with subkeys. Walking through a normal WoT (in one direction -- the other is just a mirror image). Alice wants to send a message to Bob. Alice gets Bob's key and see's that Charlie has signed it. Alice knows Charlie, has verified Charlie's key, and trusts Charlie to properly verify keys, so through the WoT Alice can now trust Bob's key. Alice can now encrypt a message to Bob's key and have some level of assurance that it is correct. An attacker could supply another key on a keyserver with Bob's name, but it wouldn't have Charlie's signature Now, let's look at encryption subkeys. The beginning of the story remains the same, except Charlie is signing Bob's master key. Bob's master key signs the encryption subkey, so Alice knows that Bob wants to use that subkey. An attacker couldn't add another encryption key because it wouldn't be signed by Bob's master key. An attacker could claim an encryption key as their own, but to what end -- they couldn't read the message anyways? At best it provides plausible deniability for the actual recipient of an encrypted message. So we're perfectly safe so far. Let's look at Bob signing messages to Alice. In a normal single-key (RSA or DSA) case we're in the same boat at the first case. Nothing new here. The question is what happens when you introduce signature subkeys? Alice receives a message signed with 'key X'. Bob's "keychain" contains subkey X signed with his master key. So, Alice knows that Bob claims X is his key. Alice knows the master key belongs to Bob from Charlie's signature, so the master key is verified. However, there is a problem here (and in RFC2440). Eve could strip out subkey X from Bob's keychain, put it onto her own and self-sign the subkey with Eve's master key. Now (following 2440) Alice does not know whether key X belongs to Bob or Eve. HOWEVER, if we take a step forward in time and look at the current proposal, where the master key and sub-key co-sign the binding. With the co-signature, key X signs "I belong to Bob's master key B" and Bob's master key signs "key X belongs to me". Now, just having key X you can back-track to Bob's master key and the existing WoT for verification. Even if Eve extracts subkey X and puts it on her keychain a 2440bis-compliant implementation wont accept it, because the subkey wont be co-signed. So signing subkeys are safe (with the change to cosign). > That is all I have to say, and only time > will prove me right. Perhaps, but you have not provided the math to back yourself up. Please, if you see a problem with this proposal please explain it... Please provide the math showing how it doesn't work, or the use cases where the key-bindings are insufficient. We want to make 2440bis complete, and all input is welcome. But please keep the topic to "fixing the subkey problem" instead of "subkeys are bad -- get rid of them". The latter is both unhelpful and derailing, neither of which helps make forward progress. > If you do find me obnoxious, then, by all means > do let me know, I will then refrain for posting > anything to this forum. I have not asked you to refrain from posting. I have asked that posts remain on topic and in-scope. I do not feel that is an unreasonable request. > Best Regards > > Imad R. Faiad -derek > On 01 Jul 2003 11:57:13 -0400, you wrote: > > >Ok, putting my chair hat on. > > > >Removing subkeys from 2440bis is OUT OF SCOPE. Fixing security > >problems with subkeys is IN SCOPE. The goal of 2440bis is to fix > >security and interop issues, not remove functionality just because > >some people have minimalist views. > > > >While minimalism is a virtue, it (like all things) should be applied > >in moderation. > > > >Having said that, and taking my chair hat off.... > > > >"Imad R. Faiad" writes: > > > >> 9) She sends a message to Bob, which > >> is at least signed with the signing > >> subkey of Alice's fake key. Does > >> the same with Alice using the signing > >> subkey in Bob's fake key. > > > >Except there is no subkey-signature from the signing subkey on the > >fake-Alice master key, so Bob wont accept it as a valid subkey. > > > >> 10) Alice and Bob thinking that the other > >> party must have generated yet another > >> subkey update their copy from the servers. > > > >Except they wont think this, because the subkey wont validate on > >Eve's replacement keys. > > > >> 11) In both cases the message authenticates, > >> giving credence to the respective fake keys. > >> 12) In the worst case scenario, Alice > >> and Bob, will start using the other's > >> fake key, while each is ignorant > >> that the other party is using his fake > >> key. Since, Eve is in the middle, > >> decrypting the messages, then > >> re-encrypting and forwarding them to > >> the other party. > > > >Well, first, if Alice and Bob have signed each other's master key, > >then they wont use the fake keys. > > > >> The above sounds implausible to you? > > > >It sounds implausible in the face of a real WoT between > >Alice and Bob. It also sounds implausible once Alice and > >Bob have keys in the local keyright. It is certainly plausible > >on a first-contact basis without a real WoT. > > > >I will note that UI issues are out of scope here. The UI issue > >is an implementation issue and has nothing to do with interop. > >The purpose of 2440bis is to fix security and interop problems; > >how that is translated to a UI is implementation dependent and has > >little to do with the protocol. > > > >> There are a spectrum of solutions. > >> On the one extreme there is the scalpel school of > >> thought which believes that if something > >> is questionable, you get rid of it altogether, > >> to put my suggestion on the Master key/ one > >> subkey restriction, into perspective. It does > >> not mean that I belong to the "scalpel school of > >> thought". Nor do I profess such a proposed solution > >> as a religion... I could care less what the adopted > >> solution is, as long as it addresses the root of > >> the problem to my satisfaction. > > > >As I have already stated, removing subkeys is out of scope. > > > >> David Shaw's patch, does not solve the problem. > > > >Can you please show an example where David's patch does not work? > >In particular, the approach where the master key and subkey cross-sign > >each other seems to protect against all the attacks you've proposed so > >far... The case where Alice does not know Bob's master key is a WoT > >issue and has nothing to do with subkeys -- the subkey issue is knowing > >what master key a subkey belongs to. > > > >> Why shouldn't subkeys be regarded like any other > >> keys. What applies to key, should apply to them > >> too. > > > >In what way are subkeys not regarded like master keys? > > > >> my 2c > >> > >> Best Regards > >> > >> Imad R. Faiad > > > >-derek > > > >> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: > >> > >> > > >> >> >I am amazed that this thread is still running several weeks > >> >> after you > >> >> >started it, with virtually every response refuting your arguments... > >> >> > > >> >> And what amazes me, is that you have yet to grasp what we are > >> >> talking about! Please re-read the thread, some issues have > >> >> been addressed. I sincerely hope that you re-read each and > >> >> every message in that thread, because, you are taylor made > >> >> for the kind of attacks which can be inflicted to your OpenPGP keys. > >> > > >> >I've read all the messages. Your request that subkey capability be > >> >essentially removed has been rejected by all of them. > >> > > >> >> >RFC 2440 was published five years ago. I look forward to your draft > >> >> >removing multiple subkey capability from it. > >> >> I am no paper pusher, and do not have the funding or > >> >> time/ability to publish RFC's > >> > > >> >So I guess this thread is at an end then, with the capability > >> >remaining. > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJZFK074246 for ; Tue, 1 Jul 2003 11:19:35 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61IJZvj074245 for ietf-openpgp-bks; Tue, 1 Jul 2003 11:19:35 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from lake.cyberia.net.lb (lake.cyberia.net.lb [195.112.195.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJRFK074236 for ; Tue, 1 Jul 2003 11:19:28 -0700 (PDT) (envelope-from matic@cyberia.net.lb) Received: from ppp-12-83.cyberia.net.lb ([195.112.203.84]) by lake.cyberia.net.lb with SMTP id <20030701180916.GEQC9885.lake@ppp-12-83.cyberia.net.lb>; Tue, 1 Jul 2003 21:09:16 +0300 From: "Imad R. Faiad" To: ietf-openpgp@imc.org Cc: Derek Atkins Subject: Re: Suggestion for the signing subkey problem Date: Tue, 01 Jul 2003 20:19:21 +0200 Message-ID: <75k3gv4vvqi2b0eccqobbp13d3j6jhe4c5@4ax.com> References: <047b01c33e89$fd852930$39632352@happy> In-Reply-To: X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h61IJYFK074240 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Except that the human psyche does not function in the manner in which your protocol thinks it should. And that may be it's shortcomings. Packets, protocols, and RFC's are meaningless, when the limitations of the human mind are not taken into consideration. By UI, I do not mean an implementation, I mean, the UI of your RFC, yes, RFC's have a UI... UI does not only stand for "User Interface", it is also what I call "Human Element". You talk about the WoT, but, isn't that broken with subkeys... That is all I have to say, and only time will prove me right. If you do find me obnoxious, then, by all means do let me know, I will then refrain for posting anything to this forum. Best Regards Imad R. Faiad On 01 Jul 2003 11:57:13 -0400, you wrote: >Ok, putting my chair hat on. > >Removing subkeys from 2440bis is OUT OF SCOPE. Fixing security >problems with subkeys is IN SCOPE. The goal of 2440bis is to fix >security and interop issues, not remove functionality just because >some people have minimalist views. > >While minimalism is a virtue, it (like all things) should be applied >in moderation. > >Having said that, and taking my chair hat off.... > >"Imad R. Faiad" writes: > >> 9) She sends a message to Bob, which >> is at least signed with the signing >> subkey of Alice's fake key. Does >> the same with Alice using the signing >> subkey in Bob's fake key. > >Except there is no subkey-signature from the signing subkey on the >fake-Alice master key, so Bob wont accept it as a valid subkey. > >> 10) Alice and Bob thinking that the other >> party must have generated yet another >> subkey update their copy from the servers. > >Except they wont think this, because the subkey wont validate on >Eve's replacement keys. > >> 11) In both cases the message authenticates, >> giving credence to the respective fake keys. >> 12) In the worst case scenario, Alice >> and Bob, will start using the other's >> fake key, while each is ignorant >> that the other party is using his fake >> key. Since, Eve is in the middle, >> decrypting the messages, then >> re-encrypting and forwarding them to >> the other party. > >Well, first, if Alice and Bob have signed each other's master key, >then they wont use the fake keys. > >> The above sounds implausible to you? > >It sounds implausible in the face of a real WoT between >Alice and Bob. It also sounds implausible once Alice and >Bob have keys in the local keyright. It is certainly plausible >on a first-contact basis without a real WoT. > >I will note that UI issues are out of scope here. The UI issue >is an implementation issue and has nothing to do with interop. >The purpose of 2440bis is to fix security and interop problems; >how that is translated to a UI is implementation dependent and has >little to do with the protocol. > >> There are a spectrum of solutions. >> On the one extreme there is the scalpel school of >> thought which believes that if something >> is questionable, you get rid of it altogether, >> to put my suggestion on the Master key/ one >> subkey restriction, into perspective. It does >> not mean that I belong to the "scalpel school of >> thought". Nor do I profess such a proposed solution >> as a religion... I could care less what the adopted >> solution is, as long as it addresses the root of >> the problem to my satisfaction. > >As I have already stated, removing subkeys is out of scope. > >> David Shaw's patch, does not solve the problem. > >Can you please show an example where David's patch does not work? >In particular, the approach where the master key and subkey cross-sign >each other seems to protect against all the attacks you've proposed so >far... The case where Alice does not know Bob's master key is a WoT >issue and has nothing to do with subkeys -- the subkey issue is knowing >what master key a subkey belongs to. > >> Why shouldn't subkeys be regarded like any other >> keys. What applies to key, should apply to them >> too. > >In what way are subkeys not regarded like master keys? > >> my 2c >> >> Best Regards >> >> Imad R. Faiad > >-derek > >> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: >> >> > >> >> >I am amazed that this thread is still running several weeks >> >> after you >> >> >started it, with virtually every response refuting your arguments... >> >> > >> >> And what amazes me, is that you have yet to grasp what we are >> >> talking about! Please re-read the thread, some issues have >> >> been addressed. I sincerely hope that you re-read each and >> >> every message in that thread, because, you are taylor made >> >> for the kind of attacks which can be inflicted to your OpenPGP keys. >> > >> >I've read all the messages. Your request that subkey capability be >> >essentially removed has been rejected by all of them. >> > >> >> >RFC 2440 was published five years ago. I look forward to your draft >> >> >removing multiple subkey capability from it. >> >> I am no paper pusher, and do not have the funding or >> >> time/ability to publish RFC's >> > >> >So I guess this thread is at an end then, with the capability >> >remaining. -----BEGIN PGP SIGNATURE----- Version: 8.0.2irf Comment: KeyID: 0xBCC31718833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBPwHP/LzDFxiDPxutAQJMwQf/UNKORxZfDApb5sZWItwkl7bkvJEkOECh SphQ5B5+YWOdm6zjWaK0GKISA7LIwsrOBIWZ7VEpbNHZznbyHMa7pM9iedy3s0p4 29twTgSf7XEGBX0GuJSvsgt8Oh1aJoLQYGXUWS+GJ7rqPzjFuXQKv6h6+fvWMNzf At+9M49H+zrAGFaiWWWX4gErpV74XmaZS63ARyro0taWTHlJY1Flm9OPhbGsA4kQ undI200hv1Z1f4zfCfGqNeyknRQz5dRqQnJ6D1ZwUu1fPtHGCsAaVmL9Mf+kGZ2Q 3gSI0hnYH3MhZWXgMFc1cYxgIhiFqbn/BDLS0isS/9EjG5GGWLJ0qw== =cDhw -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJBFK074231 for ; Tue, 1 Jul 2003 11:19:11 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61IJB8x074230 for ietf-openpgp-bks; Tue, 1 Jul 2003 11:19:11 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from lake.cyberia.net.lb (lake.cyberia.net.lb [195.112.195.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61IJ8FK074217 for ; Tue, 1 Jul 2003 11:19:08 -0700 (PDT) (envelope-from matic@cyberia.net.lb) Received: from ppp-12-83.cyberia.net.lb ([195.112.203.84]) by lake.cyberia.net.lb with SMTP id <20030701180852.GEPX9885.lake@ppp-12-83.cyberia.net.lb>; Tue, 1 Jul 2003 21:08:52 +0300 From: "Imad R. Faiad" To: ietf-openpgp@imc.org Cc: Derek Atkins Subject: Re: Suggestion for the signing subkey problem Date: Tue, 01 Jul 2003 20:18:55 +0200 Message-ID: References: <047b01c33e89$fd852930$39632352@happy> In-Reply-To: X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h61IJAFK074226 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Except that the human psyche does not function in the manner in which your protocol thinks it should. And that may be it's shortcomings. Packets, protocols, and RFC's are meaningless, when the limitations of the human mind are not taken into consideration. By UI, I do not mean an implementation, I mean, the UI of your RFC, yes, RFC's have a UI... UI does not only stand for "User Interface", it is also what I call "Human Element". You talk about the WoT, but, isn't that broken with subkeys... That is all I have to say, and only time will prove me right. If you do find me obnoxious, then, by all means do let me know, I will then refrain for posting anything to this forum. Best Regards Imad R. Faiad On 01 Jul 2003 11:57:13 -0400, you wrote: >Ok, putting my chair hat on. > >Removing subkeys from 2440bis is OUT OF SCOPE. Fixing security >problems with subkeys is IN SCOPE. The goal of 2440bis is to fix >security and interop issues, not remove functionality just because >some people have minimalist views. > >While minimalism is a virtue, it (like all things) should be applied >in moderation. > >Having said that, and taking my chair hat off.... > >"Imad R. Faiad" writes: > >> 9) She sends a message to Bob, which >> is at least signed with the signing >> subkey of Alice's fake key. Does >> the same with Alice using the signing >> subkey in Bob's fake key. > >Except there is no subkey-signature from the signing subkey on the >fake-Alice master key, so Bob wont accept it as a valid subkey. > >> 10) Alice and Bob thinking that the other >> party must have generated yet another >> subkey update their copy from the servers. > >Except they wont think this, because the subkey wont validate on >Eve's replacement keys. > >> 11) In both cases the message authenticates, >> giving credence to the respective fake keys. >> 12) In the worst case scenario, Alice >> and Bob, will start using the other's >> fake key, while each is ignorant >> that the other party is using his fake >> key. Since, Eve is in the middle, >> decrypting the messages, then >> re-encrypting and forwarding them to >> the other party. > >Well, first, if Alice and Bob have signed each other's master key, >then they wont use the fake keys. > >> The above sounds implausible to you? > >It sounds implausible in the face of a real WoT between >Alice and Bob. It also sounds implausible once Alice and >Bob have keys in the local keyright. It is certainly plausible >on a first-contact basis without a real WoT. > >I will note that UI issues are out of scope here. The UI issue >is an implementation issue and has nothing to do with interop. >The purpose of 2440bis is to fix security and interop problems; >how that is translated to a UI is implementation dependent and has >little to do with the protocol. > >> There are a spectrum of solutions. >> On the one extreme there is the scalpel school of >> thought which believes that if something >> is questionable, you get rid of it altogether, >> to put my suggestion on the Master key/ one >> subkey restriction, into perspective. It does >> not mean that I belong to the "scalpel school of >> thought". Nor do I profess such a proposed solution >> as a religion... I could care less what the adopted >> solution is, as long as it addresses the root of >> the problem to my satisfaction. > >As I have already stated, removing subkeys is out of scope. > >> David Shaw's patch, does not solve the problem. > >Can you please show an example where David's patch does not work? >In particular, the approach where the master key and subkey cross-sign >each other seems to protect against all the attacks you've proposed so >far... The case where Alice does not know Bob's master key is a WoT >issue and has nothing to do with subkeys -- the subkey issue is knowing >what master key a subkey belongs to. > >> Why shouldn't subkeys be regarded like any other >> keys. What applies to key, should apply to them >> too. > >In what way are subkeys not regarded like master keys? > >> my 2c >> >> Best Regards >> >> Imad R. Faiad > >-derek > >> On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: >> >> > >> >> >I am amazed that this thread is still running several weeks >> >> after you >> >> >started it, with virtually every response refuting your arguments... >> >> > >> >> And what amazes me, is that you have yet to grasp what we are >> >> talking about! Please re-read the thread, some issues have >> >> been addressed. I sincerely hope that you re-read each and >> >> every message in that thread, because, you are taylor made >> >> for the kind of attacks which can be inflicted to your OpenPGP keys. >> > >> >I've read all the messages. Your request that subkey capability be >> >essentially removed has been rejected by all of them. >> > >> >> >RFC 2440 was published five years ago. I look forward to your draft >> >> >removing multiple subkey capability from it. >> >> I am no paper pusher, and do not have the funding or >> >> time/ability to publish RFC's >> > >> >So I guess this thread is at an end then, with the capability >> >remaining. -----BEGIN PGP SIGNATURE----- Version: 8.0.2irf Comment: KeyID: 0xBCC31718833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBPwHP/LzDFxiDPxutAQJMwQf/UNKORxZfDApb5sZWItwkl7bkvJEkOECh SphQ5B5+YWOdm6zjWaK0GKISA7LIwsrOBIWZ7VEpbNHZznbyHMa7pM9iedy3s0p4 29twTgSf7XEGBX0GuJSvsgt8Oh1aJoLQYGXUWS+GJ7rqPzjFuXQKv6h6+fvWMNzf At+9M49H+zrAGFaiWWWX4gErpV74XmaZS63ARyro0taWTHlJY1Flm9OPhbGsA4kQ undI200hv1Z1f4zfCfGqNeyknRQz5dRqQnJ6D1ZwUu1fPtHGCsAaVmL9Mf+kGZ2Q 3gSI0hnYH3MhZWXgMFc1cYxgIhiFqbn/BDLS0isS/9EjG5GGWLJ0qw== =cDhw -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61G07FK066320 for ; Tue, 1 Jul 2003 09:00:07 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61G07Fa066319 for ietf-openpgp-bks; Tue, 1 Jul 2003 09:00:07 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61G03FK066296 for ; Tue, 1 Jul 2003 09:00:04 -0700 (PDT) (envelope-from warlord@MIT.EDU) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61FxoKl024580; Tue, 1 Jul 2003 11:59:59 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.12.4/8.9.2) with ESMTP id h61FvEjO018614; Tue, 1 Jul 2003 11:57:16 -0400 (EDT) Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) ) by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id h61FvDU8017556; Tue, 1 Jul 2003 11:57:14 -0400 (EDT) Received: (from warlord@localhost) by kikki.mit.edu (8.12.9) id h61FvDY5026607; Tue, 1 Jul 2003 11:57:13 -0400 (EDT) To: "Imad R. Faiad" Cc: ietf-openpgp@imc.org, Ian Brown From: Derek Atkins Subject: Re: Suggestion for the signing subkey problem References: <047b01c33e89$fd852930$39632352@happy> Date: 01 Jul 2003 11:57:13 -0400 In-Reply-To: Message-ID: Lines: 126 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ok, putting my chair hat on. Removing subkeys from 2440bis is OUT OF SCOPE. Fixing security problems with subkeys is IN SCOPE. The goal of 2440bis is to fix security and interop issues, not remove functionality just because some people have minimalist views. While minimalism is a virtue, it (like all things) should be applied in moderation. Having said that, and taking my chair hat off.... "Imad R. Faiad" writes: > 9) She sends a message to Bob, which > is at least signed with the signing > subkey of Alice's fake key. Does > the same with Alice using the signing > subkey in Bob's fake key. Except there is no subkey-signature from the signing subkey on the fake-Alice master key, so Bob wont accept it as a valid subkey. > 10) Alice and Bob thinking that the other > party must have generated yet another > subkey update their copy from the servers. Except they wont think this, because the subkey wont validate on Eve's replacement keys. > 11) In both cases the message authenticates, > giving credence to the respective fake keys. > 12) In the worst case scenario, Alice > and Bob, will start using the other's > fake key, while each is ignorant > that the other party is using his fake > key. Since, Eve is in the middle, > decrypting the messages, then > re-encrypting and forwarding them to > the other party. Well, first, if Alice and Bob have signed each other's master key, then they wont use the fake keys. > The above sounds implausible to you? It sounds implausible in the face of a real WoT between Alice and Bob. It also sounds implausible once Alice and Bob have keys in the local keyright. It is certainly plausible on a first-contact basis without a real WoT. I will note that UI issues are out of scope here. The UI issue is an implementation issue and has nothing to do with interop. The purpose of 2440bis is to fix security and interop problems; how that is translated to a UI is implementation dependent and has little to do with the protocol. > There are a spectrum of solutions. > On the one extreme there is the scalpel school of > thought which believes that if something > is questionable, you get rid of it altogether, > to put my suggestion on the Master key/ one > subkey restriction, into perspective. It does > not mean that I belong to the "scalpel school of > thought". Nor do I profess such a proposed solution > as a religion... I could care less what the adopted > solution is, as long as it addresses the root of > the problem to my satisfaction. As I have already stated, removing subkeys is out of scope. > David Shaw's patch, does not solve the problem. Can you please show an example where David's patch does not work? In particular, the approach where the master key and subkey cross-sign each other seems to protect against all the attacks you've proposed so far... The case where Alice does not know Bob's master key is a WoT issue and has nothing to do with subkeys -- the subkey issue is knowing what master key a subkey belongs to. > Why shouldn't subkeys be regarded like any other > keys. What applies to key, should apply to them > too. In what way are subkeys not regarded like master keys? > my 2c > > Best Regards > > Imad R. Faiad -derek > On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: > > > > >> >I am amazed that this thread is still running several weeks > >> after you > >> >started it, with virtually every response refuting your arguments... > >> > > >> And what amazes me, is that you have yet to grasp what we are > >> talking about! Please re-read the thread, some issues have > >> been addressed. I sincerely hope that you re-read each and > >> every message in that thread, because, you are taylor made > >> for the kind of attacks which can be inflicted to your OpenPGP keys. > > > >I've read all the messages. Your request that subkey capability be > >essentially removed has been rejected by all of them. > > > >> >RFC 2440 was published five years ago. I look forward to your draft > >> >removing multiple subkey capability from it. > >> I am no paper pusher, and do not have the funding or > >> time/ability to publish RFC's > > > >So I guess this thread is at an end then, with the capability remaining. > > > > > > > -- Derek Atkins 617-623-3745 derek@ihtfp.com www.ihtfp.com Computer and Internet Security Consultant Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61EkCFK058673 for ; Tue, 1 Jul 2003 07:46:12 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h61EkC9p058672 for ietf-openpgp-bks; Tue, 1 Jul 2003 07:46:12 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from lake.cyberia.net.lb (lake.cyberia.net.lb [195.112.195.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h61Ek9FK058655 for ; Tue, 1 Jul 2003 07:46:10 -0700 (PDT) (envelope-from matic@cyberia.net.lb) Received: from ppp-07-23.cyberia.net.lb ([195.112.205.121]) by lake.cyberia.net.lb with SMTP id <20030701143549.GBRD9885.lake@ppp-07-23.cyberia.net.lb>; Tue, 1 Jul 2003 17:35:49 +0300 From: "Imad R. Faiad" To: ietf-openpgp@imc.org Cc: Ian Brown Subject: Re: Suggestion for the signing subkey problem Date: Tue, 01 Jul 2003 16:45:51 +0200 Message-ID: References: <047b01c33e89$fd852930$39632352@happy> In-Reply-To: <047b01c33e89$fd852930$39632352@happy> X-Mailer: Forte Agent 1.93/32.576 English (American) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h61EkBFK058668 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Ian, Alice and Bob use OpenPGP to securely communicate with each other. They both are prolific with their use of subkeys for signing and encryption. 1) Eve obtains Alice's public key. 2) Generates a Master Key with as many of the attributes as Alice's master key. 3) She then extracts all the public subkey which are Alice's key and binds them to the Master Key generated in 1). 4) She generates a signing subkey. 5) She then generates an encryption subkey, in such a way so that it will be the most likely one to be used by an OpenPGP implementation. 6) She performs steps 1) through 5), with Bob's key in mind. 7) Both fake keys are then submitted to the keyserver. 8) She sit in the middle intercepting and forwarding Alice's messages to Bob and vise versa. 9) She sends a message to Bob, which is at least signed with the signing subkey of Alice's fake key. Does the same with Alice using the signing subkey in Bob's fake key. 10) Alice and Bob thinking that the other party must have generated yet another subkey update their copy from the servers. 11) In both cases the message authenticates, giving credence to the respective fake keys. 12) In the worst case scenario, Alice and Bob, will start using the other's fake key, while each is ignorant that the other party is using his fake key. Since, Eve is in the middle, decrypting the messages, then re-encrypting and forwarding them to the other party. I know that the above may not be the best. But, I am sure, that someone, with better skills than mine, can refine, or come up with one which is a lot more effective than the above. The above sounds implausible to you? Think again, while you think that you know what you are doing, most OpenPGP users don't, so don't trust that they do. No fool is going to attack the cryptographic aspect of OpenPGP. Subkeys, used incorrectly, gives yet another avenue for a would be attacker, to exploit the vulnerabilities of the user. Please read this:- http://home.earthlink.net/~cortana/johnny.pdf The users are finding hard to understand the simple aspects of OpenPGP. The user interface has yet to evolve to present such simple aspects to the user in an easily understood manner. I wish that someone from say the PGP team, can comment on the impact of the prolific use of subkeys on the user interface of their software. OpenPGP is not a Diffie-Hellman key exchange protocol, people are in the middle of it, and they do err... Now, which you do you prefer, more bells and whistles, which will be mis-understood, and mis-used, or less which is better understood, and more likely to be used in a more idiot proof manner. There are a spectrum of solutions. On the one extreme there is the scalpel school of thought which believes that if something is questionable, you get rid of it altogether, to put my suggestion on the Master key/ one subkey restriction, into perspective. It does not mean that I belong to the "scalpel school of thought". Nor do I profess such a proposed solution as a religion... I could care less what the adopted solution is, as long as it addresses the root of the problem to my satisfaction. David Shaw's patch, does not solve the problem. Why shouldn't subkeys be regarded like any other keys. What applies to key, should apply to them too. my 2c Best Regards Imad R. Faiad On Sun, 29 Jun 2003 23:01:26 +0100, you wrote: > >> >I am amazed that this thread is still running several weeks >> after you >> >started it, with virtually every response refuting your arguments... >> > >> And what amazes me, is that you have yet to grasp what we are >> talking about! Please re-read the thread, some issues have >> been addressed. I sincerely hope that you re-read each and >> every message in that thread, because, you are taylor made >> for the kind of attacks which can be inflicted to your OpenPGP keys. > >I've read all the messages. Your request that subkey capability be >essentially removed has been rejected by all of them. > >> >RFC 2440 was published five years ago. I look forward to your draft >> >removing multiple subkey capability from it. >> I am no paper pusher, and do not have the funding or >> time/ability to publish RFC's > >So I guess this thread is at an end then, with the capability remaining. > > -----BEGIN PGP SIGNATURE----- Version: 8.0.2irf Comment: KeyID: 0xBCC31718833F1BAD Comment: Fingerprint: 75CD 96A7 8ABB F87E 9390 5FD7 2A88 4F45 iQEVAwUBPwGdvrzDFxiDPxutAQKy3gf/Vt7ZfERneXijPcN2LqvxKQXKG7QO44R/ Yh7jKigtTVU2MYNV5/htjaFXtg4pdL/syndT4uq4o5SzfenXK1zzgQFgesZrhakw B8JzHzhWibDJIiURKnSJgaxoxPASkyhaAPzcE8Z/d1oZexXhRhqbQw3Hlrtrn3+g zt/ZrnjukYMkPUYGKuSWmLI7ps8A5Hd4XWjmBGh+hV2kFUV6S3q1Du65zmWSvvdX h1FkQjCc5xczkBcmoVUP0hyMgUG7p7V7F65sX8BePTh2HB/sVd6gASUDjIERtd2k EXcP1ipt4xeoCpxGv5WcRYyJBPaelYbZzumxw3gbeGy7oV8sb7DBig== =Tfpn -----END PGP SIGNATURE----- Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h617vUFK019713 for ; Tue, 1 Jul 2003 00:57:30 -0700 (PDT) (envelope-from owner-ietf-openpgp@mail.imc.org) Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h617vUYE019710 for ietf-openpgp-bks; Tue, 1 Jul 2003 00:57:30 -0700 (PDT) X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-openpgp@mail.imc.org using -f Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h617vTFK019698 for ; Tue, 1 Jul 2003 00:57:29 -0700 (PDT) (envelope-from jon@callas.org) Received: from [63.73.97.182] (63.73.97.165) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.2) for ; Tue, 1 Jul 2003 00:57:25 -0700 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Tue, 01 Jul 2003 00:57:29 -0700 Subject: Re: key flag for authentication From: Jon Callas To: OpenPGP Message-ID: In-Reply-To: <003901c33356$4e3e0fc0$c23fa8c0@transarc.ibm.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Is there a consensus for this? I'm happy with anything, myself. Jon