Ignore spelling and grammar...
INTERNET-DRAFT Lutz Donnerhacke
Security IN-Root-CA
Expires in six months Individual Network e.V.
October 19 1997
PGP Message Exchange Formats
<draft-ietf-pgp-formats01.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).
This document is maintained in order to publish all necessary information
needed to develop interoperable applications based on the PGP message
exchange format. It is not a step by step cookbook for the source code, it
describes only the format and methods needed to read, check, generate and
write conforming packets crossing any network. It does not deal with storing
and implementation questions albeit it is necessary to avoid security flaws.
Abstract
PGP (Pretty Good Privacy) is a software product combining strong asymmetric
and symmetric cryptography for secure e-mail communication. These services
include confidentiality, key management, digital signature, and time
stamping. This document specifies the message exchange format used in
version 2.6.3x and 5.x of PGP.
Table of Contents
[autogenerated using sed -n '/^[0-9]\+\./s/^/ /p' format.txt]
1. Introduction
2. General functions
2.1 Confidentiality
2.2 Digital signature
2.3 Key management
2.4 Time stamping
3. Layers of a message
3.1 Session layer
3.1.1 MIME
3.1.2 Ascii Armor
3.1.2.1 Radix-64 encoding
3.1.2.2 Checksum
3.1.2.3 Header and footer lines
3.1.2.4 Armor headers
3.1.2.5 Example
3.1.3 Cleartext signature framework
3.2 General packet framework
3.2.1 Cipher Type Byte
3.2.2 Packet length
3.2.2.1 Packet version three or lower
3.2.2.2 Packet version four or higher
4. Generic data types
4.1 Scalar numbers
4.2 Multi-Precision Integers
4.3 Strings
4.4 Time fields
5. Packet types
5.1 Packet version three or lower
5.1.1 Public key encrypted packet
5.1.2 Signature packet
5.1.3 Secret key packet
5.1.4 Public key packet
5.1.5 Compressed data packet
5.1.6 Conventional key encrypted packet
5.1.7 Literal data packet
5.1.8 Keyring trust packet
5.1.9 User ID packet
5.1.10 Comment packet
5.2 Packet version four or higher
5.2.1 Encrypted session key packet
5.2.2 Signature packet
5.2.3 Conventionally encrypted session key packet
5.2.4 One-pass signature packet
5.2.5 Secret key packet
5.2.6 Public key packet
5.2.7 Secret subkey packet
5.2.8 Compressed data packet
5.2.9 Symmetrically encrypted data packet
5.2.10 Marker packet
5.2.11 Literal data packet
5.2.12 Trust packet
5.2.13 User ID packet
5.2.14 Subkey packet
5.2.15 Comment packet
6. Key identification
6.1 Key ID
6.2 User ID
6.2.1 Primary user ID
6.2.2 Matching multiple user IDs
6.2.3 User ID conventions
6.3 Fingerprint
7. Keyserver
7.1 E-Mail keyserver
7.2 DNS keyserver
7.3 HTTP keyserver
8. Notes
9. Security Considerations
10. Author's Address
11. References
1. Introduction
This document provides information on the message-exchange packet formats
used by PGP to provide encryption, decryption, signing, key management and
timestamping functions. It builds on the foundation provided RfC 1991 "PGP
Message Exchange Formats" [1] and RfC 2015 "MIME Security with Pretty Good
Privacy (PGP)" [2]. Despite the well known authors (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, there are several
contributions from the Internet community.
2. General functions
This standard provides four services related to the format of messages and
data files:
- confidentiality,
- digital signature,
- key management,
- time stamping.
2.1 Confidentiality
This standard provides confidentiality by compressing and encrypting
messages to be transmitted or data files to be stored locally using
conventional encryption. Each conventional key is probably used only once.
That is, a new key is generated at random for each message. Since it is to
be used probably 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. If files are stored, the owner's public key is
used. The sequence is as follows:
1. The sender creates a message.
2. The sending software generates a random number to be used as
a session key for this message only.
3. The sending software conventionally encrypts the message using
the session key.
4. The session key is encrypted using each recipient's public key. These
ecrypted session keys are prepended to the encrypted message.
5. The receiving software decrypts the session key using the approbriate
recipient's private key.
6. The receiving software 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.2 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 software generates a hash code of the message
3. The sending software encrypts the hash code using the sender's private
key.
4. The encrypted hash code is prepended to the message.
5. The receiving software decrypts the hash code using the sender's public
key.
6. The receiving software 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.
The terms "encrypt" and "decrypt" in this section do not refer to
confidentiality like real encryption. The message is readable by everyone.
2.3 Key management
Public key cryptography requires the knowlegde of the correct public key for
every person involved into communication. A lot of possible attacks deal
with key spoofing or man-in-the-middle key and message manipulation. Any
cryptosystem for the Internet must deal with these attacks.
In order to prove that a certain public key really belongs to the expected
person, certificates are used. A certificate is a machine readable,
digitally signed message. The following certificates are mandantory:
- binding of a public key and a user id => "ordinary" certificate.
- unbinding => certificate revocation certificate.
- compromised key => key revocation certificate.
There are two models of key management: Hierarchical trust and Web of trust.
Hierarchical key management relies on a tree of certification authorities
(CA). Every user is certified only by "his" CA. This CA is certified be its
superior CA from the next higher level. The toplevel CA is called "root CA"
and is certified by itself. (Unfortunly in the real world the structure of
the CAs is rather a forest than one tree.) This concept offers:
- easy implementation
- single point of failture (compromised or unreachable CA)
- definite policy
- extortion and corruption cause lot of trouble (false certificates)
- short public key packets (usually only one certificate per key)
- guaranteed to work between every two people
- central system trust
Web of trust key management allows everybody to certify everybody. The
problem is to find an appropriate trust function to describe and evaluate
the trust of multiple certificate chains through this web of certificates.
This concept offers:
- a lot of implementation work (hard to implement)
- many different trust models
- alternative pathes
- robustness against compromised or unreachable nodes
- many different and unknown certification policies
- large public key packets
- no guaranteed path between every two people within the web of trust
- decentralized private trust
Existing software implement the Web of trust using the following ruleset
(described more in detail in 5.1.8):
1) Public keys of the user herself are completely trusted.
2) The user chooses for every trusted key if she trust it's certificates
fully, marginally or not at all.
3) Every key offering a certificate (to a user ID) by at least n fully
or m marginally trusted keys is considered trusted.
4) Repeat at 2) until the trust chain is longer than the length l.
The default values are n (Completes_Needed) = 1, m (Marginals_Needed) = 2, and
l (Cert_Depth) = 4.
The current implementations have several flaws: Key revocation certificates
and certificate revocation certificates are not recognized; User IDs without
a selfcertificate are useable; user IDs with a self-certificate revocation
certificate are not considered to be bogus; there is no possibility to
change the default user ID for a public key.
Note: Some of these lacks are fixed in PGP2.6.3in. [3]
Some CAs do offer a hierarchical certification structure in addition to the
web of trust. This may solve the problem of finding a path. But currently
there is no solution known to define a good trust metric in the web of
trust. Several people doing reserach on this subject.
2.4 Time stamping
A time stamp is a certificate binding an independent time source to a
document. This is especially necessary to prove the existence of a signature
before the key was revoked. So timestamping a document is the task of the
recipient of a digitally signed message. An other usage is to show that a
document existed at a certain time. (Example: European patent offices grant
a patent to the person offering the oldest source of the idea.) So
timestamping belongs only to storage operations. Time stamps should not be
used to detect replay attacks.
Time stamps are defined in the PGP format [1] but not yet implemented. In
order to obtain trustable timestamps automatically, the use of the Eternity
logfile [4] may be considered, because it is royalty free and payment free:
1) The user calculates a cryptographic secure hash of the file to timestamp.
2) His software telnets to logfile.iks-jena.de port 1234 and enters the hash
value and the monetary value behind this document.
3) The server responds with a line of new hashes.
4) User's software digitally signes the file and the returned line.
5) In order to prove this time stamp, the hash line must be requested by
searching for the hash of the file. The checks are similar to the
checks required for ordinary digital signatures.
3. Layers of a message
PGP messages occur in OSI layer seven "application layer". They are pure
octect streams. In order to exchange them beween a lot of different
architectures, the OSI layer six "session layer" is needed to define an
exchange enviroment.
The octet stream at level seven has an internal structure describing the
content of the PGP message in a machine-readable format. It is designed to
generate and process any data in a single pass in order to avoid temporary
files. So the byte order of the actual machine can be ignored.
3.1 Session layer
According to RfC 821, binary data may not be transfered as a binary stream
via electronic mail. So it has to be converted to a transport format.
Nowadays, MIME [5] (RfC 2015) [2] should be used wherever possible.
But PGP is older than MIME. So there is a proprietary session layer called
'Ascii Armor'.
3.1.1 MIME
RfC 2015 "MIME Security with Pretty Good Privacy (PGP)" [2] contains all
information necessary to strip or apply this layer. It may make use of the
Ascii Armor layer, but the octect stream may also encoded directly using
MIME itself.
3.1.2 Ascii Armor
Similar to MIME encoding, the process of ascii armor encodes an 8-bit binary
stream of data into printable characters. Every three subsequent octets are
mapped into four subsequent ASCII characters. Futhermore ascii armor
encoding also appends a special CRC to detect transmission errors. In order
to ease recognition of Ascii Armored messages, a special header and footer
is provided.
The whole ascii armored message contains:
- a header line,
- the armor headers,
- a blank line,
- the radix-64 encoded octet stream,
- the radix-64 encoded checksum and
- a footer line.
3.1.2.1 Radix-64 encoding
To encode assume the file as an octect (input) stream. Take the first three
bytes from the stream. Convert each byte into network bit order (MSB first).
This results into:
+--first octect-+-second octect-+--third octect-+
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|
+-----------+---+-------+-------+---+-----------+
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|
+--1.index--+--2.index--+--3.index--+--4.index--+
Each index value points to a character of the following string (all upper
letter characters followed by all lower letter characters followed by the
digest and '+' (US-ASCII 0x2B) and '/' (US-ASCII 0x2F):
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/
The resulting characters are send to the output stream. The numeric values
of all these characters are taken from US-ASCII [6].
Repeat the aforementioned until the input stream does contain less than
three octets. If no octet is left, the procedure is finished. If one or two
octets are left, the missing octets are assumed to be zero for the last
translation step. All indeces containing no valid bit from the data stream
(because the octect is missing), are converted to the padding character '='
(US-ASCII 0x3D). If only the third octect is missing, this happens to the
fourth index. If only the first octect is present, it happens to the third
and the fourth index, respectively.
The output stream should be broken to lines of 64 characters each.
To decode such an radix-64 encoded character (input) stream, lookup each
character in the array mentioned above. Ignore any character not in the
array and not the padding character. You must not expect any finite line
length for internal buffers.
The input stream contains a multiple of four such characters. Due to
transmission errors this assumption might fail. Any software that adheres to
this RfC must expect such situations.
Every four characters are looked up into there index values. The padding
character looked up as numerical zero. The convertion is reversed to the
three octets of this procedure. Starting with the first, octets are sent to
the output stream. Only octects containing no bit from a padding character
are sent. If even the first octect contains a padding character, the padding
character is not part of this radix-64 stream. It belongs to the next part
of of ascii armor.
3.1.2.2 Checksum
In order to detect transmission errors, a simple radix-64 encoded checksum
is appended to the radix-64 encoding of the octet stream. In order to
terminate the radix-64 encoded octet stream, the checksum is prepended by a
single radix-64 padding character. Software should output the padding
character and the radix-64 encoded checksum as a single line. Note, that the
checksum is generated using the pure octet stream and not the radix-64
encoded transport shell.
The 24-bit CRC checksum is computed by using the generator 0x864CFB and an
initialization of 0xB704CE. For more information on CRC functions, the
reader is asked to look at chapter 19 of [7].
[This paragraph needs a lot of work. I have to rewrite the paragraph
using the sources.]
3.1.2.3 Header and footer lines
Any ascii armored content is surrounded by a specific pair of
corresponding header/footer lines. They are used to automatically
recognise an ascii armored content and to determine the right handler for
this content. Normally the content of a ascii armored message can be
obtained by reading the radix-64 encoded octet stream. But this technique
requires software able to decode radix-64. In many cases, simple string
comparation are used to determine the right handler (i.e. using procmail).
A header line is a single line composed by:
- five dashes '-' (US-ASCII 0x2D),
- the words "BEGIN PGP content" seperateded by single spaces ' '
(US-ASCII 0x20), and
- five dashes.
"Content" is a placeholder for the content phrase. It is substituded by
one of the following phrases:
"MESSAGE" -- generetic content, usually signed or encrypted.
"SIGNATURE" -- seperate signature of some corresponding data.
"PUBLIC KEY BLOCK" -- one or more public keys.
"SECRET KEY BLOCK" -- one or more secret keys.
It might be possible that the octect stream is larger than the maximum
transmission size of the channel. In this case the the octet stream can be
broken into chunks. Each chunk is ascii armored seperatly. In order to
identify and reorder the seperate chunks, the content phrase is extented by
the phrase ", PART x/y" where x and y are numbers printed decimal. y denotes
the total number of chunks the octect stream was split into. x denotes the
the running number of the chunk starting with one. These number can start
with leading zeros, but are still decimal coded. The "/y" part of the phrase
is optional.
Examples:
"-----BEGIN PGP PUBLIC KEY BLOCK, PART 3/09-----"
introduces the third part of nine of some public keys.
"-----BEGIN PGP MESSAGE, PART 091-----"
introduces the ninty first part of a generic PGP message.
"-----BEGIN PGP SIGNATURE-----"
introduces a seperate digital signature.
Directly after the radix-64 encoded checksum line, a footer line is
expected. It must match the corresponding header line despite the word
"BEGIN" is replaced by "END".
3.1.2.4 Armor headers
Directly after the header line, special armor headers may exist. They are
terminated by an empty line. If no armor header exists, this empty line
should not be generated, but may be present.
The syntax of those headers is defined in RfC 822 without the extenstions
defined in later RfCs.
The following keywords are defined:
Version -- Denotes the version used to generate this message.
Comment -- Any user defined world readable message.
Hash -- Used method of hashing to ease one pass processing.
Defined are "MD5", "MD2" and "SHA-1".
MessageID -- Random number to trace messages.
Charset -- Character set for the message.
The MessageID is usually derivated from the same "randomness" pool the
session key comes from. So the MessageID header introduces an unnecessary
security weekness, because the confidentiality of the message may be
attacked by attacking the "randomness" pool functions. This header must not
generated and should produce a warning to the recipient.
Any unknown armor header should produce a warning to the recipient.
3.1.2.5 Example
-----BEGIN PGP MESSAGE-----
Version: 2.6.3in
owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn
l6UWpabo8XIBAA==
=3m1o
-----END PGP MESSAGE-----
Please note, that this example is idented by two spaces in order to not
confuse software.
3.1.3 Cleartext signature framework
Sometimes it is necessary to sign a textual octet stream without ascii
armoring the stream itself. So the signed text is still readable without
special software. In order to bind a signature to such an cleartext, this
framework is used.
It consists of:
- the cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a single
line,
- some optional armor headers (3.1.2.4),
- any number of empty lines not included into the message digest,
- the dash escaped cleartext which is included into the message digest,
- the ascii armored signature(s) including the armor header and footer
lines.
If the "Hash" armor header is given, the specified message digest algorithm
is used for the signature. If this header is missing, MD5 is assumed as
default. It is possible, that more than one message digest is used in the
signature, so the "Hash" armor header may contain a comma delimited list
of used message digests.
Dash escaped cleartext is the ordinary cleartext where every line starting
with a dash '-' (US-ASCII 0x2D) is prepended by the sequence dash '-'
(US-ASCII 0x2D) and space ' ' (US-ASCII 0x20). This prevents the parser
from recognising armor headers of the cleartext itself. The message digest
is computed using the cleartext itself, not the dash escaped form. So it
is possible to seperate or join a signature from or to a cleartext without
resigning it.
3.2 General packet framework
The octet stream of a PGP message is seperated into a several chunks. They
are called packets. Every packet consists of a header and it's data tail.
The header of a packet consists of a single octet and some length
definitions. So it may be possible to skip a packet if the software is
unable to handle the content. Unfortunly some data has an indefinite length
to single pass software. So the packets in a chunk should be arranged in a
single pass aware way ending with the indefinite length packet. This may
cause temorary storage of small amounts of data.
The octets of the PGP message are described in network bit order (highest
bit first).
3.2.1 Cipher Type Byte
Every packet starts with a single octet, the CTB "Cipher Type Byte". It
determines the content of the packet and the length octets.
+---------------+
CTB |7 6 5 4 3 2 1 0|
+---------------+
Bit 7 -- always one
Bit 6 -- paket version four or higher is present if set
packet version three or lower
Bits 5-2 -- content type
0001 -- public key encrypted packet
0010 -- signature packet
0101 -- secret key packet
0110 -- public key packet
1000 -- compressed data packet
1001 -- conventional key encrypted packet
1011 -- literal data packet
1100 -- keyring trust packet
1101 -- user id packet
1110 -- comment packet
other - undefined
Bits 1,0 -- length type
00 -- one length octet
01 -- two length octets
10 -- four length octets
11 -- no length octet (The packet is of indeterminate length.)
packet version four or higher
Bits 5-0 -- content type
000000 -- Reserved. A packet must not have a tag with this value.
000001 -- Encrypted Session Key Packet
000010 -- Signature Packet
000011 -- Conventionally Encrypted Session Key Packet
000100 -- One-Pass Signature Packet
000101 -- Secret Key Packet
000110 -- Public Key Packet
000111 -- Secret Subkey Packet
001000 -- Compressed Data Packet
001001 -- Symmetrically Encrypted Data Packet
001010 -- Marker Packet
001011 -- Literal Data Packet
001100 -- Trust Packet
001101 -- User ID Packet
001110 -- Subkey Packet
010000 -- Comment Packet
other -- undefined
3.2.2 Packet length
The packet length is the amount of content octects without the CTB (3.2.1)
and length octets.
3.2.2.1 Packet version three or lower
The CTB (3.2.1) contains the length type pointing out, how many length
octets follow the CTB. The length of the following data must be known to
the generation process or the indefinite length must be used. The
indefinite length packet should be the last in the chunk. Reading software
can assume, that the indefinite length packet is the last chunk of the
stream.
The length of the packet data is stored in network byte order (see 4.1) as
one, two or four octet value. It is recommended to use the smallest storing
size for the length. But some implementations default this length to two or
four bytes length if it is necessary or not.
Example:
10111001 00000011 10010000 ...912 octets...
3.2.2.2 Packet version four or higher
The CTB (3.2.1) is followed by several subpackets. Every subpacket
contains data of a definite length and the information if this is the last
subpacket or not.
Every subpacket starts with a single length octet:
+---------------+
|7 6 5 4 3 2 1 0|
+---------------+
If bit seven to five are set, the length of the subpacket is two to the
power of the numerical value of bits four to zero. This subpacket is
followed by additional subpackets.
The length octet of the last subpacket has at least on of the bits seven to
five cleared. If bit seven is cleared, the length of the subpacket is the
numerical value of of the bits six to zero. So this subpacket codes lengths
from zero to 127.
If bit seven is set and bit six is cleared, the length of the subpacket is
the numerical value of the bits five to zero plus 128. So this subpacket
codes lengths from 128 to 192.
If bit seven and bit six are set and bit five is cleared, the length of this
subpacket is the numerical value of the bits four to zero prepended to the
next octet plus 192. So this subpacket codes length from 192 to 8383. Note
that this subpacket uses two octets for it's length.
Example:
11010000 111011011 ...134217728 octets... 11000000 00001000 ...200 octets...
4. Generic data types
This section describes the generic data elements used in this standard.
4.1 Scalar numbers
Scalar numbers are unsigned, and are always stored in big-endian format also
known as network byte order. To read a scalar from the octet stream:
1) set the result to be to zero
2) multiply the result to be by 256
3) read the an octet from the steam and add it to the result to be
4) jump to 2) until all octets of the scalar are read.
4.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 number that is the length
of the MPI in bits followed by a string of octets that contain the actual
integer stored exactly as an ordinary scalar number.
Example: (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.
The storage size in octets of an MPI is the ((length of an MPI + 7) / 8) in
addition to the length scalar number.
The length field of an MPI should describe the length starting from its
most significant non-zero bit. Software must be able to deal with leading
zero bits of an MPI.
4.3 Strings
A string consists of a one-octet length and then N octets of string data.
Characters values must fit into an octet. The default charset is US-ASCII.
So strings are limited to 255 charaters.
4.4 Time fields
A time field is a four-octet scalar number containing the number of
seconds elapsed since midnight, 1 January 1970 GMT. This is standard unix
time. Other timezones must be ajusted to GMT.
5. Packet types
5.1 Packet version three or lower
5.1.1 Public key encrypted packet
A public key encrypted packet has the CTB (3.2.1) tag 1. It contains the
symmetric session key for conventionally encrypted packets (5.1.6) later
in the stream. If a message is encrypted to more recipients, such a public
key encrypted packet occurs for every recipient.
Software must not encrypt to anybody else without interaction with the
user. The user must have the full control over the list of recipients the
message is encrypted to. This explicitly includes the EncryptToSelf
configuration option of existing implementations. The software is now
required to ask the user explicitly if he wants to encrypt to additional
recipients or not.
A public key encrypted packet consists of:
- a version octet,
- a key ID,
- an algorithm identifier octet, and
- algorithm specific data.
The version octet is two for PGP versions <= 2.5 or three for newer PGP
versions.
The key ID (6.1) is an eight octet scalar number (4.1).
The algorithm identifier is one for RSA or sixteen for ElGamal.
If the algorithm is RSA or ElGamal, the rest of the packet is the the
encrypted session key as a MPI (4.2).
The session key is generally shorter than the input blocksize of the
asymmetric algorithm. So padding is needed to enlarge the session key as
much as possible. On decrypting the session key the padding must be
checked to prove the correct secret key to be used.
PGP version 2.2 or earlier encode the message digest into a long enough
number as follows:
most significant octets ... least significant octets
0x00 0x01 session-key checksum 0x00 random(padding) 0x01
PGP versions 2.3 and later encode the message digest into a long enough
number as follows:
most significant octets ... least significant octets
0x00 0x02 random(padding) 0x00 0x01 session-key checksum
The checksum is a 16 bit checksum of the session key stored as a two octet
scalar (4.1). The random padding is required to be nonzero for each octet.
[The chekcsum algorithm will be added from the source.]
5.1.2 Signature packet
A signature packet has the CTB (3.2.1) tag 2. It is used to store any
signature.
If the plaintext that was signed is included in the same octet stream as
the signature packet, it begins right after the signature packet as a
literal packet.
If the plaintext that was signed is included as a cleartext signature
If the signature is a certificate it follows the key packet and the
optionally user ID packet.
A signature packet consists of
- a version octet,
- a subpacket containing signature type and time,
- a key ID,
- an algorithm octet determining the asymmetric cryptosystem,
- an algorithm octet determining the message digest algorithm,
- the two most significant octets of the message algorithm, and
- algorithm specific data.
The version octet is two for PGP versions <= 2.5 or three for newer PGP
versions.
The subpacket consists of
- a length octet, determining how many following octets are included
to the subpacket. All those following octets of the subpacket are
prepended to the message in order to be hashed.
It was designed to contain more data, but this introduces a security
hole, so a warning must be generated, if the subpacket length has an
other value than five.
- a signature classification octet described below.
- a time field (4.4), when the signature was made.
- (optionally) a two octet scalar value (4.1), containing the validity
period of the signature in days.
Owing to the way the MD5 is computed for the signature, if that field is
variable length, it is possible to generate two different messages with
the same MD5 hash. One would be a file of length N, with a 7-byte
following section consisting of a signature type byte, 4 bytes of
timestamp, and 2 of validity period, while the other would be a file of
length N+2, whose last two bytes would be the siganture type byte and
the first byte of timestamp, and the last three bytes of timestamp and
the validity period would instead be interpreted as a signature type
byte and a timestmap.
The key ID (6.1) is an eight octet scalar number (4.1).
The asymmetric cryptosystem algorithm identifier octet is one for RSA,
sixteen for ElGamal or seventeen for DSS.
The message digest algorithm identifier octet is one for MD5 or two for
SHA-1. The message digest output is generally shorter than the input
blocksize of the asymmetric algorithm. So padding is needed to enlarge the
message digest as much as possible. On verifying the signature the padding
must be checked to prove the correct public key to be used.
PGP version 2.2 or earlier encode the message digest into a long enough
number as follows:
most significant octets ... least significant octets
0x00 0x01 message-digest 0x00 0xFF(padding) 0x01
PGP versions 2.3 and later encode the message digest into a long enough
number as follows:
most significant octets ... least significant octets
0x00 0x01 0xFF(padding) 0x00 ASN.1-coded-message-digest
The ASN.1-coded-message-digest is derivated from RfC1423 [9]:
Sequence of (code 0x30, len 0x??)
Sequence of (code 0x30, len 0x??)
Object Identifier (code 0x06, len 0x??)
iso(1) member-body(2) US(840) rsadsi(113549) digestAlgorithm(2) 5
(= 2a 86 48 86 f7 0d 02 05) (determining MD5)
or ... (SHA-1)
Null Data (code 0x05, len 0x00)
Scalar number (0x04, len 0x??)
Message Digest
Example for MD5: 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10
followed by the 16 octets of the message digest itself.
If the algorithm is RSA, the rest of the packet is the the encrypted
message digest as a MPI (4.2).
If the algorithm is ElGamal, the rest of the packet is the the encrypted
message digest as a MPI (4.2).
If the algorithm is DSS, the rest of the packet are the the encrypted
message digest values as two MPIs (4.2).
The signature classification field describes what kind of
signature certificate this is. There are various hex values:
00 - Signature of a message or document, pure octet stream.
01 - Signature of a message or document, canonical text.
10 - Key certification, generic. Material signed is public key pkt and
User ID pkt.
11 - Key certification, persona. No attempt made at all to identify the
user with a real name. Material signed is public key pkt and User
ID pkt.
12 - Key certification, casual identification. Some casual attempt made
to identify user with his name. Material signed is public key pkt
and User ID pkt.
13 - Key certification, positive ID. Heavy-duty identification efforts,
photo ID, direct contact with personal friend, etc. Material
signed is public key pkt and User ID pkt.
20 - Key compromise. User signs his own compromise certificate. This is
independent of user ID associations, so material signed is public
key pkt ONLY.
30 - Key/user ID revocation. User can sign his own revocation to dissolve
an association between a key and a user ID, or certifier may revoke
his previous certification of this key/userid pair. Material
signed is public key pkt and User ID pkt.
40 - Timestamping a signature certificate. It is used to apply trusted
timestamp. Material signed is the octet stream followed by the line
of hashes as described in 2.4.
When a signature is made to certify a key/UserID pair, it is computed
across two packets-- the public key packet, and the separate User ID
packet: The packet headers (CTB (3.2.1) and length fields (3.2.2)) for the
public key packet and the user ID packet are both omitted from the
signature calculation for a key certification.
A key compromise certificate is issued by someone to revoke his own key
when his secret key is known or assumed to be compromised. If that
happens, a user would sign his own key compromise certificate with the key
that is being revoked. Even a encryption or storage key is used for this
signature to point out, that exactly this key is revoked. It is not
possible to revoke a encryption or storage key using the corresponding
certifictation or signature key. A key revoked by its own signature means
that this key should never be used or trusted again, in any form,
associated with any user ID. A key compromise certificate issued by the
keyholder invalidates any other key/user ID certifications made by anyone
else for that key. A key compromise signed by someone other than the key
holder is invalid.
If a key has been revoked, software must not allow its use to generate any
messages, and if an incoming message uses it, a warning must inform the
user that the key is invalidated. Its conforming to even not allow
decrypting or verifiying signatures make by this key.
A key/user ID revocation certificate (certificate revocation certificates)
issued by the keyholder must invalidate all other key certifications made
by anyone else for that key/user ID pair. Also, a third party certifier
may revoke his own previous certification of this key/user ID pair by
issuing a certificate revocation certificate. Such a revocation should not
affect the certifications by other third parties for this same key/user ID
pair.
5.1.3 Secret key packet
A secret key packet has the CTB (3.2.1) tag 5. It contain all information
of the secret component of a key pair. It must be stored using encryption.
It should not leave the local computer. If it is extracted locally, this
packet is followed by a sequence of user ID packets (5.1.9).
Only the keyowner has access to the secret component. Secret keys must not
be accessible to any other person or institution. This is even true for
employee keys of companies. If the key owner suspect a compromise by an
onther person, any company or any gouvernment of this secret component, he
must immedeatly revoke this key.
A secret key packet consists of:
- a version octet,
- a time value,
- a valitidy period,
- an algorithm octet determining the asymmetric cryptosystem,
- algorithm specific public data of the key,
- an algorithm octet determining the symmetric cryptosystem,
- optionally the initialisation vector of the symmetric encryption,
- encrypted algorithm specific secret data of the key, and
- a encrypted 16 bit checksum of the secret data.
The version octet is two for PGP versions <= 2.5 or three for newer PGP
versions.
The time value (4.4) determine the moment the is not valid before.
Ususally this is the creation time of the key.
The validity period is a two octet scalar number (4.1) determining the
validity period of the key in days. If it is zero, the key ha an unlimited
lifetime.
The algorithm identifier of the asymmetric cryptosystem is one for RSA,
sixteen for ElGamal, or seventeen for DSS.
The algorithm identifier of the symmetric cryptosystem is zero for
unencrypted (should only occur in not pagable memory), one for IDEA, two
for 3DES-EDE, or three for CAST5.
The initialisation vector is a scalar number (4.1) of the blocksize of the
symmetric algorithm. It is only necessary if encryption takes place.
All secret fields in the secret key certificate may be (passphrase)
encrypted, including the checksum. The checksum is calculated from all of
the bytes of the unenciphered secret components. The public fields are not
encrypted. The encrypted fields are done in cipher feedback mode (CFB),
and the checksum is used to tell if the password was good. The CFB
initialisation vector field is just encrypted random data using a zero
initialisation vector.
If the algorithm is RSA, the public component consits of:
- a MPI (4.2) of the public modulus n, and
- a MPI (4.2) of the public encryption exponent e
If the algorithm is RSA, the secret component consits of:
- a MPI (4.2) of the secret decryption exponent d,
- a MPI (4.2) of the secret factor p,
- a MPI (4.2) of the secret factor q, and
- a MPI (4.2) of the secret multiplicative inverse u.
If the algorithm is ElGamal, the public component data consists of:
- a MPI (4.2) of the prime p,
- a MPI (4.2) of the generator g, and
- a MPI (4.2) of the public key y (= g**x mod p where x is secret).
If the algorithm is DSS, the public component data consists of:
- a MPI (4.2) of the prime p,
- a MPI (4.2) of the group order q, (prime divisor of p-1)
- a MPI (4.2) of the generator g, and
- a MPI (4.2) of the public key y (= g**x mod p where x is secret).
5.1.4 Public key packet
A public key packet has the CTB (3.2.1) tag 6. It contains the public
component of an asymmetric key pair. This packet introduce a published
public key. It is followed by either the key compromise certificate or an
optional keyring trust packet (5.1.8) (owner trust) and several user ID
packets (5.1.9) chunks. Each user ID packet is followed in its chunk by an
optional keyring trust packet (keylegit) and several signature packets
(5.1.2) (certificates) optionally followed by a keyring trust packet
(signature trust).
A public key packet consits of:
- a version octet,
- a time value,
- a validity period,
- an algorithm identifier octet, and
- algorithm specific public component.
The version octet is two for PGP versions <= 2.5 or three for newer PGP
versions.
The time value (4.4) determine the moment the is not valid before.
Ususally this is the creation time of the key.
The validity period is a two octet scalar number (4.1) determining the
validity period of the key in days. If it is zero, the key ha an unlimited
lifetime.
The algorithm identifier of the asymmetric cryptosystem is one for RSA,
sixteen for ElGamal, or seventeen for DSS.
If the algorithm is RSA, the public component data consists of:
- a MPI (4.2) of the public modulus n, and
- a MPI (4.2) of the public encryption exponent e
If the algorithm is ElGamal, the public component data consists of:
- a MPI (4.2) of the prime p,
- a MPI (4.2) of the generator g, and
- a MPI (4.2) of the public key k.
If the algorithm is DSS, the public component data consists of:
- a MPI (4.2) of the prime p,
- a MPI (4.2) of the group order q,
- a MPI (4.2) of the generator g, and
- a MPI (4.2) of the public key k.
5.1.5 Compressed data packet
A compressed data packet has the CTB (3.2.1) tag 8. It contains external
data compressed to remove redundancy and save space. The compressed data
decompress into a layer seven octet stream conforming 3.2. Compressing
should be used on every external octet stream unless it enlarges the data
stream.
A compressed data packet consists of a algorithm identifier octet followed
by the octet stream of compressed data.
The algorithm identifier octet is one for ZIP.
[A description of ZIP is needed here.]
Compressed data packets are the prominent canidates for indefinit length
packets. So they are expeced as the last ones in their enclosing object,
and the decompressor knows when to stop.
5.1.6 Conventional key encrypted packet
A conventional key encrypted packet has the CTB (3.2.1) tag 9. It contains
an encrypted octet stream. It decrypts into a layer seven the octet stream
conforming 3.2. It is recommended to contain a compressed data packet to
avoid redundacy helpful to break the symmetric cipher.
The conventional key encrypted packet consists of a stream of
conventionally encrypted octets up to the end of the packet.
After decrypting the conventionally encrypted data, a special random
prefix stored as an eight octet scalar (4.1) and two key check octets are
revealed. The random prefix and key check prefix are inserted before
encryption and discarded after decryption. This prefix group is visible
after decrypting the ciphertext in the packet.
The random prefix serves to start off the cipher feedback chaining process
with 64 bits of random material. It may be discarded after decryption.
The key check prefix is composed of two identical copies of the least
significant octets of the random prefix, stored in the same order. During
decryption, the 9th and 10th octets of decrypted material are checked to
see if they match the 7th and 8th octets, respectively. If these key check
bytes meet this criterion, then the conventional key is assumed to be
correct.
One unusual point about the way encryption is done. Using the cipher in
CFB mode, the first ten octets are decrypted normally, but octets ten to
seventeen, the first eight octets of the data proper, are encrypted using
octets two to nine as the initialisation vector. This is essentially using
CFB-16 for one part of the encryption, while CFB-64 is used elsewhere.
5.1.7 Literal data packet
A literal data packet has the CTB (3.2.1) tag 11. The content of a literal
data packet is generic data and not subject to any further interpretation.
In order to transfer storage relevant information, a literal data packet
consists of the concatination of a mode octet, a string (4.3), a time field
(4.4) and the octet stream of the data itself.
The mode octet is either 0x62 (US-ASCII 'b'), 0x74 (US-ASCII 't'), 0x01 or
0x6C (US-ASCII 'l').
Mode 'b' is the binary mode. The octet stream should be stored as an octet
stream. No conversations must be made.
Mode 't' is the text mode. The octet stream is a character stream in the
given message charset. If no charset is defined in the message, assume
US-ASCII. All necessary translations should be applied including line
termination translation.
Mode 0x01 and 'l' are local mode. The octet stream contains data in local
storage conventions. If this mode is generated, only the mode octet 'l'
should be used. The existance of mode octet 0x01 is an typographic error of
RfC 1991.
The string is used a the default file name for storing on receiver's site.
Implementors should keep in mind the security problem of overwriting
existing files especially designing an automatic batch mode.
The time field should contain the time at which the file was last modified,
if not applicable the time at which the data packet was created. If no time
should be provided, the time value is set to zero. The receiver should set
the time of the received file to the provided value or to the current time,
if the time value is zero.
The octet stream of the data starts directly after the time field and ends
with the packet. If a signature includes a literal data packet (5.1.7),
only the octet stream of the data is joined to the signature. The octet
stream is used as is for the signature process. Any translation must be
done before generating or after checking the signature. This allows to
detach the signature from the data without resigning.
5.1.8 Keyring trust packet
A keyring trust packet has the CTB (3.2.1) tag 12. Keyring trust packets
should not exported with any key transaction, but may be occur in generic
PGP data. It is not uncommon to transfer a whole local keyring which
contains the trust packets. Trust packets may be exported without any
security risks, but must not included into the receiver's database.
The keyring trust packets may useful for implementing the web of trust as
described in 2.3. It only exists to speed up programms. It is described in
this RfC to discuss the trust model more in detail.
The meaning of the keyring trust packet is context sensitive. The trust byte
has three different definitions depending on whether it follows a public key
packet, a user ID packet, or a certificate on the ring.
It consists of a single octet:
+---------------+
|7 6 5 4 3 2 1 0|
+---------------+
If the keyring trust packet follows a public key packet, the following bit
definitions apply:
Bits 0-2 - OWNERTRUST bits - Trust bits for this key owner.
The OWNERTRUST bits are set by the user. Values are:
000 - undefined, or uninitialized trust.
001 - unknown, we don't know the owner of this key.
010 - usually do not trust this key owner to certify other keys.
101 - usually do trust this key owner to certify other keys.
110 - always trust this key owner to certify other keys.
111 - the secret part of this key is also present in the database.
User can't set the OWNERTRUST to this value without having the
corresponding secret part. Check enforced by software.
Bit 5 - DISABLED bit - Means that this key is disabled, and
must not be used.
Bit 7 - BUCKSTOP bit - OWNERTRUST == 111.
Signifies the ultimately-trusted "keyring owner".
"The buck stops here".
If the keyring trust packet follows a user ID packet, the following bit
definitions apply:
Bit 0-1 - KEYLEGIT bits - Validity bits for this key. Set if we believe
the preceding key is legitimately owned by who it appears to
belong to, specified by the preceding user ID. Computed from
various certificates trust packets that follow. If a user ID
is not certified by the key itself or the corresponding signature
key, the user ID must be assumed to be invalid. If a trusted
certificate revocation certificate exisits, the new trust can
not be derivated automatically. User interaction is required.
00 - unknown, undefined, or uninitialized trust.
01 - do not trust this key's ownership.
10 - marginal confidence of this key's ownership.
Totally useless for certifying other keys, but may be useful
for checking message certificates with an advisory warning
to the user. This requires any trusted certificate.
11 - completely trust this key's ownership.
This requires either:
- one ultimately trusted certificate (SIGTRUST=111)
- COMPLETES_NEEDED completely trusted certificate (SIGTRUST=110)
- MARGINALS_NEEDED marginally trusted certificate (SIGTRUST=101)
- the trust metric of 6.2.1 is one or more.
Bit 7 - WARNONLY bit - If the user wants to use a not fully validated
key for encryption, he is asked if he really wants to use this
key. If the user answers 'yes', the WARNONLY bit gets set,
and the next time he uses this key, only a warning will be
printed. This bit gets cleared during the maintenance pass.
If the keyring trust packet follows a certificate, the following bit
definitions apply:
Bits 0-2 - SIGTRUST bits - Trust bits for this certificate. Value is
copied directly from OWNERTRUST bits of signer:
000 - undefined, or uninitialized trust
001 - unknown
010 - untrusted certificate
101 - reasonably trusted certificate
110 - completely trusted certificate
111 - ultimately trusted certificate
Bit 6 - CHECKED bit - This means that the key checking pass has tested
this certificate and found it good. If this bit is not set, the
maintenance pass considers this certificate untrustworthy.
Bit 7 - CONTIG bit - Means this signature leads up a contiguous trusted
certification path all the way back to the ultimately-trusted
keyring owner, where the buck stops. This bit is derived
from other trust packets.
All other trust is derived from the BUCKSTOP keys in a special maintenance
pass over the key database. Any good signature made by a given key has its
SIGTRUST equal to the key's OWNERTRUST. Based on COMPLETES_NEEDED and
MARGINALS_NEEDED, if enough trusted certificates are on a key/userID pair,
the key/userid association is considered legitimate. If there is no
certificate from the keyowner itself (selfsigned or using the corresponding
signing key), the user ID is considered bogus and all certificates are
stripped away. If there is a certificate revocation certificate from the
keyowner itself, the user ID is considered invalid and all other
certificates are stripped away. If there are certificate revocation
certificates interaction with the user is required. The results of the last
interaction may be stored for reuse.
When a key has a legitimate user ID, the user is asked to set the OWNERTRUST
for the corresponding key. Ths idea is that the user ID identifies someone
the user knows, at least by reputation, so once it has been established who
holds the secret key, that person's trustworthiness as an introducer can be
established and assigned to the key.
Once that is done, this key's certificates then have weight establishing
other key/user ID associations.
There is a limit to the depth to which this can go. Keys which secret parts
are in the database are at depth zero. Keys certified by those keys are at
depth one. Keys which are fully certified using only certificates from keys
at depth one or less are at depth two. Keys which are fully certified using
only certificates from keys at depth two or less are at depth three, and so
on.
If you know all of your trusted introducers personally, and have certified
their keys, then you will never have a trused key at a depth of greater than
two. The maximum depth is limited my MAX_CERT_DEPTH. It should never get
very large in a well-connected "web of trust".
The trust of a key owner (OWNERTRUST) does not just reflect our estimation
of their personal integrity, it also reflects how competent we think they
are at understanding key management and using good judgement in signing
keys. The OWNERTRUST bits are not computed from anything -- it requires
asking the user for his opinion.
It must be possible for the user to modify the SIGTRUST or the KEYLEGIT bits
seperatly. This allows working assumptions if some certificates seems to be
unlikly. This is especially true for joke certificates or testing purposes.
New certificates are checked on adding them to the key database. Old
certificates are checked on request (checking pass). The maintenance pass is
run every time the key database changes, and operates in a
top-of-pyramid-down manner as follows.
If at any time during any of these steps the KEYLEGIT field goes from not
fully set to fully set, and the OWNERTRUST bits are still undefined, the
user is asked a question to define the OWNERTRUST bits. First, for all keys
with BUCKSTOP set, check if they are really present in the secret keyring,
if not, the BUCKSTOP bit is cleared and OWNERTRUST is requested from the
user. SIGTRUST and KEYLEGIT is initialized to zero for non-buckstop keys.
The real maintenance pass is done in a recursive scan: Start with BUCKSTOP
keys, find all user ID/key pairs certified by a key and update the trust
value of these certificates by copying the OWNERTRUST of the signer to the
SIGTRUST of the certificate. SIGTRUST values set by the user must remain.
If this makes a key fully validated, start looking for signatures made by
this key, and update the trust value for them. Repeat until everything has
settled down.
5.1.9 User ID packet
A user ID packet has the CTB (3.2.1) tag 13. The user ID packet follows a
public or secret key. The content is a octet stream of printable
characters up to the end of the packet.
When a key/user ID pair is certified, the signature covers both the public
key packet and the user ID packet. The certificate thereby logically binds
together the user ID with the key. The user ID packet is always associated
with the most recently occurring public key regardless of whether there
are other packet types appearing between the public key packet and the
associated user ID packet.
There may be more than one user ID packet after a public key packet. They
all would be associated with the preceding public key packet.
A user ID must be followed by a keyowner certificate or a keyowner
certificate revokation certificate to be valid.
5.1.10 Comment packet
A comment packet has the CTB (3.2.1) tag 14. A comment packet is generally
just skipped over, although it may be displayed to the user when
processed.
The content is a octet stream of printable characters up to the end of the
packet.
5.2 Packet version four or higher
5.2.1 Encrypted session key packet
An encrypted session key packet has the CTB (3.2.1) tag 1. It contains the
symmetric session key for symmetrically encrypted data packets (5.2.9)
later in the stream. If a message is encrypted to more recipients, such a
public key encrypted packet occurs for every recipient.
Software must not encrypt to anybody else without interaction with the
user. The user must have the full control over the list of recipients the
message is encrypted to. This explicitly includes the EncryptToSelf
configuration option of existing implementations. The software is now
required to ask the user explicitly if he wants to encrypt to additional
recipients or not.
The content of the encrypted session key packet is exactly the same syntax
and semantic as described in 5.1.1. The version octet is two or three as
described there.
5.2.2 Signature packet
A signature packet has the CTB (3.2.1) tag 2. It is used to store any
signature or certificate.
The sihnature packet consits of:
- a version octet, (set ot four)
- a signature classification octet, (hashed)
- a asymmetric cryptosystem identifier octet (hashed)
which is one for RSA, sixteen for ElGamal, or seventeen for DSS,
- a message digest algorithm (hashed)
which is one for MD5 or two for SHA-1,
- a two octet scalar (4.1) determining the length of the following
hashed subpackets, (hashed)
- a sequence of hashed subpackets (hashed),
- a two octet scalar (4.1) determining the length of the following
non hashed subpackets,
- a sequence of non hashed subpackets,
- the two most significant octets of message digest, and
- the algorithm specific encrypted message digest.
The signature contains subpackets of the following structure:
- a subpacket length (1 or 2 octets):
Length includes the type byte but not this length,
1st octet < 192: length is the numerical value of this octet
1st octet >= 192: length is equal to
(1st octet - 192) * 256 + (2nd byte) + 192;
- a subpacket type octet, critical if higest significant bit (Bit 7)
is set. The remaining bits six to zero are defined the type.
- subpacket specific data
The following subpacket types are defined. Some subpackets apply to the
signature itself and some are attributes of the key. Noncritical
subpackets may be displayed and must be ignored. Unrecognized subpackets
should be skipped unless marked critical. Sorted by subpacked type
(without critical bit):
2 - signature creation time
A time value (4.4) determining the signature was made.
3 - signature expiration time
The validity period of the signature. This is an eight octet scalar
continaing 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
signature never expires.
8 - user ID flags
It is an octet which is one, if the self-certificate belongs to the
primary user ID. Otherwise it is zero.
9 - key expiration time
The validity period of the key. This is an eight octet scalar
continaing 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.
11 - preferred symmetric algorithms
It is an stream of symmetric cryprosystem identifier octets with the
most perfered first. It should be assumed that only algorithms
listed are supported by the recipient's software. If this subpacket
is not included, IDEA is assumed. This is found on a self-signature.
16 - key ID of signer
An eight octect scalar (4.1) containing the key ID of the signer.
5.2.3 Conventionally encrypted session key packet
A conventionally encrypted session key packet has the CTB (3.2.1) tag 3.
It describes a session key that has been encrypted to a secondary
symmetric cipher. This allows a message to be encrypted to a company or
gouvernment key. It is a technique to implement key recovery.
Software must not generate or accept this packet in communication. Any
incoming message containing this packet must be considered escrowed. A
warning must be produced to the users frontend and should not be
decrypted. Without users supervision the message must be discarded without
decrypting it.
The body of this packet consists of:
- a version octet, (The current version is four.)
- an algorithm identifier octet,
- a string (4.3) selecting the recovery key,
- the encrypted session key itself.
[Further specification is yet not issued by PGP Inc.]
5.2.4 One-pass signature packet
An one-pass signature packet has the CTB (3.2.1) tag 4. It tells the
processing software how to compute a signature of later data packets, so
that it does not have to read the entire message or store the signature
information in memory before starting.
The body of this packet consists of:
- a version octet, (The current version is four.) [changed to draft00]
- a signature type octet,
- an algorithm identfier octet describing the message digest algorithm used,
- an algorithm identfier octet describing the asymmetric cryptosystem used,
- a key ID of the signing key, and
- a flag octet.
All octets are described in the signature packet (5.2.2).
The flag octet is one, if the signature is nested, or zero, if not.
[What does that mean?]
5.2.5 Secret key packet
A secret key packet has the CTB (3.2.1) tag 5. It contain all information
of the secret component of a key pair. It must be stored using encryption.
It should not leave the local computer. If it is extracted locally, this
packet is followed by a sequence of user ID packets (5.2.13).
Only the keyowner has access to the secret component. Secret keys must not
be accessible to any other person or institution. This is even true for
employee keys of companies. If the key owner suspect a compromise by an
onther person, any company or any gouvernment of this secret component, he
must immedeatly revoke this key.
A secret key packet consits of a version octet and the key material. If
the version octet is three or lower, the following data is described in
(5.1.3).
The version four packet format is similar to 5.1.3 except there is no
validity period field. The validity period may be specified in the self
signature.
5.2.6 Public key packet
A public key packet has the CTB (3.2.1) tag 6. It contains the public
component of an asymmetric key pair. This packet introduce a published
public key. It is followed by either the key compromise certificate or an
optional keyring trust packet (5.1.8) (owner trust) and several user ID
packets chunks. Each user ID packet is followed in its chunk by an
optional keyring trust packet (keylegit) and several signature packets
(certificates) optionally followed by a keyring trust packet (signature
trust).
A public key packet consits of a version octet and the public key
material. If the version octet is three or lower, the following data is
described in (5.1.4).
The version four packet format is similar to 5.1.4 except there is no
validity period field.
5.2.7 Secret subkey packet
A secret subkey packet has the CTB (3.2.1) tag 7. It contains a associated
subkey of a secret key (5.2.5) defined erlier in the octet stream. All
following (user ID) packets refering to a secret key uses this key instead
of the secret key of (5.2.5). Following secret subkeys refers to the
secret key of (5.2.5) instead.
Subkeys are useful to provide forward security by changing encryption keys
very often.
The content is exactly the same as described in 5.2.5.
5.2.8 Compressed data packet
A compressed data packet has the CTB (3.2.1) tag 8. It contains external
data compressed to remove redundancy and save space. The compressed data
decompress into a layer seven octet stream conforming 3.2. Compressing
should be used on every external octet stream unless it enlarges the data
stream.
The content is exactly the same as described in 5.1.5.
5.2.9 Symmetrically encrypted data packet
A symmetrically encrypted data packet has the CTB (3.2.1) tag 9. It
contains an encrypted octet stream. It decrypts into a layer seven the
octet stream conforming 3.2. It is recommended to contain a compressed
data packet to avoid redundacy helpful to break the symmetric cipher.
The content is exactly the same as described in 5.1.6.
5.2.10 Marker packet
A marker packet has the CTB (3.2.1) tag 10. It is used to provide a
standardized beginning of an octet stream conforming 3.2. It is recognised
by every version even, if the general structure defined in 3.2 will change
in future.
The content of a marker packet are the three octet sequence 0x50 0x47 0x50.
Applying US-ASCII it means "PGP".
5.2.11 Literal data packet
A literal data packet has the CTB (3.2.1) tag 11. The content of a literal
data packet is generic data and not subject to any further interpretation.
The content is exactly the same as described in 5.1.7.
5.2.12 Trust packet
A trust packet has the CTB (3.2.1) tag 12. It is an internal orgnaisation
packet.
The content is exactly the same as described in 5.1.8.
5.2.13 User ID packet
A user ID packet has the CTB (3.2.1) tag 13. The user ID packet follows a
public or secret key. The content is a string (4.3). The user ID packet
sematics are defined in 5.1.9.
5.2.14 Subkey packet
A subkey packet has the CTB (3.2.1) tag 14. It contains a associated
subkey of a public key (5.2.6) defined erlier in the octet stream. All
following packets (user IDs, certificates, trust packets, ...) refering to
a public key uses this key instead of the public key of (5.2.6). Following
subkeys refers to the public key of (5.2.6) instead.
Subkeys are useful to provide forward security by changing encryption keys
very often. So certificats of a subkey should be avoided.
The content is exactly the same as described in 5.2.6.
5.2.15 Comment packet
A comment Packet has the CTB (3.2.1) tag 16. It may be displayed and must
be ignored.
The content is exactly the same as described in 5.1.10.
6. Key identification
Usually the key ID is used to identify a key by software and the user ID is
used to identify a key by the user. Unfortunly there are many problems.
In order to certify a key, sometimes only the fingerprint is exchanged.
This is a dangerous behavior and must be avoided. To compare keys for
certifying all characteristic values - fingerprint, public key component
lengths, key ID, and user ID - has to be compared exactly.
The same goes for interactive software requests to select from ambiguios
keys.
6.1 Key ID
The key ID is the lower 64 bits of the modulus of a RSA key stored in
packet version three or lower. The key ID is the lower 64 bits of the
public key of en ElGamal or DSS key in packet version three or lower. It
is trivial to forge.
The key ID is the lower 64 bit of the fingerprint (6.3) of a key stored in
packet version four or higher.
Due to independed decentral key generation it is possible, that two keys
has the same key ID. There is no guarantee nor any method to prevent this.
That's why the key ID must be considered as not unique. Several keys with
the same key ID must be handeled by software without any problem.
If the user request a key providing a part of the key ID, software must be
present all matching keys to select the right one.
6.2 User ID
The user ID is a user provided string. It may contain everything
printable.
6.2.1 Primary user ID
A public key can have any number of user IDs. It is problematic to define,
which user ID should be printed if a special key is named.
Existing practice is to use the latest user ID added to the database. This
should be avoided, because later user IDs are often the the prefered ones.
Futhermore on any remote system (i.e. keyserver) the user IDs are added
in random order.
Software should use the latest signed primary user ID subkey packet. Older
primary user ID subkey packets may be deleted.
If no signed primary user ID subkey packet exists, the user ID with the
highest trust should be used. Note, that there is no known metric for
trust in the web of trust.
A possible solution is to add all trusted certificates of a certain user
ID/key binding. Fully trusted certificates should count the inverse of
COMPLETES_NEEDED and marginally trustet certificates should count the
inverse of MARGINALS_NEEDED.
Example:
UserID1 has three fully trusted certificates, six marginal trusted
certificates, and eleven untrusted certificates.
UserID2 has two fully trusted certificates, eight marginal trusted
certificates, and one untrusted certificate.
COMPLETES_NEEDED is two and MARGINALS_NEEDED is six.
So UserID1 has an 'trust value' of 3/2 + 6/6 = 2.5
So UserID2 has an 'trust value' of 2/2 + 8/6 = 2.333...
UserID1 is choosen as the primary user ID.
6.2.2 Matching multiple user IDs
Obviously there is no guarantee, that the user ID is unique.
Existing versions of PGP allow adding any user ID to any key in the local
keyring. This is widly used to add offending or misleading user IDs to
many keys. This RfC requires user IDs not selfsigned or signed with the
corresponding signature key to be removed from the database despite they
provide trusted certificates or not.
Usually the user selects the key to work with a substring of the user ID.
Some existing versions of PGP choose the first key with a matching user
ID. There are several attacks known to forge a lot of keys certified by
each other using exactly the same user IDs. That's why all matching user
IDs must be present to the user to select the right one.
6.2.3 User ID conventions
It is common to include several key properties to the user ID, due to lack
of support by software. The following convention is partially implemented
[3].
The general structure of a user ID should be usable as an RfC 822 [8]
address: Real Name (Comments) <eMail(_at_)do(_dot_)main> (Options)
The "Real Name" should be the name of the user. "Comments" may contain
human readble informations about the e-mail address given. Non US-ASCII
characters must be encoded using MIME [5]. "eMail(_at_)do(_dot_)main" is the
e-mail
address of the user. "Options" is any combination of:
Key usage (only one of the following may be used in a user ID)
SIGN -- sign external octet streams (documents).
ENCR -- encrypt external octet streams to the receiver.
STOR -- crypt files on a storage media.
CERT -- certify key/user ID bindings.
EXPIRE:yyyy-mm-dd
Defines the latest day the key is usable. Software must prevent
any cryptographic use of such keys except verifying signatures and
certificates made while the key was valid. yyyy is the year, mm the
month, and dd the day the key expires.
IN-CA:do.main
Denotes the responsible IN-CA for the person certified by this CA.
It is safe to ignore this option but generation should not be
prevented.
Examples:
Lutz Donnerhacke (UUCP dayly)
<lutz(_at_)as-node(_dot_)jena(_dot_)thur(_dot_)de> (ENCR)
L. Donnerhacke <Lutz(_dot_)Donnerhacke(_at_)Jena(_dot_)Thur(_dot_)De> (CERT
EXPIRE:1998-07-29)
6.3 Fingerprint
The fingerprint is a hash digest of the public key. Packet version three
or lower hashs only the content of a the MPIs of the public key components
using MD5. This allows the attack to move bits from one component of the
public key to an other without modifying the fingerprint. So only the
fingerprint and the length of the key components are a good characteristic
for a key.
Packet version four or higher use SHA-1 to hash a few header bytes
followed by the entire public key packet starting with the version field.
Here are the fields of the hash material:
- 0x99 (one octet),
- a two octet scalar (4.1) containing the length of the following data,
- the version number (one octet),
- the time stamp of key creation (4.4),
- the asymmetric cryptosystem identifier octet, and
- the algorithm specific public key components as full MPIs (4.2).
Due to independed decentral key generation it is possible, that two keys
has the same fingerprint. There is no guarantee nor any method to prevent
this. That's why the fingerprint must not be considered as unique. Several
keys with the same fingerprint must be handeled by software without any
problem.
7. Keyserver
7.1 E-Mail keyserver
....
7.2 DNS keyserver
....
7.3 HTTP keyserver
....
8. Notes
PGP and Pretty Good Privacy are trademarks of Pretty Good Privacy, Inc.
9. Security Considerations
....
10. Author's Address
IKS GmbH
IN-Root-CA
c/o Lutz Donnerhacke
Wildenbruchstr. 15
07747 Jena, Thuringia
Germany
Lutz(_dot_)Donnerhacke(_at_)Jena(_dot_)Thur(_dot_)De
Phone: +49-3641-675-642
Fax: +49-3641-675-655
11. References
[1] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message Exchange
Formats", RfC 1991, August 1996.
[2] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RfC 2015,
October 1996.
[3] Donnerhacke, L., et. al, "PGP263in - an improved international
version of PGP", ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/
[4] Eternity Logfile, https://www.iks-jena.de/mitarb/lutz/logfile/
[5] Borenstein, N., and Freed, N., "Multipurpose Internet Mail Extensions
(MIME) Part xxx: Format of Internet Message Bodies.", RfC 2045 ff.,
November 1996
[6] V.G. Cerf, "ASCII format for network interchange", RfC 20, October
1969.
[7] Campbell, Joe, "C Programmer's Guide to Serial Communications"
[8] D. Crocker, "Standard for the format of ARPA Internet text
messages", RfC 822, August 1982
[9] D. Balenson, "Privacy Enhancement for Internet Electronic Mail: Part
III: Algorithms, Modes, and Identifiers", RfC 1423, October 1993