draft-ietf-openpgp-formats-02.txt | draft-ietf-openpgp-formats-03.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-02.txt | draft-ietf-openpgp-formats-03.txt | |||
Expires Oct 1998 Lutz Donnerhacke | Expires Nov 1998 Lutz Donnerhacke | |||
April 1997 IN-Root-CA Individual Network e.V. | May 1998 IN-Root-CA Individual Network e.V. | |||
Hal Finney | Hal Finney | |||
Network Associates | Network Associates | |||
Rodney Thayer | Rodney Thayer | |||
Sable Technology | Sable Technology | |||
OpenPGP Message Format | OpenPGP Message Format | |||
draft-ietf-openpgp-formats-02.txt | draft-ietf-openpgp-formats-03.txt | |||
Copyright 1998 by The Internet Society. All Rights Reserved. | Copyright 1998 by The Internet Society. All Rights Reserved. | |||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft. Internet-Drafts are working | This document is an Internet-Draft. Internet-Drafts are working | |||
documents of the Internet Engineering Task Force (IETF), its areas, | documents of the Internet Engineering Task Force (IETF), its areas, | |||
and its working groups. Note that other groups may also distribute | and its working groups. Note that other groups may also distribute | |||
working documents as Internet-Drafts. | working documents as Internet-Drafts. | |||
skipping to change at page 2, line 47 | skipping to change at page 2, line 47 | |||
4.2.2.2. Two-Octet Lengths 13 | 4.2.2.2. Two-Octet Lengths 13 | |||
4.2.2.3. Five-Octet Lengths 13 | 4.2.2.3. Five-Octet Lengths 13 | |||
4.2.2.4. Partial Body Lengths 13 | 4.2.2.4. Partial Body Lengths 13 | |||
4.2.3. Packet Length Examples 13 | 4.2.3. Packet Length Examples 13 | |||
4.3. Packet Tags 14 | 4.3. Packet Tags 14 | |||
5. Packet Types 14 | 5. Packet Types 14 | |||
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 14 | 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 14 | |||
5.2. Signature Packet (Tag 2) 16 | 5.2. Signature Packet (Tag 2) 16 | |||
5.2.1. Signature Types 16 | 5.2.1. Signature Types 16 | |||
5.2.2. Version 3 Signature Packet Format 18 | 5.2.2. Version 3 Signature Packet Format 18 | |||
5.2.3. Version 4 Signature Packet Format 19 | 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 21 | 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 22 | 5.2.3.4. Issuer 23 | |||
5.2.3.5. Key expiration time 22 | 5.2.3.5. Key expiration time 23 | |||
5.2.3.6. Preferred symmetric algorithms 22 | 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 23 | |||
5.2.3.10.Exportable 23 | 5.2.3.10.Exportable 24 | |||
5.2.3.11.Revocable 23 | 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 24 | 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 25 | |||
5.2.3.17.Preferred key server 25 | 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.4. Computing Signatures 27 | |||
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 28 | 5.2.4.1. Subpacket Hints 28 | |||
5.4. One-Pass Signature Packets (Tag 4) 29 | 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 29 | |||
5.5. Key Material Packet 29 | 5.4. One-Pass Signature Packets (Tag 4) 30 | |||
5.5.1. Key Packet Variants 29 | 5.5. Key Material Packet 30 | |||
5.5.1.1. Public Key Packet (Tag 6) 29 | 5.5.1. Key Packet Variants 30 | |||
5.5.1.1. Public Key Packet (Tag 6) 30 | ||||
5.5.1.2. Public Subkey Packet (Tag 14) 30 | 5.5.1.2. Public Subkey Packet (Tag 14) 30 | |||
5.5.1.3. Secret Key Packet (Tag 5) 30 | 5.5.1.3. Secret Key Packet (Tag 5) 31 | |||
5.5.1.4. Secret Subkey Packet (Tag 7) 30 | 5.5.1.4. Secret Subkey Packet (Tag 7) 31 | |||
5.5.2. Public Key Packet Formats 30 | 5.5.2. Public Key Packet Formats 31 | |||
5.5.3. Secret Key Packet Formats 32 | 5.5.3. Secret Key Packet Formats 33 | |||
5.6. Compressed Data Packet (Tag 8) 33 | 5.6. Compressed Data Packet (Tag 8) 34 | |||
5.7. Symmetrically Encrypted Data Packet (Tag 9) 34 | 5.7. Symmetrically Encrypted Data Packet (Tag 9) 35 | |||
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 34 | 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 35 | |||
5.9. Literal Data Packet (Tag 11) 35 | 5.9. Literal Data Packet (Tag 11) 36 | |||
5.10. Trust Packet (Tag 12) 35 | 5.10. Trust Packet (Tag 12) 36 | |||
5.11. User ID Packet (Tag 13) 36 | 5.11. User ID Packet (Tag 13) 37 | |||
6. Radix-64 Conversions 36 | 6. Radix-64 Conversions 37 | |||
6.1. An Implementation of the CRC-24 in "C" 36 | 6.1. An Implementation of the CRC-24 in "C" 37 | |||
6.2. Forming ASCII Armor 37 | 6.2. Forming ASCII Armor 38 | |||
6.3. Encoding Binary in Radix-64 39 | 6.3. Encoding Binary in Radix-64 39 | |||
6.4. Decoding Radix-64 40 | 6.4. Decoding Radix-64 41 | |||
6.5. Examples of Radix-64 40 | 6.5. Examples of Radix-64 41 | |||
6.6. Example of an ASCII Armored Message 41 | 6.6. Example of an ASCII Armored Message 42 | |||
7. Cleartext signature framework 41 | 7. Cleartext signature framework 42 | |||
7.1. Dash-Escaped Text 42 | 7.1. Dash-Escaped Text 42 | |||
8. Regular Expressions 42 | 8. Regular Expressions 43 | |||
9. Constants 43 | 9. Constants 43 | |||
9.1. Public Key Algorithms 43 | 9.1. Public Key Algorithms 44 | |||
9.2. Symmetric Key Algorithms 43 | 9.2. Symmetric Key Algorithms 44 | |||
9.3. Compression Algorithms 44 | 9.3. Compression Algorithms 44 | |||
9.4. Hash Algorithms 44 | 9.4. Hash Algorithms 45 | |||
10. Packet Composition 44 | 10. Packet Composition 45 | |||
10.1. Transferable Public Keys 44 | 10.1. Transferable Public Keys 45 | |||
10.2. OpenPGP Messages 45 | 10.2. OpenPGP Messages 46 | |||
11. Enhanced Key Formats 46 | 11. Enhanced Key Formats 47 | |||
11.1. Key Structures 46 | 11.1. Key Structures 47 | |||
11.2. Key IDs and Fingerprints 47 | 11.2. Key IDs and Fingerprints 48 | |||
12. Notes on Algorithms 48 | 12. Notes on Algorithms 48 | |||
12.1. Symmetric Algorithm Preferences 48 | 12.1. Symmetric Algorithm Preferences 48 | |||
12.2. Other Algorithm Preferences 48 | 12.2. Other Algorithm Preferences 49 | |||
12.2.1. Compression Preferences 49 | 12.2.1. Compression Preferences 49 | |||
12.2.2. Hash Algorithm Preferences 49 | 12.2.2. Hash Algorithm Preferences 50 | |||
12.3. Plaintext 49 | 12.3. Plaintext 50 | |||
12.4. RSA 49 | 12.4. RSA 50 | |||
12.5. Elgamal 49 | 12.5. Elgamal 51 | |||
12.6. DSA 50 | 12.6. DSA 51 | |||
12.7. OpenPGP CFB mode 50 | 12.7. OpenPGP CFB mode 51 | |||
13. Security Considerations 51 | 13. Security Considerations 52 | |||
14. Authors and Working Group Chair 52 | 14. Implementation Nits 53 | |||
15. References 53 | 15. Authors and Working Group Chair 54 | |||
16. Full Copyright Statement 54 | 16. References 55 | |||
17. Full Copyright Statement 56 | ||||
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 | key management and 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 | |||
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. In general, an implementation | extends until the end of the file. With a compressed packet, the | |||
should not use indeterminate length packets except where the end | algorithm implicitly denotes how the end of the packet. In | |||
of the data will be clear from the context. The new format | general, an implementation SHOULD NOT use indeterminate length | |||
headers described below have a mechanism for precisely encoding | packets except where the end of the data will be clear from the | |||
data of indeterminite length. | context, and even then it is better to use a definite length, or | |||
a new-format header. The new-format headers described below have | ||||
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 42 | skipping to change at page 13, line 45 | |||
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 << (length_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 | |||
follows that portion. The last length header in the packet must not | -- one octet, two-octet, or partial) follows that portion. The last | |||
be a partial Body Length header. Partial Body Length headers may | length header in the packet MUST NOT be a partial Body Length | |||
only be used for the non-final parts of the packet. | header. Partial Body Length headers may only be used for the | |||
non-final parts of the packet. | ||||
4.2.3. Packet Length Examples | 4.2.3. Packet Length Examples | |||
A packet with length 100 may have its length encoded in one octet: | A packet with length 100 may have its length encoded in one octet: | |||
0x64. This is followed by 100 octets of data. | 0x64. This is followed by 100 octets of data. | |||
A packet with length 1723 may have its length coded in two octets: | A packet with length 1723 may have its length coded in two octets: | |||
0xC5, 0xFB. This header is followed by the 1723 octets of data. | 0xC5, 0xFB. This header is followed by the 1723 octets of data. | |||
A packet with length 100000 may have its length encoded in five | A packet with length 100000 may have its length encoded in five | |||
octets: 0xFF, 0x01, 0x86, 0xA0. | octets: 0xFF, 0x00, 0x01, 0x86, 0xA0. | |||
It might also be encoded in the following octet stream: 0xE1, first | It might also be encoded in the following octet stream: 0xEF, first | |||
two octets of data, 0xE0, next one octet of data, 0xEF, next 32768 | 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one | |||
octets of data, 0xF0, next 65536 octets of data, 0xC5, 0xDD, last | octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last | |||
1693 octets of data. This is just one possible encoding, and many | 1693 octets of data. This is just one possible encoding, and many | |||
variations are possible on the size of the Partial Body Length | variations are possible on the size of the Partial Body Length | |||
headers, as long as a regular Body Length header encodes the last | headers, as long as a regular Body Length header encodes the last | |||
portion of the data. Note also that the last Body Length header can | portion of the data. Note also that the last Body Length header can | |||
be a zero-length header. | be a zero-length header. | |||
An implementation MUST only use Partial Body Lengths for data | An implementation MAY use Partial Body Lengths for data packets, be | |||
packets, be they literal, compressed, or encrypted. The first | they literal, compressed, or encrypted. The first partial length | |||
partial length MUST be at least 512 octets long. | MUST be at least 512 octets long. Partial Body Lengths MAY NOT be | |||
used for any other packet types. | ||||
Please note that in all of these explanations, the total length of | Please note that in all of these explanations, the total length of | |||
the packet is the length of the header(s) plus the length of the | the packet is the length of the header(s) plus the length of the | |||
body. | body. | |||
4.3. Packet Tags | 4.3. Packet Tags | |||
The packet tag denotes what type of packet the body holds. Note that | The packet tag denotes what type of packet the body holds. Note that | |||
old format headers can only have tags less than 16, whereas new | old format headers can only have tags less than 16, whereas new | |||
format headers can have tags as great as 63. The defined tags (in | format headers can have tags as great as 63. The defined tags (in | |||
skipping to change at page 19, line 23 | skipping to change at page 19, line 27 | |||
- MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 | - MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 | |||
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 | - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 | |||
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 | - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 | |||
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A | - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A | |||
The ASN.1 OIDs are: | The ASN.1 OIDs are: | |||
- MD5: 1.2.840.113549.2.2 | - MD2: 1.2.840.113549.2.2 | |||
- MD5: 1.2.840.113549.2.5 | - MD5: 1.2.840.113549.2.5 | |||
- RIPEMD160: 1.3.36.3.2.1 | - RIPEMD-160: 1.3.36.3.2.1 | |||
- SHA-1: 1.3.14.3.2.26 | - SHA-1: 1.3.14.3.2.26 | |||
The full hash prefixes for these are: | ||||
MD2: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, | ||||
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02, 0x05, 0x00, | ||||
0x04, 0x10 | ||||
MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, | ||||
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, | ||||
0x04, 0x10 | ||||
RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, | ||||
0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 | ||||
SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, | ||||
0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 | ||||
DSA signatures SHOULD use hashes with a size of 160 bits, to match | DSA signatures SHOULD use hashes with a size of 160 bits, to match | |||
q, the size of the group generated by the DSA key's generator value. | q, the size of the group generated by the DSA key's generator value. | |||
The hash function result is treated as a 160 bit number and used | The hash function result is treated as a 160 bit number and used | |||
directly in the DSA signature algorithm. | directly in the DSA signature algorithm. | |||
5.2.3. Version 4 Signature Packet Format | 5.2.3. Version 4 Signature Packet Format | |||
The body of a version 4 Signature Packet contains: | The body of a version 4 Signature Packet contains: | |||
- One-octet version number (4). | - One-octet version number (4). | |||
skipping to change at page 27, line 45 | skipping to change at page 28, line 16 | |||
octet 0x99, followed by a two-octet length of the key, and then body | octet 0x99, followed by a two-octet length of the key, and then body | |||
of the key packet. (Note that this is an old-style packet header for | of the key packet. (Note that this is an old-style packet header for | |||
a key packet with two-octet length.) A subkey signature (type 0x18) | a key packet with two-octet length.) A subkey signature (type 0x18) | |||
then hashes the subkey, using the same format as the main key. Key | then hashes the subkey, using the same format as the main key. Key | |||
revocation signatures (types 0x20 and 0x28) hash only the key being | revocation signatures (types 0x20 and 0x28) hash only the key being | |||
revoked. | revoked. | |||
A certification signature (type 0x10 through 0x13) hashes the user | A certification signature (type 0x10 through 0x13) hashes the user | |||
id being bound to the key into the hash context after the above | id being bound to the key into the hash context after the above | |||
data. A V3 certification hashes the contents of the name packet, | data. A V3 certification hashes the contents of the name packet, | |||
without any header. A V4 certification hashes the constant 0xd4 | without any header. A V4 certification hashes the constant 0xb4 | |||
(which is an old-style packet header with the length-of-length set | (which is an old-style packet header with the length-of-length set | |||
to zero), a four-octet number giving the length of the username, and | to zero), a four-octet number giving the length of the username, and | |||
then the username data. | then the username data. | |||
Once the data body is hashed, then a trailer is hashed. A V3 | Once the data body is hashed, then a trailer is hashed. A V3 | |||
signature hashes five octets of the packet body, starting from the | signature hashes five octets of the packet body, starting from the | |||
signature type field. This data is the signature type, followed by | signature type field. This data is the signature type, followed by | |||
the four-octet signature time. A V4 signature hashes the packet body | the four-octet signature time. A V4 signature hashes the packet body | |||
starting from its first field, the version number, through the end | starting from its first field, the version number, through the end | |||
of the hashed subpacket data. Thus, the fields hashed are the | of the hashed subpacket data. Thus, the fields hashed are the | |||
skipping to change at page 28, line 18 | skipping to change at page 28, line 41 | |||
V4 signatures also hash in a final trailer of six octets: the | V4 signatures also hash in a final trailer of six octets: the | |||
version of the signature packet, i.e. 0x04; 0xFF; a four-octet, | version of the signature packet, i.e. 0x04; 0xFF; a four-octet, | |||
big-endian number that is the length of the hashed data from the | big-endian number that is the length of the hashed data from the | |||
signature packet (note that this number does not include these final | signature packet (note that this number does not include these final | |||
six octets. | six octets. | |||
After all this has been hashed, the resulting hash field is used in | After all this has been hashed, 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 | ||||
An implementation SHOULD put the two mandatory subpackets, creation | ||||
time and issuer, as the first subpackets in the subpacket list, | ||||
simply to make it easier for the implementor to find them. | ||||
It is certainly possible for a signature to contain conflicting | ||||
information in subpackets. For example, a signature may contain | ||||
multiple copies of a preference or multiple expiration times. In | ||||
most cases, an implementation SHOULD use the last subpacket in the | ||||
signature, but MAY use any conflict resolution scheme that makes | ||||
more sense. Please note that we are intentionally leaving conflict | ||||
resolution to the implementor; most conflicts are simply syntax | ||||
errors, and the wishy-washy language here allows a receiver to be | ||||
generous in what they accept, while putting pressure on a creator to | ||||
be stingy in what they generate. | ||||
Some apparent conflicts may actually make sense -- for example, | ||||
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 | ||||
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 | ||||
tying those keys to the signature. | ||||
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) | 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) | |||
The Symmetric-Key Encrypted Session Key packet holds the | The Symmetric-Key Encrypted Session Key packet holds the | |||
symmetric-key encryption of a session key used to encrypt a message. | symmetric-key encryption of a session key used to encrypt a message. | |||
Zero or more Encrypted Session Key packets and/or Symmetric-Key | Zero or more Encrypted Session Key packets and/or Symmetric-Key | |||
Encrypted Session Key packets may precede a Symmetrically Encrypted | Encrypted Session Key packets may precede a Symmetrically Encrypted | |||
Data Packet that holds an encrypted message. The message is | Data Packet that holds an encrypted message. The message is | |||
encrypted with a session key, and the session key is itself | encrypted with a session key, and the session key is itself | |||
encrypted and stored in the Encrypted Session Key packet or the | encrypted and stored in the Encrypted Session Key packet or the | |||
Symmetric-Key Encrypted Session Key packet. | Symmetric-Key Encrypted Session Key packet. | |||
skipping to change at page 34, line 18 | skipping to change at page 35, line 10 | |||
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, it cannot be | |||
decompressed by PGP V2.6 | decompressed by PGP V2.6 | |||
ZLIB-compressed packets are compressed with RFC1950 ZLIB-style | ||||
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 | |||
skipping to change at page 35, line 8 | skipping to change at page 36, line 5 | |||
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. | |||
The body of this packet consists of: | The body of this packet consists of: | |||
- The three octets 0x60, 0x47, 0x60 (which spell "PGP" in UTF-8). | - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). | |||
Such a packet MUST be ignored when received. It may be placed at | Such a packet MUST be ignored when received. It may be placed at | |||
the beginning of a message that uses features not available in PGP | the beginning of a message that uses features not available in PGP | |||
2.6.x in order to cause that version to report that newer software | 2.6.x in order to cause that version to report that newer software | |||
is necessary to process the message. | is necessary to process the message. | |||
5.9. Literal Data Packet (Tag 11) | 5.9. Literal Data Packet (Tag 11) | |||
A Literal Data packet contains the body of a message; data that is | A Literal Data packet contains the body of a message; data that is | |||
not to be further interpreted. | not to be further interpreted. | |||
skipping to change at page 41, line 16 | skipping to change at page 42, line 8 | |||
8-bit: 00010100 11111011 10011100 | 00000011 | 8-bit: 00010100 11111011 10011100 | 00000011 | |||
pad with 0000 | pad with 0000 | |||
6-bit: 000101 001111 101110 011100 | 000000 110000 | 6-bit: 000101 001111 101110 011100 | 000000 110000 | |||
Decimal: 5 15 46 28 0 48 | Decimal: 5 15 46 28 0 48 | |||
pad with = = | pad with = = | |||
Output: F P u c A w = = | Output: F P u c A w = = | |||
6.6. Example of an ASCII Armored Message | 6.6. Example of an ASCII Armored Message | |||
-----BEGIN PGP MESSAGE----- | -----BEGIN PGP MESSAGE----- | |||
Version: OpenPGP 1.0 | Version: OpenPrivacy 0.99 | |||
yCoBc07MUy9RSMyrzM9LVchOTS1QSFQoTk0uSgUKFuWX5qUoZKQWpdpzAQA= | yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS | |||
=jYsF | vBSFjNSiVHsuAA== | |||
=njUN | ||||
-----END PGP MESSAGE----- | -----END PGP MESSAGE----- | |||
Note that this example is indented by two spaces. | Note that this example is indented by two spaces. | |||
7. Cleartext signature framework | 7. Cleartext signature framework | |||
It is desirable to sign a textual octet stream without ASCII | It is desirable to sign a textual octet stream without ASCII | |||
armoring the stream itself, so the signed text is still readable | armoring the stream itself, so the signed text is still readable | |||
without special software. In order to bind a signature to such a | without special software. In order to bind a signature to such a | |||
cleartext, this framework is used. (Note that RFC 2015 defines | cleartext, this framework is used. (Note that RFC 2015 defines | |||
skipping to change at page 44, line 10 | skipping to change at page 44, line 53 | |||
Implementations MUST implement Triple-DES. Implementations SHOULD | Implementations MUST implement Triple-DES. Implementations SHOULD | |||
implement IDEA and CAST5.Implementations MAY implement any other | implement IDEA and CAST5.Implementations MAY implement any other | |||
algorithm. | algorithm. | |||
9.3. Compression Algorithms | 9.3. Compression Algorithms | |||
ID Algorithm | ID Algorithm | |||
-- --------- | -- --------- | |||
0 - Uncompressed | 0 - Uncompressed | |||
1 - ZIP | 1 - ZIP (RFC1951) | |||
2 - ZLIB (RFC1950) | ||||
100 to 110 - Private/Experimental algorithm. | 100 to 110 - Private/Experimental algorithm. | |||
Implementations MUST implement uncompressed data. Implementations | Implementations MUST implement uncompressed data. Implementations | |||
SHOULD implement ZIP. | SHOULD implement ZIP. | |||
9.4. Hash Algorithms | 9.4. Hash Algorithms | |||
ID Algorithm Text Name | ID Algorithm Text Name | |||
-- --------- ---- ---- | -- --------- ---- ---- | |||
1 - MD5 "MD5" | 1 - MD5 "MD5" | |||
2 - SHA-1 "SHA1" | 2 - SHA-1 "SHA1" | |||
3 - RIPE-MD/160 "RIPEMD160" | 3 - RIPE-MD/160 "RIPEMD160" | |||
4 - HAVAL (5 pass, 160-bit) "HAVAL-5-160" | 4 - HAVAL (5 pass, 160-bit) "HAVAL-5-160" | |||
5 - MD2 "MD2" | 5 - MD2 "MD2" | |||
6 - TIGER/192 "TIGER192" | ||||
100 to 110 - Private/Experimental algorithm. | 100 to 110 - Private/Experimental algorithm. | |||
Implementations MUST implement SHA-1. Implementations SHOULD | Implementations MUST implement SHA-1. Implementations SHOULD | |||
implement MD5. | implement MD5. | |||
10. Packet Composition | 10. Packet Composition | |||
OpenPGP packets are assembled into sequences in order to create | OpenPGP packets are assembled into sequences in order to create | |||
messages | messages | |||
skipping to change at page 49, line 8 | skipping to change at page 50, line 4 | |||
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 | |||
Compression has been an integral part of PGP since its first days. | Compression has been an integral part of PGP since its first days. | |||
OpenPGP and all previous versions of PGP have offered compression. | OpenPGP and all previous versions of PGP have offered compression. | |||
And in this specification, the default is for messages to be | And in this specification, the default is for messages to be | |||
compressed, although an implementation is not required to do so. | compressed, although an implementation is not required to do so. | |||
Consequently, the compression preference gives a way for a keyholder | Consequently, the compression preference gives a way for a keyholder | |||
to request that messages not be compressed, presumably because they | to request that messages not be compressed, presumably because they | |||
are using a minimal implementation that does not include | are using a minimal implementation that does not include | |||
compression. | compression. Additionally, this gives a keyholder a way to state | |||
that it can support alternate algorithms. | ||||
Like the algorithm preferences, an implementation MUST NOT use an | ||||
algorithm that is not in the preference vector. If the preferences | ||||
are mot present, then they are assumed to be [ZIP(1), | ||||
UNCOMPRESSED(0)]. | ||||
12.2.2. Hash Algorithm Preferences | 12.2.2. Hash Algorithm Preferences | |||
Typically, the choice of a hash algorithm is something the signer | Typically, the choice of a hash algorithm is something the signer | |||
does, rather than the verifier, because a signer does not typically | does, rather than the verifier, because a signer does not typically | |||
know who is going to be verifying the signature. This preference, | know who is going to be verifying the signature. This preference, | |||
though, allows a protocol based upon digital signatures ease in | though, allows a protocol based upon digital signatures ease in | |||
negotiation. | negotiation. | |||
Thus, if Alice is authenticating herself to Bob with a signature, it | Thus, if Alice is authenticating herself to Bob with a signature, it | |||
skipping to change at page 50, line 49 | skipping to change at page 51, line 53 | |||
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. | detail. This mode is what is used for Symmetrically Ecrypted Data | |||
Packets; the mechanism used for encrypting secret key material is | ||||
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. | |||
Step by step, here is the procedure: | Step by step, here is the procedure: | |||
skipping to change at page 52, line 32 | skipping to change at page 53, line 36 | |||
Some of the encryption algorithms mentioned in this document have | Some of the encryption algorithms mentioned in this document have | |||
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. Authors and Working Group Chair | 14. Implementation Nits | |||
This section is a collection of comments to help an implementor, | ||||
particularly with an eye to backwards compatibility. Previous | ||||
implementations of PGP are not OpenPGP-compliant. Often the | ||||
differences are small, but small differences are frequently more | ||||
vexing than large differences. Thus, this list of potential problems | ||||
and gotchas for a developer who is trying to be | ||||
backwards-compatible. | ||||
* PGP 5.x does not accept V4 signatures for anything other than | ||||
key material. | ||||
* PGP 5.x does not recognize the "five-octet" lengths in | ||||
new-format headers or in signature subpacket lengths. | ||||
* PGP 5.0 rejects an encrypted session key if the keylength | ||||
differs from the the S2K symmetric algorithm. This is a bug in | ||||
its validation function. | ||||
* PGP 5.0 does not handle multiple one-pass signature headers and | ||||
trailers. Signing one will compress the one-pass signed literal | ||||
and prefix a V3 signature instead of doing a nested one-pass | ||||
signature. | ||||
* When exporting a private key, PGP 2.x generates the header | ||||
"BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY | ||||
BLOCK". All previous versions ignore the implied data type, and | ||||
look directly at the packet data type. | ||||
* In a clear-signed signature, PGP 5.0 will figure out the correct | ||||
hash algorithm if there is no "Hash:" header, but it will reject | ||||
a mismatch between the header and the actual agorithm used. The | ||||
"standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x | ||||
rejects the "Hash:" header and assumes MD5. There are a number | ||||
of enhanced variants of PGP 2.6.x that have been modified for | ||||
SHA-1 signatures. | ||||
* PGP 5.0 can read an RSA key in V4 format, but will only | ||||
recognize it using V3 format. | ||||
* There are many ways possible for for two keys to have the same | ||||
key material, but different fingerprints (and thus key ids). | ||||
Perhaps the most interesting is an RSA key that has been | ||||
"upgraded" to V4 format, but since a V4 fingerprint is | ||||
constructed by hashing the key creation time along with other | ||||
things, two V4 keys created at different times, yet with the | ||||
same key material will have different fingerprints. | ||||
* PGP 2.6.x and PGP 5.0 sometimes add to the beginning of a file a | ||||
zero-length compressed data packet. | ||||
* If an implemtation is using zlib to interoperate with PGP 2.x, | ||||
then the "windowBits" parameter should be set to -13. | ||||
15. Authors and Working Group Chair | ||||
The working group can be contacted via the current chair: | The working group can be contacted via the current chair: | |||
John W. Noerenberg, II | John W. Noerenberg, II | |||
Qualcomm, Inc | Qualcomm, Inc | |||
6455 Lusk Blvd | 6455 Lusk Blvd | |||
San Diego, CA 92131 USA | San Diego, CA 92131 USA | |||
Email: jwn2@qualcomm.com | Email: jwn2@qualcomm.com | |||
Tel: +1 619-658-3510 | Tel: +1 619-658-3510 | |||
skipping to change at page 53, line 25 | skipping to change at page 55, line 33 | |||
Newton, MA 02160 USA | Newton, MA 02160 USA | |||
Email: rodney@sabletech.com | Email: rodney@sabletech.com | |||
Tel: +1-617-332-7292 | 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. | |||
15. References | 16. References | |||
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal | [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal | |||
signatures without knowing the secret key," Eurocrypt 96. Note that | signatures without knowing the secret key," Eurocrypt 96. Note that | |||
the version in the proceedings has an error. A revised version is | the version in the proceedings has an error. A revised version is | |||
available at the time of writing from | available at the time of writing from | |||
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps> | <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps> | |||
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved | [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved | |||
international version of PGP", | international version of PGP", | |||
ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/ | ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/ | |||
skipping to change at page 54, line 35 | skipping to change at page 56, line 45 | |||
[RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and | [RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and | |||
ISO 10646. October 1996. | ISO 10646. October 1996. | |||
[RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail | [RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail | |||
Extensions (MIME) Part One: Format of Internet Message Bodies.", | Extensions (MIME) Part One: Format of Internet Message Bodies.", | |||
November 1996 | November 1996 | |||
[RFC2119] Bradner, S., Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., Key words for use in RFCs to Indicate | |||
Requirement Level. March 1997. | Requirement Level. March 1997. | |||
16. Full Copyright Statement | 17. Full Copyright Statement | |||
Copyright 1998 by The Internet Society. All Rights Reserved. | Copyright 1998 by The Internet Society. All Rights Reserved. | |||
This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
kind, provided that the above copyright notice and this paragraph | kind, provided that the above copyright notice and this paragraph | |||
are included on all such copies and derivative works. However, this | are included on all such copies and derivative works. However, this | |||
document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |