RFC 4880
OpenPGP Message Format
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.
Primary-Key
[Revocation Self Signature]
[Direct Key Signature...]
User ID [Signature ...]
[User ID [Signature ...] ...]
[User Attribute [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-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
signatures.
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
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).
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.
13.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.13.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 follows 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.13.1.3. EMSA-PKCS1-v1_5
This encoding method is deterministic and only has an encoding operation. Option: Hash - a hash function in which 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.
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 "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 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 preferences.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), 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.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 may use. Since SHA1 is the MUST-implement hash algorithm, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly.
13.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.13.5. RSA
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 1024 bits.13.6. DSA
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 ways: * 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or SHA-512 hash * 2048-bit key, 224-bit q, SHA-224, 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 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 hash.
13.7. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less than 1024 bits.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 zero index). 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 correct key.
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[1] through C[BS], the first BS octets
of ciphertext.
4. FR is loaded with C[1] 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[3] through
C[BS+2].
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
in [RFC2434].
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- grade. 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 subpacket. 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
equivalent strengths:
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
requests it.
* 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
surrounding them.
* In late summer 2002, Jallad, Katz, and Schneier published an
interesting attack on the OpenPGP protocol and some of its
implementations [JKS02]. In this attack, the attacker modifies a
message and sends it to a user who then returns the erroneously
decrypted message to the attacker. The attacker is thus using the
user as a random oracle, and can often decrypt the message.
Compressing data can ameliorate this attack. The incorrectly
decrypted data nearly always decompresses in ways that 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
problem.
This attack can be defeated by the use of Modification Detection,
provided that the implementation does not let the user naively
return the data to the attacker. An implementation MUST treat an
MDC failure as a security problem, not merely a data problem.
In either case, the implementation MAY allow the user access to the
erroneous data, but MUST warn the user as to potential security
problems should that data be returned to the sender.
While this attack is somewhat obscure, requiring a special set of
circumstances to create it, it is nonetheless quite serious as it
permits someone to trick a user to decrypt a message.
Consequently, it is important that:
1. Implementers treat MDC errors and decompression failures as
security problems.
2. Implementers implement Modification Detection with all due
speed and encourage its spread.
3. Users migrate to implementations that support Modification
Detection with all due speed.
* 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
queries.
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-
signature).
* 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
them.
* 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
different fingerprints.
* 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
requirement for ASCII armor so those implementations will
necessarily have support.
16. References
16.1. Normative References
[AES] NIST, FIPS PUB 197, "Advanced Encryption Standard
(AES)," November 2001.
http://csrc.nist.gov/publications/fips/fips197/fips-
197.{ps,pdf}
[BLOWFISH] Schneier, B. "Description of a New Variable-Length
Key, 64-Bit Block Cipher (Blowfish)" Fast Software
Encryption, Cambridge Security Workshop Proceedings
(December 1993), Springer-Verlag, 1994, pp191-204
<http://www.counterpane.com/bfsverlag.html>
[BZ2] J. Seward, jseward@acm.org, "The Bzip2 and libbzip2
home page" <http://www.bzip.org/>
[ELGAMAL] T. Elgamal, "A Public-Key Cryptosystem and a
Signature Scheme Based on Discrete Logarithms," IEEE
Transactions on Information Theory, v. IT-31, n. 4,
1985, pp. 469-472.
[FIPS180] Secure Hash Signature Standard (SHS) (FIPS PUB 180-
2).
<http://csrc.nist.gov/publications/fips/fips180-
2/fips180-2withchangenotice.pdf>
[FIPS186] Digital Signature Standard (DSS) (FIPS PUB 186-2).
<http://csrc.nist.gov/publications/fips/fips186-2/
fips186-2-change1.pdf> FIPS 186-3 describes keys
greater than 1024 bits. The latest draft is at:
<http://csrc.nist.gov/publications/drafts/
fips_186-3/Draft-FIPS-186-3%20_March2006.pdf>
[HAC] Alfred Menezes, Paul van Oorschot, and Scott
Vanstone, "Handbook of Applied Cryptography," CRC
Press, 1996.
<http://www.cacr.math.uwaterloo.ca/hac/>
[IDEA] Lai, X, "On the design and security of block
ciphers", ETH Series in Information Processing, J.L.
Massey (editor), Vol. 1, Hartung-Gorre Verlag
Knostanz, Technische Hochschule (Zurich), 1992
[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 1996. [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, April 2001. [RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001. [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 <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti /isc/ElGamal.ps> [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 1998.
[SP800-57] NIST Special Publication 800-57, Recommendation on Key Management <http://csrc.nist.gov/publications/nistpubs/ 800- 57/SP800-57-Part1.pdf> <http://csrc.nist.gov/publications/nistpubs/ 800- 57/SP800-57-Part2.pdf>Acknowledgements
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.Authors' Addresses
The working group can be contacted via the current chair: Derek Atkins IHTFP Consulting, Inc. 4 Farragut Ave Somerville, MA 02144 USA EMail: derek@ihtfp.com Tel: +1 617 623 3745 The principal authors of this document are as follows: Jon Callas EMail: jon@callas.org Lutz Donnerhacke IKS GmbH Wildenbruchstr. 15 07745 Jena, Germany EMail: lutz@iks-jena.de Hal Finney EMail: hal@finney.org David Shaw EMail: dshaw@jabberwocky.com Rodney Thayer EMail: rodney@canola-jones.com
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. Intellectual Property 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 http://www.ietf.org/ipr. 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 ietf-ipr@ietf.org.