--- 1/draft-ietf-openpgp-rfc2440bis-06.txt 2006-02-05 00:55:37.000000000 +0100 +++ 2/draft-ietf-openpgp-rfc2440bis-07.txt 2006-02-05 00:55:37.000000000 +0100 @@ -1,25 +1,25 @@ Network Working Group Jon Callas -Category: INTERNET-DRAFT -draft-ietf-openpgp-rfc2440bis-06.txt -Expires Feb 2003 Lutz Donnerhacke -August 2002 IN-Root-CA Individual Network e.V. +Category: INTERNET-DRAFT PGP Corporation +draft-ietf-openpgp-rfc2440bis-07.txt +Expires Sep 2003 Lutz Donnerhacke +March 2003 IN-Root-CA Individual Network e.V. Hal Finney Network Associates Rodney Thayer OpenPGP Message Format - draft-ietf-openpgp-rfc2440bis-06.txt + draft-ietf-openpgp-rfc2440bis-07.txt - Copyright 2002 by The Internet Society. All Rights Reserved. + Copyright 2003 by The Internet Society. All Rights Reserved. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. @@ -83,129 +83,129 @@ 2.4. Conversion to Radix-64 8 2.5. Signature-Only Applications 8 3. Data Element Formats 9 3.1. Scalar numbers 9 3.2. Multi-Precision Integers 9 3.3. Key IDs 9 3.4. Text 10 3.5. Time fields 10 3.6. Keyrings 10 3.7. String-to-key (S2K) specifiers 10 - 3.7.1. String-to-key (S2k) specifier types 10 + 3.7.1. String-to-key (S2K) specifier types 10 3.7.1.1. Simple S2K 10 3.7.1.2. Salted S2K 11 3.7.1.3. Iterated and Salted S2K 11 3.7.2. String-to-key usage 12 3.7.2.1. Secret key encryption 12 - 3.7.2.2. Symmetric-key message encryption 12 + 3.7.2.2. Symmetric-key message encryption 13 4. Packet Syntax 13 4.1. Overview 13 4.2. Packet Headers 13 4.2.1. Old-Format Packet Lengths 14 4.2.2. New-Format Packet Lengths 14 - 4.2.2.1. One-Octet Lengths 14 + 4.2.2.1. One-Octet Lengths 15 4.2.2.2. Two-Octet Lengths 15 4.2.2.3. Five-Octet Lengths 15 4.2.2.4. Partial Body Lengths 15 - 4.2.3. Packet Length Examples 15 + 4.2.3. Packet Length Examples 16 4.3. Packet Tags 16 - 5. Packet Types 16 - 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16 + 5. Packet Types 17 + 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17 5.2. Signature Packet (Tag 2) 18 5.2.1. Signature Types 18 5.2.2. Version 3 Signature Packet Format 20 - 5.2.3. Version 4 Signature Packet Format 22 - 5.2.3.1. Signature Subpacket Specification 23 + 5.2.3. Version 4 Signature Packet Format 23 + 5.2.3.1. Signature Subpacket Specification 24 5.2.3.2. Signature Subpacket Types 25 5.2.3.3. Notes on Self-Signatures 25 5.2.3.4. Signature creation time 26 5.2.3.5. Issuer 26 - 5.2.3.6. Key expiration time 26 - 5.2.3.7. Preferred symmetric algorithms 26 + 5.2.3.6. Key expiration time 27 + 5.2.3.7. Preferred symmetric algorithms 27 5.2.3.8. Preferred hash algorithms 27 5.2.3.9. Preferred compression algorithms 27 5.2.3.10.Signature expiration time 27 5.2.3.11.Exportable Certification 27 5.2.3.12.Revocable 28 5.2.3.13.Trust signature 28 - 5.2.3.14.Regular expression 28 - 5.2.3.15.Revocation key 28 + 5.2.3.14.Regular expression 29 + 5.2.3.15.Revocation key 29 5.2.3.16.Notation Data 29 5.2.3.17.Key server preferences 30 5.2.3.18.Preferred key server 30 5.2.3.19.Primary user id 30 - 5.2.3.20.Policy URL 30 + 5.2.3.20.Policy URL 31 5.2.3.21.Key Flags 31 5.2.3.22.Signer's User ID 32 5.2.3.23.Reason for Revocation 32 5.2.3.24.Features 33 - 5.2.3.25.Revocation Target 33 - 5.2.4. Computing Signatures 33 - 5.2.4.1. Subpacket Hints 34 - 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 35 + 5.2.3.25.Signature Target 33 + 5.2.4. Computing Signatures 34 + 5.2.4.1. Subpacket Hints 35 + 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 35 5.4. One-Pass Signature Packets (Tag 4) 36 - 5.5. Key Material Packet 36 - 5.5.1. Key Packet Variants 36 - 5.5.1.1. Public Key Packet (Tag 6) 36 + 5.5. Key Material Packet 37 + 5.5.1. Key Packet Variants 37 + 5.5.1.1. Public Key Packet (Tag 6) 37 5.5.1.2. Public Subkey Packet (Tag 14) 37 5.5.1.3. Secret Key Packet (Tag 5) 37 5.5.1.4. Secret Subkey Packet (Tag 7) 37 - 5.5.2. Public Key Packet Formats 37 + 5.5.2. Public Key Packet Formats 38 5.5.3. Secret Key Packet Formats 39 - 5.6. Compressed Data Packet (Tag 8) 40 + 5.6. Compressed Data Packet (Tag 8) 41 5.7. Symmetrically Encrypted Data Packet (Tag 9) 41 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 42 - 5.9. Literal Data Packet (Tag 11) 42 + 5.9. Literal Data Packet (Tag 11) 43 5.10. Trust Packet (Tag 12) 43 5.11. User ID Packet (Tag 13) 43 - 5.12. User Attribute Packet (Tag 17) 43 + 5.12. User Attribute Packet (Tag 17) 44 5.12.1. The Image Attribute Subpacket 44 - 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 44 - 5.14. Modification Detection Code Packet (Tag 19) 46 + 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45 + 5.14. Modification Detection Code Packet (Tag 19) 47 6. Radix-64 Conversions 47 - 6.1. An Implementation of the CRC-24 in "C" 47 + 6.1. An Implementation of the CRC-24 in "C" 48 6.2. Forming ASCII Armor 48 - 6.3. Encoding Binary in Radix-64 50 - 6.4. Decoding Radix-64 51 + 6.3. Encoding Binary in Radix-64 51 + 6.4. Decoding Radix-64 52 6.5. Examples of Radix-64 52 - 6.6. Example of an ASCII Armored Message 52 - 7. Cleartext signature framework 52 - 7.1. Dash-Escaped Text 53 + 6.6. Example of an ASCII Armored Message 53 + 7. Cleartext signature framework 53 + 7.1. Dash-Escaped Text 54 8. Regular Expressions 54 - 9. Constants 54 - 9.1. Public Key Algorithms 54 + 9. Constants 55 + 9.1. Public Key Algorithms 55 9.2. Symmetric Key Algorithms 55 - 9.3. Compression Algorithms 55 - 9.4. Hash Algorithms 55 + 9.3. Compression Algorithms 56 + 9.4. Hash Algorithms 56 10. Packet Composition 56 10.1. Transferable Public Keys 56 - 10.2. OpenPGP Messages 57 + 10.2. OpenPGP Messages 58 10.3. Detached Signatures 58 - 11. Enhanced Key Formats 58 - 11.1. Key Structures 58 - 11.2. Key IDs and Fingerprints 59 - 12. Notes on Algorithms 60 - 12.1. Symmetric Algorithm Preferences 60 + 11. Enhanced Key Formats 59 + 11.1. Key Structures 59 + 11.2. Key IDs and Fingerprints 60 + 12. Notes on Algorithms 61 + 12.1. Symmetric Algorithm Preferences 61 12.2. Other Algorithm Preferences 61 - 12.2.1. Compression Preferences 61 + 12.2.1. Compression Preferences 62 12.2.2. Hash Algorithm Preferences 62 12.3. Plaintext 62 - 12.4. RSA 62 - 12.5. Elgamal 62 - 12.6. DSA 63 - 12.7. Reserved Algorithm Numbers 63 + 12.4. RSA 63 + 12.5. Elgamal 63 + 12.6. DSA 64 + 12.7. Reserved Algorithm Numbers 64 12.8. OpenPGP CFB mode 64 13. Security Considerations 65 14. Implementation Nits 67 - 15. Authors and Working Group Chair 68 - 16. References 69 - 17. Full Copyright Statement 71 + 15. Authors and Working Group Chair 69 + 16. References 70 + 17. Full Copyright Statement 72 1. Introduction This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, and key management functions. It is a revision of RFC2440, "OpenPGP Message Format", which itself replaces RFC 1991, "PGP Message Exchange Formats." 1.1. Terms @@ -227,21 +227,21 @@ the PGP 2.6.x design. It is referred to here as PGP 5.x because that software was the first release of the "PGP 3" code base. * GPG - GNU Privacy Guard, also called GNUpg. GPG is an OpenPGP implementation that avoids all encumbered algorithms. Consequently, early versions of GPG did not include RSA public keys. GPG may or may not have (depending on version) support for IDEA or other encumbered algorithms. "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of - Network Associates, Inc. and are used with permission. + PGP Corporation and are used with permission. This document uses the terms "MUST", "SHOULD", and "MAY" as defined in RFC2119, along with the negated forms of those terms. 2. General functions OpenPGP provides data integrity services for messages and data files by using these core technologies: - digital signatures @@ -426,33 +426,42 @@ standard to discuss the details of keyrings or other databases. 3.7. String-to-key (S2K) specifiers String-to-key (S2K) specifiers are used to convert passphrase strings into symmetric-key encryption/decryption keys. They are used in two places, currently: to encrypt the secret part of private keys in the private keyring, and to convert passphrases to encryption keys for symmetrically encrypted messages. -3.7.1. String-to-key (S2k) specifier types +3.7.1. String-to-key (S2K) specifier types - There are three types of S2K specifiers currently supported, as - follows: + There are three types of S2K specifiers currently supported, and + some reserved values: + + ID S2K Type + -- --- ---- + 0 Simple S2K + 1 Salted S2K + 2 Illegal value + 3 Iterated and Salted S2K + 100 to 110 Private/Experimental S2K + + These are described as follows: 3.7.1.1. Simple S2K This directly hashes the string to produce the key data. See below for how this hashing is done. Octet 0: 0x00 Octet 1: hash algorithm - Simple S2K hashes the passphrase to produce the session key. The manner in which this is done depends on the size of the session key (which will depend on the cipher used) and the size of the hash algorithm's output. If the hash size is greater than the session key size, the high-order (leftmost) octets of the hash are used as the key. If the hash size is less than the key size, multiple instances of the hash context are created -- enough to produce the required key data. These instances are preloaded with 0, 1, 2, ... octets of @@ -536,23 +545,22 @@ For compatibility, when an S2K specifier is used, the special value 255 is stored in the position where the hash algorithm octet would have been in the old data structure. This is then followed immediately by a one-octet algorithm identifier, and then by the S2K specifier as encoded above. Therefore, preceding the secret data there will be one of these possibilities: 0: secret data is unencrypted (no pass phrase) - 255: followed by algorithm octet and S2K specifier + 255 or 254: followed by algorithm octet and S2K specifier Cipher alg: use Simple S2K algorithm using MD5 hash - This last possibility, the cipher algorithm number with an implicit use of MD5 and IDEA, is provided for backward compatibility; it MAY be understood, but SHOULD NOT be generated, and is deprecated. These are followed by an Initial Vector of the same length as the block size of the cipher for the decryption of the secret values, if they are encrypted, and then the secret key values themselves. 3.7.2.2. Symmetric-key message encryption @@ -917,29 +925,36 @@ 0x28: Subkey revocation signature The signature is calculated directly on the subkey being revoked. A revoked subkey is not to be used. Only revocation signatures by the top-level signature key that is bound to this subkey, or by an authorized revocation key, should be considered valid revocation signatures. 0x30: Certification revocation signature This signature revokes an earlier user ID certification - signature (signature class 0x10 through 0x13). It should be - issued by the same key that issued the revoked signature or an - authorized revocation key The signature should have a later - creation date than the signature it revokes. + signature (signature class 0x10 through 0x13) or direct-key + signature (0x1F). It should be issued by the same key that + issued the revoked signature or an authorized revocation key. + The signature should have a later creation date than the + signature it revokes. 0x40: Timestamp signature. This signature is only meaningful for the timestamp contained in it. + 0x50: Notary signature. + This signature is a signature over some other OpenPGP signature + packet. It is a notary seal on the signed data. Note that a + notary signature SHOULD include a Signature Target subpacket to + give easy identification. + 5.2.2. Version 3 Signature Packet Format The body of a version 3 Signature Packet contains: - One-octet version number (3). - One-octet length of following hashed material. MUST be 5. - One-octet signature type. @@ -1066,21 +1080,21 @@ - One-octet public key algorithm. - One-octet hash algorithm. - Two-octet scalar octet count for following hashed subpacket data. Note that this is the length in octets of all of the hashed subpackets; a pointer incremented by this number will skip over the hashed subpackets. - - Hashed subpacket data. (two or more subpackets) + - Hashed subpacket data. (zero or more subpackets) - Two-octet scalar octet count for following unhashed subpacket data. Note that this is the length in octets of all of the unhashed subpackets; a pointer incremented by this number will skip over the unhashed subpackets. - Unhashed subpacket data. (zero or more subpackets) - Two-octet field holding left 16 bits of signed hash value. @@ -1108,22 +1122,21 @@ Each set of subpackets is preceded by a two-octet scalar count of the length of the set of subpackets. Each subpacket consists of a subpacket header and a body. The header consists of: - the subpacket length (1, 2, or 5 octets) - the subpacket type (1 octet) - and is followed by the subpacket specific data. Note that this is - the same encoding used for signature subpackets + and is followed by the subpacket specific data. The length includes the type octet but not this length. Its format is similar to the "new" format packet header lengths, but cannot have partial body lengths. That is: if the 1st octet < 192, then lengthOfLength = 1 subpacketLen = 1st_octet if the 1st octet >= 192 and < 255, then @@ -1151,21 +1164,21 @@ 21 = preferred hash algorithms 22 = preferred compression algorithms 23 = key server preferences 24 = preferred key server 25 = primary user id 26 = policy URL 27 = key flags 28 = signer's user id 29 = reason for revocation 30 = features - 31 = revocation identification + 31 = signature target 100 to 110 = internal or user-defined An implementation SHOULD ignore any subpacket of a type that it does not recognize. Bit 7 of the subpacket type is the "critical" bit. If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating software, the @@ -1201,44 +1214,45 @@ A self-signature is a binding signature made by the key the signature refers to. There are three types of self-signatures, the certification signatures (types 0x10-0x13), the direct-key signature (type 0x1f), and the subkey binding signature (type 0x18). For certification self-signatures, each user ID may have a self-signature, and thus different subpackets in those self-signatures. For subkey binding signatures, each subkey in fact has a self-signature. Subpackets that appear in a certification self-signature apply to the username, and subpackets that appear in the subkey self-signature apply to the subkey. Lastly, subpackets on - the direct key signature apply to the entire key. + the direct-key signature apply to the entire key. Implementing software should interpret a self-signature's preference subpackets as narrowly as possible. For example, suppose a key has two usernames, Alice and Bob. Suppose that Alice prefers the symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If the software locates this key via Alice's name, then the preferred algorithm is CAST5, if software locates the key via Bob's name, then the preferred algorithm is IDEA. If the key is located by key id, then algorithm of the default user id of the key provides the default symmetric algorithm. - Revoking a self-signature or allowing it to expire has a defined - semantic meaning. Revoking the self-signature on a user ID - effectively retires that user name. The self-signature is a - statement, "My name X is tied to my signing key K" and is - corroborated by other users' certifications. If another user revokes - their certification, they are effectively saying that they no longer - believe that name and that key are tied together. Similarly, if the - user themselves revokes their self-signature, it means the user no - longer goes by that name, no longer has that email address, etc. - Revoking a binding signature effectively retires that subkey. Please - see the "Reason for Revocation" subpacket below for more relevant - detail. + Revoking a self-signature or allowing it to expire has a semantic + meaning that varies with the signature type. Revoking the + self-signature on a user ID effectively retires that user name. The + self-signature is a statement, "My name X is tied to my signing key + K" and is corroborated by other users' certifications. If another + user revokes their certification, they are effectively saying that + they no longer believe that name and that key are tied together. + Similarly, if the user themselves revokes their self-signature, it + means the user no longer goes by that name, no longer has that email + address, etc. Revoking a binding signature effectively retires that + subkey. Revoking a direct-key signature cancels that signature. + Please see the "Reason for Revocation" subpacket below for more + relevant detail. Since a self-signature contains important information about the key's use, an implementation SHOULD allow the user to rewrite the self-signature, and important information in it, such as preferences and key expiration. An implementation that encounters multiple self-signatures on the same object may resolve the ambiguity in any way it sees fit, but it is RECOMMENDED that priority be given to the most recent self-signature. @@ -1608,27 +1621,28 @@ 0x01 - Modification Detection (packets 18 and 19) If an implementation implements any of the defined features, it SHOULD implement the features subpacket, too. In the case of Modification Detection, an implementation may freely infer this feature from other suitable implementation-dependent mechanisms. -5.2.3.25. Revocation Target +5.2.3.25. Signature Target (1 octet PK algorithm, 1 octet hash algorithm, N octets hash) - This subpacket identifies a specific target signature that a - revocation signature revokes. This provides explicit designation of - a revocation. All arguments are an identifier of that signature. + signature refers to. For revocation signatures, this subpacket + provides explicit designation of which signature is being revoked. + For a notary or timestamp signature, this designates what signature + is signed. All arguments are an identifier of that target signature. The N octets of hash data MUST be the size of the hash of the signature. For example, a target signature with a SHA-1 hash MUST have 20 octets of hash data. 5.2.4. Computing Signatures All signatures are formed by producing a hash over the signature data, and then using the resulting hash in the signature algorithm. @@ -1691,21 +1705,21 @@ 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) +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. @@ -1915,21 +1929,21 @@ Public Key and Public Subkey packets, with additional algorithm-specific secret key data appended, in encrypted form. The packet contains: - A Public Key or Public Subkey packet, as described above - One octet indicating string-to-key usage conventions. 0 indicates that the secret key data is not encrypted. 255 or 254 indicates that a string-to-key specifier is being given. Any - other value is a symmetric-key encryption algorithm specifier. + other value is a symmetric-key encryption algorithm identifier. - [Optional] If string-to-key usage octet was 255 or 254, a one-octet symmetric encryption algorithm. - [Optional] If string-to-key usage octet was 255 or 254, a string-to-key specifier. The length of the string-to-key specifier is implied by its type, as described above. - [Optional] If secret data is encrypted, Initial Vector (IV) of the same length as the cipher's block size. @@ -2036,26 +2050,26 @@ Symmetrically Encrypted Data Packet. In that case, the cipher algorithm octet is prefixed to the session key before it is encrypted. If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase. 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 a string of length equal to the block size of the cipher plus two to the data - before it is encrypted. The first block-length octets (for example, - 8 octets for a 64-bit block length) are random, and the following - two octets are copies of the last two octets of the IV. For example, - in an 8 octet block, octet 9 is a repeat of octet 7, and octet 10 is - a repeat of octet 8. In a cipher of length 16, octet 17 is a repeat - of octet 15 and octet 18 is a repeat of octet 16. As a pedantic + before it is encrypted. The first block-size octets (for example, 8 + octets for a 64-bit block length) are random, and the following two + octets are copies of the last two octets of the IV. For example, in + an 8 octet block, octet 9 is a repeat of octet 7, and octet 10 is a + repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of + octet 15 and octet 18 is a repeat of octet 16. As a pedantic clarification, in both these examples, we consider the first octet to be numbered 1. After encrypting the first block-size-plus-two octets, the CFB state is resynchronized. The last block-size octets of ciphertext are passed through the cipher and the block boundary is reset. 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. @@ -2171,22 +2185,22 @@ (but not required to be) that of the key owner. The image attribute subpacket begins with an image header. The first two octets of the image header contain the length of the image header. Note that unlike other multi-byte numerical values in this document, due to an historical accident this value is encoded as a little-endian number. The image header length is followed by a single octet for the image header version. The only currently defined version of the image header is 1, which is a 16 octet image header. The first three octets of a version 1 image header are thus - 0x10 0x00 0x01. - + 0x10 0x00 0x01. Also note that this is the same encoding used for + signature subpackets The fourth octet of a version 1 image header designates the encoding format of the image. The only currently defined encoding format is the value 1 to indicate JPEG. Image format types 100 through 110 are reserved for private or experimental use. The rest of the version 1 image header is made up of 12 reserved octets, all of which MUST be set to 0. The rest of the image subpacket contains the image itself. As the only currently defined image type is JPEG, the image is encoded in the JPEG File Interchange Format (JFIF), a standard file format for @@ -2256,40 +2270,39 @@ respectively. 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. + plaintext in a Modification Detection Code packet. The input to the + hash function includes the prefix data described above; it includes + all of the plaintext, and then also includes two octets of values + 0xD3, 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 + including the prefix data as well as 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.14. Modification Detection Code Packet (Tag 19) @@ -2706,21 +2721,21 @@ the algorithms. 9.1. Public Key Algorithms ID Algorithm -- --------- 1 - RSA (Encrypt or Sign) 2 - RSA Encrypt-Only 3 - RSA Sign-Only 16 - Elgamal (Encrypt-Only), see [ELGAMAL] - 17 - DSA (Digital Signature Standard) [SCHNEIER] + 17 - DSA (Digital Signature Algorithm) [SCHNEIER] 18 - Reserved for Elliptic Curve 19 - Reserved for ECDSA 20 - Elgamal (Encrypt or Sign) 21 - Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) 100 to 110 - Private/Experimental algorithm. Implementations MUST implement DSA for signatures, and Elgamal for encryption. Implementations SHOULD implement RSA keys. Implementations MAY implement any other algorithm. @@ -3370,22 +3385,22 @@ vexing than large differences. Thus, this is a non-comprehensive list of potential problems and gotchas for a developer who is trying to be backward-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 S2K symmetric algorithm. This is a bug in its + * PGP 5.0 rejects an encrypted session key if the key size differs + from 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 @@ -3572,21 +3588,21 @@ [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: protocols, algorithms, and source code in C", 1996. [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. Hall, and N. Ferguson, "The Twofish Encryption Algorithm", John Wiley & Sons, 1999. 17. Full Copyright Statement - Copyright 2002 by The Internet Society. All Rights Reserved. + Copyright 2003 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 the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of