draft-ietf-openpgp-rfc2440bis-08.txt   draft-ietf-openpgp-rfc2440bis-09.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-08.txt draft-ietf-openpgp-rfc2440bis-09.txt
Expires Sep 2003 Lutz Donnerhacke Expires Apr 2004 Lutz Donnerhacke
March 2003 IN-Root-CA Individual Network e.V. October 2003 IN-Root-CA Individual Network e.V.
Hal Finney Obsoletes: 1991, 2440 Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-08.txt draft-ietf-openpgp-rfc2440bis-09.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 56 skipping to change at page 3, line 56
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 23 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 26 5.2.3.6. Key expiration time 27
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 28
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 28 5.2.3.14.Regular expression 29
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 31
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 34
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) 38
5.5.1.4. Secret Subkey Packet (Tag 7) 37 5.5.1.4. Secret Subkey Packet (Tag 7) 38
5.5.2. Public Key Packet Formats 37 5.5.2. Public Key Packet Formats 38
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) 42 5.9. Literal Data Packet (Tag 11) 43
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) 44
5.12. User Attribute Packet (Tag 17) 43 5.12. User Attribute Packet (Tag 17) 44
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) 46 5.14. Modification Detection Code Packet (Tag 19) 47
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 50 6.3. Encoding Binary in Radix-64 51
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 52 6.6. Example of an ASCII Armored Message 53
7. Cleartext signature framework 53 7. Cleartext signature framework 53
7.1. Dash-Escaped Text 53 7.1. Dash-Escaped Text 54
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 57
10.2. OpenPGP Messages 58 10.2. OpenPGP Messages 58
10.3. Detached Signatures 58 10.3. Detached Signatures 59
11. Enhanced Key Formats 58 11. Enhanced Key Formats 59
11.1. Key Structures 58 11.1. Key Structures 59
11.2. Key IDs and Fingerprints 59 11.2. Key IDs and Fingerprints 60
12. Notes on Algorithms 60 12. Notes on Algorithms 61
12.1. Symmetric Algorithm Preferences 60 12.1. Symmetric Algorithm Preferences 61
12.2. Other Algorithm Preferences 61 12.2. Other Algorithm Preferences 62
12.2.1. Compression Preferences 61 12.2.1. Compression Preferences 62
12.2.2. Hash Algorithm Preferences 62 12.2.2. Hash Algorithm Preferences 62
12.3. Plaintext 62 12.3. Plaintext 63
12.4. RSA 62 12.4. RSA 63
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 66
14. Implementation Nits 67 14. Implementation Nits 68
15. Authors and Working Group Chair 68 15. Authors and Working Group Chair 69
16. References 69 16. References (Normative) 70
17. References (Non-Normative) 70 17. References (Non-Normative) 71
18. Full Copyright Statement 71 18. Full Copyright Statement 72
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 6, line 32 skipping to change at page 6, line 32
term PGP 2.6.x. It used only RSA, MD5, and IDEA for its term PGP 2.6.x. It used only RSA, MD5, and IDEA for its
cryptographic transforms. An informational RFC, RFC1991, was cryptographic transforms. An informational RFC, RFC1991, was
written describing this version of PGP. written describing this version of PGP.
* PGP 5.x - This version of PGP is formerly known as "PGP 3" in * PGP 5.x - This version of PGP is formerly known as "PGP 3" in
the community and also in the predecessor of this document, the community and also in the predecessor of this document,
RFC1991. It has new formats and corrects a number of problems in RFC1991. It has new formats and corrects a number of problems in
the PGP 2.6.x design. It is referred to here as PGP 5.x because the PGP 2.6.x design. It is referred to here as PGP 5.x because
that software was the first release of the "PGP 3" code base. that software was the first release of the "PGP 3" code base.
* GPG - GNU Privacy Guard, also called GNUpg. GPG is an OpenPGP * GPG - GNU Privacy Guard, also called GnuPG. GPG is an OpenPGP
implementation that avoids all encumbered algorithms. implementation that avoids all encumbered algorithms.
Consequently, early versions of GPG did not include RSA public Consequently, early versions of GPG did not include RSA public
keys. GPG may or may not have (depending on version) support for keys. GPG may or may not have (depending on version) support for
IDEA or other encumbered algorithms. IDEA or other encumbered algorithms.
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of
PGP Corporation and are used with permission. PGP Corporation and are used with permission.
This document uses the terms "MUST", "SHOULD", and "MAY" as defined This document uses the terms "MUST", "SHOULD", and "MAY" as defined
in RFC2119, along with the negated forms of those terms. in RFC2119, along with the negated forms of those terms.
skipping to change at page 13, line 19 skipping to change at page 13, line 19
block size of the cipher for the decryption of the secret values, if block size of the cipher for the decryption of the secret values, if
they are encrypted, and then the secret key values themselves. they are encrypted, and then the secret key values themselves.
3.7.2.2. Symmetric-key message encryption 3.7.2.2. Symmetric-key message encryption
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) OpenPGP can create a Symmetric-key Encrypted Session Key (ESK)
packet at the front of a message. This is used to allow S2K packet at the front of a message. This is used to allow S2K
specifiers to be used for the passphrase conversion or to create specifiers to be used for the passphrase conversion or to create
messages with a mix of symmetric-key ESKs and public-key ESKs. This messages with a mix of symmetric-key ESKs and public-key ESKs. This
allows a message to be decrypted either with a passphrase or a allows a message to be decrypted either with a passphrase or a
public key. public key pair.
PGP 2.X always used IDEA with Simple string-to-key conversion when PGP 2.X always used IDEA with Simple string-to-key conversion when
encrypting a message with a symmetric algorithm. This is deprecated, encrypting a message with a symmetric algorithm. This is deprecated,
but MAY be used for backward-compatibility. but MAY be used for backward-compatibility.
4. Packet Syntax 4. Packet Syntax
This section describes the packets used by OpenPGP. This section describes the packets used by OpenPGP.
4.1. Overview 4.1. Overview
skipping to change at page 17, line 34 skipping to change at page 17, line 34
itself encrypted and stored in the Encrypted Session Key packet(s). itself encrypted and stored in the Encrypted Session Key packet(s).
The Symmetrically Encrypted Data Packet is preceded by one The Symmetrically Encrypted Data Packet is preceded by one
Public-Key Encrypted Session Key packet for each OpenPGP key to Public-Key Encrypted Session Key packet for each OpenPGP key to
which the message is encrypted. The recipient of the message finds which the message is encrypted. The recipient of the message finds
a session key that is encrypted to their public key, decrypts the a session key that is encrypted to their public key, decrypts the
session key, and then uses the session key to decrypt the message. session key, and then uses the session key to decrypt the message.
The body of this packet consists of: The body of this packet consists of:
- A one-octet number giving the version number of the packet type. - A one-octet number giving the version number of the packet type.
The currently defined value for packet version is 3. An The currently defined value for packet version is 3.
implementation should accept, but not generate a version of 2,
which is equivalent to V3 in all other respects.
- An eight-octet number that gives the key ID of the public key - An eight-octet number that gives the key ID of the public key
that the session key is encrypted to. If the session key is that the session key is encrypted to. If the session key is
encrypted to a subkey then the key ID of this subkey is used encrypted to a subkey then the key ID of this subkey is used
here instead of the key ID of the primary key. here instead of the key ID of the primary key.
- A one-octet number giving the public key algorithm used. - A one-octet number giving the public key algorithm used.
- A string of octets that is the encrypted session key. This - A string of octets that is the encrypted session key. This
string takes up the remainder of the packet, and its contents string takes up the remainder of the packet, and its contents
skipping to change at page 20, line 34 skipping to change at page 20, line 34
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: Third-Party Confirmation 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(s). It is a notary seal on the signed data. A third-party packet(s). It is analogous to a notary seal on the signed data.
signature SHOULD include Signature Target subpacket(s) to give A third-party signature SHOULD include Signature Target
easy identification. Note that we really do mean SHOULD. There subpacket(s) to give easy identification. Note that we really do
are plausible uses for this (such a a blind party that only sees mean SHOULD. There are plausible uses for this (such as a blind
the signature, not the key nor source document) that cannot party that only sees the signature, not the key nor source
include a target subpacket. 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 25, line 30 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
ID certification made by the key itself. Note that a key may have certification made by the key itself. Note that a key may have more
more than one User ID, and thus may have more than one than one User ID, and thus may have more than one self-signature,
self-signature, and differing subpackets. 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
skipping to change at page 26, line 12 skipping to change at page 26, line 12
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 the algorithm of the primary User ID of the key provides the default
default symmetric algorithm. 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.
Since a self-signature contains important information about the Since a self-signature contains important information about the
key's use, an implementation SHOULD allow the user to rewrite the key's use, an implementation SHOULD allow the user to rewrite the
self-signature, and important information in it, such as preferences self-signature, and important information in it, such as preferences
and key expiration. and key expiration.
It is good practice to verify that a self-signature imported into an
implementation doesn't advertise features that the implementation
doesn't support, rewriting the signature as appropriate.
An implementation that encounters multiple self-signatures on the An implementation that encounters multiple self-signatures on the
same object may resolve the ambiguity in any way it sees fit, but it same object may resolve the ambiguity in any way it sees fit, but it
is RECOMMENDED that priority be given to the most recent is RECOMMENDED that priority be given to the most recent
self-signature. self-signature.
5.2.3.4. Signature creation time 5.2.3.4. Signature creation time
(4 octet time field) (4 octet time field)
The time the signature was made. The time the signature was made.
skipping to change at page 30, line 28 skipping to change at page 30, line 38
Since the user name space is in the form of an email address, Since the user name space is in the form of an email address,
implementers MAY wish to arrange for that address to reach a person implementers MAY wish to arrange for that address to reach a person
who can be consulted about the use of the named tag. Note that due who can be consulted about the use of the named tag. Note that due
to UTF-8 encoding, not all valid user space name tags are valid to UTF-8 encoding, not all valid user space name tags are valid
email addresses. email addresses.
5.2.3.17. Key server preferences 5.2.3.17. Key server preferences
(N octets of flags) (N octets of flags)
This is a list of flags that indicate preferences that the key This is a list of one-bit flags that indicate preferences that the
holder has about how the key is handled on a key server. All key holder has about how the key is handled on a key server. All
undefined flags MUST be zero. undefined flags MUST be zero.
First octet: 0x80 = No-modify First octet: 0x80 = No-modify
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
skipping to change at page 31, line 45 skipping to change at page 32, line 5
0x02 - This key may be used to sign data. 0x02 - This key may be used to sign data.
0x04 - This key may be used to encrypt communications. 0x04 - This key may be used to encrypt communications.
0x08 - This key may be used to encrypt storage. 0x08 - This key may be used to encrypt storage.
0x10 - The private component of this key may have been split by 0x10 - The private component of this key may have been split by
a secret-sharing mechanism. a secret-sharing mechanism.
0x20 - This key may be used for authentication.
0x80 - The private component of this key may be in the 0x80 - The private component of this key may be in the
possession of more than one person. possession of more than one person.
Usage notes: Usage notes:
The flags in this packet may appear in self-signatures or in The flags in this packet may appear in self-signatures or in
certification signatures. They mean different things depending on certification signatures. They mean different things depending on
who is making the statement -- for example, a certification who is making the statement -- for example, a certification
signature that has the "sign data" flag is stating that the signature that has the "sign data" flag is stating that the
certification is for that use. On the other hand, the certification is for that use. On the other hand, the
skipping to change at page 33, line 16 skipping to change at page 33, line 32
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 is no longer a part of validity calculations.
5.2.3.24. Features 5.2.3.24. Features
(N octets of flags) (N octets of flags)
The features subpacket denotes which advanced OpenPGP features a The features subpacket denotes which advanced OpenPGP features a
user's implementation supports. This is so that as features are user's implementation supports. This is so that as features are
added to OpenPGP that cannot be backwards-compatible, a user can added to OpenPGP that cannot be backwards-compatible, a user can
state that they can use that feature. state that they can use that feature. The flags are single bits that
indicate that a given feature is supported.
This subpacket is similar to a preferences subpacket, and only This subpacket is similar to a preferences subpacket, and only
appears in a self-signature. appears in a self-signature.
An implementation SHOULD NOT use a feature listed when sending to a An implementation SHOULD NOT use a feature listed when sending to a
user who does not state that they can use it. user who does not state that they can use it.
Defined features are: Defined features are:
First octet: First octet:
skipping to change at page 34, line 34 skipping to change at page 34, line 51
0x20 and 0x28) hash only the key being revoked. 0x20 and 0x28) hash only the key being revoked.
When a signature is made over a signature, the hash data starts with When a signature is made over a signature, the hash data starts with
the octet 0x88, followed by the four-octet length of the signature, 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 and then the body of the signature packet. (Note that this is an
old-style packet header for a signature packet with the old-style packet header for a signature packet with the
length-of-length set to zero). length-of-length set to zero).
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 User ID or
without any header. A V4 certification hashes the constant 0xb4 for attribute packet packet, without any header. A V4 certification
User ID certifications or the constant 0xd1 for User Attribute hashes the constant 0xb4 for User ID certifications or the constant
certifications, followed by a four-octet number giving the length of 0xd1 for User Attribute certifications, followed by a four-octet
the User ID or User Attribute data, and then the User ID or User number giving the length of the User ID or User Attribute data, and
Attribute data. then 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 43, line 35 skipping to change at page 43, line 53
Text data is stored with <CR><LF> text endings (i.e. network-normal Text data is stored with <CR><LF> text endings (i.e. network-normal
line endings). These should be converted to native line endings by line endings). These should be converted to native line endings by
the receiving software. the receiving software.
5.10. Trust Packet (Tag 12) 5.10. Trust Packet (Tag 12)
The Trust packet is used only within keyrings and is not normally The Trust packet is used only within keyrings and is not normally
exported. Trust packets contain data that record the user's exported. Trust packets contain data that record the user's
specifications of which key holders are trustworthy introducers, specifications of which key holders are trustworthy introducers,
along with other information that implementing software uses for along with other information that implementing software uses for
trust information. trust information. The format of trust packets is defined by a given
implementation.
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 UTF-8 text that is intended to
name and email address of the key holder. By convention, it represent the name and email address of the key holder. By
includes an RFC822 mail name, but there are no restrictions on its convention, it includes an RFC822 mail name, but there are no
content. The packet length in the header specifies the length of restrictions on its content. The packet length in the header
the User ID. If it is text, it is encoded in UTF-8. specifies the length of the User ID.
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 47, line 43 skipping to change at page 48, line 9
In principle, any printable encoding scheme that met the In principle, any printable encoding scheme that met the
requirements of the unsafe channel would suffice, since it would not requirements of the unsafe channel would suffice, since it would not
change the underlying binary bit streams of the native OpenPGP data change the underlying binary bit streams of the native OpenPGP data
structures. The OpenPGP standard specifies one such printable structures. The OpenPGP standard specifies one such printable
encoding scheme to ensure interoperability. encoding scheme to ensure interoperability.
OpenPGP's Radix-64 encoding is composed of two parts: a base64 OpenPGP's Radix-64 encoding is composed of two parts: a base64
encoding of the binary data, and a checksum. The base64 encoding is encoding of the binary data, and a checksum. The base64 encoding is
identical to the MIME base64 content-transfer-encoding [RFC 2045]. identical to the MIME base64 content-transfer-encoding [RFC 2045].
An OpenPGP implementation MAY use ASCII Armor to protect the raw
binary data.
The checksum is a 24-bit CRC converted to four characters of The checksum is a 24-bit CRC converted to four characters of
radix-64 encoding by the same MIME base64 transformation, preceded radix-64 encoding by the same MIME base64 transformation, preceded
by an equals sign (=). The CRC is computed by using the generator by an equals sign (=). The CRC is computed by using the generator
0x864CFB and an initialization of 0xB704CE. The accumulation is 0x864CFB and an initialization of 0xB704CE. The accumulation is
done on the data before it is converted to radix-64, rather than on done on the data before it is converted to radix-64, rather than on
the converted data. A sample implementation of this algorithm is in the converted data. A sample implementation of this algorithm is in
the next section. the next section.
The checksum with its leading equal sign MAY appear on the first The checksum with its leading equal sign MAY appear on the first
skipping to change at page 48, line 37 skipping to change at page 48, line 50
if (crc & 0x1000000) if (crc & 0x1000000)
crc ^= CRC24_POLY; crc ^= CRC24_POLY;
} }
} }
return crc & 0xffffffL; return crc & 0xffffffL;
} }
6.2. Forming ASCII Armor 6.2. Forming ASCII Armor
When OpenPGP encodes data into ASCII Armor, it puts specific headers When OpenPGP encodes data into ASCII Armor, it puts specific headers
around the data, so OpenPGP can reconstruct the data later. OpenPGP around the Radix-64 encoded data, so OpenPGP can reconstruct the
informs the user what kind of data is encoded in the ASCII armor data later. An OpenPGP implementation MAY use ASCII armor to protect
through the use of the headers. raw binary data. OpenPGP informs the user what kind of data is
encoded in the ASCII armor through the use of the headers.
Concatenating the following data creates ASCII Armor: Concatenating the following data creates ASCII Armor:
- An Armor Header Line, appropriate for the type of data - An Armor Header Line, appropriate for the type of data
- Armor Headers - Armor Headers
- A blank (zero-length, or containing only whitespace) line - A blank (zero-length, or containing only whitespace) line
- The ASCII-Armored data - The ASCII-Armored data
skipping to change at page 53, line 39 skipping to change at page 53, line 50
- Exactly one empty line not included into the message digest, - Exactly one empty line not included into the message digest,
- The dash-escaped cleartext that is included into the message - The dash-escaped cleartext that is included into the message
digest, digest,
- The ASCII armored signature(s) including the '-----BEGIN PGP - The ASCII armored signature(s) including the '-----BEGIN PGP
SIGNATURE-----' Armor Header and Armor Tail Lines. SIGNATURE-----' Armor Header and Armor Tail Lines.
If the "Hash" armor header is given, the specified message digest If the "Hash" armor header is given, the specified message digest
algorithm is used for the signature. If there are no such headers, algorithm(s) are used for the signature. If there are no such
MD5 is used. If MD5 is the only hash used, then an implementation headers, MD5 is used. If MD5 is the only hash used, then an
MAY omit this header for improved V2.x compatibility. If more than implementation MAY omit this header for improved V2.x compatibility.
one message digest is used in the signature, the "Hash" armor header If more than one message digest is used in the signature, the "Hash"
contains a comma-delimited list of used message digests. armor header contains a comma-delimited list of used message
digests.
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 '-'
skipping to change at page 55, line 10 skipping to change at page 55, line 21
them (e.g. '[0-9]' matches any decimal digit). To include a literal them (e.g. '[0-9]' matches any decimal digit). To include a literal
']' in the sequence, make it the first character (following a ']' in the sequence, make it the first character (following a
possible '^'). To include a literal '-', make it the first or last possible '^'). To include a literal '-', make it the first or last
character. character.
9. Constants 9. Constants
This section describes the constants used in OpenPGP. This section describes the constants used in OpenPGP.
Note that these tables are not exhaustive lists; an implementation Note that these tables are not exhaustive lists; an implementation
MAY implement an algorithm not on these lists. MAY implement an algorithm not on these lists, so long as the
algorithm number(s) are chosen from the private or experimental
algorithm range.
See the section "Notes on Algorithms" below for more discussion of See the section "Notes on Algorithms" below for more discussion of
the algorithms. the algorithms.
9.1. Public Key Algorithms 9.1. Public Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
1 - RSA (Encrypt or Sign) 1 - RSA (Encrypt or Sign)
2 - RSA Encrypt-Only 2 - RSA Encrypt-Only
skipping to change at page 56, line 13 skipping to change at page 56, line 27
symmetric cipher those versions use. Implementations MAY implement symmetric cipher those versions use. Implementations MAY implement
any other algorithm. any other algorithm.
9.3. Compression Algorithms 9.3. Compression Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Uncompressed 0 - Uncompressed
1 - ZIP (RFC1951) 1 - ZIP (RFC1951)
2 - ZLIB (RFC1950) 2 - ZLIB (RFC1950)
3 - BZip2 [BZ2]
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. 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"
skipping to change at page 57, line 14 skipping to change at page 57, line 28
- After each User ID packet, zero or more signature packets - After each User ID packet, zero or more signature packets
(certifications) (certifications)
- Zero or more User Attribute packets - Zero or more User Attribute packets
- After each User Attribute packet, zero or more signature packets - After each User Attribute packet, zero or more signature packets
(certifications) (certifications)
- Zero or more Subkey packets - Zero or more Subkey packets
- After each Subkey packet, one signature packet, optionally a - After each Subkey packet, one signature packet, plus optionally
revocation. a revocation.
The Public Key packet occurs first. Each of the following User ID The Public Key packet occurs first. Each of the following User ID
packets provides the identity of the owner of this public key. If packets provides the identity of the owner of this public key. If
there are multiple User ID packets, this corresponds to multiple there are multiple User ID packets, this corresponds to multiple
means of identifying the same unique individual user; for example, a means of identifying the same unique individual user; for example, a
user may have more than one email address, and construct a User ID user may have more than one email address, and construct a User ID
for each one. for each one.
Immediately following each User ID packet, there are zero or more Immediately following each User ID packet, there are zero or more
signature packets. Each signature packet is calculated on the signature packets. Each signature packet is calculated on the
skipping to change at page 57, line 42 skipping to change at page 58, line 5
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.
After the User ID packets there may be one or more Subkey packets. After the User ID or Attribute packets there may be one or more
In general, subkeys are provided in cases where the top-level public Subkey packets. In general, subkeys are provided in cases where the
key is a signature-only key. However, any V4 key may have subkeys, top-level public key is a signature-only key. However, any V4 key
and the subkeys may be encryption-only keys, signature-only keys, or may have subkeys, and the subkeys may be encryption-only keys,
general-purpose keys. V3 keys MUST NOT have subkeys. signature-only keys, or general-purpose keys. V3 keys MUST NOT have
subkeys.
Each Subkey packet must be followed by one Signature packet, which Each Subkey packet must be followed by one Signature packet, which
should be a subkey binding signature issued by the top level key. should be a subkey binding signature issued by the top level key.
Subkey and Key packets may each be followed by a revocation Subkey and Key packets may each be followed by a revocation
Signature packet to indicate that the key is revoked. Revocation Signature packet to indicate that the key is revoked. Revocation
signatures are only accepted if they are issued by the key itself, signatures are only accepted if they are issued by the key itself,
or by a key that is authorized to issue revocations via a revocation or by a key that is authorized to issue revocations via a revocation
key subpacket in a self-signature by the top level key. key subpacket in a self-signature by the top level key.
skipping to change at page 58, line 19 skipping to change at page 58, line 35
An OpenPGP message is a packet or sequence of packets that An OpenPGP message is a packet or sequence of packets that
corresponds to the following grammatical rules (comma represents corresponds to the following grammatical rules (comma represents
sequential composition, and vertical bar separates alternatives): sequential composition, and vertical bar separates alternatives):
OpenPGP Message :- Encrypted Message | Signed Message | OpenPGP Message :- Encrypted Message | Signed Message |
Compressed Message | Literal Message. Compressed Message | Literal Message.
Compressed Message :- Compressed Data Packet. Compressed Message :- Compressed Data Packet.
Literal Message :- Literal Data Packet. Literal Message :- Literal Data Packet |
Literal Message, Literal Data Packet.
ESK :- Public Key Encrypted Session Key Packet | ESK :- Public Key Encrypted Session Key Packet |
Symmetric-Key Encrypted Session Key Packet. Symmetric-Key Encrypted Session Key Packet.
ESK Sequence :- ESK | ESK Sequence, ESK. ESK Sequence :- ESK | ESK Sequence, ESK.
Encrypted Data :- Symmetrically Encrypted Data Packet | Encrypted Data :- Symmetrically Encrypted Data Packet |
Symmetrically Encrypted Integrity Protected Data Packet Symmetrically Encrypted Integrity Protected Data Packet
Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data. Encrypted Message :- Encrypted Data | ESK Sequence, Encrypted Data.
skipping to change at page 59, line 20 skipping to change at page 59, line 37
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 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 SHOULD be V4. signature may be in either V3 or V4 format, but SHOULD be V4.
skipping to change at page 68, line 18 skipping to change at page 68, line 35
2.x interoperability. It is also the defacto preferred algorithm 2.x interoperability. It is also the defacto preferred algorithm
for a V3 key with a V3 self-signature (or no self-signature). for a V3 key with a V3 self-signature (or no self-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.
* PGP 2.0 through 2.5 generated V2 Public Key Packets. These are * PGP 2.0 through 2.5 generated V2 Public Key Packets. These are
identical to the deprecated V3 keys except for the version identical to the deprecated V3 keys except for the version
number. An implementation may accept or reject them as it sees number. An implementation MUST NOT generate them and may accept
fit. or reject them as it sees fit. Similarly, these versions
generated V2 PKESK packets (Tag 1). An implementation may accept
or reject V2 PKESK packets as it sees fit, and MUST NOT generate
them.
* PGP 2.6.x will not accept key-material packets with versions * PGP 2.6.x will not accept key-material packets with versions
greater than 3. greater than 3.
* 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
skipping to change at page 69, line 24 skipping to change at page 69, line 46
07745 Jena, Germany 07745 Jena, Germany
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Tel: +49-3641-675642 Tel: +49-3641-675642
Hal Finney Hal Finney
Network Associates, Inc. Network Associates, Inc.
3965 Freedom Circle 3965 Freedom Circle
Santa Clara, CA 95054, USA Santa Clara, CA 95054, USA
Email: hal@pgp.com Email: hal@finney.org
Rodney Thayer Rodney Thayer
Email: rodney@tillerman.to Email: rodney@tillerman.to
This memo also draws on much previous work from a number of other This memo 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
Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark
Weaver, and Philip R. Zimmermann. Weaver, and Philip R. Zimmermann.
16. References 16. References (Normative)
[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>
[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>
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page"
<http://sources.redhat.com/bzip2/>
[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.
[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
Internet text messages", STD 11, RFC 822, August
1982.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, October 1993.
[RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with [RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with
MIME", RFC 1641, July 1994. MIME", RFC 1641, July 1994.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC
1750, December 1994.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3.", RFC 1951, May 1996. Specification version 1.3.", RFC 1951, May 1996.
[RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies.", RFC 2045, November 1996.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997. 2144, May 1997.
[RFC2279] Yergeau., F., "UTF-8, a transformation format of [RFC2279] Yergeau., F., "UTF-8, a transformation format of
Unicode and ISO 10646", RFC 2279, January 1998. Unicode and ISO 10646", RFC 2279, January 1998.
[RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA [RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA
Cryptography Specifications Version 2.0", Cryptography Specifications Version 2.0",
RFC 2437, October 1998. RFC 2437, October 1998.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156,
August 2001.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996. protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C. [TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999. Algorithm", John Wiley & Sons, 1999.
17. References (Non-Normative) 17. References (Non-Normative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key," signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is 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 <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti
/isc/ElGamal.ps> /isc/ElGamal.ps>
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved
international version of PGP", ftp://ftp.iks- international version of PGP", ftp://ftp.iks-
jena.de/mitarb/lutz/crypt/software/pgp/ 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
[RFC822] Crocker, D., "Standard for the format of ARPA
Internet text messages", STD 11, RFC 822, August
1982.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, October 1993.
[RFC1750] Eastlake, D., Crocker, S. and J. Schiller,
"Randomness Recommendations for Security", RFC
1750, December 1994.
[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
Message Exchange Formats", RFC 1991, August 1996.
[RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
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.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156,
August 2001.
18. Full Copyright Statement 18. 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
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
</x-flowed>
 End of changes. 

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