draft-ietf-openpgp-formats-05.txt   draft-ietf-openpgp-formats-06.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Network Associates Category: INTERNET-DRAFT Network Associates
draft-ietf-openpgp-formats-05.txt draft-ietf-openpgp-formats-06.txt
Expires Dec 1998 Lutz Donnerhacke Expires Jan 1999 Lutz Donnerhacke
June 1998 IN-Root-CA Individual Network e.V. July 1998 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
EIS Corporation EIS Corporation
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-formats-05.txt draft-ietf-openpgp-formats-06.txt
Copyright 1998 by The Internet Society. All Rights Reserved. Copyright 1998 by The Internet Society. All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 2, line 25 skipping to change at page 2, line 25
2.3. Compression 7 2.3. Compression 7
2.4. Conversion to Radix-64 7 2.4. Conversion to Radix-64 7
3. Data Element Formats 7 3. Data Element Formats 7
3.1. Scalar numbers 7 3.1. Scalar numbers 7
3.2. Multi-Precision Integers 7 3.2. Multi-Precision Integers 7
3.3. Key IDs 8 3.3. Key IDs 8
3.4. Text 8 3.4. Text 8
3.5. Time fields 8 3.5. Time fields 8
3.6. String-to-key (S2K) specifiers 8 3.6. String-to-key (S2K) specifiers 8
3.6.1. String-to-key (S2k) specifier types 8 3.6.1. String-to-key (S2k) specifier types 8
3.6.1.1. Simple S2K 8 3.6.1.1. Simple S2K 9
3.6.1.2. Salted S2K 9 3.6.1.2. Salted S2K 9
3.6.1.3. Iterated and Salted S2K 9 3.6.1.3. Iterated and Salted S2K 9
3.6.2. String-to-key usage 10 3.6.2. String-to-key usage 10
3.6.2.1. Secret key encryption 10 3.6.2.1. Secret key encryption 10
3.6.2.2. Symmetric-key message encryption 11 3.6.2.2. Symmetric-key message encryption 11
4. Packet Syntax 11 4. Packet Syntax 11
4.1. Overview 11 4.1. Overview 11
4.2. Packet Headers 11 4.2. Packet Headers 11
4.2.1. Old-Format Packet Lengths 12 4.2.1. Old-Format Packet Lengths 12
4.2.2. New-Format Packet Lengths 12 4.2.2. New-Format Packet Lengths 12
4.2.2.1. One-Octet Lengths 13 4.2.2.1. One-Octet Lengths 13
4.2.2.2. Two-Octet Lengths 13 4.2.2.2. Two-Octet Lengths 13
4.2.2.3. Five-Octet Lengths 13 4.2.2.3. Five-Octet Lengths 13
4.2.2.4. Partial Body Lengths 13 4.2.2.4. Partial Body Lengths 13
4.2.3. Packet Length Examples 13 4.2.3. Packet Length Examples 14
4.3. Packet Tags 14 4.3. Packet Tags 14
5. Packet Types 14 5. Packet Types 15
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 14 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 15
5.2. Signature Packet (Tag 2) 16 5.2. Signature Packet (Tag 2) 16
5.2.1. Signature Types 16 5.2.1. Signature Types 16
5.2.2. Version 3 Signature Packet Format 18 5.2.2. Version 3 Signature Packet Format 18
5.2.3. Version 4 Signature Packet Format 20 5.2.3. Version 4 Signature Packet Format 20
5.2.3.1. Signature Subpacket Specification 20 5.2.3.1. Signature Subpacket Specification 21
5.2.3.2. Signature Subpacket Types 22 5.2.3.2. Signature Subpacket Types 22
5.2.3.3. Signature creation time 22 5.2.3.3. Signature creation time 23
5.2.3.4. Issuer 23 5.2.3.4. Issuer 23
5.2.3.5. Key expiration time 23 5.2.3.5. Key expiration time 23
5.2.3.6. Preferred symmetric algorithms 23 5.2.3.6. Preferred symmetric algorithms 23
5.2.3.7. Preferred hash algorithms 23 5.2.3.7. Preferred hash algorithms 23
5.2.3.8. Preferred compression algorithms 23 5.2.3.8. Preferred compression algorithms 24
5.2.3.9. Signature expiration time 24 5.2.3.9. Signature expiration time 24
5.2.3.10.Exportable 24 5.2.3.10.Exportable Certification 24
5.2.3.11.Revocable 24 5.2.3.11.Revocable 25
5.2.3.12.Trust signature 24 5.2.3.12.Trust signature 25
5.2.3.13.Regular expression 24 5.2.3.13.Regular expression 25
5.2.3.14.Revocation key 25 5.2.3.14.Revocation key 25
5.2.3.15.Notation Data 25 5.2.3.15.Notation Data 26
5.2.3.16.Key server preferences 26 5.2.3.16.Key server preferences 26
5.2.3.17.Preferred key server 26 5.2.3.17.Preferred key server 26
5.2.3.18.Primary user id 26 5.2.3.18.Primary user id 27
5.2.3.19.Policy URL 26 5.2.3.19.Policy URL 27
5.2.3.20.Key Flags 26 5.2.3.20.Key Flags 27
5.2.3.21.Signer's User ID 27 5.2.3.21.Signer's User ID 28
5.2.3.22.Reason for Revocation 27 5.2.3.22.Reason for Revocation 28
5.2.4. Computing Signatures 28 5.2.4. Computing Signatures 29
5.2.4.1. Subpacket Hints 29 5.2.4.1. Subpacket Hints 29
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 29 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 30
5.4. One-Pass Signature Packets (Tag 4) 30 5.4. One-Pass Signature Packets (Tag 4) 31
5.5. Key Material Packet 31 5.5. Key Material Packet 31
5.5.1. Key Packet Variants 31 5.5.1. Key Packet Variants 32
5.5.1.1. Public Key Packet (Tag 6) 31 5.5.1.1. Public Key Packet (Tag 6) 32
5.5.1.2. Public Subkey Packet (Tag 14) 31 5.5.1.2. Public Subkey Packet (Tag 14) 32
5.5.1.3. Secret Key Packet (Tag 5) 31 5.5.1.3. Secret Key Packet (Tag 5) 32
5.5.1.4. Secret Subkey Packet (Tag 7) 31 5.5.1.4. Secret Subkey Packet (Tag 7) 32
5.5.2. Public Key Packet Formats 31 5.5.2. Public Key Packet Formats 32
5.5.3. Secret Key Packet Formats 33 5.5.3. Secret Key Packet Formats 34
5.6. Compressed Data Packet (Tag 8) 35 5.6. Compressed Data Packet (Tag 8) 35
5.7. Symmetrically Encrypted Data Packet (Tag 9) 35 5.7. Symmetrically Encrypted Data Packet (Tag 9) 36
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 36 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 37
5.9. Literal Data Packet (Tag 11) 36 5.9. Literal Data Packet (Tag 11) 37
5.10. Trust Packet (Tag 12) 37 5.10. Trust Packet (Tag 12) 38
5.11. User ID Packet (Tag 13) 37 5.11. User ID Packet (Tag 13) 38
6. Radix-64 Conversions 37 6. Radix-64 Conversions 38
6.1. An Implementation of the CRC-24 in "C" 38 6.1. An Implementation of the CRC-24 in "C" 39
6.2. Forming ASCII Armor 38 6.2. Forming ASCII Armor 39
6.3. Encoding Binary in Radix-64 40 6.3. Encoding Binary in Radix-64 41
6.4. Decoding Radix-64 41 6.4. Decoding Radix-64 42
6.5. Examples of Radix-64 42 6.5. Examples of Radix-64 42
6.6. Example of an ASCII Armored Message 42 6.6. Example of an ASCII Armored Message 43
7. Cleartext signature framework 42 7. Cleartext signature framework 43
7.1. Dash-Escaped Text 43 7.1. Dash-Escaped Text 44
8. Regular Expressions 44 8. Regular Expressions 44
9. Constants 44 9. Constants 45
9.1. Public Key Algorithms 44 9.1. Public Key Algorithms 45
9.2. Symmetric Key Algorithms 45 9.2. Symmetric Key Algorithms 45
9.3. Compression Algorithms 45 9.3. Compression Algorithms 46
9.4. Hash Algorithms 45 9.4. Hash Algorithms 46
10. Packet Composition 46 10. Packet Composition 46
10.1. Transferable Public Keys 46 10.1. Transferable Public Keys 47
10.2. OpenPGP Messages 47 10.2. OpenPGP Messages 48
11. Enhanced Key Formats 47 11. Enhanced Key Formats 48
11.1. Key Structures 47 11.1. Key Structures 48
11.2. Key IDs and Fingerprints 48 11.2. Key IDs and Fingerprints 49
12. Notes on Algorithms 49 12. Notes on Algorithms 50
12.1. Symmetric Algorithm Preferences 49 12.1. Symmetric Algorithm Preferences 50
12.2. Other Algorithm Preferences 50 12.2. Other Algorithm Preferences 51
12.2.1. Compression Preferences 50 12.2.1. Compression Preferences 51
12.2.2. Hash Algorithm Preferences 51 12.2.2. Hash Algorithm Preferences 51
12.3. Plaintext 51 12.3. Plaintext 52
12.4. RSA 51 12.4. RSA 52
12.5. Elgamal 51 12.5. Elgamal 52
12.6. DSA 52 12.6. DSA 53
12.7. OpenPGP CFB mode 52 12.7. Reserved Algorithm Numbers 53
13. Security Considerations 53 12.8. OpenPGP CFB mode 53
14. Implementation Nits 54 13. Security Considerations 54
15. Authors and Working Group Chair 55 14. Implementation Nits 55
16. References 56 15. Authors and Working Group Chair 56
17. Full Copyright Statement 57 16. References 57
17. Full Copyright Statement 58
1. Introduction 1. Introduction
This document provides information on the message-exchange packet This document provides information on the message-exchange packet
formats used by OpenPGP to provide encryption, decryption, signing, formats used by OpenPGP to provide encryption, decryption, signing,
and key management functions. It builds on the foundation provided and key management functions. It builds on the foundation provided
in RFC 1991 "PGP Message Exchange Formats." in RFC 1991 "PGP Message Exchange Formats."
1.1. Terms 1.1. Terms
* OpenPGP - This is a definition for security software that uses * OpenPGP - This is a definition for security software that uses
PGP 5.x as a basis. PGP 5.x as a basis.
* PGP - Pretty Good Privacy. PGP is a family of software systems * PGP - Pretty Good Privacy. PGP is a family of software systems
developed by Philip R. Zimmermann from which OpenPGP is based. developed by Philip R. Zimmermann from which OpenPGP is based.
* PGP 2.6.x - This version of PGP has many variants, hence the * PGP 2.6.x - This version of PGP has many variants, hence the
term PGP 2.6.x. It used only RSA, MD5, and IDEA for its term PGP 2.6.x. It used only RSA, MD5, and IDEA for its
cryptographic transforms. cryptographic transforms. An informational RFC, RFC1991, was
written describing this version of PGP.
* PGP 5.x - This version of PGP is formerly known as "PGP 3" in * PGP 5.x - This version of PGP is formerly known as "PGP 3" in
the community and also in the predecessor of this document, the community and also in the predecessor of this document,
RFC1991. It has new formats and corrects a number of problems in RFC1991. It has new formats and corrects a number of problems in
the PGP 2.6.x design. It is referred to here as PGP 5.x because the PGP 2.6.x design. It is referred to here as PGP 5.x because
that software was the first release of the "PGP 3" code base. that software was the first release of the "PGP 3" code base.
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of
Network Associates, Inc. Network Associates, Inc. and are used with permission.
This document uses the terms "MUST", "SHOULD", and "MAY" as defined
in RFC2119, along with the negated forms of those terms.
2. General functions 2. General functions
OpenPGP provides data integrity services for messages and data files OpenPGP provides data integrity services for messages and data files
by using these core technologies: by using these core technologies:
- digital signatures - digital signatures
- encryption - encryption
skipping to change at page 13, line 4 skipping to change at page 13, line 11
1. A one-octet Body Length header encodes packet lengths of up to 1. A one-octet Body Length header encodes packet lengths of up to
191 octets. 191 octets.
2. A two-octet Body Length header encodes packet lengths of 192 to 2. A two-octet Body Length header encodes packet lengths of 192 to
8383 octets. 8383 octets.
3. A five-octet Body Length header encodes packet lengths of up to 3. A five-octet Body Length header encodes packet lengths of up to
4,294,967,295 (0xFFFFFFFF) octets in length. (This actually 4,294,967,295 (0xFFFFFFFF) octets in length. (This actually
encodes a four-octet scalar number.) encodes a four-octet scalar number.)
4. When the length of the packet body is not known in advance by 4. When the length of the packet body is not known in advance by
the issuer, Partial Body Length headers encode a packet of the issuer, Partial Body Length headers encode a packet of
indeterminite length, effectively making it a stream. indeterminate length, effectively making it a stream.
4.2.2.1. One-Octet Lengths 4.2.2.1. One-Octet Lengths
A one-octet Body Length header encodes a length of from 0 to 191 A one-octet Body Length header encodes a length of from 0 to 191
octets. This type of length header is recognized because the one octets. This type of length header is recognized because the one
octet value is less than 192. The body length is equal to: octet value is less than 192. The body length is equal to:
bodyLen = 1st_octet; bodyLen = 1st_octet;
4.2.2.2. Two-Octet Lengths 4.2.2.2. Two-Octet Lengths
skipping to change at page 13, line 53 skipping to change at page 14, line 8
Each Partial Body Length header is followed by a portion of the Each Partial Body Length header is followed by a portion of the
packet body data. The Partial Body Length header specifies this packet body data. The Partial Body Length header specifies this
portion's length. Another length header (of one of the three types portion's length. Another length header (of one of the three types
-- one octet, two-octet, or partial) follows that portion. The last -- one octet, two-octet, or partial) follows that portion. The last
length header in the packet MUST NOT be a partial Body Length length header in the packet MUST NOT be a partial Body Length
header. Partial Body Length headers may only be used for the header. Partial Body Length headers may only be used for the
non-final parts of the packet. non-final parts of the packet.
4.2.3. Packet Length Examples 4.2.3. Packet Length Examples
These examples show ways that new-format packets might encode the
packet lengths.
A packet with length 100 may have its length encoded in one octet: A packet with length 100 may have its length encoded in one octet:
0x64. This is followed by 100 octets of data. 0x64. This is followed by 100 octets of data.
A packet with length 1723 may have its length coded in two octets: A packet with length 1723 may have its length coded in two octets:
0xC5, 0xFB. This header is followed by the 1723 octets of data. 0xC5, 0xFB. This header is followed by the 1723 octets of data.
A packet with length 100000 may have its length encoded in five A packet with length 100000 may have its length encoded in five
octets: 0xFF, 0x00, 0x01, 0x86, 0xA0. octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.
It might also be encoded in the following octet stream: 0xEF, first It might also be encoded in the following octet stream: 0xEF, first
skipping to change at page 20, line 18 skipping to change at page 20, line 28
- One-octet version number (4). - One-octet version number (4).
- One-octet signature type. - One-octet signature type.
- One-octet public key algorithm. - One-octet public key algorithm.
- One-octet hash algorithm. - One-octet hash algorithm.
- Two-octet scalar octet count for following hashed subpacket - Two-octet scalar octet count for following hashed subpacket
data. data. Note that this is the length in octets of all of the
hashed subpackets; a pointer incremented by this number will
skip over the hashed subpackets.
- Hashed subpacket data. (zero or more subpackets) - Hashed subpacket data. (zero or more subpackets)
- Two-octet scalar octet count for following unhashed subpacket - Two-octet scalar octet count for following unhashed subpacket
data. data. Note that this is the length in octets of all of the
unhashed subpackets; a pointer incremented by this number will
skip over the unhashed subpackets.
- Unhashed subpacket data. (zero or more subpackets) - Unhashed subpacket data. (zero or more subpackets)
- Two-octet field holding left 16 bits of signed hash value. - Two-octet field holding left 16 bits of signed hash value.
- One or more multi-precision integers comprising the signature. - One or more multi-precision integers comprising the signature.
This portion is algorithm specific, as described above. This portion is algorithm specific, as described above.
The data being signed is hashed, and then the signature data from The data being signed is hashed, and then the signature data from
the version number through the hashed subpacket data (inclusive) is the version number through the hashed subpacket data (inclusive) is
skipping to change at page 21, line 31 skipping to change at page 21, line 44
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then if the 1st octet = 255, then
lengthOfLength = 5 lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet] subpacket length = [four-octet scalar starting at 2nd_octet]
The value of the subpacket type octet may be: The value of the subpacket type octet may be:
2 = signature creation time 2 = signature creation time
3 = signature expiration time 3 = signature expiration time
4 = exportable 4 = exportable certification
5 = trust signature 5 = trust signature
6 = regular expression 6 = regular expression
7 = revocable 7 = revocable
9 = key expiration time 9 = key expiration time
10 = placeholder for backward compatibility 10 = placeholder for backward compatibility
11 = preferred symmetric algorithms 11 = preferred symmetric algorithms
12 = revocation key 12 = revocation key
16 = issuer key ID 16 = issuer key ID
20 = notation data 20 = notation data
21 = preferred hash algorithms 21 = preferred hash algorithms
skipping to change at page 24, line 13 skipping to change at page 24, line 27
on a self-signature. on a self-signature.
5.2.3.9. Signature expiration time 5.2.3.9. Signature expiration time
(4 octet time field) (4 octet time field)
The validity period of the signature. This is the number of seconds The validity period of the signature. This is the number of seconds
after the signature creation time that the signature expires. If after the signature creation time that the signature expires. If
this is not present or has a value of zero, it never expires. this is not present or has a value of zero, it never expires.
5.2.3.10. Exportable 5.2.3.10. Exportable Certification
(1 octet of exportability, 0 for not, 1 for exportable) (1 octet of exportability, 0 for not, 1 for exportable)
Signature's exportability status. Packet body contains a boolean This subpacket denotes whether a certification signature is
flag indicating whether the signature is exportable. Signatures that "exportable," to be used by other users than the signature's issuer.
are not exportable are ignored during export and import operations. The packet body contains a boolean flag indicating whether the
If this packet is not present the signature is assumed to be signature is exportable. If this packet is not present, the
exportable. certification is exportable; it is equvalent to a flag containing a
1.
Non-exportable, or "local," certifications are signatures made by a
user to mark a key as valid within that user's implementation only.
Thus, when an implementation prepare's a user's copy of a key for
transport to another user (this is the process of "exporting" the
key), any local certification signatures are deleted from the key.
The receiver of a transported key "imports" it, and likewise trims
any local certifications. In normal operation, there won't be any,
assuming the import is performed on an exported key. However, there
are instances where this can reasonably happen. For example, if an
implementation allows keys to be imported from a key database in
addition to an exported key, then this situation can arise.
Some implementations do not represent the interest of a single user
(for example, a key server). Such implementations always trim local
certifications from any key they handle.
5.2.3.11. Revocable 5.2.3.11. Revocable
(1 octet of revocability, 0 for not, 1 for revocable) (1 octet of revocability, 0 for not, 1 for revocable)
Signature's revocability status. Packet body contains a boolean Signature's revocability status. Packet body contains a boolean
flag indicating whether the signature is revocable. Signatures that flag indicating whether the signature is revocable. Signatures that
are not revocable have any later revocation signatures ignored. are not revocable have any later revocation signatures ignored.
They represent a commitment by the signer that he cannot revoke his They represent a commitment by the signer that he cannot revoke his
signature for the life of his key. If this packet is not present, signature for the life of his key. If this packet is not present,
skipping to change at page 30, line 32 skipping to change at page 31, line 15
If the encrypted session key is present, the result of applying the If the encrypted session key is present, the result of applying the
S2K algorithm to the passphrase is used to decrypt just that S2K algorithm to the passphrase is used to decrypt just that
encrypted session key field, using CFB mode with an IV of all zeros. encrypted session key field, using CFB mode with an IV of all zeros.
The decryption result consists of a one-octet algorithm identifier The decryption result consists of a one-octet algorithm identifier
that specifies the symmetric-key encryption algorithm used to that specifies the symmetric-key encryption algorithm used to
encrypt the following Symmetrically Encrypted Data Packet, followed encrypt the following Symmetrically Encrypted Data Packet, followed
by the session key octets themselves. by the session key octets themselves.
Note: because an all-zero IV is used for this decryption, the S2K Note: because an all-zero IV is used for this decryption, the S2K
specifier MUST use a salt value, either a a Salted S2K or an specifier MUST use a salt value, either a Salted S2K or an
Iterated-Salted S2K. The salt value will insure that the decryption Iterated-Salted S2K. The salt value will insure that the decryption
key is not repeated even if the passphrase is reused. key is not repeated even if the passphrase is reused.
5.4. One-Pass Signature Packets (Tag 4) 5.4. One-Pass Signature Packets (Tag 4)
The One-Pass Signature packet precedes the signed data and contains The One-Pass Signature packet precedes the signed data and contains
enough information to allow the receiver to begin calculating any enough information to allow the receiver to begin calculating any
hashes needed to verify the signature. It allows the Signature hashes needed to verify the signature. It allows the Signature
Packet to be placed at the end of the message, so that the signer Packet to be placed at the end of the message, so that the signer
can compute the entire signed message in one pass. can compute the entire signed message in one pass.
A One-Pass Signature does not interoperate with PGP 2.6.x or A One-Pass Signature does not interoperate with PGP 2.6.x or
earlier. earlier.
The body of this packet consists of: The body of this packet consists of:
- A one-octet version number. The current version is 3. - A one-octet version number. The current version is 3.
- A one-octet signature type. Signature types are described in - A one-octet signature type. Signature types are described in
section 5.2.3. section 5.2.1.
- A one-octet number describing the hash algorithm used. - A one-octet number describing the hash algorithm used.
- A one-octet number describing the public key algorithm used. - A one-octet number describing the public key algorithm used.
- An eight-octet number holding the key ID of the signing key. - An eight-octet number holding the key ID of the signing key.
- A one-octet number holding a flag showing whether the signature - A one-octet number holding a flag showing whether the signature
is nested. A zero value indicates that the next packet is is nested. A zero value indicates that the next packet is
another One-Pass Signature packet that describes another another One-Pass Signature packet that describes another
skipping to change at page 44, line 56 skipping to change at page 45, line 42
9.1. Public Key Algorithms 9.1. Public Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
1 - RSA (Encrypt or Sign) 1 - RSA (Encrypt or Sign)
2 - RSA Encrypt-Only 2 - RSA Encrypt-Only
3 - RSA Sign-Only 3 - RSA Sign-Only
16 - Elgamal (Encrypt-Only), see [ELGAMAL] 16 - Elgamal (Encrypt-Only), see [ELGAMAL]
17 - DSA (Digital Signature Standard) 17 - DSA (Digital Signature Standard)
18 - Elliptic Curve 18 - Elliptic Curve (reserved for)
19 - ECDSA 19 - ECDSA (reserved for)
20 - Elgamal (Encrypt or Sign) 20 - Elgamal (Encrypt or Sign)
21 - Diffie-Hellman (X9.42) 21 - Diffie-Hellman (X9.42, as defined for IETF-S/MIME)
(reserved for)
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement DSA for signatures, and Elgamal for Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys. encryption. Implementations SHOULD implement RSA keys.
Implementations MAY implement any other algorithm. Implementations MAY implement any other algorithm.
9.2. Symmetric Key Algorithms 9.2. Symmetric Key Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Plaintext or unencrypted data 0 - Plaintext or unencrypted data
1 - IDEA 1 - IDEA
2 - Triple-DES (DES-EDE, as per spec - 2 - Triple-DES (DES-EDE, as per spec -
168 bit key derived from 192) 168 bit key derived from 192)
3 - CAST5 (128 bit key) 3 - CAST5 (128 bit key, as per RFC2144)
4 - Blowfish (128 bit key, 16 rounds) 4 - Blowfish (128 bit key, 16 rounds)
5 - SAFER-SK128 (13 rounds) 5 - SAFER-SK128 (13 rounds)
6 - DES/SK 6 - DES/SK (reserved for)
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement Triple-DES. Implementations SHOULD Implementations MUST implement Triple-DES. Implementations SHOULD
implement IDEA and CAST5.Implementations MAY implement any other implement IDEA and CAST5.Implementations MAY implement any other
algorithm. algorithm.
9.3. Compression Algorithms 9.3. Compression Algorithms
ID Algorithm ID Algorithm
-- --------- -- ---------
0 - Uncompressed 0 - Uncompressed
1 - ZIP (RFC1951) 1 - ZIP (RFC1951)
2 - ZLIB (RFC1950) 2 - ZLIB (RFC1950)
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement uncompressed data. Implementations Implementations MUST implement uncompressed data. Implementations
SHOULD implement ZIP. SHOULD implement ZIP. Implementations MAY implement ZLIB.
9.4. Hash Algorithms 9.4. Hash Algorithms
ID Algorithm Text Name ID Algorithm Text Name
-- --------- ---- ---- -- --------- ---- ----
1 - MD5 "MD5" 1 - MD5 "MD5"
2 - SHA-1 "SHA1" 2 - SHA-1 "SHA1"
3 - RIPE-MD/160 "RIPEMD160" 3 - RIPE-MD/160 "RIPEMD160"
4 - HAVAL (5 pass, 160-bit) "HAVAL-5-160" 4 - Reserved for double-width
SHA (experimental)
5 - MD2 "MD2" 5 - MD2 "MD2"
6 - TIGER/192 "TIGER192" 6 - TIGER/192 (reserved for) "TIGER192"
7 - HAVAL (5 pass, 160-bit) "HAVAL-5-160"
(reserved for)
100 to 110 - Private/Experimental algorithm. 100 to 110 - Private/Experimental algorithm.
Implementations MUST implement SHA-1. Implementations SHOULD Implementations MUST implement SHA-1. Implementations SHOULD
implement MD5. implement MD5.
10. Packet Composition 10. Packet Composition
OpenPGP packets are assembled into sequences in order to create OpenPGP packets are assembled into sequences in order to create
messages messages
skipping to change at page 48, line 28 skipping to change at page 49, line 15
Primary-Key Primary-Key
[Revocation Self Signature] [Revocation Self Signature]
[Direct Key Self Signature...] [Direct Key Self Signature...]
User ID [Signature ...] User ID [Signature ...]
[User ID [Signature ...] ...] [User ID [Signature ...] ...]
[[Subkey [Binding-Signature-Revocation] [[Subkey [Binding-Signature-Revocation]
Primary-Key-Binding-Signature] ...] Primary-Key-Binding-Signature] ...]
A subkey always has a single signature after it that is issued using A subkey always has a single signature after it that is issued using
the primary key to tie the two keys together. This binding the primary key to tie the two keys together. This binding
signature may be in either V3 or V4 format, but V4 is prefered, of signature may be in either V3 or V4 format, but V4 is preferred, of
course. course.
In the above diagram, if the binding signature of a subkey has been In the above diagram, if the binding signature of a subkey has been
revoked, the revoked binding signature may be removed, leaving only revoked, the revoked binding signature may be removed, leaving only
one signature. one signature.
In a key that has a main key and subkeys, the primary key MUST be a In a key that has a main key and subkeys, the primary key MUST be a
key capable of signing. The subkeys may be keys of any other type. key capable of signing. The subkeys may be keys of any other type.
There may be other constructions of V4 keys, too. For example, there 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 may be a single-key RSA key in V4 format, a DSA primary key with an
skipping to change at page 49, line 8 skipping to change at page 49, line 45
For a V3 key, the eight-octet key ID consists of the low 64 bits of For a V3 key, the eight-octet key ID consists of the low 64 bits of
the public modulus of the RSA key. the public modulus of the RSA key.
The fingerprint of a V3 key is formed by hashing the body (but not 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 the two-octet length) of the MPIs that form the key material (public
modulus n, followed by exponent e) with MD5. modulus n, followed by exponent e) with MD5.
A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet A V4 fingerprint is the 160-bit SHA-1 hash of the one-octet Packet
Tag, followed by the two-octet packet length, followed by the entire Tag, followed by the two-octet packet length, followed by the entire
Public Key packet starting with the version field. The key ID is Public Key packet starting with the version field. The key ID is
either the low order 64 bits of the fingerprint. Here are the the low order 64 bits of the fingerprint. Here are the fields of
fields of the hash material, with the example of a DSA key: the hash material, with the example of a DSA key:
a.1) 0x99 (1 octet) a.1) 0x99 (1 octet)
a.2) high order length octet of (b)-(f) (1 octet) a.2) high order length octet of (b)-(f) (1 octet)
a.3) low order length octet of (b)-(f) (1 octet) a.3) low order length octet of (b)-(f) (1 octet)
b) version number = 4 (1 octet); b) version number = 4 (1 octet);
c) time stamp of key creation (4 octets); c) time stamp of key creation (4 octets);
d) algorithm (1 octet): 7 = DSA (example); d) algorithm (1 octet): 17 = DSA (example);
e) Algorithm specific fields. e) Algorithm specific fields.
Algorithm Specific Fields for DSA keys (example): Algorithm Specific Fields for DSA keys (example):
e.1) MPI of DSA prime p; e.1) MPI of DSA prime p;
e.2) MPI of DSA group order q (q is a prime divisor of p-1); 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.3) MPI of DSA group generator g;
skipping to change at page 50, line 38 skipping to change at page 51, line 24
An implementation that is striving for backward compatibility MAY An implementation that is striving for backward compatibility MAY
consider a V3 key with a V3 self-signature to be an implicit consider a V3 key with a V3 self-signature to be an implicit
preference for IDEA, and no ability to do TripleDES. This is preference for IDEA, and no ability to do TripleDES. This is
technically non-compliant, but an implementation MAY violate the technically non-compliant, but an implementation MAY violate the
above rule in this case only and use IDEA to encrypt the message, above rule in this case only and use IDEA to encrypt the message,
provided that the message creator is warned. Ideally, though, the provided that the message creator is warned. Ideally, though, the
implementation would follow the rule by actually generating two implementation would follow the rule by actually generating two
messages, because it is possible that the OpenPGP user's messages, because it is possible that the OpenPGP user's
implementation does not have IDEA, and thus could not read the implementation does not have IDEA, and thus could not read the
message. Consenquently, an implementation MAY, but SHOULD NOT use message. Consequently, an implementation MAY, but SHOULD NOT use
IDEA in an algorithm conflict with a V3 key. IDEA in an algorithm conflict with a V3 key.
12.2. Other Algorithm Preferences 12.2. Other Algorithm Preferences
Other algorithm preferences work similarly to the symmetric Other algorithm preferences work similarly to the symmetric
algorithm preference, in that they specify which algorithms the algorithm preference, in that they specify which algorithms the
keyholder accepts. There are two interesting cases that other keyholder accepts. There are two interesting cases that other
comments need to be made about, though, the compression preferences comments need to be made about, though, the compression preferences
and the hash preferences. and the hash preferences.
skipping to change at page 51, line 10 skipping to change at page 51, line 49
And in this specification, the default is for messages to be And in this specification, the default is for messages to be
compressed, although an implementation is not required to do so. compressed, although an implementation is not required to do so.
Consequently, the compression preference gives a way for a keyholder Consequently, the compression preference gives a way for a keyholder
to request that messages not be compressed, presumably because they to request that messages not be compressed, presumably because they
are using a minimal implementation that does not include are using a minimal implementation that does not include
compression. Additionally, this gives a keyholder a way to state compression. Additionally, this gives a keyholder a way to state
that it can support alternate algorithms. that it can support alternate algorithms.
Like the algorithm preferences, an implementation MUST NOT use an Like the algorithm preferences, an implementation MUST NOT use an
algorithm that is not in the preference vector. If the preferences algorithm that is not in the preference vector. If the preferences
are mot present, then they are assumed to be [ZIP(1), are not present, then they are assumed to be [ZIP(1),
UNCOMPRESSED(0)]. UNCOMPRESSED(0)].
12.2.2. Hash Algorithm Preferences 12.2.2. Hash Algorithm Preferences
Typically, the choice of a hash algorithm is something the signer Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer does not typically does, rather than the verifier, because a signer does not typically
know who is going to be verifying the signature. This preference, know who is going to be verifying the signature. This preference,
though, allows a protocol based upon digital signatures ease in though, allows a protocol based upon digital signatures ease in
negotiation. negotiation.
skipping to change at page 52, line 44 skipping to change at page 53, line 29
An implementation SHOULD NOT implement Elgamal keys of size less An implementation SHOULD NOT implement Elgamal keys of size less
than 768 bits. For long-term security, Elgamal keys should be 1024 than 768 bits. For long-term security, Elgamal keys should be 1024
bits or longer. bits or longer.
12.6. DSA 12.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
768 bits. Note that present DSA is limited to a maximum of 1024 bit 768 bits. Note that present DSA is limited to a maximum of 1024 bit
keys, which are recommended for long-term use. keys, which are recommended for long-term use.
12.7. OpenPGP CFB mode 12.7. 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 implementor from actually implementing the
algorithm. These are marked in the Public Algorithms section as
"(reserved for)".
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19),
and X9.42 (21) do not have the necessary parameters, parameter
order, or semantics defined.
The reserved symmetric key algorithm, DES/SK (6), does not have
semantics defined.
The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do
not have OIDs. The reserved algorithm number 4, reserved for a
double-width variant of SHA1, is not presently defined.
12.8. OpenPGP CFB mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback OpenPGP does symmetric encryption using a variant of Cipher Feedback
Mode (CFB mode). This section describes the procedure it uses in Mode (CFB mode). This section describes the procedure it uses in
detail. This mode is what is used for Symmetrically Encrypted Data detail. This mode is what is used for Symmetrically Encrypted Data
Packets; the mechanism used for encrypting secret key material is Packets; the mechanism used for encrypting secret key material is
similar, but described in those sections above. similar, but described in those sections above.
OpenPGP CFB mode uses an initialization vector (IV) of all zeros, OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
and prefixes the plaintext with ten bytes of random data, such that and prefixes the plaintext with ten octets of random data, such that
bytes 9 and 10 match bytes 7 and 8. It does a CFB "resync" after octets 9 and 10 match octets 7 and 8. It does a CFB "resync" after
encrypting those ten bytes. encrypting those ten octets.
Note that for an algorithm that has a larger block size than 64 Note that for an algorithm that has a larger block size than 64
bits, the equivalent function will be done with that entire block. bits, the equivalent function will be done with that entire block.
For example, a 16-octet block algorithm would operate on 16 octets,
and then produce two octets of check, and then work on 16-octet
blocks.
Step by step, here is the procedure: Step by step, here is the procedure:
1. The feedback register (FR) is set to the IV, which is all zeros. 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 2. FR is encrypted to produce FRE (FR Encrypted). This is the
encryption of an all-zero value. encryption of an all-zero value.
3. FRE is xored with the first 8 bytes of random data prefixed to 3. FRE is xored with the first 8 octets of random data prefixed to
the plaintext to produce C1-C8, the first 8 bytes of ciphertext. the plaintext to produce C1-C8, the first 8 octets of
ciphertext.
4. FR is loaded with C1-C8. 4. FR is loaded with C1-C8.
5. FR is encrypted to produce FRE, the encryption of the first 8 5. FR is encrypted to produce FRE, the encryption of the first 8
bytes of ciphertext. octets of ciphertext.
6. The left two bytes of FRE get xored with the next two bytes of 6. The left two octets of FRE get xored with the next two octets of
data that were prefixed to the plaintext. This produces C9-C10, data that were prefixed to the plaintext. This produces C9-C10,
the next two bytes of ciphertext. the next two octets of ciphertext.
7. (The resync step) FR is loaded with C3-C10. 7. (The resync step) FR is loaded with C3-C10.
8. FR is encrypted to produce FRE. 8. FR is encrypted to produce FRE.
9. FRE is xored with the first 8 bytes of the given plaintext, now 9. FRE is xored with the first 8 octets of the given plaintext, now
that we have finished encrypting the 10 bytes of prefixed data. that we have finished encrypting the 10 octets of prefixed data.
This produces C11-C18, the next 8 bytes of ciphertext. This produces C11-C18, the next 8 octets of ciphertext.
10. FR is loaded with C11-C18 10. FR is loaded with C11-C18
11. FR is encrypted to produce FRE. 11. FR is encrypted to produce FRE.
12. FRE is xored with the next 8 bytes of plaintext, to produce the 12. FRE is xored with the next 8 octets of plaintext, to produce the
next 8 bytes of ciphertext. These are loaded into FR and the next 8 octets of ciphertext. These are loaded into FR and the
process is repeated until the plaintext is used up. process is repeated until the plaintext is used up.
13. Security Considerations 13. Security Considerations
As with any technology involving cryptography, you should check the As with any technology involving cryptography, you should check the
current literature to determine if any algorithms used here have current literature to determine if any algorithms used here have
been found to be vulnerable to attack. been found to be vulnerable to attack.
This specification uses Public Key Cryptography technologies. This specification uses Public Key Cryptography technologies.
Possession of the private key portion of a public-private key pair Possession of the private key portion of a public-private key pair
skipping to change at page 55, line 6 skipping to change at page 56, line 12
vexing than large differences. Thus, this list of potential problems vexing than large differences. Thus, this list of potential problems
and gotchas for a developer who is trying to be backward-compatible. and gotchas for a developer who is trying to be backward-compatible.
* PGP 5.x does not accept V4 signatures for anything other than * PGP 5.x does not accept V4 signatures for anything other than
key material. key material.
* PGP 5.x does not recognize the "five-octet" lengths in * PGP 5.x does not recognize the "five-octet" lengths in
new-format headers or in signature subpacket lengths. new-format headers or in signature subpacket lengths.
* PGP 5.0 rejects an encrypted session key if the keylength * PGP 5.0 rejects an encrypted session key if the keylength
differs from the the S2K symmetric algorithm. This is a bug in differs from the S2K symmetric algorithm. This is a bug in its
its validation function. validation function.
* PGP 5.0 does not handle multiple one-pass signature headers and * PGP 5.0 does not handle multiple one-pass signature headers and
trailers. Signing one will compress the one-pass signed literal trailers. Signing one will compress the one-pass signed literal
and prefix a V3 signature instead of doing a nested one-pass and prefix a V3 signature instead of doing a nested one-pass
signature. signature.
* When exporting a private key, PGP 2.x generates the header * When exporting a private key, PGP 2.x generates the header
"BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY "BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY
BLOCK". All previous versions ignore the implied data type, and BLOCK". All previous versions ignore the implied data type, and
look directly at the packet data type. look directly at the packet data type.
skipping to change at page 55, line 31 skipping to change at page 56, line 37
a mismatch between the header and the actual agorithm used. The a mismatch between the header and the actual agorithm used. The
"standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x
rejects the "Hash:" header and assumes MD5. There are a number rejects the "Hash:" header and assumes MD5. There are a number
of enhanced variants of PGP 2.6.x that have been modified for of enhanced variants of PGP 2.6.x that have been modified for
SHA-1 signatures. SHA-1 signatures.
* PGP 5.0 can read an RSA key in V4 format, but can only recognize * PGP 5.0 can read an RSA key in V4 format, but can only recognize
it with a V3 keyid, and can properly use only a V3 format RSA it with a V3 keyid, and can properly use only a V3 format RSA
key. key.
* There are many ways possible for for two keys to have the same * There are many ways possible for two keys to have the same key
key material, but different fingerprints (and thus key ids). material, but different fingerprints (and thus key ids). Perhaps
Perhaps the most interesting is an RSA key that has been the most interesting is an RSA key that has been "upgraded" to
"upgraded" to V4 format, but since a V4 fingerprint is V4 format, but since a V4 fingerprint is constructed by hashing
constructed by hashing the key creation time along with other the key creation time along with other things, two V4 keys
things, two V4 keys created at different times, yet with the created at different times, yet with the same key material will
same key material will have different fingerprints. have different fingerprints.
* If an implemtation is using zlib to interoperate with PGP 2.x, * If an implemtation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
15. Authors and Working Group Chair 15. Authors and Working Group Chair
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
John W. Noerenberg, II John W. Noerenberg, II
Qualcomm, Inc Qualcomm, Inc
skipping to change at page 56, line 33 skipping to change at page 57, line 36
Email: hal@pgp.com Email: hal@pgp.com
Rodney Thayer Rodney Thayer
EIS Corporation EIS Corporation
Clearwater, FL 33767, USA Clearwater, FL 33767, USA
Email: rodney@unitran.com Email: rodney@unitran.com
This draft also draws on much previous work from a number of other This draft also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto, authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Levien, Colin Plumb, Will Price, William Stallings, Mark Weaver, and
Philip R. Zimmermann. Philip R. Zimmermann.
16. References 16. References
[BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal [BLEICHENBACHER] Bleichenbacher, Daniel, "Generating ElGamal
signatures without knowing the secret key," Eurocrypt 96. Note that signatures without knowing the secret key," Eurocrypt 96. Note that
the version in the proceedings has an error. A revised version is the version in the proceedings has an error. A revised version is
available at the time of writing from available at the time of writing from
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps> <ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps>
skipping to change at page 57, line 44 skipping to change at page 58, line 50
[RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and [RFC2044] F. Yergeau., UTF-8, a transformation format of Unicode and
ISO 10646. October 1996. ISO 10646. October 1996.
[RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail [RFC2045] Borenstein, N., and Freed, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies.", Extensions (MIME) Part One: Format of Internet Message Bodies.",
November 1996 November 1996
[RFC2119] Bradner, S., Key words for use in RFCs to Indicate [RFC2119] Bradner, S., Key words for use in RFCs to Indicate
Requirement Level. March 1997. Requirement Level. March 1997.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", May 1997
17. Full Copyright Statement 17. Full Copyright Statement
Copyright 1998 by The Internet Society. All Rights Reserved. Copyright 1998 by The Internet Society. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/