--- 1/draft-ietf-openpgp-formats-04.txt 2006-02-05 00:55:15.000000000 +0100 +++ 2/draft-ietf-openpgp-formats-05.txt 2006-02-05 00:55:16.000000000 +0100 @@ -1,25 +1,25 @@ Network Working Group Jon Callas Category: INTERNET-DRAFT Network Associates -draft-ietf-openpgp-formats-04.txt +draft-ietf-openpgp-formats-05.txt Expires Dec 1998 Lutz Donnerhacke June 1998 IN-Root-CA Individual Network e.V. Hal Finney Network Associates Rodney Thayer EIS Corporation OpenPGP Message Format - draft-ietf-openpgp-formats-04.txt + draft-ietf-openpgp-formats-05.txt Copyright 1998 by The Internet Society. All Rights Reserved. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. @@ -137,27 +137,27 @@ 5.11. User ID Packet (Tag 13) 37 6. Radix-64 Conversions 37 6.1. An Implementation of the CRC-24 in "C" 38 6.2. Forming ASCII Armor 38 6.3. Encoding Binary in Radix-64 40 6.4. Decoding Radix-64 41 6.5. Examples of Radix-64 42 6.6. Example of an ASCII Armored Message 42 7. Cleartext signature framework 42 7.1. Dash-Escaped Text 43 - 8. Regular Expressions 43 + 8. Regular Expressions 44 9. Constants 44 9.1. Public Key Algorithms 44 9.2. Symmetric Key Algorithms 45 9.3. Compression Algorithms 45 9.4. Hash Algorithms 45 - 10. Packet Composition 45 + 10. Packet Composition 46 10.1. Transferable Public Keys 46 10.2. OpenPGP Messages 47 11. Enhanced Key Formats 47 11.1. Key Structures 47 11.2. Key IDs and Fingerprints 48 12. Notes on Algorithms 49 12.1. Symmetric Algorithm Preferences 49 12.2. Other Algorithm Preferences 50 12.2.1. Compression Preferences 50 12.2.2. Hash Algorithm Preferences 51 @@ -642,21 +642,21 @@ 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last 1693 octets of data. This is just one possible encoding, and many variations are possible on the size of the Partial Body Length headers, as long as a regular Body Length header encodes the last portion of the data. Note also that the last Body Length header can be a zero-length header. An implementation MAY use Partial Body Lengths for data packets, be they literal, compressed, or encrypted. The first partial length - MUST be at least 512 octets long. Partial Body Lengths MAY NOT be + MUST be at least 512 octets long. Partial Body Lengths MUST NOT be used for any other packet types. Please note that in all of these explanations, the total length of the packet is the length of the header(s) plus the length of the body. 4.3. Packet Tags The packet tag denotes what type of packet the body holds. Note that old format headers can only have tags less than 16, whereas new @@ -1135,22 +1135,23 @@ This is only found on a self-signature. 5.2.3.8. Preferred compression algorithms (array of one-octet values) Compression algorithm numbers that indicate which algorithms the key holder prefers to use. Like the preferred symmetric algorithms, the list is ordered. Algorithm numbers are in section 6. If this subpacket is not included, ZIP is preferred. A zero denotes that - uncompressed data is preferred; the key holder's software may not - have compression software. This is only found on a self-signature. + uncompressed data is preferred; the key holder's software might have + no compression software in that implementation. This is only found + on a self-signature. 5.2.3.9. Signature expiration time (4 octet time field) The validity period of the signature. This is the number of seconds after the signature creation time that the signature expires. If this is not present or has a value of zero, it never expires. 5.2.3.10. Exportable @@ -1728,22 +1729,22 @@ - One octet that gives the algorithm used to compress the packet. - The remainder of the packet is compressed data. A Compressed Data Packet's body contains an block that compresses some set of packets. See section "Packet Composition" for details on how messages are formed. ZIP-compressed packets are compressed with raw RFC1951 DEFLATE blocks. Note that PGP V2.6 uses 13 bits of compression. If an - implementation uses more bits of compression, If an implementation - uses more bits of compression, PGP V2.6 cannot decompress it. + implementation uses more bits of compression, PGP V2.6 cannot + decompress it. ZLIB-compressed packets are compressed with RFC1950 ZLIB-style blocks. 5.7. Symmetrically Encrypted Data Packet (Tag 9) The Symmetrically Encrypted Data packet contains data encrypted with a symmetric-key algorithm. When it has been decrypted, it will typically contain other packets (often literal data packets or compressed data packets). @@ -1968,20 +1969,29 @@ - "Comment", a user-defined comment. - "MessageID", a 32-character string of printable characters. The string must be the same for all parts of a multi-part message that uses the "PART X" Armor Header. MessageID strings should be unique enough that the recipient of the mail can associate all the parts of a message with each other. A good checksum or cryptographic hash function is sufficient. + - "Hash", a comma-separated list of hash algorithms used in this + message. This is used only in clear-signed messages. + + - "Charset", a description of the character set that the plantext + is in. Please note that OpenPGP defines text to be in UTF-8, so + this Armor Header Key is only useful for backwards + compatibility. An implementation MAY implement it; an + implementation MAY ignore it. + The MessageID SHOULD NOT appear unless it is in a multi-part message. If it appears at all, it MUST be computed from the finished (encrypted, signed, etc.) message in a deterministic fashion, rather than contain a purely random value. This is to allow the legitimate recipient to determine that the MessageID cannot serve as a covert means of leaking cryptographic key information. The Armor Tail Line is composed in the same manner as the Armor Header Line, except the string "BEGIN" is replaced by the string @@ -2108,40 +2117,42 @@ Note that this example is indented by two spaces. 7. Cleartext signature framework It is desirable to sign a textual octet stream without ASCII armoring the stream itself, so the signed text is still readable without special software. In order to bind a signature to such a cleartext, this framework is used. (Note that RFC 2015 defines another way to clear sign messages for environments that support MIME.) + The cleartext signed message consists of: - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a single line, - - Zero or more "Hash" Armor Headers, + - One or more "Hash" Armor Headers, - Exactly one empty line not included into the message digest, - The dash-escaped cleartext that is included into the message digest, - The ASCII armored signature(s) including the Armor Header and Armor Tail Lines. If the "Hash" armor header is given, the specified message digest algorithm is used for the signature. If there are no such headers, - SHA-1 is used. If more than one message digest is used in the - signature, the "Hash" armor header contains a comma-delimited list - of used message digests. + MD5 is used, an implementation MAY omit them for V2.x compatibility. + If more than one message digest is used in the signature, the "Hash" + armor header contains a comma-delimited list of used message + digests. Current message digest names are described below with the algorithm IDs. 7.1. Dash-Escaped Text The cleartext content of the message must also be dash-escaped. Dash escaped cleartext is the ordinary cleartext where every line starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' @@ -2588,21 +2601,21 @@ While verifying Elgamal signatures, note that it is important to test that r and s are less than p. If this test is not done then signatures can be trivially forged by using large r values of approximately twice the length of p. This attack is also discussed in the Bleichenbacher paper. Details on safe use of Elgamal signatures may be found in [MENEZES], which discusses all the weaknesses described above. If an implementation allows Elgamal signatures, then it MUST use the - algorithm identifier 20. + algorithm identifier 20 for an Elgamal public key that can sign. An implementation SHOULD NOT implement Elgamal keys of size less than 768 bits. For long-term security, Elgamal keys should be 1024 bits or longer. 12.6. DSA An implementation SHOULD NOT implement DSA keys of size less than 768 bits. Note that present DSA is limited to a maximum of 1024 bit keys, which are recommended for long-term use. @@ -2669,28 +2682,36 @@ is assumed to be controlled by the proper party or parties. Certain operations in this specification involve the use of random numbers. An appropriate entropy source should be used to generate these numbers. See RFC 1750. The MD5 hash algorithm has been found to have weaknesses (pseudo-collisions in the compress function) that make some people deprecate its use. They consider the SHA-1 algorithm better. + Many security protocol designers think that it is a bad idea to use + a single key for both privacy (encryption) and integrity + (signatures). In fact, this was one of the motivating forces behind + the V4 key format with separate signature and encryption keys. If + you as an implementor promote dual-use keys, you should at least be + aware of this controversy. + 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. + could leak the secret key. These same considerations about the + quality of the hash algorithm apply to Elgamal signatures. If you are building an authentication system, the recipient may specify a preferred signing algorithm. However, the signer would be foolish to use a weak algorithm simply because the recipient requests it. Some of the encryption algorithms mentioned in this document have been analyzed less than others. For example, although CAST5 is presently considered strong, it has been analyzed less than Triple-DES. Other algorithms may have other controversies @@ -2729,34 +2750,32 @@ look directly at the packet data type. * In a clear-signed signature, PGP 5.0 will figure out the correct hash algorithm if there is no "Hash:" header, but it will reject a mismatch between the header and the actual agorithm used. The "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x rejects the "Hash:" header and assumes MD5. There are a number of enhanced variants of PGP 2.6.x that have been modified for SHA-1 signatures. - * PGP 5.0 can read an RSA key in V4 format, but will only - recognize it using V3 format. + * PGP 5.0 can read an RSA key in V4 format, but can only recognize + it with a V3 keyid, and can properly use only a V3 format RSA + key. * There are many ways possible for for two keys to have the same key material, but different fingerprints (and thus key ids). Perhaps the most interesting is an RSA key that has been "upgraded" to V4 format, but since a V4 fingerprint is constructed by hashing the key creation time along with other things, two V4 keys created at different times, yet with the same key material will have different fingerprints. - * PGP 2.6.x and PGP 5.0 sometimes add to the beginning of a file a - zero-length compressed data packet. - * If an implemtation is using zlib to interoperate with PGP 2.x, then the "windowBits" parameter should be set to -13. 15. Authors and Working Group Chair The working group can be contacted via the current chair: John W. Noerenberg, II Qualcomm, Inc 6455 Lusk Blvd @@ -2778,23 +2797,24 @@ Wildenbruchstr. 15 07745 Jena, Germany EMail: lutz@iks-jena.de Tel: +49-3641-675642 Hal Finney Network Associates, Inc. 4200 Bohannon Drive Menlo Park, CA 94025, USA Email: hal@pgp.com + Rodney Thayer EIS Corporation - Clearwater, FL 33767 + Clearwater, FL 33767, USA Email: rodney@unitran.com This draft also draws on much previous work from a number of other authors who include: Derek Atkins, Charles Breed, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann. 16. References