Thank you for mailing me and discussing. (I'm now read to also accept
spelling and grammer corrections ;-})
Base directory: ftp://ftp.iks-jena.de/pub/mitarb/lutz/crypt/software/pgp/
Current history: draft-ietf-pgp-formats.changes
21.10.1997
* Fingerprint derivated from public key format.
* Major extentions to signature subpackets (several new types).
* Signature subpacket derivated from general packet framework.
* Consequently use octet instead of byte.
* Secret key is derivated from public key.
* Added algorith identifiers 2 (RSA encr) and 3 (RSA sign).
* Backward compatibility derivated from packet version of public key.
* Started different trust models used by PGP 5.x. New trust packet.
21.10.1997
* Corrections on Ascii Armor.
* Armor header 'Version' defined to current use.
19.10.1997
* published fist version of the draft completely rewritten from fragments.
In detail: draft-ietf-pgp-formats.current.txt
--- draft-ietf-pgp-formats01.txt Mon Oct 20 09:36:53 1997
+++ draft-ietf-pgp-formats.current.txt Tue Oct 21 19:43:11 1997
@@ -1,10 +1,10 @@
INTERNET-DRAFT Lutz Donnerhacke
Security IN-Root-CA
Expires in six months Individual Network e.V.
- October 19 1997
+ October 21 1997
PGP Message Exchange Formats
- <draft-ietf-pgp-formats01.txt>
+ <draft-ietf-pgp-formats01a.txt>
Status of this Memo
@@ -195,7 +195,7 @@
- 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
@@ -235,7 +235,7 @@
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.
@@ -247,6 +247,9 @@
Note: Some of these lacks are fixed in PGP2.6.3in. [3]
+PGP 5.x provides two different trust models.
+ [pgpRngMnt.c http://www.inf.ethz.ch/personal/maurer/publications]
+
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
@@ -295,14 +298,17 @@
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'.
+'Ascii Armor'. For backward compatibility this format should be read but may
+not be generated.
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.
+information necessary to strip or apply this layer. Despite RfC 2015
+requires the use of Ascii Armor, this standard explicitly allows the level
+seven octect stream encoded directly using MIME itself (updates RfC 2015).
+This does not confuse existing applications, due to the fact that they can
+read and generate the level seven octet stream directly.
3.1.2 Ascii Armor
@@ -324,8 +330,8 @@
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:
+octets from the stream. Convert each octet 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|
@@ -423,13 +429,13 @@
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".
@@ -445,7 +451,7 @@
The following keywords are defined:
- Version -- Denotes the version used to generate this message.
+ Version -- Denotes the program 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".
@@ -464,7 +470,7 @@
-----BEGIN PGP MESSAGE-----
Version: 2.6.3in
-
+
owFbx8DAYFTCWlySkpkHZDKEFCXmFedmFhdn5ucpZKdWFiv4hgaHKPj5hygUpSbn
l6UWpabo8XIBAA==
=3m1o
@@ -496,12 +502,14 @@
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.
+with a dash '-' (US-ASCII 0x2D) or the sequence 0x46 0x72 0x6f 0x6d 0x20
+(US-ASCII "From ") is prepended by the sequence dash '-' (US-ASCII 0x2D) and
+space ' ' (US-ASCII 0x20). This prevents the parser from recognising armor
+headers in the cleartext itself. Futhermore it is a workaround for common
+mail clients escaping the "From " sequence itself, which causes invalid a
+signature. 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
@@ -514,6 +522,11 @@
single pass aware way ending with the indefinite length packet. This may
cause temorary storage of small amounts of data.
+For backward compatibility the packet version of a generated message should
+not exceed the packet version of any recipient's public key. Note that
+several PGP versions rewrite the packet version of a key from two to three
+without notice.
+
The octets of the PGP message are described in network bit order (highest
bit first).
@@ -539,7 +552,7 @@
1001 -- conventional key encrypted packet
1011 -- literal data packet
1100 -- keyring trust packet
- 1101 -- user id packet
+ 1101 -- user ID packet
1110 -- comment packet
other - undefined
@@ -552,24 +565,23 @@
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
+ 000001 -- asymmetric 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)
@@ -587,7 +599,7 @@
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.
+four octets length if it is necessary or not.
Example:
10111001 00000011 10010000 ...912 octets...
@@ -640,8 +652,8 @@
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.
+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
@@ -654,8 +666,8 @@
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
+The length field of an MPI should describe the length starting from its most
+significant non-zero bit. But software must be able to deal with leading
zero bits of an MPI.
4.3 Strings
@@ -699,7 +711,8 @@
The key ID (6.1) is an eight octet scalar number (4.1).
-The algorithm identifier is one for RSA or sixteen for ElGamal.
+The algorithm identifier is one for RSA, two for RSA (encryption only), 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).
@@ -713,7 +726,7 @@
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
@@ -723,7 +736,7 @@
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
@@ -760,22 +773,22 @@
- 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.
+ period of the signature in days. It must not be generated.
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 same MD5 hash. One would be a file of length N, with a seven octet
+ following section consisting of a signature type octet, four octets of
+ timestamp, and two of validity period, while the other would be a file of
+ length N+2, whose last two octets would be the siganture type octet and
+ the first octet of timestamp, and the last three octets of timestamp and
+ the validity period would instead be interpreted as a signature type octet
+ 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 asymmetric cryptosystem algorithm identifier octet is one for RSA, three
+for RSA (signature only), 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
@@ -803,7 +816,7 @@
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.
@@ -816,7 +829,7 @@
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
+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.
@@ -888,28 +901,11 @@
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,
+ - a complete public key packet (5.1.4) followed by
- 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
@@ -920,33 +916,18 @@
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
+the octets 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
@@ -974,10 +955,12 @@
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.
+lifetime. Note that this field is not present in packet version four or
+higher.
-The algorithm identifier of the asymmetric cryptosystem is one for RSA,
-sixteen for ElGamal, or seventeen for DSS.
+The algorithm identifier of the asymmetric cryptosystem is one for RSA, two
+for RSA (encryption only), three for RSA (signature only), 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
@@ -986,13 +969,13 @@
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.
+ - 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,
+ - 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 k.
+ - a MPI (4.2) of the public key y (= g**x mod p where x is secret).
5.1.5 Compressed data packet
@@ -1034,9 +1017,9 @@
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
+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
+octets 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
@@ -1099,9 +1082,9 @@
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.
+The meaning of the keyring trust packet is context sensitive. The trust
+octet 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:
+---------------+
@@ -1170,9 +1153,9 @@
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
+ 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
+ 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
@@ -1270,7 +1253,7 @@
5.2 Packet version four or higher
-5.2.1 Encrypted session key packet
+5.2.1 asymmetric 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)
@@ -1293,11 +1276,12 @@
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)
+The signature packet consits of:
+ - a version octet, (set to four)
- a signature classification octet, (hashed)
- a asymmetric cryptosystem identifier octet (hashed)
- which is one for RSA, sixteen for ElGamal, or seventeen for DSS,
+ which is one for RSA, three for RSA (signature only),
+ 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
@@ -1310,39 +1294,80 @@
- 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 length (one, two or four octets):
+ Length includes the type octet but not these length octets.
+ Semantics of the length octets is described in (3.2.2.2)
- 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):
+Some subpackets apply to the signature itself and some are attributes of the
+key. Noncritical subpackets may be displayed and must be ignored even if
+marked critical. Unrecognized hashed subpackets should be skipped unless
+marked critical. Subpackets of the same type may occur as often as needed.
+The following subpacket types are defined sorted by subpacked type (without
+critical bit):
+
+ 1 - signatue version
+ It is an octet determining the packet version used to generate this
+ signature.
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
+ The validity period of the signature. This is an four 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
+ 4 - user ID flags
It is an octet which is one, if the self-certificate belongs to the
- primary user ID. Otherwise it is zero.
-
+ primary user ID. Otherwise it is zero. This is found on a
+ self-signature.
+
+ 8 - key usage
+ It is an octet used as a bit field. This is found on a self-signature.
+ +---------------+
+ |7 6 5 4 3 2 1 0|
+ +---------------+
+ Bit 0: certification of other key/user ID bindings.
+ Bit 1: signing external data.
+ Bit 2: encrypt external data for communication.
+ Bit 3: encrypt external data for storage.
+
+ If this field is missing, this field is assumed to be 0x07 (certifying,
+ signing, and encypting communication).
+
+ Storage keys must must not be used in communication. They should be
+ droped from keyrings outside the desired storage enviroment to avoid
+ message key recovery. They must not occur on public keyservers. If
+ such a key arrives over the Internet, a warning must be produced and
+ the key must be droped (prefered) or disabled locally.
+
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.
+ The validity period of the key. This is an four 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.
+
+ 10 - symmetric key recovery key
+ This option consits of a class octet, a asymmetric cryptosystem
+ identifier octet, and twenty octets of the fingerprint. The last eight
+ octets are the key ID. So only keys of the packet format four or higher
+ can be used. This is found on a self-signature.
+
+ The class octet is one, if the use of this recovery key is required.
+ If it is zero, the use of this recovery key is up to the user. If data
+ is encrypted to such a key, it must/may (depending on the class octet)
+ be encrypted to each recovery key, too.
+
+ Keys containing this subpacket are local storage keys only. They must
+ not be used in communication. They should be droped from keyrings
+ outside the desired storage enviroment to avoid message key recovery.
+ They must not occur on public keyservers. If such a key arrives over
+ the Internet, a warning must be produced and the key must be droped
+ (prefered) or disabled locally.
11 - preferred symmetric algorithms
It is an stream of symmetric cryprosystem identifier octets with the
@@ -1350,9 +1375,28 @@
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.
-
+ 16 - key ID of the signer
+ An octect scalar (4.1) containing the last part of the key ID of the
+ signer. It is useful in conjunction with packet version four or
+ higher, where it can be extended to the full twenty octets of the
+ fingerprint (6.3).
+
+ 17 - user ID of the signer
+ The content of this subpacket is the user ID the signer wants to
+ display instead of its primary user ID. If this user ID does not
+ belong to the signer's key this packet should produce a warning and
+ must be ignored.
+
+ 18 - Unified Resource Locator
+ The content of this subpacket is a URL pointing to the policy used to
+ sign this key. The purpose is to determine the trustworthiness of the
+ signer. It is especially useful for certification authorities.
+
+ 19 - finger
+ The content of this subpacket is an e-mail address to finger for the
+ current public key of the signer. Providing this the verifier is able
+ to obtain the key (revocation certifcate) without problems. This finger
+ address should provide the key at least for the lifespan of the key.
5.2.3 Conventionally encrypted session key packet
@@ -1489,7 +1533,15 @@
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.
+A trust packet consits of one to tree octets as follows:
+ - a traditional trust octet (described in 5.1.8),
+ - a validity name octet, and
+ - a confidend introducer octet.
+
+The validity name octet and the confidend introducer octet may only present
+directly after a user ID packet. Both are generated using a more complex
+trust model. They should be written to KEYLEGIT if the trust packets are
+exported to a packet version of three or lower.
5.2.13 User ID packet
@@ -1532,16 +1584,19 @@
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 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
+an 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.
+Storing the same key in different packet versions cause the key to have
+different key IDs.
+
+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.
@@ -1581,12 +1636,12 @@
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
@@ -1618,7 +1673,7 @@
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.
@@ -1630,7 +1685,7 @@
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
@@ -1649,11 +1704,13 @@
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:
+Packet version four or higher use SHA-1 to hash a few header octets followed
+by the entire public key packet starting with the version field. Here are
+the fields of the hash material (essentially a complete public key packet
+(5.2.6) coded with in the wrong packet version, changing this would
+definitly ease programming and invalidating existing fingerprints):
- - 0x99 (one octet),
+ - CTB of version <= three public key packet: 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),
@@ -1683,7 +1740,7 @@
8. Notes
PGP and Pretty Good Privacy are trademarks of Pretty Good Privacy, Inc.
-
+
9. Security Considerations
....
@@ -1725,7 +1782,7 @@
[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