--- 1/draft-ietf-openpgp-formats-02.txt 2006-02-05 00:55:13.000000000 +0100 +++ 2/draft-ietf-openpgp-formats-03.txt 2006-02-05 00:55:13.000000000 +0100 @@ -1,25 +1,25 @@ Network Working Group Jon Callas Category: INTERNET-DRAFT Network Associates -draft-ietf-openpgp-formats-02.txt -Expires Oct 1998 Lutz Donnerhacke -April 1997 IN-Root-CA Individual Network e.V. +draft-ietf-openpgp-formats-03.txt +Expires Nov 1998 Lutz Donnerhacke +May 1998 IN-Root-CA Individual Network e.V. Hal Finney Network Associates Rodney Thayer Sable Technology OpenPGP Message Format - draft-ietf-openpgp-formats-02.txt + draft-ietf-openpgp-formats-03.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. @@ -87,94 +87,96 @@ 4.2.2.2. Two-Octet Lengths 13 4.2.2.3. Five-Octet Lengths 13 4.2.2.4. Partial Body Lengths 13 4.2.3. Packet Length Examples 13 4.3. Packet Tags 14 5. Packet Types 14 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 14 5.2. Signature Packet (Tag 2) 16 5.2.1. Signature Types 16 5.2.2. Version 3 Signature Packet Format 18 - 5.2.3. Version 4 Signature Packet Format 19 + 5.2.3. Version 4 Signature Packet Format 20 5.2.3.1. Signature Subpacket Specification 20 - 5.2.3.2. Signature Subpacket Types 21 + 5.2.3.2. Signature Subpacket Types 22 5.2.3.3. Signature creation time 22 - 5.2.3.4. Issuer 22 - 5.2.3.5. Key expiration time 22 - 5.2.3.6. Preferred symmetric algorithms 22 + 5.2.3.4. Issuer 23 + 5.2.3.5. Key expiration time 23 + 5.2.3.6. Preferred symmetric algorithms 23 5.2.3.7. Preferred hash algorithms 23 5.2.3.8. Preferred compression algorithms 23 5.2.3.9. Signature expiration time 23 - 5.2.3.10.Exportable 23 - 5.2.3.11.Revocable 23 + 5.2.3.10.Exportable 24 + 5.2.3.11.Revocable 24 5.2.3.12.Trust signature 24 5.2.3.13.Regular expression 24 - 5.2.3.14.Revocation key 24 + 5.2.3.14.Revocation key 25 5.2.3.15.Notation Data 25 5.2.3.16.Key server preferences 25 - 5.2.3.17.Preferred key server 25 + 5.2.3.17.Preferred key server 26 5.2.3.18.Primary user id 26 5.2.3.19.Policy URL 26 5.2.3.20.Key Flags 26 5.2.3.21.Signer's User ID 27 5.2.4. Computing Signatures 27 - 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 28 - 5.4. One-Pass Signature Packets (Tag 4) 29 - 5.5. Key Material Packet 29 - 5.5.1. Key Packet Variants 29 - 5.5.1.1. Public Key Packet (Tag 6) 29 + 5.2.4.1. Subpacket Hints 28 + 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 29 + 5.4. One-Pass Signature Packets (Tag 4) 30 + 5.5. Key Material Packet 30 + 5.5.1. Key Packet Variants 30 + 5.5.1.1. Public Key Packet (Tag 6) 30 5.5.1.2. Public Subkey Packet (Tag 14) 30 - 5.5.1.3. Secret Key Packet (Tag 5) 30 - 5.5.1.4. Secret Subkey Packet (Tag 7) 30 - 5.5.2. Public Key Packet Formats 30 - 5.5.3. Secret Key Packet Formats 32 - 5.6. Compressed Data Packet (Tag 8) 33 - 5.7. Symmetrically Encrypted Data Packet (Tag 9) 34 - 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 34 - 5.9. Literal Data Packet (Tag 11) 35 - 5.10. Trust Packet (Tag 12) 35 - 5.11. User ID Packet (Tag 13) 36 - 6. Radix-64 Conversions 36 - 6.1. An Implementation of the CRC-24 in "C" 36 - 6.2. Forming ASCII Armor 37 + 5.5.1.3. Secret Key Packet (Tag 5) 31 + 5.5.1.4. Secret Subkey Packet (Tag 7) 31 + 5.5.2. Public Key Packet Formats 31 + 5.5.3. Secret Key Packet Formats 33 + 5.6. Compressed Data Packet (Tag 8) 34 + 5.7. Symmetrically Encrypted Data Packet (Tag 9) 35 + 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 35 + 5.9. Literal Data Packet (Tag 11) 36 + 5.10. Trust Packet (Tag 12) 36 + 5.11. User ID Packet (Tag 13) 37 + 6. Radix-64 Conversions 37 + 6.1. An Implementation of the CRC-24 in "C" 37 + 6.2. Forming ASCII Armor 38 6.3. Encoding Binary in Radix-64 39 - 6.4. Decoding Radix-64 40 - 6.5. Examples of Radix-64 40 - 6.6. Example of an ASCII Armored Message 41 - 7. Cleartext signature framework 41 + 6.4. Decoding Radix-64 41 + 6.5. Examples of Radix-64 41 + 6.6. Example of an ASCII Armored Message 42 + 7. Cleartext signature framework 42 7.1. Dash-Escaped Text 42 - 8. Regular Expressions 42 + 8. Regular Expressions 43 9. Constants 43 - 9.1. Public Key Algorithms 43 - 9.2. Symmetric Key Algorithms 43 + 9.1. Public Key Algorithms 44 + 9.2. Symmetric Key Algorithms 44 9.3. Compression Algorithms 44 - 9.4. Hash Algorithms 44 - 10. Packet Composition 44 - 10.1. Transferable Public Keys 44 - 10.2. OpenPGP Messages 45 - 11. Enhanced Key Formats 46 - 11.1. Key Structures 46 - 11.2. Key IDs and Fingerprints 47 + 9.4. Hash Algorithms 45 + 10. Packet Composition 45 + 10.1. Transferable Public Keys 45 + 10.2. OpenPGP Messages 46 + 11. Enhanced Key Formats 47 + 11.1. Key Structures 47 + 11.2. Key IDs and Fingerprints 48 12. Notes on Algorithms 48 12.1. Symmetric Algorithm Preferences 48 - 12.2. Other Algorithm Preferences 48 + 12.2. Other Algorithm Preferences 49 12.2.1. Compression Preferences 49 - 12.2.2. Hash Algorithm Preferences 49 - 12.3. Plaintext 49 - 12.4. RSA 49 - 12.5. Elgamal 49 - 12.6. DSA 50 - 12.7. OpenPGP CFB mode 50 - 13. Security Considerations 51 - 14. Authors and Working Group Chair 52 - 15. References 53 - 16. Full Copyright Statement 54 + 12.2.2. Hash Algorithm Preferences 50 + 12.3. Plaintext 50 + 12.4. RSA 50 + 12.5. Elgamal 51 + 12.6. DSA 51 + 12.7. OpenPGP CFB mode 51 + 13. Security Considerations 52 + 14. Implementation Nits 53 + 15. Authors and Working Group Chair 54 + 16. References 55 + 17. Full Copyright Statement 56 1. Introduction This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, key management and functions. It builds on the foundation provided in RFC 1991 "PGP Message Exchange Formats." 1.1. Terms @@ -550,25 +552,27 @@ 0 - The packet has a one-octet length. The header is 2 octets long. 1 - The packet has a two-octet length. The header is 3 octets long. 2 - The packet has a four-octet length. The header is 5 octets long. 3 - The packet is of indeterminate length. The header is 1 octet long, and the implementation must determine how long the packet is. If the packet is in a file, this means that the packet - extends until the end of the file. In general, an implementation - should not use indeterminate length packets except where the end - of the data will be clear from the context. The new format - headers described below have a mechanism for precisely encoding - data of indeterminite length. + extends until the end of the file. With a compressed packet, the + algorithm implicitly denotes how the end of the packet. In + general, an implementation SHOULD NOT use indeterminate length + packets except where the end of the data will be clear from the + context, and even then it is better to use a definite length, or + a new-format header. The new-format headers described below have + a mechanism for precisely encoding data of indeterminite length. 4.2.2. New-Format Packet Lengths New format packets have four possible ways of encoding length: 1. A one-octet Body Length header encodes packet lengths of up to 191 octets. 2. A two-octet Body Length header encodes packet lengths of 192 to 8383 octets. @@ -611,48 +614,50 @@ A Partial Body Length header is one octet long and encodes the length of only part of the data packet. This length is a power of 2, from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by its one octet value that is greater than or equal to 224, and less than 255. The partial body length is equal to: partialBodyLen = 1 << (length_octet & 0x1f); Each Partial Body Length header is followed by a portion of the packet body data. The Partial Body Length header specifies this - portion's length. Another length header (of one of the three types) - follows that portion. The last length header in the packet must not - be a partial Body Length header. Partial Body Length headers may - only be used for the non-final parts of the packet. + portion's length. Another length header (of one of the three types + -- one octet, two-octet, or partial) follows that portion. The last + length header in the packet MUST NOT be a partial Body Length + header. Partial Body Length headers may only be used for the + non-final parts of the packet. 4.2.3. Packet Length Examples A packet with length 100 may have its length encoded in one octet: 0x64. This is followed by 100 octets of data. A packet with length 1723 may have its length coded in two octets: 0xC5, 0xFB. This header is followed by the 1723 octets of data. A packet with length 100000 may have its length encoded in five - octets: 0xFF, 0x01, 0x86, 0xA0. + octets: 0xFF, 0x00, 0x01, 0x86, 0xA0. - It might also be encoded in the following octet stream: 0xE1, first - two octets of data, 0xE0, next one octet of data, 0xEF, next 32768 - octets of data, 0xF0, next 65536 octets of data, 0xC5, 0xDD, last + It might also be encoded in the following octet stream: 0xEF, first + 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 MUST only use Partial Body Lengths for data - packets, be they literal, compressed, or encrypted. The first - partial length MUST be at least 512 octets long. + 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 + 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 format headers can have tags as great as 63. The defined tags (in @@ -901,28 +905,44 @@ - MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A The ASN.1 OIDs are: - - MD5: 1.2.840.113549.2.2 + - MD2: 1.2.840.113549.2.2 - MD5: 1.2.840.113549.2.5 - - RIPEMD160: 1.3.36.3.2.1 + - RIPEMD-160: 1.3.36.3.2.1 - SHA-1: 1.3.14.3.2.26 + The full hash prefixes for these are: + + MD2: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, + 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00, + 0x04, 0x10 + + MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, + 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, + 0x04, 0x10 + + RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, + 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 + + SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, + 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 + DSA signatures SHOULD 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. 5.2.3. Version 4 Signature Packet Format The body of a version 4 Signature Packet contains: - One-octet version number (4). @@ -1335,21 +1354,21 @@ octet 0x99, followed by a two-octet length of the key, and then body of the key packet. (Note that this is an old-style packet header for a key packet with two-octet length.) A subkey signature (type 0x18) then hashes the subkey, using the same format as the main key. Key revocation signatures (types 0x20 and 0x28) hash only the key being revoked. A certification signature (type 0x10 through 0x13) hashes the user id being bound to the key into the hash context after the above data. A V3 certification hashes the contents of the name packet, - without any header. A V4 certification hashes the constant 0xd4 + without any header. A V4 certification hashes the constant 0xb4 (which is an old-style packet header with the length-of-length set to zero), a four-octet number giving the length of the username, and then the username data. Once the data body is hashed, then a trailer is hashed. A V3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature time. A V4 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data. Thus, the fields hashed are the @@ -1360,20 +1379,44 @@ V4 signatures also hash in a final trailer of six octets: the version of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian number that is the length of the hashed data from the signature packet (note that this number does not include these final six octets. After all this has been hashed, the resulting hash field is used in the signature algorithm, and placed at the end of the signature packet. +5.2.4.1. Subpacket Hints + + An implementation SHOULD put the two mandatory subpackets, creation + time and issuer, as the first subpackets in the subpacket list, + simply to make it easier for the implementor to find them. + + It is certainly possible for a signature to contain conflicting + information in subpackets. For example, a signature may contain + multiple copies of a preference or multiple expiration times. In + most cases, an implementation SHOULD use the last subpacket in the + signature, but MAY use any conflict resolution scheme that makes + more sense. Please note that we are intentionally leaving conflict + resolution to the implementor; most conflicts are simply syntax + errors, and the wishy-washy language here allows a receiver to be + generous in what they accept, while putting pressure on a creator to + be stingy in what they generate. + + Some apparent conflicts may actually make sense -- for example, + suppose a keyholder has an V3 key and a V4 key that share the same + RSA key material. Either of these keys can verify a signature + created by the other, and it may be reasonable for a signature to + contain an issuer subpacket for each key, as a way of explicitly + tying those keys to the signature. + 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) The Symmetric-Key Encrypted Session Key packet holds the symmetric-key encryption of a session key used to encrypt a message. Zero or more Encrypted Session Key packets and/or Symmetric-Key Encrypted Session Key packets may precede a Symmetrically Encrypted Data Packet that holds an encrypted message. The message is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet or the Symmetric-Key Encrypted Session Key packet. @@ -1661,20 +1705,23 @@ 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, it cannot be decompressed by PGP V2.6 + 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). The body of this packet consists of: - Encrypted data, the output of the selected symmetric-key cipher @@ -1704,21 +1751,21 @@ 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) An experimental version of PGP used this packet as the Literal packet, but no released version of PGP generated Literal packets with this tag. With PGP 5.x, this packet has been re-assigned and is reserved for use as the Marker packet. The body of this packet consists of: - - The three octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8). + - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). Such a packet MUST be ignored when received. It may be placed at the beginning of a message that uses features not available in PGP 2.6.x in order to cause that version to report that newer software is necessary to process the message. 5.9. Literal Data Packet (Tag 11) A Literal Data packet contains the body of a message; data that is not to be further interpreted. @@ -2016,24 +2065,25 @@ 8-bit: 00010100 11111011 10011100 | 00000011 pad with 0000 6-bit: 000101 001111 101110 011100 | 000000 110000 Decimal: 5 15 46 28 0 48 pad with = = Output: F P u c A w = = 6.6. Example of an ASCII Armored Message -----BEGIN PGP MESSAGE----- - Version: OpenPGP 1.0 + Version: OpenPrivacy 0.99 - yCoBc07MUy9RSMyrzM9LVchOTS1QSFQoTk0uSgUKFuWX5qUoZKQWpdpzAQA= - =jYsF + yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS + vBSFjNSiVHsuAA== + =njUN -----END PGP MESSAGE----- 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 @@ -2161,35 +2211,37 @@ Implementations MUST implement Triple-DES. Implementations SHOULD implement IDEA and CAST5.Implementations MAY implement any other algorithm. 9.3. Compression Algorithms ID Algorithm -- --------- 0 - Uncompressed - 1 - ZIP + 1 - ZIP (RFC1951) + 2 - ZLIB (RFC1950) 100 to 110 - Private/Experimental algorithm. Implementations MUST implement uncompressed data. Implementations SHOULD implement ZIP. 9.4. Hash Algorithms ID Algorithm Text Name -- --------- ---- ---- 1 - MD5 "MD5" 2 - SHA-1 "SHA1" 3 - RIPE-MD/160 "RIPEMD160" 4 - HAVAL (5 pass, 160-bit) "HAVAL-5-160" 5 - MD2 "MD2" + 6 - TIGER/192 "TIGER192" 100 to 110 - Private/Experimental algorithm. Implementations MUST implement SHA-1. Implementations SHOULD implement MD5. 10. Packet Composition OpenPGP packets are assembled into sequences in order to create messages @@ -2418,27 +2470,34 @@ Other algorithm preferences work similarly to the symmetric algorithm preference, in that they specify which algorithms the keyholder accepts. There are two interesting cases that other comments need to be made about, though, the compression preferences and the hash preferences. 12.2.1. Compression Preferences Compression has been an integral part of PGP since its first days. + OpenPGP and all previous versions of PGP have offered compression. And in this specification, the default is for messages to be compressed, although an implementation is not required to do so. Consequently, the compression preference gives a way for a keyholder to request that messages not be compressed, presumably because they are using a minimal implementation that does not include - compression. + compression. Additionally, this gives a keyholder a way to state + that it can support alternate algorithms. + + Like the algorithm preferences, an implementation MUST NOT use an + algorithm that is not in the preference vector. If the preferences + are mot present, then they are assumed to be [ZIP(1), + UNCOMPRESSED(0)]. 12.2.2. Hash Algorithm Preferences Typically, the choice of a hash algorithm is something the signer does, rather than the verifier, because a signer does not typically know who is going to be verifying the signature. This preference, though, allows a protocol based upon digital signatures ease in negotiation. Thus, if Alice is authenticating herself to Bob with a signature, it @@ -2512,21 +2571,23 @@ 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. 12.7. OpenPGP CFB mode OpenPGP does symmetric encryption using a variant of Cipher Feedback Mode (CFB mode). This section describes the procedure it uses in - detail. + detail. This mode is what is used for Symmetrically Ecrypted Data + Packets; the mechanism used for encrypting secret key material is + similar, but described in those sections above. OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and prefixes the plaintext with ten bytes of random data, such that bytes 9 and 10 match bytes 7 and 8. It does a CFB "resync" after encrypting those ten bytes. Note that for an algorithm that has a larger block size than 64 bits, the equivalent function will be done with that entire block. Step by step, here is the procedure: @@ -2598,21 +2659,76 @@ 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 surrounding them. Some technologies mentioned here may be subject to government control in some countries. -14. Authors and Working Group Chair +14. Implementation Nits + + This section is a collection of comments to help an implementor, + particularly with an eye to backwards compatibility. Previous + implementations of PGP are not OpenPGP-compliant. Often the + differences are small, but small differences are frequently more + vexing than large differences. Thus, this list of potential problems + and gotchas for a developer who is trying to be + backwards-compatible. + + * PGP 5.x does not accept V4 signatures for anything other than + key material. + + * PGP 5.x does not recognize the "five-octet" lengths in + new-format headers or in signature subpacket lengths. + + * PGP 5.0 rejects an encrypted session key if the keylength + differs from the the S2K symmetric algorithm. This is a bug in + its validation function. + + * PGP 5.0 does not handle multiple one-pass signature headers and + trailers. Signing one will compress the one-pass signed literal + and prefix a V3 signature instead of doing a nested one-pass + signature. + + * When exporting a private key, PGP 2.x generates the header + "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY + BLOCK". All previous versions ignore the implied data type, and + 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. + + * 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 San Diego, CA 92131 USA Email: jwn2@qualcomm.com Tel: +1 619-658-3510 @@ -2644,21 +2760,21 @@ Newton, MA 02160 USA Email: rodney@sabletech.com Tel: +1-617-332-7292 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. -15. References +16. References [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal signatures without knowing the secret key," Eurocrypt 96. Note that the version in the proceedings has an error. A revised version is available at the time of writing from [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved international version of PGP", ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/ @@ -2705,21 +2822,21 @@ [RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and ISO 10646. October 1996. [RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies.", November 1996 [RFC2119] Bradner, S., Key words for use in RFCs to Indicate Requirement Level. March 1997. -16. Full Copyright Statement +17. Full Copyright Statement Copyright 1998 by The Internet Society. All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing