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