Internet DRAFT - draft-ietf-pgp-formats
draft-ietf-pgp-formats
INTERNET-DRAFT Gail Haspert
Security PGP, Inc.
Expires in six months Editor
July 30 1997
PGP Message Exchange Formats
<draft-ietf-pgp-formats00.txt>
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check
the "1id-abstracts.txt" listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
In order to release information about PGP 5.x prior to the Birds
of a Feather discussion at the 39th IETF Conference in Munich, we
wanted people to have the opportunity to review the current
specification of the published PGP source code. This document is
the cookbook for the source code. Completion of items marked TBD
will be done by end of October, 1997.
Abstract
PGP (Pretty Good Privacy) software uses a combination of public-key
and conventional encryption to provide strong security services
for e-mail, EDI, and data files. These services include confidentiality,
authorization, authentication and digital signature. This document
specifies the message formats used in version 5.x, fully backward-
compatible with earlier PGP versions.
Since PGP first became available in 1991, it is now the worldwide
de facto standard for securing electronic communications. It has
achieve this success through international availability and the
unique distributed "Web-of-Trust" model to create the current PGP
Public Key Infrastructure for storing and obtaining
'PGP-formatted-certificates.'
PGP Formats - Open PGP BOF Page 1
Table of Contents
1. Introduction......................................3
2. PGP Services......................................3
2.1 Digital signature.................................3
2.2 Confidentiality...................................4
2.3 Compression.......................................4
2.4 Radix-64 conversion...............................4
2.4.1 ASCII Armor Formats...............................5
3. Data Element Formats..............................6
3.1 Scalar numbers....................................6
3.2 Multi-Precision Integers..........................6
3.3 Strings...........................................7
3.4 Time fields.......................................7
4. Packets...........................................7
4.1 Overview..........................................7
4.2 Packet Headers....................................7
4.3 Packet Tags.......................................8
5. Packet Types......................................9
5.1 Encrypted Session Key Packets.....................9
5.2 Conventional Encrypted Session-Key Packets........9
5.3 One-Pass Signature Packets........................9
5.4 Symmetrically Encrypted Data Packet..............10
5.5 Compressed Data Packet...........................10
5.6 Literal Data Packet..............................10
5.7 Obsolete Literal Packet..........................11
5.8 Key Material Packet..............................11
5.9 User-Name Packet.................................12
5.10 Signature Packets................................12
6. Constants........................................13
6.1 Public Key Algorithms............................13
6.2 Symmetric Key Algorithms.........................13
6.3 Compression Algorithms...........................13
6.4 Hash Algorithms..................................13
7. Transferable Public Keys.........................13
8. PGP 5.0 Enhanced Key Formats.....................14
8.1 Key Structures...................................14
8.2 Public Key Certificate Packet Structure..........15
8.3 Signature Packet Structure.......................16
8.4 Diffie-Hellman/DSS Key IDs and Fingerprints......18
8.5 New Algorithm and Signature Classification Types.18
8.6 Interoperability.................................18
8.7 Future Formats...................................19
PGP Formats - Open PGP BOF Page 2
1. Introduction
This document provides information on the message-exchange packet
formats used by PGP to provide encryption, decryption, and signing
functions. It builds on the foundation provided RFC 1991, PGP
Message Exchange Formats and RFC 2015, MIME Security with Pretty
Good Privacy (PGP). PGP and is the collective work of a number of
contributing authors. Those authors include, (alphabetical order):
Derek Atkins, Charles Breed, Jon Callas, Dave Del Torto, Marc
Dyksterhouse, Gail Haspert, Gene Hoffman, Raph Levine, Colin Plumb,
Will Price, William Stallings, Mark Weaver, and Philip R. Zimmermann.
A special thank you goes to Paul Hoffman for hosting and managing
the mail lists for PGP.PGP (Pretty Good Privacy) uses a combination
of public-key and conventional encryption to provide security
services for electronic mail messages, electronic data interchange
(EDI) and data files. These services include confidentiality and
digital signature. PGP is widely used throughout the global computer
community. This document describes the format of "PGP files",
i.e., messages that have been encrypted and/or signed 1991. Subsequent
versions have been designed and implemented by a combination of
volunteers and PGP, Inc. in a collaborative effort under the design
guidance of Philip Zimmermann. PGP and Pretty Good Privacy are
trademarks of Pretty Good Privacy, Inc.
2. PGP Services
PGP provides four services related to the format of messages and data files:
-digital signature
-encryption
-compression
-radix-64 conversion
2.1 Digital signature
The digital signature uses a hash code or
message digest algorithm, and a public-key encryption algorithm. The
sequence is as follows:
1. The sender creates a message
2. The sending PGP generates a hash code of the message
3. The sending PGP encrypts the hash code using the sender's
private key.
4. The encrypted hash code is prepended to the message
5. The receiving PGP decrypts the hash code using the sender's
public key.
6. The receiving PGP generates a new hash code for the received
message and compares it to the decrypted hash code. If the two
match, the message is accepted as authentic.
PGP Formats - Open PGP BOF Page 3
2.2 Confidentiality
PGP provides confidentiality by encrypting messages to be transmitted
or data files to be stored locally using conventional encryption. In
PGP, each conventional key is used only once. That is, a new key is
generated as a random 128-bit number for each message. Since it is to
be used only once, the session key is bound to the message and
transmitted with it. To protect the key, it is encrypted with the
receiver's public key. The sequence is as follows:
1. The sender creates a message.
2. The sending PGP generates a random number to be used as a
session key for this message only.
3. The sending PGP encrypts the message using the session key.
4. The session key is encrypted using the recipient's public key
and is prepended to the encrypted message.
5. The receiving PGP decrypts the session key using the recipient's
private key.
6. The receiving PGP decrypts the message using the session key.
Both digital signature and confidentiality services may be applied to
the same message. First, a signature is generated for the message and
prepended to the message. Then, the message plus signature is
encrypted using a conventional session key. Finally, the session key
is encrypted using public-key encryption and prepended to the
encrypted block.
2.3 Compression
As a default, PGP compresses the message after applying the signature
but before encryption.
2.4 Radix-64 conversion
When using PGP to sign clear text, or to encrypt and/or sign a
message a resulting encrypted block must either accompany or travel
in place of the message block. Thus, part or all of the resulting
block consists of a stream of arbitrary octets. Many electronic mail
systems only permit the use of blocks consisting of ASCII text. To
accommodate this restriction, PGP provides the service of converting
the raw 8-bit binary octet stream to a stream of printable ASCII
characters, called Radix-64 encoding or ASCII Armor.
Similar to MIME encoding, the process of Radix-64 encoding an 8-bit
binary stream of data is as follows. Every three subsequent 8 bit
binary octets are mapped into four subsequent 6-bit ASCII characters.
Radix-64 encoding also appends a CRC to detect transmission errors.
This radix-64 conversion, is a wrapper around the binary PGP
messages, and is used to protect the binary messages during
transmission over non-binary channels, such as Internet Email.
The following table defines the mapping. The characters used are the
upper- and lower-case letters, the digits 0 through 9, and the
characters + and /. The carriage-return and linefeed characters
aren't used in the conversion, nor is the tab or any other character
that might be altered by the mail system. The result is a text file
that is "immune" to the modifications inflicted by mail systems.
PGP Formats - Open PGP BOF Page 4
To encode an arbitrary 3 octets, separate the bit stream logically
into four 6-bit groups, calculate the decimal value of the 6-bit
group, and replace it with the corresponding character from the table
below. Decoding is the exact opposite operation.
6-bit Value Mapped to Character Encoding
6-bit character 6-bit character 6-bit character 6-bit character
value encoding value encoding value encoding value encoding
0 A 16 Q 32 g 48 w
1 B 17 R 33 h 49 x
2 C 18 S 34 i 50 y
3 D 19 T 35 j 51 z
4 E 20 U 36 k 52 0
5 F 21 V 37 l 53 1
6 G 22 W 38 m 54 2
7 H 23 X 39 n 55 3
8 I 24 Y 40 o 56 4
9 J 25 Z 41 p 57 5
1 K 26 a 42 q 58 6
11 L 27 b 43 r 59 7
12 M 28 c 44 s 60 8
13 N 29 d 45 t 61 9
14 O 30 e 46 u 62 +
15 P 31 f 47 v 63 /
(pad) =
Hex octet 0x17 0x3A 0xA3
Example: Binary stream 00010111 00111010 10100011
Translate to 6bit 000101 110011 101010 100011
Decimal 5 51 42 35
Final Character F z q j
It is possible to use PGP to convert any arbitrary file to ASCII
Armor. When this is done, PGP tries to compress the data before it
is converted to Radix-64.
2.4.1 ASCII Armor Formats
When PGP encodes data into ASCII Armor, it puts specific headers
around the data, so PGP can reconstruct the data at a future time.
PGP tries to inform the user what kind of data is encoded in the
ASCII armor through the use of the headers.
ASCII Armor is created by concatenating the following data:
- An Armor Headerline, appropriate for the type of data
- Armor Headers
- A blank line
- The ASCII-Armored data
- An Armor Checksum
- The Armor Tail, which depends on the Armor Headerline.
PGP Formats - Open PGP BOF Page 5
An Armor Headerline is composed by taking the appropriate headerline
text surrounded by five (5) dashes (-) on either side of the
headerline text. The headerline text is chosen based upon the type
of data that is being encoded in Armor, and how it is being encoded.
Headerline texts include the following strings:
BEGIN PGP MESSAGE -- used for signed, encrypted, or compressed files
BEGIN PGP PUBLIC KEY BLOCK -- used for transferring public keys
BEGIN PGP MESSAGE, PART X/Y -- used for multi-part messages, where
the armor is split amongst Y files,
and this is the Xth file out of Y.
The Armor Headers are pairs of strings that can give the user or the
receiving PGP message block some information about how to decode or
use the message. The Armor Headers are a part of the armor, not a
part of the message, and hence should not be used to convey any
important information, since they can be changed in transport.
The format of an Armor Header is that of a key-value pair. PGP
should consider improperly formatted Armor Headers to be corruption
of the ASCII Armor. Unknown keys should be reported to the user, but
PGP should continue to process the message. Currently defined Armor
Header Keys include "Version" and "Comment," which define the PGP
Version used to encode the message and a user-defined comment.
The Armor Checksum is a 24-bit CRC converted to four characters of
radix-64 encoding, prepending an equal-sign (=) to the four character code.
The CRC is computed by using the generator 0x864CFB and an initialization
of 0xB704CE. The accumulation is done on the data before it is converted
to radix-64, rather than on the converted data. For more information on
CRC functions, the reader is asked to look at chapter 19 of the book
"C Programmer's Guide to Serial Communications," by Joe Campbell.
The Armor Tail is composed in the same manner as the Armor
Headerline, except the string "BEGIN" is replaced by the string
"END."
3. Data Element Formats
This section describes the data elements used by PGP.
3.1 Scalar numbers
Scalar numbers are unsigned, and are always stored in big-endian format.
Thus, the value of a two-octet scalar is ((n[0] << 8) + n[1]). The value
of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]).
3.2 Multi-Precision Integers
Multi-Precision Integers (also called MPIs) are unsigned integers used to
hold large integers such as ones used in cryptographic calculations.
An MPI consists of two pieces: a two-octet scalar that is the length of
the MPI in bits followed by a string of octets that contain the actual integer.
These octets form a big-endian number; a big-endian number can be made into an
MPI by prefixing it with the appropriate length.
PGP Formats - Open PGP BOF Page 6
Examples:
(all numbers are in hexadecimal)
The string of octets [00 01 01] forms an MPI that has a value of 1. The string
[00 09 01 ff] forms an MPI with the value of 511.
Additional rules:
The size of an MPI is ((MPI.length + 7) / 8) + 2.
The length field of an MPI describes the length starting from its most
significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly.
It should be [00 01 01].
3.3 Strings
A string consists of a one-octet length and then N octets of string data.
3.4 Time fields
A time field is a four-octet number containing the number of seconds
elapsed since midnight, 1 January 1970 GMT.
4. Packets
This section describes the packets used by PGP.
4.1 Overview
A packet is a chunk of data that has a tag specifying its meaning. A PGP
message, keyring, certificate, and so forth consists of a number of packets.
Some of those packets may contain other PGP packets (for example, a
compressed data packet, when uncompressed, contains PGP packets).
Each packet consists of a packet header, followed by the packet body.
The packet header is of variable length.
4.2 Packet Headers
The first octet of the packet header is called the "Cipher Type Byte."
It determines the format of the header. Its high-order bit (0x80) must be set.
If the next bit (0x40) is set, it is a new format packet.
If it is clear, then it is an old format packet. New format packets can only be
decoded by PGP V5.0 or later. Thus, software that needs to be compatible
with earlier versions of PGP must only use old format packets.
In an old format packet, the packet tag resides in the middle four bits
((ctb & 0x3c) >> 2). The two low order bits (ctb & 0x3) denote the number
of octets following the CTB that hold the length of the packet body.
The meaning of the length-type is:
PGP Formats - Open PGP BOF Page 7
0 - The packet has a one-octet length. The header is 2 octets long.
1 - The packet has a two-octet length. The header is 3 octets long.
2 - The packet has a four-octet length. The header is 5 octets long.
3 - The packet is of indeterminate length. The header is 1 byte long,
and the application must determine how long the packet is. If the packet
is in a file, this means that the packet extends until the end of the file.
In general, an application should not use indeterminate length packets.
In a new format packet, the low-order six bits (cth & 0x3f) form the packet tag.
The length of the packet is found in the next one or two octets, thus:
If the next octet is 191 or less, then that is the length of the packet
body. If that octet is between 192 and 223, then the length of the packet
body is held in the two octets following the CTB with the following formula:
bodyLen = ((p[1] - 192) * 256) + p[2] + 192;
Note that this yields a maximum packet body length of 8383 octets for this type of
packet.
If the second octet is 224 or greater (note that 224 is E0 in hexadecimal, or
11100000 in binary), then the low-order five bits form the length of the
packet body with the formula:
bodyLen = 1 << (p[1] & 0x1f);
In English, the packet body length is a power of two. Its maximum length
is 2**31 octets long. Note that there is no way to form a new-format packet
that is longer than 8383 octets and not a power of two in length.
Please note that in all of these explanations, the total length of the
packet is the length of the header plus the length of the body.
4.3 Packet Tags
The packet tag denotes what type of packet the body holds. Note that old
format packets can only have tags less than 16, whereas new format packets
can have tags as great as 63. The defined tags are:
0 -- Reserved. A packet must not have a tag with this value.
1 -- Encrypted Session Key Packet
2 -- Signature Packet
3 -- Conventionally Encrypted Session Key Packet
4 -- One-Pass Signature Packet
5 -- Secret Key Packet
6 -- Public Key Packet
7 -- Secret Subkey Packet
8 -- Compressed Data Packet
9 -- Symmetrically Encrypted Data Packet
10 -- Obsolete Literal Packet
11 -- Literal Data Packet
12 -- Trust Packet
13 -- Name Packet
PGP Formats - Open PGP BOF Page 8
14 -- Subkey Packet
15 -- Reserved
16 -- Comment Packet
5.0 Packet Types
This section describes some of the more interesting packet types.
5.1 Encrypted Session Key Packets
The encrypted session key packet (tag 1) describes how a message is
encrypted. One or more of these packets precede a Symmetrically
Encrypted Data Packet, for each PGP key the message is encrypted to.
The recipient of the message finds a session key that is encrypted
to their public key, decrypts the session key, and then uses the
session key to decrypt the message.
The body of this packet consists of:
- A one-octet number giving the version number of the packet type,
either 2 or 3. All modern versions of PGP generate type 3
packets.
- - An eight-octet number that gives the ID of the public key that
the session key is encrypted to.
- A one-octet number giving the public-key algorithm used.
- - A string of octets that is the encrypted session key. This
string takes up the remainder of the packet, but is not
explicitly counted.
5.2 Conventional Encrypted Session-Key Packets
This packet (tag 3) describes a session key that has been encrypted to a
secondary symmetric cipher. This allows a message to be encrypted to a
number of public keys, and also to one or more pass phrases. This packet
type is new, and is not generated by PGP 2.x or PGP 5.0.
The body of this packet consists of:
- A one-octet version number. The current version is 4.
- A one-octet number describing the symmetric algorithm used.
- A "string-to-key" object. This is described below. It is 2, 10,
or 11 octets long.
- The encrypted session key itself, which is decrypted with the
string-to-key object.
The string-to-key object has this format:
<To be written in a future draft.>
5.3 One-Pass Signature Packets
This packet (tag 4) is also a new packet type, but may be generated by PGP
5.0 or later. This in an in-line packet that tells the processing software
how to compute a signature so that it does not have to read the entire
message before starting.
PGP Formats - Open PGP BOF Page 9
The body of this packet consists of:
- A one-octet version number. The current version is 3.
- A one-octet signature type. Signature types are described later
in this document.
- A one-octet number describing the hash algorithm used.
- A one-octet number describing the public key algorithm used.
- An eight-octet number holding the key ID of the signing key.
- A one-octet number holding a flag showing if the signature is
nested.
5.4 Symmetrically Encrypted Data Packet
This packet (tag 9) contains encrypted data. When it has been decrypted,
it will typically contain other packets (often literal data packets or
compressed data packets).
The body of this packet consists of:
- Eight octets of initialization data. This is arbitrarily chosen
material that starts the encryption engine. This serves a
similar purpose to an initialization vector in a cipher-block-
chaining engine. It helps to reduce the chance of information
leaks caused by known-plaintext attacks.
- - Two octets of data that are used to check the decryption
process. The seventh and eighth octets of decrypted data must
match these two octets.
- The remainder of the packet is encrypted data.
5.5 Compressed Data Packet
This packet (tag 8) contains compressed data. Typically, this packet is
found as the contents of an encrypted packet, and contains literal data
packets.
The body of this packet consists of:
- One octet that gives the algorithm used to compress the packet.
- The remainder of the packet is compressed data.
5.6 Literal Data Packet
A literal data packet (tag 11) contains the body of a message, data
that is not to be further interpreted.
The body of this packet consists of:
- - A one-octet field that describes how the data is formatted. If
it is a 'b' (0x62), then the literal packet contains binary
data. If it is 't' (0x74), then it contains text data, and thus
may need line ends converted to local form, or other text-mode
changes (similar to FTP's text mode). RFC 1991 also defines a
'local' mode for machine-local conversions, but does not define
it. Curiously, it specifies that the character for it is '1'
(numeral one) (which this author thinks might be a typo for 'l'
(lower-case ell), and does not give its hexadecimal equivalent.
- A counted string giving a file name.
- - A four-octet number that indicates the modification date of the
file, or the creation time of the packet, or a zero that
indicates the present time.
- The remainder of the packet is literal data.
PGP Formats - Open PGP BOF Page 10
5.7 Obsolete Literal Packet
An experimental version of PGP used this packet (tag 10) as the literal
packet, but no released version of PGP generated literal packets with this
tag. With PGP 5.x, this packet has been re-assigned and is reserved for
use as a marker packet. PGP 5.x makes a packet and puts it at the start of
a message that mixes RSA and DSS keys, so that PGP 2.x will recognize it
as a legal PGP message, but one that it is not equipped to decode. You
may use these packets for similar purposes, and should ignore any you find.
The packet that PGP 5.x uses contains three octets of data, holding the
string "PGP."
5.8 Key Material Packet
A key material packet contains all the information about a public or
private key. There are four variants of this packet type, and two major
versions. Consequently, this section is complex.
A public-key packet (tag 6) starts a series of packets that forms a PGP
certificate (or PGP key, as it is commonly known). A subkey packet (tag 14)
has exactly the same format, but denotes a subkey. If it had the same tag,
then it would be impossible to tell a subkey from the start of another certificate.
A secret-key packet (tag 5) contains all the information that is found
in a public key packet, including the public key material, but also
includes the secret key material after all the public-key fields.
As you would expect, a secret subkey packet (tag 7) is the secret-key
analog of the secret key packet, and has exactly the same format.
There are two versions of key-material packets. Version 3 packets
are PGP 2.6 packets. Version 2 packets are identical in format to
Version 3 packets, but are generated by PGP 2.5 or before. This
document hereafter ignores them. PGP 5.0 introduces version 4
packets, with new fields and semantics.
PGP 5.x uses version 3 packets for RSA keys, and version 4 packets
for DSS/DH keys. Note that there is no reason that there cannot be
a V4 RSA key (except that it is not compatible with previous versions
of PGP), nor a reason that there cannot be a V3 DSS key.
A version 3 packet contains:
- A one-octet version number.
- A four-octet number denoting the time that the key was created.
- A two-octet number denoting the time in days that this key is
valid. If this number is zero, then it does not expire.
- A one-octet number denoting the public key algorithm of this key
- - A series of multi-precision integers comprising the key
material.
An RSA key has two MPIs: the RSA public modulus (n), followed by the
public exponent (e).
A Diffie-Hellman key has three MPIs: the prime (p), the generator (g),
and the public key (k).
A DSS key has four MPIs: the prime (p), the group order (o),
the generator(g), and the public key (k).
PGP Formats - Open PGP BOF Page 11
The fingerprint of the key is formed by hashing the body (but not the
two-octet length) of the MPIs that form the key material with MD5.
The eight-octet key ID of the key is formed by taking the low 64 bits
of the public modulus of an RSA key.
Note that no released version of PGP has created a V3 key with any
other public key algorithm other than RSA. PGP 5 still generates
its RSA keys in V3 format to ensure interoperability with V2.x.
Since the release of PGP 2.6, there have been a number of improvements
desired in the key format. For example, making the key id be a function
of the public modulus makes it easy for a person to purposely create a
key that has the same key id as some existing key. Similarly,
MD5 is no longer the preferred hash algorithm, and not hashing the
length of an MPI with its body increases the chances of a fingerprint
collision.
The version four packet format is similar to the V3 format except for the
following changes:
- There is no validity period field.
- The fingerprint is constructed by taking the SHA-1 hash of
<To be written in later draft>.
- The key ID is the low 64 bits of the fingerprint.
<Placeholder for Secret key extensions in a later draft.>
5.9 User-Name Packet
A user-name packet is a counted string with a one-octet length. By
convention, it is an RFC 822 mail name, but there are no restrictions on its content.
5.10 Signature Packets
A signature packet describes a binding between some public key and some
data. The most common signatures are a signature of a file or a block of text,
and a signature that is a certification of a user name. There are a number of
meanings of a signature, which are specified in a signature-type octet in
any given signature. These meanings are:
- 0x00: Signature of a binary document. Typically, this means the
signer owns it, created it, or certifies that it has not been
modified.
- 0x01: Signature of a canonical text document. Typically, this
means the signer owns it, created it, or certifies that it has
not been modified.
- 0x10: The generic certification of a user name and public-key
packet. The issuer of this certification does not make any
particular assertion as to how well the certifier has checked
that the owner of the key is in fact the person described by
the user name. Note that all PGP "key signatures" are this type
of certification.
- - 0x11: This is a persona certification of a user name and
public-key packet. It means that the issuer of this
certification has not done any verification of the claim that
the owner of this key is the user name specified. Note that no
released version of PGP has generated this type of
certification.
PGP Formats - Open PGP BOF Page 12
- - 0x12: This is the casual certification of a user name and
public-key packet. It means that the issuer of this
certification has done some casual verification of the claim of
identity. Note that no version of PGP has generated this type
of certification, nor is there any definition of what
constitutes a casual certification.
- - 0x13: This is the positive certification of a user name and
public-key packet. It means that the issuer of this
certification has done substantial verification of the claim of
identity. Note that no version of PGP has generated this type
of certification, nor is there any definition of what
constitutes a positive certification. Please also note that the
vagueness of these certification systems is not a flaw, but a
feature of the system. Because PGP places final authority for
validity upon the receiver of a certification, it may be that
one authority's casual certification might be more rigorous
than some other authority's positive certification.
SigSubkeyCert = 0x18,
SigKRev = 0x20,
SigSubkeyRev = 0x28,
SigKSRev = 0x30,
SigTimeStamp = 0x40
6. Constants
This section describes the constants used in PGP Version 5.x.
6.1 Public Key Algorithms
1 - RSA
16 - Diffie-Helman, El Gamal variant
17 - DSS (Digital Signature Algorithm)
6.2 Symmetric Key Algorithms
0 - Plaintext
1 - IDEA
2 - Triple-DES (DES-EDE, 168 bit key)
3 - CAST5 (128 bit key)
6.3 Compression Algorithms
0 - Uncompressed
1 - ZIP
6.4 Hash Algorithms
1 - MD5
2 - SHA-1
? - RIPE-MD/160
7. Transferable Public Keys
Public keys may transferred between PGP users. The essential elements
of a transferable public key are:
PGP Formats - Open PGP BOF Page 13
(a) One public-key packet
(b) One or more user-ID packets
(c) Zero or more signature packets
The public-key packet occurs first. Each of the following user ID
packets provides the identity of the owner of this public key. If
there are multiple user-ID packets, this corresponds to multiple
means of identifying the same unique individual user; for example, a
user may enjoy the use of more than one e-mail address, and construct
a user-ID packet for each one. Immediately following each user-ID
packet, there are zero or more signature packets. Each signature
packet is calculated on the immediately preceding user-ID packet and
the initial public key packet. The signature serves to certify the
corresponding public key and user ID. In effect, the signer is
testifying to his or her belief that this public key belongs to the
user identified by this user ID.
8. PGP 5.0 Enhanced Key Formats
With PGP 5.0, a more flexible PGP key format was introduced. The
new key format allows for two new features. One is the ability
to support a key that has one public key to do authentication and
a second to do encryption. The other new feature is the ability
to easily expand the signature packets.
Currently, both authentication and encryption are done using the
RSA public key cryptosystem. The RSA algorithm uses a single
public/private key pair to perform both operations. The existing
PGP key format only supports algorithms that digitally sign and
encrypt with a single key. The enhanced key format supports
algorithms that can use a different key pair for each operation.
The first example of this new flexibility is PGP 5.0's support of
keys that use NIST's Digital Signature Standard (DSS) for digital
signatures and the ElGamal variation of Diffie-Hellman for
encryption and decryption. PGP 5.0 continues to support both the
RSA algorithm and the existing PGP key format when used with RSA.
The new signature packet (version 4) includes subpackets to easily
add new attributes to a signature. Further, two types of
subpackets exist; a group of subpackets that is included in the
hash used by the signature and a group that is not. The subpackets
can be either attributes of the signature packet, or they can be an
assertion by the signer about the key being signed.
Currently, this new format is only generated for signatures on
Diffie-Hellman/DSS keys. This prevents any backward compatibility
problems since all RSA keys still use version 3 signatures and all
software that supports Diffie-Hellman/DSS also supports the new
signature packets.
8.1 Key Structures
The format of an existing PGP key using RSA is as follows. Entries
in square brackets are optional and ellipses indicate repetition.
PGP Formats - Open PGP BOF Page 14
RSA Public Key
[Revocation Self Signature]
UserID [Signature ...]
[UserID [Signature ...] ...]
Each signature certifies the RSA public key and the preceding UserID.
The RSA public key can have many UserIDs and each UserID can have
many signatures.
The format of the new PGP key type that requires two public keys is
very similar except that the second key is added to the end as a
'subkey' of the primary key.
Primary-Key
[Revocation Self Signature]
UserID [Signature ...]
[UserID [Signature ...] ...]
[Subkey Primary-Key-Signature]
The subkey always has a single signature after it that is issued
using the primary key to tie the two keys together. The new format
can use either the new signature packets or the existing signature
packets.
In a Diffie-Hellman/DSS key, the DSS public key is the primary key, the
Diffie-Hellman public key is the subkey, and either version 3 or 4 of
the signature packet can be used.
8.2 Public Key Certificate Packet Structure
To accommodate the addition of the subkey construction, a new
version of the public-key-certificate packet was created. Packets
with a version of '3' are still created for PGP keys that use RSA
public keys. For specifics on version 3 packets, see RFC 1991.
The terms and formatting used here are consistent with that RFC.
A Cipher Type Byte (CTB) with bits 5-2 of 0110 indicates a primary
public-key-certificate packet. This can be either an existing RSA
key with a packet version of 3 or a DSS key with a version of 4.
A new packet type is now defined for the subkey. The CTB of the
subkey packet has bits 5-2 of 1110. Notice that this used to
indicate a comment packet. These packet-type bits were selected
because no previous version of PGP ever emitted comment packets but
they did properly ignore them. This provides some backwards
compatibility with existing PGP implementations.
Below are the complete definitions for the primary and subkey public
key packets. Support for RSA and Diffie-Hellman/DSS keys is described.
RSA Public Key Certificate Packet ("old format")
a) packet structure field with CTB bits 5-2 = 0110 (2 or 3 bytes);
b) version number = 3 (1 byte);
c) time stamp of key creation (4 bytes);
d) validity period in days (0 means forever) (2 bytes);
PGP Formats - Open PGP BOF Page 15
e) algorithm (1 byte):
1 = RSA,
f) Algorithm specific fields.
Algorithm Specific Fields for RSA keys:
f.1) multiprecision integer (MPI) of RSA public modulus n;
f.2) MPI of RSA public encryption exponent e.
New Public Key Certificate Packet
a) packet structure field with (2 or 3 bytes):
Bits 5-2 of CTB = 0110 means primary key packet,
Bits 5-2 of CTB = 1110 means subkey packet;
b) version number = 4 (1 byte);
c) time stamp of key creation (4 bytes);
e) algorithm (1 byte):
1 = RSA (not presently generated),
16 = Diffie-Hellman,
17 = DSS;
f) Algorithm specific fields.
Algorithm Specific Fields for DSS keys:
f.1) MPI of DSS prime p;
f.2) MPI of DSS group order q (q is a prime divisor of p-1);
f.3) MPI of DSS group generator g;
f.4) MPI of DSS public key value y (= g**x where x is secret).
Algorithm Specific Fields for Diffie-Hellman keys:
f.1) MPI of Diffie-Hellman prime p;
f.2) MPI of Diffie-Hellman group generator g;
f.3) MPI of Diffie-Hellman public key value y (= g**x where x
is secret).
8.3 Signature Packet Structure
Version 4 of the signature packet adds the concept of hashed and
non-hashed subpackets. Since this version is not recognized by
previous versions of PGP, it is currently only being generated in
conjunction with version 4 public-key-certificate packets (i.e.,
Diffie-Hellman/DSS PGP keys).
NOTE: The order and contents of the data that is hashed in a
version 4 signature packet needs further detail.
Here is the specification of a version 4 signature packet:
a) packet structure field with CTB with bits 5-2 = 0010
(2 or 3 bytes);
b) version number = 4 (1 byte);
c) signature classification (hashed) (1 byte);
d) public key algorithm (hashed) (1 byte):
1 = RSA (not presently generated),
16 = Diffie-Hellman,
17 = DSS;
PGP Formats - Open PGP BOF Page 16
e) hash algorithm (hashed) (1 byte):
1 = MD5,
2 = SHA;
f) length of hashed subpacket data (hashed) (2 bytes);
g) hashed subpacket data (hashed) (f bytes):
- signature creation time,
- key expiration time,
- preferred symmetric encryption algorithms;
h) length of non-hashed subpacket data (2 bytes);
i) non-hashed subpacket data (h bytes):
- signer key ID;
j) first 2 bytes of message digest (16 bit checksum);
k) MPI of public key signature
l) MPI #2 of public key signature (for DSS signatures only)
Fields g) and i) consist of signature subpackets. Below is the
specification of signature subpackets. The list of subpackets may grow
in the future. Unrecognized packets should be skipped unless marked as
critical.
a) subpacket length (1 or 2 bytes):
Length includes the type byte but not this length,
1st byte < 192, then length is one byte,
1st byte >= 192, then length is 2 bytes and equal to
(1st byte & 0x3F) * 256 + (2nd byte) + 192;
b) subpacket type (1 byte):
If bit 7 is set, subpacket understanding is critical,
2 = signature creation time,
9 = key expiration time,
11 = preferred symmetric algorithms,
16 = key ID of signer,
c) subpacket specific data (b bytes);
Several types of subpackets are currently defined. Some subpackets
apply to the signature itself and some are attributes of the key.
Signature creation time (4 byte time field) (Hashed)
The time the signature was made. Always included with new
signatures.
Key ID of signer (8 byte key ID) (Non-hashed)
The PGP key ID of the person signing the key.
Key expiration time (4 byte time field) (Hashed)
The validity period of the key. This is the number of seconds
after the key creation time that the key expires. If this is
not present or has a value of zero, the key never expires.
This is found on a self-signature.
Preferred symmetric algorithms (array of 1 byte) (Hashed)
Symmetric algorithm numbers that indicate which algorithms
the key holder prefers to use. This is an ordered list of
bytes with the most preferred listed first. It should be
assumed that only algorithms listed are supported by the
recipient's software. Algorithm numbers are provided below.
If this subpacket is not included, IDEA is assumed. This is
found on a self-signature.
PGP Formats - Open PGP BOF Page 17
8.4 Diffie-Hellman/DSS Key IDs and Fingerprints
A Diffie-Hellman/DSS fingerprint is the 160-bit SHA-1 hash of a few
header bytes followed by the entire public key packet starting with
the version field. The key ID is either the low order 32 bits or
64 bits of the fingerprint. Here are the fields of the hash
material:
a.1) 0x99 (1 byte)
a.2) high order length byte of (b)-(f) (1 byte)
a.3) low order length byte of (b)-(f) (1 byte)
b) version number = 4 (1 byte);
c) time stamp of key creation (4 bytes);
e) algorithm (1 byte):
17 = DSS;
f) Algorithm specific fields.
Algorithm Specific Fields for DSS keys:
f.1) MPI of DSS prime p;
f.2) MPI of DSS group order q (q is a prime divisor of p-1);
f.3) MPI of DSS group generator g;
f.4) MPI of DSS public key value y (= g**x where x is secret).
8.5 New Algorithm and Signature Classification Types
Several new algorithm types were added to support Diffie-Hellman/DSS
keys. Below are the new public-key-encryption algorithm numbers:
Diffie-Hellman 16
DSS 17
DSS uses a different message digest algorithm, the Secure Hash
Algorithm (SHA-1). This is the only message-digest-algorithm number
added:
SHA-1 2
Below are the preferred symmetric algorithm numbers:
IDEA 1 (not new)
Triple DES 2
CAST5 3
A single new signature classification was added for the signature
packet that ties the subkey to the primary key.
Subkey Signature 24
8.6 Interoperability
Starting with PGP 5.0, PGP's products support this new format and
the sending and receiving of mail protected using either RSA or
Diffie-Hellman/DSS keys. A keyring can contain both types of
keys and you can send a piece of mail to people with either key type.
PGP Formats - Open PGP BOF Page 18
Users of previous versions of PGP cannot accept keys that use
Diffie-Hellman/DSS. PGP is releasing patches for most versions that
provide some support for Diffie-Hellman/DSS keys. The patches allow
prior versions to interoperate better with Diffie-Hellman/DSS keys.
The patched versions still do not support generating Diffie-Hellman/DSS
keys or usingthem to send or receive encrypted mail.
8.7 Future Formats
Additional information on PGP formats is being provided to the public in
order for others to build compatible or complimentary systems that
support PGP.
PGP Formats - Open PGP BOF Page 19
