 1/draftietfopenpgprfc2440bis16.txt 20060509 22:12:39.000000000 +0200
+++ 2/draftietfopenpgprfc2440bis17.txt 20060509 22:12:39.000000000 +0200
@@ 1,25 +1,25 @@
Network Working Group Jon Callas
Category: INTERNETDRAFT PGP Corporation
draftietfopenpgprfc2440bis16.txt
Expires October 2006 Lutz Donnerhacke
April 2006
+draftietfopenpgprfc2440bis17.txt
+Expires November 2006 Lutz Donnerhacke
+May 2006
Obsoletes: 1991, 2440 Hal Finney
PGP Corporation
David Shaw
Rodney Thayer
OpenPGP Message Format
 draftietfopenpgprfc2440bis16.txt
+ draftietfopenpgprfc2440bis17.txt
Copyright (C) The Internet Society (2006).
IPR Claim Notice
By submitting this InternetDraft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
@@ 208,36 +208,40 @@
9.4. Hash Algorithms 57
10. Packet Composition 58
10.1. Transferable Public Keys 58
10.2. Transferable Secret Keys 59
10.3. OpenPGP Messages 59
10.4. Detached Signatures 60
11. Enhanced Key Formats 60
11.1. Key Structures 60
11.2. Key IDs and Fingerprints 61
12. Notes on Algorithms 62
 12.1. Symmetric Algorithm Preferences 62
 12.2. Other Algorithm Preferences 63
 12.2.1. Compression Preferences 63
 12.2.2. Hash Algorithm Preferences 64
 12.3. Plaintext 64
 12.4. RSA 64
 12.5. DSA 64
 12.6. Elgamal 65
 12.7. Reserved Algorithm Numbers 65
 12.8. OpenPGP CFB mode 65
 13. Security Considerations 67
 14. Implementation Nits 70
 15. Authors' Addresses 70
 16. References (Normative) 71
 17. References (Informative) 73
 18. Full Copyright Statement 74
+ 12.1. PKCS#1 Encoding In OpenPGP 62
+ 12.1.1. EMEPKCS1v1_5ENCODE 63
+ 12.1.2. EMEPKCS1v1_5DECODE 63
+ 12.1.3. EMSAPKCS1v1_5 64
+ 12.2. Symmetric Algorithm Preferences 65
+ 12.3. Other Algorithm Preferences 65
+ 12.3.1. Compression Preferences 65
+ 12.3.2. Hash Algorithm Preferences 66
+ 12.4. Plaintext 66
+ 12.5. RSA 66
+ 12.6. DSA 67
+ 12.7. Elgamal 67
+ 12.8. Reserved Algorithm Numbers 67
+ 12.9. OpenPGP CFB mode 68
+ 13. Security Considerations 69
+ 14. Implementation Nits 72
+ 15. Authors' Addresses 73
+ 16. References (Normative) 74
+ 17. References (Informative) 76
+ 18. Full Copyright Statement 76
1. Introduction
This document provides information on the messageexchange packet
formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It is a revision of RFC 2440, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message
Exchange Formats."
1.1. Terms
@@ 804,30 +808,31 @@
17  User Attribute Packet
18  Sym. Encrypted and Integrity Protected Data Packet
19  Modification Detection Code Packet
60 to 63  Private or Experimental Values
5. Packet Types
5.1. PublicKey Encrypted Session Key Packets (Tag 1)
A PublicKey Encrypted Session Key packet holds the session key used
 to encrypt a message. Zero or more Encrypted Session Key packets
 (either PublicKey or SymmetricKey) may precede a Symmetrically
 Encrypted Data Packet, which holds an encrypted message. The message
 is encrypted with the session key, and the session key is itself
 encrypted and stored in the Encrypted Session Key packet(s). The
 Symmetrically Encrypted Data Packet is preceded by one PublicKey
 Encrypted Session Key packet for each OpenPGP key to which the
 message is encrypted. The recipient of the message finds a session
 key that is encrypted to their public key, decrypts the session key,
 and then uses the session key to decrypt the message.
+ to encrypt a message. Zero or more PublicKey Encrypted Session Key
+ packets and/or SymmetricKey Encrypted Session Key packets may
+ precede a Symmetrically Encrypted Data Packet, which holds an
+ encrypted message. The message is encrypted with the session key,
+ and the session key is itself encrypted and stored in the Encrypted
+ Session Key packet(s). The Symmetrically Encrypted Data Packet is
+ preceded by one PublicKey Encrypted Session Key packet for each
+ OpenPGP key to which the message is encrypted. The recipient of the
+ message finds a session key that is encrypted to their public key,
+ decrypts the session key, and then uses the session key to decrypt
+ the message.
The body of this packet consists of:
 A oneoctet number giving the version number of the packet type.
