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/ |