draft-ietf-openpgp-rfc2440bis-06.txt   draft-ietf-openpgp-rfc2440bis-07.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Category: INTERNET-DRAFT PGP Corporation
draft-ietf-openpgp-rfc2440bis-06.txt draft-ietf-openpgp-rfc2440bis-07.txt
Expires Feb 2003 Lutz Donnerhacke Expires Sep 2003 Lutz Donnerhacke
August 2002 IN-Root-CA Individual Network e.V. March 2003 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format 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 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 27 skipping to change at page 3, line 27
2.4. Conversion to Radix-64 8 2.4. Conversion to Radix-64 8
2.5. Signature-Only Applications 8 2.5. Signature-Only Applications 8
3. Data Element Formats 9 3. Data Element Formats 9
3.1. Scalar numbers 9 3.1. Scalar numbers 9
3.2. Multi-Precision Integers 9 3.2. Multi-Precision Integers 9
3.3. Key IDs 9 3.3. Key IDs 9
3.4. Text 10 3.4. Text 10
3.5. Time fields 10 3.5. Time fields 10
3.6. Keyrings 10 3.6. Keyrings 10
3.7. String-to-key (S2K) specifiers 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.1. Simple S2K 10
3.7.1.2. Salted S2K 11 3.7.1.2. Salted S2K 11
3.7.1.3. Iterated and Salted S2K 11 3.7.1.3. Iterated and Salted S2K 11
3.7.2. String-to-key usage 12 3.7.2. String-to-key usage 12
3.7.2.1. Secret key encryption 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. Packet Syntax 13
4.1. Overview 13 4.1. Overview 13
4.2. Packet Headers 13 4.2. Packet Headers 13
4.2.1. Old-Format Packet Lengths 14 4.2.1. Old-Format Packet Lengths 14
4.2.2. New-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.2. Two-Octet Lengths 15
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 15 4.2.3. Packet Length Examples 16
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 16 5. Packet Types 17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16 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 22 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 26
5.2.3.6. Key expiration time 26 5.2.3.6. Key expiration time 27
5.2.3.7. Preferred symmetric algorithms 26 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 27 5.2.3.11.Exportable Certification 27
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 28 5.2.3.14.Regular expression 29
5.2.3.15.Revocation key 28 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 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.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.Revocation Target 33 5.2.3.25.Signature Target 33
5.2.4. Computing Signatures 33 5.2.4. Computing Signatures 34
5.2.4.1. Subpacket Hints 34 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) 35
5.4. One-Pass Signature Packets (Tag 4) 36 5.4. One-Pass Signature Packets (Tag 4) 36
5.5. Key Material Packet 36 5.5. Key Material Packet 37
5.5.1. Key Packet Variants 36 5.5.1. Key Packet Variants 37
5.5.1.1. Public Key Packet (Tag 6) 36 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) 37
5.5.1.3. Secret Key Packet (Tag 5) 37 5.5.1.3. Secret Key Packet (Tag 5) 37
5.5.1.4. Secret Subkey Packet (Tag 7) 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.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.7. Symmetrically Encrypted Data Packet (Tag 9) 41
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 42 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.10. Trust Packet (Tag 12) 43
5.11. User ID Packet (Tag 13) 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.12.1. The Image Attribute Subpacket 44
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 44 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45
5.14. Modification Detection Code Packet (Tag 19) 46 5.14. Modification Detection Code Packet (Tag 19) 47
6. Radix-64 Conversions 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.2. Forming ASCII Armor 48
6.3. Encoding Binary in Radix-64 50 6.3. Encoding Binary in Radix-64 51
6.4. Decoding Radix-64 51 6.4. Decoding Radix-64 52
6.5. Examples of Radix-64 52 6.5. Examples of Radix-64 52
6.6. Example of an ASCII Armored Message 52 6.6. Example of an ASCII Armored Message 53
7. Cleartext signature framework 52 7. Cleartext signature framework 53
7.1. Dash-Escaped Text 53 7.1. Dash-Escaped Text 54
8. Regular Expressions 54 8. Regular Expressions 54
9. Constants 54 9. Constants 55
9.1. Public Key Algorithms 54 9.1. Public Key Algorithms 55
9.2. Symmetric Key Algorithms 55 9.2. Symmetric Key Algorithms 55
9.3. Compression Algorithms 55 9.3. Compression Algorithms 56
9.4. Hash Algorithms 55 9.4. Hash Algorithms 56
10. Packet Composition 56 10. Packet Composition 56
10.1. Transferable Public Keys 56 10.1. Transferable Public Keys 56
10.2. OpenPGP Messages 57 10.2. OpenPGP Messages 58
10.3. Detached Signatures 58 10.3. Detached Signatures 58
11. Enhanced Key Formats 58 11. Enhanced Key Formats 59
11.1. Key Structures 58 11.1. Key Structures 59
11.2. Key IDs and Fingerprints 59 11.2. Key IDs and Fingerprints 60
12. Notes on Algorithms 60 12. Notes on Algorithms 61
12.1. Symmetric Algorithm Preferences 60 12.1. Symmetric Algorithm Preferences 61
12.2. Other 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.2.2. Hash Algorithm Preferences 62
12.3. Plaintext 62 12.3. Plaintext 62
12.4. RSA 62 12.4. RSA 63
12.5. Elgamal 62 12.5. Elgamal 63
12.6. DSA 63 12.6. DSA 64
12.7. Reserved Algorithm Numbers 63 12.7. Reserved Algorithm Numbers 64
12.8. OpenPGP CFB mode 64 12.8. OpenPGP CFB mode 64
13. Security Considerations 65 13. Security Considerations 65
14. Implementation Nits 67 14. Implementation Nits 67
15. Authors and Working Group Chair 68 15. Authors and Working Group Chair 69
16. References 69 16. References 70
17. Full Copyright Statement 71 17. 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."
1.1. Terms 1.1. Terms
skipping to change at page 6, line 39 skipping to change at page 6, line 39
the PGP 2.6.x design. It is referred to here as PGP 5.x because 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. that software was the first release of the "PGP 3" code base.
* GPG - GNU Privacy Guard, also called GNUpg. GPG is an OpenPGP * GPG - GNU Privacy Guard, also called GNUpg. GPG is an OpenPGP
implementation that avoids all encumbered algorithms. implementation that avoids all encumbered algorithms.
Consequently, early versions of GPG did not include RSA public Consequently, early versions of GPG did not include RSA public
keys. GPG may or may not have (depending on version) support for keys. GPG may or may not have (depending on version) support for
IDEA or other encumbered algorithms. IDEA or other encumbered algorithms.
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of "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 This document uses the terms "MUST", "SHOULD", and "MAY" as defined
in RFC2119, along with the negated forms of those terms. in RFC2119, along with the negated forms of those terms.
2. General functions 2. General functions
OpenPGP provides data integrity services for messages and data files OpenPGP provides data integrity services for messages and data files
by using these core technologies: by using these core technologies:
- digital signatures - digital signatures
skipping to change at page 10, line 31 skipping to change at page 10, line 31
standard to discuss the details of keyrings or other databases. standard to discuss the details of keyrings or other databases.
3.7. String-to-key (S2K) specifiers 3.7. String-to-key (S2K) specifiers
String-to-key (S2K) specifiers are used to convert passphrase String-to-key (S2K) specifiers are used to convert passphrase
strings into symmetric-key encryption/decryption keys. They are strings into symmetric-key encryption/decryption keys. They are
used in two places, currently: to encrypt the secret part of private used in two places, currently: to encrypt the secret part of private
keys in the private keyring, and to convert passphrases to keys in the private keyring, and to convert passphrases to
encryption keys for symmetrically encrypted messages. 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 There are three types of S2K specifiers currently supported, and
follows: 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 3.7.1.1. Simple S2K
This directly hashes the string to produce the key data. See below This directly hashes the string to produce the key data. See below
for how this hashing is done. for how this hashing is done.
Octet 0: 0x00 Octet 0: 0x00
Octet 1: hash algorithm Octet 1: hash algorithm
Simple S2K hashes the passphrase to produce the session key. The 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 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 (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 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 size, the high-order (leftmost) octets of the hash are used as the
key. key.
If the hash size is less than the key size, multiple instances of If the hash size is less than the key size, multiple instances of
the hash context are created -- enough to produce the required key the hash context are created -- enough to produce the required key
data. These instances are preloaded with 0, 1, 2, ... octets of data. These instances are preloaded with 0, 1, 2, ... octets of
skipping to change at page 12, line 40 skipping to change at page 12, line 52
For compatibility, when an S2K specifier is used, the special value For compatibility, when an S2K specifier is used, the special value
255 is stored in the position where the hash algorithm octet would 255 is stored in the position where the hash algorithm octet would
have been in the old data structure. This is then followed have been in the old data structure. This is then followed
immediately by a one-octet algorithm identifier, and then by the S2K immediately by a one-octet algorithm identifier, and then by the S2K
specifier as encoded above. specifier as encoded above.
Therefore, preceding the secret data there will be one of these Therefore, preceding the secret data there will be one of these
possibilities: possibilities:
0: secret data is unencrypted (no pass phrase) 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 Cipher alg: use Simple S2K algorithm using MD5 hash
This last possibility, the cipher algorithm number with an implicit This last possibility, the cipher algorithm number with an implicit
use of MD5 and IDEA, is provided for backward compatibility; it MAY use of MD5 and IDEA, is provided for backward compatibility; it MAY
be understood, but SHOULD NOT be generated, and is deprecated. be understood, but SHOULD NOT be generated, and is deprecated.
These are followed by an Initial Vector of the same length as the 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 block size of the cipher for the decryption of the secret values, if
they are encrypted, and then the secret key values themselves. they are encrypted, and then the secret key values themselves.
3.7.2.2. Symmetric-key message encryption 3.7.2.2. Symmetric-key message encryption
skipping to change at page 20, line 10 skipping to change at page 20, line 22
0x28: Subkey revocation signature 0x28: Subkey revocation signature
The signature is calculated directly on the subkey being The signature is calculated directly on the subkey being
revoked. A revoked subkey is not to be used. Only revocation revoked. A revoked subkey is not to be used. Only revocation
signatures by the top-level signature key that is bound to this signatures by the top-level signature key that is bound to this
subkey, or by an authorized revocation key, should be considered subkey, or by an authorized revocation key, should be considered
valid revocation signatures. valid revocation signatures.
0x30: Certification revocation signature 0x30: Certification revocation signature
This signature revokes an earlier user ID certification This signature revokes an earlier user ID certification
signature (signature class 0x10 through 0x13). It should be signature (signature class 0x10 through 0x13) or direct-key
issued by the same key that issued the revoked signature or an signature (0x1F). It should be issued by the same key that
authorized revocation key The signature should have a later issued the revoked signature or an authorized revocation key.
creation date than the signature it revokes. The signature should have a later creation date than the
signature it revokes.
0x40: Timestamp signature. 0x40: Timestamp signature.
This signature is only meaningful for the timestamp contained in This signature is only meaningful for the timestamp contained in
it. 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 5.2.2. Version 3 Signature Packet Format
The body of a version 3 Signature Packet contains: The body of a version 3 Signature Packet contains:
- One-octet version number (3). - One-octet version number (3).
- One-octet length of following hashed material. MUST be 5. - One-octet length of following hashed material. MUST be 5.
- One-octet signature type. - One-octet signature type.
skipping to change at page 23, line 6 skipping to change at page 23, line 26
- One-octet public key algorithm. - One-octet public key algorithm.
- One-octet hash algorithm. - One-octet hash algorithm.
- Two-octet scalar octet count for following hashed subpacket - Two-octet scalar octet count for following hashed subpacket
data. Note that this is the length in octets of all of the data. Note that this is the length in octets of all of the
hashed subpackets; a pointer incremented by this number will hashed subpackets; a pointer incremented by this number will
skip over the hashed subpackets. 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 - Two-octet scalar octet count for following unhashed subpacket
data. Note that this is the length in octets of all of the data. Note that this is the length in octets of all of the
unhashed subpackets; a pointer incremented by this number will unhashed subpackets; a pointer incremented by this number will
skip over the unhashed subpackets. skip over the unhashed subpackets.
- Unhashed subpacket data. (zero or more subpackets) - Unhashed subpacket data. (zero or more subpackets)
- Two-octet field holding left 16 bits of signed hash value. - Two-octet field holding left 16 bits of signed hash value.
skipping to change at page 23, line 48 skipping to change at page 24, line 18
Each set of subpackets is preceded by a two-octet scalar count of Each set of subpackets is preceded by a two-octet scalar count of
the length of the set of subpackets. the length of the set of subpackets.
Each subpacket consists of a subpacket header and a body. The Each subpacket consists of a subpacket header and a body. The
header consists of: header consists of:
- the subpacket length (1, 2, or 5 octets) - the subpacket length (1, 2, or 5 octets)
- the subpacket type (1 octet) - the subpacket type (1 octet)
and is followed by the subpacket specific data. Note that this is and is followed by the subpacket specific data.
the same encoding used for signature subpackets
The length includes the type octet but not this length. Its format The length includes the type octet but not this length. Its format
is similar to the "new" format packet header lengths, but cannot is similar to the "new" format packet header lengths, but cannot
have partial body lengths. That is: have partial body lengths. That is:
if the 1st octet < 192, then if the 1st octet < 192, then
lengthOfLength = 1 lengthOfLength = 1
subpacketLen = 1st_octet subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then if the 1st octet >= 192 and < 255, then
skipping to change at page 24, line 41 skipping to change at page 25, line 7
21 = preferred hash algorithms 21 = preferred hash algorithms
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 = revocation identification 31 = signature target
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
skipping to change at page 25, line 38 skipping to change at page 26, line 5
A self-signature is a binding signature made by the key the A self-signature is a binding signature made by the key the
signature refers to. There are three types of self-signatures, the signature refers to. There are three types of self-signatures, the
certification signatures (types 0x10-0x13), the direct-key signature certification signatures (types 0x10-0x13), the direct-key signature
(type 0x1f), and the subkey binding signature (type 0x18). For (type 0x1f), and the subkey binding signature (type 0x18). For
certification self-signatures, each user ID may have a certification self-signatures, each user ID may have a
self-signature, and thus different subpackets in those self-signature, and thus different subpackets in those
self-signatures. For subkey binding signatures, each subkey in fact self-signatures. For subkey binding signatures, each subkey in fact
has a self-signature. Subpackets that appear in a certification has a self-signature. Subpackets that appear in a certification
self-signature apply to the username, and subpackets that appear in self-signature apply to the username, and subpackets that appear in
the subkey self-signature apply to the subkey. Lastly, subpackets on 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 Implementing software should interpret a self-signature's preference
subpackets as narrowly as possible. For example, suppose a key has subpackets as narrowly as possible. For example, suppose a key has
two usernames, Alice and Bob. Suppose that Alice prefers the two usernames, Alice and Bob. Suppose that Alice prefers the
symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If
the software locates this key via Alice's name, then the preferred 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 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, 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 then algorithm of the default user id of the key provides the
default symmetric algorithm. default symmetric algorithm.
Revoking a self-signature or allowing it to expire has a defined Revoking a self-signature or allowing it to expire has a semantic
semantic meaning. Revoking the self-signature on a user ID meaning that varies with the signature type. Revoking the
effectively retires that user name. The self-signature is a self-signature on a user ID effectively retires that user name. The
statement, "My name X is tied to my signing key K" and is self-signature is a statement, "My name X is tied to my signing key
corroborated by other users' certifications. If another user revokes K" and is corroborated by other users' certifications. If another
their certification, they are effectively saying that they no longer user revokes their certification, they are effectively saying that
believe that name and that key are tied together. Similarly, if the they no longer believe that name and that key are tied together.
user themselves revokes their self-signature, it means the user no Similarly, if the user themselves revokes their self-signature, it
longer goes by that name, no longer has that email address, etc. means the user no longer goes by that name, no longer has that email
Revoking a binding signature effectively retires that subkey. Please address, etc. Revoking a binding signature effectively retires that
see the "Reason for Revocation" subpacket below for more relevant subkey. Revoking a direct-key signature cancels that signature.
detail. Please see the "Reason for Revocation" subpacket below for more
relevant detail.
Since a self-signature contains important information about the Since a self-signature contains important information about the
key's use, an implementation SHOULD allow the user to rewrite the key's use, an implementation SHOULD allow the user to rewrite the
self-signature, and important information in it, such as preferences self-signature, and important information in it, such as preferences
and key expiration. and key expiration.
An implementation that encounters multiple self-signatures on the An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but it same object may resolve the ambiguity in any way it sees fit, but it
is RECOMMENDED that priority be given to the most recent is RECOMMENDED that priority be given to the most recent
self-signature. self-signature.
skipping to change at page 33, line 33 skipping to change at page 33, line 52
0x01 - Modification Detection (packets 18 and 19) 0x01 - Modification Detection (packets 18 and 19)
If an implementation implements any of the defined features, it If an implementation implements any of the defined features, it
SHOULD implement the features subpacket, too. SHOULD implement the features subpacket, too.
In the case of Modification Detection, an implementation may freely In the case of Modification Detection, an implementation may freely
infer this feature from other suitable implementation-dependent infer this feature from other suitable implementation-dependent
mechanisms. mechanisms.
5.2.3.25. Revocation Target 5.2.3.25. Signature Target
(1 octet PK algorithm, 1 octet hash algorithm, N octets hash) (1 octet PK algorithm, 1 octet hash algorithm, N octets hash)
This subpacket identifies a specific target signature that a This subpacket identifies a specific target signature that a
revocation signature revokes. This provides explicit designation of signature refers to. For revocation signatures, this subpacket
a revocation. All arguments are an identifier of that signature. 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 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.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.
skipping to change at page 35, line 12 skipping to change at page 35, line 33
generous in what they accept, while putting pressure on a creator to generous in what they accept, while putting pressure on a creator to
be stingy in what they generate. be stingy in what they generate.
Some apparent conflicts may actually make sense -- for example, Some apparent conflicts may actually make sense -- for example,
suppose a keyholder has an V3 key and a V4 key that share the same 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 RSA key material. Either of these keys can verify a signature
created by the other, and it may be reasonable for a signature to 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 contain an issuer subpacket for each key, as a way of explicitly
tying those keys to the signature. 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 The Symmetric-Key Encrypted Session Key packet holds the
symmetric-key encryption of a session key used to encrypt a message. symmetric-key encryption of a session key used to encrypt a message.
Zero or more Encrypted Session Key packets and/or Symmetric-Key Zero or more Encrypted Session Key packets and/or Symmetric-Key
Encrypted Session Key packets may precede a Symmetrically Encrypted Encrypted Session Key packets may precede a Symmetrically Encrypted
Data Packet that holds an encrypted message. The message is Data Packet that holds an encrypted message. The message is
encrypted with a session key, and the session key is itself encrypted with a session key, and the session key is itself
encrypted and stored in the Encrypted Session Key packet or the encrypted and stored in the Encrypted Session Key packet or the
Symmetric-Key Encrypted Session Key packet. Symmetric-Key Encrypted Session Key packet.
skipping to change at page 39, line 31 skipping to change at page 39, line 54
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, 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. 0
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 specifier. 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, Initial Vector (IV) of
the same length as the cipher's block size. the same length as the cipher's block size.
skipping to change at page 41, line 49 skipping to change at page 42, line 22
Symmetrically Encrypted Data Packet. In that case, the cipher Symmetrically Encrypted Data Packet. In that case, the cipher
algorithm octet is prefixed to the session key before it is algorithm octet is prefixed to the session key before it is
encrypted. If no packets of these types precede the encrypted data, encrypted. If no packets of these types precede the encrypted data,
the IDEA algorithm is used with the session key calculated as the the IDEA algorithm is used with the session key calculated as the
MD5 hash of the passphrase. MD5 hash of the passphrase.
The data is encrypted in CFB mode, with a CFB shift size equal to 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 the cipher's block size. The Initial Vector (IV) is specified as
all zeros. Instead of using an IV, OpenPGP prefixes a string of 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 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, before it is encrypted. The first block-size octets (for example, 8
8 octets for a 64-bit block length) are random, and the following octets for a 64-bit block length) are random, and the following two
two octets are copies of the last two octets of the IV. For example, octets are copies of the last two octets of the IV. For example, in
in an 8 octet block, octet 9 is a repeat of octet 7, and octet 10 is an 8 octet block, octet 9 is a repeat of octet 7, and octet 10 is a
a repeat of octet 8. In a cipher of length 16, octet 17 is a repeat repeat of octet 8. In a cipher of length 16, octet 17 is a repeat of
of octet 15 and octet 18 is a repeat of octet 16. As a pedantic octet 15 and octet 18 is a repeat of octet 16. As a pedantic
clarification, in both these examples, we consider the first octet clarification, in both these examples, we consider the first octet
to be numbered 1. to be numbered 1.
After encrypting the first block-size-plus-two octets, the CFB state After encrypting the first block-size-plus-two octets, the CFB state
is resynchronized. The last block-size octets of ciphertext are is resynchronized. The last block-size octets of ciphertext are
passed through the cipher and the block boundary is reset. passed through the cipher and the block boundary is reset.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. incorrect.
skipping to change at page 44, line 29 skipping to change at page 44, line 54
(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-byte 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. Also note that this is the same encoding used for
signature subpackets
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
are reserved for private or experimental use. The rest of the are reserved for private or experimental use. The rest of the
version 1 image header is made up of 12 reserved octets, all of version 1 image header is made up of 12 reserved octets, all of
which MUST be set to 0. which MUST be set to 0.
The rest of the image subpacket contains the image itself. As the The rest of the image subpacket contains the image itself. As the
only currently defined image type is JPEG, the image is encoded in only currently defined image type is JPEG, the image is encoded in
the JPEG File Interchange Format (JFIF), a standard file format for the JPEG File Interchange Format (JFIF), a standard file format for
skipping to change at page 46, line 11 skipping to change at page 46, line 38
respectively. Unlike the Symmetrically Encrypted Data Packet, no respectively. Unlike the Symmetrically Encrypted Data Packet, no
special CFB resynchronization is done after encrypting this prefix special CFB resynchronization is done after encrypting this prefix
data. data.
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. incorrect.
The plaintext of the data to be encrypted is passed through the 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 SHA-1 hash function, and the result of the hash is appended to the
plaintext in a Modification Detection Code packet. Specifically, plaintext in a Modification Detection Code packet. The input to the
the input to the hash function does not include the prefix data hash function includes the prefix data described above; it includes
described above; it includes all of the plaintext, and then also all of the plaintext, and then also includes two octets of values
includes two octets of values 0xD0, 0x14. These represent the 0xD3, 0x14. These represent the encoding of a Modification
encoding of a Modification Detection Code packet tag and length Detection Code packet tag and length field of 20 octets.
field of 20 octets.
The resulting hash value is stored in a Modification Detection Code The resulting hash value is stored in a Modification Detection Code
packet which MUST use the two octet encoding just given to represent 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 its tag and length field. The body of the MDC packet is the 20
octet output of the SHA-1 hash. octet output of the SHA-1 hash.
The Modification Detection Code packet is appended to the plaintext The Modification Detection Code packet is appended to the plaintext
and encrypted along with the plaintext using the same CFB context. and encrypted along with the plaintext using the same CFB context.
During decryption, the plaintext data should be hashed with SHA-1, During decryption, the plaintext data should be hashed with SHA-1,
not including the prefix data but including the packet tag and including the prefix data as well as the packet tag and length field
length field of the Modification Detection Code packet. The body of of the Modification Detection Code packet. The body of the MDC
the MDC packet, upon decryption, is compared with the result of the packet, upon decryption, is compared with the result of the SHA-1
SHA-1 hash. Any difference in hash values is an indication that the hash. Any difference in hash values is an indication that the
message has been modified and SHOULD be reported to the user. message has been modified and SHOULD be reported to the user.
Likewise, the absence of an MDC packet, or an MDC packet in any Likewise, the absence of an MDC packet, or an MDC packet in any
position other than the end of the plaintext, also represent message position other than the end of the plaintext, also represent message
modifications and SHOULD also be reported. modifications and SHOULD also be reported.
Note: future designs of new versions of this packet should consider Note: future designs of new versions of this packet should consider
rollback attacks since it will be possible for an attacker to change rollback attacks since it will be possible for an attacker to change
the version back to 1. the version back to 1.
5.14. Modification Detection Code Packet (Tag 19) 5.14. Modification Detection Code Packet (Tag 19)
skipping to change at page 54, line 55 skipping to change at page 55, line 25
the algorithms. the algorithms.
9.1. Public Key Algorithms 9.1. Public Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
1 - RSA (Encrypt or Sign) 1 - RSA (Encrypt or Sign)
2 - RSA Encrypt-Only 2 - RSA Encrypt-Only
3 - RSA Sign-Only 3 - RSA Sign-Only
16 - Elgamal (Encrypt-Only), see [ELGAMAL] 16 - Elgamal (Encrypt-Only), see [ELGAMAL]
17 - DSA (Digital Signature Standard) [SCHNEIER] 17 - DSA (Digital Signature Algorithm) [SCHNEIER]
18 - Reserved for Elliptic Curve 18 - Reserved for Elliptic Curve
19 - Reserved for ECDSA 19 - Reserved for ECDSA
20 - Elgamal (Encrypt or Sign) 20 - Elgamal (Encrypt or Sign)
21 - Reserved for Diffie-Hellman (X9.42, 21 - Reserved for Diffie-Hellman (X9.42,
as defined for IETF-S/MIME) as defined for IETF-S/MIME)
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement DSA for signatures, and Elgamal for Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys. encryption. Implementations SHOULD implement RSA keys.
Implementations MAY implement any other algorithm. Implementations MAY implement any other algorithm.
skipping to change at page 67, line 44 skipping to change at page 68, line 16
vexing than large differences. Thus, this is a non-comprehensive vexing than large differences. Thus, this is a non-comprehensive
list of potential problems and gotchas for a developer who is trying list of potential problems and gotchas for a developer who is trying
to be backward-compatible. to be backward-compatible.
* PGP 5.x does not accept V4 signatures for anything other than * PGP 5.x does not accept V4 signatures for anything other than
key material. key material.
* PGP 5.x does not recognize the "five-octet" lengths in * PGP 5.x does not recognize the "five-octet" lengths in
new-format headers or in signature subpacket lengths. new-format headers or in signature subpacket lengths.
* PGP 5.0 rejects an encrypted session key if the keylength * PGP 5.0 rejects an encrypted session key if the key size differs
differs from the S2K symmetric algorithm. This is a bug in its from the S2K symmetric algorithm. This is a bug in its
validation function. validation function.
* PGP 5.0 does not handle multiple one-pass signature headers and * PGP 5.0 does not handle multiple one-pass signature headers and
trailers. Signing one will compress the one-pass signed literal trailers. Signing one will compress the one-pass signed literal
and prefix a V3 signature instead of doing a nested one-pass and prefix a V3 signature instead of doing a nested one-pass
signature. signature.
* When exporting a private key, PGP 2.x generates the header * When exporting a private key, PGP 2.x generates the header
"BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY
BLOCK". All previous versions ignore the implied data type, and BLOCK". All previous versions ignore the implied data type, and
skipping to change at page 71, line 43 skipping to change at page 72, line 15
[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.
17. Full Copyright Statement 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 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
 End of changes. 

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