From owner-ietf-openpgp@mail.imc.org Mon Oct 2 19:04:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15451 for ; Mon, 2 Oct 2000 19:04:13 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA27499 for ietf-openpgp-bks; Mon, 2 Oct 2000 15:44:08 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27493 for ; Mon, 2 Oct 2000 15:44:06 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA27899 for ; Mon, 2 Oct 2000 15:47:57 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA27895 for ; Mon, 2 Oct 2000 15:47:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Mon, 2 Oct 2000 15:36:23 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: MDC Excerpts Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 15) The Symmetrically Encrypted Integrity Protected Data Packet is a variant of the Symmetrically Encrypted Data Packet. It is a new feature created for OpenPGP that addresses the problem of detecting a modification to encrypted data. It is used in combination with a Modification Detection Code Packet. There is a corresponding feature in the features signature subpacket that denotes that an implementation can properly use this packet type. An implementation SHOULD NOT use this packet when encrypting to a recipient that does not state it can use this packet, and SHOULD prefer this to older Symmetrically Encrypted Data Packet when possible. This 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 decrypted packet in this packet's payload 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, is 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.13. Modification Detection Code Packet (Tag 16) The Modification Detection Code packet contains a SHA-1 hash of plaintext data which is used to detect message modification. It is only used with 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. The reason for this is that the hashing rules for modification detection include a one-octet tag and one-octet length in the data hash. While this is a bit restrictive, it reduces complexity. [...] [Yes, I know this is earlier in the document.] 5.2.3.24. Features (array of one-octet values) The features subpacket denotes which advanced OpenPGP features a user's implementation supports. This is so that as features are added to OpenPGP that cannot be backwards-compatible, a user can state that they can use that feature. This subpacket is similar to a preferences subpacket, and only appears in a self-signature. An implementation SHOULD NOT use a feature listed when sending to a user who does not state that they can use it. Defined features are: 1 - Modification Detection (packets 15 and 16) If an implementation implements any of the defined features, it SHOULD implement the features subpacket, too. From owner-ietf-openpgp@mail.imc.org Mon Oct 2 19:05:45 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15486 for ; Mon, 2 Oct 2000 19:05:45 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA27073 for ietf-openpgp-bks; Mon, 2 Oct 2000 15:32:09 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27062 for ; Mon, 2 Oct 2000 15:31:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA27725; Mon, 2 Oct 2000 15:35:45 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA27721; Mon, 2 Oct 2000 15:35:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000929141551.D2592@djebel.openit.de> References: <200009291101.HAA26175@ietf.org> <20000929141551.D2592@djebel.openit.de> Date: Mon, 2 Oct 2000 15:27:21 -0700 To: Werner Koch , ietf-openpgp@imc.org From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:15 PM +0200 9/29/00, Werner Koch wrote: >Thanks for updating the draft Jon. > >I think we should add the section on the new MDC packets. Those are >implemented in PGP 7 and GnuPG 1.0.3. Hal: Can you post this >proposed section again? > I've added in the MDC packets, editing the text from Hal's submission. I also added in a "features" subpacket to state that you speak MDC. Excerpts will be forthcoming. I made a few other edits surrounding MDC use (for example in the BNF). I also put in a reminder in the packet header description that you have to use a new-format packet for tags of 16 and greater. >Assuming that AES will be announced quite soon, we could issue a new >draft right after this event. > What changes need to be made for that? We've already reserved constants for the AES. Do I need to do anything other than remove the word "reserved"? Hmmm. A Rijndael reference. That seems to be it to me, though. Jon From owner-ietf-openpgp@mail.imc.org Tue Oct 3 00:52:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA20805 for ; Tue, 3 Oct 2000 00:52:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02321 for ietf-openpgp-bks; Mon, 2 Oct 2000 21:29:20 -0700 (PDT) Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA02316 for ; Mon, 2 Oct 2000 21:29:19 -0700 (PDT) Received: from localhost ([64.228.185.51]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001003043309.OMEO10530.tomts6-srv.bellnexxia.net@localhost> for ; Tue, 3 Oct 2000 00:33:09 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13gIe7-0000a6-00; Mon, 2 Oct 2000 23:21:35 -0400 Date: Mon, 2 Oct 2000 23:21:35 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Message-ID: <20001002232134.A1762@rho.invalid> References: <200009291101.HAA26175@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009291101.HAA26175@ietf.org>; from Internet-Drafts@ietf.org on Fri, Sep 29, 2000 at 07:01:02AM -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The security notes still don't mention that there is a cryptographic flaw in v4 signatures. This needs to be fixed, or if there are good reasons for not fixing it, it must at least be explained in the document. As I explained on January 19th: | > I think I'm confused here. Suppose I have an implementation that does DSA | > with SHA-1. Let us also suppose that Tiger gets broken. How does this | > affect my DSA/SHA signature? | | Then if I want to forge a signature, I find a message for which the | Tiger hash value is identical to your original SHA-1 hash. Unless | your original signature was a v3 RSA signature, nothing in OpenPGP | prevents me from setting the hash algorithm identifier for that | message to Tiger. That's why the RSA value in PKCS #1 contains a | DigestInfo, and why the DSS specifies SHA-1 as the only signature | algorithm. Putting the hash algorithm identifier in the data | protected by that very hash algorithm is pointless. | | That clearly is a cryptographic weakness in the protocol, so it has to | be mentioned in the RFC. Most of the other issues I raised haven't been addressed either, but as things are it looks like it would be pointless to invest a lot of time in OpenPGP. From owner-ietf-openpgp@mail.imc.org Tue Oct 3 05:32:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04803 for ; Tue, 3 Oct 2000 05:32:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA07436 for ietf-openpgp-bks; Tue, 3 Oct 2000 02:01:37 -0700 (PDT) Received: from vi-b2.ipcore.viaginterkom.de (ns1.ipcore.viaginterkom.de [195.182.96.28]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA07432 for ; Tue, 3 Oct 2000 02:01:35 -0700 (PDT) Received: from sobolev.does-not-exist.org (f-210-103.cvx.ipdial.viaginterkom.de [62.180.210.103]) by vi-b2.ipcore.viaginterkom.de (8.9.3/8.9.3) with ESMTP id KAA18216 for ; Tue, 3 Oct 2000 10:56:03 +0200 (MET DST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 9433A2ED15; Tue, 3 Oct 2000 10:47:30 +0200 (CEST) Date: Tue, 3 Oct 2000 10:47:30 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Message-ID: <20001003104730.B2625@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <200009291101.HAA26175@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <200009291101.HAA26175@ietf.org>; from Internet-Drafts@ietf.org on Fri, Sep 29, 2000 at 07:01:02AM -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This draft still does not say anything about name spaces for notation data tags, making notation data essentially useless. Suggestion: The present document defines two name spaces for notation data names: The IETF name space and the user name space. Notation data names in the IETF name space consist of an arbitrary string of UTF-8 encoded characters, with the exception that the character "@" ("at") MUST NOT occur in such a name. XXX - describe IANA registration procedures. Notation data names in the user name space consist of a tag, followed by the "@" character, followed by a DNS domain name. The tag may be an arbitrary string of UTF-8 encoded characters, with the exception that the character "@" MUST NOT occur in such a name. The DNS domain name must be under the exclusive control of the person or entity which introduces the notation data name in question. For example, if The Example Corporation wishes to introduce sample notation data, the appropriate notation data name could be "sample@example.com". -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Tue Oct 3 18:27:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24276 for ; Tue, 3 Oct 2000 18:27:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01349 for ietf-openpgp-bks; Tue, 3 Oct 2000 14:57:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01343 for ; Tue, 3 Oct 2000 14:57:53 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA17853 for ; Tue, 3 Oct 2000 15:01:48 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA17849 for ; Tue, 3 Oct 2000 15:01:48 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Tue, 3 Oct 2000 14:56:29 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA01344 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id OAA01349 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id SAA24276 In our last episode ("Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt", shown on 10/2/00), Ulf Möller said: >The security notes still don't mention that there is a cryptographic >flaw in v4 signatures. This needs to be fixed, or if there are good >reasons for not fixing it, it must at least be explained in the >document. > Should we start killing hash algorithms, then? Jon From owner-ietf-openpgp@mail.imc.org Tue Oct 3 18:32:21 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA24329 for ; Tue, 3 Oct 2000 18:32:20 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01756 for ietf-openpgp-bks; Tue, 3 Oct 2000 15:13:01 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01752 for ; Tue, 3 Oct 2000 15:13:01 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA18185 for ; Tue, 3 Oct 2000 15:16:56 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA18181 for ; Tue, 3 Oct 2000 15:16:55 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Tue, 3 Oct 2000 15:15:19 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: PKCS1 update excerpts Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Please let me know if this is adequate: 5.1: The value "m" in the above formulas is derived from the session key as follows. First the session key is prefixed with a one-octet algorithm identifier that specifies the symmetric encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet. Then a two-octet checksum is appended which is equal to the sum of the preceding session key octets, not including the algorithm identifier, modulo 65536. This value is then encoded as described in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m" value used in the formulas above. Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation MUST make new PKCS-1 encoding for each key. and 5.2.2: With RSA signatures, the hash value is encoded as described in PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of type DigestInfo, and then encoded using PKCS-1 encoding type EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value as an octet string into an ASN.1 structure. The object identifier for the type of hash being used is included in the structure. The hexadecimal representations for the currently defined hash algorithms are: From owner-ietf-openpgp@mail.imc.org Tue Oct 3 19:15:16 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA24651 for ; Tue, 3 Oct 2000 19:15:16 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02559 for ietf-openpgp-bks; Tue, 3 Oct 2000 15:53:27 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02555 for ; Tue, 3 Oct 2000 15:53:25 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA09014; Tue, 3 Oct 2000 15:52:54 -0700 Date: Tue, 3 Oct 2000 15:52:54 -0700 Message-Id: <200010032252.PAA09014@finney.org> To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ulf Möller wrote: >The security notes still don't mention that there is a cryptographic >flaw in v4 signatures. This needs to be fixed, or if there are good >reasons for not fixing it, it must at least be explained in the >document. The problem is that we currently allow a choice of hash algorithms with DSA signatures. Because there is no room in the DSA inputs to specify the hash algorithm, it is possible to do a hash substitution attack. This is why the DSS specifies that the hash must be SHA-1. We allow other hashes with a size of 160 bits, as described in section 5.2.2: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. The only other hashes listed in RFC 2440 which have this size are RIPEMD-160 and HAVAL. These are thought to be strong hashes, like SHA-1, hence there is no actual cryptographic weakness in RFC-2440. This issue is discussed in section 13, Security Considerations: The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. These same considerations about the quality of the hash algorithm apply to Elgamal signatures. In my opinion this does address the issue raised above. Hal From owner-ietf-openpgp@mail.imc.org Tue Oct 3 20:29:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25088 for ; Tue, 3 Oct 2000 20:29:03 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id QAA03012 for ietf-openpgp-bks; Tue, 3 Oct 2000 16:14:06 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03008 for ; Tue, 3 Oct 2000 16:14:04 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id QAA19380 for ; Tue, 3 Oct 2000 16:17:59 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id QAA19376 for ; Tue, 3 Oct 2000 16:17:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200010032252.PAA09014@finney.org> References: <200010032252.PAA09014@finney.org> Date: Tue, 3 Oct 2000 16:11:09 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I added the following two paragraphs to Security Considerations that address this issue: There is a potential security problem in signatures. If an attacker can find a message that hashes to the same hash with a different algorithm, a bogus signature structure can be constructed that evaluates correctly. For example, suppose Alice DSA signs message M using hash algorithm H. Suppose that Mallet finds a message M' that has the same hash value as M with H'. Mallet can then construct a signature block that verifies as Alice's signature of M' with H'. However, this would also constitute a weakness in either H or H' or both. Should this ever occur, a revision will have to be made to this document to revise the allowed hash algorithms. From owner-ietf-openpgp@mail.imc.org Wed Oct 4 00:26:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29585 for ; Wed, 4 Oct 2000 00:26:54 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id VAA08350 for ietf-openpgp-bks; Tue, 3 Oct 2000 21:07:34 -0700 (PDT) Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08344 for ; Tue, 3 Oct 2000 21:07:32 -0700 (PDT) Received: from localhost ([206.172.147.137]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001004041128.KVXI1518.tomts7-srv.bellnexxia.net@localhost> for ; Wed, 4 Oct 2000 00:11:28 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13gdo3-0000Gx-00; Tue, 3 Oct 2000 21:57:15 -0400 Date: Tue, 3 Oct 2000 21:57:15 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Message-ID: <20001003215715.A1035@rho.invalid> References: <200010032252.PAA09014@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jon@callas.org on Tue, Oct 03, 2000 at 04:11:09PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 03, 2000 at 04:11:09PM -0700, Jon Callas wrote: > I added the following two paragraphs to Security Considerations that > address this issue: Thanks. From owner-ietf-openpgp@mail.imc.org Wed Oct 4 03:59:41 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13383 for ; Wed, 4 Oct 2000 03:59:41 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA12817 for ietf-openpgp-bks; Wed, 4 Oct 2000 00:41:34 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA12811 for ; Wed, 4 Oct 2000 00:41:30 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A353E7A10296; Wed, 04 Oct 2000 15:46:43 0800 Message-Id: <5.0.0.25.0.20001004152310.02162c88@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 04 Oct 2000 15:40:27 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: PKCS1 update excerpts Cc: Jon Callas In-Reply-To: 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: Jon, Does this info help: The m value is calculated as follows: boundary 0x00 The boundary value identifier 0x02 The block type identifier random n octets n octets of non zero PRNG data to make len(m) = modulus of the length of the primary key p boundary 0x00 The boundary value algorithm id 1 octet The ID of the symmetrical algorithm used with the session key session key n bits This is the n bit session key to encrypt the data checksum 2 bytes Is the 16 bit checksum of the session key, MOD 65536 At 03:15 PM 3/10/2000 -0700, you wrote: >Please let me know if this is adequate: > >5.1: > > The value "m" in the above formulas is derived from the session key > as follows. First the session key is prefixed with a one-octet > algorithm identifier that specifies the symmetric encryption > algorithm used to encrypt the following Symmetrically Encrypted Data > Packet. Then a two-octet checksum is appended which is equal to the > sum of the preceding session key octets, not including the algorithm > identifier, modulo 65536. This value is then encoded as described > in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m" > value used in the formulas above. > > Note that when an implementation forms several PKESKs with one > session key, forming a message that can be decrypted by several > keys, the implementation MUST make new PKCS-1 encoding for each key. > >and > >5.2.2: > > With RSA signatures, the hash value is encoded as described in > PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of > type DigestInfo, and then encoded using PKCS-1 encoding type > EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value > as an octet string into an ASN.1 structure. The object identifier > for the type of hash being used is included in the structure. The > hexadecimal representations for the currently defined hash > algorithms are: From owner-ietf-openpgp@mail.imc.org Wed Oct 4 04:59:32 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13838 for ; Wed, 4 Oct 2000 04:59:31 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA17560 for ietf-openpgp-bks; Wed, 4 Oct 2000 01:37:44 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA17549 for ; Wed, 4 Oct 2000 01:37:42 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13gkL7-00073r-00; Wed, 04 Oct 2000 10:55:49 +0200 Date: Wed, 4 Oct 2000 10:55:49 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: MDC Excerpts Message-ID: <20001004105549.D26868@djebel.openit.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: ; from jon@callas.org on Mon, Oct 02, 2000 at 03:36:23PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2 Oct 2000, Jon Callas wrote: > 5.2.3.24. Features > > (array of one-octet values) We need a number for this signature sub packet. > 1 - Modification Detection (packets 15 and 16) > > If an implementation implements any of the defined features, it > SHOULD implement the features subpacket, too. I have a problem with this. Currently PGP 7 and GnuPG 1.0.2 implement this feature and use packets 15 and 16 when Twofish is used. A year back or so we had a long discussion about this MDC packets and the use of Twofish. I suggested that we should wait with using Twofish until we had figured out how to do this MDC and the require implementations to use the MDC packet if they use a cipher with a blocklength not equal to 64 bits. Requiring to use the MDC only if the feature packet is present makes the code more complicated because an implementation has to check the cipher preferences and the MDC feature. The feature packet is a good thing because it enables us to use the MDC even with with CAST5 or 3DES. It should however say that this feature is implictly assumed when a symmetrical cipher algorithm with ablocklength different from 64 bits is used (or explitly enumerate algorithms). I'd also appreciate if we can say that the use of the MDC is a SHOULD for such algorithms. Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Wed Oct 4 05:01:58 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13866 for ; Wed, 4 Oct 2000 05:01:57 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA18183 for ietf-openpgp-bks; Wed, 4 Oct 2000 01:43:44 -0700 (PDT) Received: from merrymeet.com (fwuser@w023.z064000151.sjc-ca.dsl.cnc.net [64.0.151.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA18179 for ; Wed, 4 Oct 2000 01:43:41 -0700 (PDT) Received: from [64.0.151.22] (64.0.151.22) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1); Wed, 4 Oct 2000 01:47:31 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <5.0.0.25.0.20001004152310.02162c88@203.38.66.7> References: <5.0.0.25.0.20001004152310.02162c88@203.38.66.7> Date: Wed, 4 Oct 2000 01:20:56 -0700 To: Erron Criddle , ietf-openpgp@imc.org From: Jon Callas Subject: Re: PKCS1 update excerpts Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm trying to clarify and get the references proper. So perhaps, if other people think it helps. Jon From owner-ietf-openpgp@mail.imc.org Wed Oct 4 07:26:04 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15567 for ; Wed, 4 Oct 2000 07:26:03 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA05577 for ietf-openpgp-bks; Wed, 4 Oct 2000 04:03:39 -0700 (PDT) Received: from vi-b1.ipcore.viaginterkom.de (ns0.ipcore.viaginterkom.de [195.182.96.29] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05572 for ; Wed, 4 Oct 2000 04:03:37 -0700 (PDT) Received: from sobolev.does-not-exist.org (f-209-112.cvx.ipdial.viaginterkom.de [62.180.209.112]) by vi-b1.ipcore.viaginterkom.de (8.9.3/8.9.3) with ESMTP id MAA15417; Wed, 4 Oct 2000 12:38:43 +0200 (MET DST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 7EE5D2ED13; Wed, 4 Oct 2000 12:36:38 +0200 (CEST) Date: Wed, 4 Oct 2000 12:36:38 +0200 From: Thomas Roessler To: "Peter J . Holzer" Cc: Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" Subject: Text canonicalization in RFC 2440 - backwards compatibility? Message-ID: <20001004123638.D15312@sobolev.does-not-exist.org> Mail-Followup-To: "Peter J . Holzer" , Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <20001004115529.C15434@wsr.ac.at>; from hjp@wsr.ac.at on Wed, Oct 04, 2000 at 11:55:29AM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [This thread got started since PGP signatures on the bugtraq list did not verify correctly. However, these signatures are (1) text-mode, and (2) the modification apparently concerns trailing whitespace.] This smells like a discrepancy between RFC 2440 and the classical PGP implementation has crept in, and gone unnoticed for quite some time. Essentially, RFC 2440 says that we shouldn't observe the problems occuring on bugtraq: Peter is generating "canonical text" signatures. RFC 2440 says: 0x01: Signature of a canonical text document. Typically, this means the signer owns it, created it, or certifies that it has not been modified. The signature is calculated over the text data with its line endings converted to and trailing blanks removed. However, when experimenting with PGP 2.6.3in, I'm observing that canonical text signatures _do_ take trailing whitespace into account. Now, let's look at the older docs: RFC 1991 doesn't seem to define canonical text mode at all. pgpdoc2.txt from the PGP 2 distribution, however, just says this: "Canonical text has a carriage return and a linefeed at the end of each line of text." This is a precise description of the behaviour, and actually matches the expectation which seems to have been implicit to RFC 2015, which only deals with line-end canonicalization, but not with the signature mode to be used. To make things worse, the "clearsign" signatures of pgp2 _do_ correspond with what RFC 2440 says about canonical text documents in general. Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing about all this? Are they compatible: - to each other? - to PGP 2.6? Or am I just confused? On 2000-10-04 11:55:29 +0200, Peter J . Holzer wrote: > Date: Wed, 4 Oct 2000 11:55:29 +0200 > From: "Peter J . Holzer" > To: Lars Hecking > Cc: Thomas Roessler , > aleph1@SECURITYFOCUS.COM > Subject: Re: rcp file transfer hole (was: scp file transfer hole) > X-Mailer: Mutt 0.95.3i >=20 > [I have included Elias in the Cc, because I think he might want to know > about this "feature" of his mailing-list software] >=20 >=20 > On 2000-10-04 10:06:34 +0100, Lars Hecking wrote: > > Any idea why half the signatures on bugtraq don't check out? Do you > > have an fcc copy of your posting that you can compare with the posted > > message? >=20 > Yes. >=20 > Looks like Bugtraq strips trailing spaces from each line. This will > garble the signature separator ("-- ") and therefore the pgp signature > won't check out any more.=20 >=20 > I guess I should add=20 >=20 > send-hook '~t BUGTRAQ@SECURITYFOCUS.COM' 'set pgp_strict_enc' >=20 > to my .muttrc. >=20 > For people which don't use PGP signatures, but want their normal > signatures to be separated correctly, it would be nice if mutt could be > forced to use quoted printable even for ascii messages. Thomas? >=20 > hp >=20 > --=20 > _ | Peter J. Holzer | Any setuid root program that does an > |_|_) | Sysadmin WSR / LUGA | exec() somewhere is just a less > | | | hjp@wsr.ac.at | user friendly version of su. > __/ | http://www.hjp.at/ | -- Olaf Kirch on bugtraq 2000-08-07 --=20 Thomas Roessler --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOdsINtImKUTOasbBAQEJ1ggAnlQP8OrYh4HrPgCLzTDD/7T7RlFTkUyv CkoPt2ZVvWABfy2Bv2T+lGE/k6W1Wqhb+Yzjz0xboOBsGgaWKBJVbA7Go2SECQ4s +VRzj4XMWVb0RTWcg4t7tHdBwfpIM3d9heMp0KiYgVuHRMkSDITZ8QYQqJcI9xYw 1ACX3QzfGCMCKO4uCe/KjPeIS6zM1SzcgqjOn6vigjCWWCxXrUTBOP7dSbO53kx8 ovIX68eRCn1gIGBUtNONW29r5avZ/SYTt9FT1D2J/eEvdG82tyMtOOoFL1ObL6Tg 2xMGDX5H3CXAlXoJUsHvPptu4vu6cGyuzdpuNszct3WA0C6YHL36qA== =Kti5 -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- From owner-ietf-openpgp@mail.imc.org Wed Oct 4 08:33:38 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17466 for ; Wed, 4 Oct 2000 08:33:35 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10477 for ietf-openpgp-bks; Wed, 4 Oct 2000 05:16:25 -0700 (PDT) Received: from wsrcom1.wsr.ac.at (wsrcom1.wsr.ac.at [143.130.16.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10473 for ; Wed, 4 Oct 2000 05:16:23 -0700 (PDT) Received: from enkur.wsr.ac.at (IDENT:hjp@enkur.wsr.ac.at [143.130.50.57]) by wsrcom1.wsr.ac.at (8.9.3/8.9.3) with ESMTP id OAA14517; Wed, 4 Oct 2000 14:20:03 +0200 (METDST) Received: (from hjp@localhost) by enkur.wsr.ac.at (8.9.3/8.9.3) id OAA24793; Wed, 4 Oct 2000 14:20:01 +0200 Date: Wed, 4 Oct 2000 14:20:01 +0200 From: "Peter J . Holzer" To: Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility? Message-ID: <20001004142001.G15434@wsr.ac.at> References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> <20001004123638.D15312@sobolev.does-not-exist.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=pfTAc8Cvt8L6I27a; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.3i In-Reply-To: <20001004123638.D15312@sobolev.does-not-exist.org>; from Thomas Roessler on Wed, Oct 04, 2000 at 12:36:38PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --pfTAc8Cvt8L6I27a Content-Type: text/plain; charset=us-ascii On 2000-10-04 12:36:38 +0200, Thomas Roessler wrote: > Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing > about all this? Are they compatible: > > - to each other? > - to PGP 2.6? I think that GnuPG is not compatible with PGP 2.6. Lars (using GnuPG) couldn't verify a message (signed with PGP 2.6) I sent to him in a tarred and compressed folder (to avoid any corruption in transit). I'll try PGP 6.5 (which I have installed at home) this evening. hp -- _ | Peter J. Holzer | Any setuid root program that does an |_|_) | Sysadmin WSR / LUGA | exec() somewhere is just a less | | | hjp@wsr.ac.at | user friendly version of su. __/ | http://www.hjp.at/ | -- Olaf Kirch on bugtraq 2000-08-07 --pfTAc8Cvt8L6I27a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQDQAwUBOdsgcVLjemazOuKpAQFqjwXRAe6uFTOKBKkXpM+xdWrWwLPpD/s9LjP1 yzHd+FDkdHKaJtydAYN5W3zVqUz9VW/w3gIE6lycv0g28AjtJGqMohEIUDVQmlDk 1hGcYfF6Oyw+wQ2eXPlF/7EAhWtPJLzS14WDgaq2vZrtMdigKQjLgcwxDQGeySny 1nvP4O/wqSIP4uYKrAwzn7QPdh8LP6eiMpusPqy0L7Xqf/9TJ04f3Xc1LfJw58ka ClCkFA/h+HGMBy+XsVIPOKpe6Q== =ho3n -----END PGP SIGNATURE----- --pfTAc8Cvt8L6I27a-- From owner-ietf-openpgp@mail.imc.org Wed Oct 4 08:38:43 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17619 for ; Wed, 4 Oct 2000 08:38:43 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10668 for ietf-openpgp-bks; Wed, 4 Oct 2000 05:22:33 -0700 (PDT) Received: from nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10663 for ; Wed, 4 Oct 2000 05:22:31 -0700 (PDT) Date: Wed, 4 Oct 2000 13:25:46 +0100 From: Lars Hecking To: "Peter J . Holzer" Cc: aleph1@securityfocus.com, "ietf-openpgp @ imc . org" Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility? Message-ID: <20001004132546.A26016@nmrc.ie> References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> <20001004123638.D15312@sobolev.does-not-exist.org> <20001004142001.G15434@wsr.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <20001004142001.G15434@wsr.ac.at>; from hjp@wsr.ac.at on Wed, Oct 04, 2000 at 02:20:01PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter J . Holzer writes: > On 2000-10-04 12:36:38 +0200, Thomas Roessler wrote: > > Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing > > about all this? Are they compatible: > > > > - to each other? > > - to PGP 2.6? > > I think that GnuPG is not compatible with PGP 2.6. Lars (using GnuPG) > couldn't verify a message (signed with PGP 2.6) I sent to him in a > tarred and compressed folder (to avoid any corruption in transit). I'll > try PGP 6.5 (which I have installed at home) this evening. Just re-tried with pgp 2.6.3i, and yes, this time it works. -l -- Be free and open and breezy! Enjoy! Things won't get any better so get used to it. From owner-ietf-openpgp@mail.imc.org Thu Oct 5 22:27:52 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10952 for ; Thu, 5 Oct 2000 22:27:51 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id SAA16496 for ietf-openpgp-bks; Thu, 5 Oct 2000 18:35:22 -0700 (PDT) Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16490 for ; Thu, 5 Oct 2000 18:35:08 -0700 (PDT) Received: from localhost ([64.228.185.57]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001006013902.WWVW625.tomts8-srv.bellnexxia.net@localhost>; Thu, 5 Oct 2000 21:39:02 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13hL8M-0000Py-00; Thu, 5 Oct 2000 20:13:06 -0400 Date: Thu, 5 Oct 2000 20:13:06 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: "Peter J . Holzer" , Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility? Message-ID: <20001005201305.A1500@rho.invalid> References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> <20001004123638.D15312@sobolev.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20001004123638.D15312@sobolev.does-not-exist.org>; from roessler@does-not-exist.org on Wed, Oct 04, 2000 at 12:36:38PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 04, 2000 at 12:36:38PM +0200, Thomas Roessler wrote: > This smells like a discrepancy between RFC 2440 and the classical > PGP implementation has crept in, and gone unnoticed for quite some > time. Sometimes I have the impression that most of my comments on the OpenPGP drafts fall in the "gone unnoticed" category (I first pointed it out on September 16th, 1998, again on October 13th -- RFC 2440 was published in November --, once more on February 10th, 1999, and again on December 23rd after a cryptic note on the subject appeared in 2440bis-00); but we actually have the following text in the latest draft: * PGP 2.6.X and 5.0 do not trim trailing whitespace from a "canonical text" signature. They only remove it from cleartext signatures. These signatures are not OpenPGP compliant -- OpenPGP requires trimming the whitespace. If you wish to interoperate with PGP 2.6.X or PGP 5, you may wish to accept these non-compliant signatures. From owner-ietf-openpgp@mail.imc.org Fri Oct 6 03:55:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26566 for ; Fri, 6 Oct 2000 03:55:35 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA22634 for ietf-openpgp-bks; Fri, 6 Oct 2000 00:16:59 -0700 (PDT) Received: from merrymeet.com (fwuser@w023.z064000151.sjc-ca.dsl.cnc.net [64.0.151.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22629 for ; Fri, 6 Oct 2000 00:16:53 -0700 (PDT) Received: from [64.0.151.22] (64.0.151.22) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1); Fri, 6 Oct 2000 00:20:55 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com (Unverified) Message-Id: In-Reply-To: <20001005201305.A1500@rho.invalid> References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> <20001004123638.D15312@sobolev.does-not-exist.org> <20001005201305.A1500@rho.invalid> Date: Thu, 5 Oct 2000 20:52:40 -0700 To: Ulf =?iso-8859-1?Q?M=F6ller?= , "Peter J . Holzer" , Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" From: Jon Callas Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility? Content-Type: text/plain; charset="iso-8859-1" X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA22631 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-MIME-Autoconverted: from 8bit to quoted-printable by ns.secondary.com id AAA22634 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA26566 At 8:13 PM -0400 10/5/00, Ulf Möller wrote: >Sometimes I have the impression that most of my comments on the >OpenPGP drafts fall in the "gone unnoticed" category (I first pointed >it out on September 16th, 1998, again on October 13th -- RFC 2440 was >published in November --, once more on February 10th, 1999, and again >on December 23rd after a cryptic note on the subject appeared in >2440bis-00); but we actually have the following text in the latest >draft: > > * PGP 2.6.X and 5.0 do not trim trailing whitespace from a > "canonical text" signature. They only remove it from cleartext > signatures. These signatures are not OpenPGP compliant -- > OpenPGP requires trimming the whitespace. If you wish to > interoperate with PGP 2.6.X or PGP 5, you may wish to accept > these non-compliant signatures. You're welcome. I've said this a number of times, and I think it bears repeating. If I get a request about OpenPGP that is vague, I may not do what the requester intends. The ways in which I can fall down include putting the wrong thing in the draft, but they are also likely to be that I'll do nothing when you wanted something. There are a couple of reasons I might do nothing. The usual one is that I don't know what you want me to do. OpenPGP has small quantities of sub-optimal things in it. Usually, those things are there because of backwards compatibility. However, at the start of this working group, we decided that backwards compatibility is important and desirable, but not essential. So there are things we can, and have, broken because it makes a better standard moving forward. So sometimes I interpret someone's complaint as a complaint, not as a suggestion for a change in the document. I know that in your case, I've made a number of errors of this sort. I am truly sorry for this, and I've been trying to make a special effort to pay closer attention to what you want. However, it makes it *much* easier for me if you tell me what you want. The best thing is something like: Please change XXX to YYY. For example, I am presently working on getting the PKCS1 updates done. Thank you for you help. But changing them correctly means that I have to go dredge out the PKCS1 draft, read it, interpret it, and figure out what to do. This will take a couple of hours, most likely. In the last few days I've had several ten minute opportunities to edit. I've had a couple hour-long ones. I haven't yet had that much time. If you know what you want text to be, tell me. If I have to do research not only will I do it slower, but there's a chance I may decide that the best thing to do is nothing. In short -- if you make me think, I may end up concluding something other than you want. Again, though, I'm sorry I've screwed up. It isn't that I'm ignoring you. Jon From owner-ietf-openpgp@mail.imc.org Sun Oct 8 13:18:46 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10211 for ; Sun, 8 Oct 2000 13:18:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA04048 for ietf-openpgp-bks; Sun, 8 Oct 2000 09:56:09 -0700 (PDT) Received: from mail2.mia.bellsouth.net (mail2.mia.bellsouth.net [205.152.144.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04044 for ; Sun, 8 Oct 2000 09:56:07 -0700 (PDT) From: bubblehead32@hotmail.com Received: from www.goldendeckcasino.com (adsl-61-143-206.mia.bellsouth.net [208.61.143.206]) by mail2.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id NAA16873; Sun, 8 Oct 2000 13:00:12 -0400 (EDT) Message-Id: <200010081700.NAA16873@mail2.mia.bellsouth.net> To: <> Subject: WOW!!! Highest Payouts Around!!!!!!!! Date: Sun, 08 Oct 2000 12:52:08 -0400 X-Sender: bubblehead32@hotmail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html. If you would like to be removed from these mailings in the future please mailto:bubblehead32@hotmail.com?subject=remove From owner-ietf-openpgp@mail.imc.org Sun Oct 8 18:20:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11715 for ; Sun, 8 Oct 2000 18:20:02 -0400 (EDT) Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA10164 for ietf-openpgp-bks; Sun, 8 Oct 2000 14:52:41 -0700 (PDT) Received: from www.tclking.com (IDENT:root@szptt103-190.szptt.net.cn [202.103.190.164] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10159 for ; Sun, 8 Oct 2000 14:52:39 -0700 (PDT) From: rsb@docsj.de Received: from pavilion (mig-fl29a-49.rasserver.net [206.214.131.49]) by www.tclking.com (8.9.3/8.8.7) with SMTP id GAA25178; Mon, 9 Oct 2000 06:10:20 +0800 Date: Mon, 9 Oct 2000 06:10:20 +0800 Message-Id: <200010082210.GAA25178@www.tclking.com> To: rsb@docsj.de Subject: At last, HERBAL V the all natural alternative! Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $24 ______ 2 Bottles of Herbal V $44 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-ietf-openpgp@mail.imc.org Mon Oct 9 19:00:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA10932 for ; Mon, 9 Oct 2000 19:00:53 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA22154 for ietf-openpgp-bks; Mon, 9 Oct 2000 15:37:29 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22148 for ; Mon, 9 Oct 2000 15:37:28 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA08356 for ; Mon, 9 Oct 2000 15:41:53 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA08352 for ; Mon, 9 Oct 2000 15:41:52 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Mon, 9 Oct 2000 15:37:44 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Another draft is going out Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have the MDC packets in and Ulf's comments (signature collisions and PKCS1 leap to mind). I also added in a definition of a keyring. Like I said before, I'm willing to put out a number of small drafts. This one is particularly important because of the MDC packets, which required small changes in a number of places. I also added in a "features" signature subpacket. There are also AES references added and reservation notes removed. I standardized some spelling. I'm sure I missed someone's something. Just send me mail. In a week or two, I'll do another. Jon From owner-ietf-openpgp@mail.imc.org Wed Oct 11 03:50:55 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04372 for ; Wed, 11 Oct 2000 03:50:55 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA27538 for ietf-openpgp-bks; Wed, 11 Oct 2000 00:24:13 -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 AAA27534 for ; Wed, 11 Oct 2000 00:24:12 -0700 (PDT) Received: from [63.73.97.185] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1) for ; Wed, 11 Oct 2000 00:28:44 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Wed, 11 Oct 2000 00:07:43 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: Another draft is going out Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I forgot to mention that there's also the notation data namespace thing in there, too. Let me know what you think. Jon From owner-ietf-openpgp@mail.imc.org Wed Oct 11 05:25:53 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA05066 for ; Wed, 11 Oct 2000 05:25:52 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00704 for ietf-openpgp-bks; Wed, 11 Oct 2000 02:05:38 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA00699 for ; Wed, 11 Oct 2000 02:05:35 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13jI92-0008Cz-00; Wed, 11 Oct 2000 11:25:52 +0200 Date: Wed, 11 Oct 2000 11:25:52 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Another draft is going out Message-ID: <20001011112552.I31259@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jon@callas.org on Wed, Oct 11, 2000 at 12:07:43AM -0700 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, now that it has been decided on AES I suggest to change: 9.2. Symmetric Key Algorithms [...] "Implementations MUST implement Triple-DES. Implementations SHOULD implement IDEA and CAST5. Implementations MAY implement any other algorithm." by "Implementations MUST implement Triple-DES. Implementations SHOULD implement CAST5 and AES 128bit. Implementations MAY implement any other algorithm. To allow backward compatibilty with PGP2 IDEA SHOULD be implemented." I dropped IDEA because I don't see a reason to support that patented algorithm anymore - now that there is another well analyzed new algorithm available. Another point: If the use of the MDC packet is not required for at least the modern ciphers (w/o the feature packet), we should at least add a note that "An implementation SHOULD issue a warning if one of the new[1] cipher algorithms is used without the MDC packet". [1] new: Either explictly list old algorithms or say that new algorithms are those with a blocklength other than 64 bit. Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Wed Oct 11 06:48:05 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06001 for ; Wed, 11 Oct 2000 06:48:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05058 for ietf-openpgp-bks; Wed, 11 Oct 2000 03:25:59 -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 DAA05053 for ; Wed, 11 Oct 2000 03:25:57 -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 GAA05469; Wed, 11 Oct 2000 06:30:30 -0400 (EDT) Message-Id: <200010111030.GAA05469@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-rfc2440bis-02.txt Date: Wed, 11 Oct 2000 06:30:29 -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 : OpenPGP Message Format Author(s) : J. Callas, L. Donnerhacke, H. Finney, R. Thayer Filename : draft-ietf-openpgp-rfc2440bis-02.txt Pages : 67 Date : 10-Oct-00 This document defines many tag values, yet it doesn't describe a mechanism for adding new tags (for new features). Traditionally the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion and RFCs usually define the procedure to be used by the IANA. However there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which result in a significant reduction in over all security. Therefore this document does not define an extension procedure. Instead requests to define new tag values (say for new encryption algorithms for example) should be forwarded to the IESG Security Area Directors for consideration or forwarding to the appropriate IETF Working Group for consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-02.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-rfc2440bis-02.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-rfc2440bis-02.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: <20001010123103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-rfc2440bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001010123103.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openpgp@mail.imc.org Wed Oct 11 06:49:28 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06047 for ; Wed, 11 Oct 2000 06:49:28 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05126 for ietf-openpgp-bks; Wed, 11 Oct 2000 03:29:10 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05122 for ; Wed, 11 Oct 2000 03:29:05 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin189-nt.pg1.frankfurt.nikoma.de [213.54.32.189]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id MAA50711 for ; Wed, 11 Oct 2000 12:33:26 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 0C70D2ED1B; Wed, 11 Oct 2000 12:27:39 +0200 (CEST) Date: Wed, 11 Oct 2000 12:27:39 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: Another draft is going out Message-ID: <20001011122739.Q25061@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <20001011112552.I31259@gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <20001011112552.I31259@gnupg.de>; from wk@gnupg.org on Wed, Oct 11, 2000 at 11:25:52AM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-10-11 11:25:52 +0200, Werner Koch wrote: > I dropped IDEA because I don't see a reason to support that > patented algorithm anymore - now that there is another well > analyzed new algorithm available. We don't need to add still more interoperability nightmares with the old implementations which are still in use at some places. The text-mode signature problems are bad enough already. -- Thomas Roessler From owner-ietf-openpgp@mail.imc.org Wed Oct 11 15:12:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18806 for ; Wed, 11 Oct 2000 15:12:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03065 for ietf-openpgp-bks; Wed, 11 Oct 2000 11:51:32 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03061 for ; Wed, 11 Oct 2000 11:51:31 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id LAA07437; Wed, 11 Oct 2000 11:56:06 -0700 (PDT) Received: from [63.73.97.185] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id LAA07433; Wed, 11 Oct 2000 11:56:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20001011122739.Q25061@sobolev.does-not-exist.org> References: <20001011112552.I31259@gnupg.de> <20001011122739.Q25061@sobolev.does-not-exist.org> Date: Wed, 11 Oct 2000 11:52:41 -0700 To: Thomas Roessler , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Another draft is going out Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:27 PM +0200 10/11/00, Thomas Roessler wrote: >On 2000-10-11 11:25:52 +0200, Werner Koch wrote: > >> I dropped IDEA because I don't see a reason to support that >> patented algorithm anymore - now that there is another well >> analyzed new algorithm available. > >We don't need to add still more interoperability nightmares with the >old implementations which are still in use at some places. The >text-mode signature problems are bad enough already. > Sooner or later, we should start encouraging people away from PGP 2. I like what Werner said -- he simply explicitly called out that IDEA is needed for PGP 2 support. The subtle, lovely thing about SHOULD is that SHOULD means "if you don't understand the ramifications, do it." It allows anyone to say "I know what I'm doing." However, I like the idea of calling out that IDEA is there for backwards compatibility. How about this paragraph: --- Implementations MUST implement Triple-DES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate with PGP 2.6 or earlier need to support IDEA, as that is the only symmetric cipher those versions use. Implementations MAY implement any other algorithm. --- Jon From owner-ietf-openpgp@mail.imc.org Wed Oct 11 15:19:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19160 for ; Wed, 11 Oct 2000 15:19:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id MAA03233 for ietf-openpgp-bks; Wed, 11 Oct 2000 12:01:34 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03229 for ; Wed, 11 Oct 2000 12:01:33 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id MAA07562; Wed, 11 Oct 2000 12:06:08 -0700 (PDT) Received: from [63.73.97.185] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id MAA07558; Wed, 11 Oct 2000 12:05:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20001011112552.I31259@gnupg.de> References: <20001011112552.I31259@gnupg.de> Date: Wed, 11 Oct 2000 11:59:53 -0700 To: Werner Koch , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Another draft is going out Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:25 AM +0200 10/11/00, Werner Koch wrote: >Another point: > >If the use of the MDC packet is not required for at least the modern >ciphers (w/o the feature packet), we should at least add a note that >"An implementation SHOULD issue a warning if one of the new[1] cipher >algorithms is used without the MDC packet". > >[1] new: Either explictly list old algorithms or say that new >algorithms are those with a blocklength other than 64 bit. > I don't think that tying MDC and big blocks is a good idea -- in the spec. I think it is perfectly fine for you implementers to do that. The spec gives you a lot of latitude, and if you want to only use a big block with MDCs, that's fine. You need to *decrypt* one, but you don't ever have to encrypt one. And you're perfectly within your rights to issue warning messages if you think it's not a good idea. If you want to limit use more, I have a suggestion: we put in a "feature" of 128-bit-block ciphers. That way you can declare whether you use them or not. Jon From owner-ietf-openpgp@mail.imc.org Thu Oct 12 05:43:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA16531 for ; Thu, 12 Oct 2000 05:43:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA29834 for ietf-openpgp-bks; Thu, 12 Oct 2000 02:19:30 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29830 for ; Thu, 12 Oct 2000 02:19:27 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13jeqI-0000i0-00; Thu, 12 Oct 2000 11:40:02 +0200 Date: Thu, 12 Oct 2000 11:40:02 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Another draft is going out Message-ID: <20001012114002.G2549@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20001011112552.I31259@gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jon@callas.org on Wed, Oct 11, 2000 at 11:59:53AM -0700 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 11 Oct 2000, Jon Callas wrote: > I don't think that tying MDC and big blocks is a good idea -- in the spec. The idea established at the time we introduced Twofish and talked about MDC. I suggested to wait with Twofish until we worked out the MDC stuff. Anyway, the specs are getting more and more complex, so we better don't do what I suggested. > If you want to limit use more, I have a suggestion: we put in a "feature" > of 128-bit-block ciphers. That way you can declare whether you use them or Too complicated. We already have the preferences and issue a warning when a received message is not encrypted by an algorithm listed in the preferences. So we can have the same effect by setting up the preferences right and issue a warning when the MUST algorithm 3DES has been used without MDC. Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Sun Oct 15 23:38:26 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA14580 for ; Sun, 15 Oct 2000 23:38:25 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11142 for ietf-openpgp-bks; Sun, 15 Oct 2000 20:16:29 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11138 for ; Sun, 15 Oct 2000 20:16:26 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A78A422E02A0; Mon, 16 Oct 2000 11:23:06 0800 Message-Id: <5.0.0.25.0.20001016111259.00aa0eb8@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 16 Oct 2000 11:16:06 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: ElGamal & DSA Sample Keys Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, I know this may be a bit off track, however I am looking for 2048 bit ElGamal p and g keys as well as 1024 bit DSA p, q (160 bit) and g keys. If anyone knows where I can generate/obtain these from it would be much appreciated as we need to do some testing :) TIA. From owner-ietf-openpgp@mail.imc.org Mon Oct 16 05:41:15 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01107 for ; Mon, 16 Oct 2000 05:41:14 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id CAA23586 for ietf-openpgp-bks; Mon, 16 Oct 2000 02:22:58 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA23581 for ; Mon, 16 Oct 2000 02:22:56 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13l6p4-0007Ju-00; Mon, 16 Oct 2000 11:44:46 +0200 Date: Mon, 16 Oct 2000 11:44:46 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: ElGamal & DSA Sample Keys Message-ID: <20001016114446.J27890@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <5.0.0.25.0.20001016111259.00aa0eb8@203.38.66.7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20001016111259.00aa0eb8@203.38.66.7>; from ejc@comasp.com on Mon, Oct 16, 2000 at 11:16:06AM +0800 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 16 Oct 2000, Erron Criddle wrote: > To all, > > I know this may be a bit off track, however I am looking for 2048 bit > ElGamal p and g keys as well as 1024 bit DSA p, q (160 bit) and g keys. $ gpg --gen-key $ gpg --with-key-data --list-key my-new-key See doc/DETAILS or g10/keylist.c for the format of the output. Ciao, Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Thu Oct 19 09:41:22 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28386 for ; Thu, 19 Oct 2000 09:41:21 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id GAA23447 for ietf-openpgp-bks; Thu, 19 Oct 2000 06:12:25 -0700 (PDT) Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23424 for ; Thu, 19 Oct 2000 06:12:14 -0700 (PDT) Received: from mwyoung.transarc.com ([24.48.233.14]) by smtprelay1.adelphia.net (Netscape Messaging Server 4.15) with SMTP id G2OI4400.1BY for ; Thu, 19 Oct 2000 09:14:28 -0400 Message-ID: <000201c039ce$85434b40$023fa8c0@mwyoung.transarc.com> From: "Michael Young" To: Subject: MDC, gnupg 1.0.3, and PGP7 Date: Thu, 19 Oct 2000 00:18:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I gather from Jon Callas's recent MDC spec message that his proposed revision of June 15 is dead. [That revision used tags 18 and 19, and purported to have the hash include the block+2 salt bytes (but wasn't changed consistently).] Is that right? I note that gnupg 1.0.3 uses tag 18. As I started to write this, I noticed that 1.0.4 was release in source form yesterday -- does it use tag 15 again? Werner Koch's recent reply suggests that PGP7 also uses tag 15. Would someone be willing to post a sample encryption from PGP7 that uses an MDC and Twofish? (I'd also love to see a secret key packet encrypted with Twofish.) My understanding of a reasonable packet sequence and proper containment is as follows: zero or more PKE- or SKE- session-key packets Protected-SE-data packet (tag 15) { version "1"; encrypted< block-size+2 random data (last two bytes repeated); % some packet(s?) { ... } -- typically a Compressed-data packet MDC packet (tag 16) % { 20-byte SHA hash result } > } where the hash occurs over the data between the two %-signs. The gnupg 1.0.3 release generates roughly this format, but it uses an indeterminate size for the Compressed-data packet. An implementation that treats an indeterminate size as that of the containing file or packet, as I think the spec implies, would consider the MDC packet to be extraneous junk at the end of the Compressed-data packet. Moreover, this approach won't work for the "uncompressed" algorithm, or for a Literal-data or other packets in the payload. Given that an MDC packet will follow, the receiver must understand new-style packets, so a partial-body representation should always be valid. Does this sound reasonable? [I apologize to Werner Koch for asking about his implementation in public, but I thought others might have yet other ideas on how this ought to work.] Would it be reasonable to specify the encrypted payload more precisely, something like "a sequence of OpenPGP packets, ending with an MDC packet"? The MDC packet section loosely implies this, but I think it would help to say so in the Protected-SE data packet section explicitly. From owner-ietf-openpgp@mail.imc.org Thu Oct 19 12:00:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16910 for ; Thu, 19 Oct 2000 12:00:29 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00338 for ietf-openpgp-bks; Thu, 19 Oct 2000 08:30:24 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00324 for ; Thu, 19 Oct 2000 08:30:20 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13mI0D-0005dV-00; Thu, 19 Oct 2000 17:53:09 +0200 Date: Thu, 19 Oct 2000 17:53:09 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: MDC, gnupg 1.0.3, and PGP7 Message-ID: <20001019175309.M20744@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <000201c039ce$85434b40$023fa8c0@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000201c039ce$85434b40$023fa8c0@mwyoung.transarc.com>; from mwy-opgp97@the-youngs.org on Thu, Oct 19, 2000 at 12:18:06AM -0400 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 19 Oct 2000, Michael Young wrote: > revision of June 15 is dead. [That revision used tags 18 and 19, and 18 and 19 is right. > I note that gnupg 1.0.3 uses tag 18. As I started to write this, I noticed > that 1.0.4 was release in source form yesterday -- does it use tag 15 again? No. > Werner Koch's recent reply suggests that PGP7 also uses tag 15. I was wrong, it uses 18,19 and I did some interoperability tests. > Would someone be willing to post a sample encryption from PGP7 that uses > an MDC and Twofish? (I'd also love to see a secret key packet encrypted Passphrase "test" -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.4a (GNU/Linux) Comment: For info see http://www.gnupg.org jA0ECgMCUDpHpGjiZQlg0ooBAHDje+vcyFMyBA5bjCemhEVjPKly7+zNodZM9XwG Ks9NGi/dpYfKmUbpUzET1wZpIHEt81vDvVhP7VfLbhYvOBXlWxPyr1IV6Pjznkz/ XxYN8O2f276f/fJ45erHG41SS+N/jKrTYgOEJp5cSSzp6NkJ8hLTRYYSUlX21nYZ sAOiTw1s/j/nX9s= =Ymv/ -----END PGP MESSAGE----- Here are the packets: symkey enc packet: version 4, cipher 10, s2k 3, hash 2 salt 503a47a468e26509, count 96 :encrypted data packet: length: 137 mdc_method: 2 :literal data packet: mode b, created 971969290, name="geheim", raw data: 83 bytes :mdc packet: length=20 And here come the same thing with compression: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.4a (GNU/Linux) Comment: For info see http://www.gnupg.org jA0ECgMC+Mkg2Ij8RYpg0ogBjrSClbfynZowH3o9HDfdSlhBM0IFf8cGqkpcu9Z9 tAF3SciSHV2RRWoObmcUDF5F4gOK81OzB40qbj8DAGHE8BgR13ze/PhswH51H1jY y6wXLackZ0WA2RYFh6UnbR/i/Gu8/jASOqu1Hmqmy8DK2mGEqfcm/oGGaxJz4e47 7lkaBDBuQfSo =AJBJ -----END PGP MESSAGE----- :symkey enc packet: version 4, cipher 10, s2k 3, hash 2 salt f8c920d888fc458a, count 96 :encrypted data packet: length: 135 mdc_method: 2 :compressed packet: algo=1 :literal data packet: mode b, created 971969488, name="geheim", raw data: 83 bytes The MDC packet is not listed due to a bug/implementation issue. From packet.h: PKT_ENCRYPTED_MDC =18, /* integrity protected encrypted data */ PKT_MDC =19, /* manipulaion detection code packet */ Hth, Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Thu Oct 19 14:12:06 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08901 for ; Thu, 19 Oct 2000 14:12:05 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05691 for ietf-openpgp-bks; Thu, 19 Oct 2000 10:44:26 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05687 for ; Thu, 19 Oct 2000 10:44:25 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id KAA04598 for ; Thu, 19 Oct 2000 10:49:40 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id KAA04594 for ; Thu, 19 Oct 2000 10:49:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20001019175309.M20744@gnupg.de> References: <000201c039ce$85434b40$023fa8c0@mwyoung.transarc.com> <20001019175309.M20744@gnupg.de> Date: Thu, 19 Oct 2000 10:47:01 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: MDC, gnupg 1.0.3, and PGP7 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Re: MDC, gnupg 1.0.3, and PGP7", shown on 10/19/00), Werner Koch said: >The MDC packet is not listed due to a bug/implementation issue. > >From packet.h: > PKT_ENCRYPTED_MDC =18, /* integrity protected encrypted data */ > PKT_MDC =19, /* manipulaion detection code packet */ > I only do what the voices in my head tell me to. This time, the voices told me to use 15 and 16. :-) I'm changing them to 18 and 19. Send me some more changes/additions, folks and they'll go in, too. Otherwise, in a week or so, I'll just fling out another draft with this correction. Jon From owner-ietf-openpgp@mail.imc.org Thu Oct 19 14:44:13 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14947 for ; Thu, 19 Oct 2000 14:44:13 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06732 for ietf-openpgp-bks; Thu, 19 Oct 2000 11:13:35 -0700 (PDT) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06728 for ; Thu, 19 Oct 2000 11:13:34 -0700 (PDT) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA12438 for ; Thu, 19 Oct 2000 13:52:34 -0400 (EDT) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id OAA02900 for ; Thu, 19 Oct 2000 14:18:10 -0400 (EDT) Message-ID: <00a001c039f8$a1cccc80$66c52609@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: MDC, gnupg 1.0.3, and PGP7 Date: Thu, 19 Oct 2000 14:15:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Thanks for the examples from 1.0.4a. Do you still have the examples generated by PGP7 that you used for interoperability testing? >And here come the same thing with compression: ... >The MDC packet is not listed due to a bug/implementation issue. Do you believe the bug is in the generation, or in the parsing? I believe that it's in the generation: the compressed data packet uses an old-style indeterminate length, leading your parser (and mine) to treat the MDC packet as contained within it. From owner-ietf-openpgp@mail.imc.org Thu Oct 19 18:58:37 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21827 for ; Thu, 19 Oct 2000 18:58:37 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13437 for ietf-openpgp-bks; Thu, 19 Oct 2000 15:26:46 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13432 for ; Thu, 19 Oct 2000 15:26:40 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA04665; Thu, 19 Oct 2000 15:26:57 -0700 Date: Thu, 19 Oct 2000 15:26:57 -0700 Message-Id: <200010192226.PAA04665@finney.org> To: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Subject: Re: MDC, gnupg 1.0.3, and PGP7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here are two MDC test messages created by PGP 7. The first uses Twofish, the second 3DES. The passphrase for each is "test". I wanted to test both to make sure we interoperate properly with both 64 bit and 128 bit block ciphers. Hal -----BEGIN PGP MESSAGE----- Version: PGPsdk 2.0d20 Copyright (C) 2000 Networks Associates Technology, Inc. A ll rights reserved. qANQR1DDDQQKAwKbEffw1iOFWWDSagG2TUxTd8SWAFCCrwUfH+T0ENGoWmmL+R07 8ZD9CB3OnyBqz/zEVBi4aOrbuYPbJMCImPIt669wwIUx0XmaxwLQZufRCbnU/z1g H/ElneG43J83HCFsHsFGtT7V6Uzq1nOjGaX9Dxpma8I= =tXQ6 -----END PGP MESSAGE----- -----BEGIN PGP MESSAGE----- Version: PGPsdk 2.0d20 Copyright (C) 2000 Networks Associates Technology, Inc. A ll rights reserved. qANQR1DDDQQCAwIQP0qEoEdt7WDSYgHJNchv5Om9R1y9QkMlDO0JPPCbVPcPLkhy U8ynd+LiJeqx2CZjKtyZUIBv+Osj/ZOpMRju9lClQvLUiyjmJbYyN9+7mcT+r7aV vBEXhpFtMQgWvQP0jp7KQGRQKTXeBRsr =WKzv -----END PGP MESSAGE----- From owner-ietf-openpgp@mail.imc.org Fri Oct 20 02:06:33 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07555 for ; Fri, 20 Oct 2000 02:06:32 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28265 for ietf-openpgp-bks; Thu, 19 Oct 2000 22:33:27 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28261 for ; Thu, 19 Oct 2000 22:33:25 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13mVAI-0006IT-00; Fri, 20 Oct 2000 07:56:26 +0200 Date: Fri, 20 Oct 2000 07:56:26 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: MDC, gnupg 1.0.3, and PGP7 Message-ID: <20001020075626.G23958@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <00a001c039f8$a1cccc80$66c52609@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00a001c039f8$a1cccc80$66c52609@mwyoung.transarc.com>; from mwy-opgp97@the-youngs.org on Thu, Oct 19, 2000 at 02:15:57PM -0400 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 19 Oct 2000, Michael Young wrote: > Do you still have the examples generated by PGP7 that you used for > interoperability testing? See Hal's mail. > >The MDC packet is not listed due to a bug/implementation issue. > > > Do you believe the bug is in the generation, or in the parsing? No, it is due to the way it is implemented. The MDC check is done by the decryption fucntion. > I believe that it's in the generation: the compressed data packet uses > an old-style indeterminate length, leading your parser (and mine) to I am not sure but I thing this is allowed. Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de From owner-ietf-openpgp@mail.imc.org Mon Oct 23 02:21:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06226 for ; Mon, 23 Oct 2000 02:21:46 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA19003 for ietf-openpgp-bks; Sun, 22 Oct 2000 22:41:29 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA18999 for ; Sun, 22 Oct 2000 22:41:26 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A42514360192; Mon, 23 Oct 2000 13:48:37 0800 Message-Id: <5.0.0.25.0.20001023132916.00a75e80@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Oct 2000 13:41:10 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Public Key-Rings Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, We have downloaded a PGP 5.0 Key from a key-server and, expecting a CTB as the first byte (ie 0xC6) of the public key-ring, we are getting 0x99... Does anyone know WTF is going on? Also, if we are reading some other format/version of a "transferable public key" other than OpenPGP, does anyone know of a key-server whereby we can obtain "transferable public key" data based on OpenPGP for testing purposes? Thanks for any info (and excuse me if I'm missing something :) From owner-ietf-openpgp@mail.imc.org Mon Oct 23 03:39:00 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01892 for ; Mon, 23 Oct 2000 03:39:00 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA23315 for ietf-openpgp-bks; Mon, 23 Oct 2000 00:16:40 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA23310 for ; Mon, 23 Oct 2000 00:16:37 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA9D44101AC; Mon, 23 Oct 2000 15:24:29 0800 Message-Id: <5.0.0.25.0.20001023151624.024ccf18@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Oct 2000 15:16:33 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: the joys of public key-rings (NOT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, We have downloaded a PGP 5.0 Key-Ring from a key-server and expecting a new format (OpenPGP) header (0xC6) with a version 4 public key (new format packet), we are getting an old format header (0x99) with a version 4 public key (new format packet)! So, what to do for the transfer of public key-rings???? Do we use: 1) old format headers with old format packets 2) old format headers with new format packets 3) new format headers with old format packets, or: 4) new format headers with new format packets??? Please help as we are just sitting here drinking lots and want to get back to programming and testing... TIA. From owner-ietf-openpgp@mail.imc.org Mon Oct 23 12:33:02 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09799 for ; Mon, 23 Oct 2000 12:33:01 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA15849 for ietf-openpgp-bks; Mon, 23 Oct 2000 09:03:20 -0700 (PDT) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15845 for ; Mon, 23 Oct 2000 09:03:19 -0700 (PDT) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA17728; Mon, 23 Oct 2000 11:42:16 -0400 (EDT) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id MAA01048; Mon, 23 Oct 2000 12:08:00 -0400 (EDT) Message-ID: <00ab01c03d0b$11c60aa0$66c52609@mwyoung.transarc.com> From: "Michael Young" To: "Erron Criddle" Cc: Subject: Re: the joys of public key-rings (NOT) Date: Mon, 23 Oct 2000 12:05:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Are you asking whether it's legal to use an old-style header (single byte for tag + length) on a version-4 key? Yes, it's legal to use old-style headers whenever you are able. Is it legal to use a new-style header on a version-3 key? Sure, if you don't care about PGP2 compatibility. Is it legal to generate the same key value in both version-3 and version-4 forms? Yes, but since signatures hash the whole key packet, they will refer to only one version or the other, so you can't mix and match. (You could also have the same key value with different creation times, which would all hash differently, and in v4 would generate different fingerprints.) Are you asking what you should generate? If you know in advance that you're generating material that PGP2 won't understand, you might use a new-style packet to catch the incompatibility right away. If you don't know, you might use old-style. Some other esoteric considerations (that you probably should ignore): If you get all excited about extra bytes, old-style encoding can be shorter. If you don't want to compute packet lengths up front, it would appear that an old-style indeterminate-length packet is legal for a single key in a file, but the new-style partial-body scheme is not. From owner-ietf-openpgp@mail.imc.org Mon Oct 23 12:54:50 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13000 for ; Mon, 23 Oct 2000 12:54:49 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16238 for ietf-openpgp-bks; Mon, 23 Oct 2000 09:18:24 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16234 for ; Mon, 23 Oct 2000 09:18:22 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA25476; Mon, 23 Oct 2000 12:23:45 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id MAA08520; Mon, 23 Oct 2000 12:23:13 -0400 Date: Mon, 23 Oct 2000 12:23:13 -0400 From: Tom Zerucha To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: the joys of public key-rings (NOT) Message-ID: <20001023122313.B8511@deimos.mw.mediaone.net> References: <5.0.0.25.0.20001023151624.024ccf18@203.38.66.7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <5.0.0.25.0.20001023151624.024ccf18@203.38.66.7>; from ejc@comasp.com on Mon, Oct 23, 2000 at 03:16:33PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Oct 23, 2000 at 03:16:33PM +0800, Erron Criddle wrote: > To all, > > We have downloaded a PGP 5.0 Key-Ring from a key-server and expecting a new > format (OpenPGP) header (0xC6) with a version 4 public key (new format > packet), we are getting an old format header (0x99) with a version 4 public > key (new format packet)! This is withing spec. > So, what to do for the transfer of public key-rings???? > > Do we use: > > 1) old format headers with old format packets > 2) old format headers with new format packets > 3) new format headers with old format packets, or: > 4) new format headers with new format packets??? Yes. In that you should accept all formats. The header/encapsulation should be separate from the actual packet formats. > Please help as we are just sitting here drinking lots and want to get back > to programming and testing... If you want to be nice, you should encapsulate old format packets in old format headers, and new in new. From owner-ietf-openpgp@mail.imc.org Fri Oct 27 03:01:51 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA23851 for ; Fri, 27 Oct 2000 03:01:50 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA19684 for ietf-openpgp-bks; Thu, 26 Oct 2000 23:37:54 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA19672 for ; Thu, 26 Oct 2000 23:37:51 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A79FC25500B6; Fri, 27 Oct 2000 14:46:07 0800 Message-Id: <5.0.0.25.0.20001027143533.0232bb88@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 27 Oct 2000 14:37:54 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: MDC Usage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, I was wondering where\why you would use the tag 18 and 19 packets? TIA. Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Oct 27 04:43:24 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28810 for ; Fri, 27 Oct 2000 04:43:24 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA06519 for ietf-openpgp-bks; Fri, 27 Oct 2000 01:19:57 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06515 for ; Fri, 27 Oct 2000 01:19:55 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13p52S-0001VB-00; Fri, 27 Oct 2000 10:39:00 +0200 Date: Fri, 27 Oct 2000 10:39:00 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: MDC Usage Message-ID: <20001027103900.D5691@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <5.0.0.25.0.20001027143533.0232bb88@203.38.66.7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20001027143533.0232bb88@203.38.66.7>; from ejc@comasp.com on Fri, Oct 27, 2000 at 02:37:54PM +0800 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 27 Oct 2000, Erron Criddle wrote: > I was wondering where\why you would use the tag 18 and 19 packets? To replace packet 9. To avoid attacks like "A Choosen Ciphertext Attack Against Several E-Mail Encryption Protocols" by Katz and Schneier, June 23rd, 2000 presented at the last [I am not sure] Crypto - you should be able to find that paper at the Counterpane site. Werner From owner-ietf-openpgp@mail.imc.org Fri Oct 27 05:26:18 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12471 for ; Fri, 27 Oct 2000 05:26:17 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA10140 for ietf-openpgp-bks; Fri, 27 Oct 2000 01:47:21 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA10134 for ; Fri, 27 Oct 2000 01:47:19 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5F8D30E00B6; Fri, 27 Oct 2000 16:55:36 0800 Message-Id: <5.0.0.25.0.20001027163917.0240aad0@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 27 Oct 2000 16:47:22 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: 2 octet length determination Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, After a lot of "wondering" about how to write a version 4 two octet length, I thought it would be nice to post this for a two octet length (192 to 8383 octets): let a = (total data packet length) - 192 let bc = two octet representation of a let d = b + 192 From this, the two octet value to write is equal to dc. Nice and easy :) 2440bis/4.2.2.2 tells you how to determine that packet length from a two octet length, however it does not tell you how to code the two octet length packet and it may be worth adding the above simplified formula for us dummies. Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Fri Oct 27 12:22:08 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16288 for ; Fri, 27 Oct 2000 12:22:06 -0400 (EDT) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16962 for ietf-openpgp-bks; Fri, 27 Oct 2000 08:48:41 -0700 (PDT) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16958 for ; Fri, 27 Oct 2000 08:48:40 -0700 (PDT) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA17372 for ; Fri, 27 Oct 2000 11:28:03 -0400 (EDT) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA09238 for ; Fri, 27 Oct 2000 11:53:56 -0400 (EDT) Message-ID: <004901c0402d$bbaa9ac0$66c52609@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: MDC Usage Date: Fri, 27 Oct 2000 11:51:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit As the name suggests, an MDC helps detect modifications. Without an MDC, an attacker has a fair chance of changing the end of the file without it being noticed. Suppose I change a byte in the last cipher-block of a "classic PGP" message. Because PGP uses a CFB mode, this changes the corresponding byte of the plaintext, and nothing else. (It would completely change subsequent blocks, but there aren't any more.) If the plaintext is human-readable text, there is a fair chance that this would change one word to another, such that the human reader won't realize that tampering had occurred. Worse, if the data has no internal consistency check (raw binary data), this attack could be applied to anything after the salt+2 check bytes. If the message is encoded using the indeterminate packet length feature, an attacker could also just truncate the message. The MDC itself is redundant data that can be used as a consistency check. The variant on the symmetric data packet is necessary to ensure that a receiver knows an MDC packet will appear, both so that it can hash the plaintext as it goes and so that it can detect the MDC being cut off; it uses a different CFB resync to make it harder to tweak this new packet into an old one undetected (at which point the MDC could be stripped). There was a lengthy discussion on the MDC proposal on the mailing list. (I wasn't reading it at the time, but img.org maintains an archive.) From owner-ietf-openpgp@mail.imc.org Mon Oct 30 04:07:29 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA01860 for ; Mon, 30 Oct 2000 04:07:28 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id AAA01914 for ietf-openpgp-bks; Mon, 30 Oct 2000 00:40:45 -0800 (PST) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA01894 for ; Mon, 30 Oct 2000 00:40:36 -0800 (PST) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A6F5D40019E; Mon, 30 Oct 2000 16:48:53 0800 Message-Id: <5.0.0.25.0.20001030161030.01c0ca20@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 16:40:26 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: version 3 header & USER ID packet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, We have been reading a public key-ring and have noticed that the CTB for the user id is: 10110101 that says: 10: Version 3 header 1101: User ID packet 01: 2 octet length Now when I read the "File Formats Used by PGP 2.x", it says (under the User ID packet) that a User ID packet has a length of 1 octet. From this, either two things have happened: a) The program that wrote the key-ring has used a default "two byte" length identifier when a CTB is created and when the User ID CTB has been created it simply leaves this as the User ID always uses a 1 octet length identifier with a version 3 header (as "File Formats used by PGP 2.x" indicates). b) The public key-ring is bad. Now, if b) should be followed then OK, however if a) should be followed, is there any other packets that follow this peculiar line? I though that when a version 3 CTB is created for a User ID, it should read 10110100, indicating a 1 octet length for the user ID, not 10110101??? TIA for the clarification... Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Mon Oct 30 13:49:47 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16496 for ; Mon, 30 Oct 2000 13:49:47 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id KAA18384 for ietf-openpgp-bks; Mon, 30 Oct 2000 10:22:18 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA18380 for ; Mon, 30 Oct 2000 10:22:17 -0800 (PST) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA09173; Mon, 30 Oct 2000 10:22:57 -0800 Date: Mon, 30 Oct 2000 10:22:57 -0800 Message-Id: <200010301822.KAA09173@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: version 3 header & USER ID packet Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron writes: > We have been reading a public key-ring and have noticed that the CTB for > the user id is: > > 10110101 that says: > > 10: Version 3 header > 1101: User ID packet > 01: 2 octet length > > Now when I read the "File Formats Used by PGP 2.x", it says (under the User > ID packet) that a User ID packet has a length of 1 octet. If the CTB says there is a two byte length, there better be a two byte length. It doesn't matter what "File Formats used by PGP 2.x" says, after all, this CTB may not have been created by PGP 2.x. Was there in fact a two byte length in this userid packet? I.e. did the next two bytes look like a reasonable length field? If so, just use them. If not, then it's a bad keyring. Hal From owner-ietf-openpgp@mail.imc.org Tue Oct 31 03:01:03 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26218 for ; Tue, 31 Oct 2000 03:01:02 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06636 for ietf-openpgp-bks; Mon, 30 Oct 2000 23:42:15 -0800 (PST) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA06629 for ; Mon, 30 Oct 2000 23:42:11 -0800 (PST) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AAD5D1E600B6; Tue, 31 Oct 2000 15:50:45 0800 Message-Id: <5.0.0.25.1.20001031153331.00a62c50@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 31 Oct 2000 15:42:15 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: version 3 header & USER ID packet Cc: hal@finney.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:22 AM 30/10/2000 -0800, hal@finney.org wrote: >Erron writes: > > We have been reading a public key-ring and have noticed that the CTB for > > the user id is: > > > > 10110101 that says: > > > > 10: Version 3 header > > 1101: User ID packet > > 01: 2 octet length > > > > Now when I read the "File Formats Used by PGP 2.x", it says (under the > User > > ID packet) that a User ID packet has a length of 1 octet. > >If the CTB says there is a two byte length, there better be a two byte >length. It doesn't matter what "File Formats used by PGP 2.x" says, >after all, this CTB may not have been created by PGP 2.x. not in this case. >Was there in fact a two byte length in this userid packet? no. > I.e. did the next two bytes look like a reasonable length field? If > so, just use them. >If not, then it's a bad keyring. The version 3 CTB's last 2 bits were 01, indicating a two byte length field, however there was only one length byte (this worked in with the length of the User ID field (39 octets)). Has anyone else any comments on this? This key-ring that was extracted is from any one of the key-servers located at: http://math-www.uni-paderborn.de/pgp/ or: http://www.rediris.es/cert/index.en.html or: http://keys.pgp.com:11371/ (the NAI server!) using the keyword of: 0xFC4CC190 As many PGP key-servers contain this key-ring with a 2 byte length identifier in the CTB (see http://www.openpgp.net/pgpsrv.html) and a 1 byte length identifier for the actual User ID packet, what should we do? Should we accept it or have all the keyservers change their software so they check each transferred key-ring for mistakes like these? The latter seems a very large task. Or is it easier to assume a 1 octet length indentifier for the User ID? Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com From owner-ietf-openpgp@mail.imc.org Tue Oct 31 11:37:57 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08622 for ; Tue, 31 Oct 2000 11:37:56 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id IAA09729 for ietf-openpgp-bks; Tue, 31 Oct 2000 08:12:29 -0800 (PST) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09720 for ; Tue, 31 Oct 2000 08:12:26 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA56224 for ; Tue, 31 Oct 2000 10:52:06 -0500 (EST) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA09294 for ; Tue, 31 Oct 2000 11:18:08 -0500 (EST) Message-ID: <003d01c04355$d8f6ada0$66c52609@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: version 3 header & USER ID packet Date: Tue, 31 Oct 2000 11:15:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit >> > We have been reading a public key-ring and have noticed that the CTB for >> > the user id is: >> > >> > 10110101 that says: ... >This key-ring that was extracted is from any one of the key-servers located at: >http://www.rediris.es/cert/index.en.html or: >0xFC4CC190 The key I got back has 0xb4 (10110100) as the header byte for the user packet, indicating a one-byte length. The whole thing parsed just fine for me. From owner-ietf-openpgp@mail.imc.org Tue Oct 31 21:15:36 2000 Received: from ns.secondary.com (ns.secondary.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24454 for ; Tue, 31 Oct 2000 21:15:36 -0500 (EST) Received: by ns.secondary.com (8.9.3/8.9.3) id RAA22874 for ietf-openpgp-bks; Tue, 31 Oct 2000 17:47:56 -0800 (PST) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA22869 for ; Tue, 31 Oct 2000 17:47:51 -0800 (PST) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A92F15DA01E0; Wed, 01 Nov 2000 09:55:59 0800 Message-Id: <5.0.0.25.1.20001101094426.023089c8@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 01 Nov 2000 09:47:27 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: version 3 header & USER ID packet Cc: "Michael Young" In-Reply-To: <003d01c04355$d8f6ada0$66c52609@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:15 AM 31/10/2000 -0500, "Michael Young" wrote: > >> > We have been reading a public key-ring and have noticed that the CTB for > >> > the user id is: > >> > > >> > 10110101 that says: >... > >This key-ring that was extracted is from any one of the key-servers > located at: > >http://www.rediris.es/cert/index.en.html or: > >0xFC4CC190 > >The key I got back has 0xb4 (10110100) as the header byte for the user packet, >indicating a one-byte length. The whole thing parsed just fine for me. Funny enough, so did we when I got the programmer to look at it again...apparently he changed some code last night and now its producing the right result!!! Sorry for the wasted bandwidth :) Also Michael, thanks for re-analysis :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id RAA22874 for ietf-openpgp-bks; Tue, 31 Oct 2000 17:47:56 -0800 (PST) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id RAA22869 for ; Tue, 31 Oct 2000 17:47:51 -0800 (PST) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A92F15DA01E0; Wed, 01 Nov 2000 09:55:59 0800 Message-Id: <5.0.0.25.1.20001101094426.023089c8@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 01 Nov 2000 09:47:27 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: version 3 header & USER ID packet Cc: "Michael Young" In-Reply-To: <003d01c04355$d8f6ada0$66c52609@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:15 AM 31/10/2000 -0500, "Michael Young" wrote: > >> > We have been reading a public key-ring and have noticed that the CTB for > >> > the user id is: > >> > > >> > 10110101 that says: >... > >This key-ring that was extracted is from any one of the key-servers > located at: > >http://www.rediris.es/cert/index.en.html or: > >0xFC4CC190 > >The key I got back has 0xb4 (10110100) as the header byte for the user packet, >indicating a one-byte length. The whole thing parsed just fine for me. Funny enough, so did we when I got the programmer to look at it again...apparently he changed some code last night and now its producing the right result!!! Sorry for the wasted bandwidth :) Also Michael, thanks for re-analysis :) Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id IAA09729 for ietf-openpgp-bks; Tue, 31 Oct 2000 08:12:29 -0800 (PST) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA09720 for ; Tue, 31 Oct 2000 08:12:26 -0800 (PST) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id KAA56224 for ; Tue, 31 Oct 2000 10:52:06 -0500 (EST) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA09294 for ; Tue, 31 Oct 2000 11:18:08 -0500 (EST) Message-ID: <003d01c04355$d8f6ada0$66c52609@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: version 3 header & USER ID packet Date: Tue, 31 Oct 2000 11:15:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: >> > We have been reading a public key-ring and have noticed that the CTB for >> > the user id is: >> > >> > 10110101 that says: ... >This key-ring that was extracted is from any one of the key-servers located at: >http://www.rediris.es/cert/index.en.html or: >0xFC4CC190 The key I got back has 0xb4 (10110100) as the header byte for the user packet, indicating a one-byte length. The whole thing parsed just fine for me. Received: by ns.secondary.com (8.9.3/8.9.3) id XAA06636 for ietf-openpgp-bks; Mon, 30 Oct 2000 23:42:15 -0800 (PST) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA06629 for ; Mon, 30 Oct 2000 23:42:11 -0800 (PST) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AAD5D1E600B6; Tue, 31 Oct 2000 15:50:45 0800 Message-Id: <5.0.0.25.1.20001031153331.00a62c50@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 31 Oct 2000 15:42:15 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: version 3 header & USER ID packet Cc: hal@finney.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:22 AM 30/10/2000 -0800, hal@finney.org wrote: >Erron writes: > > We have been reading a public key-ring and have noticed that the CTB for > > the user id is: > > > > 10110101 that says: > > > > 10: Version 3 header > > 1101: User ID packet > > 01: 2 octet length > > > > Now when I read the "File Formats Used by PGP 2.x", it says (under the > User > > ID packet) that a User ID packet has a length of 1 octet. > >If the CTB says there is a two byte length, there better be a two byte >length. It doesn't matter what "File Formats used by PGP 2.x" says, >after all, this CTB may not have been created by PGP 2.x. not in this case. >Was there in fact a two byte length in this userid packet? no. > I.e. did the next two bytes look like a reasonable length field? If > so, just use them. >If not, then it's a bad keyring. The version 3 CTB's last 2 bits were 01, indicating a two byte length field, however there was only one length byte (this worked in with the length of the User ID field (39 octets)). Has anyone else any comments on this? This key-ring that was extracted is from any one of the key-servers located at: http://math-www.uni-paderborn.de/pgp/ or: http://www.rediris.es/cert/index.en.html or: http://keys.pgp.com:11371/ (the NAI server!) using the keyword of: 0xFC4CC190 As many PGP key-servers contain this key-ring with a 2 byte length identifier in the CTB (see http://www.openpgp.net/pgpsrv.html) and a 1 byte length identifier for the actual User ID packet, what should we do? Should we accept it or have all the keyservers change their software so they check each transferred key-ring for mistakes like these? The latter seems a very large task. Or is it easier to assume a 1 octet length indentifier for the User ID? Regards Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id KAA18384 for ietf-openpgp-bks; Mon, 30 Oct 2000 10:22:18 -0800 (PST) Received: from computer (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id KAA18380 for ; Mon, 30 Oct 2000 10:22:17 -0800 (PST) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id KAA09173; Mon, 30 Oct 2000 10:22:57 -0800 Date: Mon, 30 Oct 2000 10:22:57 -0800 Message-Id: <200010301822.KAA09173@finney.org> To: ejc@comasp.com, ietf-openpgp@imc.org Subject: Re: version 3 header & USER ID packet Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Erron writes: > We have been reading a public key-ring and have noticed that the CTB for > the user id is: > > 10110101 that says: > > 10: Version 3 header > 1101: User ID packet > 01: 2 octet length > > Now when I read the "File Formats Used by PGP 2.x", it says (under the User > ID packet) that a User ID packet has a length of 1 octet. If the CTB says there is a two byte length, there better be a two byte length. It doesn't matter what "File Formats used by PGP 2.x" says, after all, this CTB may not have been created by PGP 2.x. Was there in fact a two byte length in this userid packet? I.e. did the next two bytes look like a reasonable length field? If so, just use them. If not, then it's a bad keyring. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id AAA01914 for ietf-openpgp-bks; Mon, 30 Oct 2000 00:40:45 -0800 (PST) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA01894 for ; Mon, 30 Oct 2000 00:40:36 -0800 (PST) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A6F5D40019E; Mon, 30 Oct 2000 16:48:53 0800 Message-Id: <5.0.0.25.0.20001030161030.01c0ca20@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 30 Oct 2000 16:40:26 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: version 3 header & USER ID packet Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, We have been reading a public key-ring and have noticed that the CTB for the user id is: 10110101 that says: 10: Version 3 header 1101: User ID packet 01: 2 octet length Now when I read the "File Formats Used by PGP 2.x", it says (under the User ID packet) that a User ID packet has a length of 1 octet. From this, either two things have happened: a) The program that wrote the key-ring has used a default "two byte" length identifier when a CTB is created and when the User ID CTB has been created it simply leaves this as the User ID always uses a 1 octet length identifier with a version 3 header (as "File Formats used by PGP 2.x" indicates). b) The public key-ring is bad. Now, if b) should be followed then OK, however if a) should be followed, is there any other packets that follow this peculiar line? I though that when a version 3 CTB is created for a User ID, it should read 10110100, indicating a 1 octet length for the user ID, not 10110101??? TIA for the clarification... Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id IAA16962 for ietf-openpgp-bks; Fri, 27 Oct 2000 08:48:41 -0700 (PDT) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA16958 for ; Fri, 27 Oct 2000 08:48:40 -0700 (PDT) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA17372 for ; Fri, 27 Oct 2000 11:28:03 -0400 (EDT) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id LAA09238 for ; Fri, 27 Oct 2000 11:53:56 -0400 (EDT) Message-ID: <004901c0402d$bbaa9ac0$66c52609@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: MDC Usage Date: Fri, 27 Oct 2000 11:51:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: As the name suggests, an MDC helps detect modifications. Without an MDC, an attacker has a fair chance of changing the end of the file without it being noticed. Suppose I change a byte in the last cipher-block of a "classic PGP" message. Because PGP uses a CFB mode, this changes the corresponding byte of the plaintext, and nothing else. (It would completely change subsequent blocks, but there aren't any more.) If the plaintext is human-readable text, there is a fair chance that this would change one word to another, such that the human reader won't realize that tampering had occurred. Worse, if the data has no internal consistency check (raw binary data), this attack could be applied to anything after the salt+2 check bytes. If the message is encoded using the indeterminate packet length feature, an attacker could also just truncate the message. The MDC itself is redundant data that can be used as a consistency check. The variant on the symmetric data packet is necessary to ensure that a receiver knows an MDC packet will appear, both so that it can hash the plaintext as it goes and so that it can detect the MDC being cut off; it uses a different CFB resync to make it harder to tweak this new packet into an old one undetected (at which point the MDC could be stripped). There was a lengthy discussion on the MDC proposal on the mailing list. (I wasn't reading it at the time, but img.org maintains an archive.) Received: by ns.secondary.com (8.9.3/8.9.3) id BAA10140 for ietf-openpgp-bks; Fri, 27 Oct 2000 01:47:21 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id BAA10134 for ; Fri, 27 Oct 2000 01:47:19 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A5F8D30E00B6; Fri, 27 Oct 2000 16:55:36 0800 Message-Id: <5.0.0.25.0.20001027163917.0240aad0@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 27 Oct 2000 16:47:22 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: 2 octet length determination Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, After a lot of "wondering" about how to write a version 4 two octet length, I thought it would be nice to post this for a two octet length (192 to 8383 octets): let a = (total data packet length) - 192 let bc = two octet representation of a let d = b + 192 From this, the two octet value to write is equal to dc. Nice and easy :) 2440bis/4.2.2.2 tells you how to determine that packet length from a two octet length, however it does not tell you how to code the two octet length packet and it may be worth adding the above simplified formula for us dummies. Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id BAA06519 for ietf-openpgp-bks; Fri, 27 Oct 2000 01:19:57 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06515 for ; Fri, 27 Oct 2000 01:19:55 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13p52S-0001VB-00; Fri, 27 Oct 2000 10:39:00 +0200 Date: Fri, 27 Oct 2000 10:39:00 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: MDC Usage Message-ID: <20001027103900.D5691@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <5.0.0.25.0.20001027143533.0232bb88@203.38.66.7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20001027143533.0232bb88@203.38.66.7>; from ejc@comasp.com on Fri, Oct 27, 2000 at 02:37:54PM +0800 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Fri, 27 Oct 2000, Erron Criddle wrote: > I was wondering where\why you would use the tag 18 and 19 packets? To replace packet 9. To avoid attacks like "A Choosen Ciphertext Attack Against Several E-Mail Encryption Protocols" by Katz and Schneier, June 23rd, 2000 presented at the last [I am not sure] Crypto - you should be able to find that paper at the Counterpane site. Werner Received: by ns.secondary.com (8.9.3/8.9.3) id XAA19684 for ietf-openpgp-bks; Thu, 26 Oct 2000 23:37:54 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id XAA19672 for ; Thu, 26 Oct 2000 23:37:51 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A79FC25500B6; Fri, 27 Oct 2000 14:46:07 0800 Message-Id: <5.0.0.25.0.20001027143533.0232bb88@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Fri, 27 Oct 2000 14:37:54 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: MDC Usage Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, I was wondering where\why you would use the tag 18 and 19 packets? TIA. Erron Criddle Comasp Ltd. Level 2, 45 Stirling Hwy NEDLANDS WA 6009 Australia Fax: +61 8 9386 9473 Tel: + 61 8 9386 9534 http://www.comasp.com ejc@comasp.com Received: by ns.secondary.com (8.9.3/8.9.3) id JAA16238 for ietf-openpgp-bks; Mon, 23 Oct 2000 09:18:24 -0700 (PDT) Received: from demai05.mw.mediaone.net (demai05.mw.mediaone.net [24.131.1.56]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA16234 for ; Mon, 23 Oct 2000 09:18:22 -0700 (PDT) Received: from deimos.ceddec.com (nic-30-c64-170.mw.mediaone.net [24.30.64.170]) by demai05.mw.mediaone.net (8.8.7/8.8.7) with ESMTP id MAA25476; Mon, 23 Oct 2000 12:23:45 -0400 (EDT) Received: (from nobody@localhost) by deimos.ceddec.com (8.9.3/8.9.3) id MAA08520; Mon, 23 Oct 2000 12:23:13 -0400 Date: Mon, 23 Oct 2000 12:23:13 -0400 From: Tom Zerucha To: Erron Criddle Cc: ietf-openpgp@imc.org Subject: Re: the joys of public key-rings (NOT) Message-ID: <20001023122313.B8511@deimos.mw.mediaone.net> References: <5.0.0.25.0.20001023151624.024ccf18@203.38.66.7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <5.0.0.25.0.20001023151624.024ccf18@203.38.66.7>; from ejc@comasp.com on Mon, Oct 23, 2000 at 03:16:33PM +0800 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, Oct 23, 2000 at 03:16:33PM +0800, Erron Criddle wrote: > To all, > > We have downloaded a PGP 5.0 Key-Ring from a key-server and expecting a new > format (OpenPGP) header (0xC6) with a version 4 public key (new format > packet), we are getting an old format header (0x99) with a version 4 public > key (new format packet)! This is withing spec. > So, what to do for the transfer of public key-rings???? > > Do we use: > > 1) old format headers with old format packets > 2) old format headers with new format packets > 3) new format headers with old format packets, or: > 4) new format headers with new format packets??? Yes. In that you should accept all formats. The header/encapsulation should be separate from the actual packet formats. > Please help as we are just sitting here drinking lots and want to get back > to programming and testing... If you want to be nice, you should encapsulate old format packets in old format headers, and new in new. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA15849 for ietf-openpgp-bks; Mon, 23 Oct 2000 09:03:20 -0700 (PDT) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA15845 for ; Mon, 23 Oct 2000 09:03:19 -0700 (PDT) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id LAA17728; Mon, 23 Oct 2000 11:42:16 -0400 (EDT) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id MAA01048; Mon, 23 Oct 2000 12:08:00 -0400 (EDT) Message-ID: <00ab01c03d0b$11c60aa0$66c52609@mwyoung.transarc.com> From: "Michael Young" To: "Erron Criddle" Cc: Subject: Re: the joys of public key-rings (NOT) Date: Mon, 23 Oct 2000 12:05:31 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Are you asking whether it's legal to use an old-style header (single byte for tag + length) on a version-4 key? Yes, it's legal to use old-style headers whenever you are able. Is it legal to use a new-style header on a version-3 key? Sure, if you don't care about PGP2 compatibility. Is it legal to generate the same key value in both version-3 and version-4 forms? Yes, but since signatures hash the whole key packet, they will refer to only one version or the other, so you can't mix and match. (You could also have the same key value with different creation times, which would all hash differently, and in v4 would generate different fingerprints.) Are you asking what you should generate? If you know in advance that you're generating material that PGP2 won't understand, you might use a new-style packet to catch the incompatibility right away. If you don't know, you might use old-style. Some other esoteric considerations (that you probably should ignore): If you get all excited about extra bytes, old-style encoding can be shorter. If you don't want to compute packet lengths up front, it would appear that an old-style indeterminate-length packet is legal for a single key in a file, but the new-style partial-body scheme is not. Received: by ns.secondary.com (8.9.3/8.9.3) id AAA23315 for ietf-openpgp-bks; Mon, 23 Oct 2000 00:16:40 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA23310 for ; Mon, 23 Oct 2000 00:16:37 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id AA9D44101AC; Mon, 23 Oct 2000 15:24:29 0800 Message-Id: <5.0.0.25.0.20001023151624.024ccf18@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Oct 2000 15:16:33 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: the joys of public key-rings (NOT) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, We have downloaded a PGP 5.0 Key-Ring from a key-server and expecting a new format (OpenPGP) header (0xC6) with a version 4 public key (new format packet), we are getting an old format header (0x99) with a version 4 public key (new format packet)! So, what to do for the transfer of public key-rings???? Do we use: 1) old format headers with old format packets 2) old format headers with new format packets 3) new format headers with old format packets, or: 4) new format headers with new format packets??? Please help as we are just sitting here drinking lots and want to get back to programming and testing... TIA. Received: by ns.secondary.com (8.9.3/8.9.3) id WAA19003 for ietf-openpgp-bks; Sun, 22 Oct 2000 22:41:29 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id WAA18999 for ; Sun, 22 Oct 2000 22:41:26 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A42514360192; Mon, 23 Oct 2000 13:48:37 0800 Message-Id: <5.0.0.25.0.20001023132916.00a75e80@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 23 Oct 2000 13:41:10 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Public Key-Rings Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, We have downloaded a PGP 5.0 Key from a key-server and, expecting a CTB as the first byte (ie 0xC6) of the public key-ring, we are getting 0x99... Does anyone know WTF is going on? Also, if we are reading some other format/version of a "transferable public key" other than OpenPGP, does anyone know of a key-server whereby we can obtain "transferable public key" data based on OpenPGP for testing purposes? Thanks for any info (and excuse me if I'm missing something :) Received: by ns.secondary.com (8.9.3/8.9.3) id WAA28265 for ietf-openpgp-bks; Thu, 19 Oct 2000 22:33:27 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA28261 for ; Thu, 19 Oct 2000 22:33:25 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13mVAI-0006IT-00; Fri, 20 Oct 2000 07:56:26 +0200 Date: Fri, 20 Oct 2000 07:56:26 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: MDC, gnupg 1.0.3, and PGP7 Message-ID: <20001020075626.G23958@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <00a001c039f8$a1cccc80$66c52609@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <00a001c039f8$a1cccc80$66c52609@mwyoung.transarc.com>; from mwy-opgp97@the-youngs.org on Thu, Oct 19, 2000 at 02:15:57PM -0400 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 19 Oct 2000, Michael Young wrote: > Do you still have the examples generated by PGP7 that you used for > interoperability testing? See Hal's mail. > >The MDC packet is not listed due to a bug/implementation issue. > > > Do you believe the bug is in the generation, or in the parsing? No, it is due to the way it is implemented. The MDC check is done by the decryption fucntion. > I believe that it's in the generation: the compressed data packet uses > an old-style indeterminate length, leading your parser (and mine) to I am not sure but I thing this is allowed. Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id PAA13437 for ietf-openpgp-bks; Thu, 19 Oct 2000 15:26:46 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA13432 for ; Thu, 19 Oct 2000 15:26:40 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA04665; Thu, 19 Oct 2000 15:26:57 -0700 Date: Thu, 19 Oct 2000 15:26:57 -0700 Message-Id: <200010192226.PAA04665@finney.org> To: ietf-openpgp@imc.org, mwy-opgp97@the-youngs.org Subject: Re: MDC, gnupg 1.0.3, and PGP7 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Here are two MDC test messages created by PGP 7. The first uses Twofish, the second 3DES. The passphrase for each is "test". I wanted to test both to make sure we interoperate properly with both 64 bit and 128 bit block ciphers. Hal -----BEGIN PGP MESSAGE----- Version: PGPsdk 2.0d20 Copyright (C) 2000 Networks Associates Technology, Inc. A ll rights reserved. qANQR1DDDQQKAwKbEffw1iOFWWDSagG2TUxTd8SWAFCCrwUfH+T0ENGoWmmL+R07 8ZD9CB3OnyBqz/zEVBi4aOrbuYPbJMCImPIt669wwIUx0XmaxwLQZufRCbnU/z1g H/ElneG43J83HCFsHsFGtT7V6Uzq1nOjGaX9Dxpma8I= =tXQ6 -----END PGP MESSAGE----- -----BEGIN PGP MESSAGE----- Version: PGPsdk 2.0d20 Copyright (C) 2000 Networks Associates Technology, Inc. A ll rights reserved. qANQR1DDDQQCAwIQP0qEoEdt7WDSYgHJNchv5Om9R1y9QkMlDO0JPPCbVPcPLkhy U8ynd+LiJeqx2CZjKtyZUIBv+Osj/ZOpMRju9lClQvLUiyjmJbYyN9+7mcT+r7aV vBEXhpFtMQgWvQP0jp7KQGRQKTXeBRsr =WKzv -----END PGP MESSAGE----- Received: by ns.secondary.com (8.9.3/8.9.3) id LAA06732 for ietf-openpgp-bks; Thu, 19 Oct 2000 11:13:35 -0700 (PDT) Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA06728 for ; Thu, 19 Oct 2000 11:13:34 -0700 (PDT) Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA12438 for ; Thu, 19 Oct 2000 13:52:34 -0400 (EDT) Received: from mwyoung.transarc.com (dhcp-197-102.transarc.ibm.com [9.38.197.102]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id OAA02900 for ; Thu, 19 Oct 2000 14:18:10 -0400 (EDT) Message-ID: <00a001c039f8$a1cccc80$66c52609@mwyoung.transarc.com> From: "Michael Young" To: Subject: Re: MDC, gnupg 1.0.3, and PGP7 Date: Thu, 19 Oct 2000 14:15:57 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Thanks for the examples from 1.0.4a. Do you still have the examples generated by PGP7 that you used for interoperability testing? >And here come the same thing with compression: ... >The MDC packet is not listed due to a bug/implementation issue. Do you believe the bug is in the generation, or in the parsing? I believe that it's in the generation: the compressed data packet uses an old-style indeterminate length, leading your parser (and mine) to treat the MDC packet as contained within it. Received: by ns.secondary.com (8.9.3/8.9.3) id KAA05691 for ietf-openpgp-bks; Thu, 19 Oct 2000 10:44:26 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA05687 for ; Thu, 19 Oct 2000 10:44:25 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id KAA04598 for ; Thu, 19 Oct 2000 10:49:40 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id KAA04594 for ; Thu, 19 Oct 2000 10:49:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20001019175309.M20744@gnupg.de> References: <000201c039ce$85434b40$023fa8c0@mwyoung.transarc.com> <20001019175309.M20744@gnupg.de> Date: Thu, 19 Oct 2000 10:47:01 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: MDC, gnupg 1.0.3, and PGP7 Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Re: MDC, gnupg 1.0.3, and PGP7", shown on 10/19/00), Werner Koch said: >The MDC packet is not listed due to a bug/implementation issue. > >From packet.h: > PKT_ENCRYPTED_MDC =18, /* integrity protected encrypted data */ > PKT_MDC =19, /* manipulaion detection code packet */ > I only do what the voices in my head tell me to. This time, the voices told me to use 15 and 16. :-) I'm changing them to 18 and 19. Send me some more changes/additions, folks and they'll go in, too. Otherwise, in a week or so, I'll just fling out another draft with this correction. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id IAA00338 for ietf-openpgp-bks; Thu, 19 Oct 2000 08:30:24 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA00324 for ; Thu, 19 Oct 2000 08:30:20 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13mI0D-0005dV-00; Thu, 19 Oct 2000 17:53:09 +0200 Date: Thu, 19 Oct 2000 17:53:09 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: MDC, gnupg 1.0.3, and PGP7 Message-ID: <20001019175309.M20744@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <000201c039ce$85434b40$023fa8c0@mwyoung.transarc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000201c039ce$85434b40$023fa8c0@mwyoung.transarc.com>; from mwy-opgp97@the-youngs.org on Thu, Oct 19, 2000 at 12:18:06AM -0400 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, 19 Oct 2000, Michael Young wrote: > revision of June 15 is dead. [That revision used tags 18 and 19, and 18 and 19 is right. > I note that gnupg 1.0.3 uses tag 18. As I started to write this, I noticed > that 1.0.4 was release in source form yesterday -- does it use tag 15 again? No. > Werner Koch's recent reply suggests that PGP7 also uses tag 15. I was wrong, it uses 18,19 and I did some interoperability tests. > Would someone be willing to post a sample encryption from PGP7 that uses > an MDC and Twofish? (I'd also love to see a secret key packet encrypted Passphrase "test" -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.4a (GNU/Linux) Comment: For info see http://www.gnupg.org jA0ECgMCUDpHpGjiZQlg0ooBAHDje+vcyFMyBA5bjCemhEVjPKly7+zNodZM9XwG Ks9NGi/dpYfKmUbpUzET1wZpIHEt81vDvVhP7VfLbhYvOBXlWxPyr1IV6Pjznkz/ XxYN8O2f276f/fJ45erHG41SS+N/jKrTYgOEJp5cSSzp6NkJ8hLTRYYSUlX21nYZ sAOiTw1s/j/nX9s= =Ymv/ -----END PGP MESSAGE----- Here are the packets: symkey enc packet: version 4, cipher 10, s2k 3, hash 2 salt 503a47a468e26509, count 96 :encrypted data packet: length: 137 mdc_method: 2 :literal data packet: mode b, created 971969290, name="geheim", raw data: 83 bytes :mdc packet: length=20 And here come the same thing with compression: -----BEGIN PGP MESSAGE----- Version: GnuPG v1.0.4a (GNU/Linux) Comment: For info see http://www.gnupg.org jA0ECgMC+Mkg2Ij8RYpg0ogBjrSClbfynZowH3o9HDfdSlhBM0IFf8cGqkpcu9Z9 tAF3SciSHV2RRWoObmcUDF5F4gOK81OzB40qbj8DAGHE8BgR13ze/PhswH51H1jY y6wXLackZ0WA2RYFh6UnbR/i/Gu8/jASOqu1Hmqmy8DK2mGEqfcm/oGGaxJz4e47 7lkaBDBuQfSo =AJBJ -----END PGP MESSAGE----- :symkey enc packet: version 4, cipher 10, s2k 3, hash 2 salt f8c920d888fc458a, count 96 :encrypted data packet: length: 135 mdc_method: 2 :compressed packet: algo=1 :literal data packet: mode b, created 971969488, name="geheim", raw data: 83 bytes The MDC packet is not listed due to a bug/implementation issue. >From packet.h: PKT_ENCRYPTED_MDC =18, /* integrity protected encrypted data */ PKT_MDC =19, /* manipulaion detection code packet */ Hth, Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id GAA23447 for ietf-openpgp-bks; Thu, 19 Oct 2000 06:12:25 -0700 (PDT) Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA23424 for ; Thu, 19 Oct 2000 06:12:14 -0700 (PDT) Received: from mwyoung.transarc.com ([24.48.233.14]) by smtprelay1.adelphia.net (Netscape Messaging Server 4.15) with SMTP id G2OI4400.1BY for ; Thu, 19 Oct 2000 09:14:28 -0400 Message-ID: <000201c039ce$85434b40$023fa8c0@mwyoung.transarc.com> From: "Michael Young" To: Subject: MDC, gnupg 1.0.3, and PGP7 Date: Thu, 19 Oct 2000 00:18:06 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I gather from Jon Callas's recent MDC spec message that his proposed revision of June 15 is dead. [That revision used tags 18 and 19, and purported to have the hash include the block+2 salt bytes (but wasn't changed consistently).] Is that right? I note that gnupg 1.0.3 uses tag 18. As I started to write this, I noticed that 1.0.4 was release in source form yesterday -- does it use tag 15 again? Werner Koch's recent reply suggests that PGP7 also uses tag 15. Would someone be willing to post a sample encryption from PGP7 that uses an MDC and Twofish? (I'd also love to see a secret key packet encrypted with Twofish.) My understanding of a reasonable packet sequence and proper containment is as follows: zero or more PKE- or SKE- session-key packets Protected-SE-data packet (tag 15) { version "1"; encrypted< block-size+2 random data (last two bytes repeated); % some packet(s?) { ... } -- typically a Compressed-data packet MDC packet (tag 16) % { 20-byte SHA hash result } > } where the hash occurs over the data between the two %-signs. The gnupg 1.0.3 release generates roughly this format, but it uses an indeterminate size for the Compressed-data packet. An implementation that treats an indeterminate size as that of the containing file or packet, as I think the spec implies, would consider the MDC packet to be extraneous junk at the end of the Compressed-data packet. Moreover, this approach won't work for the "uncompressed" algorithm, or for a Literal-data or other packets in the payload. Given that an MDC packet will follow, the receiver must understand new-style packets, so a partial-body representation should always be valid. Does this sound reasonable? [I apologize to Werner Koch for asking about his implementation in public, but I thought others might have yet other ideas on how this ought to work.] Would it be reasonable to specify the encrypted payload more precisely, something like "a sequence of OpenPGP packets, ending with an MDC packet"? The MDC packet section loosely implies this, but I think it would help to say so in the Protected-SE data packet section explicitly. Received: by ns.secondary.com (8.9.3/8.9.3) id CAA23586 for ietf-openpgp-bks; Mon, 16 Oct 2000 02:22:58 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA23581 for ; Mon, 16 Oct 2000 02:22:56 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13l6p4-0007Ju-00; Mon, 16 Oct 2000 11:44:46 +0200 Date: Mon, 16 Oct 2000 11:44:46 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: ElGamal & DSA Sample Keys Message-ID: <20001016114446.J27890@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <5.0.0.25.0.20001016111259.00aa0eb8@203.38.66.7> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <5.0.0.25.0.20001016111259.00aa0eb8@203.38.66.7>; from ejc@comasp.com on Mon, Oct 16, 2000 at 11:16:06AM +0800 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 16 Oct 2000, Erron Criddle wrote: > To all, > > I know this may be a bit off track, however I am looking for 2048 bit > ElGamal p and g keys as well as 1024 bit DSA p, q (160 bit) and g keys. $ gpg --gen-key $ gpg --with-key-data --list-key my-new-key See doc/DETAILS or g10/keylist.c for the format of the output. Ciao, Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id UAA11142 for ietf-openpgp-bks; Sun, 15 Oct 2000 20:16:29 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id UAA11138 for ; Sun, 15 Oct 2000 20:16:26 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A78A422E02A0; Mon, 16 Oct 2000 11:23:06 0800 Message-Id: <5.0.0.25.0.20001016111259.00aa0eb8@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Mon, 16 Oct 2000 11:16:06 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: ElGamal & DSA Sample Keys Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To all, I know this may be a bit off track, however I am looking for 2048 bit ElGamal p and g keys as well as 1024 bit DSA p, q (160 bit) and g keys. If anyone knows where I can generate/obtain these from it would be much appreciated as we need to do some testing :) TIA. Received: by ns.secondary.com (8.9.3/8.9.3) id CAA29834 for ietf-openpgp-bks; Thu, 12 Oct 2000 02:19:30 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA29830 for ; Thu, 12 Oct 2000 02:19:27 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13jeqI-0000i0-00; Thu, 12 Oct 2000 11:40:02 +0200 Date: Thu, 12 Oct 2000 11:40:02 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Another draft is going out Message-ID: <20001012114002.G2549@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: <20001011112552.I31259@gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jon@callas.org on Wed, Oct 11, 2000 at 11:59:53AM -0700 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 11 Oct 2000, Jon Callas wrote: > I don't think that tying MDC and big blocks is a good idea -- in the spec. The idea established at the time we introduced Twofish and talked about MDC. I suggested to wait with Twofish until we worked out the MDC stuff. Anyway, the specs are getting more and more complex, so we better don't do what I suggested. > If you want to limit use more, I have a suggestion: we put in a "feature" > of 128-bit-block ciphers. That way you can declare whether you use them or Too complicated. We already have the preferences and issue a warning when a received message is not encrypted by an algorithm listed in the preferences. So we can have the same effect by setting up the preferences right and issue a warning when the MUST algorithm 3DES has been used without MDC. Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id MAA03233 for ietf-openpgp-bks; Wed, 11 Oct 2000 12:01:34 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id MAA03229 for ; Wed, 11 Oct 2000 12:01:33 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id MAA07562; Wed, 11 Oct 2000 12:06:08 -0700 (PDT) Received: from [63.73.97.185] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id MAA07558; Wed, 11 Oct 2000 12:05:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20001011112552.I31259@gnupg.de> References: <20001011112552.I31259@gnupg.de> Date: Wed, 11 Oct 2000 11:59:53 -0700 To: Werner Koch , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Another draft is going out Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 11:25 AM +0200 10/11/00, Werner Koch wrote: >Another point: > >If the use of the MDC packet is not required for at least the modern >ciphers (w/o the feature packet), we should at least add a note that >"An implementation SHOULD issue a warning if one of the new[1] cipher >algorithms is used without the MDC packet". > >[1] new: Either explictly list old algorithms or say that new >algorithms are those with a blocklength other than 64 bit. > I don't think that tying MDC and big blocks is a good idea -- in the spec. I think it is perfectly fine for you implementers to do that. The spec gives you a lot of latitude, and if you want to only use a big block with MDCs, that's fine. You need to *decrypt* one, but you don't ever have to encrypt one. And you're perfectly within your rights to issue warning messages if you think it's not a good idea. If you want to limit use more, I have a suggestion: we put in a "feature" of 128-bit-block ciphers. That way you can declare whether you use them or not. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id LAA03065 for ietf-openpgp-bks; Wed, 11 Oct 2000 11:51:32 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA03061 for ; Wed, 11 Oct 2000 11:51:31 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id LAA07437; Wed, 11 Oct 2000 11:56:06 -0700 (PDT) Received: from [63.73.97.185] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id LAA07433; Wed, 11 Oct 2000 11:56:02 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20001011122739.Q25061@sobolev.does-not-exist.org> References: <20001011112552.I31259@gnupg.de> <20001011122739.Q25061@sobolev.does-not-exist.org> Date: Wed, 11 Oct 2000 11:52:41 -0700 To: Thomas Roessler , ietf-openpgp@imc.org From: Jon Callas Subject: Re: Another draft is going out Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:27 PM +0200 10/11/00, Thomas Roessler wrote: >On 2000-10-11 11:25:52 +0200, Werner Koch wrote: > >> I dropped IDEA because I don't see a reason to support that >> patented algorithm anymore - now that there is another well >> analyzed new algorithm available. > >We don't need to add still more interoperability nightmares with the >old implementations which are still in use at some places. The >text-mode signature problems are bad enough already. > Sooner or later, we should start encouraging people away from PGP 2. I like what Werner said -- he simply explicitly called out that IDEA is needed for PGP 2 support. The subtle, lovely thing about SHOULD is that SHOULD means "if you don't understand the ramifications, do it." It allows anyone to say "I know what I'm doing." However, I like the idea of calling out that IDEA is there for backwards compatibility. How about this paragraph: --- Implementations MUST implement Triple-DES. Implementations SHOULD implement AES-128 and CAST5. Implementations that interoperate with PGP 2.6 or earlier need to support IDEA, as that is the only symmetric cipher those versions use. Implementations MAY implement any other algorithm. --- Jon Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05126 for ietf-openpgp-bks; Wed, 11 Oct 2000 03:29:10 -0700 (PDT) Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA05122 for ; Wed, 11 Oct 2000 03:29:05 -0700 (PDT) Received: from sobolev.does-not-exist.org (dialin189-nt.pg1.frankfurt.nikoma.de [213.54.32.189]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id MAA50711 for ; Wed, 11 Oct 2000 12:33:26 +0200 (CEST) (envelope-from roessler@does-not-exist.org) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 0C70D2ED1B; Wed, 11 Oct 2000 12:27:39 +0200 (CEST) Date: Wed, 11 Oct 2000 12:27:39 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: Another draft is going out Message-ID: <20001011122739.Q25061@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <20001011112552.I31259@gnupg.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <20001011112552.I31259@gnupg.de>; from wk@gnupg.org on Wed, Oct 11, 2000 at 11:25:52AM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On 2000-10-11 11:25:52 +0200, Werner Koch wrote: > I dropped IDEA because I don't see a reason to support that > patented algorithm anymore - now that there is another well > analyzed new algorithm available. We don't need to add still more interoperability nightmares with the old implementations which are still in use at some places. The text-mode signature problems are bad enough already. -- Thomas Roessler Received: by ns.secondary.com (8.9.3/8.9.3) id DAA05058 for ietf-openpgp-bks; Wed, 11 Oct 2000 03:25:59 -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 DAA05053 for ; Wed, 11 Oct 2000 03:25:57 -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 GAA05469; Wed, 11 Oct 2000 06:30:30 -0400 (EDT) Message-Id: <200010111030.GAA05469@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-rfc2440bis-02.txt Date: Wed, 11 Oct 2000 06:30:29 -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 : OpenPGP Message Format Author(s) : J. Callas, L. Donnerhacke, H. Finney, R. Thayer Filename : draft-ietf-openpgp-rfc2440bis-02.txt Pages : 67 Date : 10-Oct-00 This document defines many tag values, yet it doesn't describe a mechanism for adding new tags (for new features). Traditionally the Internet Assigned Numbers Authority (IANA) handles the allocation of new values for future expansion and RFCs usually define the procedure to be used by the IANA. However there are subtle (and not so subtle) interactions that may occur in this protocol between new features and existing features which result in a significant reduction in over all security. Therefore this document does not define an extension procedure. Instead requests to define new tag values (say for new encryption algorithms for example) should be forwarded to the IESG Security Area Directors for consideration or forwarding to the appropriate IETF Working Group for consideration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-openpgp-rfc2440bis-02.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-rfc2440bis-02.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-rfc2440bis-02.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: <20001010123103.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-openpgp-rfc2440bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-openpgp-rfc2440bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001010123103.I-D@ietf.org> --OtherAccess-- --NextPart-- Received: by ns.secondary.com (8.9.3/8.9.3) id CAA00704 for ietf-openpgp-bks; Wed, 11 Oct 2000 02:05:38 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA00699 for ; Wed, 11 Oct 2000 02:05:35 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13jI92-0008Cz-00; Wed, 11 Oct 2000 11:25:52 +0200 Date: Wed, 11 Oct 2000 11:25:52 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: Another draft is going out Message-ID: <20001011112552.I31259@gnupg.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jon@callas.org on Wed, Oct 11, 2000 at 12:07:43AM -0700 X-PGP-KeyID: 621CC013 X-Request-PGP: http://www.openit.de/people/wk/gpg.html Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Hi, now that it has been decided on AES I suggest to change: 9.2. Symmetric Key Algorithms [...] "Implementations MUST implement Triple-DES. Implementations SHOULD implement IDEA and CAST5. Implementations MAY implement any other algorithm." by "Implementations MUST implement Triple-DES. Implementations SHOULD implement CAST5 and AES 128bit. Implementations MAY implement any other algorithm. To allow backward compatibilty with PGP2 IDEA SHOULD be implemented." I dropped IDEA because I don't see a reason to support that patented algorithm anymore - now that there is another well analyzed new algorithm available. Another point: If the use of the MDC packet is not required for at least the modern ciphers (w/o the feature packet), we should at least add a note that "An implementation SHOULD issue a warning if one of the new[1] cipher algorithms is used without the MDC packet". [1] new: Either explictly list old algorithms or say that new algorithms are those with a blocklength other than 64 bit. Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id AAA27538 for ietf-openpgp-bks; Wed, 11 Oct 2000 00:24:13 -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 AAA27534 for ; Wed, 11 Oct 2000 00:24:12 -0700 (PDT) Received: from [63.73.97.185] (63.73.97.185) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1) for ; Wed, 11 Oct 2000 00:28:44 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Wed, 11 Oct 2000 00:07:43 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: Another draft is going out Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I forgot to mention that there's also the notation data namespace thing in there, too. Let me know what you think. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id PAA22154 for ietf-openpgp-bks; Mon, 9 Oct 2000 15:37:29 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA22148 for ; Mon, 9 Oct 2000 15:37:28 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA08356 for ; Mon, 9 Oct 2000 15:41:53 -0700 (PDT) Received: from [172.20.1.38] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA08352 for ; Mon, 9 Oct 2000 15:41:52 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Mon, 9 Oct 2000 15:37:44 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Another draft is going out Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I have the MDC packets in and Ulf's comments (signature collisions and PKCS1 leap to mind). I also added in a definition of a keyring. Like I said before, I'm willing to put out a number of small drafts. This one is particularly important because of the MDC packets, which required small changes in a number of places. I also added in a "features" signature subpacket. There are also AES references added and reservation notes removed. I standardized some spelling. I'm sure I missed someone's something. Just send me mail. In a week or two, I'll do another. Jon Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id OAA10164 for ietf-openpgp-bks; Sun, 8 Oct 2000 14:52:41 -0700 (PDT) Received: from www.tclking.com (IDENT:root@szptt103-190.szptt.net.cn [202.103.190.164] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA10159 for ; Sun, 8 Oct 2000 14:52:39 -0700 (PDT) From: rsb@docsj.de Received: from pavilion (mig-fl29a-49.rasserver.net [206.214.131.49]) by www.tclking.com (8.9.3/8.8.7) with SMTP id GAA25178; Mon, 9 Oct 2000 06:10:20 +0800 Date: Mon, 9 Oct 2000 06:10:20 +0800 Message-Id: <200010082210.GAA25178@www.tclking.com> To: rsb@docsj.de Subject: At last, HERBAL V the all natural alternative! Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $24 ______ 2 Bottles of Herbal V $44 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. Received: by ns.secondary.com (8.9.3/8.9.3) id JAA04048 for ietf-openpgp-bks; Sun, 8 Oct 2000 09:56:09 -0700 (PDT) Received: from mail2.mia.bellsouth.net (mail2.mia.bellsouth.net [205.152.144.14]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id JAA04044 for ; Sun, 8 Oct 2000 09:56:07 -0700 (PDT) From: bubblehead32@hotmail.com Received: from www.goldendeckcasino.com (adsl-61-143-206.mia.bellsouth.net [208.61.143.206]) by mail2.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id NAA16873; Sun, 8 Oct 2000 13:00:12 -0400 (EDT) Message-Id: <200010081700.NAA16873@mail2.mia.bellsouth.net> To: <> Subject: WOW!!! Highest Payouts Around!!!!!!!! Date: Sun, 08 Oct 2000 12:52:08 -0400 X-Sender: bubblehead32@hotmail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html. If you would like to be removed from these mailings in the future please mailto:bubblehead32@hotmail.com?subject=remove Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id AAA22634 for ietf-openpgp-bks; Fri, 6 Oct 2000 00:16:59 -0700 (PDT) Received: from merrymeet.com (fwuser@w023.z064000151.sjc-ca.dsl.cnc.net [64.0.151.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA22629 for ; Fri, 6 Oct 2000 00:16:53 -0700 (PDT) Received: from [64.0.151.22] (64.0.151.22) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1); Fri, 6 Oct 2000 00:20:55 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com (Unverified) Message-Id: In-Reply-To: <20001005201305.A1500@rho.invalid> References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> <20001004123638.D15312@sobolev.does-not-exist.org> <20001005201305.A1500@rho.invalid> Date: Thu, 5 Oct 2000 20:52:40 -0700 To: Ulf =?iso-8859-1?Q?M=F6ller?= , "Peter J . Holzer" , Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" From: Jon Callas Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility? Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id AAA22631 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 8:13 PM -0400 10/5/00, Ulf Möller wrote: >Sometimes I have the impression that most of my comments on the >OpenPGP drafts fall in the "gone unnoticed" category (I first pointed >it out on September 16th, 1998, again on October 13th -- RFC 2440 was >published in November --, once more on February 10th, 1999, and again >on December 23rd after a cryptic note on the subject appeared in >2440bis-00); but we actually have the following text in the latest >draft: > > * PGP 2.6.X and 5.0 do not trim trailing whitespace from a > "canonical text" signature. They only remove it from cleartext > signatures. These signatures are not OpenPGP compliant -- > OpenPGP requires trimming the whitespace. If you wish to > interoperate with PGP 2.6.X or PGP 5, you may wish to accept > these non-compliant signatures. You're welcome. I've said this a number of times, and I think it bears repeating. If I get a request about OpenPGP that is vague, I may not do what the requester intends. The ways in which I can fall down include putting the wrong thing in the draft, but they are also likely to be that I'll do nothing when you wanted something. There are a couple of reasons I might do nothing. The usual one is that I don't know what you want me to do. OpenPGP has small quantities of sub-optimal things in it. Usually, those things are there because of backwards compatibility. However, at the start of this working group, we decided that backwards compatibility is important and desirable, but not essential. So there are things we can, and have, broken because it makes a better standard moving forward. So sometimes I interpret someone's complaint as a complaint, not as a suggestion for a change in the document. I know that in your case, I've made a number of errors of this sort. I am truly sorry for this, and I've been trying to make a special effort to pay closer attention to what you want. However, it makes it *much* easier for me if you tell me what you want. The best thing is something like: Please change XXX to YYY. For example, I am presently working on getting the PKCS1 updates done. Thank you for you help. But changing them correctly means that I have to go dredge out the PKCS1 draft, read it, interpret it, and figure out what to do. This will take a couple of hours, most likely. In the last few days I've had several ten minute opportunities to edit. I've had a couple hour-long ones. I haven't yet had that much time. If you know what you want text to be, tell me. If I have to do research not only will I do it slower, but there's a chance I may decide that the best thing to do is nothing. In short -- if you make me think, I may end up concluding something other than you want. Again, though, I'm sorry I've screwed up. It isn't that I'm ignoring you. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id SAA16496 for ietf-openpgp-bks; Thu, 5 Oct 2000 18:35:22 -0700 (PDT) Received: from tomts8-srv.bellnexxia.net (tomts8.bellnexxia.net [209.226.175.52]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id SAA16490 for ; Thu, 5 Oct 2000 18:35:08 -0700 (PDT) Received: from localhost ([64.228.185.57]) by tomts8-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001006013902.WWVW625.tomts8-srv.bellnexxia.net@localhost>; Thu, 5 Oct 2000 21:39:02 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13hL8M-0000Py-00; Thu, 5 Oct 2000 20:13:06 -0400 Date: Thu, 5 Oct 2000 20:13:06 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: "Peter J . Holzer" , Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility? Message-ID: <20001005201305.A1500@rho.invalid> References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> <20001004123638.D15312@sobolev.does-not-exist.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20001004123638.D15312@sobolev.does-not-exist.org>; from roessler@does-not-exist.org on Wed, Oct 04, 2000 at 12:36:38PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, Oct 04, 2000 at 12:36:38PM +0200, Thomas Roessler wrote: > This smells like a discrepancy between RFC 2440 and the classical > PGP implementation has crept in, and gone unnoticed for quite some > time. Sometimes I have the impression that most of my comments on the OpenPGP drafts fall in the "gone unnoticed" category (I first pointed it out on September 16th, 1998, again on October 13th -- RFC 2440 was published in November --, once more on February 10th, 1999, and again on December 23rd after a cryptic note on the subject appeared in 2440bis-00); but we actually have the following text in the latest draft: * PGP 2.6.X and 5.0 do not trim trailing whitespace from a "canonical text" signature. They only remove it from cleartext signatures. These signatures are not OpenPGP compliant -- OpenPGP requires trimming the whitespace. If you wish to interoperate with PGP 2.6.X or PGP 5, you may wish to accept these non-compliant signatures. Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10668 for ietf-openpgp-bks; Wed, 4 Oct 2000 05:22:33 -0700 (PDT) Received: from nmrc.ucc.ie (nmrc.ucc.ie [143.239.64.1]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10663 for ; Wed, 4 Oct 2000 05:22:31 -0700 (PDT) Date: Wed, 4 Oct 2000 13:25:46 +0100 From: Lars Hecking To: "Peter J . Holzer" Cc: aleph1@securityfocus.com, "ietf-openpgp @ imc . org" Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility? Message-ID: <20001004132546.A26016@nmrc.ie> References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> <20001004123638.D15312@sobolev.does-not-exist.org> <20001004142001.G15434@wsr.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <20001004142001.G15434@wsr.ac.at>; from hjp@wsr.ac.at on Wed, Oct 04, 2000 at 02:20:01PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Peter J . Holzer writes: > On 2000-10-04 12:36:38 +0200, Thomas Roessler wrote: > > Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing > > about all this? Are they compatible: > > > > - to each other? > > - to PGP 2.6? > > I think that GnuPG is not compatible with PGP 2.6. Lars (using GnuPG) > couldn't verify a message (signed with PGP 2.6) I sent to him in a > tarred and compressed folder (to avoid any corruption in transit). I'll > try PGP 6.5 (which I have installed at home) this evening. Just re-tried with pgp 2.6.3i, and yes, this time it works. -l -- Be free and open and breezy! Enjoy! Things won't get any better so get used to it. Received: by ns.secondary.com (8.9.3/8.9.3) id FAA10477 for ietf-openpgp-bks; Wed, 4 Oct 2000 05:16:25 -0700 (PDT) Received: from wsrcom1.wsr.ac.at (wsrcom1.wsr.ac.at [143.130.16.5]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA10473 for ; Wed, 4 Oct 2000 05:16:23 -0700 (PDT) Received: from enkur.wsr.ac.at (IDENT:hjp@enkur.wsr.ac.at [143.130.50.57]) by wsrcom1.wsr.ac.at (8.9.3/8.9.3) with ESMTP id OAA14517; Wed, 4 Oct 2000 14:20:03 +0200 (METDST) Received: (from hjp@localhost) by enkur.wsr.ac.at (8.9.3/8.9.3) id OAA24793; Wed, 4 Oct 2000 14:20:01 +0200 Date: Wed, 4 Oct 2000 14:20:01 +0200 From: "Peter J . Holzer" To: Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" Subject: Re: Text canonicalization in RFC 2440 - backwards compatibility? Message-ID: <20001004142001.G15434@wsr.ac.at> References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> <20001004123638.D15312@sobolev.does-not-exist.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary=pfTAc8Cvt8L6I27a; micalg=pgp-md5; protocol="application/pgp-signature" X-Mailer: Mutt 0.95.3i In-Reply-To: <20001004123638.D15312@sobolev.does-not-exist.org>; from Thomas Roessler on Wed, Oct 04, 2000 at 12:36:38PM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --pfTAc8Cvt8L6I27a Content-Type: text/plain; charset=us-ascii On 2000-10-04 12:36:38 +0200, Thomas Roessler wrote: > Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing > about all this? Are they compatible: > > - to each other? > - to PGP 2.6? I think that GnuPG is not compatible with PGP 2.6. Lars (using GnuPG) couldn't verify a message (signed with PGP 2.6) I sent to him in a tarred and compressed folder (to avoid any corruption in transit). I'll try PGP 6.5 (which I have installed at home) this evening. hp -- _ | Peter J. Holzer | Any setuid root program that does an |_|_) | Sysadmin WSR / LUGA | exec() somewhere is just a less | | | hjp@wsr.ac.at | user friendly version of su. __/ | http://www.hjp.at/ | -- Olaf Kirch on bugtraq 2000-08-07 --pfTAc8Cvt8L6I27a Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia iQDQAwUBOdsgcVLjemazOuKpAQFqjwXRAe6uFTOKBKkXpM+xdWrWwLPpD/s9LjP1 yzHd+FDkdHKaJtydAYN5W3zVqUz9VW/w3gIE6lycv0g28AjtJGqMohEIUDVQmlDk 1hGcYfF6Oyw+wQ2eXPlF/7EAhWtPJLzS14WDgaq2vZrtMdigKQjLgcwxDQGeySny 1nvP4O/wqSIP4uYKrAwzn7QPdh8LP6eiMpusPqy0L7Xqf/9TJ04f3Xc1LfJw58ka ClCkFA/h+HGMBy+XsVIPOKpe6Q== =ho3n -----END PGP SIGNATURE----- --pfTAc8Cvt8L6I27a-- Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA05577 for ietf-openpgp-bks; Wed, 4 Oct 2000 04:03:39 -0700 (PDT) Received: from vi-b1.ipcore.viaginterkom.de (ns0.ipcore.viaginterkom.de [195.182.96.29] (may be forged)) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA05572 for ; Wed, 4 Oct 2000 04:03:37 -0700 (PDT) Received: from sobolev.does-not-exist.org (f-209-112.cvx.ipdial.viaginterkom.de [62.180.209.112]) by vi-b1.ipcore.viaginterkom.de (8.9.3/8.9.3) with ESMTP id MAA15417; Wed, 4 Oct 2000 12:38:43 +0200 (MET DST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 7EE5D2ED13; Wed, 4 Oct 2000 12:36:38 +0200 (CEST) Date: Wed, 4 Oct 2000 12:36:38 +0200 From: Thomas Roessler To: "Peter J . Holzer" Cc: Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" Subject: Text canonicalization in RFC 2440 - backwards compatibility? Message-ID: <20001004123638.D15312@sobolev.does-not-exist.org> Mail-Followup-To: "Peter J . Holzer" , Lars Hecking , aleph1@SECURITYFOCUS.COM, "ietf-openpgp @ imc . org" References: <87em21kw78.fsf@cain.internet2.edu> <20001002130658.A5228@faui02.informatik.uni-erlangen.de> <20001002190646.A17974@gondor.com> <20001003153031.G32582@wsr.ac.at> <20001004100634.A22743@nmrc.ie> <20001004115529.C15434@wsr.ac.at> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="6TrnltStXW4iwmi0" Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <20001004115529.C15434@wsr.ac.at>; from hjp@wsr.ac.at on Wed, Oct 04, 2000 at 11:55:29AM +0200 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --6TrnltStXW4iwmi0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable [This thread got started since PGP signatures on the bugtraq list did not verify correctly. However, these signatures are (1) text-mode, and (2) the modification apparently concerns trailing whitespace.] This smells like a discrepancy between RFC 2440 and the classical PGP implementation has crept in, and gone unnoticed for quite some time. Essentially, RFC 2440 says that we shouldn't observe the problems occuring on bugtraq: Peter is generating "canonical text" signatures. RFC 2440 says: 0x01: Signature of a canonical text document. Typically, this means the signer owns it, created it, or certifies that it has not been modified. The signature is calculated over the text data with its line endings converted to and trailing blanks removed. However, when experimenting with PGP 2.6.3in, I'm observing that canonical text signatures _do_ take trailing whitespace into account. Now, let's look at the older docs: RFC 1991 doesn't seem to define canonical text mode at all. pgpdoc2.txt from the PGP 2 distribution, however, just says this: "Canonical text has a carriage return and a linefeed at the end of each line of text." This is a precise description of the behaviour, and actually matches the expectation which seems to have been implicit to RFC 2015, which only deals with line-end canonicalization, but not with the signature mode to be used. To make things worse, the "clearsign" signatures of pgp2 _do_ correspond with what RFC 2440 says about canonical text documents in general. Now, what are the recent implementations (PGP 5/6/7, GnuPG) doing about all this? Are they compatible: - to each other? - to PGP 2.6? Or am I just confused? On 2000-10-04 11:55:29 +0200, Peter J . Holzer wrote: > Date: Wed, 4 Oct 2000 11:55:29 +0200 > From: "Peter J . Holzer" > To: Lars Hecking > Cc: Thomas Roessler , > aleph1@SECURITYFOCUS.COM > Subject: Re: rcp file transfer hole (was: scp file transfer hole) > X-Mailer: Mutt 0.95.3i >=20 > [I have included Elias in the Cc, because I think he might want to know > about this "feature" of his mailing-list software] >=20 >=20 > On 2000-10-04 10:06:34 +0100, Lars Hecking wrote: > > Any idea why half the signatures on bugtraq don't check out? Do you > > have an fcc copy of your posting that you can compare with the posted > > message? >=20 > Yes. >=20 > Looks like Bugtraq strips trailing spaces from each line. This will > garble the signature separator ("-- ") and therefore the pgp signature > won't check out any more.=20 >=20 > I guess I should add=20 >=20 > send-hook '~t BUGTRAQ@SECURITYFOCUS.COM' 'set pgp_strict_enc' >=20 > to my .muttrc. >=20 > For people which don't use PGP signatures, but want their normal > signatures to be separated correctly, it would be nice if mutt could be > forced to use quoted printable even for ascii messages. Thomas? >=20 > hp >=20 > --=20 > _ | Peter J. Holzer | Any setuid root program that does an > |_|_) | Sysadmin WSR / LUGA | exec() somewhere is just a less > | | | hjp@wsr.ac.at | user friendly version of su. > __/ | http://www.hjp.at/ | -- Olaf Kirch on bugtraq 2000-08-07 --=20 Thomas Roessler --6TrnltStXW4iwmi0 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: 2.6.3in iQEVAwUBOdsINtImKUTOasbBAQEJ1ggAnlQP8OrYh4HrPgCLzTDD/7T7RlFTkUyv CkoPt2ZVvWABfy2Bv2T+lGE/k6W1Wqhb+Yzjz0xboOBsGgaWKBJVbA7Go2SECQ4s +VRzj4XMWVb0RTWcg4t7tHdBwfpIM3d9heMp0KiYgVuHRMkSDITZ8QYQqJcI9xYw 1ACX3QzfGCMCKO4uCe/KjPeIS6zM1SzcgqjOn6vigjCWWCxXrUTBOP7dSbO53kx8 ovIX68eRCn1gIGBUtNONW29r5avZ/SYTt9FT1D2J/eEvdG82tyMtOOoFL1ObL6Tg 2xMGDX5H3CXAlXoJUsHvPptu4vu6cGyuzdpuNszct3WA0C6YHL36qA== =Kti5 -----END PGP SIGNATURE----- --6TrnltStXW4iwmi0-- Received: by ns.secondary.com (8.9.3/8.9.3) id BAA18183 for ietf-openpgp-bks; Wed, 4 Oct 2000 01:43:44 -0700 (PDT) Received: from merrymeet.com (fwuser@w023.z064000151.sjc-ca.dsl.cnc.net [64.0.151.23]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA18179 for ; Wed, 4 Oct 2000 01:43:41 -0700 (PDT) Received: from [64.0.151.22] (64.0.151.22) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.0.1); Wed, 4 Oct 2000 01:47:31 -0700 Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <5.0.0.25.0.20001004152310.02162c88@203.38.66.7> References: <5.0.0.25.0.20001004152310.02162c88@203.38.66.7> Date: Wed, 4 Oct 2000 01:20:56 -0700 To: Erron Criddle , ietf-openpgp@imc.org From: Jon Callas Subject: Re: PKCS1 update excerpts Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I'm trying to clarify and get the references proper. So perhaps, if other people think it helps. Jon Received: by ns.secondary.com (8.9.3/8.9.3) id BAA17560 for ietf-openpgp-bks; Wed, 4 Oct 2000 01:37:44 -0700 (PDT) Received: from djebel.gnupg.de (mail@djebel.openit.de [194.77.127.20]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA17549 for ; Wed, 4 Oct 2000 01:37:42 -0700 (PDT) Received: from wk by djebel.gnupg.de with local (Exim 3.12 #1 (Debian)) id 13gkL7-00073r-00; Wed, 04 Oct 2000 10:55:49 +0200 Date: Wed, 4 Oct 2000 10:55:49 +0200 From: Werner Koch To: ietf-openpgp@imc.org Subject: Re: MDC Excerpts Message-ID: <20001004105549.D26868@djebel.openit.de> Mail-Followup-To: ietf-openpgp@imc.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.8i In-Reply-To: ; from jon@callas.org on Mon, Oct 02, 2000 at 03:36:23PM -0700 X-URL: http://www.openit.de X-PGP-KeyID: 621CC013 X-Request-PGP: finger:wkoch@sigtrap.guug.de Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Mon, 2 Oct 2000, Jon Callas wrote: > 5.2.3.24. Features > > (array of one-octet values) We need a number for this signature sub packet. > 1 - Modification Detection (packets 15 and 16) > > If an implementation implements any of the defined features, it > SHOULD implement the features subpacket, too. I have a problem with this. Currently PGP 7 and GnuPG 1.0.2 implement this feature and use packets 15 and 16 when Twofish is used. A year back or so we had a long discussion about this MDC packets and the use of Twofish. I suggested that we should wait with using Twofish until we had figured out how to do this MDC and the require implementations to use the MDC packet if they use a cipher with a blocklength not equal to 64 bits. Requiring to use the MDC only if the feature packet is present makes the code more complicated because an implementation has to check the cipher preferences and the MDC feature. The feature packet is a good thing because it enables us to use the MDC even with with CAST5 or 3DES. It should however say that this feature is implictly assumed when a symmetrical cipher algorithm with ablocklength different from 64 bits is used (or explitly enumerate algorithms). I'd also appreciate if we can say that the use of the MDC is a SHOULD for such algorithms. Werner -- Werner Koch GnuPG key: 621CC013 OpenIT GmbH http://www.OpenIT.de Received: by ns.secondary.com (8.9.3/8.9.3) id AAA12817 for ietf-openpgp-bks; Wed, 4 Oct 2000 00:41:34 -0700 (PDT) Received: from mail.comasp.com (dns2.techrron.com.au [203.38.66.9]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id AAA12811 for ; Wed, 4 Oct 2000 00:41:30 -0700 (PDT) Received: from pc.comasp.com [203.38.66.8] by mail.comasp.com with ESMTP (SMTPD32-4.06) id A353E7A10296; Wed, 04 Oct 2000 15:46:43 0800 Message-Id: <5.0.0.25.0.20001004152310.02162c88@203.38.66.7> X-Sender: ejc@203.38.66.7 X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Wed, 04 Oct 2000 15:40:27 +0800 To: ietf-openpgp@imc.org From: Erron Criddle Subject: Re: PKCS1 update excerpts Cc: Jon Callas In-Reply-To: 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: Jon, Does this info help: The m value is calculated as follows: boundary 0x00 The boundary value identifier 0x02 The block type identifier random n octets n octets of non zero PRNG data to make len(m) = modulus of the length of the primary key p boundary 0x00 The boundary value algorithm id 1 octet The ID of the symmetrical algorithm used with the session key session key n bits This is the n bit session key to encrypt the data checksum 2 bytes Is the 16 bit checksum of the session key, MOD 65536 At 03:15 PM 3/10/2000 -0700, you wrote: >Please let me know if this is adequate: > >5.1: > > The value "m" in the above formulas is derived from the session key > as follows. First the session key is prefixed with a one-octet > algorithm identifier that specifies the symmetric encryption > algorithm used to encrypt the following Symmetrically Encrypted Data > Packet. Then a two-octet checksum is appended which is equal to the > sum of the preceding session key octets, not including the algorithm > identifier, modulo 65536. This value is then encoded as described > in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m" > value used in the formulas above. > > Note that when an implementation forms several PKESKs with one > session key, forming a message that can be decrypted by several > keys, the implementation MUST make new PKCS-1 encoding for each key. > >and > >5.2.2: > > With RSA signatures, the hash value is encoded as described in > PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of > type DigestInfo, and then encoded using PKCS-1 encoding type > EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value > as an octet string into an ASN.1 structure. The object identifier > for the type of hash being used is included in the structure. The > hexadecimal representations for the currently defined hash > algorithms are: Received: by ns.secondary.com (8.9.3/8.9.3) id VAA08350 for ietf-openpgp-bks; Tue, 3 Oct 2000 21:07:34 -0700 (PDT) Received: from tomts7-srv.bellnexxia.net (tomts7.bellnexxia.net [209.226.175.40]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA08344 for ; Tue, 3 Oct 2000 21:07:32 -0700 (PDT) Received: from localhost ([206.172.147.137]) by tomts7-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001004041128.KVXI1518.tomts7-srv.bellnexxia.net@localhost> for ; Wed, 4 Oct 2000 00:11:28 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13gdo3-0000Gx-00; Tue, 3 Oct 2000 21:57:15 -0400 Date: Tue, 3 Oct 2000 21:57:15 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Message-ID: <20001003215715.A1035@rho.invalid> References: <200010032252.PAA09014@finney.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from jon@callas.org on Tue, Oct 03, 2000 at 04:11:09PM -0700 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Tue, Oct 03, 2000 at 04:11:09PM -0700, Jon Callas wrote: > I added the following two paragraphs to Security Considerations that > address this issue: Thanks. Received: by ns.secondary.com (8.9.3/8.9.3) id QAA03012 for ietf-openpgp-bks; Tue, 3 Oct 2000 16:14:06 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA03008 for ; Tue, 3 Oct 2000 16:14:04 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id QAA19380 for ; Tue, 3 Oct 2000 16:17:59 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id QAA19376 for ; Tue, 3 Oct 2000 16:17:59 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <200010032252.PAA09014@finney.org> References: <200010032252.PAA09014@finney.org> Date: Tue, 3 Oct 2000 16:11:09 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I added the following two paragraphs to Security Considerations that address this issue: There is a potential security problem in signatures. If an attacker can find a message that hashes to the same hash with a different algorithm, a bogus signature structure can be constructed that evaluates correctly. For example, suppose Alice DSA signs message M using hash algorithm H. Suppose that Mallet finds a message M' that has the same hash value as M with H'. Mallet can then construct a signature block that verifies as Alice's signature of M' with H'. However, this would also constitute a weakness in either H or H' or both. Should this ever occur, a revision will have to be made to this document to revise the allowed hash algorithms. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA02559 for ietf-openpgp-bks; Tue, 3 Oct 2000 15:53:27 -0700 (PDT) Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA02555 for ; Tue, 3 Oct 2000 15:53:25 -0700 (PDT) From: hal@finney.org Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id PAA09014; Tue, 3 Oct 2000 15:52:54 -0700 Date: Tue, 3 Oct 2000 15:52:54 -0700 Message-Id: <200010032252.PAA09014@finney.org> To: ietf-openpgp@imc.org, jon@callas.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Ulf Möller wrote: >The security notes still don't mention that there is a cryptographic >flaw in v4 signatures. This needs to be fixed, or if there are good >reasons for not fixing it, it must at least be explained in the >document. The problem is that we currently allow a choice of hash algorithms with DSA signatures. Because there is no room in the DSA inputs to specify the hash algorithm, it is possible to do a hash substitution attack. This is why the DSS specifies that the hash must be SHA-1. We allow other hashes with a size of 160 bits, as described in section 5.2.2: DSA signatures MUST use hashes with a size of 160 bits, to match q, the size of the group generated by the DSA key's generator value. The hash function result is treated as a 160 bit number and used directly in the DSA signature algorithm. The only other hashes listed in RFC 2440 which have this size are RIPEMD-160 and HAVAL. These are thought to be strong hashes, like SHA-1, hence there is no actual cryptographic weakness in RFC-2440. This issue is discussed in section 13, Security Considerations: The DSA algorithm will work with any 160-bit hash, but it is sensitive to the quality of the hash algorithm, if the hash algorithm is broken, it can leak the secret key. The Digital Signature Standard (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is considered by many cryptographers to be as strong. An implementation should take care which hash algorithms are used with DSA, as a weak hash can not only allow a signature to be forged, but could leak the secret key. These same considerations about the quality of the hash algorithm apply to Elgamal signatures. In my opinion this does address the issue raised above. Hal Received: by ns.secondary.com (8.9.3/8.9.3) id PAA01756 for ietf-openpgp-bks; Tue, 3 Oct 2000 15:13:01 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA01752 for ; Tue, 3 Oct 2000 15:13:01 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA18185 for ; Tue, 3 Oct 2000 15:16:56 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA18181 for ; Tue, 3 Oct 2000 15:16:55 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Tue, 3 Oct 2000 15:15:19 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: PKCS1 update excerpts Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Please let me know if this is adequate: 5.1: The value "m" in the above formulas is derived from the session key as follows. First the session key is prefixed with a one-octet algorithm identifier that specifies the symmetric encryption algorithm used to encrypt the following Symmetrically Encrypted Data Packet. Then a two-octet checksum is appended which is equal to the sum of the preceding session key octets, not including the algorithm identifier, modulo 65536. This value is then encoded as described in PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m" value used in the formulas above. Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation MUST make new PKCS-1 encoding for each key. and 5.2.2: With RSA signatures, the hash value is encoded as described in PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of type DigestInfo, and then encoded using PKCS-1 encoding type EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value as an octet string into an ASN.1 structure. The object identifier for the type of hash being used is included in the structure. The hexadecimal representations for the currently defined hash algorithms are: Received: by ns.secondary.com (8.9.3/8.9.3) id OAA01349 for ietf-openpgp-bks; Tue, 3 Oct 2000 14:57:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id OAA01343 for ; Tue, 3 Oct 2000 14:57:53 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA17853 for ; Tue, 3 Oct 2000 15:01:48 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA17849 for ; Tue, 3 Oct 2000 15:01:48 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Tue, 3 Oct 2000 14:56:29 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ns.secondary.com id OAA01344 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In our last episode ("Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt", shown on 10/2/00), Ulf Möller said: >The security notes still don't mention that there is a cryptographic >flaw in v4 signatures. This needs to be fixed, or if there are good >reasons for not fixing it, it must at least be explained in the >document. > Should we start killing hash algorithms, then? Jon Received: by ns.secondary.com (8.9.3/8.9.3) id CAA07436 for ietf-openpgp-bks; Tue, 3 Oct 2000 02:01:37 -0700 (PDT) Received: from vi-b2.ipcore.viaginterkom.de (ns1.ipcore.viaginterkom.de [195.182.96.28]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA07432 for ; Tue, 3 Oct 2000 02:01:35 -0700 (PDT) Received: from sobolev.does-not-exist.org (f-210-103.cvx.ipdial.viaginterkom.de [62.180.210.103]) by vi-b2.ipcore.viaginterkom.de (8.9.3/8.9.3) with ESMTP id KAA18216 for ; Tue, 3 Oct 2000 10:56:03 +0200 (MET DST) Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 9433A2ED15; Tue, 3 Oct 2000 10:47:30 +0200 (CEST) Date: Tue, 3 Oct 2000 10:47:30 +0200 From: Thomas Roessler To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Message-ID: <20001003104730.B2625@sobolev.does-not-exist.org> Mail-Followup-To: ietf-openpgp@imc.org References: <200009291101.HAA26175@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.9i In-Reply-To: <200009291101.HAA26175@ietf.org>; from Internet-Drafts@ietf.org on Fri, Sep 29, 2000 at 07:01:02AM -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This draft still does not say anything about name spaces for notation data tags, making notation data essentially useless. Suggestion: The present document defines two name spaces for notation data names: The IETF name space and the user name space. Notation data names in the IETF name space consist of an arbitrary string of UTF-8 encoded characters, with the exception that the character "@" ("at") MUST NOT occur in such a name. XXX - describe IANA registration procedures. Notation data names in the user name space consist of a tag, followed by the "@" character, followed by a DNS domain name. The tag may be an arbitrary string of UTF-8 encoded characters, with the exception that the character "@" MUST NOT occur in such a name. The DNS domain name must be under the exclusive control of the person or entity which introduces the notation data name in question. For example, if The Example Corporation wishes to introduce sample notation data, the appropriate notation data name could be "sample@example.com". -- Thomas Roessler Received: by ns.secondary.com (8.9.3/8.9.3) id VAA02321 for ietf-openpgp-bks; Mon, 2 Oct 2000 21:29:20 -0700 (PDT) Received: from tomts6-srv.bellnexxia.net (smtp.bellnexxia.net [209.226.175.26]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA02316 for ; Mon, 2 Oct 2000 21:29:19 -0700 (PDT) Received: from localhost ([64.228.185.51]) by tomts6-srv.bellnexxia.net (InterMail vM.4.01.03.00 201-229-121) with ESMTP id <20001003043309.OMEO10530.tomts6-srv.bellnexxia.net@localhost> for ; Tue, 3 Oct 2000 00:33:09 -0400 Received: from um by localhost with local (Exim 2.05 #1 (Debian)) id 13gIe7-0000a6-00; Mon, 2 Oct 2000 23:21:35 -0400 Date: Mon, 2 Oct 2000 23:21:35 -0400 From: =?iso-8859-1?Q?Ulf_M=F6ller?= To: ietf-openpgp@imc.org Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Message-ID: <20001002232134.A1762@rho.invalid> References: <200009291101.HAA26175@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200009291101.HAA26175@ietf.org>; from Internet-Drafts@ietf.org on Fri, Sep 29, 2000 at 07:01:02AM -0400 Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: The security notes still don't mention that there is a cryptographic flaw in v4 signatures. This needs to be fixed, or if there are good reasons for not fixing it, it must at least be explained in the document. As I explained on January 19th: | > I think I'm confused here. Suppose I have an implementation that does DSA | > with SHA-1. Let us also suppose that Tiger gets broken. How does this | > affect my DSA/SHA signature? | | Then if I want to forge a signature, I find a message for which the | Tiger hash value is identical to your original SHA-1 hash. Unless | your original signature was a v3 RSA signature, nothing in OpenPGP | prevents me from setting the hash algorithm identifier for that | message to Tiger. That's why the RSA value in PKCS #1 contains a | DigestInfo, and why the DSS specifies SHA-1 as the only signature | algorithm. Putting the hash algorithm identifier in the data | protected by that very hash algorithm is pointless. | | That clearly is a cryptographic weakness in the protocol, so it has to | be mentioned in the RFC. Most of the other issues I raised haven't been addressed either, but as things are it looks like it would be pointless to invest a lot of time in OpenPGP. Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA27499 for ietf-openpgp-bks; Mon, 2 Oct 2000 15:44:08 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27493 for ; Mon, 2 Oct 2000 15:44:06 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA27899 for ; Mon, 2 Oct 2000 15:47:57 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA27895 for ; Mon, 2 Oct 2000 15:47:57 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: Date: Mon, 2 Oct 2000 15:36:23 -0700 To: ietf-openpgp@imc.org From: Jon Callas Subject: MDC Excerpts Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 5.12. Sym. Encrypted Integrity Protected Data Packet (Tag 15) The Symmetrically Encrypted Integrity Protected Data Packet is a variant of the Symmetrically Encrypted Data Packet. It is a new feature created for OpenPGP that addresses the problem of detecting a modification to encrypted data. It is used in combination with a Modification Detection Code Packet. There is a corresponding feature in the features signature subpacket that denotes that an implementation can properly use this packet type. An implementation SHOULD NOT use this packet when encrypting to a recipient that does not state it can use this packet, and SHOULD prefer this to older Symmetrically Encrypted Data Packet when possible. This 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 decrypted packet in this packet's payload 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, is 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.13. Modification Detection Code Packet (Tag 16) The Modification Detection Code packet contains a SHA-1 hash of plaintext data which is used to detect message modification. It is only used with 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. The reason for this is that the hashing rules for modification detection include a one-octet tag and one-octet length in the data hash. While this is a bit restrictive, it reduces complexity. [...] [Yes, I know this is earlier in the document.] 5.2.3.24. Features (array of one-octet values) The features subpacket denotes which advanced OpenPGP features a user's implementation supports. This is so that as features are added to OpenPGP that cannot be backwards-compatible, a user can state that they can use that feature. This subpacket is similar to a preferences subpacket, and only appears in a self-signature. An implementation SHOULD NOT use a feature listed when sending to a user who does not state that they can use it. Defined features are: 1 - Modification Detection (packets 15 and 16) If an implementation implements any of the defined features, it SHOULD implement the features subpacket, too. Received: by ns.secondary.com (8.9.3/8.9.3) id PAA27073 for ietf-openpgp-bks; Mon, 2 Oct 2000 15:32:09 -0700 (PDT) Received: from natasha.sj.counterpane.com (natasha.sj.counterpane.com [63.196.29.130]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA27062 for ; Mon, 2 Oct 2000 15:31:58 -0700 (PDT) Received: from natasha.sj.counterpane.com (root@localhost) by natasha.sj.counterpane.com with ESMTP id PAA27725; Mon, 2 Oct 2000 15:35:45 -0700 (PDT) Received: from [64.0.151.22] (eris.sj.counterpane.com [172.20.1.38]) by natasha.sj.counterpane.com with ESMTP id PAA27721; Mon, 2 Oct 2000 15:35:34 -0700 (PDT) Mime-Version: 1.0 X-Sender: jon@merrymeet.com Message-Id: In-Reply-To: <20000929141551.D2592@djebel.openit.de> References: <200009291101.HAA26175@ietf.org> <20000929141551.D2592@djebel.openit.de> Date: Mon, 2 Oct 2000 15:27:21 -0700 To: Werner Koch , ietf-openpgp@imc.org From: Jon Callas Subject: Re: I-D ACTION:draft-ietf-openpgp-rfc2440bis-01.txt Content-Type: text/plain; charset="us-ascii" Sender: owner-ietf-openpgp@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 2:15 PM +0200 9/29/00, Werner Koch wrote: >Thanks for updating the draft Jon. > >I think we should add the section on the new MDC packets. Those are >implemented in PGP 7 and GnuPG 1.0.3. Hal: Can you post this >proposed section again? > I've added in the MDC packets, editing the text from Hal's submission. I also added in a "features" subpacket to state that you speak MDC. Excerpts will be forthcoming. I made a few other edits surrounding MDC use (for example in the BNF). I also put in a reminder in the packet header description that you have to use a new-format packet for tags of 16 and greater. >Assuming that AES will be announced quite soon, we could issue a new >draft right after this event. > What changes need to be made for that? We've already reserved constants for the AES. Do I need to do anything other than remove the word "reserved"? Hmmm. A Rijndael reference. That seems to be it to me, though. Jon