draft-ietf-openpgp-rfc2440bis-19.txt   draft-ietf-openpgp-rfc2440bis-20.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Expires September 2007 Lutz Donnerhacke Expires September 2007 Lutz Donnerhacke
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
PGP Corporation PGP Corporation
David Shaw David Shaw
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-19 draft-ietf-openpgp-rfc2440bis-20
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 48 skipping to change at page 3, line 48
4.2.2. New-Format Packet Lengths 15 4.2.2. New-Format Packet Lengths 15
4.2.2.1. One-Octet Lengths 16 4.2.2.1. One-Octet Lengths 16
4.2.2.2. Two-Octet Lengths 16 4.2.2.2. Two-Octet Lengths 16
4.2.2.3. Five-Octet Lengths 16 4.2.2.3. Five-Octet Lengths 16
4.2.2.4. Partial Body Lengths 16 4.2.2.4. Partial Body Lengths 16
4.2.3. Packet Length Examples 17 4.2.3. Packet Length Examples 17
4.3. Packet Tags 17 4.3. Packet Tags 17
5. Packet Types 18 5. Packet Types 18
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 18 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 18
5.2. Signature Packet (Tag 2) 19 5.2. Signature Packet (Tag 2) 19
5.2.1. Signature Types 19 5.2.1. Signature Types 20
5.2.2. Version 3 Signature Packet Format 22 5.2.2. Version 3 Signature Packet Format 22
5.2.3. Version 4 Signature Packet Format 24 5.2.3. Version 4 Signature Packet Format 24
5.2.3.1. Signature Subpacket Specification 25 5.2.3.1. Signature Subpacket Specification 25
5.2.3.2. Signature Subpacket Types 26 5.2.3.2. Signature Subpacket Types 27
5.2.3.3. Notes on Self-Signatures 27 5.2.3.3. Notes on Self-Signatures 27
5.2.3.4. Signature creation time 28 5.2.3.4. Signature creation time 28
5.2.3.5. Issuer 28 5.2.3.5. Issuer 28
5.2.3.6. Key expiration time 28 5.2.3.6. Key expiration time 28
5.2.3.7. Preferred symmetric algorithms 28 5.2.3.7. Preferred symmetric algorithms 28
5.2.3.8. Preferred hash algorithms 28 5.2.3.8. Preferred hash algorithms 28
5.2.3.9. Preferred compression algorithms 28 5.2.3.9. Preferred compression algorithms 29
5.2.3.10.Signature expiration time 29 5.2.3.10.Signature expiration time 29
5.2.3.11.Exportable Certification 29 5.2.3.11.Exportable Certification 29
5.2.3.12.Revocable 29 5.2.3.12.Revocable 30
5.2.3.13.Trust signature 30 5.2.3.13.Trust signature 30
5.2.3.14.Regular expression 30 5.2.3.14.Regular expression 30
5.2.3.15.Revocation key 30 5.2.3.15.Revocation key 30
5.2.3.16.Notation Data 31 5.2.3.16.Notation Data 31
5.2.3.17.Key server preferences 31 5.2.3.17.Key server preferences 32
5.2.3.18.Preferred key server 32 5.2.3.18.Preferred key server 32
5.2.3.19.Primary User ID 32 5.2.3.19.Primary User ID 32
5.2.3.20.Policy URI 32 5.2.3.20.Policy URI 32
5.2.3.21.Key Flags 32 5.2.3.21.Key Flags 33
5.2.3.22.Signer's User ID 33 5.2.3.22.Signer's User ID 34
5.2.3.23.Reason for Revocation 34 5.2.3.23.Reason for Revocation 34
5.2.3.24.Features 34 5.2.3.24.Features 35
5.2.3.25.Signature Target 35 5.2.3.25.Signature Target 35
5.2.3.26.Embedded Signature 35 5.2.3.26.Embedded Signature 35
5.2.4. Computing Signatures 35 5.2.4. Computing Signatures 36
5.2.4.1. Subpacket Hints 36 5.2.4.1. Subpacket Hints 37
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 37 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 37
5.4. One-Pass Signature Packets (Tag 4) 38 5.4. One-Pass Signature Packets (Tag 4) 38
5.5. Key Material Packet 38 5.5. Key Material Packet 39
5.5.1. Key Packet Variants 39 5.5.1. Key Packet Variants 39
5.5.1.1. Public Key Packet (Tag 6) 39 5.5.1.1. Public Key Packet (Tag 6) 39
5.5.1.2. Public Subkey Packet (Tag 14) 39 5.5.1.2. Public Subkey Packet (Tag 14) 39
5.5.1.3. Secret Key Packet (Tag 5) 39 5.5.1.3. Secret Key Packet (Tag 5) 39
5.5.1.4. Secret Subkey Packet (Tag 7) 39 5.5.1.4. Secret Subkey Packet (Tag 7) 39
5.5.2. Public Key Packet Formats 39 5.5.2. Public Key Packet Formats 39
5.5.3. Secret Key Packet Formats 41 5.5.3. Secret Key Packet Formats 41
5.6. Compressed Data Packet (Tag 8) 43 5.6. Compressed Data Packet (Tag 8) 43
5.7. Symmetrically Encrypted Data Packet (Tag 9) 43 5.7. Symmetrically Encrypted Data Packet (Tag 9) 43
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 44 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 44
5.9. Literal Data Packet (Tag 11) 44 5.9. Literal Data Packet (Tag 11) 44
5.10. Trust Packet (Tag 12) 45 5.10. Trust Packet (Tag 12) 45
5.11. User ID Packet (Tag 13) 45 5.11. User ID Packet (Tag 13) 46
5.12. User Attribute Packet (Tag 17) 46 5.12. User Attribute Packet (Tag 17) 46
5.12.1. The Image Attribute Subpacket 46 5.12.1. The Image Attribute Subpacket 46
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 47 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 47
5.14. Modification Detection Code Packet (Tag 19) 50 5.14. Modification Detection Code Packet (Tag 19) 50
6. Radix-64 Conversions 50 6. Radix-64 Conversions 50
6.1. An Implementation of the CRC-24 in "C" 51 6.1. An Implementation of the CRC-24 in "C" 51
6.2. Forming ASCII Armor 51 6.2. Forming ASCII Armor 51
6.3. Encoding Binary in Radix-64 54 6.3. Encoding Binary in Radix-64 54
6.4. Decoding Radix-64 55 6.4. Decoding Radix-64 55
6.5. Examples of Radix-64 55 6.5. Examples of Radix-64 55
skipping to change at page 5, line 18 skipping to change at page 5, line 18
9.4. Hash Algorithms 59 9.4. Hash Algorithms 59
10. IANA Considerations 60 10. IANA Considerations 60
10.1. New String-to-Key specifier types 60 10.1. New String-to-Key specifier types 60
10.2. New Packets 60 10.2. New Packets 60
10.2.1. User Attribute Types 60 10.2.1. User Attribute Types 60
10.2.1.1.Image Format Subpacket Types 60 10.2.1.1.Image Format Subpacket Types 60
10.2.2. New Signature Subpackets 61 10.2.2. New Signature Subpackets 61
10.2.2.1.Signature Notation Data Subpackets 61 10.2.2.1.Signature Notation Data Subpackets 61
10.2.2.2.Key Server Preference Extensions 61 10.2.2.2.Key Server Preference Extensions 61
10.2.2.3.Key Flags Extensions 61 10.2.2.3.Key Flags Extensions 61
10.2.2.4.Reason For Revocation Extensions 61 10.2.2.4.Reason For Revocation Extensions 62
10.2.2.5.Implementation Features 62 10.2.2.5.Implementation Features 62
10.2.3. New Packet Versions 62 10.2.3. New Packet Versions 62
10.3. New Algorithms 62 10.3. New Algorithms 62
10.3.1. Public Key Algorithms 62 10.3.1. Public Key Algorithms 63
10.3.2. Symmetric Key Algorithms 63 10.3.2. Symmetric Key Algorithms 63
10.3.3. Hash Algorithms 63 10.3.3. Hash Algorithms 63
10.3.4. Compression Algorithms 63 10.3.4. Compression Algorithms 63
10.4. Private or Experimental Parameters 63 10.4. Private or Experimental Parameters 63
10.5. Extension of the MDC System 63 10.5. Extension of the MDC System 64
10.6. Meta-Considerations 64 10.6. Meta-Considerations 64
11. Packet Composition 64 11. Packet Composition 65
11.1. Transferable Public Keys 65 11.1. Transferable Public Keys 65
11.2. Transferable Secret Keys 66 11.2. Transferable Secret Keys 66
11.3. OpenPGP Messages 66 11.3. OpenPGP Messages 66
11.4. Detached Signatures 67 11.4. Detached Signatures 67
12. Enhanced Key Formats 67 12. Enhanced Key Formats 67
12.1. Key Structures 67 12.1. Key Structures 67
12.2. Key IDs and Fingerprints 68 12.2. Key IDs and Fingerprints 68
13. Notes on Algorithms 69 13. Notes on Algorithms 69
13.1. PKCS#1 Encoding In OpenPGP 69 13.1. PKCS#1 Encoding In OpenPGP 69
13.1.1. EME-PKCS1-v1_5-ENCODE 69 13.1.1. EME-PKCS1-v1_5-ENCODE 70
13.1.2. EME-PKCS1-v1_5-DECODE 70 13.1.2. EME-PKCS1-v1_5-DECODE 70
13.1.3. EMSA-PKCS1-v1_5 70 13.1.3. EMSA-PKCS1-v1_5 71
13.2. Symmetric Algorithm Preferences 71 13.2. Symmetric Algorithm Preferences 72
13.3. Other Algorithm Preferences 72 13.3. Other Algorithm Preferences 72
13.3.1. Compression Preferences 72 13.3.1. Compression Preferences 72
13.3.2. Hash Algorithm Preferences 73 13.3.2. Hash Algorithm Preferences 73
13.4. Plaintext 73 13.4. Plaintext 73
13.5. RSA 73 13.5. RSA 73
13.6. DSA 73 13.6. DSA 74
13.7. Elgamal 74 13.7. Elgamal 74
13.8. Reserved Algorithm Numbers 74 13.8. Reserved Algorithm Numbers 74
13.9. OpenPGP CFB mode 74 13.9. OpenPGP CFB mode 75
14. Security Considerations 76 14. Security Considerations 76
15. Implementation Nits 79 15. Implementation Nits 79
16. Authors' Addresses 80 16. Authors' Addresses 80
17. References (Normative) 80 17. References (Normative) 81
18. References (Informative) 82 18. References (Informative) 82
19. Full Copyright Statement 83 19. Full Copyright Statement 83
20. Intellectual Property 84 20. Intellectual Property 84
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC 2440, "OpenPGP and key management functions. It is a revision of RFC 2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
skipping to change at page 11, line 20 skipping to change at page 11, line 20
3.3. Key IDs 3.3. Key IDs
A Key ID is an eight-octet scalar that identifies a key. A Key ID is an eight-octet scalar that identifies a key.
Implementations SHOULD NOT assume that Key IDs are unique. The Implementations SHOULD NOT assume that Key IDs are unique. The
section, "Enhanced Key Formats" below describes how Key IDs are section, "Enhanced Key Formats" below describes how Key IDs are
formed. formed.
3.4. Text 3.4. Text
Unless otherwise specified, the character set for text is the UTF-8 Unless otherwise specified, the character set for text is the UTF-8
[RFC2279] encoding of Unicode [ISO10646]. [RFC3629] encoding of Unicode [ISO10646].
3.5. Time fields 3.5. Time fields
A time field is an unsigned four-octet number containing the number A time field is an unsigned four-octet number containing the number
of seconds elapsed since midnight, 1 January 1970 UTC. of seconds elapsed since midnight, 1 January 1970 UTC.
3.6. Keyrings 3.6. Keyrings
A keyring is a collection of one or more keys in a file or database. A keyring is a collection of one or more keys in a file or database.
Traditionally, a keyring is simply a sequential list of keys, but Traditionally, a keyring is simply a sequential list of keys, but
skipping to change at page 19, line 22 skipping to change at page 19, line 22
- MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
The value "m" in the above formulas is derived from the session key 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 as follows. First the session key is prefixed with a one-octet
algorithm identifier that specifies the symmetric encryption algorithm identifier that specifies the symmetric encryption
algorithm used to encrypt the following Symmetrically Encrypted Data algorithm used to encrypt the following Symmetrically Encrypted Data
Packet. Then a two-octet checksum is appended which is equal to the Packet. Then a two-octet checksum is appended which is equal to the
sum of the preceding session key octets, not including the algorithm sum of the preceding session key octets, not including the algorithm
identifier, modulo 65536. This value is then encoded as described in identifier, modulo 65536. This value is then encoded as described in
PKCS#1 block encoding EME-PKCS1-v1_5 in Section 12.1 to form the "m" PKCS#1 block encoding EME-PKCS1-v1_5 in Section 12.1 of RFC 3447 to
value used in the formulas above. form the "m" value used in the formulas above. See Section 13.1 of
this document for notes on OpenPGP's use of PKCS#1.
Note that when an implementation forms several PKESKs with one Note that when an implementation forms several PKESKs with one
session key, forming a message that can be decrypted by several session key, forming a message that can be decrypted by several
keys, the implementation MUST make a new PKCS#1 encoding for each keys, the implementation MUST make a new PKCS#1 encoding for each
key. key.
An implementation MAY accept or use a Key ID of zero as a "wild An implementation MAY accept or use a Key ID of zero as a "wild
card" or "speculative" Key ID. In this case, the receiving card" or "speculative" Key ID. In this case, the receiving
implementation would try all available private keys, checking for a implementation would try all available private keys, checking for a
valid decrypted session key. This format helps reduce traffic valid decrypted session key. This format helps reduce traffic
skipping to change at page 22, line 52 skipping to change at page 23, line 6
- MPI of DSA value r. - MPI of DSA value r.
- MPI of DSA value s. - MPI of DSA value s.
The signature calculation is based on a hash of the signed data, as The signature calculation is based on a hash of the signed data, as
described above. The details of the calculation are different for described above. The details of the calculation are different for
DSA signatures than for RSA signatures. DSA signatures than for RSA signatures.
With RSA signatures, the hash value is encoded as described in With RSA signatures, the hash value is encoded as described in
PKCS#1 section 9.2.1 encoded using PKCS#1 encoding type PKCS#1 section 9.2.1 of RFC 3447 encoded using PKCS#1 encoding type
EMSA-PKCS1-v1_5 as described in section 12.1. This requires EMSA-PKCS1-v1_5 as described in section 12.1 of RFC 3447. This
inserting the hash value as an octet string into an ASN.1 structure. requires inserting the hash value as an octet string into an ASN.1
The object identifier for the type of hash being used is included in structure. The object identifier for the type of hash being used is
the structure. The hexadecimal representations for the currently included in the structure. The hexadecimal representations for the
defined hash algorithms are: currently defined hash algorithms are:
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
- SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04 - SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04
- SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
skipping to change at page 43, line 33 skipping to change at page 43, line 41
how messages are formed. how messages are formed.
ZIP-compressed packets are compressed with raw RFC 1951 DEFLATE ZIP-compressed packets are compressed with raw RFC 1951 DEFLATE
blocks. Note that PGP V2.6 uses 13 bits of compression. If an blocks. Note that PGP V2.6 uses 13 bits of compression. If an
implementation uses more bits of compression, PGP V2.6 cannot implementation uses more bits of compression, PGP V2.6 cannot
decompress it. decompress it.
ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style ZLIB-compressed packets are compressed with RFC 1950 ZLIB-style
blocks. blocks.
BZip2-compressed packets are compressed using the BZip2 algorithm. BZip2-compressed packets are compressed using the BZip2 [BZ2]
algorithm.
5.7. Symmetrically Encrypted Data Packet (Tag 9) 5.7. Symmetrically Encrypted Data Packet (Tag 9)
The Symmetrically Encrypted Data packet contains data encrypted with The Symmetrically Encrypted Data packet contains data encrypted with
a symmetric-key algorithm. When it has been decrypted, it contains a symmetric-key algorithm. When it has been decrypted, it contains
other packets (usually a literal data packet or compressed data other packets (usually a literal data packet or compressed data
packet, but in theory other Symmetrically Encrypted Data Packets or packet, but in theory other Symmetrically Encrypted Data Packets or
sequences of packets that form whole OpenPGP messages). sequences of packets that form whole OpenPGP messages).
The body of this packet consists of: The body of this packet consists of:
skipping to change at page 55, line 40 skipping to change at page 55, line 51
occurrence of any "=" characters may be taken as evidence that the occurrence of any "=" characters may be taken as evidence that the
end of the data has been reached (without truncation in transit). No end of the data has been reached (without truncation in transit). No
such assurance is possible, however, when the number of octets such assurance is possible, however, when the number of octets
transmitted was a multiple of three and no "=" characters are transmitted was a multiple of three and no "=" characters are
present. present.
6.5. Examples of Radix-64 6.5. Examples of Radix-64
Input data: 0x14fb9c03d97e Input data: 0x14fb9c03d97e
Hex: 1 4 f b 9 c | 0 3 d 9 7 e Hex: 1 4 f b 9 c | 0 3 d 9 7 e
8-bit: 00010100 11111011 10011100 | 00000011 11011001 8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110
11111110 6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110
6-bit: 000101 001111 101110 011100 | 000000 111101 100111
111110
Decimal: 5 15 46 28 0 61 37 62 Decimal: 5 15 46 28 0 61 37 62
Output: F P u c A 9 l + Output: F P u c A 9 l +
Input data: 0x14fb9c03d9 Input data: 0x14fb9c03d9
Hex: 1 4 f b 9 c | 0 3 d 9 Hex: 1 4 f b 9 c | 0 3 d 9
8-bit: 00010100 11111011 10011100 | 00000011 11011001 8-bit: 00010100 11111011 10011100 | 00000011 11011001
pad with 00 pad with 00
6-bit: 000101 001111 101110 011100 | 000000 111101 100100 6-bit: 000101 001111 101110 011100 | 000000 111101 100100
Decimal: 5 15 46 28 0 61 36 Decimal: 5 15 46 28 0 61 36
pad with = pad with =
Output: F P u c A 9 k = Output: F P u c A 9 k =
Input data: 0x14fb9c03 Input data: 0x14fb9c03
Hex: 1 4 f b 9 c | 0 3 Hex: 1 4 f b 9 c | 0 3
skipping to change at page 59, line 34 skipping to change at page 59, line 40
implement AES-128 and CAST5. Implementations that interoperate with implement AES-128 and CAST5. Implementations that interoperate with
PGP 2.6 or earlier need to support IDEA, as that is the only PGP 2.6 or earlier need to support IDEA, as that is the only
symmetric cipher those versions use. Implementations MAY implement symmetric cipher those versions use. Implementations MAY implement
any other algorithm. any other algorithm.
9.3. Compression Algorithms 9.3. Compression Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Uncompressed 0 - Uncompressed
1 - ZIP (RFC 1951) 1 - ZIP [RFC 1951]
2 - ZLIB (RFC 1950) 2 - ZLIB [RFC 1950]
3 - BZip2 [BZ2] 3 - BZip2 [BZ2]
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement uncompressed data. Implementations Implementations MUST implement uncompressed data. Implementations
SHOULD implement ZIP. Implementations MAY implement any other SHOULD implement ZIP. Implementations MAY implement any other
algorithm. algorithm.
9.4. Hash Algorithms 9.4. Hash Algorithms
ID Algorithm Text Name ID Algorithm Text Name
-- --------- ---- ---- -- --------- ---- ----
1 - MD5 "MD5" 1 - MD5 [HAC] "MD5"
2 - SHA-1 [FIPS180] "SHA1" 2 - SHA-1 [FIPS180] "SHA1"
3 - RIPE-MD/160 "RIPEMD160" 3 - RIPE-MD/160 [HAC] "RIPEMD160"
4 - Reserved 4 - Reserved
5 - Reserved 5 - Reserved
6 - Reserved 6 - Reserved
7 - Reserved 7 - Reserved
8 - SHA256 [FIPS180] "SHA256" 8 - SHA256 [FIPS180] "SHA256"
9 - SHA384 [FIPS180] "SHA384" 9 - SHA384 [FIPS180] "SHA384"
10 - SHA512 [FIPS180] "SHA512" 10 - SHA512 [FIPS180] "SHA512"
11 - SHA224 [FIPS180] "SHA224" 11 - SHA224 [FIPS180] "SHA224"
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
skipping to change at page 63, line 33 skipping to change at page 63, line 43
5.2.2 for the OIDs and expanded signature prefixes. Adding a new 5.2.2 for the OIDs and expanded signature prefixes. Adding a new
hash algorithm MUST be done through the IETF CONSENSUS method, as hash algorithm MUST be done through the IETF CONSENSUS method, as
described in [RFC2434]. described in [RFC2434].
10.3.4. Compression Algorithms 10.3.4. Compression Algorithms
OpenPGP specifies a number of compression algorithms. This OpenPGP specifies a number of compression algorithms. This
specification creates a registry of compression algorithm specification creates a registry of compression algorithm
identifiers. The registry includes the algorithm name, and a identifiers. The registry includes the algorithm name, and a
reference to the defining specification. The initial values for this reference to the defining specification. The initial values for this
registry can be found in section 9. Adding a new compression key registry can be found in section 9.3. Adding a new compression key
algorithm MUST be done through the IETF CONSENSUS method, as algorithm MUST be done through the IETF CONSENSUS method, as
described in [RFC2434]. described in [RFC2434].
10.4. Private or Experimental Parameters 10.4. Private or Experimental Parameters
S2K specifiers, Signature subpacket types, user attribute types, S2K specifiers, Signature subpacket types, user attribute types,
image format types, and algorithms described in Section 9 all image format types, and algorithms described in Section 9 all
reserve the range 100 to 110 for private and experimental use. reserve the range 100 to 110 for private and experimental use.
Packet types reserve the range 60 to 63 for private and experimental Packet types reserve the range 60 to 63 for private and experimental
use. These are intentionally managed with the PRIVATE USE method, as use. These are intentionally managed with the PRIVATE USE method, as
skipping to change at page 74, line 50 skipping to change at page 75, line 8
algorithm. These are marked in the Public Algorithms section as algorithm. These are marked in the Public Algorithms section as
"(reserved for)". "(reserved for)".
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
and X9.42 (21) do not have the necessary parameters, parameter and X9.42 (21) do not have the necessary parameters, parameter
order, or semantics defined. order, or semantics defined.
Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
with a public key identifier of 20. These are no longer permitted. with a public key identifier of 20. These are no longer permitted.
An implementation MUST NOT generate such keys. An implementation An implementation MUST NOT generate such keys. An implementation
MUST NOT generate Elgamal signatures. MUST NOT generate Elgamal signatures. See [BLEICHENBACHER].
13.9. OpenPGP CFB mode 13.9. OpenPGP CFB mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback OpenPGP does symmetric encryption using a variant of Cipher Feedback
Mode (CFB mode). This section describes the procedure it uses in Mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Encrypted Data detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret key material is Packets; the mechanism used for encrypting secret key material is
similar, but described in those sections above. similar, but described in those sections above.
In the description below, the value BS is the block size in octets In the description below, the value BS is the block size in octets
skipping to change at page 76, line 26 skipping to change at page 76, line 36
* As with any technology involving cryptography, you should check * As with any technology involving cryptography, you should check
the current literature to determine if any algorithms used here the current literature to determine if any algorithms used here
have been found to be vulnerable to attack. have been found to be vulnerable to attack.
* This specification uses Public Key Cryptography technologies. It * This specification uses Public Key Cryptography technologies. It
is assumed that the private key portion of a public-private key is assumed that the private key portion of a public-private key
pair is controlled and secured by the proper party or parties. pair is controlled and secured by the proper party or parties.
* Certain operations in this specification involve the use of * Certain operations in this specification involve the use of
random numbers. An appropriate entropy source should be used to random numbers. An appropriate entropy source should be used to
generate these numbers. See RFC 1750. generate these numbers. See RFC 4086.
* The MD5 hash algorithm has been found to have weaknesses, with * The MD5 hash algorithm has been found to have weaknesses, with
collisions found in a number of cases. MD5 is deprecated for use collisions found in a number of cases. MD5 is deprecated for use
in OpenPGP. Implementations MUST NOT generate new signatures in OpenPGP. Implementations MUST NOT generate new signatures
using MD5 as a hash function. They MAY continue to consider old using MD5 as a hash function. They MAY continue to consider old
signatures that used MD5 as valid. signatures that used MD5 as valid.
* SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512 * SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512
respectively. In general, there are few reasons to use them respectively. In general, there are few reasons to use them
outside of DSS compatibility. You need a situation where one outside of DSS compatibility. You need a situation where one
skipping to change at page 81, line 53 skipping to change at page 82, line 18
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- [ISO10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture Coded Character Set (UCS) -- Part 1: Architecture
and Basic Multilingual Plane. and Basic Multilingual Plane.
[JFIF] JPEG File Interchange Format (Version 1.02). [JFIF] JPEG File Interchange Format (Version 1.02).
Eric Hamilton, C-Cube Microsystems, Milpitas, CA, Eric Hamilton, C-Cube Microsystems, Milpitas, CA,
September 1, 1992. September 1, 1992.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, October 1993.
[RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with
MIME", RFC 1641, July 1994.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC
1750, December 1994.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3.", RFC 1951, May 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet [RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies.", RFC 2045, November 1996. Message Bodies.", RFC 2045, November 1996.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997. 2144, May 1997.
[RFC2279] Yergeau., F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2279, January 1998.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
August 2001. August 2001.
[RFC3447] B. Kaliski and J. Staddon, "PKCS #1: RSA [RFC3447] B. Kaliski and J. Staddon, "PKCS #1: RSA
Cryptography Specifications Version 2.1", Cryptography Specifications Version 2.1",
RFC 3447, February 2003. RFC 3447, February 2003.
[RFC3629] Yergeau., F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 3629, November 2003.
[RFC4086] Eastlake, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC
4086, June 2005.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996. protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999. Algorithm", John Wiley & Sons, 1999.
18. References (Informative) 18. References (Informative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key," signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is proceedings has an error. A revised version is
available at the time of writing from available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps> /isc/ElGamal.ps>
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
international version of PGP", ftp://ftp.iks-
jena.de/mitarb/lutz/crypt/software/pgp/
[JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier [JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier
"Implementation of Chosen-Ciphertext Attacks "Implementation of Chosen-Ciphertext Attacks
against PGP and GnuPG" against PGP and GnuPG"
http://www.counterpane.com/pgp-attack.html http://www.counterpane.com/pgp-attack.html
[MAURER] Ueli Maurer, "Modelling a Public-Key [MAURER] Ueli Maurer, "Modelling a Public-Key
Infrastructure", Proc. 1996 European Symposium on Infrastructure", Proc. 1996 European Symposium on
Research in Computer Security (ESORICS' 96), Research in Computer Security (ESORICS' 96),
Lecture Notes in Computer Science, Springer-Verlag, Lecture Notes in Computer Science, Springer-Verlag,
vol. 1146, pp. 325-350, Sep 1996. vol. 1146, pp. 325-350, Sep 1996.
[MZ05] Serge Mister, Robert Zuccherato, "An Attack on [MZ05] Serge Mister, Robert Zuccherato, "An Attack on
CFB Mode Encryption As Used By OpenPGP," IACR CFB Mode Encryption As Used By OpenPGP," IACR
http://eprint.iacr.org/2005/033 http://eprint.iacr.org/2005/033
[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC [RFC1423] Balenson, D., "Privacy Enhancement for Internet
1983, August 1996. Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, October 1993.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3.", RFC 1951, May 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Level", BCP 14, RFC 2119, March 1997. Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998. BCP 26, RFC 2434, October 1998.
[SP800-57] NIST Special Publication 800-57, Recommendation on [SP800-57] NIST Special Publication 800-57, Recommendation on
Key Management Key Management
<http://csrc.nist.gov/publications/nistpubs/ <http://csrc.nist.gov/publications/nistpubs/
 End of changes. 37 change blocks. 
70 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/