12. Enhanced Key Formats
12.1. Key Structures
The format of an OpenPGP V3 key is as follows. Entries in square
brackets are optional and ellipses indicate repetition.
RSA Public Key
[Revocation Self Signature]
User ID [Signature ...]
[User ID [Signature ...] ...]
Each signature certifies the RSA public key and the preceding User
ID. The RSA public key can have many User IDs and each User ID can
have many signatures. V3 keys are deprecated. Implementations MUST
NOT generate new V3 keys, but MAY continue to use existing ones.
The format of an OpenPGP V4 key that uses multiple public keys is
similar except that the other keys are added to the end as "subkeys"
of the primary key.
[Revocation Self Signature]
[Direct Key Signature...]
User ID [Signature ...]
[User ID [Signature ...] ...]
[User Attribute [Signature ...] ...]
A subkey always has a single signature after it that is issued using
the primary key to tie the two keys together. This binding signature
may be in either V3 or V4 format, but SHOULD be V4. Subkeys that can
issue signatures MUST have a V4 binding signature due to the REQUIRED
embedded primary key binding signature.
In the above diagram, if the binding signature of a subkey has been
revoked, the revoked key may be removed, leaving only one key.
In a V4 key, the primary key MUST be a key capable of certification.
The subkeys may be keys of any other type. There may be other
constructions of V4 keys, too. For example, there may be a single-
key RSA key in V4 format, a DSA primary key with an RSA encryption
key, or RSA primary key with an Elgamal subkey, etc.
It is also possible to have a signature-only subkey. This permits a
primary key that collects certifications (key signatures), but is
used only for certifying subkeys that are used for encryption and
12.2. Key IDs and Fingerprints
For a V3 key, the eight-octet Key ID consists of the low 64 bits of
the public modulus of the RSA key.
The fingerprint of a V3 key is formed by hashing the body (but not
the two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5. Note that both V3 keys
and MD5 are deprecated.
A V4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99,
followed by the two-octet packet length, followed by the entire
Public-Key packet starting with the version field. The Key ID is the
low-order 64 bits of the fingerprint. Here are the fields of the
hash material, with the example of a DSA key:
a.1) 0x99 (1 octet)
a.2) high-order length octet of (b)-(e) (1 octet)
a.3) low-order length octet of (b)-(e) (1 octet)
b) version number = 4 (1 octet);
c) timestamp of key creation (4 octets);
d) algorithm (1 octet): 17 = DSA (example);
e) Algorithm-specific fields.
Algorithm-Specific Fields for DSA keys (example):
e.1) MPI of DSA prime p;
e.2) MPI of DSA group order q (q is a prime divisor of p-1);
e.3) MPI of DSA group generator g;
e.4) MPI of DSA public-key value y (= g**x mod p where x is secret).
Note that it is possible for there to be collisions of Key IDs -- two
different keys with the same Key ID. Note that there is a much
smaller, but still non-zero, probability that two different keys have
the same fingerprint.
Also note that if V3 and V4 format keys share the same RSA key
material, they will have different Key IDs as well as different
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).
13. Notes on Algorithms
13.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.
k = the length in octets of the key modulus
M = message to be encoded, an octet string of length mLen, where
mLen <= k - 11
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
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.
EM = encoded message, an octet string
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
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 14 regarding differences
in reporting between a decryption error and a padding error.
This encoding method is deterministic and only has an encoding
Hash - a hash function in which hLen denotes the length in octets of
the hash function output
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
EM = encoded message, an octet string of length emLen
Errors: "message too long"; "intended encoded message length too
1. Apply the hash function to the message M to produce a hash value
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.
13.2. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature,
it is possible that a keyholder may have multiple, different
preferences. For example, Alice may have TripleDES only specified
for "email@example.com" but CAST5, Blowfish, and TripleDES specified for
"firstname.lastname@example.org". Note that it is also possible for preferences to
be in a subkey's binding signature.
Since TripleDES is the MUST-implement 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. Note also that if an
implementation does not implement the preference, then it is
implicitly a TripleDES-only implementation.
An implementation MUST NOT use a symmetric algorithm that is not in
the recipient's preference list. When encrypting to more than one
recipient, the implementation finds a suitable algorithm by taking
the intersection of the preferences of the recipients. Note that the
MUST-implement algorithm, TripleDES, ensures that the intersection is
not null. The implementation may use any mechanism to pick an
algorithm in the intersection.
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 IDEA-encrypted message, but it
would ideally decrypt it anyway.
13.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
13.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.
Like the algorithm preferences, an implementation MUST NOT use an
algorithm that is not in the preference vector. If the preferences
are not present, then they are assumed to be [ZIP(1),
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.
13.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
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.
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.
There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
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
An implementation SHOULD NOT implement DSA keys of size less than
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
* 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or
* 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512
* 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
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 160-bit q
with no truncation allowed, so earlier implementations may not be
able to handle signatures with a different q size or a truncated
An implementation SHOULD NOT implement Elgamal keys of size less than
13.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 Section 9.1, "Public-Key Algorithms",
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. See [BLEICHENBACHER].
13.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, and is described in the 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
description below assumes that the IV and CFB arrays start with an
index of 1 (unlike the C language, which assumes arrays start with a
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
prefixes the plaintext with BS+2 octets of random data, such that
octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB
resynchronization after encrypting those BS+2 octets.
Thus, for an algorithm that has a block size of 8 octets (64 bits),
the IV is 10 octets long and octets 7 and 8 of the IV are the same as
octets 9 and 10. For an algorithm with a block size of 16 octets
(128 bits), the IV is 18 octets long, and octets 17 and 18 replicate
octets 15 and 16. Those extra two octets are an easy check for a
Step by step, here is the procedure:
1. The feedback register (FR) is set to the IV, which is all zeros.
2. FR is encrypted to produce FRE (FR Encrypted). This is the
encryption of an all-zero value.
3. FRE is xored with the first BS octets of random data prefixed to
the plaintext to produce C through C[BS], the first BS octets
4. FR is loaded with C through C[BS].
5. FR is encrypted to produce FRE, the encryption of the first BS
octets of ciphertext.
6. The left two octets of FRE get xored with the next two octets of
data that were prefixed to the plaintext. This produces C[BS+1]
and C[BS+2], the next two octets of ciphertext.
7. (The resynchronization step) FR is loaded with C through
8. FR is encrypted to produce FRE.
9. FRE is xored with the first BS octets of the given plaintext, now
that we have finished encrypting the BS+2 octets of prefixed
data. This produces C[BS+3] through C[BS+(BS+2)], the next BS
octets of ciphertext.
10. FR is loaded with C[BS+3] to C[BS + (BS+2)] (which is C11-C18 for
an 8-octet block).
11. FR is encrypted to produce FRE.
12. FRE is xored with the next BS octets of plaintext, to produce
the next BS octets of ciphertext. These are loaded into FR, and
the process is repeated until the plaintext is used up.
13.10. Private or Experimental Parameters
S2K specifiers, Signature subpacket types, user attribute types,
image format types, and algorithms described in Section 9 all reserve
the range 100 to 110 for private and experimental use. Packet types
reserve the range 60 to 63 for private and experimental use. These
are intentionally managed with the PRIVATE USE method, as described
However, implementations need to be careful with these and promote
them to full IANA-managed parameters when they grow beyond the
original, limited system.
13.11. Extension of the MDC System
As described in the non-normative explanation in Section 5.13, the
MDC system is uniquely unparameterized in OpenPGP. This was an
intentional decision to avoid cross-grade attacks. If the MDC system
is extended to a stronger hash function, care must be taken to avoid
downgrade and cross-grade attacks.
One simple way to do this is to create new packets for a new MDC.
For example, instead of the MDC system using packets 18 and 19, a new
MDC could use 20 and 21. This has obvious drawbacks (it uses two
packet numbers for each new hash function in a space that is limited
to a maximum of 60).
Another simple way to extend the MDC system is to create new versions
of packet 18, and reflect this in packet 19. For example, suppose
that V2 of packet 18 implicitly used SHA-256. This would require
packet 19 to have a length of 32 octets. The change in the version
in packet 18 and the size of packet 19 prevent a downgrade attack.
There are two drawbacks to this latter approach. The first is that
using the version number of a packet to carry algorithm information
is not tidy from a protocol-design standpoint. It is possible that
there might be several versions of the MDC system in common use, but
this untidiness would reflect untidiness in cryptographic consensus
about hash function security. The second is that different versions
of packet 19 would have to have unique sizes. If there were two
versions each with 256-bit hashes, they could not both have 32-octet
packet 19s without admitting the chance of a cross-grade attack.
Yet another, complex approach to extend the MDC system would be a
hybrid of the two above -- create a new pair of MDC packets that are
fully parameterized, and yet protected from downgrade and cross-
Any change to the MDC system MUST be done through the IETF CONSENSUS
method, as described in [RFC2434].
13.12. Meta-Considerations for Expansion
If OpenPGP is extended in a way that is not backwards-compatible,
meaning that old implementations will not gracefully handle their
absence of a new feature, the extension proposal can be declared in
the key holder's self-signature as part of the Features signature
We cannot state definitively what extensions will not be upwards-
compatible, but typically new algorithms are upwards-compatible,
whereas new packets are not.
If an extension proposal does not update the Features system, it
SHOULD include an explanation of why this is unnecessary. If the
proposal contains neither an extension to the Features system nor an
explanation of why such an extension is unnecessary, the proposal
SHOULD be rejected.
14. Security Considerations
* As with any technology involving cryptography, you should check the
current literature to determine if any algorithms used here have
been found to be vulnerable to attack.
* This specification uses Public-Key Cryptography technologies. It
is assumed that the private key portion of a public-private key
pair is controlled and secured by the proper party or parties.
* Certain operations in this specification involve the use of random
numbers. An appropriate entropy source should be used to generate
these numbers (see [RFC4086]).
* 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.
* SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512,
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 256-bit or 512-bit 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 dual-use 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 that even
if the signer used a strong hash, an attacker could have modified
the signature to use a weak one. Only signatures using acceptably
strong hash algorithms should be accepted as valid.
* As OpenPGP combines many different asymmetric, symmetric, and hash
algorithms, each with different measures of strength, care should
be taken that the weakest element of an OpenPGP message is still
sufficiently strong for the purpose at hand. While consensus about
the strength of a given algorithm may evolve, NIST Special
Publication 800-57 [SP800-57] recommends the following list of
Asymmetric | Hash | Symmetric
key size | size | key size
1024 160 80
2048 224 112
3072 256 128
7680 384 192
15360 512 256
* There is a somewhat-related potential security problem in
signatures. If an attacker can find a message that hashes to the
same hash with a different algorithm, a bogus signature structure
can be constructed that evaluates correctly.
For example, suppose Alice DSA signs message M using hash algorithm
H. Suppose that Mallet finds a message M' that has the same hash
value as M with H'. Mallet can then construct a signature block
that verifies as Alice's signature of M' with H'. However, this
would also constitute a weakness in either H or H' or both. Should
this ever occur, a revision will have to be made to this document
to revise the allowed hash algorithms.
* If you are building an authentication system, the recipient may
specify a preferred signing algorithm. However, the signer would
be foolish to use a weak algorithm simply because the recipient
* Some of the encryption algorithms mentioned in this document have
been analyzed less than others. For example, although CAST5 is
presently considered strong, it has been analyzed less than
TripleDES. Other algorithms may have other controversies
* 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 defeat 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
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
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.
* 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 to
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.
* In winter 2005, Serge Mister and Robert Zuccherato from Entrust
released a paper describing a way that the "quick check" in OpenPGP
CFB mode can be used with a random oracle to decrypt two octets of
every cipher block [MZ05]. They recommend as prevention not using
the quick check at all.
Many implementers have taken this advice to heart for any data that
is symmetrically encrypted and for which the session key is
public-key encrypted. In this case, the quick check is not needed
as the public-key encryption of the session key should guarantee
that it is the right session key. In other cases, the
implementation should use the quick check with care.
On the one hand, there is a danger to using it if there is a random
oracle that can leak information to an attacker. In plainer
language, there is a danger to using the quick check if timing
information about the check can be exposed to an attacker,
particularly via an automated service that allows rapidly repeated
On the other hand, it is inconvenient to the user to be informed
that they typed in the wrong passphrase only after a petabyte of
data is decrypted. There are many cases in cryptographic
engineering where the implementer must use care and wisdom, and
this is one.
15. Implementation Nits
This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous
implementations of PGP are not OpenPGP compliant. Often the
differences are small, but small differences are frequently more
vexing than large differences. Thus, this is a non-comprehensive
list of potential problems and gotchas for a developer who is trying
to be backward-compatible.
* The IDEA algorithm is patented, and yet it is required for PGP
2.x interoperability. It is also the de-facto preferred
algorithm for a V3 key with a V3 self-signature (or no self-
* When exporting a private key, PGP 2.x generates the header "BEGIN
PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK".
All previous versions ignore the implied data type, and look
directly at the packet data type.
* PGP 2.0 through 2.5 generated V2 Public-Key packets. These are
identical to the deprecated V3 keys except for the version
number. An implementation MUST NOT generate them and may accept
or reject them as it sees fit. Some older PGP versions generated
V2 PKESK packets (Tag 1) as well. An implementation may accept
or reject V2 PKESK packets as it sees fit, and MUST NOT generate
* PGP 2.6.x will not accept key-material packets with versions
greater than 3.
* There are many ways possible for two keys to have the same key
material, but different fingerprints (and thus Key IDs). Perhaps
the most interesting is an RSA key that has been "upgraded" to V4
format, but since a V4 fingerprint is constructed by hashing the
key creation time along with other things, two V4 keys created at
different times, yet with the same key material will have
* If an implementation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13.
* The 0x19 back signatures were not required for signing subkeys
until relatively recently. Consequently, there may be keys in
the wild that do not have these back signatures. Implementing
software may handle these keys as it sees fit.
* OpenPGP does not put limits on the size of public keys. However,
larger keys are not necessarily better keys. Larger keys take
more computation time to use, and this can quickly become
impractical. Different OpenPGP implementations may also use
different upper bounds for public key sizes, and so care should
be taken when choosing sizes to maintain interoperability. As of
2007 most implementations have an upper bound of 4096 bits.
* ASCII armor is an optional feature of OpenPGP. The OpenPGP
working group strives for a minimal set of mandatory-to-implement
features, and since there could be useful implementations that
only use binary object formats, this is not a "MUST" feature for
an implementation. For example, an implementation that is using
OpenPGP as a mechanism for file signatures may find ASCII armor
unnecessary. OpenPGP permits an implementation to declare what
features it does and does not support, but ASCII armor is not one
of these. Since most implementations allow binary and armored
objects to be used indiscriminately, an implementation that does
not implement ASCII armor may find itself with compatibility
issues with general-purpose implementations. Moreover,
implementations of OpenPGP-MIME [RFC3156] already have a
[ISO10646] ISO/IEC 10646-1:1993. International Standard --
Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture
and Basic Multilingual Plane.
[JFIF] JPEG File Interchange Format (Version 1.02). Eric
Hamilton, C-Cube Microsystems, Milpitas, CA,
September 1, 1992.
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC
2144, May 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP
26, RFC 2434, October 1998.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T.
Roessler, "MIME Security with OpenPGP", RFC 3156,
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC
4086, June 2005.
[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.
16.2. Informative References
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating Elgamal
signatures without knowing the secret key,"
Eurocrypt 96. Note that the version in the
proceedings has an error. A revised version is
available at the time of writing from
[JKS02] Kahil Jallad, Jonathan Katz, Bruce Schneier
"Implementation of Chosen-Ciphertext Attacks against
PGP and GnuPG" http://www.counterpane.com/pgp-
attack.html[MAURER] Ueli Maurer, "Modelling a Public-Key
Infrastructure", Proc. 1996 European Symposium on
Research in Computer Security (ESORICS' 96), Lecture
Notes in Computer Science, Springer-Verlag, vol.
1146, pp. 325-350, Sep 1996.
[MZ05] Serge Mister, Robert Zuccherato, "An Attack on CFB
Mode Encryption As Used By OpenPGP," IACR ePrint
Archive: Report 2005/033, 8 Feb 2005
http://eprint.iacr.org/2005/033[REGEX] Jeffrey Friedl, "Mastering Regular Expressions,"
O'Reilly, ISBN 0-596-00289-0.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet
Electronic Mail: Part III: Algorithms, Modes, and
Identifiers", RFC 1423, February 1993.
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP
Message Exchange Formats", RFC 1991, August 1996.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R.
Thayer, "OpenPGP Message Format", RFC 2440, November
[SP800-57] NIST Special Publication 800-57, Recommendation on
This memo also draws on much previous work from a number of other
authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc
Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie,
Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings,
Mark Weaver, and Philip R. Zimmermann.
The working group can be contacted via the current chair:
IHTFP Consulting, Inc.
4 Farragut Ave
Somerville, MA 02144 USA
Tel: +1 617 623 3745
The principal authors of this document are as follows:
07745 Jena, Germany
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at