draft-ietf-openpgp-rfc2440bis-09.txt   draft-ietf-openpgp-rfc2440bis-10.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT PGP Corporation Category: INTERNET-DRAFT PGP Corporation
draft-ietf-openpgp-rfc2440bis-09.txt draft-ietf-openpgp-rfc2440bis-10.txt
Expires Apr 2004 Lutz Donnerhacke Expires Sep 2004 Lutz Donnerhacke
October 2003 IN-Root-CA Individual Network e.V. March 2004
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-09.txt draft-ietf-openpgp-rfc2440bis-10.txt
Copyright 2003 by The Internet Society. All Rights Reserved. Copyright 2004 by The Internet Society. All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 3, line 51 skipping to change at page 3, line 51
4.2.2.3. Five-Octet Lengths 15 4.2.2.3. Five-Octet Lengths 15
4.2.2.4. Partial Body Lengths 15 4.2.2.4. Partial Body Lengths 15
4.2.3. Packet Length Examples 16 4.2.3. Packet Length Examples 16
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 17 5. Packet Types 17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17
5.2. Signature Packet (Tag 2) 18 5.2. Signature Packet (Tag 2) 18
5.2.1. Signature Types 18 5.2.1. Signature Types 18
5.2.2. Version 3 Signature Packet Format 20 5.2.2. Version 3 Signature Packet Format 20
5.2.3. Version 4 Signature Packet Format 23 5.2.3. Version 4 Signature Packet Format 23
5.2.3.1. Signature Subpacket Specification 23 5.2.3.1. Signature Subpacket Specification 24
5.2.3.2. Signature Subpacket Types 25 5.2.3.2. Signature Subpacket Types 25
5.2.3.3. Notes on Self-Signatures 25 5.2.3.3. Notes on Self-Signatures 25
5.2.3.4. Signature creation time 26 5.2.3.4. Signature creation time 26
5.2.3.5. Issuer 26 5.2.3.5. Issuer 27
5.2.3.6. Key expiration time 27 5.2.3.6. Key expiration time 27
5.2.3.7. Preferred symmetric algorithms 27 5.2.3.7. Preferred symmetric algorithms 27
5.2.3.8. Preferred hash algorithms 27 5.2.3.8. Preferred hash algorithms 27
5.2.3.9. Preferred compression algorithms 27 5.2.3.9. Preferred compression algorithms 27
5.2.3.10.Signature expiration time 27 5.2.3.10.Signature expiration time 27
5.2.3.11.Exportable Certification 28 5.2.3.11.Exportable Certification 28
5.2.3.12.Revocable 28 5.2.3.12.Revocable 28
5.2.3.13.Trust signature 28 5.2.3.13.Trust signature 28
5.2.3.14.Regular expression 29 5.2.3.14.Regular expression 29
5.2.3.15.Revocation key 29 5.2.3.15.Revocation key 29
5.2.3.16.Notation Data 29 5.2.3.16.Notation Data 29
5.2.3.17.Key server preferences 30 5.2.3.17.Key server preferences 30
5.2.3.18.Preferred key server 30 5.2.3.18.Preferred key server 30
5.2.3.19.Primary User ID 31 5.2.3.19.Primary User ID 31
5.2.3.20.Policy URL 31 5.2.3.20.Policy URL 31
5.2.3.21.Key Flags 31 5.2.3.21.Key Flags 31
5.2.3.22.Signer's User ID 32 5.2.3.22.Signer's User ID 32
5.2.3.23.Reason for Revocation 32 5.2.3.23.Reason for Revocation 32
5.2.3.24.Features 33 5.2.3.24.Features 33
5.2.3.25.Signature Target 34 5.2.3.25.Signature Target 34
5.2.3.26.Embedded Signature 34
5.2.4. Computing Signatures 34 5.2.4. Computing Signatures 34
5.2.4.1. Subpacket Hints 35 5.2.4.1. Subpacket Hints 35
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 35 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 36
5.4. One-Pass Signature Packets (Tag 4) 36 5.4. One-Pass Signature Packets (Tag 4) 37
5.5. Key Material Packet 37 5.5. Key Material Packet 37
5.5.1. Key Packet Variants 37 5.5.1. Key Packet Variants 37
5.5.1.1. Public Key Packet (Tag 6) 37 5.5.1.1. Public Key Packet (Tag 6) 37
5.5.1.2. Public Subkey Packet (Tag 14) 37 5.5.1.2. Public Subkey Packet (Tag 14) 38
5.5.1.3. Secret Key Packet (Tag 5) 38 5.5.1.3. Secret Key Packet (Tag 5) 38
5.5.1.4. Secret Subkey Packet (Tag 7) 38 5.5.1.4. Secret Subkey Packet (Tag 7) 38
5.5.2. Public Key Packet Formats 38 5.5.2. Public Key Packet Formats 38
5.5.3. Secret Key Packet Formats 39 5.5.3. Secret Key Packet Formats 40
5.6. Compressed Data Packet (Tag 8) 41 5.6. Compressed Data Packet (Tag 8) 41
5.7. Symmetrically Encrypted Data Packet (Tag 9) 41 5.7. Symmetrically Encrypted Data Packet (Tag 9) 42
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 42 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 43
5.9. Literal Data Packet (Tag 11) 43 5.9. Literal Data Packet (Tag 11) 43
5.10. Trust Packet (Tag 12) 43 5.10. Trust Packet (Tag 12) 44
5.11. User ID Packet (Tag 13) 44 5.11. User ID Packet (Tag 13) 44
5.12. User Attribute Packet (Tag 17) 44 5.12. User Attribute Packet (Tag 17) 44
5.12.1. The Image Attribute Subpacket 44 5.12.1. The Image Attribute Subpacket 45
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45
5.14. Modification Detection Code Packet (Tag 19) 47 5.14. Modification Detection Code Packet (Tag 19) 47
6. Radix-64 Conversions 47 6. Radix-64 Conversions 48
6.1. An Implementation of the CRC-24 in "C" 48 6.1. An Implementation of the CRC-24 in "C" 48
6.2. Forming ASCII Armor 48 6.2. Forming ASCII Armor 49
6.3. Encoding Binary in Radix-64 51 6.3. Encoding Binary in Radix-64 51
6.4. Decoding Radix-64 52 6.4. Decoding Radix-64 52
6.5. Examples of Radix-64 52 6.5. Examples of Radix-64 53
6.6. Example of an ASCII Armored Message 53 6.6. Example of an ASCII Armored Message 53
7. Cleartext signature framework 53 7. Cleartext signature framework 53
7.1. Dash-Escaped Text 54 7.1. Dash-Escaped Text 54
8. Regular Expressions 54 8. Regular Expressions 55
9. Constants 55 9. Constants 55
9.1. Public Key Algorithms 55 9.1. Public Key Algorithms 55
9.2. Symmetric Key Algorithms 55 9.2. Symmetric Key Algorithms 56
9.3. Compression Algorithms 56 9.3. Compression Algorithms 56
9.4. Hash Algorithms 56 9.4. Hash Algorithms 57
10. Packet Composition 56 10. Packet Composition 57
10.1. Transferable Public Keys 57 10.1. Transferable Public Keys 57
10.2. OpenPGP Messages 58 10.2. OpenPGP Messages 58
10.3. Detached Signatures 59 10.3. Detached Signatures 59
11. Enhanced Key Formats 59 11. Enhanced Key Formats 59
11.1. Key Structures 59 11.1. Key Structures 59
11.2. Key IDs and Fingerprints 60 11.2. Key IDs and Fingerprints 60
12. Notes on Algorithms 61 12. Notes on Algorithms 61
12.1. Symmetric Algorithm Preferences 61 12.1. Symmetric Algorithm Preferences 61
12.2. Other Algorithm Preferences 62 12.2. Other Algorithm Preferences 62
12.2.1. Compression Preferences 62 12.2.1. Compression Preferences 62
12.2.2. Hash Algorithm Preferences 62 12.2.2. Hash Algorithm Preferences 63
12.3. Plaintext 63 12.3. Plaintext 63
12.4. RSA 63 12.4. RSA 63
12.5. Elgamal 63 12.5. Elgamal 64
12.6. DSA 64 12.6. DSA 64
12.7. Reserved Algorithm Numbers 64 12.7. Reserved Algorithm Numbers 65
12.8. OpenPGP CFB mode 64 12.8. OpenPGP CFB mode 65
13. Security Considerations 66 13. Security Considerations 66
14. Implementation Nits 68 14. Implementation Nits 68
15. Authors and Working Group Chair 69 15. Authors and Working Group Chair 69
16. References (Normative) 70 16. References (Normative) 70
17. References (Non-Normative) 71 17. References (Non-Normative) 72
18. Full Copyright Statement 72 18. Full Copyright Statement 72
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 RFC2440, "OpenPGP and key management functions. It is a revision of RFC2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." Exchange Formats."
skipping to change at page 15, line 53 skipping to change at page 15, line 53
A Partial Body Length header is one octet long and encodes the 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, 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 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 its one octet value that is greater than or equal to 224, and less
than 255. The partial body length is equal to: than 255. The partial body length is equal to:
partialBodyLen = 1 << (1st_octet & 0x1f); partialBodyLen = 1 << (1st_octet & 0x1f);
Each Partial Body Length header is followed by a portion of the Each Partial Body Length header is followed by a portion of the
packet body data. The Partial Body Length header specifies this packet body data. The Partial Body Length header specifies this
portion's length. Another length header (of one of the three types portion's length. Another length header (one octet, two-octet,
-- one octet, two-octet, or partial) follows that portion. The last five-octet, or partial) follows that portion. The last length header
length header in the packet MUST NOT be a partial Body Length in the packet MUST NOT be a partial Body Length header. Partial
header. Partial Body Length headers may only be used for the Body Length headers may only be used for the non-final parts of the
non-final parts of the packet. packet.
It might also be encoded in the following octet stream: 0xEF, first 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 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 octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last
1693 octets of data. This is just one possible encoding, and many 1693 octets of data. This is just one possible encoding, and many
variations are possible on the size of the Partial Body Length variations are possible on the size of the Partial Body Length
headers, as long as a regular Body Length header encodes the last headers, as long as a regular Body Length header encodes the last
portion of the data. portion of the data.
Note also that the last Body Length header can be a zero-length Note also that the last Body Length header can be a zero-length
skipping to change at page 19, line 46 skipping to change at page 19, line 46
Please note that the vagueness of these certification claims is Please note that the vagueness of these certification claims is
not a flaw, but a feature of the system. Because PGP places not a flaw, but a feature of the system. Because PGP places
final authority for validity upon the receiver of a final authority for validity upon the receiver of a
certification, it may be that one authority's casual certification, it may be that one authority's casual
certification might be more rigorous than some other authority's certification might be more rigorous than some other authority's
positive certification. These classifications allow a positive certification. These classifications allow a
certification authority to issue fine-grained claims. certification authority to issue fine-grained claims.
0x18: Subkey Binding Signature 0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key This signature is a statement by the top-level signing key that
indicates that it owns the subkey. This signature is calculated indicates that it owns the subkey. This signature is calculated
directly on the subkey itself, not on any User ID or other directly on the subkey itself, not on any User ID or other
packets. packets. A signature that binds a signing subkey also has an
embedded signature subpacket in this binding signature which
contains a 0x19 signature made by the signing subkey on the
primary key.
0x19 Primary Key Binding Signature
This signature is a statement by a signing subkey, indicating
that it is owned by the primary key. This signature is
calculated directly on the primary key itself, and not on any
User ID or other packets.
0x1F: Signature directly on a key 0x1F: Signature directly on a key
This signature is calculated directly on a key. It binds the This signature is calculated directly on a key. It binds the
information in the signature subpackets to the key, and is information in the signature subpackets to the key, and is
appropriate to be used for subpackets that provide information appropriate to be used for subpackets that provide information
about the key, such as the revocation key subpacket. It is also about the key, such as the revocation key subpacket. It is also
appropriate for statements that non-self certifiers want to make appropriate for statements that non-self certifiers want to make
about the key itself, rather than the binding between a key and about the key itself, rather than the binding between a key and
a name. a name.
skipping to change at page 25, line 4 skipping to change at page 25, line 11
22 = preferred compression algorithms 22 = preferred compression algorithms
23 = key server preferences 23 = key server preferences
24 = preferred key server 24 = preferred key server
25 = primary User ID 25 = primary User ID
26 = policy URL 26 = policy URL
27 = key flags 27 = key flags
28 = signer's User ID 28 = signer's User ID
29 = reason for revocation 29 = reason for revocation
30 = features 30 = features
31 = signature target 31 = signature target
32 = embedded signature
100 to 110 = internal or user-defined 100 to 110 = internal or user-defined
An implementation SHOULD ignore any subpacket of a type that it does An implementation SHOULD ignore any subpacket of a type that it does
not recognize. not recognize.
Bit 7 of the subpacket type is the "critical" bit. If set, it 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 denotes that the subpacket is one that is critical for the evaluator
of the signature to recognize. If a subpacket is encountered that of the signature to recognize. If a subpacket is encountered that
is marked critical but is unknown to the evaluating software, the is marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error. evaluator SHOULD consider the signature to be in error.
skipping to change at page 34, line 26 skipping to change at page 34, line 31
signature refers to. For revocation signatures, this subpacket signature refers to. For revocation signatures, this subpacket
provides explicit designation of which signature is being revoked. provides explicit designation of which signature is being revoked.
For a third-party or timestamp signature, this designates what For a third-party or timestamp signature, this designates what
signature is signed. All arguments are an identifier of that target signature is signed. All arguments are an identifier of that target
signature. signature.
The N octets of hash data MUST be the size of the hash of the 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 signature. For example, a target signature with a SHA-1 hash MUST
have 20 octets of hash data. have 20 octets of hash data.
5.2.3.26. Embedded Signature
(1 signature packet body)
This subpacket contains a complete signature packet body as
specified in section 5.2 above. It is useful when one signature
needs to refer to, or be incorporated in, another signature.
5.2.4. Computing Signatures 5.2.4. Computing Signatures
All signatures are formed by producing a hash over the signature All signatures are formed by producing a hash over the signature
data, and then using the resulting hash in the signature algorithm. data, and then using the resulting hash in the signature algorithm.
The signature data is simple to compute for document signatures The signature data is simple to compute for document signatures
(types 0x00 and 0x01), for which the document itself is the data. (types 0x00 and 0x01), for which the document itself is the data.
For standalone signatures, this is a null string. For standalone signatures, this is a null string.
When a signature is made over a key, the hash data starts with the When a signature is made over a key, the hash data starts with the
octet 0x99, followed by a two-octet length of the key, and then body 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 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) a key packet with two-octet length.) A subkey binding signature
then hashes the subkey, using the same format as the main key (also (type 0x18) or primary key binding signature (0x19) then hashes the
using 0x99 as the first octet). Key revocation signatures (types subkey using the same format as the main key (also using 0x99 as the
0x20 and 0x28) hash only the key being revoked. first octet). Key revocation signatures (types 0x20 and 0x28) hash
only the key being revoked.
When a signature is made over a signature, the hash data starts with When a signature is made over a signature packet, the hash data
the octet 0x88, followed by the four-octet length of the signature, starts with the octet 0x88, followed by the four-octet length of the
and then the body of the signature packet. (Note that this is an signature, and then the body of the signature packet. The unhashed
old-style packet header for a signature packet with the subpacket data of the signature packet being hashed is not included
length-of-length set to zero). in the hash and the unhashed subpacket data length value is set to
zero. (Note that this is an old-style packet header for a signature
packet with the length-of-length set to zero).
A certification signature (type 0x10 through 0x13) hashes the User A certification signature (type 0x10 through 0x13) hashes the User
ID being bound to the key into the hash context after the above ID being bound to the key into the hash context after the above
data. A V3 certification hashes the contents of the User ID or data. A V3 certification hashes the contents of the User ID or
attribute packet packet, without any header. A V4 certification attribute packet packet, without any header. A V4 certification
hashes the constant 0xb4 for User ID certifications or the constant hashes the constant 0xb4 for User ID certifications or the constant
0xd1 for User Attribute certifications, followed by a four-octet 0xd1 for User Attribute certifications, followed by a four-octet
number giving the length of the User ID or User Attribute data, and number giving the length of the User ID or User Attribute data, and
then the User ID or User Attribute data. then the User ID or User Attribute data.
skipping to change at page 35, line 22 skipping to change at page 35, line 38
signature version, the signature type, the public key algorithm, the signature version, the signature type, the public key algorithm, the
hash algorithm, the hashed subpacket length, and the hashed hash algorithm, the hashed subpacket length, and the hashed
subpacket body. subpacket body.
V4 signatures also hash in a final trailer of six octets: the V4 signatures also hash in a final trailer of six octets: the
version of the signature packet, i.e. 0x04; 0xFF; a four-octet, 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 big-endian number that is the length of the hashed data from the
signature packet (note that this number does not include these final signature packet (note that this number does not include these final
six octets. six octets.
After all this has been hashed, the resulting hash field is used in After all this has been hashed in a single hash context the
the signature algorithm, and placed at the end of the signature resulting hash field is used in the signature algorithm, and placed
packet. at the end of the signature packet.
5.2.4.1. Subpacket Hints 5.2.4.1. Subpacket Hints
It is certainly possible for a signature to contain conflicting It is certainly possible for a signature to contain conflicting
information in subpackets. For example, a signature may contain information in subpackets. For example, a signature may contain
multiple copies of a preference or multiple expiration times. In multiple copies of a preference or multiple expiration times. In
most cases, an implementation SHOULD use the last subpacket in the most cases, an implementation SHOULD use the last subpacket in the
signature, but MAY use any conflict resolution scheme that makes signature, but MAY use any conflict resolution scheme that makes
more sense. Please note that we are intentionally leaving conflict more sense. Please note that we are intentionally leaving conflict
resolution to the implementer; most conflicts are simply syntax resolution to the implementer; most conflicts are simply syntax
skipping to change at page 39, line 52 skipping to change at page 40, line 16
- MPI of Elgamal group generator g; - MPI of Elgamal group generator g;
- MPI of Elgamal public key value y (= g**x mod p where x is - MPI of Elgamal public key value y (= g**x mod p where x is
secret). secret).
5.5.3. Secret Key Packet Formats 5.5.3. Secret Key Packet Formats
The Secret Key and Secret Subkey packets contain all the data of the The Secret Key and Secret Subkey packets contain all the data of the
Public Key and Public Subkey packets, with additional Public Key and Public Subkey packets, with additional
algorithm-specific secret key data appended, in encrypted form. algorithm-specific secret key data appended, usually in encrypted
form.
The packet contains: The packet contains:
- A Public Key or Public Subkey packet, as described above - A Public Key or Public Subkey packet, as described above
- One octet indicating string-to-key usage conventions. 0 - One octet indicating string-to-key usage conventions. Zero
indicates that the secret key data is not encrypted. 255 or 254 indicates that the secret key data is not encrypted. 255 or 254
indicates that a string-to-key specifier is being given. Any indicates that a string-to-key specifier is being given. Any
other value is a symmetric-key encryption algorithm identifier. other value is a symmetric-key encryption algorithm identifier.
- [Optional] If string-to-key usage octet was 255 or 254, a - [Optional] If string-to-key usage octet was 255 or 254, a
one-octet symmetric encryption algorithm. one-octet symmetric encryption algorithm.
- [Optional] If string-to-key usage octet was 255 or 254, a - [Optional] If string-to-key usage octet was 255 or 254, a
string-to-key specifier. The length of the string-to-key string-to-key specifier. The length of the string-to-key
specifier is implied by its type, as described above. specifier is implied by its type, as described above.
- [Optional] If secret data is encrypted, Initial Vector (IV) of - [Optional] If secret data is encrypted (string-to-key usage
the same length as the cipher's block size. octet not zero), Initial Vector (IV) of the same length as the
cipher's block size.
- Encrypted multi-precision integers comprising the secret key - Plain or encrypted multi-precision integers comprising the
data. These algorithm-specific fields are as described below. secret key data. These algorithm-specific fields are as
described below.
- If the string-to-key usage octet was 255, then a two-octet - If the string-to-key usage octet is zero or 255, then a
checksum of the plaintext of the algorithm-specific portion (sum two-octet checksum of the plaintext of the algorithm-specific
of all octets, mod 65536). If the string-to-key usage octet was portion (sum of all octets, mod 65536). If the string-to-key
254, then a 20-octet SHA-1 hash of the plaintext of the usage octet was 254, then a 20-octet SHA-1 hash of the plaintext
algorithm-specific portion. This checksum or hash is encrypted of the algorithm-specific portion. This checksum or hash is
together with the algorithm-specific fields. encrypted together with the algorithm-specific fields (if
string-to-key usage octet is not zero). Note that for all other
values, a two-octet checksum is required.
Algorithm Specific Fields for RSA secret keys: Algorithm Specific Fields for RSA secret keys:
- multiprecision integer (MPI) of RSA secret exponent d. - multiprecision integer (MPI) of RSA secret exponent d.
- MPI of RSA secret prime value p. - MPI of RSA secret prime value p.
- MPI of RSA secret prime value q (p < q). - MPI of RSA secret prime value q (p < q).
- MPI of u, the multiplicative inverse of p, mod q. - MPI of u, the multiplicative inverse of p, mod q.
skipping to change at page 41, line 17 skipping to change at page 41, line 38
packet. A different mode is used with V3 keys (which are only RSA) packet. A different mode is used with V3 keys (which are only RSA)
than with other key formats. With V3 keys, the MPI bit count prefix than with other key formats. With V3 keys, the MPI bit count prefix
(i.e., the first two octets) is not encrypted. Only the MPI (i.e., the first two octets) is not encrypted. Only the MPI
non-prefix data is encrypted. Furthermore, the CFB state is non-prefix data is encrypted. Furthermore, the CFB state is
resynchronized at the beginning of each new MPI value, so that the resynchronized at the beginning of each new MPI value, so that the
CFB block boundary is aligned with the start of the MPI data. CFB block boundary is aligned with the start of the MPI data.
With V4 keys, a simpler method is used. All secret MPI values are With V4 keys, a simpler method is used. All secret MPI values are
encrypted in CFB mode, including the MPI bitcount prefix. encrypted in CFB mode, including the MPI bitcount prefix.
The 16-bit checksum that follows the algorithm-specific portion is The two-octet checksum that follows the algorithm-specific portion
the algebraic sum, mod 65536, of the plaintext of all the is the algebraic sum, mod 65536, of the plaintext of all the
algorithm-specific octets (including MPI prefix and data). With V3 algorithm-specific octets (including MPI prefix and data). With V3
keys, the checksum is stored in the clear. With V4 keys, the keys, the checksum is stored in the clear. With V4 keys, the
checksum is encrypted like the algorithm-specific data. This value checksum is encrypted like the algorithm-specific data. This value
is used to check that the passphrase was correct. However, this is used to check that the passphrase was correct. However, this
checksum is deprecated; an implementation SHOULD NOT use it, but checksum is deprecated; an implementation SHOULD NOT use it, but
should rather use the SHA-1 hash denoted with a usage octet of 254. should rather use the SHA-1 hash denoted with a usage octet of 254.
The reason for this is that there are some attacks on the private The reason for this is that there are some attacks on the private
key that can undetectably modify the secret key. Using a SHA-1 hash key that can undetectably modify the secret key. Using a SHA-1 hash
prevents this. prevents this.
skipping to change at page 44, line 56 skipping to change at page 45, line 23
not recognize. Subpacket types 100 through 110 are reserved for not recognize. Subpacket types 100 through 110 are reserved for
private or experimental use. private or experimental use.
5.12.1. The Image Attribute Subpacket 5.12.1. The Image Attribute Subpacket
The image attribute subpacket is used to encode an image, presumably The image attribute subpacket is used to encode an image, presumably
(but not required to be) that of the key owner. (but not required to be) that of the key owner.
The image attribute subpacket begins with an image header. The The image attribute subpacket begins with an image header. The
first two octets of the image header contain the length of the image first two octets of the image header contain the length of the image
header. Note that unlike other multi-byte numerical values in this header. Note that unlike other multi-octet numerical values in this
document, due to an historical accident this value is encoded as a document, due to an historical accident this value is encoded as a
little-endian number. The image header length is followed by a little-endian number. The image header length is followed by a
single octet for the image header version. The only currently single octet for the image header version. The only currently
defined version of the image header is 1, which is a 16 octet image 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 header. The first three octets of a version 1 image header are thus
0x10 0x00 0x01. 0x10 0x00 0x01.
The fourth octet of a version 1 image header designates the encoding The fourth octet of a version 1 image header designates the encoding
format of the image. The only currently defined encoding format is format of the image. The only currently defined encoding format is
the value 1 to indicate JPEG. Image format types 100 through 110 the value 1 to indicate JPEG. Image format types 100 through 110
skipping to change at page 47, line 35 skipping to change at page 47, line 55
packet in the plaintext data which is encrypted in the Symmetrically packet in the plaintext data which is encrypted in the Symmetrically
Encrypted Integrity Protected Data packet, and MUST appear in no Encrypted Integrity Protected Data packet, and MUST appear in no
other place. other place.
A Modification Detection Code packet MUST have a length of 20 A Modification Detection Code packet MUST have a length of 20
octets. octets.
The body of this packet consists of: The body of this packet consists of:
- A 20-octet SHA-1 hash of the preceding plaintext data of the - A 20-octet SHA-1 hash of the preceding plaintext data of the
Symmetrically Encrypted Integrity Protected Data packet, not Symmetrically Encrypted Integrity Protected Data packet,
including prefix data but including the tag and length byte of including prefix data, the tag octet, and length octet of the
the Modification Detection Code packet. Modification Detection Code packet.
Note that the Modification Detection Code packet MUST always use a Note that the Modification Detection Code packet MUST always use a
new-format encoding of the packet tag, and a one-octet encoding of new-format encoding of the packet tag, and a one-octet encoding of
the packet length. The reason for this is that the hashing rules for the packet length. The reason for this is that the hashing rules for
modification detection include a one-octet tag and one-octet length modification detection include a one-octet tag and one-octet length
in the data hash. While this is a bit restrictive, it reduces in the data hash. While this is a bit restrictive, it reduces
complexity. complexity.
6. Radix-64 Conversions 6. Radix-64 Conversions
skipping to change at page 54, line 17 skipping to change at page 54, line 40
IDs. IDs.
7.1. Dash-Escaped Text 7.1. Dash-Escaped Text
The cleartext content of the message must also be dash-escaped. The cleartext content of the message must also be dash-escaped.
Dash escaped cleartext is the ordinary cleartext where every line Dash escaped cleartext is the ordinary cleartext where every line
starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
(0x2D) and space ' ' (0x20). This prevents the parser from (0x2D) and space ' ' (0x20). This prevents the parser from
recognizing armor headers of the cleartext itself. An implementation recognizing armor headers of the cleartext itself. An implementation
MAY dash escape any line, SHOULD dash escape lines commencing "From MAY dash escape any line, SHOULD dash escape lines commencing "From"
" (note the space), and MUST dash escape any line commencing in a followed by a space, and MUST dash escape any line commencing in a
dash. The message digest is computed using the cleartext itself, not dash. The message digest is computed using the cleartext itself, not
the dash escaped form. the dash escaped form.
As with binary signatures on text documents, a cleartext signature As with binary signatures on text documents, a cleartext signature
is calculated on the text using canonical <CR><LF> line endings. is calculated on the text using canonical <CR><LF> line endings.
The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text. considered part of the signed text.
When reversing dash-escaping, an implementation MUST strip the When reversing dash-escaping, an implementation MUST strip the
skipping to change at page 56, line 31 skipping to change at page 56, line 54
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Uncompressed 0 - Uncompressed
1 - ZIP (RFC1951) 1 - ZIP (RFC1951)
2 - ZLIB (RFC1950) 2 - ZLIB (RFC1950)
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 ZLIB. SHOULD implement ZIP. Implementations MAY implement any other
algorithm.
9.4. Hash Algorithms 9.4. Hash Algorithms
ID Algorithm Text Name ID Algorithm Text Name
-- --------- ---- ---- -- --------- ---- ----
1 - MD5 "MD5" 1 - MD5 "MD5"
2 - SHA-1 "SHA1" 2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160" 3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved 4 - Reserved
5 - Reserved 5 - Reserved
skipping to change at page 58, line 14 skipping to change at page 58, line 39
After the User ID or Attribute packets there may be one or more After the User ID or Attribute packets there may be one or more
Subkey packets. In general, subkeys are provided in cases where the Subkey packets. In general, subkeys are provided in cases where the
top-level public key is a signature-only key. However, any V4 key top-level public key is a signature-only key. However, any V4 key
may have subkeys, and the subkeys may be encryption-only keys, may have subkeys, and the subkeys may be encryption-only keys,
signature-only keys, or general-purpose keys. V3 keys MUST NOT have signature-only keys, or general-purpose keys. V3 keys MUST NOT have
subkeys. subkeys.
Each Subkey packet must be followed by one Signature packet, which Each Subkey packet must be followed by one Signature packet, which
should be a subkey binding signature issued by the top level key. should be a subkey binding signature issued by the top level key.
For subkeys that can issue signatures, the subkey binding signature
must contain an embedded signature subpacket with a primary key
binding signature (0x19) issued by the subkey on the top level key.
Subkey and Key packets may each be followed by a revocation Subkey and Key packets may each be followed by a revocation
Signature packet to indicate that the key is revoked. Revocation Signature packet to indicate that the key is revoked. Revocation
signatures are only accepted if they are issued by the key itself, signatures are only accepted if they are issued by the key itself,
or by a key that is authorized to issue revocations via a revocation or by a key that is authorized to issue revocations via a revocation
key subpacket in a self-signature by the top level key. key subpacket in a self-signature by the top level key.
Transferable public key packet sequences may be concatenated to Transferable public key packet sequences may be concatenated to
allow transferring multiple public keys in one operation. allow transferring multiple public keys in one operation.
skipping to change at page 61, line 11 skipping to change at page 61, line 40
two different keys with the same key ID. Note that there is a much two different keys with the same key ID. Note that there is a much
smaller, but still non-zero probability that two different keys have smaller, but still non-zero probability that two different keys have
the same fingerprint. the same fingerprint.
Also note that if V3 and V4 format keys share the same RSA key Also note that if V3 and V4 format keys share the same RSA key
material, they will have different key ids as well as different material, they will have different key ids as well as different
fingerprints. fingerprints.
Finally, the key ID and fingerprint of a subkey are calculated in Finally, the key ID and fingerprint of a subkey are calculated in
the same way as for a primary key, including the 0x99 as the first the same way as for a primary key, including the 0x99 as the first
byte (even though this is not a valid packet ID for a public octet (even though this is not a valid packet ID for a public
subkey). subkey).
12. Notes on Algorithms 12. Notes on Algorithms
12.1. Symmetric Algorithm Preferences 12.1. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature, that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have different preferences. For it is possible that a keyholder may have different preferences. For
example, Alice may have TripleDES only specified for example, Alice may have TripleDES only specified for
skipping to change at page 72, line 11 skipping to change at page 72, line 24
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
international version of PGP", ftp://ftp.iks- international version of PGP", ftp://ftp.iks-
jena.de/mitarb/lutz/crypt/software/pgp/ 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
[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC
1983, August 1996. 1983, 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.
18. Full Copyright Statement 18. Full Copyright Statement
Copyright 2003 by The Internet Society. All Rights Reserved. Copyright 2004 by The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
</x-flowed>
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/