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/