Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4880

OpenPGP Message Format

Pages: 90
Proposed Standard
Errata
Obsoletes:  19912440
Updated by:  5581
Part 5 of 5 – Pages 70 to 90
First   Prev   None

Top   ToC   RFC4880 - Page 70   prevText

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.
Top   ToC   RFC4880 - Page 71
           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)
Top   ToC   RFC4880 - Page 72
   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.
Top   ToC   RFC4880 - Page 73

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.
Top   ToC   RFC4880 - Page 74
   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.
Top   ToC   RFC4880 - Page 75
     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.
Top   ToC   RFC4880 - Page 76

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.
Top   ToC   RFC4880 - Page 77

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.
Top   ToC   RFC4880 - Page 78

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.
Top   ToC   RFC4880 - Page 79
   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].
Top   ToC   RFC4880 - Page 80
   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
Top   ToC   RFC4880 - Page 81
   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.
Top   ToC   RFC4880 - Page 82
   * 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.
Top   ToC   RFC4880 - Page 83
   * 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.
Top   ToC   RFC4880 - Page 84
   * 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.
Top   ToC   RFC4880 - Page 85
     * 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
Top   ToC   RFC4880 - Page 86
       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
Top   ToC   RFC4880 - Page 87
   [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.
Top   ToC   RFC4880 - Page 88
   [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.
Top   ToC   RFC4880 - Page 89
   [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
Top   ToC   RFC4880 - Page 90
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.