The currently defined value for packet version is 3.
 An eightoctet number that gives the key ID of the public key
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
here instead of the key ID of the primary key.
@@ 848,26 +853,26 @@
 MPI of Elgamal (DiffieHellman) value m * y**k mod p.
The value "m" in the above formulas is derived from the session key
as follows. First the session key is prefixed with a oneoctet
algorithm identifier that specifies the symmetric encryption
algorithm used to encrypt the following Symmetrically Encrypted Data
Packet. Then a twooctet checksum is appended which is equal to the
sum of the preceding session key octets, not including the algorithm
identifier, modulo 65536. This value is then encoded as described in
 PKCS1 block encoding EMEPKCS1v1_5 [RFC2437] to form the "m" value
 used in the formulas above.
+ PKCS#1 block encoding EMEPKCS1v1_5 in Section 12.1 to form the "m"
+ value used in the formulas above.
Note that when an implementation forms several PKESKs with one
session key, forming a message that can be decrypted by several
 keys, the implementation MUST make a new PKCS1 encoding for each
+ keys, the implementation MUST make a new PKCS#1 encoding for each
key.
An implementation MAY accept or use a Key ID of zero as a "wild
card" or "speculative" Key ID. In this case, the receiving
implementation would try all available private keys, checking for a
valid decrypted session key. This format helps reduce traffic
analysis of messages.
5.2. Signature Packet (Tag 2)
@@ 883,31 +888,28 @@
Implementations SHOULD accept V3 signatures. Implementations SHOULD
generate V4 signatures.
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
V3 signature.
5.2.1. Signature Types
There are a number of possible meanings for a signature, which are
 specified in a signature type octet in any given signature. See
 section 5.2.4, "Computing Signatures," for detailed information on
 how to compute and verify signatures of each type.

 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
+ 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
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:
0x00: Signature of a binary document.
This means the signer owns it, created it, or certifies that it
has not been modified.
0x01: Signature of a canonical text document.
This means the signer owns it, created it, or certifies that it
has not been modified. The signature is calculated over the text
@@ 1035,29 +1037,29 @@
 multiprecision integer (MPI) of RSA signature value m**d mod n.
Algorithm Specific Fields for DSA signatures:
 MPI of DSA value r.
 MPI of DSA value s.
The signature calculation is based on a hash of the signed data, as
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
 PKCS1 section 9.2.1 encoded using PKCS1 encoding type
 EMSAPKCS1v1_5 [RFC2437]. This requires inserting the hash value 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
 hexadecimal representations for the currently defined hash
 algorithms are:
+ PKCS#1 section 9.2.1 encoded using PKCS1 encoding type
+ EMSAPKCS1v1_5 as described in section 12.1. This requires
+ inserting the hash value 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 hexadecimal representations for the currently
+ defined hash algorithms are:
 MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05
 RIPEMD160: 0x2B, 0x24, 0x03, 0x02, 0x01
 SHA1: 0x2B, 0x0E, 0x03, 0x02, 0x1A
 SHA224: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04
 SHA256: 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01
@@ 1399,23 +1401,23 @@
addition to an exported key, then this situation can arise.
Some implementations do not represent the interest of a single user
(for example, a key server). Such implementations always trim local
certifications from any key they handle.
5.2.3.12. Revocable
(1 octet of revocability, 0 for not, 1 for revocable)
 Signature's revocability status. Packet body contains a Boolean flag
 indicating whether the signature is revocable. Signatures that are
 not revocable have any later revocation signatures ignored. They
+ Signature's revocability status. The packet body contains a Boolean
+ flag indicating whether the signature is revocable. Signatures that
+ are not revocable have any later revocation signatures ignored. They
represent a commitment by the signer that he cannot revoke his
signature for the life of his key. If this packet is not present,
the signature is revocable.
5.2.3.13. Trust signature
(1 octet "level" (depth), 1 octet of trust amount)
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
@@ 1784,26 +1786,26 @@
suppose a keyholder has an V3 key and a V4 key that share the same
RSA key material. Either of these keys can verify a signature
created by the other, and it may be reasonable for a signature to
contain an issuer subpacket for each key, as a way of explicitly
tying those keys to the signature.
5.3. SymmetricKey Encrypted Session Key Packets (Tag 3)
The SymmetricKey Encrypted Session Key packet holds the
symmetrickey encryption of a session key used to encrypt a message.
 Zero or more Encrypted Session Key packets and/or SymmetricKey
 Encrypted Session Key packets may precede a Symmetrically Encrypted
 Data Packet that holds an encrypted message. The message is
 encrypted with a session key, and the session key is itself
 encrypted and stored in the Encrypted Session Key packet or the
 SymmetricKey Encrypted Session Key packet.
