draft-ietf-openpgp-formats-06.txt   draft-ietf-openpgp-formats-07.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Network Associates Category: INTERNET-DRAFT Network Associates
draft-ietf-openpgp-formats-06.txt draft-ietf-openpgp-formats-07.txt
Expires Jan 1999 Lutz Donnerhacke Expires Feb 1999 Lutz Donnerhacke
July 1998 IN-Root-CA Individual Network e.V. August 1998 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
EIS Corporation EIS Corporation
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-formats-06.txt draft-ietf-openpgp-formats-07.txt
Copyright 1998 by The Internet Society. All Rights Reserved. Copyright 1998 by The Internet Society. All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Status of this Memo 1 Status of this Memo 1
Abstract 1 Abstract 1
Table of Contents 2 Table of Contents 2
1. Introduction 5 1. Introduction 5
1.1. Terms 5 1.1. Terms 5
2. General functions 5 2. General functions 5
2.1. Confidentiality via Encryption 5 2.1. Confidentiality via Encryption 5
2.2. Authentication via Digital signature 6 2.2. Authentication via Digital signature 6
2.3. Compression 7 2.3. Compression 7
2.4. Conversion to Radix-64 7 2.4. Conversion to Radix-64 7
2.5. Signature-Only Applications 7
3. Data Element Formats 7 3. Data Element Formats 7
3.1. Scalar numbers 7 3.1. Scalar numbers 7
3.2. Multi-Precision Integers 7 3.2. Multi-Precision Integers 8
3.3. Key IDs 8 3.3. Key IDs 8
3.4. Text 8 3.4. Text 8
3.5. Time fields 8 3.5. Time fields 8
3.6. String-to-key (S2K) specifiers 8 3.6. String-to-key (S2K) specifiers 8
3.6.1. String-to-key (S2k) specifier types 8 3.6.1. String-to-key (S2k) specifier types 9
3.6.1.1. Simple S2K 9 3.6.1.1. Simple S2K 9
3.6.1.2. Salted S2K 9 3.6.1.2. Salted S2K 9
3.6.1.3. Iterated and Salted S2K 9 3.6.1.3. Iterated and Salted S2K 10
3.6.2. String-to-key usage 10 3.6.2. String-to-key usage 10
3.6.2.1. Secret key encryption 10 3.6.2.1. Secret key encryption 10
3.6.2.2. Symmetric-key message encryption 11 3.6.2.2. Symmetric-key message encryption 11
4. Packet Syntax 11 4. Packet Syntax 11
4.1. Overview 11 4.1. Overview 11
4.2. Packet Headers 11 4.2. Packet Headers 12
4.2.1. Old-Format Packet Lengths 12 4.2.1. Old-Format Packet Lengths 12
4.2.2. New-Format Packet Lengths 12 4.2.2. New-Format Packet Lengths 13
4.2.2.1. One-Octet Lengths 13 4.2.2.1. One-Octet Lengths 13
4.2.2.2. Two-Octet Lengths 13 4.2.2.2. Two-Octet Lengths 13
4.2.2.3. Five-Octet Lengths 13 4.2.2.3. Five-Octet Lengths 13
4.2.2.4. Partial Body Lengths 13 4.2.2.4. Partial Body Lengths 13
4.2.3. Packet Length Examples 14 4.2.3. Packet Length Examples 14
4.3. Packet Tags 14 4.3. Packet Tags 14
5. Packet Types 15 5. Packet Types 15
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 15 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 15
5.2. Signature Packet (Tag 2) 16 5.2. Signature Packet (Tag 2) 16
5.2.1. Signature Types 16 5.2.1. Signature Types 16
5.2.2. Version 3 Signature Packet Format 18 5.2.2. Version 3 Signature Packet Format 18
5.2.3. Version 4 Signature Packet Format 20 5.2.3. Version 4 Signature Packet Format 20
5.2.3.1. Signature Subpacket Specification 21 5.2.3.1. Signature Subpacket Specification 21
5.2.3.2. Signature Subpacket Types 22 5.2.3.2. Signature Subpacket Types 22
5.2.3.3. Signature creation time 23 5.2.3.3. Signature creation time 23
5.2.3.4. Issuer 23 5.2.3.4. Issuer 23
5.2.3.5. Key expiration time 23 5.2.3.5. Key expiration time 23
5.2.3.6. Preferred symmetric algorithms 23 5.2.3.6. Preferred symmetric algorithms 23
5.2.3.7. Preferred hash algorithms 23 5.2.3.7. Preferred hash algorithms 24
5.2.3.8. Preferred compression algorithms 24 5.2.3.8. Preferred compression algorithms 24
5.2.3.9. Signature expiration time 24 5.2.3.9. Signature expiration time 24
5.2.3.10.Exportable Certification 24 5.2.3.10.Exportable Certification 24
5.2.3.11.Revocable 25 5.2.3.11.Revocable 25
5.2.3.12.Trust signature 25 5.2.3.12.Trust signature 25
5.2.3.13.Regular expression 25 5.2.3.13.Regular expression 25
5.2.3.14.Revocation key 25 5.2.3.14.Revocation key 26
5.2.3.15.Notation Data 26 5.2.3.15.Notation Data 26
5.2.3.16.Key server preferences 26 5.2.3.16.Key server preferences 26
5.2.3.17.Preferred key server 26 5.2.3.17.Preferred key server 27
5.2.3.18.Primary user id 27 5.2.3.18.Primary user id 27
5.2.3.19.Policy URL 27 5.2.3.19.Policy URL 27
5.2.3.20.Key Flags 27 5.2.3.20.Key Flags 27
5.2.3.21.Signer's User ID 28 5.2.3.21.Signer's User ID 28
5.2.3.22.Reason for Revocation 28 5.2.3.22.Reason for Revocation 28
5.2.4. Computing Signatures 29 5.2.4. Computing Signatures 29
5.2.4.1. Subpacket Hints 29 5.2.4.1. Subpacket Hints 30
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 30 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 30
5.4. One-Pass Signature Packets (Tag 4) 31 5.4. One-Pass Signature Packets (Tag 4) 31
5.5. Key Material Packet 31 5.5. Key Material Packet 32
5.5.1. Key Packet Variants 32 5.5.1. Key Packet Variants 32
5.5.1.1. Public Key Packet (Tag 6) 32 5.5.1.1. Public Key Packet (Tag 6) 32
5.5.1.2. Public Subkey Packet (Tag 14) 32 5.5.1.2. Public Subkey Packet (Tag 14) 32
5.5.1.3. Secret Key Packet (Tag 5) 32 5.5.1.3. Secret Key Packet (Tag 5) 32
5.5.1.4. Secret Subkey Packet (Tag 7) 32 5.5.1.4. Secret Subkey Packet (Tag 7) 32
5.5.2. Public Key Packet Formats 32 5.5.2. Public Key Packet Formats 32
5.5.3. Secret Key Packet Formats 34 5.5.3. Secret Key Packet Formats 34
5.6. Compressed Data Packet (Tag 8) 35 5.6. Compressed Data Packet (Tag 8) 36
5.7. Symmetrically Encrypted Data Packet (Tag 9) 36 5.7. Symmetrically Encrypted Data Packet (Tag 9) 36
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 37 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 37
5.9. Literal Data Packet (Tag 11) 37 5.9. Literal Data Packet (Tag 11) 37
5.10. Trust Packet (Tag 12) 38 5.10. Trust Packet (Tag 12) 38
5.11. User ID Packet (Tag 13) 38 5.11. User ID Packet (Tag 13) 38
6. Radix-64 Conversions 38 6. Radix-64 Conversions 38
6.1. An Implementation of the CRC-24 in "C" 39 6.1. An Implementation of the CRC-24 in "C" 39
6.2. Forming ASCII Armor 39 6.2. Forming ASCII Armor 39
6.3. Encoding Binary in Radix-64 41 6.3. Encoding Binary in Radix-64 41
6.4. Decoding Radix-64 42 6.4. Decoding Radix-64 42
6.5. Examples of Radix-64 42 6.5. Examples of Radix-64 43
6.6. Example of an ASCII Armored Message 43 6.6. Example of an ASCII Armored Message 43
7. Cleartext signature framework 43 7. Cleartext signature framework 43
7.1. Dash-Escaped Text 44 7.1. Dash-Escaped Text 44
8. Regular Expressions 44 8. Regular Expressions 44
9. Constants 45 9. Constants 45
9.1. Public Key Algorithms 45 9.1. Public Key Algorithms 45
9.2. Symmetric Key Algorithms 45 9.2. Symmetric Key Algorithms 46
9.3. Compression Algorithms 46 9.3. Compression Algorithms 46
9.4. Hash Algorithms 46 9.4. Hash Algorithms 46
10. Packet Composition 46 10. Packet Composition 47
10.1. Transferable Public Keys 47 10.1. Transferable Public Keys 47
10.2. OpenPGP Messages 48 10.2. OpenPGP Messages 48
11. Enhanced Key Formats 48 11. Enhanced Key Formats 48
11.1. Key Structures 48 11.1. Key Structures 48
11.2. Key IDs and Fingerprints 49 11.2. Key IDs and Fingerprints 49
12. Notes on Algorithms 50 12. Notes on Algorithms 50
12.1. Symmetric Algorithm Preferences 50 12.1. Symmetric Algorithm Preferences 50
12.2. Other Algorithm Preferences 51 12.2. Other Algorithm Preferences 51
12.2.1. Compression Preferences 51 12.2.1. Compression Preferences 51
12.2.2. Hash Algorithm Preferences 51 12.2.2. Hash Algorithm Preferences 52
12.3. Plaintext 52 12.3. Plaintext 52
12.4. RSA 52 12.4. RSA 52
12.5. Elgamal 52 12.5. Elgamal 52
12.6. DSA 53 12.6. DSA 53
12.7. Reserved Algorithm Numbers 53 12.7. Reserved Algorithm Numbers 53
12.8. OpenPGP CFB mode 53 12.8. OpenPGP CFB mode 54
13. Security Considerations 54 13. Security Considerations 55
14. Implementation Nits 55 14. Implementation Nits 56
15. Authors and Working Group Chair 56 15. Authors and Working Group Chair 57
16. References 57 16. References 58
17. Full Copyright Statement 58 17. Full Copyright Statement 59
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 builds on the foundation provided and key management functions. It builds on the foundation provided
in RFC1991 "PGP Message Exchange Formats." in RFC1991 "PGP Message Exchange Formats."
1.1. Terms 1.1. Terms
skipping to change at page 6, line 29 skipping to change at page 6, line 29
4. The sending OpenPGP encrypts the message using the session key, 4. The sending OpenPGP encrypts the message using the session key,
which forms the remainder of the message. Note that the message which forms the remainder of the message. Note that the message
is also usually compressed. is also usually compressed.
5. The receiving OpenPGP decrypts the session key using the 5. The receiving OpenPGP decrypts the session key using the
recipient's private key. recipient's private key.
6. The receiving OpenPGP decrypts the message using the session 6. The receiving OpenPGP decrypts the message using the session
key. If the message was compressed, it will be decompressed. key. If the message was compressed, it will be decompressed.
With symmetric-key encryption, an object may encrypted with a With symmetric-key encryption, an object may be encrypted with a
symmetric key derived from a passphrase (or other shared secret), or symmetric key derived from a passphrase (or other shared secret), or
a two-stage mechanism similar to the public-key method described a two-stage mechanism similar to the public-key method described
above in which a session key is itself encrypted with a symmetric above in which a session key is itself encrypted with a symmetric
algorithm keyed from a shared secret. algorithm keyed from a shared secret.
Both digital signature and confidentiality services may be applied Both digital signature and confidentiality services may be applied
to the same message. First, a signature is generated for the message to the same message. First, a signature is generated for the message
and attached to the message. Then, the message plus signature is and attached to the message. Then, the message plus signature is
encrypted using a symmetric session key. Finally, the session key is encrypted using a symmetric session key. Finally, the session key is
encrypted using public-key encryption and prefixed to the encrypted encrypted using public-key encryption and prefixed to the encrypted
skipping to change at page 7, line 38 skipping to change at page 7, line 38
of printable ASCII characters, called Radix-64 encoding or ASCII of printable ASCII characters, called Radix-64 encoding or ASCII
Armor. Armor.
Implementations SHOULD provide Radix-64 conversions. Implementations SHOULD provide Radix-64 conversions.
Note that many applications, particularly messaging applications, Note that many applications, particularly messaging applications,
will want more advanced features as described in the OpenPGP-MIME will want more advanced features as described in the OpenPGP-MIME
document, RFC2015. An application that implements OpenPGP for document, RFC2015. An application that implements OpenPGP for
messaging SHOULD implement OpenPGP-MIME. messaging SHOULD implement OpenPGP-MIME.
2.5. Signature-Only Applications
OpenPGP is designed for applications that use both encryption and
signatures, but there are a number of problems that are solved by a
signature-only implementation. Although this specification requires
both encryption and signatures, it is reasonable for there to be
subset implementations that are non-comformant only in that they
omit encryption.
3. Data Element Formats 3. Data Element Formats
This section describes the data elements used by OpenPGP. This section describes the data elements used by OpenPGP.
3.1. Scalar numbers 3.1. Scalar numbers
Scalar numbers are unsigned, and are always stored in big-endian Scalar numbers are unsigned, and are always stored in big-endian
format. Using n[k] to refer to the kth octet being interpreted, the format. Using n[k] to refer to the kth octet being interpreted, the
value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a
four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) +
skipping to change at page 8, line 36 skipping to change at page 8, line 43
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
The default character set for text is the UTF-8 [RFC2044] encoding The default character set for text is the UTF-8 [RFC2279] encoding
of Unicode [ISO10646]. 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. String-to-key (S2K) specifiers 3.6. 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
skipping to change at page 15, line 7 skipping to change at page 15, line 15
4 -- One-Pass Signature Packet 4 -- One-Pass Signature Packet
5 -- Secret Key Packet 5 -- Secret Key Packet
6 -- Public Key Packet 6 -- Public Key Packet
7 -- Secret Subkey Packet 7 -- Secret Subkey Packet
8 -- Compressed Data Packet 8 -- Compressed Data Packet
9 -- Symmetrically Encrypted Data Packet 9 -- Symmetrically Encrypted Data Packet
10 -- Marker Packet 10 -- Marker Packet
11 -- Literal Data Packet 11 -- Literal Data Packet
12 -- Trust Packet 12 -- Trust Packet
13 -- User ID Packet 13 -- User ID Packet
14 -- Subkey Packet 14 -- Public Subkey Packet
60 to 63 -- Private or Experimental Values 60 to 63 -- Private or Experimental Values
5. Packet Types 5. Packet Types
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 5.1. Public-Key Encrypted Session Key Packets (Tag 1)
A Public-Key Encrypted Session Key packet holds the session key used A Public-Key Encrypted Session Key packet holds the session key used
to encrypt a message. Zero or more Encrypted Session Key packets to encrypt a message. Zero or more Encrypted Session Key packets
(either Public-Key or Symmetric-Key) may precede a Symmetrically (either Public-Key or Symmetric-Key) may precede a Symmetrically
Encrypted Data Packet, which holds an encrypted message. The Encrypted Data Packet, which holds an encrypted message. The
skipping to change at page 16, line 7 skipping to change at page 16, line 18
- 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 octets, including the algorithm identifier and sum of the preceding octets, including the algorithm identifier and
session key, modulo 65536. This value is then padded as described session key, modulo 65536. This value is then padded as described
in PKCS-1 block type 02 [PKCS1] to form the "m" value used in the in PKCS-1 block type 02 [RFC2313] to form the "m" value used in the
formulas above. formulas above.
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 new PKCS-1 padding for each key. keys, the implementation MUST make new PKCS-1 padding for each 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 19, line 21 skipping to change at page 19, line 33
- 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 signature than for RSA signatures. DSA signature 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 10.1.2, "Data encoding", producing an ASN.1 value of PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of
type DigestInfo, and then padded using PKCS-1 block type 01 [PKCS1]. type DigestInfo, and then padded using PKCS-1 block type 01
This requires inserting the hash value as an octet string into an [RFC2313]. This requires inserting the hash value as an octet
ASN.1 structure. The object identifier for the type of hash being string into an ASN.1 structure. The object identifier for the type
used is included in the structure. The hexadecimal representations of hash being used is included in the structure. The hexadecimal
for the currently defined hash algorithms are: representations for the currently defined hash algorithms are:
- MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 - MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02
- 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
The ASN.1 OIDs are: The ASN.1 OIDs are:
skipping to change at page 20, line 4 skipping to change at page 20, line 15
The full hash prefixes for these are: The full hash prefixes for these are:
MD2: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, MD2: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00,
0x04, 0x10 0x04, 0x10
MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
0x04, 0x10 0x04, 0x10
RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
DSA signatures SHOULD use hashes with a size of 160 bits, to match DSA signatures MUST use hashes with a size of 160 bits, to match q,
q, the size of the group generated by the DSA key's generator value. the size of the group generated by the DSA key's generator value.
The hash function result is treated as a 160 bit number and used The hash function result is treated as a 160 bit number and used
directly in the DSA signature algorithm. directly in the DSA signature algorithm.
5.2.3. Version 4 Signature Packet Format 5.2.3. Version 4 Signature Packet Format
The body of a version 4 Signature Packet contains: The body of a version 4 Signature Packet contains:
- One-octet version number (4). - One-octet version number (4).
- One-octet signature type. - One-octet signature type.
skipping to change at page 23, line 27 skipping to change at page 23, line 41
The time the signature was made. The time the signature was made.
MUST be present in the hashed area. MUST be present in the hashed area.
5.2.3.4. Issuer 5.2.3.4. Issuer
(8 octet key ID) (8 octet key ID)
The OpenPGP key ID of the key issuing the signature. The OpenPGP key ID of the key issuing the signature.
MUST be present in the hashed area.
5.2.3.5. Key expiration time 5.2.3.5. Key expiration time
(4 octet time field) (4 octet time field)
The validity period of the key. This is the number of seconds after The validity period of the key. This is the number of seconds after
the key creation time that the key expires. If this is not present the key creation time that the key expires. If this is not present
or has a value of zero, the key never expires. This is found only on or has a value of zero, the key never expires. This is found only on
a self-signature. a self-signature.
5.2.3.6. Preferred symmetric algorithms 5.2.3.6. Preferred symmetric algorithms
skipping to change at page 24, line 35 skipping to change at page 24, line 48
this is not present or has a value of zero, it never expires. this is not present or has a value of zero, it never expires.
5.2.3.10. Exportable Certification 5.2.3.10. Exportable Certification
(1 octet of exportability, 0 for not, 1 for exportable) (1 octet of exportability, 0 for not, 1 for exportable)
This subpacket denotes whether a certification signature is This subpacket denotes whether a certification signature is
"exportable," to be used by other users than the signature's issuer. "exportable," to be used by other users than the signature's issuer.
The packet body contains a boolean flag indicating whether the The packet body contains a boolean flag indicating whether the
signature is exportable. If this packet is not present, the signature is exportable. If this packet is not present, the
certification is exportable; it is equvalent to a flag containing a certification is exportable; it is equivalent to a flag containing a
1. 1.
Non-exportable, or "local," certifications are signatures made by a Non-exportable, or "local," certifications are signatures made by a
user to mark a key as valid within that user's implementation only. user to mark a key as valid within that user's implementation only.
Thus, when an implementation prepare's a user's copy of a key for Thus, when an implementation prepares a user's copy of a key for
transport to another user (this is the process of "exporting" the transport to another user (this is the process of "exporting" the
key), any local certification signatures are deleted from the key. key), any local certification signatures are deleted from the key.
The receiver of a transported key "imports" it, and likewise trims The receiver of a transported key "imports" it, and likewise trims
any local certifications. In normal operation, there won't be any, any local certifications. In normal operation, there won't be any,
assuming the import is performed on an exported key. However, there assuming the import is performed on an exported key. However, there
are instances where this can reasonably happen. For example, if an are instances where this can reasonably happen. For example, if an
implementation allows keys to be imported from a key database in implementation allows keys to be imported from a key database in
addition to an exported key, then this situation can arise. addition to an exported key, then this situation can arise.
skipping to change at page 25, line 40 skipping to change at page 25, line 51
greater indicate complete trust. Implementations SHOULD emit values greater indicate complete trust. Implementations SHOULD emit values
of 60 for partial trust and 120 for complete trust. of 60 for partial trust and 120 for complete trust.
5.2.3.13. Regular expression 5.2.3.13. Regular expression
(null-terminated regular expression) (null-terminated regular expression)
Used in conjunction with trust signature packets (of level > 0) to Used in conjunction with trust signature packets (of level > 0) to
limit the scope of trust that is extended. Only signatures by the limit the scope of trust that is extended. Only signatures by the
target key on user IDs that match the regular expression in the body target key on user IDs that match the regular expression in the body
of this packet have trust extended by the trust packet. The regular of this packet have trust extended by the trust signature subpacket.
expression uses the same syntax as the Henry Spencer's "almost The regular expression uses the same syntax as the Henry Spencer's
public domain" regular expression package. A description of the "almost public domain" regular expression package. A description of
syntax is found in a section below. the syntax is found in a section below.
5.2.3.14. Revocation key 5.2.3.14. Revocation key
(1 octet of class, 1 octet of algid, 20 octets of fingerprint) (1 octet of class, 1 octet of algid, 20 octets of fingerprint)
Authorizes the specified key to issue revocation signatures for this Authorizes the specified key to issue revocation signatures for this
key. Class octet must have bit 0x80 set, other bits are for future
expansion to other kinds of signature authorizations. This is found
on a self-signature.
Authorizes the specified key to issue revocation signatures for this
key. Class octet must have bit 0x80 set. If the bit 0x40 is set, key. Class octet must have bit 0x80 set. If the bit 0x40 is set,
then this means that the revocation information is sensitive. Other then this means that the revocation information is sensitive. Other
bits are for future expansion to other kinds of authorizations. This bits are for future expansion to other kinds of authorizations. This
is found on a self-signature. is found on a self-signature.
If the "sensitive" flag is set, the keyholder feels this subpacket If the "sensitive" flag is set, the keyholder feels this subpacket
contains private trust information that describes a real-world contains private trust information that describes a real-world
sensitive relationship. If this flag is set, implementations SHOULD sensitive relationship. If this flag is set, implementations SHOULD
NOT export this signature to other users except in cases where the NOT export this signature to other users except in cases where the
data needs to be available: when the signature is being sent to the data needs to be available: when the signature is being sent to the
skipping to change at page 28, line 50 skipping to change at page 29, line 4
certificate was revoked. certificate was revoked.
The first octet contains a machine-readable code that denotes the The first octet contains a machine-readable code that denotes the
reason for the revocation: reason for the revocation:
0x00 - No reason specified (key revocations or cert revocations) 0x00 - No reason specified (key revocations or cert revocations)
0x01 - Key is superceded (key revocations) 0x01 - Key is superceded (key revocations)
0x02 - Key material has been compromised (key revocations) 0x02 - Key material has been compromised (key revocations)
0x03 - Key is no longer used (key revocations) 0x03 - Key is no longer used (key revocations)
0x20 - User id information is no longer valid (cert revocations) 0x20 - User id information is no longer valid (cert revocations)
Following the revocation code is a string of octets which gives
Following the recovation code is a string of octets which gives
information about the reason for revocation in human-readable form information about the reason for revocation in human-readable form
(UTF-8). The string may be null, that is, of zero length. The length (UTF-8). The string may be null, that is, of zero length. The length
of the subpacket is the length of the reason string plus one. of the subpacket is the length of the reason string plus one.
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
skipping to change at page 31, line 48 skipping to change at page 32, line 5
- A one-octet number describing the public key algorithm used. - A one-octet number describing the public key algorithm used.
- An eight-octet number holding the key ID of the signing key. - An eight-octet number holding the key ID of the signing key.
- A one-octet number holding a flag showing whether the signature - A one-octet number holding a flag showing whether the signature
is nested. A zero value indicates that the next packet is is nested. A zero value indicates that the next packet is
another One-Pass Signature packet that describes another another One-Pass Signature packet that describes another
signature to be applied to the same message data. signature to be applied to the same message data.
Note that if a message contains more than one one-pass signature,
then the signature packets bracket the message; that is, the first
signature packet after the message corresponds to the last one-pass
packet and the final signature packet corresponds to the first
one-pass packet.
5.5. Key Material Packet 5.5. Key Material Packet
A key material packet contains all the information about a public or A key material packet contains all the information about a public or
private key. There are four variants of this packet type, and two private key. There are four variants of this packet type, and two
major versions. Consequently, this section is complex. major versions. Consequently, this section is complex.
5.5.1. Key Packet Variants 5.5.1. Key Packet Variants
5.5.1.1. Public Key Packet (Tag 6) 5.5.1.1. Public Key Packet (Tag 6)
skipping to change at page 38, line 40 skipping to change at page 38, line 46
character set translation, data conversions, etc. character set translation, data conversions, etc.
In principle, any printable encoding scheme that met the In principle, any printable encoding scheme that met the
requirements of the unsafe channel would suffice, since it would not requirements of the unsafe channel would suffice, since it would not
change the underlying binary bit streams of the native OpenPGP data change the underlying binary bit streams of the native OpenPGP data
structures. The OpenPGP standard specifies one such printable structures. The OpenPGP standard specifies one such printable
encoding scheme to ensure interoperability. encoding scheme to ensure interoperability.
OpenPGP's Radix-64 encoding is composed of two parts: a base64 OpenPGP's Radix-64 encoding is composed of two parts: a base64
encoding of the binary data, and a checksum. The base64 encoding is encoding of the binary data, and a checksum. The base64 encoding is
identical to the MIME base64 content-transfer-encoding [RFC 2045, identical to the MIME base64 content-transfer-encoding [RFC 2231,
Section 6.8]. An OpenPGP implementation MAY use ASCII Armor to Section 6.8]. An OpenPGP implementation MAY use ASCII Armor to
protect the raw binary data. protect the raw binary data.
The checksum is a 24-bit CRC converted to four characters of The checksum is a 24-bit CRC converted to four characters of
radix-64 encoding by the same MIME base64 transformation, preceded radix-64 encoding by the same MIME base64 transformation, preceded
by an equals sign (=). The CRC is computed by using the generator by an equals sign (=). The CRC is computed by using the generator
0x864CFB and an initialization of 0xB704CE. The accumulation is 0x864CFB and an initialization of 0xB704CE. The accumulation is
done on the data before it is converted to radix-64, rather than on done on the data before it is converted to radix-64, rather than on
the converted data. A sample implementation of this algorithm is in the converted data. A sample implementation of this algorithm is in
the next section. the next section.
skipping to change at page 39, line 21 skipping to change at page 39, line 24
#define CRC24_INIT 0xb704ce #define CRC24_INIT 0xb704ce
#define CRC24_POLY 0x1864cfb #define CRC24_POLY 0x1864cfb
typedef long crc24; typedef long crc24;
crc24 crc_octets(unsigned char *octets, size_t len) crc24 crc_octets(unsigned char *octets, size_t len)
{ {
crc24 crc = CRC24_INIT; crc24 crc = CRC24_INIT;
int i; int i;
while (len--) { while (len--) {
crc ^= *octets++; crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) { for (i = 0; i < 8; i++) {
crc <<= 1; crc <<= 1;
if (crc & 0x1000000) if (crc & 0x1000000)
crc ^= CRC24_POLY; crc ^= CRC24_POLY;
} }
} }
return crc; return crc & 0xffffff;
} }
6.2. Forming ASCII Armor 6.2. Forming ASCII Armor
When OpenPGP encodes data into ASCII Armor, it puts specific headers When OpenPGP encodes data into ASCII Armor, it puts specific headers
around the data, so OpenPGP can reconstruct the data later. OpenPGP around the data, so OpenPGP can reconstruct the data later. OpenPGP
informs the user what kind of data is encoded in the ASCII armor informs the user what kind of data is encoded in the ASCII armor
through the use of the headers. through the use of the headers.
Concatenating the following data creates ASCII Armor: Concatenating the following data creates ASCII Armor:
skipping to change at page 40, line 6 skipping to change at page 40, line 12
- The Armor Tail, which depends on the Armor Header Line. - The Armor Tail, which depends on the Armor Header Line.
An Armor Header Line consists of the appropriate header line text An Armor Header Line consists of the appropriate header line text
surrounded by five (5) dashes ('-', 0x2D) on either side of the surrounded by five (5) dashes ('-', 0x2D) on either side of the
header line text. The header line text is chosen based upon the header line text. The header line text is chosen based upon the
type of data that is being encoded in Armor, and how it is being type of data that is being encoded in Armor, and how it is being
encoded. Header line texts include the following strings: encoded. Header line texts include the following strings:
BEGIN PGP MESSAGE BEGIN PGP MESSAGE
Used for signed, encrypted, or compressed files Used for signed, encrypted, or compressed files.
BEGIN PGP PUBLIC KEY BLOCK BEGIN PGP PUBLIC KEY BLOCK
Used for armoring public keys Used for armoring public keys
BEGIN PGP PRIVATE KEY BLOCK BEGIN PGP PRIVATE KEY BLOCK
Used for armoring private keys Used for armoring private keys
BEGIN PGP MESSAGE, PART X/Y BEGIN PGP MESSAGE, PART X/Y
Used for multi-part messages, where the armor is split amongst Y Used for multi-part messages, where the armor is split amongst Y
parts, and this is the Xth part out of Y. parts, and this is the Xth part out of Y.
BEGIN PGP MESSAGE, PART X BEGIN PGP MESSAGE, PART X
Used for multi-part messages, where this is the Xth part of an Used for multi-part messages, where this is the Xth part of an
unspecified number of parts. Requires the MESSAGE-ID Armor unspecified number of parts. Requires the MESSAGE-ID Armor
Header to be used. Header to be used.
BEGIN PGP SIGNATURE BEGIN PGP SIGNATURE
Used for detached signatures, OpenPGP/MIME signatures, and Used for detached signatures, OpenPGP/MIME signatures, and
signatures following clearsigned messages signatures following clearsigned messages. Note that PGP 2.x
uses BEGIN PGP MESSAGE for detached signatures.
The Armor Headers are pairs of strings that can give the user or the The Armor Headers are pairs of strings that can give the user or the
receiving OpenPGP implementation some information about how to receiving OpenPGP implementation some information about how to
decode or use the message. The Armor Headers are a part of the decode or use the message. The Armor Headers are a part of the
armor, not a part of the message, and hence are not protected by any armor, not a part of the message, and hence are not protected by any
signatures applied to the message. signatures applied to the message.
The format of an Armor Header is that of a key-value pair. A colon The format of an Armor Header is that of a key-value pair. A colon
(':' 0x38) and a single space (0x20) separate the key and value. (':' 0x38) and a single space (0x20) separate the key and value.
OpenPGP should consider improperly formatted Armor Headers to be OpenPGP should consider improperly formatted Armor Headers to be
skipping to change at page 41, line 5 skipping to change at page 41, line 10
- "MessageID", a 32-character string of printable characters. The - "MessageID", a 32-character string of printable characters. The
string must be the same for all parts of a multi-part message string must be the same for all parts of a multi-part message
that uses the "PART X" Armor Header. MessageID strings should that uses the "PART X" Armor Header. MessageID strings should
be unique enough that the recipient of the mail can associate be unique enough that the recipient of the mail can associate
all the parts of a message with each other. A good checksum or all the parts of a message with each other. A good checksum or
cryptographic hash function is sufficient. cryptographic hash function is sufficient.
- "Hash", a comma-separated list of hash algorithms used in this - "Hash", a comma-separated list of hash algorithms used in this
message. This is used only in clear-signed messages. message. This is used only in clear-signed messages.
- "Charset", a description of the character set that the plantext - "Charset", a description of the character set that the plaintext
is in. Please note that OpenPGP defines text to be in UTF-8, so is in. Please note that OpenPGP defines text to be in UTF-8 by
this Armor Header Key is only useful for backwards default. An implementation will get best results by translating
compatibility. An implementation MAY implement it; an into and out of UTF-8. However, there are many instances where
implementation MAY ignore it. this is easier said than done. Also, there are communities of
users who have no need for UTF-8 because they are all happy with
a character set like ISO Latin-5 or a Japanese character set. In
such instances, an implementation MAY override the UTF-8 default
by using this header key. An implementation MAY implement this
key and any translations it cares to; an implementation MAY
ignore it and assume all text is UTF-8.
The MessageID SHOULD NOT appear unless it is in a multi-part The MessageID SHOULD NOT appear unless it is in a multi-part
message. If it appears at all, it MUST be computed from the message. If it appears at all, it MUST be computed from the
finished (encrypted, signed, etc.) message in a deterministic finished (encrypted, signed, etc.) message in a deterministic
fashion, rather than contain a purely random value. This is to fashion, rather than contain a purely random value. This is to
allow the legitimate recipient to determine that the MessageID allow the legitimate recipient to determine that the MessageID
cannot serve as a covert means of leaking cryptographic key cannot serve as a covert means of leaking cryptographic key
information. information.
The Armor Tail Line is composed in the same manner as the Armor The Armor Tail Line is composed in the same manner as the Armor
skipping to change at page 44, line 4 skipping to change at page 44, line 13
cleartext, this framework is used. (Note that RFC 2015 defines cleartext, this framework is used. (Note that RFC 2015 defines
another way to clear sign messages for environments that support another way to clear sign messages for environments that support
MIME.) MIME.)
The cleartext signed message consists of: The cleartext signed message consists of:
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
single line, single line,
- One or more "Hash" Armor Headers, - One or more "Hash" Armor Headers,
- Exactly one empty line not included into the message digest, - Exactly one empty line not included into the message digest,
- The dash-escaped cleartext that is included into the message - The dash-escaped cleartext that is included into the message
digest, digest,
- The ASCII armored signature(s) including the Armor Header and - The ASCII armored signature(s) including the '-----BEGIN PGP
Armor Tail Lines. SIGNATURE-----' Armor Header and Armor Tail Lines.
If the "Hash" armor header is given, the specified message digest If the "Hash" armor header is given, the specified message digest
algorithm is used for the signature. If there are no such headers, algorithm is used for the signature. If there are no such headers,
MD5 is used, an implementation MAY omit them for V2.x compatibility. MD5 is used, an implementation MAY omit them for V2.x compatibility.
If more than one message digest is used in the signature, the "Hash" If more than one message digest is used in the signature, the "Hash"
armor header contains a comma-delimited list of used message armor header contains a comma-delimited list of used message
digests. digests.
Current message digest names are described below with the algorithm Current message digest names are described below with the algorithm
IDs. IDs.
skipping to change at page 45, line 42 skipping to change at page 45, line 51
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) 17 - DSA (Digital Signature Standard)
18 - Elliptic Curve (reserved for) 18 - Reserved for Elliptic Curve
19 - ECDSA (reserved for) 19 - Reserved for ECDSA
20 - Elgamal (Encrypt or Sign) 20 - Elgamal (Encrypt or Sign)
21 - Diffie-Hellman (X9.42, as defined for IETF-S/MIME) 21 - Reserved for Diffie-Hellman (X9.42,
(reserved for) 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.
9.2. Symmetric Key Algorithms 9.2. Symmetric Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Plaintext or unencrypted data 0 - Plaintext or unencrypted data
1 - IDEA 1 - IDEA
2 - Triple-DES (DES-EDE, as per spec - 2 - Triple-DES (DES-EDE, as per spec -
168 bit key derived from 192) 168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC2144) 3 - CAST5 (128 bit key, as per RFC2144)
4 - Blowfish (128 bit key, 16 rounds) 4 - Blowfish (128 bit key, 16 rounds)
5 - SAFER-SK128 (13 rounds) 5 - SAFER-SK128 (13 rounds)
6 - DES/SK (reserved for) 6 - Reserved for DES/SK
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement Triple-DES. Implementations SHOULD Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.Implementations MAY implement any other implement IDEA and CAST5.Implementations MAY implement any other
algorithm. algorithm.
9.3. Compression Algorithms 9.3. Compression Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
skipping to change at page 46, line 37 skipping to change at page 46, line 46
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 ZLIB.
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 for double-width 4 - Reserved for double-width SHA (experimental)
SHA (experimental)
5 - MD2 "MD2" 5 - MD2 "MD2"
6 - TIGER/192 (reserved for) "TIGER192" 6 - Reserved for TIGER/192 "TIGER192"
7 - HAVAL (5 pass, 160-bit) "HAVAL-5-160" 7 - Reserved for HAVAL (5 pass, 160-bit)
(reserved for) "HAVAL-5-160"
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations SHOULD Implementations MUST implement SHA-1. Implementations SHOULD
implement MD5. implement MD5.
10. Packet Composition 10. Packet Composition
OpenPGP packets are assembled into sequences in order to create OpenPGP packets are assembled into sequences in order to create
messages messages and to transfer keys. Not all possible packet sequences
are meaningful and correct. This describes the rules for how
and to transfer keys. Not all possible packet sequences are packets should be placed into sequences.
meaningful and correct. This describes the rules for how packets
should be placed into sequences.
10.1. Transferable Public Keys 10.1. Transferable Public Keys
OpenPGP users may transfer public keys. The essential elements of a OpenPGP users may transfer public keys. The essential elements of a
transferable public key are: transferable public key are:
- One Public Key packet - One Public Key packet
- Zero or more revocation signatures - Zero or more revocation signatures
skipping to change at page 48, line 18 skipping to change at page 48, line 27
corresponds to the following grammatical rules (comma represents corresponds to the following grammatical rules (comma represents
sequential composition, and vertical bar separates alternatives): sequential composition, and vertical bar separates alternatives):
OpenPGP Message :- Encrypted Message | Signed Message | OpenPGP Message :- Encrypted Message | Signed Message |
Compressed Message | Literal Message. Compressed Message | Literal Message.
Compressed Message :- Compressed Data Packet. Compressed Message :- Compressed Data Packet.
Literal Message :- Literal Data Packet. Literal Message :- Literal Data Packet.
ESK :- Pubic Key Encrypted Session Key Packet | ESK :- Public Key Encrypted Session Key Packet |
Symmetric-Key Encrypted Session Key Packet. Symmetric-Key Encrypted Session Key Packet.
ESK Sequence :- ESK | ESK Sequence, ESK. ESK Sequence :- ESK | ESK Sequence, ESK.
Encrypted Message :- Symmetrically Encrypted Data Packet | Encrypted Message :- Symmetrically Encrypted Data Packet |
ESK Sequence, Symmetrically Encrypted Data Packet. ESK Sequence, Symmetrically Encrypted Data Packet.
One-Pass Signed Message :- One-Pass Signature Packet, One-Pass Signed Message :- One-Pass Signature Packet,
OpenPGP Message, Signature Packet. OpenPGP Message, Corresponding Signature Packet.
Signed Message :- Signature Packet, OpenPGP Message | Signed Message :- Signature Packet, OpenPGP Message |
One-Pass Signed Message. One-Pass Signed Message.
In addition, decrypting a Symmetrically Encrypted Data packet and In addition, decrypting a Symmetrically Encrypted Data packet and
decompressing a Compressed Data packet must yield a valid OpenPGP decompressing a Compressed Data packet must yield a valid OpenPGP
Message. Message.
11. Enhanced Key Formats 11. Enhanced Key Formats
skipping to change at page 56, line 27 skipping to change at page 56, line 40
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
look directly at the packet data type. look directly at the packet data type.
* In a clear-signed signature, PGP 5.0 will figure out the correct * In a clear-signed signature, PGP 5.0 will figure out the correct
hash algorithm if there is no "Hash:" header, but it will reject hash algorithm if there is no "Hash:" header, but it will reject
a mismatch between the header and the actual agorithm used. The a mismatch between the header and the actual algorithm used. The
"standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x
rejects the "Hash:" header and assumes MD5. There are a number rejects the "Hash:" header and assumes MD5. There are a number
of enhanced variants of PGP 2.6.x that have been modified for of enhanced variants of PGP 2.6.x that have been modified for
SHA-1 signatures. SHA-1 signatures.
* PGP 5.0 can read an RSA key in V4 format, but can only recognize * PGP 5.0 can read an RSA key in V4 format, but can only recognize
it with a V3 keyid, and can properly use only a V3 format RSA it with a V3 keyid, and can properly use only a V3 format RSA
key. key.
* Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign
keys. They only handle Elgamal Encrypt-only keys.
* There are many ways possible for two keys to have the same key * There are many ways possible for two keys to have the same key
material, but different fingerprints (and thus key ids). Perhaps material, but different fingerprints (and thus key ids). Perhaps
the most interesting is an RSA key that has been "upgraded" to the most interesting is an RSA key that has been "upgraded" to
V4 format, but since a V4 fingerprint is constructed by hashing V4 format, but since a V4 fingerprint is constructed by hashing
the key creation time along with other things, two V4 keys the key creation time along with other things, two V4 keys
created at different times, yet with the same key material will created at different times, yet with the same key material will
have different fingerprints. have different fingerprints.
* If an implemtation is using zlib to interoperate with PGP 2.x, * If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
15. Authors and Working Group Chair 15. Authors and Working Group Chair
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
John W. Noerenberg, II John W. Noerenberg, II
Qualcomm, Inc Qualcomm, Inc
6455 Lusk Blvd 6455 Lusk Blvd
San Diego, CA 92131 USA San Diego, CA 92131 USA
Email: jwn2@qualcomm.com Email: jwn2@qualcomm.com
Tel: +1 619-658-3510 Tel: +1 619-658-3510
The principal authors of this draft are: The principal authors of this draft are:
Jon Callas Jon Callas
Network Associates, Inc. Network Associates, Inc.
4200 Bohannon Drive 3965 Freedom Circle
Menlo Park, CA 94025, USA Santa Clara, CA 95054, USA
Email: jon@pgp.com Email: jon@pgp.com, jcallas@nai.com
Tel: +1-650-473-2860 Tel: +1-408-346-5860
Lutz Donnerhacke Lutz Donnerhacke
IKS GmbH IKS GmbH
Wildenbruchstr. 15 Wildenbruchstr. 15
07745 Jena, Germany 07745 Jena, Germany
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Tel: +49-3641-675642 Tel: +49-3641-675642
Hal Finney Hal Finney
Network Associates, Inc. Network Associates, Inc.
4200 Bohannon Drive 3965 Freedom Circle
Menlo Park, CA 94025, USA Santa Clara, CA 95054, USA
Email: hal@pgp.com Email: hal@pgp.com
Rodney Thayer Rodney Thayer
EIS Corporation EIS Corporation
Clearwater, FL 33767, USA Clearwater, FL 33767, USA
Email: rodney@unitran.com Email: rodney@unitran.com
This draft also draws on much previous work from a number of other This draft also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto, authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
skipping to change at page 58, line 14 skipping to change at page 58, line 30
[ISO-10646] ISO/IEC 10646-1:1993. International Standard -- [ISO-10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Coded Character Information technology -- Universal Multiple-Octet Coded Character
Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane.
UTF-8 is described in Annex R, adopted but not yet published. UTF-8 is described in Annex R, adopted but not yet published.
UTF-16 is described in Annex Q, adopted but not yet published. UTF-16 is described in Annex Q, adopted but not yet published.
[MENEZES] Alfred Menezes, Paul van Oorschot, and Scott Vanstone, [MENEZES] Alfred Menezes, Paul van Oorschot, and Scott Vanstone,
"Handbook of Applied Cryptography," CRC Press, 1996. "Handbook of Applied Cryptography," CRC Press, 1996.
[PKCS1] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
version 1.5, November 1993
[RFC822] D. Crocker, "Standard for the format of ARPA Internet text [RFC822] D. Crocker, "Standard for the format of ARPA Internet text
messages", RFC 822, August 1982 messages", RFC 822, August 1982
[RFC1423] D. Balenson, "Privacy Enhancement for Internet Electronic [RFC1423] D. Balenson, "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423,
October 1993 October 1993
[RFC1641] Goldsmith, D., and M. Davis, "Using Unicode with MIME", [RFC1641] Goldsmith, D., and M. Davis, "Using Unicode with MIME",
RFC 1641, Taligent inc., July 1994. RFC 1641, Taligent inc., July 1994.
skipping to change at page 58, line 41 skipping to change at page 58, line 54
version 1.3. May 1996. version 1.3. May 1996.
[RFC1983] G. Malkin., Internet Users' Glossary. August 1996. [RFC1983] G. Malkin., Internet Users' Glossary. August 1996.
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, August 1996. Exchange Formats", RFC 1991, August 1996.
[RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy
(PGP)", RFC 2015, October 1996. (PGP)", RFC 2015, October 1996.
[RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and [RFC2231] Borenstein, N., and Freed, N., "Multipurpose Internet Mail
ISO 10646. October 1996.
[RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies.", Extensions (MIME) Part One: Format of Internet Message Bodies.",
November 1996 November 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. March 1997. Requirement Level. March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", May 1997 [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", May 1997
[RFC2279] F. Yergeau., UTF-8, a transformation format of Unicode and
ISO 10646. October 1996.
[RFC2313] RSA Laboratories, "PKCS #1: RSA Encryption Standard,"
version 1.5, November 1993
17. Full Copyright Statement 17. Full Copyright Statement
Copyright 1998 by The Internet Society. All Rights Reserved. Copyright 1998 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
 End of changes. 

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