draft-ietf-openpgp-rfc2440bis-16.txt   draft-ietf-openpgp-rfc2440bis-17.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-16.txt draft-ietf-openpgp-rfc2440bis-17.txt
Expires October 2006 Lutz Donnerhacke Expires November 2006 Lutz Donnerhacke
April 2006 May 2006
Obsoletes: 1991, 2440 Hal Finney Obsoletes: 1991, 2440 Hal Finney
PGP Corporation PGP Corporation
David Shaw David Shaw
Rodney Thayer Rodney Thayer
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc2440bis-16.txt draft-ietf-openpgp-rfc2440bis-17.txt
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
IPR Claim Notice IPR Claim Notice
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
9.4. Hash Algorithms 57 9.4. Hash Algorithms 57
10. Packet Composition 58 10. Packet Composition 58
10.1. Transferable Public Keys 58 10.1. Transferable Public Keys 58
10.2. Transferable Secret Keys 59 10.2. Transferable Secret Keys 59
10.3. OpenPGP Messages 59 10.3. OpenPGP Messages 59
10.4. Detached Signatures 60 10.4. Detached Signatures 60
11. Enhanced Key Formats 60 11. Enhanced Key Formats 60
11.1. Key Structures 60 11.1. Key Structures 60
11.2. Key IDs and Fingerprints 61 11.2. Key IDs and Fingerprints 61
12. Notes on Algorithms 62 12. Notes on Algorithms 62
12.1. Symmetric Algorithm Preferences 62 12.1. PKCS#1 Encoding In OpenPGP 62
12.2. Other Algorithm Preferences 63 12.1.1. EME-PKCS1-v1_5-ENCODE 63
12.2.1. Compression Preferences 63 12.1.2. EME-PKCS1-v1_5-DECODE 63
12.2.2. Hash Algorithm Preferences 64 12.1.3. EMSA-PKCS1-v1_5 64
12.3. Plaintext 64 12.2. Symmetric Algorithm Preferences 65
12.4. RSA 64 12.3. Other Algorithm Preferences 65
12.5. DSA 64 12.3.1. Compression Preferences 65
12.6. Elgamal 65 12.3.2. Hash Algorithm Preferences 66
12.7. Reserved Algorithm Numbers 65 12.4. Plaintext 66
12.8. OpenPGP CFB mode 65 12.5. RSA 66
13. Security Considerations 67 12.6. DSA 67
14. Implementation Nits 70 12.7. Elgamal 67
15. Authors' Addresses 70 12.8. Reserved Algorithm Numbers 67
16. References (Normative) 71 12.9. OpenPGP CFB mode 68
17. References (Informative) 73 13. Security Considerations 69
18. Full Copyright Statement 74 14. Implementation Nits 72
15. Authors' Addresses 73
16. References (Normative) 74
17. References (Informative) 76
18. Full Copyright Statement 76
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 RFC 2440, "OpenPGP and key management functions. It is a revision of RFC 2440, "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 17, line 20 skipping to change at page 17, line 20
17 -- User Attribute Packet 17 -- User Attribute Packet
18 -- Sym. Encrypted and Integrity Protected Data Packet 18 -- Sym. Encrypted and Integrity Protected Data Packet
19 -- Modification Detection Code Packet 19 -- Modification Detection Code Packet
60 to 63 -- Private or Experimental Values 60 to 63 -- Private or Experimental Values
5. Packet Types 5. Packet Types
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 5.1. Public-Key Encrypted Session Key Packets (Tag 1)
A Public-Key Encrypted Session Key packet holds the session key used A Public-Key Encrypted Session Key packet holds the session key used
to encrypt a message. Zero or more Encrypted Session Key packets to encrypt a message. Zero or more Public-Key Encrypted Session Key
(either Public-Key or Symmetric-Key) may precede a Symmetrically packets and/or Symmetric-Key Encrypted Session Key packets may
Encrypted Data Packet, which holds an encrypted message. The message precede a Symmetrically Encrypted Data Packet, which holds an
is encrypted with the session key, and the session key is itself encrypted message. The message is encrypted with the session key,
encrypted and stored in the Encrypted Session Key packet(s). The and the session key is itself encrypted and stored in the Encrypted
Symmetrically Encrypted Data Packet is preceded by one Public-Key Session Key packet(s). The Symmetrically Encrypted Data Packet is
Encrypted Session Key packet for each OpenPGP key to which the preceded by one Public-Key Encrypted Session Key packet for each
message is encrypted. The recipient of the message finds a session OpenPGP key to which the message is encrypted. The recipient of the
key that is encrypted to their public key, decrypts the session key, message finds a session key that is encrypted to their public key,
and then uses the session key to decrypt the message. decrypts the 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. The currently defined value for packet version is 3.
- 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.
skipping to change at page 18, line 14 skipping to change at page 18, line 16
- MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
The value "m" in the above formulas is derived from the session key The value "m" in the above formulas is derived from the session key
as follows. First the session key is prefixed with a one-octet as follows. First the session key is prefixed with a one-octet
algorithm identifier that specifies the symmetric encryption algorithm identifier that specifies the symmetric encryption
algorithm used to encrypt the following Symmetrically Encrypted Data algorithm used to encrypt the following Symmetrically Encrypted Data
Packet. Then a two-octet checksum is appended which is equal to the Packet. Then a two-octet checksum is appended which is equal to the
sum of the preceding session key octets, not including the algorithm sum of the preceding session key octets, not including the algorithm
identifier, modulo 65536. This value is then encoded as described in identifier, modulo 65536. This value is then encoded as described in
PKCS-1 block encoding EME-PKCS1-v1_5 [RFC2437] to form the "m" value PKCS#1 block encoding EME-PKCS1-v1_5 in Section 12.1 to form the "m"
used in the formulas above. value used in the formulas above.
Note that when an implementation forms several PKESKs with one Note that when an implementation forms several PKESKs with one
session key, forming a message that can be decrypted by several session key, forming a message that can be decrypted by several
keys, the implementation MUST make a new PKCS-1 encoding for each keys, the implementation MUST make a new PKCS#1 encoding for each
key. key.
An implementation MAY accept or use a Key ID of zero as a "wild An implementation MAY accept or use a Key ID of zero as a "wild
card" or "speculative" Key ID. In this case, the receiving card" or "speculative" Key ID. In this case, the receiving
implementation would try all available private keys, checking for a implementation would try all available private keys, checking for a
valid decrypted session key. This format helps reduce traffic valid decrypted session key. This format helps reduce traffic
analysis of messages. analysis of messages.
5.2. Signature Packet (Tag 2) 5.2. Signature Packet (Tag 2)
skipping to change at page 18, line 49 skipping to change at page 18, line 51
Implementations SHOULD accept V3 signatures. Implementations SHOULD Implementations SHOULD accept V3 signatures. Implementations SHOULD
generate V4 signatures. generate V4 signatures.
Note that if an implementation is creating an encrypted and signed Note that if an implementation is creating an encrypted and signed
message that is encrypted to a V3 key, it is reasonable to create a message that is encrypted to a V3 key, it is reasonable to create a
V3 signature. V3 signature.
5.2.1. Signature Types 5.2.1. Signature Types
There are a number of possible meanings for a signature, which are There are a number of possible meanings for a signature, which are
specified in a signature type octet in any given signature. See indicated in a signature type octet in any given signature. Please
section 5.2.4, "Computing Signatures," for detailed information on note that the vagueness of these meanings is not a flaw, but a
how to compute and verify signatures of each type. feature of the system. Because OpenPGP places final authority for
There are a number of possible meanings for a signature, which may
be indicated in a signature type octet in any given signature.
Please note that the vagueness of these meanings is not a flaw, but
a feature of the system. Because OpenPGP places final authority for
validity upon the receiver of a signature, it may be that one validity upon the receiver of a signature, it may be that one
signer's casual act might be more rigorous than some other signer's casual act might be more rigorous than some other
authority's positive act. authority's positive act. See section 5.2.4, "Computing
Signatures," for detailed information on how to compute and verify
signatures of each type.
These meanings are: These meanings are:
0x00: Signature of a binary document. 0x00: Signature of a binary document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. has not been modified.
0x01: Signature of a canonical text document. 0x01: Signature of a canonical text document.
This means the signer owns it, created it, or certifies that it This means the signer owns it, created it, or certifies that it
has not been modified. The signature is calculated over the text has not been modified. The signature is calculated over the text
skipping to change at page 21, line 47 skipping to change at page 21, line 47
- multiprecision integer (MPI) of RSA signature value m**d mod n. - multiprecision integer (MPI) of RSA signature value m**d mod n.
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 signatures than for 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 as EMSA-PKCS1-v1_5 as described in section 12.1. This requires
an octet string into an ASN.1 structure. The object identifier for inserting the hash value as an octet string into an ASN.1 structure.
the type of hash being used is included in the structure. The The object identifier for the type of hash being used is included in
hexadecimal representations for the currently defined hash the structure. The hexadecimal representations for the currently
algorithms are: defined hash algorithms are:
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
- SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04 - SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04
- SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01 - SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
skipping to change at page 28, line 52 skipping to change at page 28, line 52
addition to an exported key, then this situation can arise. addition to an exported key, then this situation can arise.
Some implementations do not represent the interest of a single user Some implementations do not represent the interest of a single user
(for example, a key server). Such implementations always trim local (for example, a key server). Such implementations always trim local
certifications from any key they handle. certifications from any key they handle.
5.2.3.12. Revocable 5.2.3.12. Revocable
(1 octet of revocability, 0 for not, 1 for revocable) (1 octet of revocability, 0 for not, 1 for revocable)
Signature's revocability status. Packet body contains a Boolean flag Signature's revocability status. The packet body contains a Boolean
indicating whether the signature is revocable. Signatures that are flag indicating whether the signature is revocable. Signatures that
not revocable have any later revocation signatures ignored. They are not revocable have any later revocation signatures ignored. They
represent a commitment by the signer that he cannot revoke his represent a commitment by the signer that he cannot revoke his
signature for the life of his key. If this packet is not present, signature for the life of his key. If this packet is not present,
the signature is revocable. the signature is revocable.
5.2.3.13. Trust signature 5.2.3.13. Trust signature
(1 octet "level" (depth), 1 octet of trust amount) (1 octet "level" (depth), 1 octet of trust amount)
Signer asserts that the key is not only valid, but also trustworthy, Signer asserts that the key is not only valid, but also trustworthy,
at the specified level. Level 0 has the same meaning as an ordinary at the specified level. Level 0 has the same meaning as an ordinary
skipping to change at page 36, line 22 skipping to change at page 36, line 22
suppose a keyholder has an V3 key and a V4 key that share the same suppose a keyholder has an V3 key and a V4 key that share the same
RSA key material. Either of these keys can verify a signature RSA key material. Either of these keys can verify a signature
created by the other, and it may be reasonable for a signature to created by the other, and it may be reasonable for a signature to
contain an issuer subpacket for each key, as a way of explicitly contain an issuer subpacket for each key, as a way of explicitly
tying those keys to the signature. tying those keys to the signature.
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3)
The Symmetric-Key Encrypted Session Key packet holds the The Symmetric-Key Encrypted Session Key packet holds the
symmetric-key encryption of a session key used to encrypt a message. symmetric-key encryption of a session key used to encrypt a message.
Zero or more Encrypted Session Key packets and/or Symmetric-Key Zero or more Public-Key Encrypted Session Key packets and/or
Encrypted Session Key packets may precede a Symmetrically Encrypted Symmetric-Key Encrypted Session Key packets may precede a
Data Packet that holds an encrypted message. The message is Symmetrically Encrypted Data Packet that holds an encrypted message.
encrypted with a session key, and the session key is itself The message is encrypted with a session key, and the session key is
encrypted and stored in the Encrypted Session Key packet or the itself encrypted and stored in the Encrypted Session Key packet or
Symmetric-Key Encrypted Session Key packet. the Symmetric-Key Encrypted Session Key packet.
If the Symmetrically Encrypted Data Packet is preceded by one or If the Symmetrically Encrypted Data Packet is preceded by one or
more Symmetric-Key Encrypted Session Key packets, each specifies a more Symmetric-Key Encrypted Session Key packets, each specifies a
passphrase that may be used to decrypt the message. This allows a passphrase that may be used to decrypt the message. This allows a
message to be encrypted to a number of public keys, and also to one message to be encrypted to a number of public keys, and also to one
or more passphrases. This packet type is new, and is not generated or more passphrases. This packet type is new, and is not generated
by PGP 2.x or PGP 5.0. by PGP 2.x or PGP 5.0.
The body of this packet consists of: The body of this packet consists of:
skipping to change at page 62, line 42 skipping to change at page 62, line 42
material, they will have different key IDs as well as different material, they will have different key IDs as well as different
fingerprints. fingerprints.
Finally, the key ID and fingerprint of a subkey are calculated in Finally, the key ID and fingerprint of a subkey are calculated in
the same way as for a primary key, including the 0x99 as the first the same way as for a primary key, including the 0x99 as the first
octet (even though this is not a valid packet ID for a public octet (even though this is not a valid packet ID for a public
subkey). subkey).
12. Notes on Algorithms 12. Notes on Algorithms
12.1. Symmetric Algorithm Preferences 12.1. PKCS#1 Encoding In OpenPGP
This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and
EMSA-PKCS1-v1_5. However, the calling conventions of these
functions has changed in the past. To avoid potential confusion and
interoperability problems, we are including local copies in this
document, adapted from those in PKCS#1 v2.1 [RFC3447]. RFC-3447
should be treated as the ultimate authority on PKCS#1 for OpenPGP.
Nonetheless, we believe that there is value in having a
self-contained document that avoids problems in the future with
needed changes in the conventions.
12.1.1. EME-PKCS1-v1_5-ENCODE
Input:
k = the length in octets of the key modulus
M = message to be encoded, an octet string of length mLen, where
mLen <= k - 11
Output:
EM = encoded message, an octet string of length k
Error: "message too long"
1. Length checking: If mLen > k - 11, output "message too long" and
stop.
2. Generate an octet string PS of length k - mLen - 3 consisting of
pseudo-randomly generated nonzero octets. The length of PS will
be at least eight octets.
3. Concatenate PS, the message M, and other padding to form an
encoded message EM of length k octets as
EM = 0x00 || 0x02 || PS || 0x00 || M.
4. Output EM.
12.1.2. EME-PKCS1-v1_5-DECODE
Input:
EM = encoded message, an octet string
Output:
M = message, an octet string
Error: "decryption error"
To decode an EME-PKCS1_v1_5 message, separate the encoded message EM
into an octet string PS consisting of nonzero octets and a message M
as
EM = 0x00 || 0x02 || PS || 0x00 || M.
If the first octet of EM does not have hexadecimal value 0x00, if
the second octet of EM does not have hexadecimal value 0x02, if
there is no octet with hexadecimal value 0x00 to separate PS from M,
or if the length of PS is less than 8 octets, output "decryption
error" and stop. See also the security note in section 13 regarding
differences in reporting between a decryption error and a padding
error.
12.1.3. EMSA-PKCS1-v1_5
This encoding method is deterministic and only has an encoding
operation.
Option:
Hash hash function (hLen denotes the length in octets of the hash
function output)
Input:
M = message to be encoded
mL = intended length in octets of the encoded message, at least tLen
+ 11, where tLen is the octet length of the DER encoding T of a
certain value computed during the encoding operation
Output:
EM = encoded message, an octet string of length emLen
Errors: "message too long"; "intended encoded message length too
short"
Steps:
1. Apply the hash function to the message M to produce a hash value
H:
H = Hash(M).
If the hash function outputs "message too long," output "message
too long" and stop.
2. Using the list in section 5.2.2, produce an ASN.1 DER value for
the hash function used. Let T be the full hash prefix from
section 5.2.2, and let tLen be the length in octets of T.
3. If emLen < tLen + 11, output "intended encoded message length
too short" and stop.
4. Generate an octet string PS consisting of emLen - tLen - 3
octets with hexadecimal value 0xff. The length of PS will be at
least 8 octets.
5. Concatenate PS, the hash prefix T, and other padding to form the
encoded message EM as
EM = 0x00 || 0x01 || PS || 0x00 || T.
6. Output EM.
12.2. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature, that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have multiple, different it is possible that a keyholder may have multiple, different
preferences. For example, Alice may have TripleDES only specified preferences. For example, Alice may have TripleDES only specified
for "alice@work.com" but CAST5, Blowfish, and TripleDES specified for "alice@work.com" but CAST5, Blowfish, and TripleDES specified
for "alice@home.org". Note that it is also possible for preferences for "alice@home.org". Note that it is also possible for preferences
to be in a subkey's binding signature. to be in a subkey's binding signature.
Since TripleDES is the MUST-implement algorithm, if it is not Since TripleDES is the MUST-implement algorithm, if it is not
skipping to change at page 63, line 24 skipping to change at page 65, line 42
If an implementation can decrypt a message that a keyholder doesn't If an implementation can decrypt a message that a keyholder doesn't
have in their preferences, the implementation SHOULD decrypt the have in their preferences, the implementation SHOULD decrypt the
message anyway, but MUST warn the keyholder that the protocol has message anyway, but MUST warn the keyholder that the protocol has
been violated. For example, suppose that Alice, above, has software been violated. For example, suppose that Alice, above, has software
that implements all algorithms in this specification. Nonetheless, that implements all algorithms in this specification. Nonetheless,
she prefers subsets for work or home. If she is sent a message she prefers subsets for work or home. If she is sent a message
encrypted with IDEA, which is not in her preferences, the software encrypted with IDEA, which is not in her preferences, the software
warns her that someone sent her an IDEA-encrypted message, but it warns her that someone sent her an IDEA-encrypted message, but it
would ideally decrypt it anyway. would ideally decrypt it anyway.
12.2. Other Algorithm Preferences 12.3. Other Algorithm Preferences
Other algorithm preferences work similarly to the symmetric Other algorithm preferences work similarly to the symmetric
algorithm preference, in that they specify which algorithms the algorithm preference, in that they specify which algorithms the
keyholder accepts. There are two interesting cases that other keyholder accepts. There are two interesting cases that other
comments need to be made about, though, the compression preferences comments need to be made about, though, the compression preferences
and the hash preferences. and the hash preferences.
12.2.1. Compression Preferences 12.3.1. Compression Preferences
Compression has been an integral part of PGP since its first days. Compression has been an integral part of PGP since its first days.
OpenPGP and all previous versions of PGP have offered compression. OpenPGP and all previous versions of PGP have offered compression.
In this specification, the default is for messages to be compressed, In this specification, the default is for messages to be compressed,
although an implementation is not required to do so. Consequently, although an implementation is not required to do so. Consequently,
the compression preference gives a way for a keyholder to request the compression preference gives a way for a keyholder to request
that messages not be compressed, presumably because they are using a that messages not be compressed, presumably because they are using a
minimal implementation that does not include compression. minimal implementation that does not include compression.
Additionally, this gives a keyholder a way to state that it can Additionally, this gives a keyholder a way to state that it can
support alternate algorithms. support alternate algorithms.
skipping to change at page 64, line 5 skipping to change at page 66, line 23
UNCOMPRESSED(0)]. UNCOMPRESSED(0)].
Additionally, an implementation MUST implement this preference to Additionally, an implementation MUST implement this preference to
the degree of recognizing when to send an uncompressed message. A the degree of recognizing when to send an uncompressed message. A
robust implementation would satisfy this requirement by looking at robust implementation would satisfy this requirement by looking at
the recipient's preference and acting accordingly. A minimal the recipient's preference and acting accordingly. A minimal
implementation can satisfy this requirement by never generating a implementation can satisfy this requirement by never generating a
compressed message, since all implementations can handle messages compressed message, since all implementations can handle messages
that have not been compressed. that have not been compressed.
12.2.2. Hash Algorithm Preferences 12.3.2. Hash Algorithm Preferences
Typically, the choice of a hash algorithm is something the signer Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer 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 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 explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly. good form to place it there explicitly.
12.3. Plaintext 12.4. 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.5. RSA
There are algorithm types for RSA-signature-only, and There are algorithm types for RSA-signature-only, and
RSA-encrypt-only keys. These types are deprecated. The "key flags" RSA-encrypt-only keys. These types are deprecated. The "key flags"
subpacket in a signature is a much better way to express the same subpacket in a signature is a much better way to express the same
idea, and generalizes it to all algorithms. An implementation SHOULD idea, and generalizes it to all algorithms. An implementation SHOULD
NOT create such a key, but MAY interpret it. NOT create such a key, but MAY interpret it.
An implementation SHOULD NOT implement RSA keys of size less than An implementation SHOULD NOT implement RSA keys of size less than
1024 bits. 1024 bits.
12.5. DSA 12.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
1024 bits. It MUST NOT implement a DSA signature with a q size of 1024 bits. It MUST NOT implement a DSA key with a q size of less
less than 160 bits. DSA keys MUST also be a multiple of 64 bits, than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the
and the q size MUST be a multiple of 8 bits. The Digital Signature q size MUST be a multiple of 8 bits. The Digital Signature Standard
Standard (DSS) [FIPS186] specifies that DSA be used in one of the (DSS) [FIPS186] specifies that DSA be used in one of the following
following ways: ways:
* 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384 or
SHA-512 hash SHA-512 hash
* 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512 * 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384 or SHA-512
hash hash
* 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 2048-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash
* 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash * 3072-bit key, 256-bit q, SHA-256, SHA-384 or SHA-512 hash
The above key and q size pairs were chosen to best balance the The above key and q size pairs were chosen to best balance the
strength of the key with the strength of the hash. Implementations strength of the key with the strength of the hash. Implementations
SHOULD use one of the above key and q size pairs when generating DSA SHOULD use one of the above key and q size pairs when generating DSA
keys. If DSS compliance is desired, one of the specified SHA hashes keys. If DSS compliance is desired, one of the specified SHA hashes
must be used as well. [FIPS186] is the ultimate authority on DSS, must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance. and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160-bit q Note that earlier versions of this standard only allowed a 160-bit q
skipping to change at page 65, line 18 skipping to change at page 67, line 39
SHOULD use one of the above key and q size pairs when generating DSA SHOULD use one of the above key and q size pairs when generating DSA
keys. If DSS compliance is desired, one of the specified SHA hashes keys. If DSS compliance is desired, one of the specified SHA hashes
must be used as well. [FIPS186] is the ultimate authority on DSS, must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance. and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160-bit q Note that earlier versions of this standard only allowed a 160-bit q
with no truncation allowed, so earlier implementations may not be with no truncation allowed, so earlier implementations may not be
able to handle signatures with a different q size or a truncated able to handle signatures with a different q size or a truncated
hash. hash.
12.6. Elgamal 12.7. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less An implementation SHOULD NOT implement Elgamal keys of size less
than 1024 bits. than 1024 bits.
12.7. Reserved Algorithm Numbers 12.8. Reserved Algorithm Numbers
A number of algorithm IDs have been reserved for algorithms that A number of algorithm IDs have been reserved for algorithms that
would be useful to use in an OpenPGP implementation, yet there are would be useful to use in an OpenPGP implementation, yet there are
issues that prevent an implementer from actually implementing the issues that prevent an implementer from actually implementing the
algorithm. These are marked in the Public Algorithms section as algorithm. These are marked in the Public Algorithms section as
"(reserved for)". "(reserved for)".
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
and X9.42 (21) do not have the necessary parameters, parameter and X9.42 (21) do not have the necessary parameters, parameter
order, or semantics defined. order, or semantics defined.
Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
with a public key identifier of 20. These are no longer permitted. with a public key identifier of 20. These are no longer permitted.
An implementation MUST NOT generate such keys. An implementation An implementation MUST NOT generate such keys. An implementation
MUST NOT generate Elgamal signatures. MUST NOT generate Elgamal signatures.
12.8. OpenPGP CFB mode 12.9. OpenPGP CFB mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback OpenPGP does symmetric encryption using a variant of Cipher Feedback
Mode (CFB mode). This section describes the procedure it uses in Mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Encrypted Data detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret key material is Packets; the mechanism used for encrypting secret key material is
similar, but described in those sections above. similar, but described in those sections above.
In the description below, the value BS is the block size in octets In the description below, the value BS is the block size in octets
of the cipher. Most ciphers have a block size of 8 octets. The AES of the cipher. Most ciphers have a block size of 8 octets. The AES
and Twofish have a block size of 16 octets. Also note that the and Twofish have a block size of 16 octets. Also note that the
skipping to change at page 67, line 25 skipping to change at page 69, line 44
* Certain operations in this specification involve the use of * Certain operations in this specification involve the use of
random numbers. An appropriate entropy source should be used to random numbers. An appropriate entropy source should be used to
generate these numbers. See RFC 1750. generate these numbers. See RFC 1750.
* The MD5 hash algorithm has been found to have weaknesses, with * The MD5 hash algorithm has been found to have weaknesses, with
collisions found in a number of cases. MD5 is deprecated for use collisions found in a number of cases. MD5 is deprecated for use
in OpenPGP. Implementations MUST NOT generate new signatures in OpenPGP. Implementations MUST NOT generate new signatures
using MD5 as a hash function. They MAY continue to consider old using MD5 as a hash function. They MAY continue to consider old
signatures that used MD5 as valid. signatures that used MD5 as valid.
* SHA384 requires the same work as SHA512. In general, there are * SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512
few reasons to use it -- you need a situation where one needs respectively. In general, there are few reasons to use them
more security than SHA256, but does not want to have the 512-bit outside of DSS compatibility. You need a situation where one
data length. needs more security than smaller hashes, but does not want to
have the full 256-bit or 512-bit data length.
* Many security protocol designers think that it is a bad idea to * Many security protocol designers think that it is a bad idea to
use a single key for both privacy (encryption) and integrity use a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces (signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption behind the V4 key format with separate signature and encryption
keys. If you as an implementer promote dual-use keys, you should keys. If you as an implementer promote dual-use keys, you should
at least be aware of this controversy. at least be aware of this controversy.
* The DSA algorithm will work with any hash, but is sensitive to * The DSA algorithm will work with any hash, but is sensitive to
the quality of the hash algorithm. Verifiers should be aware the quality of the hash algorithm. Verifiers should be aware
skipping to change at page 69, line 23 skipping to change at page 71, line 43
1. Implementers treat MDC errors and decompression failures as 1. Implementers treat MDC errors and decompression failures as
security problems. security problems.
2. Implementers implement Modification Detection with all due 2. Implementers implement Modification Detection with all due
speed and encourage its spread. speed and encourage its spread.
3. Users migrate to implementations that support Modification 3. Users migrate to implementations that support Modification
Detection with all due speed. Detection with all due speed.
* PKCS1 has been found to be vulnerable to attacks in which a * PKCS#1 has been found to be vulnerable to attacks in which a
system that reports errors in padding differently from errors in system that reports errors in padding differently from errors in
decryption becomes a random oracle that can leak the private key decryption becomes a random oracle that can leak the private key
in mere millions of queries. Implementations must be aware of in mere millions of queries. Implementations must be aware of
this attack and prevent it from happening. The simplest solution this attack and prevent it from happening. The simplest solution
is report a single error code for all variants of decryption is report a single error code for all variants of decryption
errors so as not to leak information to an attacker. errors so as not to leak information to an attacker.
* 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.
skipping to change at page 73, line 21 skipping to change at page 75, line 40
[RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet [RFC2045] Borenstein, N. and N. Freed, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies.", RFC 2045, November 1996. Message Bodies.", RFC 2045, November 1996.
[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
Cryptography Specifications Version 2.0",
RFC 2437, October 1998.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler, [RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156, "MIME Security with OpenPGP", RFC 3156,
August 2001. August 2001.
[RFC3437] B. Kaliski and J. Staddon, " PKCS #1: RSA
Cryptography Specifications Version 2.1",
RFC 2437, February 2003.
[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 (Informative) 17. References (Informative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
 End of changes. 28 change blocks. 
82 lines changed or deleted 205 lines changed or added

This html diff was produced by rfcdiff 1.30. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/