draft-ietf-openpgp-formats-04.txt   draft-ietf-openpgp-formats-05.txt 
Network Working Group Jon Callas Network Working Group Jon Callas
Category: INTERNET-DRAFT Network Associates Category: INTERNET-DRAFT Network Associates
draft-ietf-openpgp-formats-04.txt draft-ietf-openpgp-formats-05.txt
Expires Dec 1998 Lutz Donnerhacke Expires Dec 1998 Lutz Donnerhacke
June 1998 IN-Root-CA Individual Network e.V. June 1998 IN-Root-CA Individual Network e.V.
Hal Finney Hal Finney
Network Associates Network Associates
Rodney Thayer Rodney Thayer
EIS Corporation EIS Corporation
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-formats-04.txt draft-ietf-openpgp-formats-05.txt
Copyright 1998 by The Internet Society. All Rights Reserved. Copyright 1998 by The Internet Society. All Rights Reserved.
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
skipping to change at page 3, line 44 skipping to change at page 3, line 44
5.11. User ID Packet (Tag 13) 37 5.11. User ID Packet (Tag 13) 37
6. Radix-64 Conversions 37 6. Radix-64 Conversions 37
6.1. An Implementation of the CRC-24 in "C" 38 6.1. An Implementation of the CRC-24 in "C" 38
6.2. Forming ASCII Armor 38 6.2. Forming ASCII Armor 38
6.3. Encoding Binary in Radix-64 40 6.3. Encoding Binary in Radix-64 40
6.4. Decoding Radix-64 41 6.4. Decoding Radix-64 41
6.5. Examples of Radix-64 42 6.5. Examples of Radix-64 42
6.6. Example of an ASCII Armored Message 42 6.6. Example of an ASCII Armored Message 42
7. Cleartext signature framework 42 7. Cleartext signature framework 42
7.1. Dash-Escaped Text 43 7.1. Dash-Escaped Text 43
8. Regular Expressions 43 8. Regular Expressions 44
9. Constants 44 9. Constants 44
9.1. Public Key Algorithms 44 9.1. Public Key Algorithms 44
9.2. Symmetric Key Algorithms 45 9.2. Symmetric Key Algorithms 45
9.3. Compression Algorithms 45 9.3. Compression Algorithms 45
9.4. Hash Algorithms 45 9.4. Hash Algorithms 45
10. Packet Composition 45 10. Packet Composition 46
10.1. Transferable Public Keys 46 10.1. Transferable Public Keys 46
10.2. OpenPGP Messages 47 10.2. OpenPGP Messages 47
11. Enhanced Key Formats 47 11. Enhanced Key Formats 47
11.1. Key Structures 47 11.1. Key Structures 47
11.2. Key IDs and Fingerprints 48 11.2. Key IDs and Fingerprints 48
12. Notes on Algorithms 49 12. Notes on Algorithms 49
12.1. Symmetric Algorithm Preferences 49 12.1. Symmetric Algorithm Preferences 49
12.2. Other Algorithm Preferences 50 12.2. Other Algorithm Preferences 50
12.2.1. Compression Preferences 50 12.2.1. Compression Preferences 50
12.2.2. Hash Algorithm Preferences 51 12.2.2. Hash Algorithm Preferences 51
skipping to change at page 14, line 22 skipping to change at page 14, line 22
32768 octets of data; 0xE1, next two octets of data; 0xE0, next one 32768 octets of data; 0xE1, next two octets of data; 0xE0, next one
octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last octet of data; 0xF0, next 65536 octets of data; 0xC5, 0xDD, last
1693 octets of data. This is just one possible encoding, and many 1693 octets of data. This is just one possible encoding, and many
variations are possible on the size of the Partial Body Length variations are possible on the size of the Partial Body Length
headers, as long as a regular Body Length header encodes the last headers, as long as a regular Body Length header encodes the last
portion of the data. Note also that the last Body Length header can portion of the data. Note also that the last Body Length header can
be a zero-length header. be a zero-length header.
An implementation MAY use Partial Body Lengths for data packets, be An implementation MAY use Partial Body Lengths for data packets, be
they literal, compressed, or encrypted. The first partial length they literal, compressed, or encrypted. The first partial length
MUST be at least 512 octets long. Partial Body Lengths MAY NOT be MUST be at least 512 octets long. Partial Body Lengths MUST NOT be
used for any other packet types. used for any other packet types.
Please note that in all of these explanations, the total length of Please note that in all of these explanations, the total length of
the packet is the length of the header(s) plus the length of the the packet is the length of the header(s) plus the length of the
body. body.
4.3. Packet Tags 4.3. Packet Tags
The packet tag denotes what type of packet the body holds. Note that The packet tag denotes what type of packet the body holds. Note that
old format headers can only have tags less than 16, whereas new old format headers can only have tags less than 16, whereas new
skipping to change at page 23, line 53 skipping to change at page 23, line 53
This is only found on a self-signature. This is only found on a self-signature.
5.2.3.8. Preferred compression algorithms 5.2.3.8. Preferred compression algorithms
(array of one-octet values) (array of one-octet values)
Compression algorithm numbers that indicate which algorithms the key Compression algorithm numbers that indicate which algorithms the key
holder prefers to use. Like the preferred symmetric algorithms, the holder prefers to use. Like the preferred symmetric algorithms, the
list is ordered. Algorithm numbers are in section 6. If this list is ordered. Algorithm numbers are in section 6. If this
subpacket is not included, ZIP is preferred. A zero denotes that subpacket is not included, ZIP is preferred. A zero denotes that
uncompressed data is preferred; the key holder's software may not uncompressed data is preferred; the key holder's software might have
have compression software. This is only found on a self-signature. no compression software in that implementation. This is only found
on a self-signature.
5.2.3.9. Signature expiration time 5.2.3.9. Signature expiration time
(4 octet time field) (4 octet time field)
The validity period of the signature. This is the number of seconds The validity period of the signature. This is the number of seconds
after the signature creation time that the signature expires. If after the signature creation time that the signature expires. If
this is not present or has a value of zero, it never expires. this is not present or has a value of zero, it never expires.
5.2.3.10. Exportable 5.2.3.10. Exportable
skipping to change at page 35, line 31 skipping to change at page 35, line 31
- One octet that gives the algorithm used to compress the packet. - One octet that gives the algorithm used to compress the packet.
- The remainder of the packet is compressed data. - The remainder of the packet is compressed data.
A Compressed Data Packet's body contains an block that compresses A Compressed Data Packet's body contains an block that compresses
some set of packets. See section "Packet Composition" for details on some set of packets. See section "Packet Composition" for details on
how messages are formed. how messages are formed.
ZIP-compressed packets are compressed with raw RFC1951 DEFLATE ZIP-compressed packets are compressed with raw RFC1951 DEFLATE
blocks. Note that PGP V2.6 uses 13 bits of compression. If an blocks. Note that PGP V2.6 uses 13 bits of compression. If an
implementation uses more bits of compression, If an implementation implementation uses more bits of compression, PGP V2.6 cannot
uses more bits of compression, PGP V2.6 cannot decompress it. decompress it.
ZLIB-compressed packets are compressed with RFC1950 ZLIB-style ZLIB-compressed packets are compressed with RFC1950 ZLIB-style
blocks. blocks.
5.7. Symmetrically Encrypted Data Packet (Tag 9) 5.7. Symmetrically Encrypted Data Packet (Tag 9)
The Symmetrically Encrypted Data packet contains data encrypted with The Symmetrically Encrypted Data packet contains data encrypted with
a symmetric-key algorithm. When it has been decrypted, it will a symmetric-key algorithm. When it has been decrypted, it will
typically contain other packets (often literal data packets or typically contain other packets (often literal data packets or
compressed data packets). compressed data packets).
skipping to change at page 40, line 17 skipping to change at page 40, line 17
- "Comment", a user-defined comment. - "Comment", a user-defined comment.
- "MessageID", a 32-character string of printable characters. The - "MessageID", a 32-character string of printable characters. The
string must be the same for all parts of a multi-part message string must be the same for all parts of a multi-part message
that uses the "PART X" Armor Header. MessageID strings should that uses the "PART X" Armor Header. MessageID strings should
be unique enough that the recipient of the mail can associate be unique enough that the recipient of the mail can associate
all the parts of a message with each other. A good checksum or all the parts of a message with each other. A good checksum or
cryptographic hash function is sufficient. cryptographic hash function is sufficient.
- "Hash", a comma-separated list of hash algorithms used in this
message. This is used only in clear-signed messages.
- "Charset", a description of the character set that the plantext
is in. Please note that OpenPGP defines text to be in UTF-8, so
this Armor Header Key is only useful for backwards
compatibility. An implementation MAY implement it; an
implementation MAY ignore it.
The MessageID SHOULD NOT appear unless it is in a multi-part The MessageID SHOULD NOT appear unless it is in a multi-part
message. If it appears at all, it MUST be computed from the message. If it appears at all, it MUST be computed from the
finished (encrypted, signed, etc.) message in a deterministic finished (encrypted, signed, etc.) message in a deterministic
fashion, rather than contain a purely random value. This is to fashion, rather than contain a purely random value. This is to
allow the legitimate recipient to determine that the MessageID allow the legitimate recipient to determine that the MessageID
cannot serve as a covert means of leaking cryptographic key cannot serve as a covert means of leaking cryptographic key
information. information.
The Armor Tail Line is composed in the same manner as the Armor The Armor Tail Line is composed in the same manner as the Armor
Header Line, except the string "BEGIN" is replaced by the string Header Line, except the string "BEGIN" is replaced by the string
skipping to change at page 43, line 4 skipping to change at page 43, line 9
Note that this example is indented by two spaces. Note that this example is indented by two spaces.
7. Cleartext signature framework 7. Cleartext signature framework
It is desirable to sign a textual octet stream without ASCII It is desirable to sign a textual octet stream without ASCII
armoring the stream itself, so the signed text is still readable armoring the stream itself, so the signed text is still readable
without special software. In order to bind a signature to such a without special software. In order to bind a signature to such a
cleartext, this framework is used. (Note that RFC 2015 defines cleartext, this framework is used. (Note that RFC 2015 defines
another way to clear sign messages for environments that support another way to clear sign messages for environments that support
MIME.) MIME.)
The cleartext signed message consists of: The cleartext signed message consists of:
- The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a - The cleartext header '-----BEGIN PGP SIGNED MESSAGE-----' on a
single line, single line,
- Zero or more "Hash" Armor Headers, - One or more "Hash" Armor Headers,
- Exactly one empty line not included into the message digest, - Exactly one empty line not included into the message digest,
- The dash-escaped cleartext that is included into the message - The dash-escaped cleartext that is included into the message
digest, digest,
- The ASCII armored signature(s) including the Armor Header and - The ASCII armored signature(s) including the Armor Header and
Armor Tail Lines. Armor Tail Lines.
If the "Hash" armor header is given, the specified message digest If the "Hash" armor header is given, the specified message digest
algorithm is used for the signature. If there are no such headers, algorithm is used for the signature. If there are no such headers,
SHA-1 is used. If more than one message digest is used in the MD5 is used, an implementation MAY omit them for V2.x compatibility.
signature, the "Hash" armor header contains a comma-delimited list If more than one message digest is used in the signature, the "Hash"
of used message digests. armor header contains a comma-delimited list of used message
digests.
Current message digest names are described below with the algorithm Current message digest names are described below with the algorithm
IDs. IDs.
7.1. Dash-Escaped Text 7.1. Dash-Escaped Text
The cleartext content of the message must also be dash-escaped. The cleartext content of the message must also be dash-escaped.
Dash escaped cleartext is the ordinary cleartext where every line Dash escaped cleartext is the ordinary cleartext where every line
starting with a dash '-' (0x2D) is prefixed by the sequence dash '-' starting with a dash '-' (0x2D) is prefixed by the sequence dash '-'
skipping to change at page 52, line 22 skipping to change at page 52, line 32
While verifying Elgamal signatures, note that it is important to While verifying Elgamal signatures, note that it is important to
test that r and s are less than p. If this test is not done then test that r and s are less than p. If this test is not done then
signatures can be trivially forged by using large r values of signatures can be trivially forged by using large r values of
approximately twice the length of p. This attack is also discussed approximately twice the length of p. This attack is also discussed
in the Bleichenbacher paper. in the Bleichenbacher paper.
Details on safe use of Elgamal signatures may be found in [MENEZES], Details on safe use of Elgamal signatures may be found in [MENEZES],
which discusses all the weaknesses described above. which discusses all the weaknesses described above.
If an implementation allows Elgamal signatures, then it MUST use the If an implementation allows Elgamal signatures, then it MUST use the
algorithm identifier 20. algorithm identifier 20 for an Elgamal public key that can sign.
An implementation SHOULD NOT implement Elgamal keys of size less An implementation SHOULD NOT implement Elgamal keys of size less
than 768 bits. For long-term security, Elgamal keys should be 1024 than 768 bits. For long-term security, Elgamal keys should be 1024
bits or longer. bits or longer.
12.6. DSA 12.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
768 bits. Note that present DSA is limited to a maximum of 1024 bit 768 bits. Note that present DSA is limited to a maximum of 1024 bit
keys, which are recommended for long-term use. keys, which are recommended for long-term use.
skipping to change at page 53, line 51 skipping to change at page 54, line 9
is assumed to be controlled by the proper party or parties. is assumed to be controlled by the proper party or parties.
Certain operations in this specification involve the use of random Certain operations in this specification involve the use of random
numbers. An appropriate entropy source should be used to generate numbers. An appropriate entropy source should be used to generate
these numbers. See RFC 1750. these numbers. See RFC 1750.
The MD5 hash algorithm has been found to have weaknesses The MD5 hash algorithm has been found to have weaknesses
(pseudo-collisions in the compress function) that make some people (pseudo-collisions in the compress function) that make some people
deprecate its use. They consider the SHA-1 algorithm better. deprecate its use. They consider the SHA-1 algorithm better.
Many security protocol designers think that it is a bad idea to use
a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces behind
the V4 key format with separate signature and encryption keys. If
you as an implementor promote dual-use keys, you should at least be
aware of this controversy.
The DSA algorithm will work with any 160-bit hash, but it is The DSA algorithm will work with any 160-bit hash, but it is
sensitive to the quality of the hash algorithm, if the hash sensitive to the quality of the hash algorithm, if the hash
algorithm is broken, it can leak the secret key. The Digital algorithm is broken, it can leak the secret key. The Digital
Signature Standard (DSS) specifies that DSA be used with SHA-1. Signature Standard (DSS) specifies that DSA be used with SHA-1.
RIPEMD-160 is considered by many cryptographers to be as strong. An RIPEMD-160 is considered by many cryptographers to be as strong. An
implementation should take care which hash algorithms are used with implementation should take care which hash algorithms are used with
DSA, as a weak hash can not only allow a signature to be forged, but DSA, as a weak hash can not only allow a signature to be forged, but
could leak the secret key. could leak the secret key. These same considerations about the
quality of the hash algorithm apply to Elgamal signatures.
If you are building an authentication system, the recipient may If you are building an authentication system, the recipient may
specify a preferred signing algorithm. However, the signer would be specify a preferred signing algorithm. However, the signer would be
foolish to use a weak algorithm simply because the recipient foolish to use a weak algorithm simply because the recipient
requests it. requests it.
Some of the encryption algorithms mentioned in this document have Some of the encryption algorithms mentioned in this document have
been analyzed less than others. For example, although CAST5 is been analyzed less than others. For example, although CAST5 is
presently considered strong, it has been analyzed less than presently considered strong, it has been analyzed less than
Triple-DES. Other algorithms may have other controversies Triple-DES. Other algorithms may have other controversies
skipping to change at page 55, line 6 skipping to change at page 55, line 27
look directly at the packet data type. look directly at the packet data type.
* In a clear-signed signature, PGP 5.0 will figure out the correct * In a clear-signed signature, PGP 5.0 will figure out the correct
hash algorithm if there is no "Hash:" header, but it will reject hash algorithm if there is no "Hash:" header, but it will reject
a mismatch between the header and the actual agorithm used. The a mismatch between the header and the actual agorithm used. The
"standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x "standard" (i.e. Zimmermann/Finney/et al.) version of PGP 2.x
rejects the "Hash:" header and assumes MD5. There are a number rejects the "Hash:" header and assumes MD5. There are a number
of enhanced variants of PGP 2.6.x that have been modified for of enhanced variants of PGP 2.6.x that have been modified for
SHA-1 signatures. SHA-1 signatures.
* PGP 5.0 can read an RSA key in V4 format, but will only * PGP 5.0 can read an RSA key in V4 format, but can only recognize
recognize it using V3 format. it with a V3 keyid, and can properly use only a V3 format RSA
key.
* There are many ways possible for for two keys to have the same * There are many ways possible for for two keys to have the same
key material, but different fingerprints (and thus key ids). key material, but different fingerprints (and thus key ids).
Perhaps the most interesting is an RSA key that has been Perhaps the most interesting is an RSA key that has been
"upgraded" to V4 format, but since a V4 fingerprint is "upgraded" to V4 format, but since a V4 fingerprint is
constructed by hashing the key creation time along with other constructed by hashing the key creation time along with other
things, two V4 keys created at different times, yet with the things, two V4 keys created at different times, yet with the
same key material will have different fingerprints. same key material will have different fingerprints.
* PGP 2.6.x and PGP 5.0 sometimes add to the beginning of a file a
zero-length compressed data packet.
* If an implemtation is using zlib to interoperate with PGP 2.x, * If an implemtation is using zlib to interoperate with PGP 2.x,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
15. Authors and Working Group Chair 15. Authors and Working Group Chair
The working group can be contacted via the current chair: The working group can be contacted via the current chair:
John W. Noerenberg, II John W. Noerenberg, II
Qualcomm, Inc Qualcomm, Inc
6455 Lusk Blvd 6455 Lusk Blvd
skipping to change at page 56, line 4 skipping to change at page 56, line 24
Wildenbruchstr. 15 Wildenbruchstr. 15
07745 Jena, Germany 07745 Jena, Germany
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Tel: +49-3641-675642 Tel: +49-3641-675642
Hal Finney Hal Finney
Network Associates, Inc. Network Associates, Inc.
4200 Bohannon Drive 4200 Bohannon Drive
Menlo Park, CA 94025, USA Menlo Park, CA 94025, USA
Email: hal@pgp.com Email: hal@pgp.com
Rodney Thayer Rodney Thayer
EIS Corporation EIS Corporation
Clearwater, FL 33767 Clearwater, FL 33767, USA
Email: rodney@unitran.com Email: rodney@unitran.com
This draft also draws on much previous work from a number of other This draft also draws on much previous work from a number of other
authors who include: Derek Atkins, Charles Breed, Dave Del Torto, authors who include: Derek Atkins, Charles Breed, Dave Del Torto,
Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Raph
Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and Levine, Colin Plumb, Will Price, William Stallings, Mark Weaver, and
Philip R. Zimmermann. Philip R. Zimmermann.
16. References 16. References
 End of changes. 

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