draft-ietf-openpgp-rfc2440bis-07.txt   draft-ietf-openpgp-rfc2440bis-08.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT PGP Corporation Category: INTERNET-DRAFT PGP Corporation
draft-ietf-openpgp-rfc2440bis-07.txt draft-ietf-openpgp-rfc2440bis-08.txt
Expires Sep 2003 Lutz Donnerhacke Expires Sep 2003 Lutz Donnerhacke
March 2003 IN-Root-CA Individual Network e.V. March 2003 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-07.txt draft-ietf-openpgp-rfc2440bis-08.txt
Copyright 2003 by The Internet Society. All Rights Reserved. Copyright 2003 by The Internet Society. All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 3, line 51 skipping to change at page 3, line 51
4.2.2.3. Five-Octet Lengths 15 4.2.2.3. Five-Octet Lengths 15
4.2.2.4. Partial Body Lengths 15 4.2.2.4. Partial Body Lengths 15
4.2.3. Packet Length Examples 16 4.2.3. Packet Length Examples 16
4.3. Packet Tags 16 4.3. Packet Tags 16
5. Packet Types 17 5. Packet Types 17
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 17
5.2. Signature Packet (Tag 2) 18 5.2. Signature Packet (Tag 2) 18
5.2.1. Signature Types 18 5.2.1. Signature Types 18
5.2.2. Version 3 Signature Packet Format 20 5.2.2. Version 3 Signature Packet Format 20
5.2.3. Version 4 Signature Packet Format 23 5.2.3. Version 4 Signature Packet Format 23
5.2.3.1. Signature Subpacket Specification 24 5.2.3.1. Signature Subpacket Specification 23
5.2.3.2. Signature Subpacket Types 25 5.2.3.2. Signature Subpacket Types 25
5.2.3.3. Notes on Self-Signatures 25 5.2.3.3. Notes on Self-Signatures 25
5.2.3.4. Signature creation time 26 5.2.3.4. Signature creation time 26
5.2.3.5. Issuer 26 5.2.3.5. Issuer 26
5.2.3.6. Key expiration time 27 5.2.3.6. Key expiration time 26
5.2.3.7. Preferred symmetric algorithms 27 5.2.3.7. Preferred symmetric algorithms 27
5.2.3.8. Preferred hash algorithms 27 5.2.3.8. Preferred hash algorithms 27
5.2.3.9. Preferred compression algorithms 27 5.2.3.9. Preferred compression algorithms 27
5.2.3.10.Signature expiration time 27 5.2.3.10.Signature expiration time 27
5.2.3.11.Exportable Certification 27 5.2.3.11.Exportable Certification 27
5.2.3.12.Revocable 28 5.2.3.12.Revocable 28
5.2.3.13.Trust signature 28 5.2.3.13.Trust signature 28
5.2.3.14.Regular expression 29 5.2.3.14.Regular expression 28
5.2.3.15.Revocation key 29 5.2.3.15.Revocation key 29
5.2.3.16.Notation Data 29 5.2.3.16.Notation Data 29
5.2.3.17.Key server preferences 30 5.2.3.17.Key server preferences 30
5.2.3.18.Preferred key server 30 5.2.3.18.Preferred key server 30
5.2.3.19.Primary user id 30 5.2.3.19.Primary User ID 30
5.2.3.20.Policy URL 31 5.2.3.20.Policy URL 31
5.2.3.21.Key Flags 31 5.2.3.21.Key Flags 31
5.2.3.22.Signer's User ID 32 5.2.3.22.Signer's User ID 32
5.2.3.23.Reason for Revocation 32 5.2.3.23.Reason for Revocation 32
5.2.3.24.Features 33 5.2.3.24.Features 33
5.2.3.25.Signature Target 33 5.2.3.25.Signature Target 33
5.2.4. Computing Signatures 34 5.2.4. Computing Signatures 34
5.2.4.1. Subpacket Hints 35 5.2.4.1. Subpacket Hints 35
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 35 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 35
5.4. One-Pass Signature Packets (Tag 4) 36 5.4. One-Pass Signature Packets (Tag 4) 36
5.5. Key Material Packet 37 5.5. Key Material Packet 37
5.5.1. Key Packet Variants 37 5.5.1. Key Packet Variants 37
5.5.1.1. Public Key Packet (Tag 6) 37 5.5.1.1. Public Key Packet (Tag 6) 37
5.5.1.2. Public Subkey Packet (Tag 14) 37 5.5.1.2. Public Subkey Packet (Tag 14) 37
5.5.1.3. Secret Key Packet (Tag 5) 37 5.5.1.3. Secret Key Packet (Tag 5) 37
5.5.1.4. Secret Subkey Packet (Tag 7) 37 5.5.1.4. Secret Subkey Packet (Tag 7) 37
5.5.2. Public Key Packet Formats 38 5.5.2. Public Key Packet Formats 37
5.5.3. Secret Key Packet Formats 39 5.5.3. Secret Key Packet Formats 39
5.6. Compressed Data Packet (Tag 8) 41 5.6. Compressed Data Packet (Tag 8) 41
5.7. Symmetrically Encrypted Data Packet (Tag 9) 41 5.7. Symmetrically Encrypted Data Packet (Tag 9) 41
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 42 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 42
5.9. Literal Data Packet (Tag 11) 43 5.9. Literal Data Packet (Tag 11) 42
5.10. Trust Packet (Tag 12) 43 5.10. Trust Packet (Tag 12) 43
5.11. User ID Packet (Tag 13) 43 5.11. User ID Packet (Tag 13) 43
5.12. User Attribute Packet (Tag 17) 44 5.12. User Attribute Packet (Tag 17) 43
5.12.1. The Image Attribute Subpacket 44 5.12.1. The Image Attribute Subpacket 44
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 45
5.14. Modification Detection Code Packet (Tag 19) 47 5.14. Modification Detection Code Packet (Tag 19) 46
6. Radix-64 Conversions 47 6. Radix-64 Conversions 47
6.1. An Implementation of the CRC-24 in "C" 48 6.1. An Implementation of the CRC-24 in "C" 48
6.2. Forming ASCII Armor 48 6.2. Forming ASCII Armor 48
6.3. Encoding Binary in Radix-64 51 6.3. Encoding Binary in Radix-64 50
6.4. Decoding Radix-64 52 6.4. Decoding Radix-64 52
6.5. Examples of Radix-64 52 6.5. Examples of Radix-64 52
6.6. Example of an ASCII Armored Message 53 6.6. Example of an ASCII Armored Message 52
7. Cleartext signature framework 53 7. Cleartext signature framework 53
7.1. Dash-Escaped Text 54 7.1. Dash-Escaped Text 53
8. Regular Expressions 54 8. Regular Expressions 54
9. Constants 55 9. Constants 55
9.1. Public Key Algorithms 55 9.1. Public Key Algorithms 55
9.2. Symmetric Key Algorithms 55 9.2. Symmetric Key Algorithms 55
9.3. Compression Algorithms 56 9.3. Compression Algorithms 56
9.4. Hash Algorithms 56 9.4. Hash Algorithms 56
10. Packet Composition 56 10. Packet Composition 56
10.1. Transferable Public Keys 56 10.1. Transferable Public Keys 56
10.2. OpenPGP Messages 58 10.2. OpenPGP Messages 58
10.3. Detached Signatures 58 10.3. Detached Signatures 58
11. Enhanced Key Formats 59 11. Enhanced Key Formats 58
11.1. Key Structures 59 11.1. Key Structures 58
11.2. Key IDs and Fingerprints 60 11.2. Key IDs and Fingerprints 59
12. Notes on Algorithms 61 12. Notes on Algorithms 60
12.1. Symmetric Algorithm Preferences 61 12.1. Symmetric Algorithm Preferences 60
12.2. Other Algorithm Preferences 61 12.2. Other Algorithm Preferences 61
12.2.1. Compression Preferences 62 12.2.1. Compression Preferences 61
12.2.2. Hash Algorithm Preferences 62 12.2.2. Hash Algorithm Preferences 62
12.3. Plaintext 62 12.3. Plaintext 62
12.4. RSA 63 12.4. RSA 62
12.5. Elgamal 63 12.5. Elgamal 63
12.6. DSA 64 12.6. DSA 64
12.7. Reserved Algorithm Numbers 64 12.7. Reserved Algorithm Numbers 64
12.8. OpenPGP CFB mode 64 12.8. OpenPGP CFB mode 64
13. Security Considerations 65 13. Security Considerations 65
14. Implementation Nits 67 14. Implementation Nits 67
15. Authors and Working Group Chair 69 15. Authors and Working Group Chair 68
16. References 70 16. References 69
17. Full Copyright Statement 72 17. References (Non-Normative) 70
18. Full Copyright Statement 71
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC2440, "OpenPGP and key management functions. It is a revision of RFC2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats." Exchange Formats."
1.1. Terms 1.1. Terms
skipping to change at page 16, line 6 skipping to change at page 16, line 6
partialBodyLen = 1 << (1st_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.
It might also be encoded in the following octet stream: 0xEF, first
32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last
1693 octets of data. This is just one possible encoding, and many
variations are possible on the size of the Partial Body Length
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 be a zero-length
header.
4.2.3. Packet Length Examples 4.2.3. Packet Length Examples
These examples show ways that new-format packets might encode the These examples show ways that new-format packets might encode the
packet lengths. packet lengths.
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, 0x00, 0x01, 0x86, 0xA0. octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.
It might also be encoded in the following octet stream: 0xEF, first
32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last
1693 octets of data. This is just one possible encoding, and many
variations are possible on the size of the Partial Body Length
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
be a zero-length header.
An implementation MAY use Partial Body Lengths for data packets, be An implementation MAY use Partial Body Lengths for data packets, be
they literal, compressed, or encrypted. The first partial length they literal, compressed, or encrypted. The first partial length
MUST be at least 512 octets long. Partial Body Lengths MUST NOT be MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
used for any other packet types. 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
skipping to change at page 18, line 31 skipping to change at page 18, line 33
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
some data. The most common signatures are a signature of a file or a some data. The most common signatures are a signature of a file or a
block of text, and a signature that is a certification of a user ID. block of text, and a signature that is a certification of a User ID.
Two versions of signature packets are defined. Version 3 provides Two versions of signature packets are defined. Version 3 provides
basic signature information, while version 4 provides an expandable basic signature information, while version 4 provides an expandable
format with subpackets that can specify more information about the format with subpackets that can specify more information about the
signature. PGP 2.6.x only accepts version 3 signatures. signature. PGP 2.6.x only accepts version 3 signatures.
Implementations MUST accept V3 signatures. Implementations SHOULD Implementations SHOULD accept V3 signatures. Implementations SHOULD
generate V4 signatures. Implementations MAY generate a V3 signature generate V4 signatures. Implementations MAY generate a V3 signature
that can be verified by PGP 2.6.x. that can be verified by PGP 2.6.x.
Note that if an implementation is creating an encrypted and signed Note that if an implementation is creating an encrypted and signed
message that is encrypted to a V3 key, it is reasonable to create a message that is encrypted to a V3 key, it is reasonable to create a
V3 signature. V3 signature.
5.2.1. Signature Types 5.2.1. Signature Types
There are a number of possible meanings for a signature, which are There are a number of possible meanings for a signature, which are
skipping to change at page 19, line 20 skipping to change at page 19, line 20
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.
The issuer of this certification does not make any particular The issuer of this certification does not make any particular
assertion as to how well the certifier has checked that the assertion as to how well the certifier has checked that the
owner of the key is in fact the person described by the user ID. owner of the key is in fact the person described by the User ID.
Note that all PGP "key signatures" are this type of Note that all PGP "key signatures" are this type of
certification. certification.
0x11: Persona certification of a User ID and Public Key packet. 0x11: Persona certification of a User ID and Public Key packet.
The issuer of this certification has not done any verification The issuer of this certification has not done any verification
of the claim that the owner of this key is the user ID of the claim that the owner of this key is the User ID
specified. specified.
0x12: Casual certification of a User ID and Public Key packet. 0x12: Casual certification of a User ID and Public Key packet.
The issuer of this certification has done some casual The issuer of this certification has done some casual
verification of the claim of identity. verification of the claim of identity.
0x13: Positive certification of a User ID and Public Key packet. 0x13: Positive certification of a User ID and Public Key packet.
The issuer of this certification has done substantial The issuer of this certification has done substantial
verification of the claim of identity. verification of the claim of identity.
skipping to change at page 20, line 21 skipping to change at page 20, line 21
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 that 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) or direct-key signature (signature class 0x10 through 0x13) or direct-key
signature (0x1F). It should be issued by the same key that signature (0x1F). It should be issued by the same key that
issued the revoked signature or an authorized revocation key. issued the revoked signature or an authorized revocation key.
The signature should have a later creation date than the The signature should have a later creation date than the
signature it revokes. 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.
0x50: Notary signature. 0x50: Third-Party Confirmation signature.
This signature is a signature over some other OpenPGP signature This signature is a signature over some other OpenPGP signature
packet. It is a notary seal on the signed data. Note that a packet(s). It is a notary seal on the signed data. A third-party
notary signature SHOULD include a Signature Target subpacket to signature SHOULD include Signature Target subpacket(s) to give
give easy identification. easy identification. Note that we really do mean SHOULD. There
are plausible uses for this (such a a blind party that only sees
the signature, not the key nor source document) that cannot
include a target subpacket.
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:
- One-octet version number (3). - One-octet version number (3).
- One-octet length of following hashed material. MUST be 5. - One-octet length of following hashed material. MUST be 5.
- One-octet signature type. - One-octet signature type.
skipping to change at page 21, line 50 skipping to change at page 21, line 52
described RSA signatures. described RSA signatures.
With RSA signatures, the hash value is encoded as described in With RSA signatures, the hash value is encoded as described in
PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type PKCS-1 section 9.2.1 encoded using PKCS-1 encoding type
EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value EMSA-PKCS1-v1_5 [RFC2437]. This requires inserting the hash value
as an octet string into an ASN.1 structure. The object identifier as an octet string into an ASN.1 structure. The object identifier
for the type of hash being used is included in the structure. The for the type of hash being used is included in the structure. The
hexadecimal representations for the currently defined hash hexadecimal representations for the currently defined hash
algorithms are: algorithms are:
- 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
- SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
- SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02 - SHA384: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02
- SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03 - SHA512: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03
The ASN.1 OIDs are: The ASN.1 OIDs are:
- MD2: 1.2.840.113549.2.2
- MD5: 1.2.840.113549.2.5 - MD5: 1.2.840.113549.2.5
- RIPEMD-160: 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
- SHA256: 2.16.840.1.101.3.4.2.1 - SHA256: 2.16.840.1.101.3.4.2.1
- SHA384: 2.16.840.1.101.3.4.2.2 - SHA384: 2.16.840.1.101.3.4.2.2
- SHA512: 2.16.840.1.101.3.4.2.3 - SHA512: 2.16.840.1.101.3.4.2.3
The full hash prefixes for these are: 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, MD5: 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86,
0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00,
0x04, 0x10 0x04, 0x10
RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, RIPEMD-160: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24,
0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14
SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E, SHA-1: 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2b, 0x0E,
0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14
skipping to change at page 24, line 54 skipping to change at page 24, line 48
9 = key expiration time 9 = key expiration time
10 = placeholder for backward 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 29 = reason for revocation
30 = features 30 = features
31 = signature target 31 = signature target
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 that 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.
skipping to change at page 25, line 35 skipping to change at page 25, line 30
Implementations SHOULD implement "preferences" and the "reason for Implementations SHOULD implement "preferences" and the "reason for
revocation" subpackets. Note, however, that if an implementation revocation" subpackets. Note, however, that if an implementation
chooses not to implement some of the preferences, it is required to chooses not to implement some of the preferences, it is required to
behave in a polite manner to respect the wishes of those users who behave in a polite manner to respect the wishes of those users who
do implement these preferences. do implement these preferences.
5.2.3.2. Signature Subpacket Types 5.2.3.2. Signature Subpacket Types
A number of subpackets are currently defined. Some subpackets apply A number of subpackets are currently defined. Some subpackets apply
to the signature itself and some are attributes of the key. to the signature itself and some are attributes of the key.
Subpackets that are found on a self-signature are placed on a user Subpackets that are found on a self-signature are placed on a User
id certification made by the key itself. Note that a key may have ID certification made by the key itself. Note that a key may have
more than one user id, and thus may have more than one more than one User ID, and thus may have more than one
self-signature, and differing subpackets. self-signature, and differing subpackets.
A subpacket may be found either in the hashed or unhashed subpacket A subpacket may be found either in the hashed or unhashed subpacket
sections of a signature. If a subpacket is not hashed, then the sections of a signature. If a subpacket is not hashed, then the
information in it cannot be considered definitive because it is not information in it cannot be considered definitive because it is not
part of the signature proper. part of the signature proper.
5.2.3.3. Notes on Self-Signatures 5.2.3.3. Notes on Self-Signatures
A self-signature is a binding signature made by the key the A self-signature is a binding signature made by the key the
signature refers to. There are three types of self-signatures, the signature refers to. There are three types of self-signatures, the
certification signatures (types 0x10-0x13), the direct-key signature certification signatures (types 0x10-0x13), the direct-key signature
(type 0x1f), and the subkey binding signature (type 0x18). For (type 0x1f), and the subkey binding signature (type 0x18). For
certification self-signatures, each user ID may have a certification self-signatures, each User ID may have a
self-signature, and thus different subpackets in those self-signature, and thus different subpackets in those
self-signatures. For subkey binding signatures, each subkey in fact self-signatures. For subkey binding signatures, each subkey in fact
has a self-signature. Subpackets that appear in a certification has a self-signature. Subpackets that appear in a certification
self-signature apply to the username, and subpackets that appear in self-signature apply to the username, and subpackets that appear in
the subkey self-signature apply to the subkey. Lastly, subpackets on the subkey self-signature apply to the subkey. Lastly, subpackets on
the direct-key signature apply to the entire key. the direct-key signature apply to the entire key.
Implementing software should interpret a self-signature's preference Implementing software should interpret a self-signature's preference
subpackets as narrowly as possible. For example, suppose a key has subpackets as narrowly as possible. For example, suppose a key has
two usernames, Alice and Bob. Suppose that Alice prefers the two usernames, Alice and Bob. Suppose that Alice prefers the
symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If
the software locates this key via Alice's name, then the preferred the software locates this key via Alice's name, then the preferred
algorithm is CAST5, if software locates the key via Bob's name, then algorithm is CAST5, if software locates the key via Bob's name, then
the preferred algorithm is IDEA. If the key is located by key id, the preferred algorithm is IDEA. If the key is located by key id,
then algorithm of the default user id of the key provides the then algorithm of the default User ID of the key provides the
default symmetric algorithm. default symmetric algorithm.
Revoking a self-signature or allowing it to expire has a semantic Revoking a self-signature or allowing it to expire has a semantic
meaning that varies with the signature type. Revoking the meaning that varies with the signature type. Revoking the
self-signature on a user ID effectively retires that user name. The self-signature on a User ID effectively retires that user name. The
self-signature is a statement, "My name X is tied to my signing key self-signature is a statement, "My name X is tied to my signing key
K" and is corroborated by other users' certifications. If another K" and is corroborated by other users' certifications. If another
user revokes their certification, they are effectively saying that user revokes their certification, they are effectively saying that
they no longer believe that name and that key are tied together. they no longer believe that name and that key are tied together.
Similarly, if the user themselves revokes their self-signature, it Similarly, if the user themselves revokes their self-signature, it
means the user no longer goes by that name, no longer has that email means the user no longer goes by that name, no longer has that email
address, etc. Revoking a binding signature effectively retires that address, etc. Revoking a binding signature effectively retires that
subkey. Revoking a direct-key signature cancels that signature. subkey. Revoking a direct-key signature cancels that signature.
Please see the "Reason for Revocation" subpacket below for more Please see the "Reason for Revocation" subpacket below for more
relevant detail. relevant detail.
skipping to change at page 29, line 8 skipping to change at page 29, 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.14. Regular expression 5.2.3.14. Regular expression
(null-terminated regular expression) (null-terminated regular expression)
Used in conjunction with trust signature packets (of level > 0) to Used in conjunction with trust signature packets (of level > 0) to
limit the scope of trust that is extended. Only signatures by the limit the scope of trust that is extended. Only signatures by the
target key on user IDs that match the regular expression in the body target key on User IDs that match the regular expression in the body
of this packet have trust extended by the trust signature subpacket. of this packet have trust extended by the trust signature subpacket.
The regular expression uses the same syntax as the Henry Spencer's The regular expression uses the same syntax as the Henry Spencer's
"almost public domain" regular expression package. A description of "almost public domain" regular expression package. A description of
the syntax is found in a section below. the syntax is found in a section below.
5.2.3.15. Revocation key 5.2.3.15. 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
skipping to change at page 30, line 46 skipping to change at page 30, line 43
the key holder requests that this key only be modified or the key holder requests that this key only be modified or
updated by the key holder or an administrator of the key server. updated by the key holder or an administrator of the key server.
This is found only on a self-signature. This is found only on a self-signature.
5.2.3.18. Preferred key server 5.2.3.18. Preferred key server
(String) (String)
This is a URL of a key server that the key holder prefers be used This is a URL of a key server that the key holder prefers be used
for updates. Note that keys with multiple user ids can have a for updates. Note that keys with multiple User IDs can have a
preferred key server for each user id. Note also that since this is preferred key server for each User ID. Note also that since this is
a URL, the key server can actually be a copy of the key retrieved by a URL, the key server can actually be a copy of the key retrieved by
ftp, http, finger, etc. ftp, http, finger, etc.
5.2.3.19. Primary user id 5.2.3.19. Primary User ID
(1 octet, Boolean) (1 octet, Boolean)
This is a flag in a user id's self signature that states whether
this user id is the main user id for this key. It is reasonable for This is a flag in a User ID's self signature that states whether
this User ID is the main User ID for this key. It is reasonable for
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, but implementation may resolve the ambiguity in any way it sees fit, but
it is RECOMMENDED that priority be given to the user ID with the it is RECOMMENDED that priority be given to the User ID with the
most recent self-signature. most recent self-signature.
When appearing on a self-signature on a User ID packet, this When appearing on a self-signature on a User ID packet, this
subpacket applies only to User ID packets. When appearing on a subpacket applies only to User ID packets. When appearing on a
self-signature on a User Attribute packet, this subpacket applies self-signature on a User Attribute packet, this subpacket applies
only to User Attribute packets. That is to say, there are two only to User Attribute packets. That is to say, there are two
different and independent "primaries" - one for User IDs, and one different and independent "primaries" - one for User IDs, and one
for User Attributes. for User Attributes.
5.2.3.20. Policy URL 5.2.3.20. Policy URL
skipping to change at page 32, line 28 skipping to change at page 32, line 21
The "split key" (0x10) and "group key" (0x80) flags are placed on a The "split key" (0x10) and "group key" (0x80) flags are placed on a
self-signature only; they are meaningless on a certification self-signature only; they are meaningless on a certification
signature. They SHOULD be placed only on a direct-key signature signature. They SHOULD be placed only on a direct-key signature
(type 0x1f) or a subkey signature (type 0x18), one that refers to (type 0x1f) or a subkey signature (type 0x18), one that refers to
the key the flag applies to. the key the flag applies to.
5.2.3.22. Signer's User ID 5.2.3.22. Signer's User ID
(String) (String)
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.
This subpacket is not appropriate to use to refer to a User This subpacket is not appropriate to use to refer to a User
Attribute packet. Attribute packet.
5.2.3.23. Reason for Revocation 5.2.3.23. Reason for Revocation
skipping to change at page 33, line 14 skipping to change at page 33, line 8
of the subpacket is the length of the reason string plus one. of the subpacket is the length of the reason string plus one.
An implementation SHOULD implement this subpacket, include it in all An implementation SHOULD implement this subpacket, include it in all
revocation signatures, and interpret revocations appropriately. revocation signatures, and interpret revocations appropriately.
There are important semantic differences between the reasons, and There are important semantic differences between the reasons, and
there are thus important reasons for revoking signatures. there are thus important reasons for revoking signatures.
If a key has been revoked because of a compromise, all signatures If a key has been revoked because of a compromise, all signatures
created by that key are suspect. However, if it was merely created by that key are suspect. However, if it was merely
superceded or retired, old signatures are still valid. If the superceded or retired, old signatures are still valid. If the
revoked signature is the self-signature for certifying a user id, a revoked signature is the self-signature for certifying a User ID, a
revocation denotes that that user name is no longer in use. Such a revocation denotes that that user name is no longer in use. Such a
revocation SHOULD include an 0x20 subpacket. revocation SHOULD include an 0x20 subpacket.
Note that any signature may be revoked, including a certification on Note that any signature may be revoked, including a certification on
some other person's key. There are many good reasons for revoking a some other person's key. There are many good reasons for revoking a
certification signature, such as the case where the keyholder leaves certification signature, such as the case where the keyholder leaves
the employ of a business with an email address. A revoked the employ of a business with an email address. A revoked
certification no longer is a part of validity calculations. certification no longer is a part of validity calculations.
5.2.3.24. Features 5.2.3.24. Features
skipping to change at page 34, line 4 skipping to change at page 33, line 49
If an implementation implements any of the defined features, it If an implementation implements any of the defined features, it
SHOULD implement the features subpacket, too. SHOULD implement the features subpacket, too.
In the case of Modification Detection, an implementation may freely In the case of Modification Detection, an implementation may freely
infer this feature from other suitable implementation-dependent infer this feature from other suitable implementation-dependent
mechanisms. mechanisms.
5.2.3.25. Signature Target 5.2.3.25. Signature Target
(1 octet PK algorithm, 1 octet hash algorithm, N octets hash) (1 octet PK algorithm, 1 octet hash algorithm, N octets hash)
This subpacket identifies a specific target signature that a This subpacket identifies a specific target signature that a
signature refers to. For revocation signatures, this subpacket signature refers to. For revocation signatures, this subpacket
provides explicit designation of which signature is being revoked. provides explicit designation of which signature is being revoked.
For a notary or timestamp signature, this designates what signature For a third-party or timestamp signature, this designates what
is signed. All arguments are an identifier of that target signature. signature is signed. All arguments are an identifier of that target
signature.
The N octets of hash data MUST be the size of the hash of the The N octets of hash data MUST be the size of the hash of the
signature. For example, a target signature with a SHA-1 hash MUST signature. For example, a target signature with a SHA-1 hash MUST
have 20 octets of hash data. have 20 octets of hash data.
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.
skipping to change at page 34, line 31 skipping to change at page 34, line 26
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
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 (also then hashes the subkey, using the same format as the main key (also
using 0x99 as the first octet). Key revocation signatures (types using 0x99 as the first octet). Key revocation signatures (types
0x20 and 0x28) hash only the key being revoked. 0x20 and 0x28) hash only the key being revoked.
A certification signature (type 0x10 through 0x13) hashes the user When a signature is made over a signature, the hash data starts with
id being bound to the key into the hash context after the above the octet 0x88, followed by the four-octet length of the signature,
and then the body of the signature packet. (Note that this is an
old-style packet header for a signature packet with the
length-of-length set to zero).
A certification signature (type 0x10 through 0x13) hashes the User
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 0xb4 for without any header. A V4 certification hashes the constant 0xb4 for
user ID certifications or the constant 0xd1 for User Attribute User ID certifications or the constant 0xd1 for User Attribute
certifications (which are old-style packet headers with the certifications, followed by a four-octet number giving the length of
length-of-length set to zero), followed by a four-octet number the User ID or User Attribute data, and then the User ID or User
giving the length of the user ID or User Attribute data, and then Attribute data.
the User ID or User Attribute 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
signature version, the signature type, the public key algorithm, the signature version, the signature type, the public key algorithm, the
hash algorithm, the hashed subpacket length, and the hashed hash algorithm, the hashed subpacket length, and the hashed
subpacket body. subpacket body.
skipping to change at page 35, line 11 skipping to change at page 35, line 11
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 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 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 implementer; 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.
skipping to change at page 38, line 8 skipping to change at page 37, line 53
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)
A Secret Subkey packet (tag 7) is the subkey analog of the Secret A Secret Subkey packet (tag 7) is the subkey analog of the Secret
Key packet, and has exactly the same format. Key packet, and has exactly the same format.
5.5.2. Public Key Packet Formats 5.5.2. Public Key Packet Formats
There are two versions of key-material packets. Version 3 packets There are two versions of key-material packets. Version 3 packets
were first generated by PGP 2.6. Version 2 packets are identical in were first generated by PGP 2.6. Version 4 keys first appeared in
format to Version 3 packets, but are generated by PGP 2.5 or before. PGP 5.0, and are the preferred key version for OpenPGP.
V2 packets are deprecated and they MUST NOT be generated.
PGP 5.0 introduced version 4 packets, with new fields and semantics.
PGP 2.6.x will not accept key-material packets with versions
greater than 3.
OpenPGP implementations SHOULD create keys with version 4 format. An OpenPGP implementations SHOULD create keys with version 4 format. V3
implementation MAY generate a V3 key to ensure interoperability with keys are deprecated; an implementation SHOULD NOT generate a V3 key,
old software; note, however, that V4 keys correct some security but MAY accept it. An implementation MUST NOT create a V3 key with a
deficiencies in V3 keys. These deficiencies are described below. An public key algorithm other than RSA.
implementation MUST NOT create a V3 key with a public key algorithm
other than RSA.
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 backward compatibility because of V3 keys are deprecated. They contain three weaknesses in them.
three weaknesses in them. First, it is relatively easy to construct First, it is relatively easy to construct a V3 key that has the same
a V3 key that has the same key ID as any other key because the key key ID as any other key because the key ID is simply the low 64 bits
ID is simply the low 64 bits of the public modulus. Secondly, of the public modulus. Secondly, because the fingerprint of a V3 key
because the fingerprint of a V3 key hashes the key material, but not hashes the key material, but not its length, which increases the
its length, which increases the opportunity for fingerprint opportunity for fingerprint collisions. Third, there are minor
collisions. Third, there are minor weaknesses in the MD5 hash weaknesses in the MD5 hash algorithm that make developers prefer
algorithm that make developers prefer other algorithms. See below other algorithms. See below for a fuller discussion of key IDs and
for a fuller discussion of key IDs and fingerprints. 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
the absence of a validity period. This has been moved to the the absence of a validity period. This has been moved to the
signature packet. In addition, fingerprints of version 4 keys are signature packet. In addition, fingerprints of version 4 keys are
calculated differently from version 3 keys, as described in section calculated differently from version 3 keys, as described in section
"Enhanced Key Formats." "Enhanced Key Formats."
A version 4 packet contains: A version 4 packet contains:
- A one-octet version number (4). - A one-octet version number (4).
- 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 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. This algorithm-specific portion is: material. This algorithm-specific portion is:
skipping to change at page 44, line 7 skipping to change at page 43, line 47
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 that 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.
5.12. User Attribute Packet (Tag 17) 5.12. User Attribute Packet (Tag 17)
The User Attribute packet is a variation of the User ID packet. It The User Attribute packet is a variation of the User ID packet. It
is capable of storing more types of data than the User ID packet is capable of storing more types of data than the User ID packet
which is (by convention) limited to text. Like the User ID packet, which is (by convention) limited to text. Like the User ID packet,
a User Attribute packet may be certified by the key owner a User Attribute packet may be certified by the key owner
("self-signed") or any other key owner who cares to certify it. ("self-signed") or any other key owner who cares to certify it.
Except as noted, a User Attribute packet may be used anywhere that a Except as noted, a User Attribute packet may be used anywhere that a
User ID packet may be used. User ID packet may be used.
skipping to change at page 44, line 54 skipping to change at page 44, line 41
(but not required to be) that of the key owner. (but not required to be) that of the key owner.
The image attribute subpacket begins with an image header. The The image attribute subpacket begins with an image header. The
first two octets of the image header contain the length of the image first two octets of the image header contain the length of the image
header. Note that unlike other multi-byte numerical values in this header. Note that unlike other multi-byte numerical values in this
document, due to an historical accident this value is encoded as a document, due to an historical accident this value is encoded as a
little-endian number. The image header length is followed by a little-endian number. The image header length is followed by a
single octet for the image header version. The only currently single octet for the image header version. The only currently
defined version of the image header is 1, which is a 16 octet image defined version of the image header is 1, which is a 16 octet image
header. The first three octets of a version 1 image header are thus header. The first three octets of a version 1 image header are thus
0x10 0x00 0x01. Also note that this is the same encoding used for 0x10 0x00 0x01.
signature subpackets
The fourth octet of a version 1 image header designates the encoding The fourth octet of a version 1 image header designates the encoding
format of the image. The only currently defined encoding format is format of the image. The only currently defined encoding format is
the value 1 to indicate JPEG. Image format types 100 through 110 the value 1 to indicate JPEG. Image format types 100 through 110
are reserved for private or experimental use. The rest of the are reserved for private or experimental use. The rest of the
version 1 image header is made up of 12 reserved octets, all of version 1 image header is made up of 12 reserved octets, all of
which MUST be set to 0. which MUST be set to 0.
The rest of the image subpacket contains the image itself. As the The rest of the image subpacket contains the image itself. As the
only currently defined image type is JPEG, the image is encoded in only currently defined image type is JPEG, the image is encoded in
the JPEG File Interchange Format (JFIF), a standard file format for the JPEG File Interchange Format (JFIF), a standard file format for
skipping to change at page 54, line 15 skipping to change at page 53, line 55
Current message digest names are described below with the algorithm Current message digest names are described below with the algorithm
IDs. IDs.
7.1. Dash-Escaped Text 7.1. Dash-Escaped Text
The cleartext content of the message must also be dash-escaped. The cleartext content of the message must also be dash-escaped.
Dash escaped cleartext is the ordinary cleartext where every line Dash escaped cleartext is the ordinary cleartext where every line
starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
(0x2D) and space ' ' (0x20). This prevents the parser from (0x2D) and space ' ' (0x20). This prevents the parser from
recognizing armor headers of the cleartext itself. The message recognizing armor headers of the cleartext itself. An implementation
digest is computed using the cleartext itself, not the dash escaped MAY dash escape any line, SHOULD dash escape lines commencing "From
form. " (note the space), and MUST dash escape any line commencing in a
dash. The message digest is computed using the cleartext itself, not
the dash escaped form.
As with binary signatures on text documents, a cleartext signature As with binary signatures on text documents, a cleartext signature
is calculated on the text using canonical <CR><LF> line endings. is calculated on the text using canonical <CR><LF> line endings.
The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
SIGNATURE-----' line that terminates the signed text is not SIGNATURE-----' line that terminates the signed text is not
considered part of the signed text. considered part of the signed text.
When reversing dash-escaping, an implementation MUST strip the
string "- " if it occurs at the beginning of a line, and SHOULD warn
on "-" and any character other than a space at the beginning of a
line.
Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of
any line is ignored when the cleartext signature is calculated. any line is ignored when the cleartext signature is calculated.
8. Regular Expressions 8. Regular Expressions
A regular expression is zero or more branches, separated by '|'. It A regular expression is zero or more branches, separated by '|'. It
matches anything that matches one of the branches. matches anything that matches one of the branches.
A branch is zero or more pieces, concatenated. It matches a match A branch is zero or more pieces, concatenated. It matches a match
for the first, followed by a match for the second, etc. for the first, followed by a match for the second, etc.
skipping to change at page 55, line 47 skipping to change at page 55, line 45
9.2. Symmetric Key Algorithms 9.2. Symmetric Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Plaintext or unencrypted data 0 - Plaintext or unencrypted data
1 - IDEA [IDEA] 1 - IDEA [IDEA]
2 - Triple-DES (DES-EDE, [SCHNEIER] - 2 - Triple-DES (DES-EDE, [SCHNEIER] -
168 bit key derived from 192) 168 bit key derived from 192)
3 - CAST5 (128 bit key, as per RFC2144) 3 - CAST5 (128 bit key, as per RFC2144)
4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH]
5 - SAFER-SK128 (13 rounds) [SAFER] 5 - Reserved
6 - Reserved for DES/SK 6 - Reserved
7 - AES with 128-bit key [AES] 7 - AES with 128-bit key [AES]
8 - AES with 192-bit key 8 - AES with 192-bit key
9 - AES with 256-bit key 9 - AES with 256-bit key
10 - Twofish with 256-bit key [TWOFISH] 10 - Twofish with 256-bit key [TWOFISH]
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement Triple-DES. Implementations SHOULD Implementations MUST implement Triple-DES. Implementations SHOULD
implement AES-128 and CAST5. Implementations that interoperate with implement AES-128 and CAST5. Implementations that interoperate with
PGP 2.6 or earlier need to support IDEA, as that is the only PGP 2.6 or earlier need to support IDEA, as that is the only
symmetric cipher those versions use. Implementations MAY implement symmetric cipher those versions use. Implementations MAY implement
skipping to change at page 56, line 30 skipping to change at page 56, line 25
Implementations MUST implement uncompressed data. Implementations Implementations MUST implement uncompressed data. Implementations
SHOULD implement ZIP. Implementations MAY implement ZLIB. SHOULD implement ZIP. Implementations MAY implement ZLIB.
9.4. Hash Algorithms 9.4. Hash Algorithms
ID Algorithm Text Name ID Algorithm Text Name
-- --------- ---- ---- -- --------- ---- ----
1 - MD5 "MD5" 1 - MD5 "MD5"
2 - SHA-1 "SHA1" 2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160" 3 - RIPE-MD/160 "RIPEMD160"
4 - Reserved for double-width SHA (experimental, 4 - Reserved
obviated) 5 - Reserved
5 - MD2 "MD2" 6 - Reserved
6 - Reserved for TIGER/192 "TIGER192" 7 - Reserved
7 - Reserved for HAVAL (5 pass, 160-bit) "HAVAL-5-160"
8 - SHA256 "SHA256" 8 - SHA256 "SHA256"
9 - SHA384 "SHA384" 9 - SHA384 "SHA384"
10 - SHA512 "SHA512" 10 - SHA512 "SHA512"
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 MAY implement
implement MD5. other algorithms.
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 and to transfer keys. Not all possible packet sequences messages and to transfer keys. Not all possible packet sequences
are meaningful and correct. This section describes the rules for are meaningful and correct. This section describes the rules for
how packets should be placed into sequences. how packets should be placed into sequences.
10.1. Transferable Public Keys 10.1. Transferable Public Keys
skipping to change at page 57, line 35 skipping to change at page 57, line 28
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
immediately preceding User ID packet and the initial Public Key immediately preceding User ID packet and the initial Public Key
packet. The signature serves to certify the corresponding public key packet. The signature serves to certify the corresponding public key
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.
Within the same section as the User ID packets, there are zero or Within the same section as the User ID packets, there are zero or
more User Attribute packets. Like the User ID packets, a User more User Attribute packets. Like the User ID packets, a User
Attribute packet is followed by zero or more signature packets Attribute packet is followed by zero or more signature packets
calculated on the immediately preceding User Attribute packet and calculated on the immediately preceding User Attribute packet and
the initial Public Key packet. the initial Public Key packet.
User Attribute packets and User ID packets may be freely intermixed User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet. maintained on the proper User Attribute or User ID packet.
skipping to change at page 59, line 19 skipping to change at page 59, line 10
11.1. Key Structures 11.1. Key Structures
The format of an OpenPGP V3 key is as follows. Entries in square The format of an OpenPGP V3 key is as follows. Entries in square
brackets are optional and ellipses indicate repetition. brackets are optional and ellipses indicate repetition.
RSA Public Key RSA Public Key
[Revocation Self Signature] [Revocation Self Signature]
User ID [Signature ...] User ID [Signature ...]
[User ID [Signature ...] ...] [User ID [Signature ...] ...]
Each signature certifies the RSA public key and the preceding user Each signature certifies the RSA public key and the preceding User
ID. The RSA public key can have many user IDs and each user ID can ID. The RSA public key can have many User IDs and each User ID can
have many signatures. have many signatures.
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 ...] ...]
[User Attribute [Signature ...] ...] [User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation] [[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...] 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. This binding the primary key to tie the two keys together. This binding
signature may be in either V3 or V4 format, but V4 is preferred, of signature may be in either V3 or V4 format, but SHOULD be V4.
course.
In the above diagram, if the binding signature of a subkey has been In the above diagram, if the binding signature of a subkey has been
revoked, the revoked key may be removed, leaving only one key. revoked, the revoked key may be removed, leaving only one key.
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 certification. The subkeys may be keys of any other key capable of certification. The subkeys may be keys of any other
type. There may be other constructions of V4 keys, too. For example, type. 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 there 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 with an RSA encryption key, or RSA primary key with an Elgamal
subkey, etc. subkey, etc.
skipping to change at page 60, line 14 skipping to change at page 60, line 5
11.2. Key IDs and Fingerprints 11.2. Key IDs and Fingerprints
For a V3 key, the eight-octet key ID consists of the low 64 bits of For a V3 key, the eight-octet key ID consists of the low 64 bits of
the public modulus of the RSA key. the public modulus of the RSA key.
The fingerprint of a V3 key is formed by hashing the body (but not The fingerprint of a V3 key is formed by hashing the body (but not
the two-octet length) of the MPIs that form the key material (public the two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5. modulus n, followed by exponent e) with MD5.
A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
Tag, followed by the two-octet packet length, followed by the entire followed by the two-octet packet length, followed by the entire
Public Key packet starting with the version field. The key ID is Public Key packet starting with the version field. The key ID is
the low order 64 bits of the fingerprint. Here are the fields of the low order 64 bits of the fingerprint. Here are the fields of
the hash material, with the example of a DSA key: the hash material, with the example of a DSA key:
a.1) 0x99 (1 octet) a.1) 0x99 (1 octet)
a.2) high order length octet of (b)-(f) (1 octet) a.2) high order length octet of (b)-(f) (1 octet)
a.3) low order length octet of (b)-(f) (1 octet) a.3) low order length octet of (b)-(f) (1 octet)
skipping to change at page 64, line 34 skipping to change at page 64, line 27
algorithm. These are marked in the Public Algorithms section as algorithm. These are marked in the Public Algorithms section as
"(reserved for)". "(reserved for)".
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
and X9.42 (21) do not have the necessary parameters, parameter and X9.42 (21) do not have the necessary parameters, parameter
order, or semantics defined. order, or semantics defined.
The reserved symmetric key algorithm, DES/SK (6), does not have The reserved symmetric key algorithm, DES/SK (6), does not have
semantics defined. semantics defined.
The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do
not have OIDs. The reserved algorithm number 4, reserved for a
double-width variant of SHA1, is not presently defined.
12.8. OpenPGP CFB mode 12.8. 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 Encrypted 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.
In the description below, the value BS is the block size in octets In the description below, the value BS is the block size in octets
of the cipher. Most ciphers have a block size of 8 octets. The AES of the cipher. Most ciphers have a block size of 8 octets. The AES
skipping to change at page 66, line 18 skipping to change at page 66, line 10
* Certain operations in this specification involve the use of * Certain operations in this specification involve the use of
random numbers. An appropriate entropy source should be used to random numbers. An appropriate entropy source should be used to
generate these numbers. See RFC 1750. generate these numbers. See RFC 1750.
* The MD5 hash algorithm has been found to have weaknesses * The MD5 hash algorithm has been found to have weaknesses
(pseudo-collisions in the compress function) that make some (pseudo-collisions in the compress function) that make some
people deprecate its use. They consider the SHA-1 algorithm people deprecate its use. They consider the SHA-1 algorithm
better. better.
* SHA384 requires the same work as SHA512. In general, there are
few reasons to use it -- you need a situation where one needs
more security than SHA256, but do not want to have the 512-bit
data length.
* Many security protocol designers think that it is a bad idea to * Many security protocol designers think that it is a bad idea to
use a single key for both privacy (encryption) and integrity use a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces (signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption behind the V4 key format with separate signature and encryption
keys. If you as an implementer promote dual-use keys, you should keys. If you as an implementer promote dual-use keys, you should
at least be aware of this controversy. at least be aware of this controversy.
* The DSA algorithm will work with any 160-bit hash, but it is * The DSA algorithm will work with any 160-bit hash, but it is
sensitive to the quality of the hash algorithm, if the hash sensitive to the quality of the hash algorithm, if the hash
algorithm is broken, it can leak the secret key. The Digital algorithm is broken, it can leak the secret key. The Digital
skipping to change at page 68, line 10 skipping to change at page 68, line 7
14. Implementation Nits 14. Implementation Nits
This section is a collection of comments to help an implementer, This section is a collection of comments to help an implementer,
particularly with an eye to backward 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 is a non-comprehensive vexing than large differences. Thus, this is a non-comprehensive
list of potential problems and gotchas for a developer who is trying list of potential problems and gotchas for a developer who is trying
to be backward-compatible. to be backward-compatible.
* PGP 5.x does not accept V4 signatures for anything other than * The IDEA algorithm is patented, and yet it is required for PGP
key material. 2.x interoperability. It is also the defacto preferred algorithm
for a V3 key with a V3 self-signature (or no self-signature).
* 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 key size differs
from 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 * When exporting a private key, PGP 2.x generates the header
"BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY
BLOCK". All previous versions ignore the implied data type, and BLOCK". All previous versions ignore the implied data type, and
look directly at the packet data type. look directly at the packet data type.
* In a clear-signed signature, PGP 5.0 will figure out the correct * PGP 2.0 through 2.5 generated V2 Public Key Packets. These are
hash algorithm if there is no "Hash:" header, but it will reject identical to the deprecated V3 keys except for the version
a mismatch between the header and the actual algorithm used. The number. An implementation may accept or reject them as it sees
"standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x fit.
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 can only recognize * PGP 2.6.x will not accept key-material packets with versions
it with a V3 key id, and can properly use only a V3 format RSA greater than 3.
key.
* Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign * Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign
keys. They only handle Elgamal Encrypt-only keys. keys. They only handle Elgamal Encrypt-only keys.
* There are many ways possible for two keys to have the same key * There are many ways possible for two keys to have the same key
material, but different fingerprints (and thus key ids). Perhaps material, but different fingerprints (and thus key ids). Perhaps
the most interesting is an RSA key that has been "upgraded" to the most interesting is an RSA key that has been "upgraded" to
V4 format, but since a V4 fingerprint is constructed by hashing V4 format, but since a V4 fingerprint is constructed by hashing
the key creation time along with other things, two V4 keys the key creation time along with other things, two V4 keys
created at different times, yet with the same key material will created at different times, yet with the same key material will
skipping to change at page 69, line 16 skipping to change at page 68, line 49
"canonical text" signature. They only remove it from cleartext "canonical text" signature. They only remove it from cleartext
signatures. These signatures are not OpenPGP compliant -- signatures. These signatures are not OpenPGP compliant --
OpenPGP requires trimming the whitespace. If you wish to OpenPGP requires trimming the whitespace. If you wish to
interoperate with PGP 2.6.X or PGP 5, you may wish to accept interoperate with PGP 2.6.X or PGP 5, you may wish to accept
these non-compliant signatures. these non-compliant signatures.
15. Authors and Working Group Chair 15. Authors and Working Group Chair
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
John W. Noerenberg, II Derek Atkins
Qualcomm, Inc IHTFP Consulting, Inc.
6455 Lusk Blvd 6 Farragut Ave
San Diego, CA 92131 USA Somerville, MA 02144 USA
Email: jwn2@qualcomm.com Email: derek@ihtfp.com
Tel: +1 (619) 658-3510 Tel: +1 617 623 3745
The principal authors of this draft are: The principal authors of this draft are:
Jon Callas Jon Callas
Email: jon@callas.org Email: jon@callas.org
Tel: +1 (408) 448-6801 Tel: +1 (408) 448-6801
Lutz Donnerhacke Lutz Donnerhacke
IKS GmbH IKS GmbH
Wildenbruchstr. 15 Wildenbruchstr. 15
skipping to change at page 70, line 14 skipping to change at page 69, line 45
16. References 16. References
[AES] Advanced Encryption Standards Questions and Answers [AES] Advanced Encryption Standards Questions and Answers
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
aesfact.html> aesfact.html>
<http://csrc.nist.gov/encryption/aes/round2/ <http://csrc.nist.gov/encryption/aes/round2/
r2algs.html#Rijndael> r2algs.html#Rijndael>
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is
available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps>
[BLOWFISH] Schneier, B. "Description of a New Variable-Length [BLOWFISH] Schneier, B. "Description of a New Variable-Length
Key, 64-Bit Block Cipher (Blowfish)" Fast Software Key, 64-Bit Block Cipher (Blowfish)" Fast Software
Encryption, Cambridge Security Workshop Proceedings Encryption, Cambridge Security Workshop Proceedings
(December 1993), Springer-Verlag, 1994, pp191-204 (December 1993), Springer-Verlag, 1994, pp191-204
<http://www.counterpane.com/bfsverlag.html> <http://www.counterpane.com/bfsverlag.html>
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
international version of PGP", ftp://ftp.iks-
jena.de/mitarb/lutz/crypt/software/pgp/
[ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a [ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a
Signature Scheme Based on Discrete Logarithms," Signature Scheme Based on Discrete Logarithms,"
IEEE Transactions on Information Theory, v. IT-31, IEEE Transactions on Information Theory, v. IT-31,
n. 4, 1985, pp. 469-472. n. 4, 1985, pp. 469-472.
[IDEA] Lai, X, "On the design and security of block [IDEA] Lai, X, "On the design and security of block
ciphers", ETH Series in Information Processing, ciphers", ETH Series in Information Processing,
J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag J.L. Massey (editor), Vol. 1, Hartung-Gorre Verlag
Knostanz, Technische Hochschule (Zurich), 1992 Knostanz, Technische Hochschule (Zurich), 1992
[ISO10646] ISO/IEC 10646-1:1993. International Standard -- [ISO10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture Coded Character Set (UCS) -- Part 1: Architecture
and Basic Multilingual Plane. and Basic Multilingual Plane.
[JFIF] JPEG File Interchange Format (Version 1.02). [JFIF] JPEG File Interchange Format (Version 1.02).
Eric Hamilton, C-Cube Microsystems, Milpitas, CA, Eric Hamilton, C-Cube Microsystems, Milpitas, CA,
September 1, 1992. September 1, 1992.
[RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with
MIME", RFC 1641, July 1994.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3.", RFC 1951, May 1996.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997.
[RFC2279] Yergeau., F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2279, January 1998.
[RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA
Cryptography Specifications Version 2.0",
RFC 2437, October 1998.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999.
17. References (Non-Normative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is
available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps>
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
international version of PGP", ftp://ftp.iks-
jena.de/mitarb/lutz/crypt/software/pgp/
[MENEZES] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.
[JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier [JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier
"Implementation of Chosen-Ciphertext Attacks "Implementation of Chosen-Ciphertext Attacks
against PGP and GnuPG" against PGP and GnuPG"
http://www.counterpane.com/pgp-attack.html http://www.counterpane.com/pgp-attack.html
[MENEZES] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.
[RFC822] Crocker, D., "Standard for the format of ARPA [RFC822] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August Internet text messages", STD 11, RFC 822, August
1982. 1982.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet [RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, October 1993. Identifiers", RFC 1423, October 1993.
[RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with
MIME", RFC 1641, July 1994.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller, [RFC1750] Eastlake, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC "Randomness Recommendations for Security", RFC
1750, December 1994. 1750, December 1994.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3.", RFC 1951, May 1996.
[RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC
1983, August 1996. 1983, August 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996. Message Exchange Formats", RFC 1991, August 1996.
[RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet [RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies.", RFC 2045, November 1996. Message Bodies.", RFC 2045, 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", BCP 14, RFC 2119, March 1997. Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997.
[RFC2279] Yergeau., F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2279, January 1998.
[RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA
Cryptography Specifications Version 2.0",
RFC 2437, October 1998.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
August 2001. August 2001.
[SAFER] Massey, J.L. "SAFER K-64: One Year Later", B. 18. Full Copyright Statement
Preneel, editor, Fast Software Encryption, Second
International Workshop (LNCS 1008) pp212-241,
Springer-Verlag 1995
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999.
17. Full Copyright Statement
Copyright 2003 by The Internet Society. All Rights Reserved. Copyright 2003 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/