+ Zero or more PublicKey Encrypted Session Key packets and/or
+ SymmetricKey Encrypted Session Key packets may precede a
+ Symmetrically Encrypted Data Packet that holds an encrypted message.
+ The message is encrypted with a session key, and the session key is
+ itself encrypted and stored in the Encrypted Session Key packet or
+ the SymmetricKey Encrypted Session Key packet.
If the Symmetrically Encrypted Data Packet is preceded by one or
more SymmetricKey Encrypted Session Key packets, each specifies 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
or more passphrases. This packet type is new, and is not generated
by PGP 2.x or PGP 5.0.
The body of this packet consists of:
@@ 3140,21 +3141,140 @@
material, they will have different key IDs as well as different
fingerprints.
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
octet (even though this is not a valid packet ID for a public
subkey).
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 EMEPKCS1v1_5 and
+ EMSAPKCS1v1_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]. RFC3447
+ should be treated as the ultimate authority on PKCS#1 for OpenPGP.
+ Nonetheless, we believe that there is value in having a
+ selfcontained document that avoids problems in the future with
+ needed changes in the conventions.
+
+12.1.1. EMEPKCS1v1_5ENCODE
+
+ 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
+ pseudorandomly 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. EMEPKCS1v1_5DECODE
+
+ Input:
+
+ EM = encoded message, an octet string
+
+ Output:
+
+ M = message, an octet string
+
+ Error: "decryption error"
+
+ To decode an EMEPKCS1_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. EMSAPKCS1v1_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
that the keyholder accepts. Since it is found on a selfsignature,
it is possible that a keyholder may have multiple, different
preferences. For example, Alice may have TripleDES only specified
for "alice@work.com" but CAST5, Blowfish, and TripleDES specified
for "alice@home.org". Note that it is also possible for preferences
to be in a subkey's binding signature.
Since TripleDES is the MUSTimplement algorithm, if it is not
@@ 3174,29 +3294,29 @@
If an implementation can decrypt a message that a keyholder doesn't
have in their preferences, the implementation SHOULD decrypt the
message anyway, but MUST warn the keyholder that the protocol has
been violated. For example, suppose that Alice, above, has software
that implements all algorithms in this specification. Nonetheless,
she prefers subsets for work or home. If she is sent a message
encrypted with IDEA, which is not in her preferences, the software
warns her that someone sent her an IDEAencrypted message, but it
would ideally decrypt it anyway.
12.2. Other Algorithm Preferences
+12.3. Other Algorithm Preferences
Other algorithm preferences work similarly to the symmetric
algorithm preference, in that they specify which algorithms the
keyholder accepts. There are two interesting cases that other
comments need to be made about, though, the compression 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.
OpenPGP and all previous versions of PGP have offered compression.
In this specification, the default is for messages to be compressed,
although an implementation is not required to do so. Consequently,
the compression preference gives a way for a keyholder to request
that messages not be compressed, presumably because they are using a
minimal implementation that does not include compression.
Additionally, this gives a keyholder a way to state that it can
support alternate algorithms.
@@ 3207,70 +3327,71 @@
UNCOMPRESSED(0)].
Additionally, an implementation MUST implement this preference to
the degree of recognizing when to send an uncompressed message. A
robust implementation would satisfy this requirement by looking at
the recipient's preference and acting accordingly. A minimal
implementation can satisfy this requirement by never generating a
compressed message, since all implementations can handle messages
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
does, rather than the verifier, because a signer rarely knows who is
going to be verifying the signature. This preference, though, allows
a protocol based upon digital signatures ease in negotiation.
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
uses. This preference allows Bob to state in his key which
algorithms Alice may use.
Since SHA1 is the MUSTimplement 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.4. Plaintext
Algorithm 0, "plaintext," may only be used to denote secret keys
that are stored in the clear. Implementations MUST NOT use plaintext
in Symmetrically Encrypted Data Packets; they must use Literal Data
Packets to encode unencrypted or literal data.
12.4. RSA
+12.5. RSA
There are algorithm types for RSAsignatureonly, and
RSAencryptonly keys. These types are deprecated. The "key flags"
subpacket in a signature is a much better way to express the same
idea, and generalizes it to all algorithms. An implementation SHOULD
NOT create such a key, but MAY interpret it.
An implementation SHOULD NOT implement RSA keys of size less than
1024 bits.
12.5. DSA
+12.6. DSA
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
 less than 160 bits. DSA keys MUST also be a multiple of 64 bits,
 and the q size MUST be a multiple of 8 bits. The Digital Signature
 Standard (DSS) [FIPS186] specifies that DSA be used in one of the
 following ways:
