draft-ietf-openpgp-formats-03.txt   draft-ietf-openpgp-formats-04.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-03.txt draft-ietf-openpgp-formats-04.txt
Expires Nov 1998 Lutz Donnerhacke Expires Dec 1998 Lutz Donnerhacke
May 1998 IN-Root-CA Individual Network e.V. June 1998 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
Sable Technology EIS Corporation
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-formats-03.txt draft-ietf-openpgp-formats-04.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 1, line 44 skipping to change at page 1, line 44
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
This document is maintained in order to publish all necessary This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on information needed to develop interoperable applications based on
the OpenPGP format. It is not a step-by-step cookbook for writing an the OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to application. It describes only the format and methods needed to
read, check, generate and write conforming packets crossing any read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions. network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid It does, however, discuss implementation issues necessary to avoid
security flaws. security flaws.
Open-PGP software uses a combination of strong public-key and Open-PGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic symmetric cryptography to provide security services for electronic
communications and data storage. These services include communications and data storage. These services include
confidentiality, key management, authentication and digital confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in signatures. This document specifies the message formats used in
OpenPGP. OpenPGP.
Table of Contents Table of Contents
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
skipping to change at page 2, line 56 skipping to change at page 2, line 56
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 20 5.2.3.1. Signature Subpacket Specification 20
5.2.3.2. Signature Subpacket Types 22 5.2.3.2. Signature Subpacket Types 22
5.2.3.3. Signature creation time 22 5.2.3.3. Signature creation time 22
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 23
5.2.3.8. Preferred compression algorithms 23 5.2.3.8. Preferred compression algorithms 23
5.2.3.9. Signature expiration time 23 5.2.3.9. Signature expiration time 24
5.2.3.10.Exportable 24 5.2.3.10.Exportable 24
5.2.3.11.Revocable 24 5.2.3.11.Revocable 24
5.2.3.12.Trust signature 24 5.2.3.12.Trust signature 24
5.2.3.13.Regular expression 24 5.2.3.13.Regular expression 24
5.2.3.14.Revocation key 25 5.2.3.14.Revocation key 25
5.2.3.15.Notation Data 25 5.2.3.15.Notation Data 25
5.2.3.16.Key server preferences 25 5.2.3.16.Key server preferences 26
5.2.3.17.Preferred key server 26 5.2.3.17.Preferred key server 26
5.2.3.18.Primary user id 26 5.2.3.18.Primary user id 26
5.2.3.19.Policy URL 26 5.2.3.19.Policy URL 26
5.2.3.20.Key Flags 26 5.2.3.20.Key Flags 26
5.2.3.21.Signer's User ID 27 5.2.3.21.Signer's User ID 27
5.2.4. Computing Signatures 27 5.2.3.22.Reason for Revocation 27
5.2.4.1. Subpacket Hints 28 5.2.4. Computing Signatures 28
5.2.4.1. Subpacket Hints 29
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 29 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 29
5.4. One-Pass Signature Packets (Tag 4) 30 5.4. One-Pass Signature Packets (Tag 4) 30
5.5. Key Material Packet 30 5.5. Key Material Packet 31
5.5.1. Key Packet Variants 30 5.5.1. Key Packet Variants 31
5.5.1.1. Public Key Packet (Tag 6) 30 5.5.1.1. Public Key Packet (Tag 6) 31
5.5.1.2. Public Subkey Packet (Tag 14) 30 5.5.1.2. Public Subkey Packet (Tag 14) 31
5.5.1.3. Secret Key Packet (Tag 5) 31 5.5.1.3. Secret Key Packet (Tag 5) 31
5.5.1.4. Secret Subkey Packet (Tag 7) 31 5.5.1.4. Secret Subkey Packet (Tag 7) 31
5.5.2. Public Key Packet Formats 31 5.5.2. Public Key Packet Formats 31
5.5.3. Secret Key Packet Formats 33 5.5.3. Secret Key Packet Formats 33
5.6. Compressed Data Packet (Tag 8) 34 5.6. Compressed Data Packet (Tag 8) 35
5.7. Symmetrically Encrypted Data Packet (Tag 9) 35 5.7. Symmetrically Encrypted Data Packet (Tag 9) 35
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 35 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 36
5.9. Literal Data Packet (Tag 11) 36 5.9. Literal Data Packet (Tag 11) 36
5.10. Trust Packet (Tag 12) 36 5.10. Trust Packet (Tag 12) 37
5.11. User ID Packet (Tag 13) 37 5.11. User ID Packet (Tag 13) 37
6. Radix-64 Conversions 37 6. Radix-64 Conversions 37
6.1. An Implementation of the CRC-24 in "C" 37 6.1. An Implementation of the CRC-24 in "C" 38
6.2. Forming ASCII Armor 38 6.2. Forming ASCII Armor 38
6.3. Encoding Binary in Radix-64 39 6.3. Encoding Binary in Radix-64 40
6.4. Decoding Radix-64 41 6.4. Decoding Radix-64 41
6.5. Examples of Radix-64 41 6.5. Examples of Radix-64 42
6.6. Example of an ASCII Armored Message 42 6.6. Example of an ASCII Armored Message 42
7. Cleartext signature framework 42 7. Cleartext signature framework 42
7.1. Dash-Escaped Text 42 7.1. Dash-Escaped Text 43
8. Regular Expressions 43 8. Regular Expressions 43
9. Constants 43 9. Constants 44
9.1. Public Key Algorithms 44 9.1. Public Key Algorithms 44
9.2. Symmetric Key Algorithms 44 9.2. Symmetric Key Algorithms 45
9.3. Compression Algorithms 44 9.3. Compression Algorithms 45
9.4. Hash Algorithms 45 9.4. Hash Algorithms 45
10. Packet Composition 45 10. Packet Composition 45
10.1. Transferable Public Keys 45 10.1. Transferable Public Keys 46
10.2. OpenPGP Messages 46 10.2. OpenPGP Messages 47
11. Enhanced Key Formats 47 11. Enhanced Key Formats 47
11.1. Key Structures 47 11.1. Key Structures 47
11.2. Key IDs and Fingerprints 48 11.2. Key IDs and Fingerprints 48
12. Notes on Algorithms 48 12. Notes on Algorithms 49
12.1. Symmetric Algorithm Preferences 48 12.1. Symmetric Algorithm Preferences 49
12.2. Other Algorithm Preferences 49 12.2. Other Algorithm Preferences 50
12.2.1. Compression Preferences 49 12.2.1. Compression Preferences 50
12.2.2. Hash Algorithm Preferences 50 12.2.2. Hash Algorithm Preferences 51
12.3. Plaintext 50 12.3. Plaintext 51
12.4. RSA 50 12.4. RSA 51
12.5. Elgamal 51 12.5. Elgamal 51
12.6. DSA 51 12.6. DSA 52
12.7. OpenPGP CFB mode 51 12.7. OpenPGP CFB mode 52
13. Security Considerations 52 13. Security Considerations 53
14. Implementation Nits 53 14. Implementation Nits 54
15. Authors and Working Group Chair 54 15. Authors and Working Group Chair 55
16. References 55 16. References 56
17. Full Copyright Statement 56 17. Full Copyright Statement 57
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,
key management and functions. It builds on the foundation provided and key management functions. It builds on the foundation provided
in RFC 1991 "PGP Message Exchange Formats." in RFC 1991 "PGP Message Exchange Formats."
1.1. Terms 1.1. Terms
* OpenPGP - This is a definition for security software that uses * OpenPGP - This is a definition for security software that uses
PGP 5.x as a basis. PGP 5.x as a basis.
* PGP - Pretty Good Privacy. PGP is a family of software systems * PGP - Pretty Good Privacy. PGP is a family of software systems
developed by Philip R. Zimmermann from which OpenPGP is based. developed by Philip R. Zimmermann from which OpenPGP is based.
skipping to change at page 6, line 27 skipping to change at page 6, line 27
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 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 aboved can be a two-stage mechanism similar to the public-key method described
used where 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 prepended to the encrypted encrypted using public-key encryption and prefixed to the encrypted
block. block.
2.2. Authentication via Digital signature 2.2. Authentication via Digital signature
The digital signature uses a hash code or message digest algorithm, The digital signature uses a hash code or message digest algorithm,
and a public-key signature algorithm. The sequence is as follows: and a public-key signature algorithm. The sequence is as follows:
1. The sender creates a message. 1. The sender creates a message.
2. The sending software generates a hash code of the message. 2. The sending software generates a hash code of the message.
skipping to change at page 11, line 23 skipping to change at page 11, line 23
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) OpenPGP can create a Symmetric-key Encrypted Session Key (ESK)
packet at the front of a message. This is used to allow S2K packet at the front of a message. This is used to allow S2K
specifiers to be used for the passphrase conversion or to create specifiers to be used for the passphrase conversion or to create
messages with a mix of symmetric-key ESKs and public-key ESKs. This messages with a mix of symmetric-key ESKs and public-key ESKs. This
allows a message to be decrypted either with a passphrase or a allows a message to be decrypted either with a passphrase or a
public key. public key.
PGP 2.X always used IDEA with Simple string-to-key conversion when PGP 2.X always used IDEA with Simple string-to-key conversion when
encrypting a message with a symmetric algorithm. This is deprecated, encrypting a message with a symmetric algorithm. This is deprecated,
but MAY be used for backwards-compatibility. but MAY be used for backward-compatibility.
4. Packet Syntax 4. Packet Syntax
This section describes the packets used by OpenPGP. This section describes the packets used by OpenPGP.
4.1. Overview 4.1. Overview
An OpenPGP message is constructed from a number of records that are An OpenPGP message is constructed from a number of records that are
traditionally called packets. A packet is a chunk of data that has a traditionally called packets. A packet is a chunk of data that has a
tag specifying its meaning. An OpenPGP message, keyring, tag specifying its meaning. An OpenPGP message, keyring,
skipping to change at page 12, line 9 skipping to change at page 12, line 9
+---------------+ +---------------+
PTag |7 6 5 4 3 2 1 0| PTag |7 6 5 4 3 2 1 0|
+---------------+ +---------------+
Bit 7 -- Always one Bit 7 -- Always one
Bit 6 -- New packet format if set Bit 6 -- New packet format if set
PGP 2.6.x only uses old format packets. Thus, software that PGP 2.6.x only uses old format packets. Thus, software that
interoperates with those versions of PGP must only use old format interoperates with those versions of PGP must only use old format
packets. If interoperability is not an issue, either format may be packets. If interoperability is not an issue, either format may be
used. Note that old format packets have four bits of content tags, used. Note that old format packets have four bits of content tags,
and new format packets have six; some features cannot be used and and new format packets have six; some features cannot be used and
still be backwards-compatible. still be backward-compatible.
Old format packets contain: Old format packets contain:
Bits 5-2 -- content tag Bits 5-2 -- content tag
Bits 1-0 - length-type Bits 1-0 - length-type
New format packets contain: New format packets contain:
Bits 5-0 -- content tag Bits 5-0 -- content tag
skipping to change at page 12, line 33 skipping to change at page 12, line 33
0 - The packet has a one-octet length. The header is 2 octets long. 0 - The packet has a one-octet length. The header is 2 octets long.
1 - The packet has a two-octet length. The header is 3 octets long. 1 - The packet has a two-octet length. The header is 3 octets long.
2 - The packet has a four-octet length. The header is 5 octets long. 2 - The packet has a four-octet length. The header is 5 octets long.
3 - The packet is of indeterminate length. The header is 1 octet 3 - The packet is of indeterminate length. The header is 1 octet
long, and the implementation must determine how long the packet long, and the implementation must determine how long the packet
is. If the packet is in a file, this means that the packet is. If the packet is in a file, this means that the packet
extends until the end of the file. With a compressed packet, the extends until the end of the file. In general, an implementation
algorithm implicitly denotes how the end of the packet. In SHOULD NOT use indeterminate length packets except where the end
general, an implementation SHOULD NOT use indeterminate length of the data will be clear from the context, and even then it is
packets except where the end of the data will be clear from the better to use a definite length, or a new-format header. The
context, and even then it is better to use a definite length, or new-format headers described below have a mechanism for
a new-format header. The new-format headers described below have precisely encoding data of indeterminate length.
a mechanism for precisely encoding data of indeterminite length.
4.2.2. New-Format Packet Lengths 4.2.2. New-Format Packet Lengths
New format packets have four possible ways of encoding length: New format packets have four possible ways of encoding length:
1. A one-octet Body Length header encodes packet lengths of up to 1. A one-octet Body Length header encodes packet lengths of up to
191 octets. 191 octets.
2. A two-octet Body Length header encodes packet lengths of 192 to 2. A two-octet Body Length header encodes packet lengths of 192 to
8383 octets. 8383 octets.
skipping to change at page 13, line 14 skipping to change at page 13, line 14
4. When the length of the packet body is not known in advance by 4. When the length of the packet body is not known in advance by
the issuer, Partial Body Length headers encode a packet of the issuer, Partial Body Length headers encode a packet of
indeterminite length, effectively making it a stream. indeterminite length, effectively making it a stream.
4.2.2.1. One-Octet Lengths 4.2.2.1. One-Octet Lengths
A one-octet Body Length header encodes a length of from 0 to 191 A one-octet Body Length header encodes a length of from 0 to 191
octets. This type of length header is recognized because the one octets. This type of length header is recognized because the one
octet value is less than 192. The body length is equal to: octet value is less than 192. The body length is equal to:
bodyLen = length_octet; bodyLen = 1st_octet;
4.2.2.2. Two-Octet Lengths 4.2.2.2. Two-Octet Lengths
A two-octet Body Length header encodes a length of from 192 to 8383 A two-octet Body Length header encodes a length of from 192 to 8383
octets. It is recognized because its first octet is in the range octets. It is recognized because its first octet is in the range
192 to 223. The body length is equal to: 192 to 223. The body length is equal to:
bodyLen = (1st_octet - 192) * 256 + (2nd_octet) + 192 bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
4.2.2.3. Five-Octet Lengths 4.2.2.3. Five-Octet Lengths
A five-octet Body Length header consists of a single octet holding A five-octet Body Length header consists of a single octet holding
the value 255, followed by a four-octet scalar. The body length is the value 255, followed by a four-octet scalar. The body length is
equal to: equal to:
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet (4th_octet << 8) | 5th_octet
4.2.2.4. Partial Body Lengths 4.2.2.4. Partial Body Lengths
A Partial Body Length header is one octet long and encodes the A Partial Body Length header is one octet long and encodes the
length of only part of the data packet. This length is a power of 2, length of only part of the data packet. This length is a power of 2,
from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by
its one octet value that is greater than or equal to 224, and less its one octet value that is greater than or equal to 224, and less
than 255. The partial body length is equal to: than 255. The partial body length is equal to:
partialBodyLen = 1 << (length_octet & 0x1f); partialBodyLen = 1 << (1st_octet & 0x1f);
Each Partial Body Length header is followed by a portion of the Each Partial Body Length header is followed by a portion of the
packet body data. The Partial Body Length header specifies this packet body data. The Partial Body Length header specifies this
portion's length. Another length header (of one of the three types portion's length. Another length header (of one of the three types
-- one octet, two-octet, or partial) follows that portion. The last -- one octet, two-octet, or partial) follows that portion. The last
length header in the packet MUST NOT be a partial Body Length length header in the packet MUST NOT be a partial Body Length
header. Partial Body Length headers may only be used for the header. Partial Body Length headers may only be used for the
non-final parts of the packet. non-final parts of the packet.
4.2.3. Packet Length Examples 4.2.3. Packet Length Examples
skipping to change at page 15, line 54 skipping to change at page 15, line 54
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 [PKCS1] 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 PKCS-1 the implementation MUST make new padding for each keys, the implementation MUST make new PKCS-1 padding for each key.
key.
An implementation MAY accept or use a Key ID of zero as a "wild An implementation MAY accept or use a Key ID of zero as a "wild
card" or "speculative" Key ID. In this case, the receiving card" or "speculative" Key ID. In this case, the receiving
implementation would try all available private keys, checking for a implementation would try all available private keys, checking for a
valid decrypted session key. This format helps reduce traffic valid decrypted session key. This format helps reduce traffic
analysis of messages. analysis of messages.
5.2. Signature Packet (Tag 2) 5.2. Signature Packet (Tag 2)
A signature packet describes a binding between some public key and A signature packet describes a binding between some public key and
skipping to change at page 16, line 42 skipping to change at page 16, line 42
There are a number of possible meanings for a signature, which are There are a number of possible meanings for a signature, which are
specified in a signature type octet in any given signature. These specified in a signature type octet in any given signature. These
meanings are: meanings are:
0x00: Signature of a binary document. 0x00: Signature of a binary document.
Typically, this means the signer owns it, created it, or Typically, this means the signer owns it, created it, or
certifies that it has not been modified. certifies that it has not been modified.
0x01: Signature of a canonical text document. 0x01: Signature of a canonical text document.
Typically, this means the signer owns it, created it, or Typically, this means the signer owns it, created it, or
certifies that it has not been modified. The signature will be certifies that it has not been modified. The signature is
calculated over the text data with its line endings converted to calculated over the text data with its line endings converted to
<CR><LF> and trailing blanks removed. <CR><LF> and trailing blanks removed.
0x02: Standalone signature. 0x02: Standalone signature.
This signature is a signature of only its own subpacket This signature is a signature of only its own subpacket
contents. It is calculated identically to a signature over a contents. It is calculated identically to a signature over a
zero-length binary document. Note that it doesn't make sense to zero-length binary document. Note that it doesn't make sense to
have a V3 standalone signature. have a V3 standalone signature.
0x10: Generic certification of a User ID and Public Key packet. 0x10: Generic certification of a User ID and Public Key packet.
skipping to change at page 17, line 36 skipping to change at page 17, line 36
0x18: Subkey Binding Signature 0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key This signature is a statement by the top-level signing key
indicates that it owns the subkey. This signature is calculated indicates that it owns the subkey. This signature is calculated
directly on the subkey itself, not on any User ID or other directly on the subkey itself, not on any User ID or other
packets. packets.
0x1F: Signature directly on a key 0x1F: Signature directly on a key
This signature is calculated directly on a key. It binds the This signature is calculated directly on a key. It binds the
information in the signature subpackets to the key, and is information in the signature subpackets to the key, and is
appropriate to be used for subpackets which provide information appropriate to be used for subpackets that provide information
about the key, such as the revocation key subpacket. It is also about the key, such as the revocation key subpacket. It is also
appropriate for statements that non-self certifiers want to make appropriate for statements that non-self certifiers want to make
about the key itself, rather than the binding between a key and about the key itself, rather than the binding between a key and
a name. a name.
0x20: Key revocation signature 0x20: Key revocation signature
The signature is calculated directly on the key being revoked. The signature is calculated directly on the key being revoked.
A revoked key is not to be used. Only revocation signatures by A revoked key is not to be used. Only revocation signatures by
the key being revoked, or by an authorized revocation key, the key being revoked, or by an authorized revocation key,
should be considered valid revocation signatures. should be considered valid revocation signatures.
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 which 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). It should be
issued by the same key which issued the revoked signature or an issued by the same key that issued the revoked signature or an
authorized revocation key The signature should have a later authorized revocation key The signature should have a later
creation date than the signature it revokes. 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.
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:
skipping to change at page 21, line 9 skipping to change at page 21, line 9
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)
- the subpacket specific data and is followed by the subpacket specific data.
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 the same as the "new" format packet header lengths. That is: is similar to the "new" format packet header lengths, but cannot
have partial body lengths. That is:
if the 1st octet < 192, then length is the octet value if the 1st octet < 192, then
lengthOfLength = 1
subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then length is 2 octets and if the 1st octet >= 192 and < 255, then
equal to (1st octet - 192) * 256 + (2nd octet) + 192 lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then the subpacket length is a if the 1st octet = 255, then
four-octet scalar found in octets 2 through 5, as per the packet lengthOfLength = 5
header length. subpacket length = [four-octet scalar starting at 2nd_octet]
The value of the subpacket type octet may be: The value of the subpacket type octet may be:
2 = signature creation time 2 = signature creation time
3 = signature expiration time 3 = signature expiration time
4 = exportable 4 = exportable
5 = trust signature 5 = trust signature
6 = regular expression 6 = regular expression
7 = revocable 7 = revocable
9 = key expiration time 9 = key expiration time
10 = placeholder for backwards compatibility 10 = placeholder for backward compatibility
11 = preferred symmetric algorithms 11 = preferred symmetric algorithms
12 = revocation key 12 = revocation key
16 = issuer key ID 16 = issuer key ID
20 = notation data 20 = notation data
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
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 which of the signature to recognize. If a subpacket is encountered that
is marked critical but is unknown to the evaluating software, the is marked critical but is unknown to the evaluating software, the
evaluator SHOULD consider the signature to be in error. evaluator SHOULD consider the signature to be in error.
An evaluator may "recognize" a subpacket, but not implement it. The An evaluator may "recognize" a subpacket, but not implement it. The
purpose of the critical bit is to allow the signer to tell an purpose of the critical bit is to allow the signer to tell an
evaluator that it would prefer a new, unknown feature to generate an evaluator that it would prefer a new, unknown feature to generate an
error than be ignored. error than be ignored.
Implementations SHOULD implement "preferences". Implementations SHOULD implement "preferences".
skipping to change at page 24, line 4 skipping to change at page 24, line 8
Compression algorithm numbers that indicate which algorithms the key Compression algorithm numbers that indicate which algorithms the key
holder prefers to use. Like the preferred symmetric algorithms, the holder prefers to use. Like the preferred symmetric algorithms, the
list is ordered. Algorithm numbers are in section 6. If this list is ordered. Algorithm numbers are in section 6. If this
subpacket is not included, ZIP is preferred. A zero denotes that subpacket is not included, ZIP is preferred. A zero denotes that
uncompressed data is preferred; the key holder's software may not uncompressed data is preferred; the key holder's software may not
have compression software. This is only found on a self-signature. have compression software. This is only found on a self-signature.
5.2.3.9. Signature expiration time 5.2.3.9. Signature expiration time
(4 octet time field) (4 octet time field)
The validity period of the signature. This is the number of seconds The validity period of the signature. This is the number of seconds
after the signature creation time that the signature expires. If after the signature creation time that the signature expires. If
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 5.2.3.10. Exportable
(1 octet of exportability, 0 for not, 1 for exportable) (1 octet of exportability, 0 for not, 1 for exportable)
Signature's exportability status. Packet body contains a boolean Signature's exportability status. Packet body contains a boolean
flag indicating whether the signature is exportable. Signatures flag indicating whether the signature is exportable. Signatures that
which are not exportable are ignored during export and import are not exportable are ignored during export and import operations.
operations. If this packet is not present the signature is assumed If this packet is not present the signature is assumed to be
to be exportable. exportable.
5.2.3.11. Revocable 5.2.3.11. Revocable
(1 octet of revocability, 0 for not, 1 for revocable) (1 octet of revocability, 0 for not, 1 for revocable)
Signature's revocability status. Packet body contains a boolean Signature's revocability status. Packet body contains a boolean
flag indicating whether the signature is revocable. Signatures flag indicating whether the signature is revocable. Signatures that
which are not revocable have any later revocation signatures are not revocable have any later revocation signatures ignored.
ignored. They represent a commitment by the signer that he cannot They represent a commitment by the signer that he cannot revoke his
revoke his signature for the life of his key. If this packet is not signature for the life of his key. If this packet is not present,
present, the signature is revocable. the signature is revocable.
5.2.3.12. Trust signature 5.2.3.12. Trust signature
(1 octet "level" (depth), 1 octet of trust amount) (1 octet "level" (depth), 1 octet of trust amount)
Signer asserts that the key is not only valid, but also trustworthy, Signer asserts that the key is not only valid, but also trustworthy,
at the specified level. Level 0 has the same meaning as an ordinary at the specified level. Level 0 has the same meaning as an ordinary
validity signature. Level 1 means that the signed key is asserted validity signature. Level 1 means that the signed key is asserted
to be a valid trusted introducer, with the 2nd octet of the body to be a valid trusted introducer, with the 2nd octet of the body
specifying the degree of trust. Level 2 means that the signed key is specifying the degree of trust. Level 2 means that the signed key is
skipping to change at page 24, line 49 skipping to change at page 25, line 4
it is a "meta introducer". Generally, a level n trust signature it is a "meta introducer". Generally, a level n trust signature
asserts that a key is trusted to issue level n-1 trust signatures. asserts that a key is trusted to issue level n-1 trust signatures.
The trust amount is in a range from 0-255, interpreted such that The trust amount is in a range from 0-255, interpreted such that
values less than 120 indicate partial trust and values of 120 or values less than 120 indicate partial trust and values of 120 or
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 which is extended. Only signatures by the limit the scope of trust that is extended. Only signatures by the
target key on user IDs which match the regular expression in the target key on user IDs that match the regular expression in the body
body of this packet have trust extended by the trust packet. The of this packet have trust extended by the trust packet. The regular
regular expression uses the same syntax as the Henry Spencer's expression uses the same syntax as the Henry Spencer's "almost
"almost public domain" regular expression package. A description of public domain" regular expression package. A description of the
the syntax is found in a section below. 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 key. Class octet must have bit 0x80 set, other bits are for future
expansion to other kinds of signature authorizations. This is found expansion to other kinds of signature authorizations. This is found
on a self-signature. on a self-signature.
skipping to change at page 25, line 29 skipping to change at page 25, line 35
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
designated revoker, or when it is accompanied by a revocation designated revoker, or when it is accompanied by a revocation
signature from that revoker. Note that it may be appropriate to signature from that revoker. Note that it may be appropriate to
isolate this subpacket within a separate signature so that it is not isolate this subpacket within a separate signature so that it is not
combined with other subpackets which need to be exported. combined with other subpackets that need to be exported.
5.2.3.15. Notation Data 5.2.3.15. Notation Data
(4 octets of flags, 2 octets of name length (M), (4 octets of flags, 2 octets of name length (M),
2 octets of value length (N), 2 octets of value length (N),
M octets of name data, M octets of name data,
N octets of value data) N octets of value data)
This subpacket describes a "notation" on the signature that the This subpacket describes a "notation" on the signature that the
issuer wishes to make. The notation has a name and a value, each of issuer wishes to make. The notation has a name and a value, each of
skipping to change at page 26, line 40 skipping to change at page 26, line 47
an implementation to resolve ambiguities in preferences, etc. by an implementation to resolve ambiguities in preferences, etc. by
referring to the primary user id. If this flag is absent, its value referring to the primary user id. If this flag is absent, its value
is zero. If more than one user id in a key is marked as primary, the is zero. If more than one user id in a key is marked as primary, the
implementation may resolve the ambiguity in any way it sees fit. implementation may resolve the ambiguity in any way it sees fit.
5.2.3.19. Policy URL 5.2.3.19. Policy URL
(String) (String)
This subpacket contains a URL of a document that describes the This subpacket contains a URL of a document that describes the
policy under which the signature was issued. policy that the signature was issued under.
5.2.3.20. Key Flags 5.2.3.20. Key Flags
(Octet string) (Octet string)
This subpacket contains a list of binary flags that hold information This subpacket contains a list of binary flags that hold information
about a key. It is a string of octets, and an implementation MUST about a key. It is a string of octets, and an implementation MUST
NOT assume a fixed size. This is so it can grow over time. If a list NOT assume a fixed size. This is so it can grow over time. If a list
is shorter than an implementation expects, the unstated flags are is shorter than an implementation expects, the unstated flags are
considered to be zero. The defined flags are: considered to be zero. The defined flags are:
skipping to change at page 27, line 48 skipping to change at page 27, line 51
the key the flag applies to. the key the flag applies to.
5.2.3.21. Signer's User ID 5.2.3.21. Signer's User ID
This subpacket allows a keyholder to state which user id is This subpacket allows a keyholder to state which user id is
responsible for the signing. Many keyholders use a single key for responsible for the signing. Many keyholders use a single key for
different purposes, such as business communications as well as different purposes, such as business communications as well as
personal communications. This subpacket allows such a keyholder to personal communications. This subpacket allows such a keyholder to
state which of their roles is making a signature. state which of their roles is making a signature.
5.2.3.22. Reason for Revocation
(1 octet of revocation code, N octets of reason string)
This subpacket is used only in key revocation and certification
revocation signatures. It describes the reason why the key or
certificate was revoked.
The first octet contains a machine-readable code that denotes the
reason for the revocation:
0x00 - No reason specified (key revocations or cert revocations)
0x01 - Key is superceded (key revocations)
0x02 - Key material has been compromised (key revocations)
0x03 - Key is no longer used (key revocations)
0x20 - User id information is no longer valid (cert revocations)
Following the recovation code is a string of octets which gives
information about the reason for revocation in human-readable form
(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.
5.2.4. Computing Signatures 5.2.4. Computing Signatures
All signatures are formed by producing a hash over the signature All signatures are formed by producing a hash over the signature
data, and then using the resulting hash in the signature algorithm. data, and then using the resulting hash in the signature algorithm.
The signature data is simple to compute for document signatures The signature data is simple to compute for document signatures
(types 0x00 and 0x01), for which the document itself is the data. (types 0x00 and 0x01), for which the document itself is the data.
For standalone signatures, this is a null string. For standalone signatures, this is a null string.
When a signature is made over a key, the hash data starts with the When a signature is made over a key, the hash data starts with the
skipping to change at page 28, line 45 skipping to change at page 29, line 19
six octets. six octets.
After all this has been hashed, the resulting hash field is used in After all this has been hashed, the resulting hash field is used in
the signature algorithm, and placed at the end of the signature the signature algorithm, and placed at the end of the signature
packet. packet.
5.2.4.1. Subpacket Hints 5.2.4.1. Subpacket Hints
An implementation SHOULD put the two mandatory subpackets, creation An implementation SHOULD put the two mandatory subpackets, creation
time and issuer, as the first subpackets in the subpacket list, time and issuer, as the first subpackets in the subpacket list,
simply to make it easier for the implementor to find them. simply to make it easier for the implementer to find them.
It is certainly possible for a signature to contain conflicting It is certainly possible for a signature to contain conflicting
information in subpackets. For example, a signature may contain information in subpackets. For example, a signature may contain
multiple copies of a preference or multiple expiration times. In multiple copies of a preference or multiple expiration times. In
most cases, an implementation SHOULD use the last subpacket in the most cases, an implementation SHOULD use the last subpacket in the
signature, but MAY use any conflict resolution scheme that makes signature, but MAY use any conflict resolution scheme that makes
more sense. Please note that we are intentionally leaving conflict more sense. Please note that we are intentionally leaving conflict
resolution to the implementor; most conflicts are simply syntax resolution to the implementer; most conflicts are simply syntax
errors, and the wishy-washy language here allows a receiver to be errors, and the wishy-washy language here allows a receiver to be
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.
skipping to change at page 29, line 25 skipping to change at page 29, line 52
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.
If the Symmetrically Encrypted Data Packet is preceded by one or If the Symmetrically Encrypted Data Packet is preceded by one or
more Symmetric-Key Encrypted Session Key packets, each specifies a more Symmetric-Key Encrypted Session Key packets, each specifies a
passphrase which may be used to decrypt the message. This allows a passphrase that may be used to decrypt the message. This allows a
message to be encrypted to a number of public keys, and also to one message to be encrypted to a number of public keys, and also to one
or more pass phrases. This packet type is new, and is not generated or more pass phrases. This packet type is new, and is not generated
by PGP 2.x or PGP 5.0. by PGP 2.x or PGP 5.0.
The body of this packet consists of: The body of this packet consists of:
- A one-octet version number. The only currently defined version - A one-octet version number. The only currently defined version
is 4. is 4.
- A one-octet number describing the symmetric algorithm used. - A one-octet number describing the symmetric algorithm used.
skipping to change at page 30, line 36 skipping to change at page 31, line 11
section 5.2.3. section 5.2.3.
- A one-octet number describing the hash algorithm used. - A one-octet number describing the hash algorithm used.
- 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 which 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.
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
skipping to change at page 31, line 11 skipping to change at page 31, line 39
A Public Subkey packet (tag 14) has exactly the same format as a A Public Subkey packet (tag 14) has exactly the same format as a
Public Key packet, but denotes a subkey. One or more subkeys may be Public Key packet, but denotes a subkey. One or more subkeys may be
associated with a top-level key. By convention, the top-level key associated with a top-level key. By convention, the top-level key
provides signature services, and the subkeys provide encryption provides signature services, and the subkeys provide encryption
services. services.
Note: in PGP 2.6.x, tag 14 was intended to indicate a comment Note: in PGP 2.6.x, tag 14 was intended to indicate a comment
packet. This tag was selected for reuse because no previous version packet. This tag was selected for reuse because no previous version
of PGP ever emitted comment packets but they did properly ignore of PGP ever emitted comment packets but they did properly ignore
them. Public Subkey packets are ignored by PGP 2.6.x and do not them. Public Subkey packets are ignored by PGP 2.6.x and do not
cause it to fail, providing a limited degree of backwards cause it to fail, providing a limited degree of backward
compatibility. compatibility.
5.5.1.3. Secret Key Packet (Tag 5) 5.5.1.3. Secret Key Packet (Tag 5)
A Secret Key packet contains all the information that is found in a A Secret Key packet contains all the information that is found in a
Public Key packet, including the public key material, but also Public Key packet, including the public key material, but also
includes the secret key material after all the public key fields. includes the secret key material after all the public key fields.
5.5.1.4. Secret Subkey Packet (Tag 7) 5.5.1.4. Secret Subkey Packet (Tag 7)
skipping to change at page 32, line 4 skipping to change at page 32, line 28
A version 3 public key or public subkey packet contains: A version 3 public key or public subkey packet contains:
- A one-octet version number (3). - A one-octet version number (3).
- A four-octet number denoting the time that the key was created. - A four-octet number denoting the time that the key was created.
- A two-octet number denoting the time in days that this key is - A two-octet number denoting the time in days that this key is
valid. If this number is zero, then it does not expire. valid. If this number is zero, then it does not expire.
- A one-octet number denoting the public key algorithm of this key - A one-octet number denoting the public key algorithm of this key
- A series of multi-precision integers comprising the key - A series of multi-precision integers comprising the key
material: material:
- a multiprecision integer (MPI) of RSA public modulus n; - a multiprecision integer (MPI) of RSA public modulus n;
- an MPI of RSA public encryption exponent e. - an MPI of RSA public encryption exponent e.
V3 keys SHOULD only be used for backards compatibility because of V3 keys SHOULD only be used for backward compatibility because of
three weaknesses in them. First, it is relatively easy to construct three weaknesses in them. First, it is relatively easy to construct
a V3 key that has the same key ID as any other key because the key a V3 key that has the same key ID as any other key because the key
ID is simply the low 64 bits of the public modulus. Secondly, ID is simply the low 64 bits of the public modulus. Secondly,
because the fingerprint of a V3 key hashes the key material, but not because the fingerprint of a V3 key hashes the key material, but not
its length, which increases the opportunity for fingerprint its length, which increases the opportunity for fingerprint
collisions. Third, there are minor weaknesses in the MD5 hash collisions. Third, there are minor weaknesses in the MD5 hash
algorithm that make developers prefer other algorithms. See below algorithm that make developers prefer other algorithms. See below
for a fuller discussion of key IDs and fingerprints. for a fuller discussion of key IDs and fingerprints.
The version 4 format is similar to the version 3 format except for The version 4 format is similar to the version 3 format except for
skipping to change at page 34, line 17 skipping to change at page 34, line 40
- MPI of DSA secret exponent x. - MPI of DSA secret exponent x.
Algorithm Specific Fields for Elgamal secret keys: Algorithm Specific Fields for Elgamal secret keys:
- MPI of Elgamal secret exponent x. - MPI of Elgamal secret exponent x.
Secret MPI values can be encrypted using a passphrase. If a Secret MPI values can be encrypted using a passphrase. If a
string-to-key specifier is given, that describes the algorithm for string-to-key specifier is given, that describes the algorithm for
converting the passphrase to a key, else a simple MD5 hash of the converting the passphrase to a key, else a simple MD5 hash of the
passphrase is used. Implementations SHOULD use a string-to-key passphrase is used. Implementations SHOULD use a string-to-key
specifier; the simple hash is for backwards compatibility. The specifier; the simple hash is for backward compatibility. The cipher
cipher for encrypting the MPIs is specified in the secret key for encrypting the MPIs is specified in the secret key packet.
packet.
Encryption/decryption of the secret data is done in CFB mode using Encryption/decryption of the secret data is done in CFB mode using
the key created from the passphrase and the Initial Vector from the the key created from the passphrase and the Initial Vector from the
packet. A different mode is used with V3 keys (which are onlyRSA) packet. A different mode is used with V3 keys (which are onlyRSA)
than with other key formats. With V3 keys, the MPI bit count prefix than with other key formats. With V3 keys, the MPI bit count prefix
(i.e., the first two octets) is not encrypted. Only the MPI (i.e., the first two octets) is not encrypted. Only the MPI
non-prefix data is encrypted. Furthermore, the CFB state is non-prefix data is encrypted. Furthermore, the CFB state is
resynchronized at the beginning of each new MPI value, so that the resynchronized at the beginning of each new MPI value, so that the
CFB block boundary is aligned with the start of the MPI data. CFB block boundary is aligned with the start of the MPI data.
skipping to change at page 35, line 7 skipping to change at page 35, line 31
- One octet that gives the algorithm used to compress the packet. - One octet that gives the algorithm used to compress the packet.
- The remainder of the packet is compressed data. - The remainder of the packet is compressed data.
A Compressed Data Packet's body contains an block that compresses A Compressed Data Packet's body contains an block that compresses
some set of packets. See section "Packet Composition" for details on some set of packets. See section "Packet Composition" for details on
how messages are formed. how messages are formed.
ZIP-compressed packets are compressed with raw RFC1951 DEFLATE ZIP-compressed packets are compressed with raw RFC1951 DEFLATE
blocks. Note that PGP V2.6 uses 13 bits of compression. If an blocks. Note that PGP V2.6 uses 13 bits of compression. If an
implementation uses more bits of compression, it cannot be implementation uses more bits of compression, If an implementation
decompressed by PGP V2.6 uses more bits of compression, PGP V2.6 cannot decompress it.
ZLIB-compressed packets are compressed with RFC1950 ZLIB-style ZLIB-compressed packets are compressed with RFC1950 ZLIB-style
blocks. blocks.
5.7. Symmetrically Encrypted Data Packet (Tag 9) 5.7. Symmetrically Encrypted Data Packet (Tag 9)
The Symmetrically Encrypted Data packet contains data encrypted with The Symmetrically Encrypted Data packet contains data encrypted with
a symmetric-key algorithm. When it has been decrypted, it will a symmetric-key algorithm. When it has been decrypted, it will
typically contain other packets (often literal data packets or typically contain other packets (often literal data packets or
compressed data packets). compressed data packets).
The body of this packet consists of: The body of this packet consists of:
- Encrypted data, the output of the selected symmetric-key cipher - Encrypted data, the output of the selected symmetric-key cipher
operating in PGP's variant of Cipher Feedback (CFB) mode. operating in PGP's variant of Cipher Feedback (CFB) mode.
The symmetric cipher used may be specified in an Public-Key or The symmetric cipher used may be specified in an Public-Key or
Symmetric-Key Encrypted Session Key packet which precedes the Symmetric-Key Encrypted Session Key packet that precedes the
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 10 octet all zeros. Instead of using an IV, OpenPGP prefixes a 10-octet
string to the data before it is encrypted. The first eight octets string to the data before it is encrypted. The first eight octets
are random, and the 9th and 10th octets are copies of the 7th and are random, and the 9th and 10th octets are copies of the 7th and
8th octets, respectivelly. After encrypting the first 10 octets, the 8th octets, respectively. After encrypting the first 10 octets, the
CFB state is resynchronized if the cipher block size is 8 octets or CFB state is resynchronized if the cipher block size is 8 octets or
less. The last 8 octets of ciphertext are passed through the cipher less. The last 8 octets of ciphertext are passed through the cipher
and the block boundary is reset. and the block boundary is reset.
The repetition of 16 bits in the 80 bits of random data prepended to The repetition of 16 bits in the 80 bits of random data prefixed to
the message allows the receiver to immediately check whether the the message allows the receiver to immediately check whether the
session key is incorrect. session key is incorrect.
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10)
An experimental version of PGP used this packet as the Literal An experimental version of PGP used this packet as the Literal
packet, but no released version of PGP generated Literal packets packet, but no released version of PGP generated Literal packets
with this tag. With PGP 5.x, this packet has been re-assigned and is with this tag. With PGP 5.x, this packet has been re-assigned and is
reserved for use as the Marker packet. reserved for use as the Marker packet.
skipping to change at page 37, line 7 skipping to change at page 37, line 30
specifications of which key holders are trustworthy introducers, specifications of which key holders are trustworthy introducers,
along with other information that implementing software uses for along with other information that implementing software uses for
trust information. trust information.
Trust packets SHOULD NOT be emitted to output streams that are Trust packets SHOULD NOT be emitted to output streams that are
transferred to other users, and they SHOULD be ignored on any input transferred to other users, and they SHOULD be ignored on any input
other than local keyring files. other than local keyring files.
5.11. User ID Packet (Tag 13) 5.11. User ID Packet (Tag 13)
A User ID packet consists of data which is intended to represent the A User ID packet consists of data that is intended to represent the
name and email address of the key holder. By convention, it name and email address of the key holder. By convention, it
includes an RFC822 mail name, but there are no restrictions on its includes an RFC822 mail name, but there are no restrictions on its
content. The packet length in the header specifies the length of content. The packet length in the header specifies the length of
the user id. If it is text, it is encoded in UTF-8. the user id. If it is text, it is encoded in UTF-8.
6. Radix-64 Conversions 6. Radix-64 Conversions
As stated in the introduction, OpenPGP's underlying native As stated in the introduction, OpenPGP's underlying native
representation for objects is a stream of arbitrary octets, and some representation for objects is a stream of arbitrary octets, and some
systems desire these objects to be immune to damage caused by systems desire these objects to be immune to damage caused by
skipping to change at page 39, line 28 skipping to change at page 40, line 5
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
corruption of the ASCII Armor. Unknown keys should be reported to corruption of the ASCII Armor. Unknown keys should be reported to
the user, but OpenPGP should continue to process the message. the user, but OpenPGP should continue to process the message.
Currently defined Armor Header Keys are: Currently defined Armor Header Keys are:
- "Version", which states the OpenPGP Version used to encode the - "Version", that states the OpenPGP Version used to encode the
message. message.
- "Comment", a user-defined comment. - "Comment", a user-defined comment.
- "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 sufficent. cryptographic hash function is sufficient.
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 43, line 40 skipping to change at page 44, line 16
followed by '*' matches a sequence of 0 or more matches of the atom. followed by '*' matches a sequence of 0 or more matches of the atom.
An atom followed by '+' matches a sequence of 1 or more matches of An atom followed by '+' matches a sequence of 1 or more matches of
the atom. An atom followed by '?' matches a match of the atom, or the atom. An atom followed by '?' matches a match of the atom, or
the null string. the null string.
An atom is a regular expression in parentheses (matching a match for An atom is a regular expression in parentheses (matching a match for
the regular expression), a range (see below), '.' (matching any the regular expression), a range (see below), '.' (matching any
single character), '^' (matching the null string at the beginning of single character), '^' (matching the null string at the beginning of
the input string), '$' (matching the null string at the end of the the input string), '$' (matching the null string at the end of the
input string), a '\' followed by a single character (matching that input string), a '\' followed by a single character (matching that
char- acter), or a single character with no other significance character), or a single character with no other significance
(matching that character). (matching that character).
A range is a sequence of characters enclosed in '[]'. It normally A range is a sequence of characters enclosed in '[]'. It normally
matches any single character from the sequence. If the sequence matches any single character from the sequence. If the sequence
begins with '^', it matches any single character not from the rest begins with '^', it matches any single character not from the rest
of the sequence. If two characters in the sequence are separated by of the sequence. If two characters in the sequence are separated by
'-', this is shorthand for the full list of ASCII characters between '-', this is shorthand for the full list of ASCII characters between
them (e.g. '[0-9]' matches any decimal digit). To include a literal them (e.g. '[0-9]' matches any decimal digit). To include a literal
']' in the sequence, make it the first character (following a ']' in the sequence, make it the first character (following a
possible '^'). To include a literal '-', make it the first or last possible '^'). To include a literal '-', make it the first or last
skipping to change at page 45, line 43 skipping to change at page 46, line 19
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
- One or more User ID packets - One or more User ID packets
- After each User ID packet, zero or more Signature packets - After each User ID packet, zero or more signature packets
(certifications)
- Zero or more Subkey packets - Zero or more Subkey packets
- After each Subkey packet, one or more Signature packets - After each Subkey packet, one signature packet, optionally a
revocation.
The Public Key packet occurs first. Each of the following User ID The Public Key packet occurs first. Each of the following User ID
packets provides the identity of the owner of this public key. If packets provides the identity of the owner of this public key. If
there are multiple User ID packets, this corresponds to multiple there are multiple User ID packets, this corresponds to multiple
means of identifying the same unique individual user; for example, a means of identifying the same unique individual user; for example, a
user may have more than one email address, and construct a User ID user may have more than one email address, and construct a User ID
for each one. for each one.
Immediately following each User ID packet, there are zero or more Immediately following each User ID packet, there are zero or more
signature packets. Each signature packet is calculated on the signature packets. Each signature packet is calculated on the
skipping to change at page 46, line 19 skipping to change at page 46, line 48
and user ID. In effect, the signer is testifying to his or her and user ID. In effect, the signer is testifying to his or her
belief that this public key belongs to the user identified by this belief that this public key belongs to the user identified by this
user ID. user ID.
After the User ID packets there may be one or more Subkey packets. After the User ID packets there may be one or more Subkey packets.
In general, subkeys are provided in cases where the top-level public In general, subkeys are provided in cases where the top-level public
key is a signature-only key. However, any V4 key may have subkeys, key is a signature-only key. However, any V4 key may have subkeys,
and the subkeys may be encryption-only keys, signature-only keys, or and the subkeys may be encryption-only keys, signature-only keys, or
general-purpose keys. general-purpose keys.
Each Subkey packet must be followed by at least one Signature Each Subkey packet must be followed by one Signature packet, which
packet, which should be of the subkey binding signature type, issued should be a subkey binding signature issued by the top level key.
by the top level key.
Subkey and Key packets may each be followed by a revocation Subkey and Key packets may each be followed by a revocation
Signature packet to indicate that the key is revoked. Revocation Signature packet to indicate that the key is revoked. Revocation
signatures are only accepted if they are issued by the key itself, signatures are only accepted if they are issued by the key itself,
or by a key which is authorized to issue revocations via a or by a key that is authorized to issue revocations via a revocation
revocation key subpacket in a self-signature by the top level key. key subpacket in a self-signature by the top level key.
Transferable public key packet sequences may be concatenated to Transferable public key packet sequences may be concatenated to
allow transferring multiple public keys in one operation. allow transferring multiple public keys in one operation.
10.2. OpenPGP Messages 10.2. OpenPGP Messages
An OpenPGP message is a packet or sequence of packets that An OpenPGP message is a packet or sequence of packets that
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):
skipping to change at page 47, line 38 skipping to change at page 48, line 14
The format of an OpenPGP V4 key that uses two public keys is similar The format of an OpenPGP V4 key that uses two public keys is similar
except that the other keys are added to the end as 'subkeys' of the except that the other keys are added to the end as 'subkeys' of the
primary key. primary key.
Primary-Key Primary-Key
[Revocation Self Signature] [Revocation Self Signature]
[Direct Key Self Signature...] [Direct Key Self Signature...]
User ID [Signature ...] User ID [Signature ...]
[User ID [Signature ...] ...] [User ID [Signature ...] ...]
[Subkey Primary-Key-Signature ...] [[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...]
A subkey always has a single signature after it that is issued using A subkey always has a single signature after it that is issued using
the primary key to tie the two keys together. The new format can the primary key to tie the two keys together. This binding
use either the new signature packets or the old signature packets. signature may be in either V3 or V4 format, but V4 is prefered, of
course.
In the above diagram, if the binding signature of a subkey has been
revoked, the revoked binding signature may be removed, leaving only
one signature.
In a key that has a main key and subkeys, the primary key MUST be a In a key that has a main key and subkeys, the primary key MUST be a
key capable of signing. The subkeys may be keys of any other type. key capable of signing. The subkeys may be keys of any other type.
There may be other constructions of V4 keys, too. For example, there There may be other constructions of V4 keys, too. For example, there
may be a single-key RSA key in V4 format, a DSA primary key with an may be a single-key RSA key in V4 format, a DSA primary key with an
RSA encryption key, or RSA primary key with an Elgamal subkey, etc. RSA encryption key, or RSA primary key with an Elgamal subkey, etc.
It is also possible to have a signature-only subkey. This permits a It is also possible to have a signature-only subkey. This permits a
primary key that collects certifications (key signatures) but is primary key that collects certifications (key signatures) but is
used only used for certifying subkeys that are used for encryption used only used for certifying subkeys that are used for encryption
skipping to change at page 49, line 4 skipping to change at page 49, line 36
smaller, but still non-zero probability that two different keys have smaller, but still non-zero probability that two different keys have
the same fingerprint. the same fingerprint.
Also note that if V3 and V4 format keys share the same RSA key Also note that if V3 and V4 format keys share the same RSA key
material, they will have different keyids as well as different material, they will have different keyids as well as different
fingerprints. fingerprints.
12. Notes on Algorithms 12. Notes on Algorithms
12.1. Symmetric Algorithm Preferences 12.1. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature, that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have different preferences. For it is possible that a keyholder may have different preferences. For
example, Alice may have TripleDES only specified for example, Alice may have TripleDES only specified for
"alice@work.com" but CAST5, Blowfish, and TripleDES specified for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for
"alice@home.org". Note that it is also possible for preferences to "alice@home.org". Note that it is also possible for preferences to
be in a subkey's binding signature. be in a subkey's binding signature.
Since TripleDES is the MUST-implement algorithm, if it is not Since TripleDES is the MUST-implement algorithm, if it is not
explicitly in the the list, it is tacitly at the end. However, it is explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly. Note also that if an good form to place it there explicitly. Note also that if an
implementation does not implement the preference, then it is implementation does not implement the preference, then it is
implicitly a TripleDES-only implementation. implicitly a TripleDES-only implementation.
An implementation MUST not use a symmetric algorithm that is not in An implementation MUST not use a symmetric algorithm that is not in
the recipent's preference list. When encrypting to more than one the recipient's preference list. When encrypting to more than one
recipient, the implementation finds a suitable algorithm by taking recipient, the implementation finds a suitable algorithm by taking
the intersection of the preferences of the recipients. Note that the the intersection of the preferences of the recipients. Note that the
MUST-implement algorithm, TripleDES, ensures that the intersection MUST-implement algorithm, TripleDES, ensures that the intersection
is not null. The implementation may use any mechanism to pick an is not null. The implementation may use any mechanism to pick an
algorithm in the intersection. algorithm in the intersection.
If an implementation can decrypt a message that a keyholder doesn't If an implementation can decrypt a message that a keyholder doesn't
have in their preferences, the implementation SHOULD decrypt the have in their preferences, the implementation SHOULD decrypt the
message anyway, but MUST warn the keyholder than protocol has been message anyway, but MUST warn the keyholder than protocol has been
violated. (For example, suppose that Alice, above, has software that violated. (For example, suppose that Alice, above, has software that
implements all algorithms in this specification. Nonetheless, she implements all algorithms in this specification. Nonetheless, she
prefers subsets for work or home. If she is sent a message encrypted prefers subsets for work or home. If she is sent a message encrypted
with IDEA, which is not in her preferences, the software warns her with IDEA, which is not in her preferences, the software warns her
that someone sent her an IDEA-encrypted message, but it would that someone sent her an IDEA-encrypted message, but it would
ideally decrypt it anyway.) ideally decrypt it anyway.)
An implementation that is striving for backwards compatibility MAY An implementation that is striving for backward compatibility MAY
consider a V3 key with a V3 self-signature to be an implicit consider a V3 key with a V3 self-signature to be an implicit
preference for IDEA, and no ability to do TripleDES. This is preference for IDEA, and no ability to do TripleDES. This is
technically non-compliant, so if an implementation is forming a technically non-compliant, but an implementation MAY violate the
message to be read by a V3 keyholder and a V4 keyholder that does above rule in this case only and use IDEA to encrypt the message,
not speak IDEA, the implementation must somehow break this up into provided that the message creator is warned. Ideally, though, the
two messages (which is relatively easy to do for email), or issue an implementation would follow the rule by actually generating two
error message when this is not possible. messages, because it is possible that the OpenPGP user's
implementation does not have IDEA, and thus could not read the
message. Consenquently, an implementation MAY, but SHOULD NOT use
IDEA in an algorithm conflict with a V3 key.
12.2. Other Algorithm Preferences 12.2. Other Algorithm Preferences
Other algorithm preferences work similarly to the symmetric Other algorithm preferences work similarly to the symmetric
algorithm preference, in that they specify which algorithms the algorithm preference, in that they specify which algorithms the
keyholder accepts. There are two interesting cases that other keyholder accepts. There are two interesting cases that other
comments need to be made about, though, the compression preferences comments need to be made about, though, the compression preferences
and the hash preferences. and the hash preferences.
12.2.1. Compression Preferences 12.2.1. Compression Preferences
skipping to change at page 50, line 50 skipping to change at page 51, line 36
There are algorithm types for RSA-signature-only, and There are algorithm types for RSA-signature-only, and
RSA-encrypt-only keys. These types are deprecated. The "key flags" RSA-encrypt-only keys. These types are deprecated. The "key flags"
subpacket in a signature is a much better way to express the same subpacket in a signature is a much better way to express the same
idea, and generalizes it to all algorithms. An implementation SHOULD idea, and generalizes it to all algorithms. An implementation SHOULD
NOT create such a key, but MAY interpret it. NOT create such a key, but MAY interpret it.
An implementation SHOULD NOT implement RSA keys of size less than An implementation SHOULD NOT implement RSA keys of size less than
768 bits. 768 bits.
It is permissable for an implementation to support RSA merely for It is permissible for an implementation to support RSA merely for
backwards compatibility; for example, such an implementation would backward compatibility; for example, such an implementation would
support V3 keys with IDEA symmetric cryptography. Note that this is support V3 keys with IDEA symmetric cryptography. Note that this is
an exception to the other MUST-implement rules. An implementation an exception to the other MUST-implement rules. An implementation
that supports RSA in V4 keys MUST implement the MUST-implement that supports RSA in V4 keys MUST implement the MUST-implement
features. features.
12.5. Elgamal 12.5. Elgamal
If an Elgamal key is to be used for both signing and encryption, If an Elgamal key is to be used for both signing and encryption,
extra care must be taken in creating the key. extra care must be taken in creating the key.
skipping to change at page 51, line 53 skipping to change at page 52, line 38
12.6. DSA 12.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
768 bits. Note that present DSA is limited to a maximum of 1024 bit 768 bits. Note that present DSA is limited to a maximum of 1024 bit
keys, which are recommended for long-term use. keys, which are recommended for long-term use.
12.7. OpenPGP CFB mode 12.7. OpenPGP CFB mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback OpenPGP does symmetric encryption using a variant of Cipher Feedback
Mode (CFB mode). This section describes the procedure it uses in Mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Ecrypted Data detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret key material is Packets; the mechanism used for encrypting secret key material is
similar, but described in those sections above. similar, but described in those sections above.
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
and prefixes the plaintext with ten bytes of random data, such that and prefixes the plaintext with ten bytes of random data, such that
bytes 9 and 10 match bytes 7 and 8. It does a CFB "resync" after bytes 9 and 10 match bytes 7 and 8. It does a CFB "resync" after
encrypting those ten bytes. encrypting those ten bytes.
Note that for an algorithm that has a larger block size than 64 Note that for an algorithm that has a larger block size than 64
bits, the equivalent function will be done with that entire block. bits, the equivalent function will be done with that entire block.
skipping to change at page 52, line 29 skipping to change at page 53, line 14
3. FRE is xored with the first 8 bytes of random data prefixed to 3. FRE is xored with the first 8 bytes of random data prefixed to
the plaintext to produce C1-C8, the first 8 bytes of ciphertext. the plaintext to produce C1-C8, the first 8 bytes of ciphertext.
4. FR is loaded with C1-C8. 4. FR is loaded with C1-C8.
5. FR is encrypted to produce FRE, the encryption of the first 8 5. FR is encrypted to produce FRE, the encryption of the first 8
bytes of ciphertext. bytes of ciphertext.
6. The left two bytes of FRE get xored with the next two bytes of 6. The left two bytes of FRE get xored with the next two bytes of
data which were prepended to the plaintext. This produces data that were prefixed to the plaintext. This produces C9-C10,
C9-C10, the next two bytes of ciphertext. the next two bytes of ciphertext.
7. (The resync step) FR is loaded with C3-C10. 7. (The resync step) FR is loaded with C3-C10.
8. FR is encrypted to produce FRE. 8. FR is encrypted to produce FRE.
9. FRE is xored with the first 8 bytes of the given plaintext, now 9. FRE is xored with the first 8 bytes of the given plaintext, now
that we have finished encrypting the 10 bytes of prepended data. that we have finished encrypting the 10 bytes of prefixed data.
This produces C11-C18, the next 8 bytes of ciphertext. This produces C11-C18, the next 8 bytes of ciphertext.
10. FR is loaded with C11-C18 10. FR is loaded with C11-C18
11. FR is encrypted to produce FRE. 11. FR is encrypted to produce FRE.
12. FRE is xored with the next 8 bytes of plaintext, to produce the 12. FRE is xored with the next 8 bytes of plaintext, to produce the
next 8 bytes of ciphertext. These are loaded into FR and the next 8 bytes of ciphertext. These are loaded into FR and the
process is repeated until the plaintext is used up. process is repeated until the plaintext is used up.
skipping to change at page 53, line 38 skipping to change at page 54, line 23
been analyzed less than others. For example, although CAST5 is been analyzed less than others. For example, although CAST5 is
presently considered strong, it has been analyzed less than presently considered strong, it has been analyzed less than
Triple-DES. Other algorithms may have other controversies Triple-DES. Other algorithms may have other controversies
surrounding them. surrounding them.
Some technologies mentioned here may be subject to government Some technologies mentioned here may be subject to government
control in some countries. control in some countries.
14. Implementation Nits 14. Implementation Nits
This section is a collection of comments to help an implementor, This section is a collection of comments to help an implementer,
particularly with an eye to backwards compatibility. Previous particularly with an eye to backward compatibility. Previous
implementations of PGP are not OpenPGP-compliant. Often the implementations of PGP are not OpenPGP-compliant. Often the
differences are small, but small differences are frequently more differences are small, but small differences are frequently more
vexing than large differences. Thus, this list of potential problems vexing than large differences. Thus, this list of potential problems
and gotchas for a developer who is trying to be and gotchas for a developer who is trying to be backward-compatible.
backwards-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 keylength
differs from the the S2K symmetric algorithm. This is a bug in differs from the the S2K symmetric algorithm. This is a bug in
its validation function. its validation function.
skipping to change at page 55, line 19 skipping to change at page 56, line 4
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 4200 Bohannon Drive
Menlo Park, CA 94025, USA Menlo Park, CA 94025, USA
Email: hal@pgp.com Email: hal@pgp.com
Rodney Thayer Rodney Thayer
Sable Technology Corporation EIS Corporation
246 Walnut Street Clearwater, FL 33767
Newton, MA 02160 USA Email: rodney@unitran.com
Email: rodney@sabletech.com
Tel: +1-617-332-7292
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
Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and
Philip R. Zimmermann. Philip R. Zimmermann.
16. References 16. References
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
 End of changes. 

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