From owner-ietf-openpgp@mail.imc.org Sat Apr 1 05:52:42 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08170 for ; Sat, 1 Apr 2000 05:52:42 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA12203 for ietf-openpgp-bks; Sat, 1 Apr 2000 02:35:36 -0800 (PST) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12198 for ; Sat, 1 Apr 2000 02:35:35 -0800 (PST) Received: from laptop.sobolev.rhein.de (dialup14.ip.lu [208.161.253.14]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id MAA20454; Sat, 1 Apr 2000 12:37:37 +0200 (CEST) Received: by laptop.sobolev.rhein.de (Postfix, from userid 1000) id 5A9C0106F; Sat, 1 Apr 2000 11:14:56 +0200 (CEST) Date: Sat, 1 Apr 2000 11:14:54 +0200 From: Thomas Roessler To: Jon Callas Cc: Ian Bell , ietf-openpgp@imc.org Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Message-ID: <20000401111453.A660@laptop.sobolev.rhein.de> Mail-Followup-To: Jon Callas , Ian Bell , ietf-openpgp@imc.org References: <20000329192904.B12300@sobolev.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.11i In-Reply-To: ; from jon@callas.org on Fri, Mar 31, 2000 at 03:47:56PM -0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-31 15:47:56 -0800, Jon Callas wrote: > So, popping back to your questions, no, we have to have > binary mode signatures, or else PGP/MIME can't sign a > binary file cross-platform. Beg your pardon? What PGP/MIME does is converting binary data to a canonical text representation which matches MIME's and OpenPGP's idea of canonical text. That is, with PGP/MIME (or any other signature standard based on RFC 1847), all you have to look at are signatures of textual data. MIME does the conversion for you. > If all parties are using the same rules of what text > is, then it doesn't matter what mode you use, as long > as you use the same mode. If you want to cross a > text-rule boundary, you have to use the right mode. Right. -- http://www.guug.de/~roessler/ From owner-ietf-openpgp@mail.imc.org Mon Apr 3 06:36:09 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15830 for ; Mon, 3 Apr 2000 06:36:08 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA10589 for ietf-openpgp-bks; Mon, 3 Apr 2000 03:02:28 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10585 for ; Mon, 3 Apr 2000 03:02:26 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA24664; Mon, 3 Apr 2000 11:05:15 +0100 (BST) Message-ID: <8t8eNGBNxG64IAkC@turnpike.com> Date: Mon, 3 Apr 2000 11:02:53 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. References: <20000329192904.B12300@sobolev.rhein.de> <20000401111453.A660@laptop.sobolev.rhein.de> In-Reply-To: <20000401111453.A660@laptop.sobolev.rhein.de> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Mailer: Turnpike Integrated Version 5.00 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 1 Apr 2000, Thomas Roessler wrote: >On 2000-03-31 15:47:56 -0800, Jon Callas wrote: > >> So, popping back to your questions, no, we have to have >> binary mode signatures, or else PGP/MIME can't sign a >> binary file cross-platform. > >Beg your pardon? What PGP/MIME does is converting binary >data to a canonical text representation which matches >MIME's and OpenPGP's idea of canonical text. That is, >with PGP/MIME (or any other signature standard based on >RFC 1847), all you have to look at are signatures of >textual data. MIME does the conversion for you. Yes, and unless there are absolutely no inter-operability problems arising from the different modes of signing MIME messages, the openPGP/MIME draft should say "MUST use text-mode signatures", not "SHOULD NOT use binary-mode signatures" as I previously suggested. -- Ian Bell T U R N P I K E Ltd From owner-ietf-openpgp@mail.imc.org Tue Apr 4 15:04:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12695 for ; Tue, 4 Apr 2000 15:04:05 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA02512 for ietf-openpgp-bks; Tue, 4 Apr 2000 11:25:43 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02508 for ; Tue, 4 Apr 2000 11:25:41 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id LAA31444; Tue, 4 Apr 2000 11:29:13 -0700 Date: Tue, 4 Apr 2000 11:29:13 -0700 Message-Id: <200004041829.LAA31444@finney.org> To: ietf-openpgp@imc.org, wk@gnupg.org Subject: Re: Return to MDC packet discussion Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch wrote: > > 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15) > > > Unlike the Symmetrically Encrypted Data Packet, no special CFB > > resynchronization is done after encrypting this prefix data. > > Good. > > This proposal is fine with me. To implement this we have to add > feature flags to the public keys or choose an implicit way to decide > when a tag-15 packet should be used or is expected. Using cipher > algorithms with a blocklength other the 64 bit should still work > as an implicit criteria. Due to our long corporate lead times for testing and quality assurance I would like to incorporate this feature on at least a read-only basis for the next release of PGP, which will be in mid to late summer. By making sure we can read the integrity protected packets in our next version, which will be v7.0, we will be able to start using them that much sooner. In implementing this I realized that the proposed tag numbers were already being used in earlier versions of PGP. I would like to use packet tag numbers 18 and 19 for the integrity protected encrypted packet, and the MDC packet, respectively. The suggested draft language below is the same as in my previous message, but with the tag numbers updated. Hal Finney PGP.COM ============ 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 18) The Symmetrically Encrypted Integrity Protected Data packet contains data encrypted with a symmetric-key algorithm and protected against modification by the SHA-1 hash algorithm. When it has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets). The last such decrypted packet must be a Modification Detection Code packet. The body of this packet consists of: - A one-octet version number. The only currently defined value is 1. - Encrypted data, the output of the selected symmetric-key cipher operating in Cipher Feedback mode with shift amount equal to the block size of the cipher (CFB-n where n is the block size). The symmetric cipher used MUST be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data Packet. In either case, the cipher algorithm octet is prefixed to the session key before it is encrypted. The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes an octet string to the data before it is encrypted. The length of the octet string equals the block size of the cipher in octets, plus two. The first octets in the group, of length equal to the block size of the cipher, are random; the last two octets are each copies of their 2nd preceding octet. For example, with a cipher whose block size is 128 bits or 16 octets, the prefix data will contain 16 random octets, then two more octets, which are copies of the 15th and 16th octets, respectivelly. Unlike the Symmetrically Encrypted Data Packet, no special CFB resynchronization is done after encrypting this prefix data. The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. The plaintext of the data to be encrypted is passed through the SHA-1 hash function, and the result of the hash is appended to the plaintext in a Modification Detection Code packet. Specifically, the input to the hash function does not include the prefix data described above; it includes all of the plaintext, and then also includes two octets of values 0xD0, 0x14. These represent the encoding of a Modification Detection Code packet tag and length field of 20 octets. The resulting hash value is stored in a Modification Detection Code packet which MUST use the two octet encoding just given to represent its tag and length field. The body of the MDC packet is the 20 octet output of the SHA-1 hash. The Modification Detection Code packet is appended to the plaintext and encrypted along with the plaintext using the same CFB context. During decryption, the plaintext data should be hashed with SHA-1, not including the prefix data but including the packet tag and length field of the Modification Detection Code packet. The body of the MDC packet, upon decryption, should be compared with the result of the SHA-1 hash. Any difference in hash values is an indication that the message has been modified and SHOULD be reported to the user. Likewise, the absence of an MDC packet, or an MDC packet in any position other than the end of the plaintext, also represent message modifications and SHOULD also be reported. Note: future designs of new versions of this packet should consider rollback attacks since it will be possible for an attacker to change the version back to 1. 5.Y Modification Detection Code Packet (Tag 19) The Modification Detection Code packet contains a SHA-1 hash of plaintext data which is used to detect message modification. It is only used in the context of a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data which is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place. A Modification Detection Code packet MUST have a length of 20 octets. The body of this packet consists of: - A 20-octet SHA-1 hash of the preceding plaintext data of the Symmetrically Encrypted Integrity Protected Data packet, not including prefix data but including the tag and length byte of the Modification Detection Code packet. Note that the Modification Detection Code packet MUST always use a new-format encoding of the packet tag, and a one-octet encoding of the packet length. (These requirements are already imposed by the rules for tag and length encoding.) From owner-ietf-openpgp@mail.imc.org Wed Apr 5 02:28:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06499 for ; Wed, 5 Apr 2000 02:28:15 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA09635 for ietf-openpgp-bks; Tue, 4 Apr 2000 23:00:15 -0700 (PDT) Received: from thetis.deor.org (root@thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09631 for ; Tue, 4 Apr 2000 23:00:14 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id XAA25709 for ; Tue, 4 Apr 2000 23:02:58 -0700 Date: Tue, 4 Apr 2000 23:02:51 -0700 (PDT) From: "L. Sassaman" To: ietf-openpgp@imc.org Subject: 5.2.3.16. Key server preferences Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, While reading over the description of the Key server preferences signature subpacket (5.2.3.17 in the current draft), a possible abuse of this option occurred to me. I would like to suggest that the wording in the draft be modified to say: "When valid revocations of signatures made on a key are submitted to a key server, implementations that honor subpacket 23 MUST allow the signature to be revoked, regardless of the value of this packet" Or something to that effect... the reasons here are obvious. - --Len. __ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1d (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE46tcSPYrxsgmsCmoRAtfZAKD5CHMt0dwTXsKIIVMMMIy68y7uUgCeNlJQ hELlxWLPnxhmjF5mtcrgia8= =u6oK -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Apr 5 03:22:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06799 for ; Wed, 5 Apr 2000 03:22:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA14482 for ietf-openpgp-bks; Wed, 5 Apr 2000 00:05:05 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14473 for ; Wed, 5 Apr 2000 00:05:03 -0700 (PDT) Received: from [63.73.97.180] (63.73.97.180) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 5 Apr 2000 00:07:59 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: Date: Wed, 5 Apr 2000 00:07:17 -0700 To: "L. Sassaman" , ietf-openpgp@imc.org From: Jon Callas Subject: Re: 5.2.3.16. Key server preferences Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:02 PM -0700 4/4/00, L. Sassaman wrote: >While reading over the description of the Key server preferences signature >subpacket (5.2.3.17 in the current draft), a possible abuse of this option >occurred to me. I would like to suggest that the wording in the draft be >modified to say: > >"When valid revocations of signatures made on a key are submitted to a key >server, implementations that honor subpacket 23 MUST allow the signature to >be revoked, regardless of the value of this packet" > >Or something to that effect... the reasons here are obvious. > What are the obvious reasons? And what's the obvious abuse? The purpose of this packet is so that a key can say, "Here's where you can get the most up-to-date version of me." Or perhaps if you prefer, the key's owner is saying "here's where you can get the most up-to-date version of this key." There are other reasonable uses, like including it in a signature so you can find the key that signed it. Like all signed statements, you shouldn't automatically treat them like gospel -- remember, any idiot can sign anything. But that's the abuse? Jon From owner-ietf-openpgp@mail.imc.org Wed Apr 5 04:11:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07087 for ; Wed, 5 Apr 2000 04:11:56 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA15898 for ietf-openpgp-bks; Wed, 5 Apr 2000 00:41:11 -0700 (PDT) Received: from thetis.deor.org (root@thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA15894 for ; Wed, 5 Apr 2000 00:41:09 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA26883; Wed, 5 Apr 2000 00:44:04 -0700 Date: Wed, 5 Apr 2000 00:43:51 -0700 (PDT) From: "L. Sassaman" To: Jon Callas cc: ietf-openpgp@imc.org Subject: Re: 5.2.3.16. Key server preferences In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 5 Apr 2000, Jon Callas wrote: > > What are the obvious reasons? And what's the obvious abuse? > > The purpose of this packet is so that a key can say, "Here's where you can > get the most up-to-date version of me." Or perhaps if you prefer, the key's No, that's what "5.2.3.18.Preferred key server" (in the current draft; 5.2.3.17 in the RFC) is for. What I am talking about is subpacket 23: 5.2.3.17. Key server preferences (N octets of flags) This is a list of flags that indicate preferences that the key holder has about how the key is handled on a key server. All undefined flags MUST be zero. First octet: 0x80 = No-modify the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server. This is found only on a self-signature. - -- If I wish to revoke a signature on a key, I am doing so because I no longer trust that key. There could be cases where the owner of the key does not wish me to revoke said signature. I should still be able to revoke it; in this case the wishes of the signer outweigh the wishes of the key owner, in my opinion. If someone has set me as a trusted introducer, I would not want them to treat keys on which I have revoked my signature as valid. That would defeat the point of the revocation (since the revocation would not be present without consent of the key owner, in the current draft). - --Len. __ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1d (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE46u7CPYrxsgmsCmoRAuX/AKDuFpIB9ELDa2uZYhy2B5WGsv7lPgCgzo3n +TkexleQPrOy+dyC+BvdId8= =ZG/Z -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Wed Apr 5 10:58:34 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11064 for ; Wed, 5 Apr 2000 10:58:33 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA00381 for ietf-openpgp-bks; Wed, 5 Apr 2000 07:33:19 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00375 for ; Wed, 5 Apr 2000 07:33:18 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12cr3Z-00063H-00; Wed, 5 Apr 2000 16:45:21 +0200 Date: Wed, 5 Apr 2000 16:45:21 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: 5.2.3.16. Key server preferences Message-ID: <20000405164521.P18423@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: ; from rabbi@quickie.net on Wed, Apr 05, 2000 at 12:43:51AM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Wed, 5 Apr 2000, L. Sassaman wrote: > longer trust that key. There could be cases where the owner of the key > does not wish me to revoke said signature. I should still be able to > revoke it; in this case the wishes of the signer outweigh the wishes of Good point. We should allow for this but I don't see a reason to change the specs. The keyserver admin can do this (using automated tools of course). Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de From owner-ietf-openpgp@mail.imc.org Wed Apr 5 11:11:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11065 for ; Wed, 5 Apr 2000 10:58:34 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id HAA00255 for ietf-openpgp-bks; Wed, 5 Apr 2000 07:27:16 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00250 for ; Wed, 5 Apr 2000 07:27:13 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12cqxg-000639-00; Wed, 5 Apr 2000 16:39:16 +0200 Date: Wed, 5 Apr 2000 16:39:16 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Return to MDC packet discussion Message-ID: <20000405163916.O18423@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200004041829.LAA31444@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <200004041829.LAA31444@finney.org>; from hal@finney.org on Tue, Apr 04, 2000 at 11:29:13AM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Tue, 4 Apr 2000, hal@finney.org wrote: > Due to our long corporate lead times for testing and quality assurance I > would like to incorporate this feature on at least a read-only basis for > the next release of PGP, which will be in mid to late summer. By making Okay, I'll implement the read-write in GnuPG within the next few weeks. > numbers 18 and 19 for the integrity protected encrypted packet, and the No problem. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de From owner-ietf-openpgp@mail.imc.org Wed Apr 5 13:33:07 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13550 for ; Wed, 5 Apr 2000 13:33:07 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02411 for ietf-openpgp-bks; Wed, 5 Apr 2000 10:09:38 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02407 for ; Wed, 5 Apr 2000 10:09:37 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id KAA07376 for ietf-openpgp@imc.org; Wed, 5 Apr 2000 10:13:16 -0700 Date: Wed, 5 Apr 2000 10:13:16 -0700 Message-Id: <200004051713.KAA07376@finney.org> To: ietf-openpgp@imc.org Subject: Re: 5.2.3.16. Key server preferences Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Another thing the keyservers should allow is importing a key revocation packet even if the sender is not able to authenticate himself as knowing the private key. We used to recommend making a key revocation packet at creation time so that the key could be revoked even if the passphrase is forgotten. It would be important for the server to accept the key revocation in this circumstance. (You could argue that since the key revocation packet is signed by the key, that is proof that it comes from the key holder and hence should be accepted under a straighforward reading of the rfc. But then that would imply that all self-sigs from the key holder should be added, and that might not always be his intention.) Hal From owner-ietf-openpgp@mail.imc.org Wed Apr 5 18:56:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17334 for ; Wed, 5 Apr 2000 18:56:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA07254 for ietf-openpgp-bks; Wed, 5 Apr 2000 15:39:03 -0700 (PDT) Received: from thetis.deor.org (root@thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07250 for ; Wed, 5 Apr 2000 15:39:02 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id PAA30537; Wed, 5 Apr 2000 15:42:03 -0700 Date: Wed, 5 Apr 2000 15:41:49 -0700 (PDT) From: "L. Sassaman" To: Werner Koch cc: ietf-openpgp@imc.org, rjh@pgp.com Subject: Re: 5.2.3.16. Key server preferences In-Reply-To: <20000405164521.P18423@djebel.gnupg.de> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 5 Apr 2000, Werner Koch wrote: > Good point. We should allow for this but I don't see a reason to > change the specs. The keyserver admin can do this (using automated > tools of course). > > Werner Actually, Werner, that thought occured to me about 20 minutes after I sent in the post. Technically any automated action by the keyserver would be an action performed by the keyserver admin, so retaining signature revocations would not violate the RFC. - --Len. __ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1d (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE468E7PYrxsgmsCmoRAnNvAKDQSEuPV/BNXtGllqs4PzVgA2hVvQCdHVNI dLgnmY7ZGD6igrlkgkVMw4o= =wext -----END PGP SIGNATURE----- From owner-ietf-openpgp@mail.imc.org Sat Apr 8 22:49:49 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21914 for ; Sat, 8 Apr 2000 22:49:48 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23209 for ietf-openpgp-bks; Sat, 8 Apr 2000 19:30:49 -0700 (PDT) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23205 for ; Sat, 8 Apr 2000 19:30:48 -0700 (PDT) Message-Id: <4.3.2.20000408193009.04ee2100@not-real.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 08 Apr 2000 19:34:22 -0700 To: ietf-openpgp@imc.org From: Paul Hoffman / IMC Subject: Two AES ciphers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For the past few months, there has been much talk of the likelihood that the AES process will come out with two ciphers, not one. This was talked about at the SAAG meeting in Adelaide, and folks from NIST said that this was indeed the current thinking. RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved for AES with 128-bit key" and so on. It might be wise to allocate another three and specify that the actual algorithms used for IDs 7, 8, and 9 (and probably 11, 12, and 13) will be defined by a future RFC. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-openpgp@mail.imc.org Sun Apr 9 17:37:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12621 for ; Sun, 9 Apr 2000 17:37:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04252 for ietf-openpgp-bks; Sun, 9 Apr 2000 14:18:52 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04248 for ; Sun, 9 Apr 2000 14:18:49 -0700 (PDT) Received: from [63.73.97.188] (63.73.97.180) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Sun, 9 Apr 2000 14:22:11 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000405163916.O18423@djebel.gnupg.de> References: <200004041829.LAA31444@finney.org> <20000405163916.O18423@djebel.gnupg.de> Date: Sun, 9 Apr 2000 14:22:04 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: Return to MDC packet discussion Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have a question. Why not use one of the packet numbers reserved for experimental use? That's why they're there. This use is experimental. If no one's going to use them, then why don't I just remove them from the standard? Jon From owner-ietf-openpgp@mail.imc.org Sun Apr 9 18:12:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13306 for ; Sun, 9 Apr 2000 18:12:18 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA04554 for ietf-openpgp-bks; Sun, 9 Apr 2000 14:57:12 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04547; Sun, 9 Apr 2000 14:57:09 -0700 (PDT) Received: from [63.73.97.188] (63.73.97.180) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Sun, 9 Apr 2000 15:00:32 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.3.2.20000408193009.04ee2100@not-real.proper.com> References: <4.3.2.20000408193009.04ee2100@not-real.proper.com> Date: Sun, 9 Apr 2000 14:49:10 -0700 To: Paul Hoffman / IMC , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Two AES ciphers Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:34 PM -0700 4/8/00, Paul Hoffman / IMC wrote: >For the past few months, there has been much talk of the likelihood that >the AES process will come out with two ciphers, not one. This was talked >about at the SAAG meeting in Adelaide, and folks from NIST said that this >was indeed the current thinking. > >RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved >for AES with 128-bit key" and so on. It might be wise to allocate another >three and specify that the actual algorithms used for IDs 7, 8, and 9 (and >probably 11, 12, and 13) will be defined by a future RFC. > I'd prefer to wait, myself. There are a few reasons for it. I'm of two minds about this. Last spring I came out against it in my comments to NIST. There's been talk about it since the first AES conference, but it's only been talk. In the past, the main rationale for more than one AES was that the AES has many goals, and it wasn't clear that one cipher could serve all of those goals. However, the analysis shows that at least three of the five finalists are usable in all contexts, from smart cards to high-performance systems.If the main argument for more than one AES is concern about usability on smart cards (or other limited system -- the 8051 is probably going to be with us always) and big switches, that concern has been addressed. To my mind, the other technical rationale is the "what if it breaks" question. That's a completely different can of worms, though. I think this is the only reasonable reason for more than one algorithm, but it raises a number of algorithms. If you have one, there's no good backup plan. If you have more than one, the odds that you'll have to deal with *some* broken cipher is higher. Ironically, under this argument, I tend to side with notion of redundancy, but I respect the opinions of people who want simplicity, and see their point. (There's a third reason, and that's political. Let's suppose that the technical favorite in NIST were Rijndael. Beyond the amusement value of having a US standard cipher being written by people outside the US, that's pretty much the icing on the cake for the argument that US governmental controls on crypto have merely helped export crypto knowledge. It would therefore behoove them to pick a second AES that they could slap a "Made in USA" sicker on. But I digress.) The third AES conference is next week. I hope this gets addressed there. If they say there that yes, definitely, there will be two algorithms, then so be it. Until NIST says something official, the issue of whether there should be more than one AES is under debate. As you can see, I have mix emotions about the issue. I think it would be high-handed for me to act as if I know what NIST is going to do before they've done it. It short-circuits the debate. If NIST says there's going to be two AES ciphers, it's five minutes of work to add it in. I'm not sending out a revision next week, or the week after. In three to four weeks there may be another 2440bis, if we get the MDC hammered out. If a week after that I have to put out another draft, sure. There's just no reason to do it now. It's not like we might run out of algorithm numbers. Jon From owner-ietf-openpgp@mail.imc.org Sun Apr 9 20:35:31 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15408 for ; Sun, 9 Apr 2000 20:35:30 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05959 for ietf-openpgp-bks; Sun, 9 Apr 2000 17:20:22 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05955 for ; Sun, 9 Apr 2000 17:20:21 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id RAA03084 for ietf-openpgp@imc.org; Sun, 9 Apr 2000 17:24:26 -0700 Date: Sun, 9 Apr 2000 17:24:26 -0700 Message-Id: <200004100024.RAA03084@finney.org> To: ietf-openpgp@imc.org Subject: Re: Two AES ciphers Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon writes: > The third AES conference is next week. I hope this gets addressed there. If > they say there that yes, definitely, there will be two algorithms, then so > be it. I wonder if rather than explicitly picking two, they might use the Miss America strategy: name the winner, but remember the first runner up. In the event the winner is unable to perform her duties (i.e. the cipher is broken) then the runner up steps into her shoes. Same idea as president and vice president. Of course it is a judgement call as to when a cipher is broken. It's probably not going to snap like a brittle twig. Rather, there may be some attack found that makes people a bit uncomfortable. Is that enough to switch or not? It may be a tough call. All in all the two cipher approach seems problematic to me. Hal From owner-ietf-openpgp@mail.imc.org Sun Apr 9 20:37:56 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15435 for ; Sun, 9 Apr 2000 20:37:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA06000 for ietf-openpgp-bks; Sun, 9 Apr 2000 17:23:56 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05996 for ; Sun, 9 Apr 2000 17:23:55 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id RAA03101; Sun, 9 Apr 2000 17:28:01 -0700 Date: Sun, 9 Apr 2000 17:28:01 -0700 Message-Id: <200004100028.RAA03101@finney.org> To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Return to MDC packet discussion Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon writes: > I have a question. Why not use one of the packet numbers reserved for > experimental use? That's why they're there. This use is experimental. > > If no one's going to use them, then why don't I just remove them from the > standard? Actually they are listed (at least in the RFC) as "private or experimental values". I view this as being an indication that these are OK for closed systems where you want to pick a packet number you know won't ever be used by the open implementations, for your own private or experimental purposes. As far as the MDC packet, I don't think it would be appropriate to put it there as it is intended to be a permanent, public addition to the spec. Hal From owner-ietf-openpgp@mail.imc.org Mon Apr 10 05:52:11 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04050 for ; Mon, 10 Apr 2000 05:52:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA07736 for ietf-openpgp-bks; Mon, 10 Apr 2000 02:30:45 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA07731 for ; Mon, 10 Apr 2000 02:30:43 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12eaju-0004eV-00; Mon, 10 Apr 2000 11:44:14 +0200 Date: Mon, 10 Apr 2000 11:44:14 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Return to MDC packet discussion Message-ID: <20000410114414.B31025@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200004041829.LAA31444@finney.org> <20000405163916.O18423@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: ; from jon@callas.org on Sun, Apr 09, 2000 at 02:22:04PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit On Sun, 9 Apr 2000, Jon Callas wrote: > I have a question. Why not use one of the packet numbers reserved for > experimental use? That's why they're there. This use is experimental. I thought we agreed on the the MAC extension so why not use regular packet numbers. We did this for Twofish as well. However it is fine for me to use the experimental numbers. But then we should add some magic numbers to those packets, so that we don't run into problems when another implemenation uses them for another purpose. > If no one's going to use them, then why don't I just remove them from the > standard? Please, don't do that. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@openit.de D-40233 Düsseldorf http://www.openit.de From owner-ietf-openpgp@mail.imc.org Mon Apr 10 11:33:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18229 for ; Mon, 10 Apr 2000 11:33:09 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15802 for ietf-openpgp-bks; Mon, 10 Apr 2000 08:09:40 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15795; Mon, 10 Apr 2000 08:09:36 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA26977; Tue, 11 Apr 2000 03:13:00 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95537958020334>; Tue, 11 Apr 2000 03:13:00 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, jon@callas.org, phoffman@imc.org Subject: Re: Two AES ciphers Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Tue, 11 Apr 2000 03:13:00 (NZST) Message-ID: <95537958020334@kahu.cs.auckland.ac.nz> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: >At 7:34 PM -0700 4/8/00, Paul Hoffman / IMC wrote: >>For the past few months, there has been much talk of the likelihood that >>the AES process will come out with two ciphers, not one. This was talked >>about at the SAAG meeting in Adelaide, and folks from NIST said that this >>was indeed the current thinking. >> >>RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved >>for AES with 128-bit key" and so on. It might be wise to allocate another >>three and specify that the actual algorithms used for IDs 7, 8, and 9 (and >>probably 11, 12, and 13) will be defined by a future RFC. > >I'm of two minds about this. Since we're listing reasons for having two AES', here's mine. At RSA2K, people were making various bets (in some cases rather nontrivial ones) about the eventual AES. Eric Young and myself were both of the opinion that there'd be two AES', the main one and a spare in case the other one breaks down. Since neither of us are betting types, I proposed that if I was wrong I'd wear a t-shirt which said "Eric was wrong", whereupon he very graciously offered to wear a shirt which said "Peter was wrong". Because of this I'm rather banking on there being two AES'. This is a somewhat lesser reason than the ones which Jon has offered, but it's valid nonetheless. Peter. From owner-ietf-openpgp@mail.imc.org Mon Apr 10 13:49:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27575 for ; Mon, 10 Apr 2000 13:49:42 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA18560 for ietf-openpgp-bks; Mon, 10 Apr 2000 10:22:00 -0700 (PDT) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18550; Mon, 10 Apr 2000 10:21:55 -0700 (PDT) Message-Id: <4.3.2.20000410101638.00be3ee0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 10 Apr 2000 10:26:05 -0700 To: Jon Callas , ietf-openpgp@imc.org From: Paul Hoffman / IMC Subject: Re: Two AES ciphers In-Reply-To: References: <4.3.2.20000408193009.04ee2100@not-real.proper.com> <4.3.2.20000408193009.04ee2100@not-real.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 02:49 PM 4/9/00 -0700, Jon Callas wrote: >I'd prefer to wait, myself. As long as you are willing to simultaneously hold up progression of 2440bis, that's good thinking. However, I didn't want to assume that timing. >If NIST says there's going to be two AES ciphers, it's five minutes of work >to add it in. I'm not sending out a revision next week, or the week after. >In three to four weeks there may be another 2440bis, if we get the MDC >hammered out. If a week after that I have to put out another draft, sure. >There's just no reason to do it now. It's not like we might run out of >algorithm numbers. The problem is that NIST probably won't decide until September (or whenever they actually announce the winner/winners). They have explicitly said that they are going to take the one/two discussion that happens at the upcoming meeting as input for their decision. It would be nice if they say soon whether there will be one or two, but the last I heard they won't decide about one/two before they announce the winner/winners. If we don't get a firm commitment on one/two soon, then the OpenPGP WG needs to think about what we want to do about progressing 2440bis before the AES announcement. --Paul Hoffman, Director --Internet Mail Consortium From owner-ietf-openpgp@mail.imc.org Fri Apr 21 06:59:10 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11613 for ; Fri, 21 Apr 2000 06:59:10 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA28239 for ietf-openpgp-bks; Fri, 21 Apr 2000 03:35:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28235 for ; Fri, 21 Apr 2000 03:34:59 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11265; Fri, 21 Apr 2000 06:39:22 -0400 (EDT) Message-Id: <200004211039.GAA11265@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-mime-01.txt Date: Fri, 21 Apr 2000 06:39:22 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : MIME Security with OpenPGP Author(s) : M. Elkins, D. Del Torto, R. Levien, T. Roessler Filename : draft-ietf-openpgp-mime-01.txt Pages : 12 Date : 20-Apr-00 This document describes how the OpenPGP Message Format [1] can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847 [2]. This draft is being discussed on the 'ietf-openpgp' mailing list. To join the list, send a message to with the single word 'subscribe' in the subject. A web site containing an archive of the list can be found at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-mime-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-mime-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000420104706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-mime-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-mime-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000420104706.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openpgp@mail.imc.org Tue Apr 25 16:49:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25640 for ; Tue, 25 Apr 2000 16:49:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA10571 for ietf-openpgp-bks; Tue, 25 Apr 2000 12:38:22 -0700 (PDT) Received: from teapot27.domain5.bigpond.com (teapot27.domain5.bigpond.com [139.134.5.174]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA10566 for ; Tue, 25 Apr 2000 12:38:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by teapot27.domain5.bigpond.com (NTMail 3.02.13) with ESMTP id ya861872 for ; Wed, 26 Apr 2000 05:31:16 +1000 Received: from DC-56-16.bpb.bigpond.com ([203.40.56.16]) by mail5.bigpond.com (Claudes-Pasteurised-MailRouter V2.7e 9/9778703); 26 Apr 2000 05:31:15 From: "$ Mafiouso" To: "ietf-openpgp@imc.org" Date: Wed, 26 Apr 2000 05:21:07 +1000 Subject: You Gota See! Reply-To: Mafiouso@most-wanted.com Organization: Mafiouso Inc. MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 1 Message-Id: <19311642802327@domain5.bigpond.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit $ Hey! $ Check Out This: http://mafiouso3.tripod.com $ The Best In Everything Mp3s, Pictures, Movies What Ever Your After You Will Find It Here, $ Want a HOT Christina Aguilera Background For Your PC $ Just Goto The Link Below And Right Click, Then `SET AS WALLPAPER. http://mafiouso3.tripod.com/Christina.jpg :) Remember It's Da A Hit! $ Contact Mafiouso At: $ ICQ 53709750 $ Email mafiouso@most-wanted.com Received: by ns.secondary.com (8.9.3/8.9.3) id MAA10571 for ietf-openpgp-bks; Tue, 25 Apr 2000 12:38:22 -0700 (PDT) Received: from teapot27.domain5.bigpond.com (teapot27.domain5.bigpond.com [139.134.5.174]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA10566 for ; Tue, 25 Apr 2000 12:38:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by teapot27.domain5.bigpond.com (NTMail 3.02.13) with ESMTP id ya861872 for ; Wed, 26 Apr 2000 05:31:16 +1000 Received: from DC-56-16.bpb.bigpond.com ([203.40.56.16]) by mail5.bigpond.com (Claudes-Pasteurised-MailRouter V2.7e 9/9778703); 26 Apr 2000 05:31:15 From: "$ Mafiouso" To: "ietf-openpgp@imc.org" Date: Wed, 26 Apr 2000 05:21:07 +1000 Subject: You Gota See! Reply-To: Mafiouso@most-wanted.com Organization: Mafiouso Inc. MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-Priority: 1 Message-Id: <19311642802327@domain5.bigpond.com> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: $ Hey! $ Check Out This: http://mafiouso3.tripod.com $ The Best In Everything Mp3s, Pictures, Movies What Ever Your After You Will Find It Here, $ Want a HOT Christina Aguilera Background For Your PC $ Just Goto The Link Below And Right Click, Then `SET AS WALLPAPER. http://mafiouso3.tripod.com/Christina.jpg :) Remember It's Da A Hit! $ Contact Mafiouso At: $ ICQ 53709750 $ Email mafiouso@most-wanted.com Received: by ns.secondary.com (8.9.3/8.9.3) id DAA28239 for ietf-openpgp-bks; Fri, 21 Apr 2000 03:35:01 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA28235 for ; Fri, 21 Apr 2000 03:34:59 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11265; Fri, 21 Apr 2000 06:39:22 -0400 (EDT) Message-Id: <200004211039.GAA11265@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openpgp@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-openpgp-mime-01.txt Date: Fri, 21 Apr 2000 06:39:22 -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF. Title : MIME Security with OpenPGP Author(s) : M. Elkins, D. Del Torto, R. Levien, T. Roessler Filename : draft-ietf-openpgp-mime-01.txt Pages : 12 Date : 20-Apr-00 This document describes how the OpenPGP Message Format [1] can be used to provide privacy and authentication using the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC1847 [2]. This draft is being discussed on the 'ietf-openpgp' mailing list. To join the list, send a message to with the single word 'subscribe' in the subject. A web site containing an archive of the list can be found at . A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-openpgp-mime-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-openpgp-mime-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000420104706.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-mime-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-mime-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000420104706.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id KAA18560 for ietf-openpgp-bks; Mon, 10 Apr 2000 10:22:00 -0700 (PDT) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA18550; Mon, 10 Apr 2000 10:21:55 -0700 (PDT) Message-Id: <4.3.2.20000410101638.00be3ee0@mail.imc.org> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Mon, 10 Apr 2000 10:26:05 -0700 To: Jon Callas , ietf-openpgp@imc.org From: Paul Hoffman / IMC Subject: Re: Two AES ciphers In-Reply-To: References: <4.3.2.20000408193009.04ee2100@not-real.proper.com> <4.3.2.20000408193009.04ee2100@not-real.proper.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 02:49 PM 4/9/00 -0700, Jon Callas wrote: >I'd prefer to wait, myself. As long as you are willing to simultaneously hold up progression of 2440bis, that's good thinking. However, I didn't want to assume that timing. >If NIST says there's going to be two AES ciphers, it's five minutes of work >to add it in. I'm not sending out a revision next week, or the week after. >In three to four weeks there may be another 2440bis, if we get the MDC >hammered out. If a week after that I have to put out another draft, sure. >There's just no reason to do it now. It's not like we might run out of >algorithm numbers. The problem is that NIST probably won't decide until September (or whenever they actually announce the winner/winners). They have explicitly said that they are going to take the one/two discussion that happens at the upcoming meeting as input for their decision. It would be nice if they say soon whether there will be one or two, but the last I heard they won't decide about one/two before they announce the winner/winners. If we don't get a firm commitment on one/two soon, then the OpenPGP WG needs to think about what we want to do about progressing 2440bis before the AES announcement. --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id IAA15802 for ietf-openpgp-bks; Mon, 10 Apr 2000 08:09:40 -0700 (PDT) Received: from mail.ec.auckland.ac.nz (mail.student.auckland.ac.nz [130.216.35.201]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA15795; Mon, 10 Apr 2000 08:09:36 -0700 (PDT) Received: from kahu.cs.auckland.ac.nz (pgut001@kahu.cs.auckland.ac.nz [130.216.36.13]) by mail.ec.auckland.ac.nz (8.9.3/8.8.6/cs-master) with SMTP id DAA26977; Tue, 11 Apr 2000 03:13:00 +1200 (NZST) (sender pgut001@cs.auckland.ac.nz) Received: by kahu.cs.auckland.ac.nz (relaymail v0.9) id <95537958020334>; Tue, 11 Apr 2000 03:13:00 (NZST) From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: ietf-openpgp@imc.org, jon@callas.org, phoffman@imc.org Subject: Re: Two AES ciphers Reply-To: pgut001@cs.auckland.ac.nz X-Charge-To: pgut001 X-Authenticated: relaymail v0.9 on kahu.cs.auckland.ac.nz Date: Tue, 11 Apr 2000 03:13:00 (NZST) Message-ID: <95537958020334@kahu.cs.auckland.ac.nz> Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon Callas writes: >At 7:34 PM -0700 4/8/00, Paul Hoffman / IMC wrote: >>For the past few months, there has been much talk of the likelihood that >>the AES process will come out with two ciphers, not one. This was talked >>about at the SAAG meeting in Adelaide, and folks from NIST said that this >>was indeed the current thinking. >> >>RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved >>for AES with 128-bit key" and so on. It might be wise to allocate another >>three and specify that the actual algorithms used for IDs 7, 8, and 9 (and >>probably 11, 12, and 13) will be defined by a future RFC. > >I'm of two minds about this. Since we're listing reasons for having two AES', here's mine. At RSA2K, people were making various bets (in some cases rather nontrivial ones) about the eventual AES. Eric Young and myself were both of the opinion that there'd be two AES', the main one and a spare in case the other one breaks down. Since neither of us are betting types, I proposed that if I was wrong I'd wear a t-shirt which said "Eric was wrong", whereupon he very graciously offered to wear a shirt which said "Peter was wrong". Because of this I'm rather banking on there being two AES'. This is a somewhat lesser reason than the ones which Jon has offered, but it's valid nonetheless. Peter. Received: by ns.secondary.com (8.9.3/8.9.3) id CAA07736 for ietf-openpgp-bks; Mon, 10 Apr 2000 02:30:45 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA07731 for ; Mon, 10 Apr 2000 02:30:43 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12eaju-0004eV-00; Mon, 10 Apr 2000 11:44:14 +0200 Date: Mon, 10 Apr 2000 11:44:14 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Return to MDC packet discussion Message-ID: <20000410114414.B31025@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200004041829.LAA31444@finney.org> <20000405163916.O18423@djebel.gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: ; from jon@callas.org on Sun, Apr 09, 2000 at 02:22:04PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sun, 9 Apr 2000, Jon Callas wrote: > I have a question. Why not use one of the packet numbers reserved for > experimental use? That's why they're there. This use is experimental. I thought we agreed on the the MAC extension so why not use regular packet numbers. We did this for Twofish as well. However it is fine for me to use the experimental numbers. But then we should add some magic numbers to those packets, so that we don't run into problems when another implemenation uses them for another purpose. > If no one's going to use them, then why don't I just remove them from the > standard? Please, don't do that. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 239577-0 Birkenstr. 12 email wk@openit.de D-40233 Düsseldorf http://www.openit.de Received: by ns.secondary.com (8.9.3/8.9.3) id RAA06000 for ietf-openpgp-bks; Sun, 9 Apr 2000 17:23:56 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05996 for ; Sun, 9 Apr 2000 17:23:55 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id RAA03101; Sun, 9 Apr 2000 17:28:01 -0700 Date: Sun, 9 Apr 2000 17:28:01 -0700 Message-Id: <200004100028.RAA03101@finney.org> To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: Return to MDC packet discussion Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon writes: > I have a question. Why not use one of the packet numbers reserved for > experimental use? That's why they're there. This use is experimental. > > If no one's going to use them, then why don't I just remove them from the > standard? Actually they are listed (at least in the RFC) as "private or experimental values". I view this as being an indication that these are OK for closed systems where you want to pick a packet number you know won't ever be used by the open implementations, for your own private or experimental purposes. As far as the MDC packet, I don't think it would be appropriate to put it there as it is intended to be a permanent, public addition to the spec. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id RAA05959 for ietf-openpgp-bks; Sun, 9 Apr 2000 17:20:22 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id RAA05955 for ; Sun, 9 Apr 2000 17:20:21 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id RAA03084 for ietf-openpgp@imc.org; Sun, 9 Apr 2000 17:24:26 -0700 Date: Sun, 9 Apr 2000 17:24:26 -0700 Message-Id: <200004100024.RAA03084@finney.org> To: ietf-openpgp@imc.org Subject: Re: Two AES ciphers Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Jon writes: > The third AES conference is next week. I hope this gets addressed there. If > they say there that yes, definitely, there will be two algorithms, then so > be it. I wonder if rather than explicitly picking two, they might use the Miss America strategy: name the winner, but remember the first runner up. In the event the winner is unable to perform her duties (i.e. the cipher is broken) then the runner up steps into her shoes. Same idea as president and vice president. Of course it is a judgement call as to when a cipher is broken. It's probably not going to snap like a brittle twig. Rather, there may be some attack found that makes people a bit uncomfortable. Is that enough to switch or not? It may be a tough call. All in all the two cipher approach seems problematic to me. Hal Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA04554 for ietf-openpgp-bks; Sun, 9 Apr 2000 14:57:12 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04547; Sun, 9 Apr 2000 14:57:09 -0700 (PDT) Received: from [63.73.97.188] (63.73.97.180) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Sun, 9 Apr 2000 15:00:32 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <4.3.2.20000408193009.04ee2100@not-real.proper.com> References: <4.3.2.20000408193009.04ee2100@not-real.proper.com> Date: Sun, 9 Apr 2000 14:49:10 -0700 To: Paul Hoffman / IMC , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Two AES ciphers Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 7:34 PM -0700 4/8/00, Paul Hoffman / IMC wrote: >For the past few months, there has been much talk of the likelihood that >the AES process will come out with two ciphers, not one. This was talked >about at the SAAG meeting in Adelaide, and folks from NIST said that this >was indeed the current thinking. > >RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved >for AES with 128-bit key" and so on. It might be wise to allocate another >three and specify that the actual algorithms used for IDs 7, 8, and 9 (and >probably 11, 12, and 13) will be defined by a future RFC. > I'd prefer to wait, myself. There are a few reasons for it. I'm of two minds about this. Last spring I came out against it in my comments to NIST. There's been talk about it since the first AES conference, but it's only been talk. In the past, the main rationale for more than one AES was that the AES has many goals, and it wasn't clear that one cipher could serve all of those goals. However, the analysis shows that at least three of the five finalists are usable in all contexts, from smart cards to high-performance systems.If the main argument for more than one AES is concern about usability on smart cards (or other limited system -- the 8051 is probably going to be with us always) and big switches, that concern has been addressed. To my mind, the other technical rationale is the "what if it breaks" question. That's a completely different can of worms, though. I think this is the only reasonable reason for more than one algorithm, but it raises a number of algorithms. If you have one, there's no good backup plan. If you have more than one, the odds that you'll have to deal with *some* broken cipher is higher. Ironically, under this argument, I tend to side with notion of redundancy, but I respect the opinions of people who want simplicity, and see their point. (There's a third reason, and that's political. Let's suppose that the technical favorite in NIST were Rijndael. Beyond the amusement value of having a US standard cipher being written by people outside the US, that's pretty much the icing on the cake for the argument that US governmental controls on crypto have merely helped export crypto knowledge. It would therefore behoove them to pick a second AES that they could slap a "Made in USA" sicker on. But I digress.) The third AES conference is next week. I hope this gets addressed there. If they say there that yes, definitely, there will be two algorithms, then so be it. Until NIST says something official, the issue of whether there should be more than one AES is under debate. As you can see, I have mix emotions about the issue. I think it would be high-handed for me to act as if I know what NIST is going to do before they've done it. It short-circuits the debate. If NIST says there's going to be two AES ciphers, it's five minutes of work to add it in. I'm not sending out a revision next week, or the week after. In three to four weeks there may be another 2440bis, if we get the MDC hammered out. If a week after that I have to put out another draft, sure. There's just no reason to do it now. It's not like we might run out of algorithm numbers. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id OAA04252 for ietf-openpgp-bks; Sun, 9 Apr 2000 14:18:52 -0700 (PDT) Received: from merrymeet.com (Merrymeet@merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA04248 for ; Sun, 9 Apr 2000 14:18:49 -0700 (PDT) Received: from [63.73.97.188] (63.73.97.180) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Sun, 9 Apr 2000 14:22:11 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000405163916.O18423@djebel.gnupg.de> References: <200004041829.LAA31444@finney.org> <20000405163916.O18423@djebel.gnupg.de> Date: Sun, 9 Apr 2000 14:22:04 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: Return to MDC packet discussion Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have a question. Why not use one of the packet numbers reserved for experimental use? That's why they're there. This use is experimental. If no one's going to use them, then why don't I just remove them from the standard? Jon Received: by ns.secondary.com (8.9.3/8.9.3) id TAA23209 for ietf-openpgp-bks; Sat, 8 Apr 2000 19:30:49 -0700 (PDT) Received: from laptop.imc.org (ip12.proper.com [165.227.249.12]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA23205 for ; Sat, 8 Apr 2000 19:30:48 -0700 (PDT) Message-Id: <4.3.2.20000408193009.04ee2100@not-real.proper.com> X-Sender: phoffman@mail.imc.org X-Mailer: QUALCOMM Windows Eudora Version 4.3 Date: Sat, 08 Apr 2000 19:34:22 -0700 To: ietf-openpgp@imc.org From: Paul Hoffman / IMC Subject: Two AES ciphers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: For the past few months, there has been much talk of the likelihood that the AES process will come out with two ciphers, not one. This was talked about at the SAAG meeting in Adelaide, and folks from NIST said that this was indeed the current thinking. RFC 2440 and the current 2440bis draft has algorithm IDs that say "Reserved for AES with 128-bit key" and so on. It might be wise to allocate another three and specify that the actual algorithms used for IDs 7, 8, and 9 (and probably 11, 12, and 13) will be defined by a future RFC. --Paul Hoffman, Director --Internet Mail Consortium Received: by ns.secondary.com (8.9.3/8.9.3) id PAA07254 for ietf-openpgp-bks; Wed, 5 Apr 2000 15:39:03 -0700 (PDT) Received: from thetis.deor.org (root@thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA07250 for ; Wed, 5 Apr 2000 15:39:02 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id PAA30537; Wed, 5 Apr 2000 15:42:03 -0700 Date: Wed, 5 Apr 2000 15:41:49 -0700 (PDT) From: "L. Sassaman" To: Werner Koch cc: ietf-openpgp@imc.org, rjh@pgp.com Subject: Re: 5.2.3.16. Key server preferences In-Reply-To: <20000405164521.P18423@djebel.gnupg.de> Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 5 Apr 2000, Werner Koch wrote: > Good point. We should allow for this but I don't see a reason to > change the specs. The keyserver admin can do this (using automated > tools of course). > > Werner Actually, Werner, that thought occured to me about 20 minutes after I sent in the post. Technically any automated action by the keyserver would be an action performed by the keyserver admin, so retaining signature revocations would not violate the RFC. - --Len. __ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1d (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE468E7PYrxsgmsCmoRAnNvAKDQSEuPV/BNXtGllqs4PzVgA2hVvQCdHVNI dLgnmY7ZGD6igrlkgkVMw4o= =wext -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id KAA02411 for ietf-openpgp-bks; Wed, 5 Apr 2000 10:09:38 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA02407 for ; Wed, 5 Apr 2000 10:09:37 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id KAA07376 for ietf-openpgp@imc.org; Wed, 5 Apr 2000 10:13:16 -0700 Date: Wed, 5 Apr 2000 10:13:16 -0700 Message-Id: <200004051713.KAA07376@finney.org> To: ietf-openpgp@imc.org Subject: Re: 5.2.3.16. Key server preferences Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Another thing the keyservers should allow is importing a key revocation packet even if the sender is not able to authenticate himself as knowing the private key. We used to recommend making a key revocation packet at creation time so that the key could be revoked even if the passphrase is forgotten. It would be important for the server to accept the key revocation in this circumstance. (You could argue that since the key revocation packet is signed by the key, that is proof that it comes from the key holder and hence should be accepted under a straighforward reading of the rfc. But then that would imply that all self-sigs from the key holder should be added, and that might not always be his intention.) Hal Received: by ns.secondary.com (8.9.3/8.9.3) id HAA00381 for ietf-openpgp-bks; Wed, 5 Apr 2000 07:33:19 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00375 for ; Wed, 5 Apr 2000 07:33:18 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12cr3Z-00063H-00; Wed, 5 Apr 2000 16:45:21 +0200 Date: Wed, 5 Apr 2000 16:45:21 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: 5.2.3.16. Key server preferences Message-ID: <20000405164521.P18423@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: ; from rabbi@quickie.net on Wed, Apr 05, 2000 at 12:43:51AM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 5 Apr 2000, L. Sassaman wrote: > longer trust that key. There could be cases where the owner of the key > does not wish me to revoke said signature. I should still be able to > revoke it; in this case the wishes of the signer outweigh the wishes of Good point. We should allow for this but I don't see a reason to change the specs. The keyserver admin can do this (using automated tools of course). Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de Received: by ns.secondary.com (8.9.3/8.9.3) id HAA00255 for ietf-openpgp-bks; Wed, 5 Apr 2000 07:27:16 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.gnupg.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id HAA00250 for ; Wed, 5 Apr 2000 07:27:13 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 2.05 #1 (Debian)) id 12cqxg-000639-00; Wed, 5 Apr 2000 16:39:16 +0200 Date: Wed, 5 Apr 2000 16:39:16 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Return to MDC packet discussion Message-ID: <20000405163916.O18423@djebel.gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <200004041829.LAA31444@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.1.8i In-Reply-To: <200004041829.LAA31444@finney.org>; from hal@finney.org on Tue, Apr 04, 2000 at 11:29:13AM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, 4 Apr 2000, hal@finney.org wrote: > Due to our long corporate lead times for testing and quality assurance I > would like to incorporate this feature on at least a read-only basis for > the next release of PGP, which will be in mid to late summer. By making Okay, I'll implement the read-write in GnuPG within the next few weeks. > numbers 18 and 19 for the integrity protected encrypted packet, and the No problem. Werner -- Werner Koch OpenPGP key 621CC013 OpenIT GmbH tel +49 211 465357 Birkenstr. 12 email info@openit.de D-40233 Düsseldorf http://www.openit.de Received: by ns.secondary.com (8.9.3/8.9.3) id AAA15898 for ietf-openpgp-bks; Wed, 5 Apr 2000 00:41:11 -0700 (PDT) Received: from thetis.deor.org (root@thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA15894 for ; Wed, 5 Apr 2000 00:41:09 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id AAA26883; Wed, 5 Apr 2000 00:44:04 -0700 Date: Wed, 5 Apr 2000 00:43:51 -0700 (PDT) From: "L. Sassaman" To: Jon Callas cc: ietf-openpgp@imc.org Subject: Re: 5.2.3.16. Key server preferences In-Reply-To: Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wed, 5 Apr 2000, Jon Callas wrote: > > What are the obvious reasons? And what's the obvious abuse? > > The purpose of this packet is so that a key can say, "Here's where you can > get the most up-to-date version of me." Or perhaps if you prefer, the key's No, that's what "5.2.3.18.Preferred key server" (in the current draft; 5.2.3.17 in the RFC) is for. What I am talking about is subpacket 23: 5.2.3.17. Key server preferences (N octets of flags) This is a list of flags that indicate preferences that the key holder has about how the key is handled on a key server. All undefined flags MUST be zero. First octet: 0x80 = No-modify the key holder requests that this key only be modified or updated by the key holder or an administrator of the key server. This is found only on a self-signature. - -- If I wish to revoke a signature on a key, I am doing so because I no longer trust that key. There could be cases where the owner of the key does not wish me to revoke said signature. I should still be able to revoke it; in this case the wishes of the signer outweigh the wishes of the key owner, in my opinion. If someone has set me as a trusted introducer, I would not want them to treat keys on which I have revoked my signature as valid. That would defeat the point of the revocation (since the revocation would not be present without consent of the key owner, in the current draft). - --Len. __ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1d (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE46u7CPYrxsgmsCmoRAuX/AKDuFpIB9ELDa2uZYhy2B5WGsv7lPgCgzo3n +TkexleQPrOy+dyC+BvdId8= =ZG/Z -----END PGP SIGNATURE----- Received: by ns.secondary.com (8.9.3/8.9.3) id AAA14482 for ietf-openpgp-bks; Wed, 5 Apr 2000 00:05:05 -0700 (PDT) Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA14473 for ; Wed, 5 Apr 2000 00:05:03 -0700 (PDT) Received: from [63.73.97.180] (63.73.97.180) by merrymeet.com with ESMTP (Eudora Internet Mail Server 2.2); Wed, 5 Apr 2000 00:07:59 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: References: Date: Wed, 5 Apr 2000 00:07:17 -0700 To: "L. Sassaman" , ietf-openpgp@imc.org From: Jon Callas Subject: Re: 5.2.3.16. Key server preferences Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:02 PM -0700 4/4/00, L. Sassaman wrote: >While reading over the description of the Key server preferences signature >subpacket (5.2.3.17 in the current draft), a possible abuse of this option >occurred to me. I would like to suggest that the wording in the draft be >modified to say: > >"When valid revocations of signatures made on a key are submitted to a key >server, implementations that honor subpacket 23 MUST allow the signature to >be revoked, regardless of the value of this packet" > >Or something to that effect... the reasons here are obvious. > What are the obvious reasons? And what's the obvious abuse? The purpose of this packet is so that a key can say, "Here's where you can get the most up-to-date version of me." Or perhaps if you prefer, the key's owner is saying "here's where you can get the most up-to-date version of this key." There are other reasonable uses, like including it in a signature so you can find the key that signed it. Like all signed statements, you shouldn't automatically treat them like gospel -- remember, any idiot can sign anything. But that's the abuse? Jon Received: by ns.secondary.com (8.9.3/8.9.3) id XAA09635 for ietf-openpgp-bks; Tue, 4 Apr 2000 23:00:15 -0700 (PDT) Received: from thetis.deor.org (root@thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA09631 for ; Tue, 4 Apr 2000 23:00:14 -0700 (PDT) Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id XAA25709 for ; Tue, 4 Apr 2000 23:02:58 -0700 Date: Tue, 4 Apr 2000 23:02:51 -0700 (PDT) From: "L. Sassaman" To: ietf-openpgp@imc.org Subject: 5.2.3.16. Key server preferences Message-ID: X-AIM: Elom777 X-icq: 10735603 X-No-Archive: yes X-PGP: X-PGP-ID-Fprnt: 0x09AC0A6A 7A1A 407F B1CA 7E4E AE85 E730 3D8A F1B2 09AC 0A6A X-PGP-S: X-PGP-ID-Fprnt-S: 0x3AF92BD0 566B 5CA8 A733 34AA A482 586F 38D9 DBA8 3AF9 2BD0 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks, While reading over the description of the Key server preferences signature subpacket (5.2.3.17 in the current draft), a possible abuse of this option occurred to me. I would like to suggest that the wording in the draft be modified to say: "When valid revocations of signatures made on a key are submitted to a key server, implementations that honor subpacket 23 MUST allow the signature to be revoked, regardless of the value of this packet" Or something to that effect... the reasons here are obvious. - --Len. __ L. Sassaman System Administrator | "All of the chaos Technology Consultant | Makes perfect sense..." icq.. 10735603 | pgp.. finger://ns.quickie.net/rabbi | --Joe Diffie -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1d (GNU/Linux) Comment: OpenPGP Encrypted Email Preferred. iD8DBQE46tcSPYrxsgmsCmoRAtfZAKD5CHMt0dwTXsKIIVMMMIy68y7uUgCeNlJQ hELlxWLPnxhmjF5mtcrgia8= =u6oK -----END PGP SIGNATURE----- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id LAA02512 for ietf-openpgp-bks; Tue, 4 Apr 2000 11:25:43 -0700 (PDT) Received: from finney.org (226-132.adsl2.avtel.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA02508 for ; Tue, 4 Apr 2000 11:25:41 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.8.7/8.8.7) id LAA31444; Tue, 4 Apr 2000 11:29:13 -0700 Date: Tue, 4 Apr 2000 11:29:13 -0700 Message-Id: <200004041829.LAA31444@finney.org> To: ietf-openpgp@imc.org, wk@gnupg.org Subject: Re: Return to MDC packet discussion Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Werner Koch wrote: > > 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 15) > > > Unlike the Symmetrically Encrypted Data Packet, no special CFB > > resynchronization is done after encrypting this prefix data. > > Good. > > This proposal is fine with me. To implement this we have to add > feature flags to the public keys or choose an implicit way to decide > when a tag-15 packet should be used or is expected. Using cipher > algorithms with a blocklength other the 64 bit should still work > as an implicit criteria. Due to our long corporate lead times for testing and quality assurance I would like to incorporate this feature on at least a read-only basis for the next release of PGP, which will be in mid to late summer. By making sure we can read the integrity protected packets in our next version, which will be v7.0, we will be able to start using them that much sooner. In implementing this I realized that the proposed tag numbers were already being used in earlier versions of PGP. I would like to use packet tag numbers 18 and 19 for the integrity protected encrypted packet, and the MDC packet, respectively. The suggested draft language below is the same as in my previous message, but with the tag numbers updated. Hal Finney PGP.COM ============ 5.X. Symmetrically Encrypted Integrity Protected Data Packet (Tag 18) The Symmetrically Encrypted Integrity Protected Data packet contains data encrypted with a symmetric-key algorithm and protected against modification by the SHA-1 hash algorithm. When it has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets). The last such decrypted packet must be a Modification Detection Code packet. The body of this packet consists of: - A one-octet version number. The only currently defined value is 1. - Encrypted data, the output of the selected symmetric-key cipher operating in Cipher Feedback mode with shift amount equal to the block size of the cipher (CFB-n where n is the block size). The symmetric cipher used MUST be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data Packet. In either case, the cipher algorithm octet is prefixed to the session key before it is encrypted. The data is encrypted in CFB mode, with a CFB shift size equal to the cipher's block size. The Initial Vector (IV) is specified as all zeros. Instead of using an IV, OpenPGP prefixes an octet string to the data before it is encrypted. The length of the octet string equals the block size of the cipher in octets, plus two. The first octets in the group, of length equal to the block size of the cipher, are random; the last two octets are each copies of their 2nd preceding octet. For example, with a cipher whose block size is 128 bits or 16 octets, the prefix data will contain 16 random octets, then two more octets, which are copies of the 15th and 16th octets, respectivelly. Unlike the Symmetrically Encrypted Data Packet, no special CFB resynchronization is done after encrypting this prefix data. The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect. The plaintext of the data to be encrypted is passed through the SHA-1 hash function, and the result of the hash is appended to the plaintext in a Modification Detection Code packet. Specifically, the input to the hash function does not include the prefix data described above; it includes all of the plaintext, and then also includes two octets of values 0xD0, 0x14. These represent the encoding of a Modification Detection Code packet tag and length field of 20 octets. The resulting hash value is stored in a Modification Detection Code packet which MUST use the two octet encoding just given to represent its tag and length field. The body of the MDC packet is the 20 octet output of the SHA-1 hash. The Modification Detection Code packet is appended to the plaintext and encrypted along with the plaintext using the same CFB context. During decryption, the plaintext data should be hashed with SHA-1, not including the prefix data but including the packet tag and length field of the Modification Detection Code packet. The body of the MDC packet, upon decryption, should be compared with the result of the SHA-1 hash. Any difference in hash values is an indication that the message has been modified and SHOULD be reported to the user. Likewise, the absence of an MDC packet, or an MDC packet in any position other than the end of the plaintext, also represent message modifications and SHOULD also be reported. Note: future designs of new versions of this packet should consider rollback attacks since it will be possible for an attacker to change the version back to 1. 5.Y Modification Detection Code Packet (Tag 19) The Modification Detection Code packet contains a SHA-1 hash of plaintext data which is used to detect message modification. It is only used in the context of a Symmetrically Encrypted Integrity Protected Data packet. The Modification Detection Code packet MUST be the last packet in the plaintext data which is encrypted in the Symmetrically Encrypted Integrity Protected Data packet, and MUST appear in no other place. A Modification Detection Code packet MUST have a length of 20 octets. The body of this packet consists of: - A 20-octet SHA-1 hash of the preceding plaintext data of the Symmetrically Encrypted Integrity Protected Data packet, not including prefix data but including the tag and length byte of the Modification Detection Code packet. Note that the Modification Detection Code packet MUST always use a new-format encoding of the packet tag, and a one-octet encoding of the packet length. (These requirements are already imposed by the rules for tag and length encoding.) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA10589 for ietf-openpgp-bks; Mon, 3 Apr 2000 03:02:28 -0700 (PDT) Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA10585 for ; Mon, 3 Apr 2000 03:02:26 -0700 (PDT) Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA24664; Mon, 3 Apr 2000 11:05:15 +0100 (BST) Message-ID: <8t8eNGBNxG64IAkC@turnpike.com> Date: Mon, 3 Apr 2000 11:02:53 +0100 To: ietf-openpgp@imc.org From: Ian Bell Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. References: <20000329192904.B12300@sobolev.rhein.de> <20000401111453.A660@laptop.sobolev.rhein.de> In-Reply-To: <20000401111453.A660@laptop.sobolev.rhein.de> MIME-Version: 1.0 Content-Type: text/plain;charset=us-ascii;format=flowed X-Mailer: Turnpike Integrated Version 5.00 M Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Sat, 1 Apr 2000, Thomas Roessler wrote: >On 2000-03-31 15:47:56 -0800, Jon Callas wrote: > >> So, popping back to your questions, no, we have to have >> binary mode signatures, or else PGP/MIME can't sign a >> binary file cross-platform. > >Beg your pardon? What PGP/MIME does is converting binary >data to a canonical text representation which matches >MIME's and OpenPGP's idea of canonical text. That is, >with PGP/MIME (or any other signature standard based on >RFC 1847), all you have to look at are signatures of >textual data. MIME does the conversion for you. Yes, and unless there are absolutely no inter-operability problems arising from the different modes of signing MIME messages, the openPGP/MIME draft should say "MUST use text-mode signatures", not "SHOULD NOT use binary-mode signatures" as I previously suggested. -- Ian Bell T U R N P I K E Ltd Received: by ns.secondary.com (8.9.3/8.9.3) id CAA12203 for ietf-openpgp-bks; Sat, 1 Apr 2000 02:35:36 -0800 (PST) Received: from tcp.ip.lu (tcp.ip.lu [208.161.252.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA12198 for ; Sat, 1 Apr 2000 02:35:35 -0800 (PST) Received: from laptop.sobolev.rhein.de (dialup14.ip.lu [208.161.253.14]) by tcp.ip.lu (8.9.3/8.9.3) with ESMTP id MAA20454; Sat, 1 Apr 2000 12:37:37 +0200 (CEST) Received: by laptop.sobolev.rhein.de (Postfix, from userid 1000) id 5A9C0106F; Sat, 1 Apr 2000 11:14:56 +0200 (CEST) Date: Sat, 1 Apr 2000 11:14:54 +0200 From: Thomas Roessler To: Jon Callas Cc: Ian Bell , ietf-openpgp@imc.org Subject: Re: PGP/MIME interop testing: Very first steps towards a test suite. Message-ID: <20000401111453.A660@laptop.sobolev.rhein.de> Mail-Followup-To: Jon Callas , Ian Bell , ietf-openpgp@imc.org References: <20000329192904.B12300@sobolev.rhein.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.1.11i In-Reply-To: ; from jon@callas.org on Fri, Mar 31, 2000 at 03:47:56PM -0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-03-31 15:47:56 -0800, Jon Callas wrote: > So, popping back to your questions, no, we have to have > binary mode signatures, or else PGP/MIME can't sign a > binary file cross-platform. Beg your pardon? What PGP/MIME does is converting binary data to a canonical text representation which matches MIME's and OpenPGP's idea of canonical text. That is, with PGP/MIME (or any other signature standard based on RFC 1847), all you have to look at are signatures of textual data. MIME does the conversion for you. > If all parties are using the same rules of what text > is, then it doesn't matter what mode you use, as long > as you use the same mode. If you want to cross a > text-rule boundary, you have to use the right mode. Right. -- http://www.guug.de/~roessler/