+ 1024 bits. It MUST NOT implement a DSA key with a q size of less
+ than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the
+ q size MUST be a multiple of 8 bits. The Digital Signature Standard
+ (DSS) [FIPS186] specifies that DSA be used in one of the following
+ ways:
* 1024bit key, 160bit q, SHA1, SHA224, SHA256, SHA384 or
SHA512 hash
* 2048bit key, 224bit q, SHA224, SHA256, SHA384 or SHA512
hash
* 2048bit key, 256bit q, SHA256, SHA384 or SHA512 hash
+
* 3072bit key, 256bit q, SHA256, SHA384 or SHA512 hash
The above key and q size pairs were chosen to best balance the
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
keys. If DSS compliance is desired, one of the specified SHA hashes
must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160bit q
@@ 3271,43 +3392,43 @@
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
must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160bit q
with no truncation allowed, so earlier implementations may not be
able to handle signatures with a different q size or a truncated
hash.
12.6. Elgamal
+12.7. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less
than 1024 bits.
12.7. Reserved Algorithm Numbers
+12.8. Reserved Algorithm Numbers
A number of algorithm IDs have been reserved for algorithms that
would be useful to use in an OpenPGP implementation, yet there are
issues that prevent an implementer from actually implementing the
algorithm. These are marked in the Public Algorithms section as
"(reserved for)".
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
and X9.42 (21) do not have the necessary parameters, parameter
order, or semantics defined.
Previous versions of OpenPGP permitted Elgamal [ELGAMAL] signatures
with a public key identifier of 20. These are no longer permitted.
An implementation MUST NOT generate such keys. An implementation
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
Mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret key material is
similar, but described in those sections above.
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
and Twofish have a block size of 16 octets. Also note that the
@@ 3379,24 +3500,25 @@
* Certain operations in this specification involve the use of
random numbers. An appropriate entropy source should be used to
generate these numbers. See RFC 1750.
* The MD5 hash algorithm has been found to have weaknesses, with
collisions found in a number of cases. MD5 is deprecated for use
in OpenPGP. Implementations MUST NOT generate new signatures
using MD5 as a hash function. They MAY continue to consider old
signatures that used MD5 as valid.
 * SHA384 requires the same work as SHA512. In general, there are
 few reasons to use it  you need a situation where one needs
 more security than SHA256, but does not want to have the 512bit
 data length.
+ * SHA224 and SHA384 require the same work as SHA256 and SHA512
+ respectively. In general, there are few reasons to use them
+ outside of DSS compatibility. You need a situation where one
+ needs more security than smaller hashes, but does not want to
+ have the full 256bit or 512bit data length.
* Many security protocol designers think that it is a bad idea to
use a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption
keys. If you as an implementer promote dualuse keys, you should
at least be aware of this controversy.
* The DSA algorithm will work with any hash, but is sensitive to
the quality of the hash algorithm. Verifiers should be aware
@@ 3481,21 +3603,21 @@
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.
 * 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
decryption becomes a random oracle that can leak the private key
in mere millions of queries. Implementations must be aware of
this attack and prevent it from happening. The simplest solution
is report a single error code for all variants of decryption
errors so as not to leak information to an attacker.
* Some technologies mentioned here may be subject to government
control in some countries.
@@ 3683,30 +3804,30 @@
[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 CAST128 Encryption Algorithm", RFC
2144, May 1997.
[RFC2279] Yergeau., F., "UTF8, a transformation format of
Unicode and ISO 10646", RFC 2279, January 1998.
 [RFC2437] B. Kaliski and J. Staddon, " PKCS #1: RSA
 Cryptography Specifications Version 2.0",
 RFC 2437, October 1998.

[RFC2822] Resnick, P., "Internet Message Format", RFC 2822.
[RFC3156] M. Elkins, D. Del Torto, R. Levien, T. Roessler,
"MIME Security with OpenPGP", RFC 3156,
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:
protocols, algorithms, and source code in C", 1996.
[TWOFISH] B. Schneier, J. Kelsey, D. Whiting, D. Wagner, C.
Hall, and N. Ferguson, "The Twofish Encryption
Algorithm", John Wiley & Sons, 1999.
17. References (Informative)
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal