draft-ietf-openpgp-rfc2440bis-05.txt   draft-ietf-openpgp-rfc2440bis-06.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Wave Systems Corporation Category: INTERNET-DRAFT
draft-ietf-openpgp-rfc2440bis-05.txt draft-ietf-openpgp-rfc2440bis-06.txt
Expires Oct 2002 Lutz Donnerhacke Expires Feb 2003 Lutz Donnerhacke
April 2002 IN-Root-CA Individual Network e.V. August 2002 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-05.txt draft-ietf-openpgp-rfc2440bis-06.txt
Copyright 2002 by The Internet Society. All Rights Reserved. Copyright 2002 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 4, line 5 skipping to change at page 4, line 5
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 22 5.2.3. Version 4 Signature Packet Format 22
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 26
5.2.3.7. Preferred symmetric algorithms 26 5.2.3.7. Preferred symmetric algorithms 26
5.2.3.8. Preferred hash algorithms 26 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 28 5.2.3.14.Regular expression 28
5.2.3.15.Revocation key 28 5.2.3.15.Revocation key 28
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 30 5.2.3.20.Policy URL 30
5.2.3.21.Key Flags 31 5.2.3.21.Key Flags 31
5.2.3.22.Signer's User ID 31 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 32 5.2.3.24.Features 33
5.2.3.25.Revocation Target 33 5.2.3.25.Revocation Target 33
5.2.4. Computing Signatures 33 5.2.4. Computing Signatures 33
5.2.4.1. Subpacket Hints 34 5.2.4.1. Subpacket Hints 34
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) 35 5.4. One-Pass Signature Packets (Tag 4) 36
5.5. Key Material Packet 36 5.5. Key Material Packet 36
5.5.1. Key Packet Variants 36 5.5.1. Key Packet Variants 36
5.5.1.1. Public Key Packet (Tag 6) 36 5.5.1.1. Public Key Packet (Tag 6) 36
5.5.1.2. Public Subkey Packet (Tag 14) 36 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 37 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) 40 5.6. Compressed Data Packet (Tag 8) 40
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) 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) 43 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) 44 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 44
5.14. Modification Detection Code Packet (Tag 19) 46 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" 47 6.1. An Implementation of the CRC-24 in "C" 47
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 50
6.4. Decoding Radix-64 51 6.4. Decoding Radix-64 51
6.5. Examples of Radix-64 51 6.5. Examples of Radix-64 52
6.6. Example of an ASCII Armored Message 52 6.6. Example of an ASCII Armored Message 52
7. Cleartext signature framework 52 7. Cleartext signature framework 52
7.1. Dash-Escaped Text 53 7.1. Dash-Escaped Text 53
8. Regular Expressions 53 8. Regular Expressions 54
9. Constants 54 9. Constants 54
9.1. Public Key Algorithms 54 9.1. Public Key Algorithms 54
9.2. Symmetric Key Algorithms 55 9.2. Symmetric Key Algorithms 55
9.3. Compression Algorithms 55 9.3. Compression Algorithms 55
9.4. Hash Algorithms 55 9.4. Hash Algorithms 55
10. Packet Composition 56 10. Packet Composition 56
10.1. Transferable Public Keys 56 10.1. Transferable Public Keys 56
10.2. OpenPGP Messages 57 10.2. OpenPGP Messages 57
10.3. Detached Signatures 58 10.3. Detached Signatures 58
11. Enhanced Key Formats 58 11. Enhanced Key Formats 58
11.1. Key Structures 58 11.1. Key Structures 58
11.2. Key IDs and Fingerprints 59 11.2. Key IDs and Fingerprints 59
12. Notes on Algorithms 60 12. Notes on Algorithms 60
12.1. Symmetric Algorithm Preferences 60 12.1. Symmetric Algorithm Preferences 60
12.2. Other Algorithm Preferences 61 12.2. Other Algorithm Preferences 61
12.2.1. Compression Preferences 61 12.2.1. Compression Preferences 61
12.2.2. Hash Algorithm Preferences 61 12.2.2. Hash Algorithm Preferences 62
12.3. Plaintext 62 12.3. Plaintext 62
12.4. RSA 62 12.4. RSA 62
12.5. Elgamal 62 12.5. Elgamal 62
12.6. DSA 63 12.6. DSA 63
12.7. Reserved Algorithm Numbers 63 12.7. Reserved Algorithm Numbers 63
12.8. OpenPGP CFB mode 63 12.8. OpenPGP CFB mode 64
13. Security Considerations 65 13. Security Considerations 65
14. Implementation Nits 66 14. Implementation Nits 67
15. Authors and Working Group Chair 67 15. Authors and Working Group Chair 68
16. References 68 16. References 69
17. Full Copyright Statement 70 17. 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 8, line 26 skipping to change at page 8, line 26
6. The receiving software generates a new hash code for the 6. The receiving software generates a new hash code for the
received message and verifies it using the message's signature. received message and verifies it using the message's signature.
If the verification is successful, the message is accepted as If the verification is successful, the message is accepted as
authentic. authentic.
2.3. Compression 2.3. Compression
OpenPGP implementations SHOULD compress the message after applying OpenPGP implementations SHOULD compress the message after applying
the signature but before encryption. the signature but before encryption.
Note that while all past implementations of PGP properly handle If an implementation does not implement compression, its authors
messages that have not been compressed, they all have compressed should be aware that most PGP messages in the world are compressed.
messages by default. If an implementation does not implement Thus, it may even be wise for a space-constrained implementation to
compression, its authors should be aware that most PGP messages in implement decompression, but not compression.
the world are compressed. Thus, it may even be wise for a
space-constrained implementation to implement decompression, but not Furthermore, compression has the added side-effect that some types
compression. of attacks can be thwarted by the fact that slightly altered,
compressed data rarely uncompresses without severe errors. This is
hardly rigorous, but it is operationally useful. These attacks can
be rigorously prevented by implementing and using Modification
Detection Codes as described in sections following.
2.4. Conversion to Radix-64 2.4. Conversion to Radix-64
OpenPGP's underlying native representation for encrypted messages, OpenPGP's underlying native representation for encrypted messages,
signature certificates, and keys is a stream of arbitrary octets. signature certificates, and keys is a stream of arbitrary octets.
Some systems only permit the use of blocks consisting of seven-bit, Some systems only permit the use of blocks consisting of seven-bit,
printable text. For transporting OpenPGP's native raw binary octets printable text. For transporting OpenPGP's native raw binary octets
through channels that are not safe to raw binary data, a printable through channels that are not safe to raw binary data, a printable
encoding of these binary octets is needed. OpenPGP provides the encoding of these binary octets is needed. OpenPGP provides the
service of converting the raw 8-bit binary octet stream to a stream service of converting the raw 8-bit binary octet stream to a stream
skipping to change at page 21, line 9 skipping to change at page 21, line 13
Algorithm Specific Fields for DSA signatures: Algorithm Specific Fields for DSA signatures:
- MPI of DSA value r. - MPI of DSA value r.
- MPI of DSA value s. - MPI of DSA value s.
The signature calculation is based on a hash of the signed data, as The signature calculation is based on a hash of the signed data, as
described above. The details of the calculation are different for described above. The details of the calculation are different for
DSA signature than for RSA signatures. DSA signature than for RSA signatures.
Algorithm Specific Fields for ElGamal signatures: Algorithm Specific Fields for Elgamal signatures:
- MPI of ElGamal value a = g**k mod p. - MPI of Elgamal value a = g**k mod p.
- MPI of ElGamal value b = (h-a*x)/k mod p-1. - MPI of Elgamal value b = (h-a*x)/k mod p-1.
The hash h is PKCS-1 padded exactly the same way as for the above The hash h is PKCS-1 padded exactly the same way as for the above
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:
skipping to change at page 25, line 49 skipping to change at page 25, line 50
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 has a defined semantic meaning. Revoking Revoking a self-signature or allowing it to expire has a defined
the self-signature on a user ID effectively retires that user name. semantic meaning. Revoking the self-signature on a user ID
The self-signature is a statement, "My name X is tied to my signing effectively retires that user name. The self-signature is a
key K" and is corroborated by other users' certifications. If statement, "My name X is tied to my signing key K" and is
another user revokes their certification, they are effectively corroborated by other users' certifications. If another user revokes
saying that they no longer believe that name and that key are tied their certification, they are effectively saying that they no longer
together. Similarly, if the user themselves revokes their believe that name and that key are tied together. Similarly, if the
self-signature, it means the user no longer goes by that name, no user themselves revokes their self-signature, it means the user no
longer has that email address, etc. Revoking a binding signature longer goes by that name, no longer has that email address, etc.
effectively retires that subkey. Please see the "Reason for Revoking a binding signature effectively retires that subkey. Please
Revocation" subpacket below for more relevant detail. see the "Reason for Revocation" subpacket below for more 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.
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.
skipping to change at page 33, line 24 skipping to change at page 33, line 29
Defined features are: Defined features are:
First octet: First octet:
0x01 - Modification Detection (packets 18 and 19) 0x01 - Modification Detection (packets 18 and 19)
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
infer this feature from other suitable implementation-dependent
mechanisms.
5.2.3.25. Revocation Target 5.2.3.25. Revocation 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
revocation signature revokes. This provides explicit designation of revocation signature revokes. This provides explicit designation of
a revocation. All arguments are an identifier of that signature. a revocation. All arguments are an identifier of that 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
skipping to change at page 45, line 7 skipping to change at page 45, line 7
5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18) 5.13. Sym. Encrypted Integrity Protected Data Packet (Tag 18)
The Symmetrically Encrypted Integrity Protected Data Packet is a The Symmetrically Encrypted Integrity Protected Data Packet is a
variant of the Symmetrically Encrypted Data Packet. It is a new variant of the Symmetrically Encrypted Data Packet. It is a new
feature created for OpenPGP that addresses the problem of detecting feature created for OpenPGP that addresses the problem of detecting
a modification to encrypted data. It is used in combination with a a modification to encrypted data. It is used in combination with a
Modification Detection Code Packet. Modification Detection Code Packet.
There is a corresponding feature in the features signature subpacket There is a corresponding feature in the features signature subpacket
that denotes that an implementation can properly use this packet that denotes that an implementation can properly use this packet
type. An implementation SHOULD NOT use this packet when encrypting type. An implementation SHOULD prefer this to the older
to a recipient that does not state it can use this packet, and Symmetrically Encrypted Data Packet when possible. Since this data
SHOULD prefer this to older Symmetrically Encrypted Data Packet when packet protects against modification attacks, this standard
possible. encourages its proliferation. While blanket adoption of this data
packet would create interoperability problems, rapid adoption is
nevertheless important. An implementation SHOULD specifically denote
support for this packet, but it MAY infer it from other mechanisms.
For example, an implementation might infer from the use of a cipher
such as AES or Twofish that a user supports this feature. It might
place in the unhashed portion of another user's key signature a
features subpacket. It might also present a user with an opportunity
to regenerate their own self-signature with a features subpacket.
This packet contains data encrypted with a symmetric-key algorithm This packet contains data encrypted with a symmetric-key algorithm
and protected against modification by the SHA-1 hash algorithm. When and protected against modification by the SHA-1 hash algorithm. When
it has been decrypted, it will typically contain other packets it has been decrypted, it will typically contain other packets
(often literal data packets or compressed data packets). The last (often literal data packets or compressed data packets). The last
decrypted packet in this packet's payload MUST be a Modification decrypted packet in this packet's payload MUST be a Modification
Detection Code packet. Detection Code packet.
The body of this packet consists of: The body of this packet consists of:
skipping to change at page 49, line 36 skipping to change at page 49, line 51
the user, but OpenPGP should continue to process the message. the user, but OpenPGP should continue to process the message.
Currently defined Armor Header Keys are: Currently defined Armor Header Keys are:
- "Version", that states the OpenPGP Version used to encode the - "Version", that states the OpenPGP Version used to encode the
message. message.
- "Comment", a user-defined comment. OpenPGP defines all text to - "Comment", a user-defined comment. OpenPGP defines all text to
be in UTF-8. A comment may be any UTF-8 string. However, the be in UTF-8. A comment may be any UTF-8 string. However, the
whole point of armoring is to provide seven-bit-clean data. whole point of armoring is to provide seven-bit-clean data.
Consquently, if a comment has character that are outside the Consequently, if a comment has characters that are outside the
US-ASCII range of UTF, they may very well not survive transport. US-ASCII range of UTF, they may very well not survive transport.
- "MessageID", a 32-character string of printable characters. The - "MessageID", a 32-character string of printable characters. The
string must be the same for all parts of a multi-part message string must be the same for all parts of a multi-part message
that uses the "PART X" Armor Header. MessageID strings should that uses the "PART X" Armor Header. MessageID strings should
be unique enough that the recipient of the mail can associate be unique enough that the recipient of the mail can associate
all the parts of a message with each other. A good checksum or all the parts of a message with each other. A good checksum or
cryptographic hash function is sufficient. cryptographic hash function is sufficient.
The MessageID SHOULD NOT appear unless it is in a multi-part The MessageID SHOULD NOT appear unless it is in a multi-part
skipping to change at page 53, line 16 skipping to change at page 53, line 27
- 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 is used for the signature. If there are no such headers,
MD5 is used, an implementation MAY omit them for V2.x compatibility. MD5 is used. If MD5 is the only hash used, then an implementation
If more than one message digest is used in the signature, the "Hash" MAY omit this header for improved V2.x compatibility. If more than
armor header contains a comma-delimited list of used message one message digest is used in the signature, the "Hash" armor header
digests. 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 62, line 11 skipping to change at page 62, line 19
Typically, the choice of a hash algorithm is something the signer Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer rarely knows who is does, rather than the verifier, because a signer rarely knows who is
going to be verifying the signature. This preference, though, allows going to be verifying the signature. This preference, though, allows
a protocol based upon digital signatures ease in negotiation. a protocol based upon digital signatures ease in negotiation.
Thus, if Alice is authenticating herself to Bob with a signature, it Thus, if Alice is authenticating herself to Bob with a signature, it
makes sense for her to use a hash algorithm that Bob's software makes sense for her to use a hash algorithm that Bob's software
uses. This preference allows Bob to state in his key which uses. This preference allows Bob to state in his key which
algorithms Alice may use. algorithms Alice may use.
Since SHA1 is the MUST-implement hash algorithm, if it is not
explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly.
12.3. Plaintext 12.3. Plaintext
Algorithm 0, "plaintext," may only be used to denote secret keys Algorithm 0, "plaintext," may only be used to denote secret keys
that are stored in the clear. Implementations MUST NOT use plaintext that are stored in the clear. Implementations MUST NOT use plaintext
in Symmetrically Encrypted Data Packets; they must use Literal Data in Symmetrically Encrypted Data Packets; they must use Literal Data
Packets to encode unencrypted or literal data. Packets to encode unencrypted or literal data.
12.4. RSA 12.4. RSA
There are algorithm types for RSA-signature-only, and There are algorithm types for RSA-signature-only, and
skipping to change at page 66, line 24 skipping to change at page 66, line 36
specify a preferred signing algorithm. However, the signer would specify a preferred signing algorithm. However, the signer would
be foolish to use a weak algorithm simply because the recipient be foolish to use a weak algorithm simply because the recipient
requests it. requests it.
* Some of the encryption algorithms mentioned in this document * Some of the encryption algorithms mentioned in this document
have been analyzed less than others. For example, although have been analyzed less than others. For example, although
CAST5 is presently considered strong, it has been analyzed less CAST5 is presently considered strong, it has been analyzed less
than Triple-DES. Other algorithms may have other controversies than Triple-DES. Other algorithms may have other controversies
surrounding them. surrounding them.
* In late summer 2002, Jallad, Katz, and Schneier published an
interesting attack on the OpenPGP protocol and some of its
implementations [JKS02]. In this attack, the attacker modifies a
message and sends it to a user who then returns the erroneously
decrypted message to the attacker. The attacker is thus using
the user as a random oracle, and can often decrypt the message.
Compressing data can ameliorate this attack. The incorrectly
decrypted data nearly always decompresses in ways that defeats
the attack. However, this is not a rigorous fix, and leaves open
some small vulnerabilities. For example, if an implementation
does not compress a message before encryption (perhaps because
it knows it was already compressed), then that message is
vulnerable. Because of this happenstance -- that modification
attacks can be thwarted by decompression errors, an
implementation SHOULD treat a decompression error as a security
problem, not merely a data problem.
This attack can be defeated by the use of Modification
Detection, provided that the implementation does not let the
user naively return the data to the attacker. An implementation
MUST treat an MDC failure as a security problem, not merely a
data problem.
In either case, the implementation MAY allow the user access to
the erroneous data, but MUST warn the user as to potential
security problems should that data be returned to the sender.
While this attack is somewhat obscure, requiring a special set
of circumstances to create it, it is nonetheless quite serious
as it permits someone to trick a user to decrypt a message.
Consequently, it is important that:
1. Implementers treat MDC errors and decompression failures as
security problems.
2. Implementers implement Modification Detection with all due
speed and encourage its spread.
3. Users migrate to implementations that support Modification
Detection with all due speed.
* Some technologies mentioned here may be subject to government * Some technologies mentioned here may be subject to government
control in some countries. control in some countries.
14. Implementation Nits 14. Implementation Nits
This section is a collection of comments to help an 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
skipping to change at page 67, line 52 skipping to change at page 69, line 4
John W. Noerenberg, II John W. Noerenberg, II
Qualcomm, Inc Qualcomm, Inc
6455 Lusk Blvd 6455 Lusk Blvd
San Diego, CA 92131 USA San Diego, CA 92131 USA
Email: jwn2@qualcomm.com Email: jwn2@qualcomm.com
Tel: +1 (619) 658-3510 Tel: +1 (619) 658-3510
The principal authors of this draft are: The principal authors of this draft are:
Jon Callas Jon Callas
Wave Systems Corp. Email: jon@callas.org
1601 S. DeAnza Blvd, Suite 200
Cupertino, CA 95014, USA
Email: jon@callas.org, jcallas@wavesys.com
Tel: +1 (408) 448-6801 Tel: +1 (408) 448-6801
Lutz Donnerhacke Lutz Donnerhacke
IKS GmbH IKS GmbH
Wildenbruchstr. 15 Wildenbruchstr. 15
07745 Jena, Germany 07745 Jena, Germany
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Tel: +49-3641-675642 Tel: +49-3641-675642
skipping to change at page 68, line 41 skipping to change at page 69, line 41
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 [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>
[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 [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/
[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.
[JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier
"Implementation of Chosen-Ciphertext Attacks
against PGP and GnuPG"
http://www.counterpane.com/pgp-attack.html
[MENEZES] Alfred Menezes, Paul van Oorschot, and Scott [MENEZES] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996. 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
 End of changes. 

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