draft-ietf-openpgp-formats-07.txt | rfc2440.txt | |||
---|---|---|---|---|
Network Working Group Jon Callas | Network Working Group J. Callas | |||
Category: INTERNET-DRAFT Network Associates | Request for Comments: 2440 Network Associates | |||
draft-ietf-openpgp-formats-07.txt | Category: Standards Track L. Donnerhacke | |||
Expires Feb 1999 Lutz Donnerhacke | IN-Root-CA Individual Network e.V. | |||
August 1998 IN-Root-CA Individual Network e.V. | H. Finney | |||
Hal Finney | ||||
Network Associates | Network Associates | |||
R. Thayer | ||||
Rodney Thayer | ||||
EIS Corporation | EIS Corporation | |||
November 1998 | ||||
OpenPGP Message Format | OpenPGP Message Format | |||
draft-ietf-openpgp-formats-07.txt | ||||
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 specifies an Internet standards track protocol for the | |||
documents of the Internet Engineering Task Force (IETF), its areas, | Internet community, and requests discussion and suggestions for | |||
and its working groups. Note that other groups may also distribute | improvements. Please refer to the current edition of the "Internet | |||
working documents as Internet-Drafts. | Official Protocol Standards" (STD 1) for the standardization state | |||
and status of this protocol. Distribution of this memo is unlimited. | ||||
Internet-Drafts are draft documents valid for a maximum of six | Copyright Notice | |||
months and may be updated, replaced, or obsoleted by other documents | ||||
at any time. It is inappropriate to use Internet-Drafts as | ||||
reference material or to cite them other than as "work in progress." | ||||
To view the entire list of current Internet-Drafts, please check the | Copyright (C) The Internet Society (1998). All Rights Reserved. | |||
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow | ||||
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern | IESG Note | |||
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific | ||||
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). | This document defines many tag values, yet it doesn't describe a | |||
mechanism for adding new tags (for new features). Traditionally the | ||||
Internet Assigned Numbers Authority (IANA) handles the allocation of | ||||
new values for future expansion and RFCs usually define the procedure | ||||
to be used by the IANA. However, there are subtle (and not so | ||||
subtle) interactions that may occur in this protocol between new | ||||
features and existing features which result in a significant | ||||
reduction in over all security. Therefore, this document does not | ||||
define an extension procedure. Instead requests to define new tag | ||||
values (say for new encryption algorithms for example) should be | ||||
forwarded to the IESG Security Area Directors for consideration or | ||||
forwarding to the appropriate IETF Working Group for consideration. | ||||
Abstract | Abstract | |||
This document is maintained in order to publish all necessary | This document is maintained in order to publish all necessary | |||
information needed to develop interoperable applications based on | information needed to develop interoperable applications based on the | |||
the OpenPGP format. It is not a step-by-step cookbook for writing an | OpenPGP format. It is not a step-by-step cookbook for writing an | |||
application. It describes only the format and methods needed to | application. It describes only the format and methods needed to read, | |||
read, check, generate, and write conforming packets crossing any | check, generate, and write conforming packets crossing any network. | |||
network. It does not deal with storage and implementation questions. | It does not deal with storage and implementation questions. It does, | |||
It does, however, discuss implementation issues necessary to avoid | however, discuss implementation issues necessary to avoid security | |||
security flaws. | flaws. | |||
Open-PGP software uses a combination of strong public-key and | Open-PGP software uses a combination of strong public-key and | |||
symmetric cryptography to provide security services for electronic | symmetric cryptography to provide security services for electronic | |||
communications and data storage. These services include | communications and data storage. These services include | |||
confidentiality, key management, authentication, and digital | confidentiality, key management, authentication, and digital | |||
signatures. This document specifies the message formats used in | signatures. This document specifies the message formats used in | |||
OpenPGP. | OpenPGP. | |||
Table of Contents | Table of Contents | |||
Status of this Memo 1 | Status of this Memo 1 | |||
IESG Note 1 | ||||
Abstract 1 | Abstract 1 | |||
Table of Contents 2 | Table of Contents 2 | |||
1. Introduction 5 | 1. Introduction 4 | |||
1.1. Terms 5 | 1.1. Terms 5 | |||
2. General functions 5 | 2. General functions 5 | |||
2.1. Confidentiality via Encryption 5 | 2.1. Confidentiality via Encryption 5 | |||
2.2. Authentication via Digital signature 6 | 2.2. Authentication via Digital signature 6 | |||
2.3. Compression 7 | 2.3. Compression 7 | |||
2.4. Conversion to Radix-64 7 | 2.4. Conversion to Radix-64 7 | |||
2.5. Signature-Only Applications 7 | 2.5. Signature-Only Applications 7 | |||
3. Data Element Formats 7 | 3. Data Element Formats 7 | |||
3.1. Scalar numbers 7 | 3.1. Scalar numbers 8 | |||
3.2. Multi-Precision Integers 8 | 3.2. Multi-Precision Integers 8 | |||
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 9 | |||
3.6. String-to-key (S2K) specifiers 8 | 3.6. String-to-key (S2K) specifiers 9 | |||
3.6.1. String-to-key (S2k) specifier types 9 | 3.6.1. String-to-key (S2k) specifier types 9 | |||
3.6.1.1. Simple S2K 9 | 3.6.1.1. Simple S2K 9 | |||
3.6.1.2. Salted S2K 9 | 3.6.1.2. Salted S2K 10 | |||
3.6.1.3. Iterated and Salted S2K 10 | 3.6.1.3. Iterated and Salted S2K 10 | |||
3.6.2. String-to-key usage 10 | 3.6.2. String-to-key usage 11 | |||
3.6.2.1. Secret key encryption 10 | 3.6.2.1. Secret key encryption 11 | |||
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 12 | |||
4.1. Overview 11 | 4.1. Overview 12 | |||
4.2. Packet Headers 12 | 4.2. Packet Headers 12 | |||
4.2.1. Old-Format Packet Lengths 12 | 4.2.1. Old-Format Packet Lengths 13 | |||
4.2.2. New-Format Packet Lengths 13 | 4.2.2. New-Format Packet Lengths 13 | |||
4.2.2.1. One-Octet Lengths 13 | 4.2.2.1. One-Octet Lengths 14 | |||
4.2.2.2. Two-Octet Lengths 13 | 4.2.2.2. Two-Octet Lengths 14 | |||
4.2.2.3. Five-Octet Lengths 13 | 4.2.2.3. Five-Octet Lengths 14 | |||
4.2.2.4. Partial Body Lengths 13 | 4.2.2.4. Partial Body Lengths 14 | |||
4.2.3. Packet Length Examples 14 | 4.2.3. Packet Length Examples 14 | |||
4.3. Packet Tags 14 | 4.3. Packet Tags 15 | |||
5. Packet Types 15 | 5. Packet Types 16 | |||
5.1. Public-Key Encrypted Session Key Packets (Tag 1) 15 | 5.1. Public-Key Encrypted Session Key Packets (Tag 1) 16 | |||
5.2. Signature Packet (Tag 2) 16 | 5.2. Signature Packet (Tag 2) 17 | |||
5.2.1. Signature Types 16 | 5.2.1. Signature Types 17 | |||
5.2.2. Version 3 Signature Packet Format 18 | 5.2.2. Version 3 Signature Packet Format 19 | |||
5.2.3. Version 4 Signature Packet Format 20 | 5.2.3. Version 4 Signature Packet Format 21 | |||
5.2.3.1. Signature Subpacket Specification 21 | 5.2.3.1. Signature Subpacket Specification 22 | |||
5.2.3.2. Signature Subpacket Types 22 | 5.2.3.2. Signature Subpacket Types 24 | |||
5.2.3.3. Signature creation time 23 | 5.2.3.3. Signature creation time 25 | |||
5.2.3.4. Issuer 23 | 5.2.3.4. Issuer 25 | |||
5.2.3.5. Key expiration time 23 | 5.2.3.5. Key expiration time 25 | |||
5.2.3.6. Preferred symmetric algorithms 23 | 5.2.3.6. Preferred symmetric algorithms 25 | |||
5.2.3.7. Preferred hash algorithms 24 | 5.2.3.7. Preferred hash algorithms 25 | |||
5.2.3.8. Preferred compression algorithms 24 | 5.2.3.8. Preferred compression algorithms 26 | |||
5.2.3.9. Signature expiration time 24 | 5.2.3.9. Signature expiration time 26 | |||
5.2.3.10.Exportable Certification 24 | 5.2.3.10.Exportable Certification 26 | |||
5.2.3.11.Revocable 25 | 5.2.3.11.Revocable 27 | |||
5.2.3.12.Trust signature 25 | 5.2.3.12.Trust signature 27 | |||
5.2.3.13.Regular expression 25 | 5.2.3.13.Regular expression 27 | |||
5.2.3.14.Revocation key 26 | 5.2.3.14.Revocation key 27 | |||
5.2.3.15.Notation Data 26 | 5.2.3.15.Notation Data 28 | |||
5.2.3.16.Key server preferences 26 | 5.2.3.16.Key server preferences 28 | |||
5.2.3.17.Preferred key server 27 | 5.2.3.17.Preferred key server 29 | |||
5.2.3.18.Primary user id 27 | 5.2.3.18.Primary user id 29 | |||
5.2.3.19.Policy URL 27 | 5.2.3.19.Policy URL 29 | |||
5.2.3.20.Key Flags 27 | 5.2.3.20.Key Flags 29 | |||
5.2.3.21.Signer's User ID 28 | 5.2.3.21.Signer's User ID 30 | |||
5.2.3.22.Reason for Revocation 28 | 5.2.3.22.Reason for Revocation 30 | |||
5.2.4. Computing Signatures 29 | 5.2.4. Computing Signatures 31 | |||
5.2.4.1. Subpacket Hints 30 | 5.2.4.1. Subpacket Hints 32 | |||
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 30 | 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) 32 | |||
5.4. One-Pass Signature Packets (Tag 4) 31 | 5.4. One-Pass Signature Packets (Tag 4) 33 | |||
5.5. Key Material Packet 32 | 5.5. Key Material Packet 34 | |||
5.5.1. Key Packet Variants 32 | 5.5.1. Key Packet Variants 34 | |||
5.5.1.1. Public Key Packet (Tag 6) 32 | 5.5.1.1. Public Key Packet (Tag 6) 34 | |||
5.5.1.2. Public Subkey Packet (Tag 14) 32 | 5.5.1.2. Public Subkey Packet (Tag 14) 34 | |||
5.5.1.3. Secret Key Packet (Tag 5) 32 | 5.5.1.3. Secret Key Packet (Tag 5) 35 | |||
5.5.1.4. Secret Subkey Packet (Tag 7) 32 | 5.5.1.4. Secret Subkey Packet (Tag 7) 35 | |||
5.5.2. Public Key Packet Formats 32 | 5.5.2. Public Key Packet Formats 35 | |||
5.5.3. Secret Key Packet Formats 34 | 5.5.3. Secret Key Packet Formats 37 | |||
5.6. Compressed Data Packet (Tag 8) 36 | 5.6. Compressed Data Packet (Tag 8) 38 | |||
5.7. Symmetrically Encrypted Data Packet (Tag 9) 36 | 5.7. Symmetrically Encrypted Data Packet (Tag 9) 39 | |||
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 37 | 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) 39 | |||
5.9. Literal Data Packet (Tag 11) 37 | 5.9. Literal Data Packet (Tag 11) 40 | |||
5.10. Trust Packet (Tag 12) 38 | 5.10. Trust Packet (Tag 12) 40 | |||
5.11. User ID Packet (Tag 13) 38 | 5.11. User ID Packet (Tag 13) 41 | |||
6. Radix-64 Conversions 38 | 6. Radix-64 Conversions 41 | |||
6.1. An Implementation of the CRC-24 in "C" 39 | 6.1. An Implementation of the CRC-24 in "C" 42 | |||
6.2. Forming ASCII Armor 39 | 6.2. Forming ASCII Armor 42 | |||
6.3. Encoding Binary in Radix-64 41 | 6.3. Encoding Binary in Radix-64 44 | |||
6.4. Decoding Radix-64 42 | 6.4. Decoding Radix-64 46 | |||
6.5. Examples of Radix-64 43 | 6.5. Examples of Radix-64 46 | |||
6.6. Example of an ASCII Armored Message 43 | 6.6. Example of an ASCII Armored Message 47 | |||
7. Cleartext signature framework 43 | 7. Cleartext signature framework 47 | |||
7.1. Dash-Escaped Text 44 | 7.1. Dash-Escaped Text 47 | |||
8. Regular Expressions 44 | 8. Regular Expressions 48 | |||
9. Constants 45 | 9. Constants 49 | |||
9.1. Public Key Algorithms 45 | 9.1. Public Key Algorithms 49 | |||
9.2. Symmetric Key Algorithms 46 | 9.2. Symmetric Key Algorithms 49 | |||
9.3. Compression Algorithms 46 | 9.3. Compression Algorithms 50 | |||
9.4. Hash Algorithms 46 | 9.4. Hash Algorithms 50 | |||
10. Packet Composition 47 | 10. Packet Composition 50 | |||
10.1. Transferable Public Keys 47 | 10.1. Transferable Public Keys 50 | |||
10.2. OpenPGP Messages 48 | 10.2. OpenPGP Messages 52 | |||
11. Enhanced Key Formats 48 | 10.3. Detached Signatures 52 | |||
11.1. Key Structures 48 | 11. Enhanced Key Formats 52 | |||
11.2. Key IDs and Fingerprints 49 | 11.1. Key Structures 52 | |||
12. Notes on Algorithms 50 | 11.2. Key IDs and Fingerprints 53 | |||
12.1. Symmetric Algorithm Preferences 50 | 12. Notes on Algorithms 54 | |||
12.2. Other Algorithm Preferences 51 | 12.1. Symmetric Algorithm Preferences 54 | |||
12.2.1. Compression Preferences 51 | 12.2. Other Algorithm Preferences 55 | |||
12.2.2. Hash Algorithm Preferences 52 | 12.2.1. Compression Preferences 56 | |||
12.3. Plaintext 52 | 12.2.2. Hash Algorithm Preferences 56 | |||
12.4. RSA 52 | 12.3. Plaintext 56 | |||
12.5. Elgamal 52 | 12.4. RSA 56 | |||
12.6. DSA 53 | 12.5. Elgamal 57 | |||
12.7. Reserved Algorithm Numbers 53 | 12.6. DSA 58 | |||
12.8. OpenPGP CFB mode 54 | 12.7. Reserved Algorithm Numbers 58 | |||
13. Security Considerations 55 | 12.8. OpenPGP CFB mode 58 | |||
14. Implementation Nits 56 | 13. Security Considerations 59 | |||
15. Authors and Working Group Chair 57 | 14. Implementation Nits 60 | |||
16. References 58 | 15. Authors and Working Group Chair 62 | |||
17. Full Copyright Statement 59 | 16. References 63 | |||
17. Full Copyright Statement 65 | ||||
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 | |||
in RFC1991 "PGP Message Exchange Formats." | 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 | |||
term PGP 2.6.x. It used only RSA, MD5, and IDEA for its | PGP 2.6.x. It used only RSA, MD5, and IDEA for its cryptographic | |||
cryptographic transforms. An informational RFC, RFC1991, was | transforms. An informational RFC, RFC 1991, was written | |||
written describing this version of PGP. | 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 | |||
the community and also in the predecessor of this document, | community and also in the predecessor of this document, RFC 1991. | |||
RFC1991. It has new formats and corrects a number of problems in | It has new formats and corrects a number of problems in the PGP | |||
the PGP 2.6.x design. It is referred to here as PGP 5.x because | 2.6.x design. It is referred to here as PGP 5.x because that | |||
that software was the first release of the "PGP 3" code base. | 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. and are used with permission. | Network Associates, Inc. and are used with permission. | |||
This document uses the terms "MUST", "SHOULD", and "MAY" as defined | This document uses the terms "MUST", "SHOULD", and "MAY" as defined | |||
in RFC2119, along with the negated forms of those terms. | in RFC 2119, 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 6, line 5 | skipping to change at page 5, line 51 | |||
- radix-64 conversion | - radix-64 conversion | |||
In addition, OpenPGP provides key management and certificate | In addition, OpenPGP provides key management and certificate | |||
services, but many of these are beyond the scope of this document. | services, but many of these are beyond the scope of this document. | |||
2.1. Confidentiality via Encryption | 2.1. Confidentiality via Encryption | |||
OpenPGP uses two encryption methods to provide confidentiality: | OpenPGP uses two encryption methods to provide confidentiality: | |||
symmetric-key encryption and public key encryption. With public-key | symmetric-key encryption and public key encryption. With public-key | |||
encryption, the object is encrypted using a symmetric encryption | encryption, the object is encrypted using a symmetric encryption | |||
algorithm. Each symmetric key is used only once. A new "session | algorithm. Each symmetric key is used only once. A new "session key" | |||
key" is generated as a random number for each message. Since it is | is generated as a random number for each message. Since it is used | |||
used only once, the session key is bound to the message and | only once, the session key is bound to the message and transmitted | |||
transmitted with it. To protect the key, it is encrypted with the | with it. To protect the key, it is encrypted with the receiver's | |||
receiver's public key. The sequence is as follows: | public key. The sequence is as follows: | |||
1. The sender creates a message. | 1. The sender creates a message. | |||
2. The sending OpenPGP generates a random number to be used as a | 2. The sending OpenPGP generates a random number to be used as a | |||
session key for this message only. | session key for this message only. | |||
3. The session key is encrypted using each recipient's public key. | 3. The session key is encrypted using each recipient's public key. | |||
These "encrypted session keys" start the message. | These "encrypted session keys" start the message. | |||
4. The sending OpenPGP encrypts the message using the session key, | 4. The sending OpenPGP encrypts the message using the session key, | |||
which forms the remainder of the message. Note that the message | which forms the remainder of the message. Note that the message | |||
is also usually compressed. | is also usually compressed. | |||
5. The receiving OpenPGP decrypts the session key using the | 5. The receiving OpenPGP decrypts the session key using the | |||
recipient's private key. | recipient's private key. | |||
6. The receiving OpenPGP decrypts the message using the session | 6. The receiving OpenPGP decrypts the message using the session key. | |||
key. If the message was compressed, it will be decompressed. | If the message was compressed, it will be decompressed. | |||
With symmetric-key encryption, an object may be encrypted with a | With symmetric-key encryption, an object may be encrypted with a | |||
symmetric key derived from a passphrase (or other shared secret), or | symmetric key derived from a passphrase (or other shared secret), or | |||
a two-stage mechanism similar to the public-key method described | a two-stage mechanism similar to the public-key method described | |||
above in which a session key is itself encrypted with a symmetric | above in which a session key is itself encrypted with a symmetric | |||
algorithm keyed from a shared secret. | algorithm keyed from a shared secret. | |||
Both digital signature and confidentiality services may be applied | Both digital signature and confidentiality services may be applied to | |||
to the same message. First, a signature is generated for the message | the same message. First, a signature is generated for the message and | |||
and attached to the message. Then, the message plus signature is | attached to the message. Then, the message plus signature is | |||
encrypted using a symmetric session key. Finally, the session key is | encrypted using a symmetric session key. Finally, the session key is | |||
encrypted using public-key encryption and prefixed to the encrypted | encrypted using public-key encryption and prefixed to the encrypted | |||
block. | block. | |||
2.2. Authentication via Digital signature | 2.2. Authentication via Digital signature | |||
The digital signature uses a hash code or message digest algorithm, | The digital signature uses a hash code or message digest algorithm, | |||
and a public-key signature algorithm. The sequence is as follows: | and a public-key signature algorithm. The sequence is as follows: | |||
1. The sender creates a message. | 1. The sender creates a message. | |||
skipping to change at page 7, line 35 | skipping to change at page 7, line 33 | |||
through channels that are not safe to raw binary data, a printable | through channels that are not safe to raw binary data, a printable | |||
encoding of these binary octets is needed. OpenPGP provides the | encoding of these binary octets is needed. OpenPGP provides the | |||
service of converting the raw 8-bit binary octet stream to a stream | service of converting the raw 8-bit binary octet stream to a stream | |||
of printable ASCII characters, called Radix-64 encoding or ASCII | of printable ASCII characters, called Radix-64 encoding or ASCII | |||
Armor. | Armor. | |||
Implementations SHOULD provide Radix-64 conversions. | Implementations SHOULD provide Radix-64 conversions. | |||
Note that many applications, particularly messaging applications, | Note that many applications, particularly messaging applications, | |||
will want more advanced features as described in the OpenPGP-MIME | will want more advanced features as described in the OpenPGP-MIME | |||
document, RFC2015. An application that implements OpenPGP for | document, RFC 2015. An application that implements OpenPGP for | |||
messaging SHOULD implement OpenPGP-MIME. | messaging SHOULD implement OpenPGP-MIME. | |||
2.5. Signature-Only Applications | 2.5. Signature-Only Applications | |||
OpenPGP is designed for applications that use both encryption and | OpenPGP is designed for applications that use both encryption and | |||
signatures, but there are a number of problems that are solved by a | signatures, but there are a number of problems that are solved by a | |||
signature-only implementation. Although this specification requires | signature-only implementation. Although this specification requires | |||
both encryption and signatures, it is reasonable for there to be | both encryption and signatures, it is reasonable for there to be | |||
subset implementations that are non-comformant only in that they | subset implementations that are non-comformant only in that they omit | |||
omit encryption. | encryption. | |||
3. Data Element Formats | 3. Data Element Formats | |||
This section describes the data elements used by OpenPGP. | This section describes the data elements used by OpenPGP. | |||
3.1. Scalar numbers | 3.1. Scalar numbers | |||
Scalar numbers are unsigned, and are always stored in big-endian | Scalar numbers are unsigned, and are always stored in big-endian | |||
format. Using n[k] to refer to the kth octet being interpreted, the | format. Using n[k] to refer to the kth octet being interpreted, the | |||
value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a | value of a two-octet scalar is ((n[0] << 8) + n[1]). The value of a | |||
skipping to change at page 8, line 31 | skipping to change at page 8, line 38 | |||
(all numbers are in hexadecimal) | (all numbers are in hexadecimal) | |||
The string of octets [00 01 01] forms an MPI with the value 1. The | The string of octets [00 01 01] forms an MPI with the value 1. The | |||
string [00 09 01 FF] forms an MPI with the value of 511. | string [00 09 01 FF] forms an MPI with the value of 511. | |||
Additional rules: | Additional rules: | |||
The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. | The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. | |||
The length field of an MPI describes the length starting from its | The length field of an MPI describes the length starting from its | |||
most significant non-zero bit. Thus, the MPI [00 02 01] is not | most significant non-zero bit. Thus, the MPI [00 02 01] is not formed | |||
formed correctly. It should be [00 01 01]. | correctly. It should be [00 01 01]. | |||
3.3. Key IDs | 3.3. Key IDs | |||
A Key ID is an eight-octet scalar that identifies a key. | A Key ID is an eight-octet scalar that identifies a key. | |||
Implementations SHOULD NOT assume that Key IDs are unique. The | Implementations SHOULD NOT assume that Key IDs are unique. The | |||
section, "Enhanced Key Formats" below describes how Key IDs are | section, "Enhanced Key Formats" below describes how Key IDs are | |||
formed. | formed. | |||
3.4. Text | 3.4. Text | |||
The default character set for text is the UTF-8 [RFC2279] encoding | The default character set for text is the UTF-8 [RFC2279] encoding of | |||
of Unicode [ISO10646]. | Unicode [ISO10646]. | |||
3.5. Time fields | 3.5. Time fields | |||
A time field is an unsigned four-octet number containing the number | A time field is an unsigned four-octet number containing the number | |||
of seconds elapsed since midnight, 1 January 1970 UTC. | of seconds elapsed since midnight, 1 January 1970 UTC. | |||
3.6. String-to-key (S2K) specifiers | 3.6. String-to-key (S2K) specifiers | |||
String-to-key (S2K) specifiers are used to convert passphrase | String-to-key (S2K) specifiers are used to convert passphrase strings | |||
strings into symmetric-key encryption/decryption keys. They are | into symmetric-key encryption/decryption keys. They are used in two | |||
used in two places, currently: to encrypt the secret part of private | places, currently: to encrypt the secret part of private keys in the | |||
keys in the private keyring, and to convert passphrases to | private keyring, and to convert passphrases to encryption keys for | |||
encryption keys for symmetrically encrypted messages. | symmetrically encrypted messages. | |||
3.6.1. String-to-key (S2k) specifier types | 3.6.1. String-to-key (S2k) specifier types | |||
There are three types of S2K specifiers currently supported, as | There are three types of S2K specifiers currently supported, as | |||
follows: | follows: | |||
3.6.1.1. Simple S2K | 3.6.1.1. Simple S2K | |||
This directly hashes the string to produce the key data. See below | This directly hashes the string to produce the key data. See below | |||
for how this hashing is done. | for how this hashing is done. | |||
skipping to change at page 9, line 27 | skipping to change at page 9, line 38 | |||
Octet 0: 0x00 | Octet 0: 0x00 | |||
Octet 1: hash algorithm | Octet 1: hash algorithm | |||
Simple S2K hashes the passphrase to produce the session key. The | Simple S2K hashes the passphrase to produce the session key. The | |||
manner in which this is done depends on the size of the session key | manner in which this is done depends on the size of the session key | |||
(which will depend on the cipher used) and the size of the hash | (which will depend on the cipher used) and the size of the hash | |||
algorithm's output. If the hash size is greater than or equal to the | algorithm's output. If the hash size is greater than or equal to the | |||
session key size, the high-order (leftmost) octets of the hash are | session key size, the high-order (leftmost) octets of the hash are | |||
used as the key. | used as the key. | |||
If the hash size is less than the key size, multiple instances of | If the hash size is less than the key size, multiple instances of the | |||
the hash context are created -- enough to produce the required key | hash context are created -- enough to produce the required key data. | |||
data. These instances are preloaded with 0, 1, 2, ... octets of | These instances are preloaded with 0, 1, 2, ... octets of zeros (that | |||
zeros (that is to say, the first instance has no preloading, the | is to say, the first instance has no preloading, the second gets | |||
second gets preloaded with 1 octet of zero, the third is preloaded | preloaded with 1 octet of zero, the third is preloaded with two | |||
with two octets of zeros, and so forth). | octets of zeros, and so forth). | |||
As the data is hashed, it is given independently to each hash | As the data is hashed, it is given independently to each hash | |||
context. Since the contexts have been initialized differently, they | context. Since the contexts have been initialized differently, they | |||
will each produce different hash output. Once the passphrase is | will each produce different hash output. Once the passphrase is | |||
hashed, the output data from the multiple hashes is concatenated, | hashed, the output data from the multiple hashes is concatenated, | |||
first hash leftmost, to produce the key data, with any excess octets | first hash leftmost, to produce the key data, with any excess octets | |||
on the right discarded. | on the right discarded. | |||
3.6.1.2. Salted S2K | 3.6.1.2. Salted S2K | |||
skipping to change at page 10, line 32 | skipping to change at page 10, line 46 | |||
The above formula is in C, where "Int32" is a type for a 32-bit | The above formula is in C, where "Int32" is a type for a 32-bit | |||
integer, and the variable "c" is the coded count, Octet 10. | integer, and the variable "c" is the coded count, Octet 10. | |||
Iterated-Salted S2K hashes the passphrase and salt data multiple | Iterated-Salted S2K hashes the passphrase and salt data multiple | |||
times. The total number of octets to be hashed is specified in the | times. The total number of octets to be hashed is specified in the | |||
encoded count in the S2K specifier. Note that the resulting count | encoded count in the S2K specifier. Note that the resulting count | |||
value is an octet count of how many octets will be hashed, not an | value is an octet count of how many octets will be hashed, not an | |||
iteration count. | iteration count. | |||
Initially, one or more hash contexts are set up as with the other | Initially, one or more hash contexts are set up as with the other S2K | |||
S2K algorithms, depending on how many octets of key data are needed. | algorithms, depending on how many octets of key data are needed. | |||
Then the salt, followed by the passphrase data is repeatedly hashed | Then the salt, followed by the passphrase data is repeatedly hashed | |||
until the number of octets specified by the octet count has been | until the number of octets specified by the octet count has been | |||
hashed. The one exception is that if the octet count is less than | hashed. The one exception is that if the octet count is less than | |||
the size of the salt plus passphrase, the full salt plus passphrase | the size of the salt plus passphrase, the full salt plus passphrase | |||
will be hashed even though that is greater than the octet count. | will be hashed even though that is greater than the octet count. | |||
After the hashing is done the data is unloaded from the hash | After the hashing is done the data is unloaded from the hash | |||
context(s) as with the other S2K algorithms. | context(s) as with the other S2K algorithms. | |||
3.6.2. String-to-key usage | 3.6.2. String-to-key usage | |||
Implementations SHOULD use salted or iterated-and-salted S2K | Implementations SHOULD use salted or iterated-and-salted S2K | |||
specifiers, as simple S2K specifiers are more vulnerable to | specifiers, as simple S2K specifiers are more vulnerable to | |||
dictionary attacks. | dictionary attacks. | |||
3.6.2.1. Secret key encryption | 3.6.2.1. Secret key encryption | |||
skipping to change at page 11, line 22 | skipping to change at page 11, line 40 | |||
possibilities: | possibilities: | |||
0: secret data is unencrypted (no pass phrase) | 0: secret data is unencrypted (no pass phrase) | |||
255: followed by algorithm octet and S2K specifier | 255: followed by algorithm octet and S2K specifier | |||
Cipher alg: use Simple S2K algorithm using MD5 hash | Cipher alg: use Simple S2K algorithm using MD5 hash | |||
This last possibility, the cipher algorithm number with an implicit | This last possibility, the cipher algorithm number with an implicit | |||
use of MD5 and IDEA, is provided for backward compatibility; it MAY | use of MD5 and IDEA, is provided for backward compatibility; it MAY | |||
be understood, but SHOULD NOT be generated, and is deprecated. | be understood, but SHOULD NOT be generated, and is deprecated. | |||
These are followed by an 8-octet Initial Vector for the decryption | These are followed by an 8-octet Initial Vector for the decryption of | |||
of the secret values, if they are encrypted, and then the secret key | the secret values, if they are encrypted, and then the secret key | |||
values themselves. | values themselves. | |||
3.6.2.2. Symmetric-key message encryption | 3.6.2.2. Symmetric-key message encryption | |||
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) | OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet | |||
packet at the front of a message. This is used to allow S2K | at the front of a message. This is used to allow S2K specifiers to | |||
specifiers to be used for the passphrase conversion or to create | be used for the passphrase conversion or to create messages with a | |||
messages with a mix of symmetric-key ESKs and public-key ESKs. This | mix of symmetric-key ESKs and public-key ESKs. This allows a message | |||
allows a message to be decrypted either with a passphrase or a | to be decrypted either with a passphrase or a public key. | |||
public key. | ||||
PGP 2.X always used IDEA with Simple string-to-key conversion when | PGP 2.X always used IDEA with Simple string-to-key conversion when | |||
encrypting a message with a symmetric algorithm. This is deprecated, | encrypting a message with a symmetric algorithm. This is deprecated, | |||
but MAY be used for backward-compatibility. | but MAY be used for backward-compatibility. | |||
4. Packet Syntax | 4. Packet Syntax | |||
This section describes the packets used by OpenPGP. | This section describes the packets used by OpenPGP. | |||
4.1. Overview | 4.1. Overview | |||
An OpenPGP message is constructed from a number of records that are | An OpenPGP message is constructed from a number of records that are | |||
traditionally called packets. A packet is a chunk of data that has a | traditionally called packets. A packet is a chunk of data that has a | |||
tag specifying its meaning. An OpenPGP message, keyring, | tag specifying its meaning. An OpenPGP message, keyring, certificate, | |||
certificate, and so forth consists of a number of packets. Some of | and so forth consists of a number of packets. Some of those packets | |||
those packets may contain other OpenPGP packets (for example, a | may contain other OpenPGP packets (for example, a compressed data | |||
compressed data packet, when uncompressed, contains OpenPGP | packet, when uncompressed, contains OpenPGP packets). | |||
packets). | ||||
Each packet consists of a packet header, followed by the packet | Each packet consists of a packet header, followed by the packet body. | |||
body. The packet header is of variable length. | The packet header is of variable length. | |||
4.2. Packet Headers | 4.2. Packet Headers | |||
The first octet of the packet header is called the "Packet Tag." It | The first octet of the packet header is called the "Packet Tag." It | |||
determines the format of the header and denotes the packet contents. | determines the format of the header and denotes the packet contents. | |||
The remainder of the packet header is the length of the packet. | The remainder of the packet header is the length of the packet. | |||
Note that the most significant bit is the left-most bit, called bit | Note that the most significant bit is the left-most bit, called bit | |||
7. A mask for this bit is 0x80 in hexadecimal. | 7. A mask for this bit is 0x80 in hexadecimal. | |||
skipping to change at page 12, line 53 | skipping to change at page 13, line 26 | |||
2 - The packet has a four-octet length. The header is 5 octets long. | 2 - The packet has a four-octet length. The header is 5 octets long. | |||
3 - The packet is of indeterminate length. The header is 1 octet | 3 - The packet is of indeterminate length. The header is 1 octet | |||
long, and the implementation must determine how long the packet | long, and the implementation must determine how long the packet | |||
is. If the packet is in a file, this means that the packet | is. If the packet is in a file, this means that the packet | |||
extends until the end of the file. In general, an implementation | extends until the end of the file. In general, an implementation | |||
SHOULD NOT use indeterminate length packets except where the end | SHOULD NOT use indeterminate length packets except where the end | |||
of the data will be clear from the context, and even then it is | of the data will be clear from the context, and even then it is | |||
better to use a definite length, or a new-format header. The | better to use a definite length, or a new-format header. The | |||
new-format headers described below have a mechanism for | new-format headers described below have a mechanism for precisely | |||
precisely encoding data of indeterminate length. | encoding data of indeterminate length. | |||
4.2.2. New-Format Packet Lengths | 4.2.2. New-Format Packet Lengths | |||
New format packets have four possible ways of encoding length: | New format packets have four possible ways of encoding length: | |||
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 | |||
the issuer, Partial Body Length headers encode a packet of | issuer, Partial Body Length headers encode a packet of | |||
indeterminate 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 | |||
A two-octet Body Length header encodes a length of from 192 to 8383 | A two-octet Body Length header encodes a length of from 192 to 8383 | |||
octets. It is recognized because its first octet is in the range | octets. It is recognized because its first octet is in the range 192 | |||
192 to 223. The body length is equal to: | to 223. The body length is equal to: | |||
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 | bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 | |||
4.2.2.3. Five-Octet Lengths | 4.2.2.3. Five-Octet Lengths | |||
A five-octet Body Length header consists of a single octet holding | A five-octet Body Length header consists of a single octet holding | |||
the value 255, followed by a four-octet scalar. The body length is | the value 255, followed by a four-octet scalar. The body length is | |||
equal to: | equal to: | |||
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | | bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | | |||
(4th_octet << 8) | 5th_octet | (4th_octet << 8) | 5th_octet | |||
4.2.2.4. Partial Body Lengths | 4.2.2.4. Partial Body Lengths | |||
A Partial Body Length header is one octet long and encodes the | A Partial Body Length header is one octet long and encodes the length | |||
length of only part of the data packet. This length is a power of 2, | of only part of the data packet. This length is a power of 2, from 1 | |||
from 1 to 1,073,741,824 (2 to the 30th power). It is recognized by | to 1,073,741,824 (2 to the 30th power). It is recognized by its one | |||
its one octet value that is greater than or equal to 224, and less | octet value that is greater than or equal to 224, and less than 255. | |||
than 255. The partial body length is equal to: | The partial body length is equal to: | |||
partialBodyLen = 1 << (1st_octet & 0x1f); | partialBodyLen = 1 << (1st_octet & 0x1f); | |||
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. | |||
header. Partial Body Length headers may only be used for the | Partial Body Length headers may only be used for the non-final parts | |||
non-final parts of the packet. | 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 | These examples show ways that new-format packets might encode the | |||
packet lengths. | 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 | |||
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 | |||
1693 octets of data. This is just one possible encoding, and many | 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 | |||
MUST be at least 512 octets long. Partial Body Lengths MUST NOT be | be at least 512 octets long. Partial Body Lengths MUST NOT be used | |||
used for any other packet types. | 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 | |||
format headers can have tags as great as 63. The defined tags (in | format headers can have tags as great as 63. The defined tags (in | |||
skipping to change at page 15, line 25 | skipping to change at page 16, line 15 | |||
14 -- Public Subkey Packet | 14 -- Public Subkey Packet | |||
60 to 63 -- Private or Experimental Values | 60 to 63 -- Private or Experimental Values | |||
5. Packet Types | 5. Packet Types | |||
5.1. Public-Key Encrypted Session Key Packets (Tag 1) | 5.1. Public-Key Encrypted Session Key Packets (Tag 1) | |||
A Public-Key Encrypted Session Key packet holds the session key used | A Public-Key Encrypted Session Key packet holds the session key used | |||
to encrypt a message. Zero or more Encrypted Session Key packets | to encrypt a message. Zero or more Encrypted Session Key packets | |||
(either Public-Key or Symmetric-Key) may precede a Symmetrically | (either Public-Key or Symmetric-Key) may precede a Symmetrically | |||
Encrypted Data Packet, which holds an encrypted message. The | Encrypted Data Packet, which holds an encrypted message. The message | |||
message is encrypted with the session key, and the session key is | is encrypted with the session key, and the session key is itself | |||
itself encrypted and stored in the Encrypted Session Key packet(s). | encrypted and stored in the Encrypted Session Key packet(s). The | |||
The Symmetrically Encrypted Data Packet is preceded by one | Symmetrically Encrypted Data Packet is preceded by one Public-Key | |||
Public-Key Encrypted Session Key packet for each OpenPGP key to | Encrypted Session Key packet for each OpenPGP key to which the | |||
which the message is encrypted. The recipient of the message finds | message is encrypted. The recipient of the message finds a session | |||
a session key that is encrypted to their public key, decrypts the | key that is encrypted to their public key, decrypts the session key, | |||
session key, and then uses the session key to decrypt the message. | and then uses the session key to decrypt the message. | |||
The body of this packet consists of: | The body of this packet consists of: | |||
- A one-octet number giving the version number of the packet type. | - A one-octet number giving the version number of the packet type. | |||
The currently defined value for packet version is 3. An | The currently defined value for packet version is 3. An | |||
implementation should accept, but not generate a version of 2, | implementation should accept, but not generate a version of 2, | |||
which is equivalent to V3 in all other respects. | which is equivalent to V3 in all other respects. | |||
- An eight-octet number that gives the key ID of the public key | - An eight-octet number that gives the key ID of the public key | |||
that the session key is encrypted to. | that the session key is encrypted to. | |||
- A one-octet number giving the public key algorithm used. | - A one-octet number giving the public key algorithm used. | |||
- A string of octets that is the encrypted session key. This | - A string of octets that is the encrypted session key. This string | |||
string takes up the remainder of the packet, and its contents | takes up the remainder of the packet, and its contents are | |||
are dependent on the public key algorithm used. | dependent on the public key algorithm used. | |||
Algorithm Specific Fields for RSA encryption | Algorithm Specific Fields for RSA encryption | |||
- multiprecision integer (MPI) of RSA encrypted value m**e mod n. | - multiprecision integer (MPI) of RSA encrypted value m**e mod n. | |||
Algorithm Specific Fields for Elgamal encryption: | Algorithm Specific Fields for Elgamal encryption: | |||
- MPI of Elgamal (Diffie-Hellman) value g**k mod p. | - MPI of Elgamal (Diffie-Hellman) value g**k mod p. | |||
- MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. | - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p. | |||
The value "m" in the above formulas is derived from the session key | The value "m" in the above formulas is derived from the session key | |||
as follows. First the session key is prefixed with a one-octet | as follows. First the session key is prefixed with a one-octet | |||
algorithm identifier that specifies the symmetric encryption | algorithm identifier that specifies the symmetric encryption | |||
algorithm used to encrypt the following Symmetrically Encrypted Data | algorithm used to encrypt the following Symmetrically Encrypted Data | |||
Packet. Then a two-octet checksum is appended which is equal to the | Packet. Then a two-octet checksum is appended which is equal to the | |||
sum of the preceding octets, including the algorithm identifier and | sum of the preceding session key octets, not including the algorithm | |||
session key, modulo 65536. This value is then padded as described | identifier, modulo 65536. This value is then padded as described in | |||
in PKCS-1 block type 02 [RFC2313] to form the "m" value used in the | PKCS-1 block type 02 [RFC2313] to form the "m" value used in the | |||
formulas above. | formulas above. | |||
Note that when an implementation forms several PKESKs with one | Note that when an implementation forms several PKESKs with one | |||
session key, forming a message that can be decrypted by several | session key, forming a message that can be decrypted by several keys, | |||
keys, the implementation MUST make new PKCS-1 padding for each key. | the implementation MUST make new PKCS-1 padding for each key. | |||
An implementation MAY accept or use a Key ID of zero as a "wild | An implementation MAY accept or use a Key ID of zero as a "wild card" | |||
card" or "speculative" Key ID. In this case, the receiving | or "speculative" Key ID. In this case, the receiving implementation | |||
implementation would try all available private keys, checking for a | would try all available private keys, checking for a valid decrypted | |||
valid decrypted session key. This format helps reduce traffic | session key. This format helps reduce traffic analysis of messages. | |||
analysis of messages. | ||||
5.2. Signature Packet (Tag 2) | 5.2. Signature Packet (Tag 2) | |||
A signature packet describes a binding between some public key and | A signature packet describes a binding between some public key and | |||
some data. The most common signatures are a signature of a file or a | some data. The most common signatures are a signature of a file or a | |||
block of text, and a signature that is a certification of a user ID. | block of text, and a signature that is a certification of a user ID. | |||
Two versions of signature packets are defined. Version 3 provides | Two versions of signature packets are defined. Version 3 provides | |||
basic signature information, while version 4 provides an expandable | basic signature information, while version 4 provides an expandable | |||
format with subpackets that can specify more information about the | format with subpackets that can specify more information about the | |||
skipping to change at page 17, line 6 | skipping to change at page 17, line 50 | |||
message that is encrypted to a V3 key, it is reasonable to create a | message that is encrypted to a V3 key, it is reasonable to create a | |||
V3 signature. | V3 signature. | |||
5.2.1. Signature Types | 5.2.1. Signature Types | |||
There are a number of possible meanings for a signature, which are | There are a number of possible meanings for a signature, which are | |||
specified in a signature type octet in any given signature. These | specified in a signature type octet in any given signature. These | |||
meanings are: | meanings are: | |||
0x00: Signature of a binary document. | 0x00: Signature of a binary document. | |||
Typically, this means the signer owns it, created it, or | Typically, this means the signer owns it, created it, or | |||
certifies that it has not been modified. | certifies that it has not been modified. | |||
0x01: Signature of a canonical text document. | 0x01: Signature of a canonical text document. | |||
Typically, this means the signer owns it, created it, or | Typically, this means the signer owns it, created it, or | |||
certifies that it has not been modified. The signature is | certifies that it has not been modified. The signature is | |||
calculated over the text data with its line endings converted to | calculated over the text data with its line endings converted | |||
<CR><LF> and trailing blanks removed. | to <CR><LF> and trailing blanks removed. | |||
0x02: Standalone signature. | 0x02: Standalone signature. | |||
This signature is a signature of only its own subpacket | This signature is a signature of only its own subpacket | |||
contents. It is calculated identically to a signature over a | contents. It is calculated identically to a signature over a | |||
zero-length binary document. Note that it doesn't make sense to | zero-length binary document. Note that it doesn't make sense to | |||
have a V3 standalone signature. | have a V3 standalone signature. | |||
0x10: Generic certification of a User ID and Public Key packet. | 0x10: Generic certification of a User ID and Public Key packet. | |||
The issuer of this certification does not make any particular | The issuer of this certification does not make any particular | |||
assertion as to how well the certifier has checked that the | assertion as to how well the certifier has checked that the | |||
owner of the key is in fact the person described by the user ID. | owner of the key is in fact the person described by the user | |||
Note that all PGP "key signatures" are this type of | ID. Note that all PGP "key signatures" are this type of | |||
certification. | certification. | |||
0x11: Persona certification of a User ID and Public Key packet. | 0x11: Persona certification of a User ID and Public Key packet. | |||
The issuer of this certification has not done any verification | The issuer of this certification has not done any verification | |||
of the claim that the owner of this key is the user ID | of the claim that the owner of this key is the user ID | |||
specified. | specified. | |||
0x12: Casual certification of a User ID and Public Key packet. | 0x12: Casual certification of a User ID and Public Key packet. | |||
The issuer of this certification has done some casual | The issuer of this certification has done some casual | |||
verification of the claim of identity. | verification of the claim of identity. | |||
0x13: Positive certification of a User ID and Public Key packet. | 0x13: Positive certification of a User ID and Public Key packet. | |||
The issuer of this certification has done substantial | The issuer of this certification has done substantial | |||
verification of the claim of identity. | verification of the claim of identity. | |||
Please note that the vagueness of these certification claims is | Please note that the vagueness of these certification claims is | |||
not a flaw, but a feature of the system. Because PGP places | not a flaw, but a feature of the system. Because PGP places | |||
final authority for validity upon the receiver of a | final authority for validity upon the receiver of a | |||
certification, it may be that one authority's casual | certification, it may be that one authority's casual | |||
certification might be more rigorous than some other authority's | certification might be more rigorous than some other | |||
positive certification. These classifications allow a | authority's positive certification. These classifications allow | |||
certification authority to issue fine-grained claims. | a certification authority to issue fine-grained claims. | |||
0x18: Subkey Binding Signature | 0x18: Subkey Binding Signature | |||
This signature is a statement by the top-level signing key | This signature is a statement by the top-level signing key | |||
indicates that it owns the subkey. This signature is calculated | indicates that it owns the subkey. This signature is calculated | |||
directly on the subkey itself, not on any User ID or other | directly on the subkey itself, not on any User ID or other | |||
packets. | packets. | |||
0x1F: Signature directly on a key | 0x1F: Signature directly on a key | |||
This signature is calculated directly on a key. It binds the | This signature is calculated directly on a key. It binds the | |||
information in the signature subpackets to the key, and is | information in the signature subpackets to the key, and is | |||
appropriate to be used for subpackets that provide information | appropriate to be used for subpackets that provide information | |||
about the key, such as the revocation key subpacket. It is also | about the key, such as the revocation key subpacket. It is also | |||
appropriate for statements that non-self certifiers want to make | appropriate for statements that non-self certifiers want to | |||
about the key itself, rather than the binding between a key and | make about the key itself, rather than the binding between a | |||
a name. | key and a name. | |||
0x20: Key revocation signature | 0x20: Key revocation signature | |||
The signature is calculated directly on the key being revoked. | The signature is calculated directly on the key being revoked. | |||
A revoked key is not to be used. Only revocation signatures by | A revoked key is not to be used. Only revocation signatures by | |||
the key being revoked, or by an authorized revocation key, | the key being revoked, or by an authorized revocation key, | |||
should be considered valid revocation signatures. | should be considered valid revocation signatures. | |||
0x28: Subkey revocation signature | 0x28: Subkey revocation signature | |||
The signature is calculated directly on the subkey being | The signature is calculated directly on the subkey being | |||
revoked. A revoked subkey is not to be used. Only revocation | revoked. A revoked subkey is not to be used. Only revocation | |||
signatures by the top-level signature key that is bound to this | signatures by the top-level signature key that is bound to this | |||
subkey, or by an authorized revocation key, should be considered | subkey, or by an authorized revocation key, should be | |||
valid revocation signatures. | considered valid revocation signatures. | |||
0x30: Certification revocation signature | 0x30: Certification revocation signature | |||
This signature revokes an earlier user ID certification | This signature revokes an earlier user ID certification | |||
signature (signature class 0x10 through 0x13). It should be | signature (signature class 0x10 through 0x13). It should be | |||
issued by the same key that issued the revoked signature or an | issued by the same key that issued the revoked signature or an | |||
authorized revocation key The signature should have a later | authorized revocation key The signature should have a later | |||
creation date than the signature it revokes. | creation date than the signature it revokes. | |||
0x40: Timestamp signature. | 0x40: Timestamp signature. | |||
This signature is only meaningful for the timestamp contained in | This signature is only meaningful for the timestamp contained | |||
it. | in it. | |||
5.2.2. Version 3 Signature Packet Format | 5.2.2. Version 3 Signature Packet Format | |||
The body of a version 3 Signature Packet contains: | The body of a version 3 Signature Packet contains: | |||
- One-octet version number (3). | - One-octet version number (3). | |||
- One-octet length of following hashed material. MUST be 5. | - One-octet length of following hashed material. MUST be 5. | |||
- One-octet signature type. | - One-octet signature type. | |||
skipping to change at page 19, line 31 | skipping to change at page 20, line 33 | |||
Algorithm Specific Fields for DSA signatures: | Algorithm Specific Fields for DSA signatures: | |||
- MPI of DSA value r. | - MPI of DSA value r. | |||
- MPI of DSA value s. | - MPI of DSA value s. | |||
The signature calculation is based on a hash of the signed data, as | The signature calculation is based on a hash of the signed data, as | |||
described above. The details of the calculation are different for | described above. The details of the calculation are different for | |||
DSA signature than for RSA signatures. | DSA signature than for RSA signatures. | |||
With RSA signatures, the hash value is encoded as described in | With RSA signatures, the hash value is encoded as described in PKCS-1 | |||
PKCS-1 section 10.1.2, "Data encoding", producing an ASN.1 value of | section 10.1.2, "Data encoding", producing an ASN.1 value of type | |||
type DigestInfo, and then padded using PKCS-1 block type 01 | DigestInfo, and then padded using PKCS-1 block type 01 [RFC2313]. | |||
[RFC2313]. This requires inserting the hash value as an octet | This requires inserting the hash value as an octet string into an | |||
string into an ASN.1 structure. The object identifier for the type | ASN.1 structure. The object identifier for the type of hash being | |||
of hash being used is included in the structure. The hexadecimal | used is included in the structure. The hexadecimal representations | |||
representations for the currently defined hash algorithms are: | for the currently defined hash algorithms are: | |||
- MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 | - MD2: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x02 | |||
- MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 | - MD5: 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05 | |||
- RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 | - RIPEMD-160: 0x2B, 0x24, 0x03, 0x02, 0x01 | |||
- SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A | - SHA-1: 0x2B, 0x0E, 0x03, 0x02, 0x1A | |||
The ASN.1 OIDs are: | The ASN.1 OIDs are: | |||
skipping to change at page 20, line 40 | skipping to change at page 21, line 49 | |||
- 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. Note that this is the length in octets of all of the | data. Note that this is the length in octets of all of the hashed | |||
hashed subpackets; a pointer incremented by this number will | subpackets; a pointer incremented by this number will skip over | |||
skip over the hashed subpackets. | 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. Note that this is the length in octets of all of the | data. Note that this is the length in octets of all of the | |||
unhashed subpackets; a pointer incremented by this number will | unhashed subpackets; a pointer incremented by this number will | |||
skip over the unhashed subpackets. | 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 | |||
the version number through the hashed subpacket data (inclusive) is | version number through the hashed subpacket data (inclusive) is | |||
hashed. The resulting hash value is what is signed. The left 16 | hashed. The resulting hash value is what is signed. The left 16 bits | |||
bits of the hash are included in the signature packet to provide a | of the hash are included in the signature packet to provide a quick | |||
quick test to reject some invalid signatures. | test to reject some invalid signatures. | |||
There are two fields consisting of signature subpackets. The first | There are two fields consisting of signature subpackets. The first | |||
field is hashed with the rest of the signature data, while the | field is hashed with the rest of the signature data, while the second | |||
second is unhashed. The second set of subpackets is not | is unhashed. The second set of subpackets is not cryptographically | |||
cryptographically protected by the signature and should include only | protected by the signature and should include only advisory | |||
advisory information. | information. | |||
The algorithms for converting the hash function result to a | The algorithms for converting the hash function result to a signature | |||
signature are described in a section below. | are described in a section below. | |||
5.2.3.1. Signature Subpacket Specification | 5.2.3.1. Signature Subpacket Specification | |||
The subpacket fields consist of zero or more signature subpackets. | The subpacket fields consist of zero or more signature subpackets. | |||
Each set of subpackets is preceded by a two-octet scalar count of | Each set of subpackets is preceded by a two-octet scalar count of the | |||
the length of the set of subpackets. | length of the set of subpackets. | |||
Each subpacket consists of a subpacket header and a body. The | Each subpacket consists of a subpacket header and a body. The header | |||
header consists of: | consists of: | |||
- the subpacket length (1, 2, or 5 octets) | - the subpacket length (1, 2, or 5 octets) | |||
- the subpacket type (1 octet) | - the subpacket type (1 octet) | |||
and is followed by the subpacket specific data. | and is followed by the subpacket specific data. | |||
The length includes the type octet but not this length. Its format | The length includes the type octet but not this length. Its format is | |||
is similar to the "new" format packet header lengths, but cannot | similar to the "new" format packet header lengths, but cannot have | |||
have partial body lengths. That is: | partial body lengths. That is: | |||
if the 1st octet < 192, then | if the 1st octet < 192, then | |||
lengthOfLength = 1 | lengthOfLength = 1 | |||
subpacketLen = 1st_octet | subpacketLen = 1st_octet | |||
if the 1st octet >= 192 and < 255, then | if the 1st octet >= 192 and < 255, then | |||
lengthOfLength = 2 | lengthOfLength = 2 | |||
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 | |||
skipping to change at page 22, line 33 | skipping to change at page 23, line 47 | |||
27 = key flags | 27 = key flags | |||
28 = signer's user id | 28 = signer's user id | |||
29 = reason for revocation | 29 = reason for revocation | |||
100 to 110 = internal or user-defined | 100 to 110 = internal or user-defined | |||
An implementation SHOULD ignore any subpacket of a type that it does | An implementation SHOULD ignore any subpacket of a type that it does | |||
not recognize. | not recognize. | |||
Bit 7 of the subpacket type is the "critical" bit. If set, it | Bit 7 of the subpacket type is the "critical" bit. If set, it | |||
denotes that the subpacket is one that is critical for the evaluator | denotes that the subpacket is one that is critical for the evaluator | |||
of the signature to recognize. If a subpacket is encountered that | of the signature to recognize. If a subpacket is encountered that is | |||
is marked critical but is unknown to the evaluating software, the | marked critical but is unknown to the evaluating software, the | |||
evaluator SHOULD consider the signature to be in error. | evaluator SHOULD consider the signature to be in error. | |||
An evaluator may "recognize" a subpacket, but not implement it. The | An evaluator may "recognize" a subpacket, but not implement it. The | |||
purpose of the critical bit is to allow the signer to tell an | purpose of the critical bit is to allow the signer to tell an | |||
evaluator that it would prefer a new, unknown feature to generate an | evaluator that it would prefer a new, unknown feature to generate an | |||
error than be ignored. | error than be ignored. | |||
Implementations SHOULD implement "preferences". | Implementations SHOULD implement "preferences". | |||
5.2.3.2. Signature Subpacket Types | 5.2.3.2. Signature Subpacket Types | |||
A number of subpackets are currently defined. Some subpackets apply | A number of subpackets are currently defined. Some subpackets apply | |||
to the signature itself and some are attributes of the key. | to the signature itself and some are attributes of the key. | |||
Subpackets that are found on a self-signature are placed on a user | Subpackets that are found on a self-signature are placed on a user id | |||
id certification made by the key itself. Note that a key may have | certification made by the key itself. Note that a key may have more | |||
more than one user id, and thus may have more than one | than one user id, and thus may have more than one self-signature, and | |||
self-signature, and differing subpackets. | differing subpackets. | |||
A self-signature is a binding signature made by the key the | A self-signature is a binding signature made by the key the signature | |||
signature refers to. There are three types of self-signatures, the | refers to. There are three types of self-signatures, the | |||
certification signatures (types 0x10-0x13), the direct-key signature | certification signatures (types 0x10-0x13), the direct-key signature | |||
(type 0x1f), and the subkey binding signature (type 0x18). For | (type 0x1f), and the subkey binding signature (type 0x18). For | |||
certification self-signatures, each user ID may have a | certification self-signatures, each user ID may have a self- | |||
self-signature, and thus different subpackets in those | signature, and thus different subpackets in those self-signatures. | |||
self-signatures. For subkey binding signatures, each subkey in fact | For subkey binding signatures, each subkey in fact has a self- | |||
has a self-signature. Subpackets that appear in a certification | signature. Subpackets that appear in a certification self-signature | |||
self-signature apply to the username, and subpackets that appear in | apply to the username, and subpackets that appear in the subkey | |||
the subkey self-signature apply to the subkey. Lastly, subpackets on | self-signature apply to the subkey. Lastly, subpackets on the direct | |||
the direct key signature apply to the entire key. | key signature apply to the entire key. | |||
Implementing software should interpret a self-signature's preference | Implementing software should interpret a self-signature's preference | |||
subpackets as narrowly as possible. For example, suppose a key has | subpackets as narrowly as possible. For example, suppose a key has | |||
two usernames, Alice and Bob. Suppose that Alice prefers the | two usernames, Alice and Bob. Suppose that Alice prefers the | |||
symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If | symmetric algorithm CAST5, and Bob prefers IDEA or Triple-DES. If the | |||
the software locates this key via Alice's name, then the preferred | software locates this key via Alice's name, then the preferred | |||
algorithm is CAST5, if software locates the key via Bob's name, then | algorithm is CAST5, if software locates the key via Bob's name, then | |||
the preferred algorithm is IDEA. If the key is located by key id, | the preferred algorithm is IDEA. If the key is located by key id, | |||
then algorithm of the default user id of the key provides the | then algorithm of the default user id of the key provides the default | |||
default symmetric algorithm. | symmetric algorithm. | |||
A subpacket may be found either in the hashed or unhashed subpacket | A subpacket may be found either in the hashed or unhashed subpacket | |||
sections of a signature. If a subpacket is not hashed, then the | sections of a signature. If a subpacket is not hashed, then the | |||
information in it cannot be considered definitive because it is not | information in it cannot be considered definitive because it is not | |||
part of the signature proper. | part of the signature proper. | |||
5.2.3.3. Signature creation time | 5.2.3.3. Signature creation time | |||
(4 octet time field) | (4 octet time field) | |||
skipping to change at page 24, line 4 | skipping to change at page 25, line 31 | |||
(4 octet time field) | (4 octet time field) | |||
The validity period of the key. This is the number of seconds after | The validity period of the key. This is the number of seconds after | |||
the key creation time that the key expires. If this is not present | 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 only on | or has a value of zero, the key never expires. This is found only on | |||
a self-signature. | a self-signature. | |||
5.2.3.6. Preferred symmetric algorithms | 5.2.3.6. Preferred symmetric algorithms | |||
(sequence of one-octet values) | (sequence of one-octet values) | |||
Symmetric algorithm numbers that indicate which algorithms the key | Symmetric algorithm numbers that indicate which algorithms the key | |||
holder prefers to use. The subpacket body is an ordered list of | holder prefers to use. The subpacket body is an ordered list of | |||
octets with the most preferred listed first. It is assumed that only | octets with the most preferred listed first. It is assumed that only | |||
algorithms listed are supported by the recipient's software. | algorithms listed are supported by the recipient's software. | |||
Algorithm numbers in section 9. This is only found on a | Algorithm numbers in section 9. This is only found on a self- | |||
self-signature. | signature. | |||
5.2.3.7. Preferred hash algorithms | 5.2.3.7. Preferred hash algorithms | |||
(array of one-octet values) | (array of one-octet values) | |||
Message digest algorithm numbers that indicate which algorithms the | Message digest algorithm numbers that indicate which algorithms the | |||
key holder prefers to receive. Like the preferred symmetric | key holder prefers to receive. Like the preferred symmetric | |||
algorithms, the list is ordered. Algorithm numbers are in section 6. | algorithms, the list is ordered. Algorithm numbers are in section 6. | |||
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 might have | uncompressed data is preferred; the key holder's software might have | |||
no compression software in that implementation. This is only found | no compression software in that implementation. This is only found on | |||
on a self-signature. | 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 | |||
this is not present or has a value of zero, it never expires. | is not present or has a value of zero, it never expires. | |||
5.2.3.10. Exportable Certification | 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) | |||
This subpacket denotes whether a certification signature is | This subpacket denotes whether a certification signature is | |||
"exportable," to be used by other users than the signature's issuer. | "exportable", to be used by other users than the signature's issuer. | |||
The packet body contains a boolean flag indicating whether the | The packet body contains a boolean flag indicating whether the | |||
signature is exportable. If this packet is not present, the | signature is exportable. If this packet is not present, the | |||
certification is exportable; it is equivalent to a flag containing a | certification is exportable; it is equivalent to a flag containing a | |||
1. | 1. | |||
Non-exportable, or "local," certifications are signatures made by a | Non-exportable, or "local", certifications are signatures made by a | |||
user to mark a key as valid within that user's implementation only. | user to mark a key as valid within that user's implementation only. | |||
Thus, when an implementation prepares a user's copy of a key for | Thus, when an implementation prepares a user's copy of a key for | |||
transport to another user (this is the process of "exporting" the | transport to another user (this is the process of "exporting" the | |||
key), any local certification signatures are deleted from the key. | key), any local certification signatures are deleted from the key. | |||
The receiver of a transported key "imports" it, and likewise trims | The receiver of a transported key "imports" it, and likewise trims | |||
any local certifications. In normal operation, there won't be any, | any local certifications. In normal operation, there won't be any, | |||
assuming the import is performed on an exported key. However, there | assuming the import is performed on an exported key. However, there | |||
are instances where this can reasonably happen. For example, if an | are instances where this can reasonably happen. For example, if an | |||
implementation allows keys to be imported from a key database in | implementation allows keys to be imported from a key database in | |||
addition to an exported key, then this situation can arise. | addition to an exported key, then this situation can arise. | |||
Some implementations do not represent the interest of a single user | Some implementations do not represent the interest of a single user | |||
(for example, a key server). Such implementations always trim local | (for example, a key server). Such implementations always trim local | |||
certifications from any key they handle. | 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 | |||
flag indicating whether the signature is revocable. Signatures that | indicating whether the signature is revocable. Signatures that are | |||
are not revocable have any later revocation signatures ignored. | not revocable have any later revocation signatures ignored. They | |||
They represent a commitment by the signer that he cannot revoke his | 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, | |||
the signature is revocable. | the signature is revocable. | |||
5.2.3.12. Trust signature | 5.2.3.12. Trust signature | |||
(1 octet "level" (depth), 1 octet of trust amount) | (1 octet "level" (depth), 1 octet of trust amount) | |||
Signer asserts that the key is not only valid, but also trustworthy, | Signer asserts that the key is not only valid, but also trustworthy, | |||
at the specified level. Level 0 has the same meaning as an ordinary | at the specified level. Level 0 has the same meaning as an ordinary | |||
validity signature. Level 1 means that the signed key is asserted | validity signature. Level 1 means that the signed key is asserted to | |||
to be a valid trusted introducer, with the 2nd octet of the body | be a valid trusted introducer, with the 2nd octet of the body | |||
specifying the degree of trust. Level 2 means that the signed key is | specifying the degree of trust. Level 2 means that the signed key is | |||
asserted to be trusted to issue level 1 trust signatures, i.e. that | asserted to be trusted to issue level 1 trust signatures, i.e. that | |||
it is a "meta introducer". Generally, a level n trust signature | it is a "meta introducer". Generally, a level n trust signature | |||
asserts that a key is trusted to issue level n-1 trust signatures. | asserts that a key is trusted to issue level n-1 trust signatures. | |||
The trust amount is in a range from 0-255, interpreted such that | The trust amount is in a range from 0-255, interpreted such that | |||
values less than 120 indicate partial trust and values of 120 or | values less than 120 indicate partial trust and values of 120 or | |||
greater indicate complete trust. Implementations SHOULD emit values | greater indicate complete trust. Implementations SHOULD emit values | |||
of 60 for partial trust and 120 for complete trust. | of 60 for partial trust and 120 for complete trust. | |||
5.2.3.13. Regular expression | 5.2.3.13. Regular expression | |||
skipping to change at page 26, line 34 | skipping to change at page 28, line 25 | |||
5.2.3.15. Notation Data | 5.2.3.15. Notation Data | |||
(4 octets of flags, 2 octets of name length (M), | (4 octets of flags, 2 octets of name length (M), | |||
2 octets of value length (N), | 2 octets of value length (N), | |||
M octets of name data, | M octets of name data, | |||
N octets of value data) | N octets of value data) | |||
This subpacket describes a "notation" on the signature that the | This subpacket describes a "notation" on the signature that the | |||
issuer wishes to make. The notation has a name and a value, each of | issuer wishes to make. The notation has a name and a value, each of | |||
which are strings of octets. There may be more than one notation in | which are strings of octets. There may be more than one notation in a | |||
a signature. Notations can be used for any extension the issuer of | signature. Notations can be used for any extension the issuer of the | |||
the signature cares to make. The "flags" field holds four octets of | signature cares to make. The "flags" field holds four octets of | |||
flags. | flags. | |||
All undefined flags MUST be zero. Defined flags are: | All undefined flags MUST be zero. Defined flags are: | |||
First octet: 0x80 = human-readable. This note is text, a note | First octet: 0x80 = human-readable. This note is text, a note | |||
from one person to another, and has no | from one person to another, and has no | |||
meaning to software. | meaning to software. | |||
Other octets: none. | Other octets: none. | |||
5.2.3.16. Key server preferences | 5.2.3.16. Key server preferences | |||
(N octets of flags) | (N octets of flags) | |||
This is a list of flags that indicate preferences that the key | This is a list of flags that indicate preferences that the key holder | |||
holder has about how the key is handled on a key server. All | has about how the key is handled on a key server. All undefined flags | |||
undefined flags MUST be zero. | MUST be zero. | |||
First octet: 0x80 = No-modify | First octet: 0x80 = No-modify | |||
the key holder requests that this key only be modified or | the key holder requests that this key only be modified or updated | |||
updated by the key holder or an administrator of the key server. | by the key holder or an administrator of the key server. | |||
This is found only on a self-signature. | This is found only on a self-signature. | |||
5.2.3.17. Preferred key server | 5.2.3.17. Preferred key server | |||
(String) | (String) | |||
This is a URL of a key server that the key holder prefers be used | This is a URL of a key server that the key holder prefers be used for | |||
for updates. Note that keys with multiple user ids can have a | updates. Note that keys with multiple user ids can have a preferred | |||
preferred key server for each user id. Note also that since this is | key server for each user id. Note also that since this is a URL, the | |||
a URL, the key server can actually be a copy of the key retrieved by | key server can actually be a copy of the key retrieved by ftp, http, | |||
ftp, http, finger, etc. | finger, etc. | |||
5.2.3.18. Primary user id | 5.2.3.18. Primary user id | |||
(1 octet, boolean) | (1 octet, boolean) | |||
This is a flag in a user id's self signature that states whether | This is a flag in a user id's self signature that states whether this | |||
this user id is the main user id for this key. It is reasonable for | user id is the main user id for this key. It is reasonable for an | |||
an implementation to resolve ambiguities in preferences, etc. by | implementation to resolve ambiguities in preferences, etc. by | |||
referring to the primary user id. If this flag is absent, its value | referring to the primary user id. If this flag is absent, its value | |||
is zero. If more than one user id in a key is marked as primary, the | is zero. If more than one user id in a key is marked as primary, the | |||
implementation may resolve the ambiguity in any way it sees fit. | implementation may resolve the ambiguity in any way it sees fit. | |||
5.2.3.19. Policy URL | 5.2.3.19. Policy URL | |||
(String) | (String) | |||
This subpacket contains a URL of a document that describes the | This subpacket contains a URL of a document that describes the policy | |||
policy that the signature was issued under. | that the signature was issued under. | |||
5.2.3.20. Key Flags | 5.2.3.20. Key Flags | |||
(Octet string) | (Octet string) | |||
This subpacket contains a list of binary flags that hold information | This subpacket contains a list of binary flags that hold information | |||
about a key. It is a string of octets, and an implementation MUST | about a key. It is a string of octets, and an implementation MUST NOT | |||
NOT assume a fixed size. This is so it can grow over time. If a list | assume a fixed size. This is so it can grow over time. If a list is | |||
is shorter than an implementation expects, the unstated flags are | shorter than an implementation expects, the unstated flags are | |||
considered to be zero. The defined flags are: | considered to be zero. The defined flags are: | |||
First octet: | First octet: | |||
0x01 - This key may be used to certify other keys. | 0x01 - This key may be used to certify other keys. | |||
0x02 - This key may be used to sign data. | 0x02 - This key may be used to sign data. | |||
0x04 - This key may be used to encrypt communications. | 0x04 - This key may be used to encrypt communications. | |||
0x08 - This key may be used to encrypt storage. | 0x08 - This key may be used to encrypt storage. | |||
0x10 - The private component of this key may have been split by | 0x10 - The private component of this key may have been split by a | |||
a secret-sharing mechanism. | secret-sharing mechanism. | |||
0x80 - The private component of this key may be in the | 0x80 - The private component of this key may be in the possession | |||
possession of more than one person. | of more than one person. | |||
Usage notes: | Usage notes: | |||
The flags in this packet may appear in self-signatures or in | The flags in this packet may appear in self-signatures or in | |||
certification signatures. They mean different things depending on | certification signatures. They mean different things depending on who | |||
who is making the statement -- for example, a certification | is making the statement -- for example, a certification signature | |||
signature that has the "sign data" flag is stating that the | that has the "sign data" flag is stating that the certification is | |||
certification is for that use. On the other hand, the | for that use. On the other hand, the "communications encryption" flag | |||
"communications encryption" flag in a self-signature is stating a | in a self-signature is stating a preference that a given key be used | |||
preference that a given key be used for communications. Note | for communications. Note however, that it is a thorny issue to | |||
however, that it is a thorny issue to determine what is | determine what is "communications" and what is "storage." This | |||
"communications" and what is "storage." This decision is left wholly | decision is left wholly up to the implementation; the authors of this | |||
up to the implementation; the authors of this document do not claim | document do not claim any special wisdom on the issue, and realize | |||
any special wisdom on the issue, and realize that accepted opinion | that accepted opinion may change. | |||
may change. | ||||
The "split key" (0x10) and "group key" (0x80) flags are placed on a | The "split key" (0x10) and "group key" (0x80) flags are placed on a | |||
self-signature only; they are meaningless on a certification | self-signature only; they are meaningless on a certification | |||
signature. They SHOULD be placed only on a direct-key signature | signature. They SHOULD be placed only on a direct-key signature (type | |||
(type 0x1f) or a subkey signature (type 0x18), one that refers to | 0x1f) or a subkey signature (type 0x18), one that refers to the key | |||
the key the flag applies to. | the flag applies to. | |||
5.2.3.21. Signer's User ID | 5.2.3.21. Signer's User ID | |||
This subpacket allows a keyholder to state which user id is | This subpacket allows a keyholder to state which user id is | |||
responsible for the signing. Many keyholders use a single key for | responsible for the signing. Many keyholders use a single key for | |||
different purposes, such as business communications as well as | different purposes, such as business communications as well as | |||
personal communications. This subpacket allows such a keyholder to | personal communications. This subpacket allows such a keyholder to | |||
state which of their roles is making a signature. | state which of their roles is making a signature. | |||
5.2.3.22. Reason for Revocation | 5.2.3.22. Reason for Revocation | |||
skipping to change at page 29, line 27 | skipping to change at page 31, line 33 | |||
For standalone signatures, this is a null string. | For standalone signatures, this is a null string. | |||
When a signature is made over a key, the hash data starts with the | When a signature is made over a key, the hash data starts with the | |||
octet 0x99, followed by a two-octet length of the key, and then body | octet 0x99, followed by a two-octet length of the key, and then body | |||
of the key packet. (Note that this is an old-style packet header for | of the key packet. (Note that this is an old-style packet header for | |||
a key packet with two-octet length.) A subkey signature (type 0x18) | a key packet with two-octet length.) A subkey signature (type 0x18) | |||
then hashes the subkey, using the same format as the main key. Key | then hashes the subkey, using the same format as the main key. Key | |||
revocation signatures (types 0x20 and 0x28) hash only the key being | revocation signatures (types 0x20 and 0x28) hash only the key being | |||
revoked. | revoked. | |||
A certification signature (type 0x10 through 0x13) hashes the user | A certification signature (type 0x10 through 0x13) hashes the user id | |||
id being bound to the key into the hash context after the above | being bound to the key into the hash context after the above data. A | |||
data. A V3 certification hashes the contents of the name packet, | V3 certification hashes the contents of the name packet, without any | |||
without any header. A V4 certification hashes the constant 0xb4 | header. A V4 certification hashes the constant 0xb4 (which is an | |||
(which is an old-style packet header with the length-of-length set | old-style packet header with the length-of-length set to zero), a | |||
to zero), a four-octet number giving the length of the username, and | four-octet number giving the length of the username, and then the | |||
then the username data. | username data. | |||
Once the data body is hashed, then a trailer is hashed. A V3 | Once the data body is hashed, then a trailer is hashed. A V3 | |||
signature hashes five octets of the packet body, starting from the | signature hashes five octets of the packet body, starting from the | |||
signature type field. This data is the signature type, followed by | signature type field. This data is the signature type, followed by | |||
the four-octet signature time. A V4 signature hashes the packet body | the four-octet signature time. A V4 signature hashes the packet body | |||
starting from its first field, the version number, through the end | starting from its first field, the version number, through the end of | |||
of the hashed subpacket data. Thus, the fields hashed are the | the hashed subpacket data. Thus, the fields hashed are the signature | |||
signature version, the signature type, the public key algorithm, the | version, the signature type, the public key algorithm, the hash | |||
hash algorithm, the hashed subpacket length, and the hashed | algorithm, the hashed subpacket length, and the hashed subpacket | |||
subpacket body. | body. | |||
V4 signatures also hash in a final trailer of six octets: the | V4 signatures also hash in a final trailer of six octets: the version | |||
version of the signature packet, i.e. 0x04; 0xFF; a four-octet, | of the signature packet, i.e. 0x04; 0xFF; a four-octet, big-endian | |||
big-endian number that is the length of the hashed data from the | number that is the length of the hashed data from the signature | |||
signature packet (note that this number does not include these final | packet (note that this number does not include these final six | |||
six octets. | octets. | |||
After all this has been hashed, the resulting hash field is used in | After all this has been hashed, the resulting hash field is used in | |||
the signature algorithm, and placed at the end of the signature | the signature algorithm, and placed at the end of the signature | |||
packet. | packet. | |||
5.2.4.1. Subpacket Hints | 5.2.4.1. Subpacket Hints | |||
An implementation SHOULD put the two mandatory subpackets, creation | An implementation SHOULD put the two mandatory subpackets, creation | |||
time and issuer, as the first subpackets in the subpacket list, | time and issuer, as the first subpackets in the subpacket list, | |||
simply to make it easier for the implementer to find them. | simply to make it easier for the implementer to find them. | |||
It is certainly possible for a signature to contain conflicting | It is certainly possible for a signature to contain conflicting | |||
information in subpackets. For example, a signature may contain | information in subpackets. For example, a signature may contain | |||
multiple copies of a preference or multiple expiration times. In | multiple copies of a preference or multiple expiration times. In most | |||
most cases, an implementation SHOULD use the last subpacket in the | cases, an implementation SHOULD use the last subpacket in the | |||
signature, but MAY use any conflict resolution scheme that makes | signature, but MAY use any conflict resolution scheme that makes more | |||
more sense. Please note that we are intentionally leaving conflict | sense. Please note that we are intentionally leaving conflict | |||
resolution to the implementer; most conflicts are simply syntax | resolution to the implementer; most conflicts are simply syntax | |||
errors, and the wishy-washy language here allows a receiver to be | errors, and the wishy-washy language here allows a receiver to be | |||
generous in what they accept, while putting pressure on a creator to | generous in what they accept, while putting pressure on a creator to | |||
be stingy in what they generate. | be stingy in what they generate. | |||
Some apparent conflicts may actually make sense -- for example, | Some apparent conflicts may actually make sense -- for example, | |||
suppose a keyholder has an V3 key and a V4 key that share the same | suppose a keyholder has an V3 key and a V4 key that share the same | |||
RSA key material. Either of these keys can verify a signature | RSA key material. Either of these keys can verify a signature created | |||
created by the other, and it may be reasonable for a signature to | by the other, and it may be reasonable for a signature to contain an | |||
contain an issuer subpacket for each key, as a way of explicitly | issuer subpacket for each key, as a way of explicitly tying those | |||
tying those keys to the signature. | keys to the signature. | |||
5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) | 5.3. Symmetric-Key Encrypted Session-Key Packets (Tag 3) | |||
The Symmetric-Key Encrypted Session Key packet holds the | The Symmetric-Key Encrypted Session Key packet holds the symmetric- | |||
symmetric-key encryption of a session key used to encrypt a message. | key encryption of a session key used to encrypt a message. Zero or | |||
Zero or more Encrypted Session Key packets and/or Symmetric-Key | more Encrypted Session Key packets and/or Symmetric-Key Encrypted | |||
Encrypted Session Key packets may precede a Symmetrically Encrypted | Session Key packets may precede a Symmetrically Encrypted Data Packet | |||
Data Packet that holds an encrypted message. The message is | that holds an encrypted message. The message is encrypted with a | |||
encrypted with a session key, and the session key is itself | session key, and the session key is itself encrypted and stored in | |||
encrypted and stored in the Encrypted Session Key packet or the | the Encrypted Session Key packet or the Symmetric-Key Encrypted | |||
Symmetric-Key Encrypted Session Key packet. | Session Key packet. | |||
If the Symmetrically Encrypted Data Packet is preceded by one or | If the Symmetrically Encrypted Data Packet is preceded by one or more | |||
more Symmetric-Key Encrypted Session Key packets, each specifies a | Symmetric-Key Encrypted Session Key packets, each specifies a | |||
passphrase that may be used to decrypt the message. This allows a | passphrase that may be used to decrypt the message. This allows a | |||
message to be encrypted to a number of public keys, and also to one | message to be encrypted to a number of public keys, and also to one | |||
or more pass phrases. This packet type is new, and is not generated | or more pass phrases. This packet type is new, and is not generated | |||
by PGP 2.x or PGP 5.0. | by PGP 2.x or PGP 5.0. | |||
The body of this packet consists of: | The body of this packet consists of: | |||
- A one-octet version number. The only currently defined version | - A one-octet version number. The only currently defined version | |||
is 4. | is 4. | |||
- A one-octet number describing the symmetric algorithm used. | - A one-octet number describing the symmetric algorithm used. | |||
- A string-to-key (S2K) specifier, length as defined above. | - A string-to-key (S2K) specifier, length as defined above. | |||
- Optionally, the encrypted session key itself, which is decrypted | - Optionally, the encrypted session key itself, which is decrypted | |||
with the string-to-key object. | with the string-to-key object. | |||
If the encrypted session key is not present (which can be detected | If the encrypted session key is not present (which can be detected on | |||
on the basis of packet length and S2K specifier size), then the S2K | the basis of packet length and S2K specifier size), then the S2K | |||
algorithm applied to the passphrase produces the session key for | algorithm applied to the passphrase produces the session key for | |||
decrypting the file, using the symmetric cipher algorithm from the | decrypting the file, using the symmetric cipher algorithm from the | |||
Symmetric-Key Encrypted Session Key packet. | Symmetric-Key Encrypted Session Key packet. | |||
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 | |||
encrypt the following Symmetrically Encrypted Data Packet, followed | the following Symmetrically Encrypted Data Packet, followed by the | |||
by the session key octets themselves. | 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 Salted S2K or an | specifier MUST use a salt value, either a Salted S2K or an Iterated- | |||
Iterated-Salted S2K. The salt value will insure that the decryption | Salted S2K. The salt value will insure that the decryption key is | |||
key is not repeated even if the passphrase is reused. | 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 | |||
can compute the entire signed message in one pass. | 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.1. | section 5.2.1. | |||
- A one-octet number describing the hash algorithm used. | - A one-octet number describing the hash algorithm used. | |||
skipping to change at page 32, line 8 | skipping to change at page 34, line 24 | |||
- 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 | |||
signature to be applied to the same message data. | signature to be applied to the same message data. | |||
Note that if a message contains more than one one-pass signature, | Note that if a message contains more than one one-pass signature, | |||
then the signature packets bracket the message; that is, the first | then the signature packets bracket the message; that is, the first | |||
signature packet after the message corresponds to the last one-pass | signature packet after the message corresponds to the last one-pass | |||
packet and the final signature packet corresponds to the first | packet and the final signature packet corresponds to the first one- | |||
one-pass packet. | pass packet. | |||
5.5. Key Material Packet | 5.5. Key Material Packet | |||
A key material packet contains all the information about a public or | A key material packet contains all the information about a public or | |||
private key. There are four variants of this packet type, and two | private key. There are four variants of this packet type, and two | |||
major versions. Consequently, this section is complex. | major versions. Consequently, this section is complex. | |||
5.5.1. Key Packet Variants | 5.5.1. Key Packet Variants | |||
5.5.1.1. Public Key Packet (Tag 6) | 5.5.1.1. Public Key Packet (Tag 6) | |||
skipping to change at page 32, line 32 | skipping to change at page 34, line 48 | |||
key (sometimes called an OpenPGP certificate). | key (sometimes called an OpenPGP certificate). | |||
5.5.1.2. Public Subkey Packet (Tag 14) | 5.5.1.2. Public Subkey Packet (Tag 14) | |||
A Public Subkey packet (tag 14) has exactly the same format as a | A Public Subkey packet (tag 14) has exactly the same format as a | |||
Public Key packet, but denotes a subkey. One or more subkeys may be | Public Key packet, but denotes a subkey. One or more subkeys may be | |||
associated with a top-level key. By convention, the top-level key | associated with a top-level key. By convention, the top-level key | |||
provides signature services, and the subkeys provide encryption | provides signature services, and the subkeys provide encryption | |||
services. | services. | |||
Note: in PGP 2.6.x, tag 14 was intended to indicate a comment | Note: in PGP 2.6.x, tag 14 was intended to indicate a comment packet. | |||
packet. This tag was selected for reuse because no previous version | This tag was selected for reuse because no previous version of PGP | |||
of PGP ever emitted comment packets but they did properly ignore | ever emitted comment packets but they did properly ignore them. | |||
them. Public Subkey packets are ignored by PGP 2.6.x and do not | Public Subkey packets are ignored by PGP 2.6.x and do not cause it to | |||
cause it to fail, providing a limited degree of backward | fail, providing a limited degree of backward compatibility. | |||
compatibility. | ||||
5.5.1.3. Secret Key Packet (Tag 5) | 5.5.1.3. Secret Key Packet (Tag 5) | |||
A Secret Key packet contains all the information that is found in a | A Secret Key packet contains all the information that is found in a | |||
Public Key packet, including the public key material, but also | Public Key packet, including the public key material, but also | |||
includes the secret key material after all the public key fields. | includes the secret key material after all the public key fields. | |||
5.5.1.4. Secret Subkey Packet (Tag 7) | 5.5.1.4. Secret Subkey Packet (Tag 7) | |||
A Secret Subkey packet (tag 7) is the subkey analog of the Secret | A Secret Subkey packet (tag 7) is the subkey analog of the Secret Key | |||
Key packet, and has exactly the same format. | packet, and has exactly the same format. | |||
5.5.2. Public Key Packet Formats | 5.5.2. Public Key Packet Formats | |||
There are two versions of key-material packets. Version 3 packets | There are two versions of key-material packets. Version 3 packets | |||
were first generated by PGP 2.6. Version 2 packets are identical in | were first generated by PGP 2.6. Version 2 packets are identical in | |||
format to Version 3 packets, but are generated by PGP 2.5 or before. | format to Version 3 packets, but are generated by PGP 2.5 or before. | |||
V2 packets are deprecated and they MUST NOT be generated. | V2 packets are deprecated and they MUST NOT be generated. PGP 5.0 | |||
introduced version 4 packets, with new fields and semantics. PGP | ||||
PGP 5.0 introduced version 4 packets, with new fields and semantics. | 2.6.x will not accept key-material packets with versions greater than | |||
PGP 2.6.x will not accept key-material packets with versions | 3. | |||
greater than 3. | ||||
OpenPGP implementations SHOULD create keys with version 4 format. An | OpenPGP implementations SHOULD create keys with version 4 format. An | |||
implementation MAY generate a V3 key to ensure interoperability with | implementation MAY generate a V3 key to ensure interoperability with | |||
old software; note, however, that V4 keys correct some security | old software; note, however, that V4 keys correct some security | |||
deficiencies in V3 keys. These deficiencies are described below. An | deficiencies in V3 keys. These deficiencies are described below. An | |||
implementation MUST NOT create a V3 key with a public key algorithm | implementation MUST NOT create a V3 key with a public key algorithm | |||
other than RSA. | other than RSA. | |||
A version 3 public key or public subkey packet contains: | A version 3 public key or public subkey packet contains: | |||
skipping to change at page 33, line 35 | skipping to change at page 36, line 6 | |||
- A one-octet number denoting the public key algorithm of this key | - A one-octet number denoting the public key algorithm of this key | |||
- A series of multi-precision integers comprising the key | - A series of multi-precision integers comprising the key | |||
material: | material: | |||
- a multiprecision integer (MPI) of RSA public modulus n; | - a multiprecision integer (MPI) of RSA public modulus n; | |||
- an MPI of RSA public encryption exponent e. | - an MPI of RSA public encryption exponent e. | |||
V3 keys SHOULD only be used for backward compatibility because of | V3 keys SHOULD only be used for backward compatibility because of | |||
three weaknesses in them. First, it is relatively easy to construct | three weaknesses in them. First, it is relatively easy to construct a | |||
a V3 key that has the same key ID as any other key because the key | V3 key that has the same key ID as any other key because the key ID | |||
ID is simply the low 64 bits of the public modulus. Secondly, | is simply the low 64 bits of the public modulus. Secondly, because | |||
because the fingerprint of a V3 key hashes the key material, but not | the fingerprint of a V3 key hashes the key material, but not its | |||
its length, which increases the opportunity for fingerprint | length, which increases the opportunity for fingerprint collisions. | |||
collisions. Third, there are minor weaknesses in the MD5 hash | Third, there are minor weaknesses in the MD5 hash algorithm that make | |||
algorithm that make developers prefer other algorithms. See below | developers prefer other algorithms. See below for a fuller discussion | |||
for a fuller discussion of key IDs and fingerprints. | of key IDs and fingerprints. | |||
The version 4 format is similar to the version 3 format except for | The version 4 format is similar to the version 3 format except for | |||
the absence of a validity period. This has been moved to the | the absence of a validity period. This has been moved to the | |||
signature packet. In addition, fingerprints of version 4 keys are | signature packet. In addition, fingerprints of version 4 keys are | |||
calculated differently from version 3 keys, as described in section | calculated differently from version 3 keys, as described in section | |||
"Enhanced Key Formats." | "Enhanced Key Formats." | |||
A version 4 packet contains: | A version 4 packet contains: | |||
- A one-octet version number (4). | - A one-octet version number (4). | |||
skipping to change at page 34, line 31 | skipping to change at page 37, line 4 | |||
- MPI of DSA group generator g; | - MPI of DSA group generator g; | |||
- MPI of DSA public key value y (= g**x where x is secret). | - MPI of DSA public key value y (= g**x where x is secret). | |||
Algorithm Specific Fields for Elgamal public keys: | Algorithm Specific Fields for Elgamal public keys: | |||
- MPI of Elgamal prime p; | - MPI of Elgamal prime p; | |||
- MPI of Elgamal group generator g; | - MPI of Elgamal group generator g; | |||
- MPI of Elgamal public key value y (= g**x where x is | - MPI of Elgamal public key value y (= g**x where x is | |||
secret). | secret). | |||
5.5.3. Secret Key Packet Formats | 5.5.3. Secret Key Packet Formats | |||
The Secret Key and Secret Subkey packets contain all the data of the | The Secret Key and Secret Subkey packets contain all the data of the | |||
Public Key and Public Subkey packets, with additional | Public Key and Public Subkey packets, with additional algorithm- | |||
algorithm-specific secret key data appended, in encrypted form. | specific secret key data appended, in encrypted form. | |||
The packet contains: | The packet contains: | |||
- A Public Key or Public Subkey packet, as described above | - A Public Key or Public Subkey packet, as described above | |||
- One octet indicating string-to-key usage conventions. 0 | - One octet indicating string-to-key usage conventions. 0 | |||
indicates that the secret key data is not encrypted. 255 | indicates that the secret key data is not encrypted. 255 | |||
indicates that a string-to-key specifier is being given. Any | indicates that a string-to-key specifier is being given. Any | |||
other value is a symmetric-key encryption algorithm specifier. | other value is a symmetric-key encryption algorithm specifier. | |||
skipping to change at page 35, line 32 | skipping to change at page 38, line 9 | |||
- MPI of u, the multiplicative inverse of p, mod q. | - MPI of u, the multiplicative inverse of p, mod q. | |||
Algorithm Specific Fields for DSA secret keys: | Algorithm Specific Fields for DSA secret keys: | |||
- MPI of DSA secret exponent x. | - MPI of DSA secret exponent x. | |||
Algorithm Specific Fields for Elgamal secret keys: | Algorithm Specific Fields for Elgamal secret keys: | |||
- MPI of Elgamal secret exponent x. | - MPI of Elgamal secret exponent x. | |||
Secret MPI values can be encrypted using a passphrase. If a | Secret MPI values can be encrypted using a passphrase. If a string- | |||
string-to-key specifier is given, that describes the algorithm for | to-key specifier is given, that describes the algorithm for | |||
converting the passphrase to a key, else a simple MD5 hash of the | converting the passphrase to a key, else a simple MD5 hash of the | |||
passphrase is used. Implementations SHOULD use a string-to-key | passphrase is used. Implementations SHOULD use a string-to-key | |||
specifier; the simple hash is for backward compatibility. The cipher | specifier; the simple hash is for backward compatibility. The cipher | |||
for encrypting the MPIs is specified in the secret key packet. | for encrypting the MPIs is specified in the secret key packet. | |||
Encryption/decryption of the secret data is done in CFB mode using | Encryption/decryption of the secret data is done in CFB mode using | |||
the key created from the passphrase and the Initial Vector from the | the key created from the passphrase and the Initial Vector from the | |||
packet. A different mode is used with V3 keys (which are only RSA) | packet. A different mode is used with V3 keys (which are only RSA) | |||
than with other key formats. With V3 keys, the MPI bit count prefix | than with other key formats. With V3 keys, the MPI bit count prefix | |||
(i.e., the first two octets) is not encrypted. Only the MPI | (i.e., the first two octets) is not encrypted. Only the MPI non- | |||
non-prefix data is encrypted. Furthermore, the CFB state is | prefix data is encrypted. Furthermore, the CFB state is | |||
resynchronized at the beginning of each new MPI value, so that the | resynchronized at the beginning of each new MPI value, so that the | |||
CFB block boundary is aligned with the start of the MPI data. | CFB block boundary is aligned with the start of the MPI data. | |||
With V4 keys, a simpler method is used. All secret MPI values are | With V4 keys, a simpler method is used. All secret MPI values are | |||
encrypted in CFB mode, including the MPI bitcount prefix. | encrypted in CFB mode, including the MPI bitcount prefix. | |||
The 16-bit checksum that follows the algorithm-specific portion is | The 16-bit checksum that follows the algorithm-specific portion is | |||
the algebraic sum, mod 65536, of the plaintext of all the | the algebraic sum, mod 65536, of the plaintext of all the algorithm- | |||
algorithm-specific octets (including MPI prefix and data). With V3 | specific octets (including MPI prefix and data). With V3 keys, the | |||
keys, the checksum is stored in the clear. With V4 keys, the | checksum is stored in the clear. With V4 keys, the checksum is | |||
checksum is encrypted like the algorithm-specific data. This value | encrypted like the algorithm-specific data. This value is used to | |||
is used to check that the passphrase was correct. | check that the passphrase was correct. | |||
5.6. Compressed Data Packet (Tag 8) | 5.6. Compressed Data Packet (Tag 8) | |||
The Compressed Data packet contains compressed data. Typically, this | The Compressed Data packet contains compressed data. Typically, this | |||
packet is found as the contents of an encrypted packet, or following | packet is found as the contents of an encrypted packet, or following | |||
a Signature or One-Pass Signature packet, and contains literal data | a Signature or One-Pass Signature packet, and contains literal data | |||
packets. | packets. | |||
The body of this packet consists of: | The body of this packet consists of: | |||
- 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 RFC 1951 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, PGP V2.6 cannot | implementation 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 RFC 1950 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). | |||
The body of this packet consists of: | The body of this packet consists of: | |||
- Encrypted data, the output of the selected symmetric-key cipher | - Encrypted data, the output of the selected symmetric-key cipher | |||
operating in PGP's variant of Cipher Feedback (CFB) mode. | operating in PGP's variant of Cipher Feedback (CFB) mode. | |||
The symmetric cipher used may be specified in an Public-Key or | The symmetric cipher used may be specified in an Public-Key or | |||
Symmetric-Key Encrypted Session Key packet that precedes the | Symmetric-Key Encrypted Session Key packet that precedes the | |||
Symmetrically Encrypted Data Packet. In that case, the cipher | Symmetrically Encrypted Data Packet. In that case, the cipher | |||
algorithm octet is prefixed to the session key before it is | algorithm octet is prefixed to the session key before it is | |||
encrypted. If no packets of these types precede the encrypted data, | encrypted. If no packets of these types precede the encrypted data, | |||
the IDEA algorithm is used with the session key calculated as the | the IDEA algorithm is used with the session key calculated as the MD5 | |||
MD5 hash of the passphrase. | hash of the passphrase. | |||
The data is encrypted in CFB mode, with a CFB shift size equal to | The data is encrypted in CFB mode, with a CFB shift size equal to the | |||
the cipher's block size. The Initial Vector (IV) is specified as | cipher's block size. The Initial Vector (IV) is specified as all | |||
all zeros. Instead of using an IV, OpenPGP prefixes a 10-octet | zeros. Instead of using an IV, OpenPGP prefixes a 10-octet string to | |||
string to the data before it is encrypted. The first eight octets | the data before it is encrypted. The first eight octets are random, | |||
are random, and the 9th and 10th octets are copies of the 7th and | and the 9th and 10th octets are copies of the 7th and 8th octets, | |||
8th octets, respectively. After encrypting the first 10 octets, the | respectively. After encrypting the first 10 octets, the CFB state is | |||
CFB state is resynchronized if the cipher block size is 8 octets or | resynchronized if the cipher block size is 8 octets or less. The | |||
less. The last 8 octets of ciphertext are passed through the cipher | last 8 octets of ciphertext are passed through the cipher and the | |||
and the block boundary is reset. | block boundary is reset. | |||
The repetition of 16 bits in the 80 bits of random data prefixed to | The repetition of 16 bits in the 80 bits of random data prefixed to | |||
the message allows the receiver to immediately check whether the | the message allows the receiver to immediately check whether the | |||
session key is incorrect. | session key is incorrect. | |||
5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) | 5.8. Marker Packet (Obsolete Literal Packet) (Tag 10) | |||
An experimental version of PGP used this packet as the Literal | An experimental version of PGP used this packet as the Literal | |||
packet, but no released version of PGP generated Literal packets | packet, but no released version of PGP generated Literal packets with | |||
with this tag. With PGP 5.x, this packet has been re-assigned and is | this tag. With PGP 5.x, this packet has been re-assigned and is | |||
reserved for use as the Marker packet. | reserved for use as the Marker packet. | |||
The body of this packet consists of: | The body of this packet consists of: | |||
- The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). | - The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8). | |||
Such a packet MUST be ignored when received. It may be placed at | Such a packet MUST be ignored when received. It may be placed at the | |||
the beginning of a message that uses features not available in PGP | beginning of a message that uses features not available in PGP 2.6.x | |||
2.6.x in order to cause that version to report that newer software | in order to cause that version to report that newer software is | |||
is necessary to process the message. | necessary to process the message. | |||
5.9. Literal Data Packet (Tag 11) | 5.9. Literal Data Packet (Tag 11) | |||
A Literal Data packet contains the body of a message; data that is | A Literal Data packet contains the body of a message; data that is | |||
not to be further interpreted. | not to be further interpreted. | |||
The body of this packet consists of: | The body of this packet consists of: | |||
- A one-octet field that describes how the data is formatted. | - A one-octet field that describes how the data is formatted. | |||
skipping to change at page 37, line 47 | skipping to change at page 40, line 34 | |||
If it is a 't' (0x74), then it contains text data, and thus may need | If it is a 't' (0x74), then it contains text data, and thus may need | |||
line ends converted to local form, or other text-mode changes. RFC | line ends converted to local form, or other text-mode changes. RFC | |||
1991 also defined a value of 'l' as a 'local' mode for machine-local | 1991 also defined a value of 'l' as a 'local' mode for machine-local | |||
conversions. This use is now deprecated. | conversions. This use is now deprecated. | |||
- File name as a string (one-octet length, followed by file name), | - File name as a string (one-octet length, followed by file name), | |||
if the encrypted data should be saved as a file. | if the encrypted data should be saved as a file. | |||
If the special name "_CONSOLE" is used, the message is considered to | If the special name "_CONSOLE" is used, the message is considered to | |||
be "for your eyes only". This advises that the message data is | be "for your eyes only". This advises that the message data is | |||
unusually sensitive, and the receiving program should process it | unusually sensitive, and the receiving program should process it more | |||
more carefully, perhaps avoiding storing the received data to disk, | carefully, perhaps avoiding storing the received data to disk, for | |||
for example. | example. | |||
- A four-octet number that indicates the modification date of the | - A four-octet number that indicates the modification date of the | |||
file, or the creation time of the packet, or a zero that | file, or the creation time of the packet, or a zero that | |||
indicates the present time. | indicates the present time. | |||
- The remainder of the packet is literal data. | - The remainder of the packet is literal data. | |||
Text data is stored with <CR><LF> text endings (i.e. network-normal | Text data is stored with <CR><LF> text endings (i.e. network-normal | |||
line endings). These should be converted to native line endings by | line endings). These should be converted to native line endings by | |||
the receiving software. | the receiving software. | |||
skipping to change at page 38, line 26 | skipping to change at page 41, line 14 | |||
along with other information that implementing software uses for | along with other information that implementing software uses for | |||
trust information. | trust information. | |||
Trust packets SHOULD NOT be emitted to output streams that are | Trust packets SHOULD NOT be emitted to output streams that are | |||
transferred to other users, and they SHOULD be ignored on any input | transferred to other users, and they SHOULD be ignored on any input | |||
other than local keyring files. | other than local keyring files. | |||
5.11. User ID Packet (Tag 13) | 5.11. User ID Packet (Tag 13) | |||
A User ID packet consists of data that is intended to represent the | A User ID packet consists of data that is intended to represent the | |||
name and email address of the key holder. By convention, it | name and email address of the key holder. By convention, it includes | |||
includes an RFC822 mail name, but there are no restrictions on its | an RFC 822 mail name, but there are no restrictions on its content. | |||
content. The packet length in the header specifies the length of | The packet length in the header specifies the length of the user id. | |||
the user id. If it is text, it is encoded in UTF-8. | If it is text, it is encoded in UTF-8. | |||
6. Radix-64 Conversions | 6. Radix-64 Conversions | |||
As stated in the introduction, OpenPGP's underlying native | As stated in the introduction, OpenPGP's underlying native | |||
representation for objects is a stream of arbitrary octets, and some | representation for objects is a stream of arbitrary octets, and some | |||
systems desire these objects to be immune to damage caused by | systems desire these objects to be immune to damage caused by | |||
character set translation, data conversions, etc. | character set translation, data conversions, etc. | |||
In principle, any printable encoding scheme that met the | In principle, any printable encoding scheme that met the requirements | |||
requirements of the unsafe channel would suffice, since it would not | of the unsafe channel would suffice, since it would not change the | |||
change the underlying binary bit streams of the native OpenPGP data | underlying binary bit streams of the native OpenPGP data structures. | |||
structures. The OpenPGP standard specifies one such printable | The OpenPGP standard specifies one such printable encoding scheme to | |||
encoding scheme to ensure interoperability. | ensure interoperability. | |||
OpenPGP's Radix-64 encoding is composed of two parts: a base64 | OpenPGP's Radix-64 encoding is composed of two parts: a base64 | |||
encoding of the binary data, and a checksum. The base64 encoding is | encoding of the binary data, and a checksum. The base64 encoding is | |||
identical to the MIME base64 content-transfer-encoding [RFC 2231, | identical to the MIME base64 content-transfer-encoding [RFC2231, | |||
Section 6.8]. An OpenPGP implementation MAY use ASCII Armor to | Section 6.8]. An OpenPGP implementation MAY use ASCII Armor to | |||
protect the raw binary data. | protect the raw binary data. | |||
The checksum is a 24-bit CRC converted to four characters of | The checksum is a 24-bit CRC converted to four characters of radix-64 | |||
radix-64 encoding by the same MIME base64 transformation, preceded | encoding by the same MIME base64 transformation, preceded by an | |||
by an equals sign (=). The CRC is computed by using the generator | equals sign (=). The CRC is computed by using the generator 0x864CFB | |||
0x864CFB and an initialization of 0xB704CE. The accumulation is | and an initialization of 0xB704CE. The accumulation is done on the | |||
done on the data before it is converted to radix-64, rather than on | data before it is converted to radix-64, rather than on the converted | |||
the converted data. A sample implementation of this algorithm is in | data. A sample implementation of this algorithm is in the next | |||
the next section. | section. | |||
The checksum with its leading equal sign MAY appear on the first | The checksum with its leading equal sign MAY appear on the first line | |||
line after the Base64 encoded data. | after the Base64 encoded data. | |||
Rationale for CRC-24: The size of 24 bits fits evenly into printable | Rationale for CRC-24: The size of 24 bits fits evenly into printable | |||
base64. The nonzero initialization can detect more errors than a | base64. The nonzero initialization can detect more errors than a | |||
zero initialization. | zero initialization. | |||
6.1. An Implementation of the CRC-24 in "C" | 6.1. An Implementation of the CRC-24 in "C" | |||
#define CRC24_INIT 0xb704ce | #define CRC24_INIT 0xb704ceL | |||
#define CRC24_POLY 0x1864cfb | #define CRC24_POLY 0x1864cfbL | |||
typedef long crc24; | typedef long crc24; | |||
crc24 crc_octets(unsigned char *octets, size_t len) | crc24 crc_octets(unsigned char *octets, size_t len) | |||
{ | { | |||
crc24 crc = CRC24_INIT; | crc24 crc = CRC24_INIT; | |||
int i; | int i; | |||
while (len--) { | while (len--) { | |||
crc ^= (*octets++) << 16; | crc ^= (*octets++) << 16; | |||
for (i = 0; i < 8; i++) { | for (i = 0; i < 8; i++) { | |||
crc <<= 1; | crc <<= 1; | |||
if (crc & 0x1000000) | if (crc & 0x1000000) | |||
crc ^= CRC24_POLY; | crc ^= CRC24_POLY; | |||
} | } | |||
} | } | |||
return crc & 0xffffff; | return crc & 0xffffffL; | |||
} | } | |||
6.2. Forming ASCII Armor | 6.2. Forming ASCII Armor | |||
When OpenPGP encodes data into ASCII Armor, it puts specific headers | When OpenPGP encodes data into ASCII Armor, it puts specific headers | |||
around the data, so OpenPGP can reconstruct the data later. OpenPGP | around the data, so OpenPGP can reconstruct the data later. OpenPGP | |||
informs the user what kind of data is encoded in the ASCII armor | informs the user what kind of data is encoded in the ASCII armor | |||
through the use of the headers. | through the use of the headers. | |||
Concatenating the following data creates ASCII Armor: | Concatenating the following data creates ASCII Armor: | |||
skipping to change at page 40, line 7 | skipping to change at page 42, line 50 | |||
- A blank (zero-length, or containing only whitespace) line | - A blank (zero-length, or containing only whitespace) line | |||
- The ASCII-Armored data | - The ASCII-Armored data | |||
- An Armor Checksum | - An Armor Checksum | |||
- The Armor Tail, which depends on the Armor Header Line. | - The Armor Tail, which depends on the Armor Header Line. | |||
An Armor Header Line consists of the appropriate header line text | An Armor Header Line consists of the appropriate header line text | |||
surrounded by five (5) dashes ('-', 0x2D) on either side of the | surrounded by five (5) dashes ('-', 0x2D) on either side of the | |||
header line text. The header line text is chosen based upon the | header line text. The header line text is chosen based upon the type | |||
type of data that is being encoded in Armor, and how it is being | of data that is being encoded in Armor, and how it is being encoded. | |||
encoded. Header line texts include the following strings: | Header line texts include the following strings: | |||
BEGIN PGP MESSAGE | BEGIN PGP MESSAGE | |||
Used for signed, encrypted, or compressed files. | Used for signed, encrypted, or compressed files. | |||
BEGIN PGP PUBLIC KEY BLOCK | BEGIN PGP PUBLIC KEY BLOCK | |||
Used for armoring public keys | Used for armoring public keys | |||
BEGIN PGP PRIVATE KEY BLOCK | BEGIN PGP PRIVATE KEY BLOCK | |||
Used for armoring private keys | Used for armoring private keys | |||
BEGIN PGP MESSAGE, PART X/Y | BEGIN PGP MESSAGE, PART X/Y | |||
Used for multi-part messages, where the armor is split amongst Y | Used for multi-part messages, where the armor is split amongst Y | |||
parts, and this is the Xth part out of Y. | parts, and this is the Xth part out of Y. | |||
BEGIN PGP MESSAGE, PART X | BEGIN PGP MESSAGE, PART X | |||
Used for multi-part messages, where this is the Xth part of an | Used for multi-part messages, where this is the Xth part of an | |||
unspecified number of parts. Requires the MESSAGE-ID Armor | unspecified number of parts. Requires the MESSAGE-ID Armor Header | |||
Header to be used. | to be used. | |||
BEGIN PGP SIGNATURE | BEGIN PGP SIGNATURE | |||
Used for detached signatures, OpenPGP/MIME signatures, and | Used for detached signatures, OpenPGP/MIME signatures, and | |||
signatures following clearsigned messages. Note that PGP 2.x | natures following clearsigned messages. Note that PGP 2.x s BEGIN | |||
uses BEGIN PGP MESSAGE for detached signatures. | PGP MESSAGE for detached signatures. | |||
The Armor Headers are pairs of strings that can give the user or the | The Armor Headers are pairs of strings that can give the user or the | |||
receiving OpenPGP implementation some information about how to | receiving OpenPGP implementation some information about how to decode | |||
decode or use the message. The Armor Headers are a part of the | or use the message. The Armor Headers are a part of the armor, not a | |||
armor, not a part of the message, and hence are not protected by any | part of the message, and hence are not protected by any signatures | |||
signatures applied to the message. | applied to the message. | |||
The format of an Armor Header is that of a key-value pair. A colon | The format of an Armor Header is that of a key-value pair. A colon | |||
(':' 0x38) and a single space (0x20) separate the key and value. | (':' 0x38) and a single space (0x20) separate the key and value. | |||
OpenPGP should consider improperly formatted Armor Headers to be | OpenPGP should consider improperly formatted Armor Headers to be | |||
corruption of the ASCII Armor. Unknown keys should be reported to | corruption of the ASCII Armor. Unknown keys should be reported to | |||
the user, but OpenPGP should continue to process the message. | the user, but OpenPGP should continue to process the message. | |||
Currently defined Armor Header Keys are: | Currently defined Armor Header Keys are: | |||
- "Version", that states the OpenPGP Version used to encode the | - "Version", that states the OpenPGP Version used to encode the | |||
message. | message. | |||
- "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 | |||
be unique enough that the recipient of the mail can associate | unique enough that the recipient of the mail can associate all | |||
all the parts of a message with each other. A good checksum or | 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 | - "Hash", a comma-separated list of hash algorithms used in this | |||
message. This is used only in clear-signed messages. | message. This is used only in clear-signed messages. | |||
- "Charset", a description of the character set that the plaintext | - "Charset", a description of the character set that the plaintext | |||
is in. Please note that OpenPGP defines text to be in UTF-8 by | is in. Please note that OpenPGP defines text to be in UTF-8 by | |||
default. An implementation will get best results by translating | default. An implementation will get best results by translating | |||
into and out of UTF-8. However, there are many instances where | into and out of UTF-8. However, there are many instances where | |||
this is easier said than done. Also, there are communities of | this is easier said than done. Also, there are communities of | |||
skipping to change at page 41, line 36 | skipping to change at page 44, line 37 | |||
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 | |||
"END." | "END." | |||
6.3. Encoding Binary in Radix-64 | 6.3. Encoding Binary in Radix-64 | |||
The encoding process represents 24-bit groups of input bits as | The encoding process represents 24-bit groups of input bits as output | |||
output strings of 4 encoded characters. Proceeding from left to | strings of 4 encoded characters. Proceeding from left to right, a | |||
right, a 24-bit input group is formed by concatenating three 8-bit | 24-bit input group is formed by concatenating three 8-bit input | |||
input groups. These 24 bits are then treated as four concatenated | groups. These 24 bits are then treated as four concatenated 6-bit | |||
6-bit groups, each of which is translated into a single digit in the | groups, each of which is translated into a single digit in the | |||
Radix-64 alphabet. When encoding a bit stream with the Radix-64 | Radix-64 alphabet. When encoding a bit stream with the Radix-64 | |||
encoding, the bit stream must be presumed to be ordered with the | encoding, the bit stream must be presumed to be ordered with the | |||
most-significant-bit first. That is, the first bit in the stream | most-significant-bit first. That is, the first bit in the stream will | |||
will be the high-order bit in the first 8-bit octet, and the eighth | be the high-order bit in the first 8-bit octet, and the eighth bit | |||
bit will be the low-order bit in the first 8-bit octet, and so on. | will be the low-order bit in the first 8-bit octet, and so on. | |||
+--first octet--+-second octet--+--third octet--+ | +--first octet--+-second octet--+--third octet--+ | |||
|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| | |7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0|7 6 5 4 3 2 1 0| | |||
+-----------+---+-------+-------+---+-----------+ | +-----------+---+-------+-------+---+-----------+ | |||
|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| | |5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0|5 4 3 2 1 0| | |||
+--1.index--+--2.index--+--3.index--+--4.index--+ | +--1.index--+--2.index--+--3.index--+--4.index--+ | |||
Each 6-bit group is used as an index into an array of 64 printable | Each 6-bit group is used as an index into an array of 64 printable | |||
characters from the table below. The character referenced by the | characters from the table below. The character referenced by the | |||
index is placed in the output string. | index is placed in the output string. | |||
skipping to change at page 42, line 45 | skipping to change at page 46, line 7 | |||
has two zero-value bits added to it, and is processed as above. | has two zero-value bits added to it, and is processed as above. | |||
A pad character (=) is added to the output. | A pad character (=) is added to the output. | |||
3. The last data group has 8 bits (1 octet). The first 6-bit group | 3. The last data group has 8 bits (1 octet). The first 6-bit group | |||
is processed as above. The second (incomplete) data group has | is processed as above. The second (incomplete) data group has | |||
four zero-value bits added to it, and is processed as above. Two | four zero-value bits added to it, and is processed as above. Two | |||
pad characters (=) are added to the output. | pad characters (=) are added to the output. | |||
6.4. Decoding Radix-64 | 6.4. Decoding Radix-64 | |||
Any characters outside of the base64 alphabet are ignored in | Any characters outside of the base64 alphabet are ignored in Radix-64 | |||
Radix-64 data. Decoding software must ignore all line breaks or | data. Decoding software must ignore all line breaks or other | |||
other characters not found in the table above. | characters not found in the table above. | |||
In Radix-64 data, characters other than those in the table, line | In Radix-64 data, characters other than those in the table, line | |||
breaks, and other white space probably indicate a transmission | breaks, and other white space probably indicate a transmission error, | |||
error, about which a warning message or even a message rejection | about which a warning message or even a message rejection might be | |||
might be appropriate under some circumstances. | appropriate under some circumstances. | |||
Because it is used only for padding at the end of the data, the | Because it is used only for padding at the end of the data, the | |||
occurrence of any "=" characters may be taken as evidence that the | occurrence of any "=" characters may be taken as evidence that the | |||
end of the data has been reached (without truncation in transit). No | end of the data has been reached (without truncation in transit). No | |||
such assurance is possible, however, when the number of octets | such assurance is possible, however, when the number of octets | |||
transmitted was a multiple of three and no "=" characters are | transmitted was a multiple of three and no "=" characters are | |||
present. | present. | |||
6.5. Examples of Radix-64 | 6.5. Examples of Radix-64 | |||
skipping to change at page 43, line 51 | skipping to change at page 47, line 19 | |||
yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS | yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS | |||
vBSFjNSiVHsuAA== | vBSFjNSiVHsuAA== | |||
=njUN | =njUN | |||
-----END PGP MESSAGE----- | -----END PGP MESSAGE----- | |||
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 | |||
armoring the stream itself, so the signed text is still readable | the stream itself, so the signed text is still readable without | |||
without special software. In order to bind a signature to such a | special software. In order to bind a signature to such a cleartext, | |||
cleartext, this framework is used. (Note that RFC 2015 defines | this framework is used. (Note that RFC 2015 defines another way to | |||
another way to clear sign messages for environments that support | 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, | |||
- One 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 '-----BEGIN PGP | - The ASCII armored signature(s) including the '-----BEGIN PGP | |||
SIGNATURE-----' Armor Header and Armor Tail Lines. | SIGNATURE-----' Armor Header and 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, | |||
MD5 is used, an implementation MAY omit them for V2.x compatibility. | MD5 is used, an implementation MAY omit them for V2.x compatibility. | |||
If more than one message digest is used in the signature, the "Hash" | If more than one message digest is used in the signature, the "Hash" | |||
armor header contains a comma-delimited list of used message | armor header contains a comma-delimited list of used message digests. | |||
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 '-' | |||
(0x2D) and space ' ' (0x20). This prevents the parser from | (0x2D) and space ' ' (0x20). This prevents the parser from | |||
recognizing armor headers of the cleartext itself. The message | recognizing armor headers of the cleartext itself. The message digest | |||
digest is computed using the cleartext itself, not the dash escaped | is computed using the cleartext itself, not the dash escaped form. | |||
form. | ||||
As with binary signatures on text documents, a cleartext signature | As with binary signatures on text documents, a cleartext signature is | |||
is calculated on the text using canonical <CR><LF> line endings. | calculated on the text using canonical <CR><LF> line endings. The | |||
The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP | line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP | |||
SIGNATURE-----' line that terminates the signed text is not | SIGNATURE-----' line that terminates the signed text is not | |||
considered part of the signed text. | considered part of the signed text. | |||
Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of | Also, any trailing whitespace (spaces, and tabs, 0x09) at the end of | |||
any line is ignored when the cleartext signature is calculated. | any line is ignored when the cleartext signature is calculated. | |||
8. Regular Expressions | 8. Regular Expressions | |||
A regular expression is zero or more branches, separated by '|'. It | A regular expression is zero or more branches, separated by '|'. It | |||
matches anything that matches one of the branches. | matches anything that matches one of the branches. | |||
A branch is zero or more pieces, concatenated. It matches a match | A branch is zero or more pieces, concatenated. It matches a match for | |||
for the first, followed by a match for the second, etc. | the first, followed by a match for the second, etc. | |||
A piece is an atom possibly followed by '*', '+', or '?'. An atom | A piece is an atom possibly followed by '*', '+', or '?'. An atom | |||
followed by '*' matches a sequence of 0 or more matches of the atom. | followed by '*' matches a sequence of 0 or more matches of the atom. | |||
An atom followed by '+' matches a sequence of 1 or more matches of | An atom followed by '+' matches a sequence of 1 or more matches of | |||
the atom. An atom followed by '?' matches a match of the atom, or | the atom. An atom followed by '?' matches a match of the atom, or the | |||
the null string. | null string. | |||
An atom is a regular expression in parentheses (matching a match for | An atom is a regular expression in parentheses (matching a match for | |||
the regular expression), a range (see below), '.' (matching any | the regular expression), a range (see below), '.' (matching any | |||
single character), '^' (matching the null string at the beginning of | single character), '^' (matching the null string at the beginning of | |||
the input string), '$' (matching the null string at the end of the | the input string), '$' (matching the null string at the end of the | |||
input string), a '\' followed by a single character (matching that | input string), a '\' followed by a single character (matching that | |||
character), or a single character with no other significance | character), or a single character with no other significance | |||
(matching that character). | (matching that character). | |||
A range is a sequence of characters enclosed in '[]'. It normally | A range is a sequence of characters enclosed in '[]'. It normally | |||
matches any single character from the sequence. If the sequence | matches any single character from the sequence. If the sequence | |||
begins with '^', it matches any single character not from the rest | begins with '^', it matches any single character not from the rest of | |||
of the sequence. If two characters in the sequence are separated by | the sequence. If two characters in the sequence are separated by '-', | |||
'-', this is shorthand for the full list of ASCII characters between | this is shorthand for the full list of ASCII characters between them | |||
them (e.g. '[0-9]' matches any decimal digit). To include a literal | (e.g. '[0-9]' matches any decimal digit). To include a literal ']' in | |||
']' in the sequence, make it the first character (following a | the sequence, make it the first character (following a possible '^'). | |||
possible '^'). To include a literal '-', make it the first or last | To include a literal '-', make it the first or last character. | |||
character. | ||||
9. Constants | 9. Constants | |||
This section describes the constants used in OpenPGP. | This section describes the constants used in OpenPGP. | |||
Note that these tables are not exhaustive lists; an implementation | Note that these tables are not exhaustive lists; an implementation | |||
MAY implement an algorithm not on these lists. | MAY implement an algorithm not on these lists. | |||
See the section "Notes on Algorithms" below for more discussion of | See the section "Notes on Algorithms" below for more discussion of | |||
the algorithms. | the algorithms. | |||
skipping to change at page 46, line 14 | skipping to change at page 49, line 41 | |||
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 [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, as per RFC2144) | 3 - CAST5 (128 bit key, as per RFC 2144) | |||
4 - Blowfish (128 bit key, 16 rounds) | 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] | |||
5 - SAFER-SK128 (13 rounds) | 5 - SAFER-SK128 (13 rounds) [SAFER] | |||
6 - Reserved for DES/SK | 6 - Reserved for DES/SK | |||
7 - Reserved for AES with 128-bit key | ||||
8 - Reserved for AES with 192-bit key | ||||
9 - Reserved for AES with 256-bit key | ||||
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 (RFC 1951) | |||
2 - ZLIB (RFC1950) | 2 - ZLIB (RFC 1950) | |||
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. Implementations MAY implement ZLIB. | 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" | |||
skipping to change at page 47, line 8 | skipping to change at page 50, line 44 | |||
7 - Reserved for HAVAL (5 pass, 160-bit) | 7 - Reserved for HAVAL (5 pass, 160-bit) | |||
"HAVAL-5-160" | "HAVAL-5-160" | |||
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 and to transfer keys. Not all possible packet sequences | messages and to transfer keys. Not all possible packet sequences are | |||
are meaningful and correct. This describes the rules for how | meaningful and correct. This describes the rules for how packets | |||
packets should be placed into sequences. | should be placed into sequences. | |||
10.1. Transferable Public Keys | 10.1. Transferable Public Keys | |||
OpenPGP users may transfer public keys. The essential elements of a | OpenPGP users may transfer public keys. The essential elements of a | |||
transferable public key are: | transferable public key are: | |||
- One Public Key packet | - One Public Key packet | |||
- Zero or more revocation signatures | - Zero or more revocation signatures | |||
skipping to change at page 48, line 5 | skipping to change at page 51, line 43 | |||
After the User ID packets there may be one or more Subkey packets. | After the User ID packets there may be one or more Subkey packets. | |||
In general, subkeys are provided in cases where the top-level public | In general, subkeys are provided in cases where the top-level public | |||
key is a signature-only key. However, any V4 key may have subkeys, | key is a signature-only key. However, any V4 key may have subkeys, | |||
and the subkeys may be encryption-only keys, signature-only keys, or | and the subkeys may be encryption-only keys, signature-only keys, or | |||
general-purpose keys. | general-purpose keys. | |||
Each Subkey packet must be followed by one Signature packet, which | Each Subkey packet must be followed by one Signature packet, which | |||
should be a subkey binding signature issued by the top level key. | should be a subkey binding signature issued by the top level key. | |||
Subkey and Key packets may each be followed by a revocation | Subkey and Key packets may each be followed by a revocation Signature | |||
Signature packet to indicate that the key is revoked. Revocation | packet to indicate that the key is revoked. Revocation signatures | |||
signatures are only accepted if they are issued by the key itself, | are only accepted if they are issued by the key itself, or by a key | |||
or by a key that is authorized to issue revocations via a revocation | that is authorized to issue revocations via a revocation key | |||
key subpacket in a self-signature by the top level key. | subpacket in a self-signature by the top level key. | |||
Transferable public key packet sequences may be concatenated to | Transferable public key packet sequences may be concatenated to allow | |||
allow transferring multiple public keys in one operation. | transferring multiple public keys in one operation. | |||
10.2. OpenPGP Messages | 10.2. OpenPGP Messages | |||
An OpenPGP message is a packet or sequence of packets that | An OpenPGP message is a packet or sequence of packets that | |||
corresponds to the following grammatical rules (comma represents | corresponds to the following grammatical rules (comma represents | |||
sequential composition, and vertical bar separates alternatives): | sequential composition, and vertical bar separates alternatives): | |||
OpenPGP Message :- Encrypted Message | Signed Message | | OpenPGP Message :- Encrypted Message | Signed Message | | |||
Compressed Message | Literal Message. | Compressed Message | Literal Message. | |||
skipping to change at page 48, line 46 | skipping to change at page 52, line 37 | |||
OpenPGP Message, Corresponding Signature Packet. | OpenPGP Message, Corresponding Signature Packet. | |||
Signed Message :- Signature Packet, OpenPGP Message | | Signed Message :- Signature Packet, OpenPGP Message | | |||
One-Pass Signed Message. | One-Pass Signed Message. | |||
In addition, decrypting a Symmetrically Encrypted Data packet and | In addition, decrypting a Symmetrically Encrypted Data packet and | |||
decompressing a Compressed Data packet must yield a valid OpenPGP | decompressing a Compressed Data packet must yield a valid OpenPGP | |||
Message. | Message. | |||
10.3. Detached Signatures | ||||
Some OpenPGP applications use so-called "detached signatures." For | ||||
example, a program bundle may contain a file, and with it a second | ||||
file that is a detached signature of the first file. These detached | ||||
signatures are simply a signature packet stored separately from the | ||||
data that they are a signature of. | ||||
11. Enhanced Key Formats | 11. Enhanced Key Formats | |||
11.1. Key Structures | 11.1. Key Structures | |||
The format of an OpenPGP V3 key is as follows. Entries in square | The format of an OpenPGP V3 key is as follows. Entries in square | |||
brackets are optional and ellipses indicate repetition. | brackets are optional and ellipses indicate repetition. | |||
RSA Public Key | RSA Public Key | |||
[Revocation Self Signature] | [Revocation Self Signature] | |||
User ID [Signature ...] | User ID [Signature ...] | |||
skipping to change at page 49, line 22 | skipping to change at page 53, line 27 | |||
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 | |||
signature may be in either V3 or V4 format, but V4 is preferred, of | 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 | |||
RSA encryption key, or RSA primary key with an Elgamal subkey, etc. | RSA encryption key, or RSA primary key with an Elgamal subkey, etc. | |||
It is also possible to have a signature-only subkey. This permits a | It is also possible to have a signature-only subkey. This permits a | |||
primary key that collects certifications (key signatures) but is | primary key that collects certifications (key signatures) but is used | |||
used only used for certifying subkeys that are used for encryption | only used for certifying subkeys that are used for encryption and | |||
and signatures. | signatures. | |||
11.2. Key IDs and Fingerprints | 11.2. Key IDs and Fingerprints | |||
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 the | |||
the low order 64 bits of the fingerprint. Here are the fields of | low order 64 bits of the fingerprint. Here are the fields of the | |||
the hash material, with the example of a DSA key: | 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); | |||
skipping to change at page 50, line 29 | skipping to change at page 54, line 35 | |||
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; | |||
e.4) MPI of DSA public key value y (= g**x where x is secret). | e.4) MPI of DSA public key value y (= g**x where x is secret). | |||
Note that it is possible for there to be collisions of key IDs -- | Note that it is possible for there to be collisions of key IDs -- two | |||
two different keys with the same key ID. Note that there is a much | different keys with the same key ID. Note that there is a much | |||
smaller, but still non-zero probability that two different keys have | smaller, but still non-zero probability that two different keys have | |||
the same fingerprint. | the same fingerprint. | |||
Also note that if V3 and V4 format keys share the same RSA key | Also note that if V3 and V4 format keys share the same RSA key | |||
material, they will have different key ids as well as different | material, they will have different key ids as well as different | |||
fingerprints. | fingerprints. | |||
12. Notes on Algorithms | 12. Notes on Algorithms | |||
12.1. Symmetric Algorithm Preferences | 12.1. Symmetric Algorithm Preferences | |||
The symmetric algorithm preference is an ordered list of algorithms | The symmetric algorithm preference is an ordered list of algorithms | |||
that the keyholder accepts. Since it is found on a self-signature, | that the keyholder accepts. Since it is found on a self-signature, it | |||
it is possible that a keyholder may have different preferences. For | is possible that a keyholder may have different preferences. For | |||
example, Alice may have TripleDES only specified for | example, Alice may have TripleDES only specified for "alice@work.com" | |||
"alice@work.com" but CAST5, Blowfish, and TripleDES specified for | but CAST5, Blowfish, and TripleDES specified for "alice@home.org". | |||
"alice@home.org". Note that it is also possible for preferences to | ||||
be in a subkey's binding signature. | Note that it is also possible for preferences to be in a subkey's | |||
binding signature. | ||||
Since TripleDES is the MUST-implement algorithm, if it is not | Since TripleDES is the MUST-implement algorithm, if it is not | |||
explicitly in the list, it is tacitly at the end. However, it is | explicitly in the list, it is tacitly at the end. However, it is good | |||
good form to place it there explicitly. Note also that if an | form to place it there explicitly. Note also that if an | |||
implementation does not implement the preference, then it is | implementation does not implement the preference, then it is | |||
implicitly a TripleDES-only implementation. | implicitly a TripleDES-only implementation. | |||
An implementation MUST not use a symmetric algorithm that is not in | An implementation MUST not use a symmetric algorithm that is not in | |||
the recipient's preference list. When encrypting to more than one | the recipient's preference list. When encrypting to more than one | |||
recipient, the implementation finds a suitable algorithm by taking | recipient, the implementation finds a suitable algorithm by taking | |||
the intersection of the preferences of the recipients. Note that the | the intersection of the preferences of the recipients. Note that the | |||
MUST-implement algorithm, TripleDES, ensures that the intersection | MUST-implement algorithm, TripleDES, ensures that the intersection is | |||
is not null. The implementation may use any mechanism to pick an | not null. The implementation may use any mechanism to pick an | |||
algorithm in the intersection. | algorithm in the intersection. | |||
If an implementation can decrypt a message that a keyholder doesn't | If an implementation can decrypt a message that a keyholder doesn't | |||
have in their preferences, the implementation SHOULD decrypt the | have in their preferences, the implementation SHOULD decrypt the | |||
message anyway, but MUST warn the keyholder than protocol has been | message anyway, but MUST warn the keyholder than protocol has been | |||
violated. (For example, suppose that Alice, above, has software that | violated. (For example, suppose that Alice, above, has software that | |||
implements all algorithms in this specification. Nonetheless, she | implements all algorithms in this specification. Nonetheless, she | |||
prefers subsets for work or home. If she is sent a message encrypted | prefers subsets for work or home. If she is sent a message encrypted | |||
with IDEA, which is not in her preferences, the software warns her | with IDEA, which is not in her preferences, the software warns her | |||
that someone sent her an IDEA-encrypted message, but it would | that someone sent her an IDEA-encrypted message, but it would ideally | |||
ideally decrypt it anyway.) | decrypt it anyway.) | |||
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. Consequently, an implementation MAY, but SHOULD NOT use | message. Consequently, an implementation MAY, but SHOULD NOT use IDEA | |||
IDEA in an algorithm conflict with a V3 key. | 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 | |||
algorithm preference, in that they specify which algorithms the | preference, in that they specify which algorithms the keyholder | |||
keyholder accepts. There are two interesting cases that other | accepts. There are two interesting cases that other comments need to | |||
comments need to be made about, though, the compression preferences | be made about, though, the compression preferences and the hash | |||
and the hash preferences. | preferences. | |||
12.2.1. Compression Preferences | 12.2.1. Compression Preferences | |||
Compression has been an integral part of PGP since its first days. | Compression has been an integral part of PGP since its first days. | |||
OpenPGP and all previous versions of PGP have offered compression. | OpenPGP and all previous versions of PGP have offered compression. | |||
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. | |||
compression. Additionally, this gives a keyholder a way to state | Additionally, this gives a keyholder a way to state that it can | |||
that it can support alternate algorithms. | 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 not 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. | |||
Thus, if Alice is authenticating herself to Bob with a signature, it | Thus, if Alice is authenticating herself to Bob with a signature, it | |||
makes sense for her to use a hash algorithm that Bob's software | makes sense for her to use a hash algorithm that Bob's software uses. | |||
uses. This preference allows Bob to state in his key which | This preference allows Bob to state in his key which algorithms Alice | |||
algorithms Alice may use. | may use. | |||
12.3. Plaintext | 12.3. Plaintext | |||
Algorithm 0, "plaintext," may only be used to denote secret keys | Algorithm 0, "plaintext", may only be used to denote secret keys that | |||
that are stored in the clear. Implementations must not use plaintext | are stored in the clear. Implementations must not use plaintext in | |||
in Symmetrically Encrypted Data Packets; they must use Literal Data | Symmetrically Encrypted Data Packets; they must use Literal Data | |||
Packets to encode unencrypted or literal data. | Packets to encode unencrypted or literal data. | |||
12.4. RSA | 12.4. RSA | |||
There are algorithm types for RSA-signature-only, and | There are algorithm types for RSA-signature-only, and RSA-encrypt- | |||
RSA-encrypt-only keys. These types are deprecated. The "key flags" | only keys. These types are deprecated. The "key flags" subpacket in a | |||
subpacket in a signature is a much better way to express the same | signature is a much better way to express the same idea, and | |||
idea, and generalizes it to all algorithms. An implementation SHOULD | generalizes it to all algorithms. An implementation SHOULD NOT create | |||
NOT create such a key, but MAY interpret it. | such a key, but MAY interpret it. | |||
An implementation SHOULD NOT implement RSA keys of size less than | An implementation SHOULD NOT implement RSA keys of size less than 768 | |||
768 bits. | bits. | |||
It is permissible for an implementation to support RSA merely for | It is permissible for an implementation to support RSA merely for | |||
backward compatibility; for example, such an implementation would | backward compatibility; for example, such an implementation would | |||
support V3 keys with IDEA symmetric cryptography. Note that this is | support V3 keys with IDEA symmetric cryptography. Note that this is | |||
an exception to the other MUST-implement rules. An implementation | an exception to the other MUST-implement rules. An implementation | |||
that supports RSA in V4 keys MUST implement the MUST-implement | that supports RSA in V4 keys MUST implement the MUST-implement | |||
features. | features. | |||
12.5. Elgamal | 12.5. Elgamal | |||
If an Elgamal key is to be used for both signing and encryption, | If an Elgamal key is to be used for both signing and encryption, | |||
extra care must be taken in creating the key. | extra care must be taken in creating the key. | |||
An ElGamal key consists of a generator g, a prime modulus p, a | An ElGamal key consists of a generator g, a prime modulus p, a secret | |||
secret exponent x, and a public value y = g^x mod p. | exponent x, and a public value y = g^x mod p. | |||
The generator and prime must be chosen so that solving the discrete | The generator and prime must be chosen so that solving the discrete | |||
log problem is intractable. The group g should generate the | log problem is intractable. The group g should generate the | |||
multiplicative group mod p-1 or a large subgroup of it, and the | multiplicative group mod p-1 or a large subgroup of it, and the order | |||
order of g should have at least one large prime factor. A good | of g should have at least one large prime factor. A good choice is | |||
choice is to use a "strong" Sophie-Germain prime in choosing p, so | to use a "strong" Sophie-Germain prime in choosing p, so that both p | |||
that both p and (p-1)/2 are primes. | and (p-1)/2 are primes. In fact, this choice is so good that | |||
implementors SHOULD do it, as it avoids a small subgroup attack. | ||||
In addition, a result of Bleichenbacher [BLEICHENBACHER] shows that | In addition, a result of Bleichenbacher [BLEICHENBACHER] shows that | |||
if the generator g has only small prime factors, and if g divides | if the generator g has only small prime factors, and if g divides the | |||
the order of the group it generates, then signatures can be forged. | order of the group it generates, then signatures can be forged. In | |||
In particular, choosing g=2 is a bad choice if the group order may | particular, choosing g=2 is a bad choice if the group order may be | |||
be even. On the other hand, a generator of 2 is a fine choice for an | even. On the other hand, a generator of 2 is a fine choice for an | |||
encryption-only key, as this will make the encryption faster. | encryption-only key, as this will make the encryption faster. | |||
While verifying Elgamal signatures, note that it is important to | While verifying Elgamal signatures, note that it is important to test | |||
test that r and s are less than p. If this test is not done then | 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 for an Elgamal public key that can sign. | 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 | |||
than 768 bits. For long-term security, Elgamal keys should be 1024 | 768 bits. For long-term security, Elgamal keys should be 1024 bits or | |||
bits or longer. | 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 | |||
768 bits. Note that present DSA is limited to a maximum of 1024 bit | bits. Note that present DSA is limited to a maximum of 1024 bit keys, | |||
keys, which are recommended for long-term use. | which are recommended for long-term use. | |||
12.7. Reserved Algorithm Numbers | 12.7. Reserved Algorithm Numbers | |||
A number of algorithm IDs have been reserved for algorithms that | A number of algorithm IDs have been reserved for algorithms that | |||
would be useful to use in an OpenPGP implementation, yet there are | would be useful to use in an OpenPGP implementation, yet there are | |||
issues that prevent an implementor from actually implementing the | issues that prevent an implementor from actually implementing the | |||
algorithm. These are marked in the Public Algorithms section as | algorithm. These are marked in the Public Algorithms section as | |||
"(reserved for)". | "(reserved for)". | |||
The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), | The reserved public key algorithms, Elliptic Curve (18), ECDSA (19), | |||
and X9.42 (21) do not have the necessary parameters, parameter | and X9.42 (21) do not have the necessary parameters, parameter order, | |||
order, or semantics defined. | or semantics defined. | |||
The reserved symmetric key algorithm, DES/SK (6), does not have | The reserved symmetric key algorithm, DES/SK (6), does not have | |||
semantics defined. | semantics defined. | |||
The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do | The reserved hash algorithms, TIGER192 (6), and HAVAL-5-160 (7), do | |||
not have OIDs. The reserved algorithm number 4, reserved for a | not have OIDs. The reserved algorithm number 4, reserved for a | |||
double-width variant of SHA1, is not presently defined. | double-width variant of SHA1, is not presently defined. | |||
We have reserver three algorithm IDs for the US NIST's Advanced | ||||
Encryption Standard. This algorithm will work with (at least) 128, | ||||
192, and 256-bit keys. We expect that this algorithm will be selected | ||||
from the candidate algorithms in the year 2000. | ||||
12.8. OpenPGP CFB mode | 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 | |||
and prefixes the plaintext with ten octets of random data, such that | prefixes the plaintext with ten octets of random data, such that | |||
octets 9 and 10 match octets 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 octets. | 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, | |||
bits, the equivalent function will be done with that entire block. | the equivalent function will be done with that entire block. For | |||
For example, a 16-octet block algorithm would operate on 16 octets, | example, a 16-octet block algorithm would operate on 16 octets, and | |||
and then produce two octets of check, and then work on 16-octet | then produce two octets of check, and then work on 16-octet blocks. | |||
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 octets 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 octets of | the plaintext to produce C1-C8, the first 8 octets of ciphertext. | |||
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 | |||
octets of ciphertext. | octets of ciphertext. | |||
6. The left two octets of FRE get xored with the next two octets 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 octets 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 octets 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 octets of prefixed data. | that we have finished encrypting the 10 octets of prefixed data. | |||
This produces C11-C18, the next 8 octets 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 octets of plaintext, to produce the | 12. FRE is xored with the next 8 octets of plaintext, to produce the | |||
next 8 octets 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 | |||
been found to be vulnerable to attack. | 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 is | |||
is assumed to be controlled by the proper party or parties. | 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- | |||
(pseudo-collisions in the compress function) that make some people | collisions in the compress function) that make some people deprecate | |||
deprecate its use. They consider the SHA-1 algorithm better. | its use. They consider the SHA-1 algorithm better. | |||
Many security protocol designers think that it is a bad idea to use | Many security protocol designers think that it is a bad idea to use a | |||
a single key for both privacy (encryption) and integrity | single key for both privacy (encryption) and integrity (signatures). | |||
(signatures). In fact, this was one of the motivating forces behind | In fact, this was one of the motivating forces behind the V4 key | |||
the V4 key format with separate signature and encryption keys. If | format with separate signature and encryption keys. If you as an | |||
you as an implementor promote dual-use keys, you should at least be | implementor promote dual-use keys, you should at least be aware of | |||
aware of this controversy. | 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 | |||
algorithm is broken, it can leak the secret key. The Digital | is broken, it can leak the secret key. The Digital Signature Standard | |||
Signature Standard (DSS) specifies that DSA be used with SHA-1. | (DSS) specifies that DSA be used with SHA-1. RIPEMD-160 is | |||
RIPEMD-160 is considered by many cryptographers to be as strong. An | considered by many cryptographers to be as strong. An implementation | |||
implementation should take care which hash algorithms are used with | should take care which hash algorithms are used with DSA, as a weak | |||
DSA, as a weak hash can not only allow a signature to be forged, but | hash can not only allow a signature to be forged, but could leak the | |||
could leak the secret key. These same considerations about the | secret key. These same considerations about the quality of the hash | |||
quality of the hash algorithm apply to Elgamal signatures. | 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 | |||
requests it. | 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- | |||
Triple-DES. Other algorithms may have other controversies | DES. Other algorithms may have other controversies surrounding them. | |||
surrounding them. | ||||
Some technologies mentioned here may be subject to government | Some technologies mentioned here may be subject to government control | |||
control in some countries. | in some countries. | |||
14. Implementation Nits | 14. Implementation Nits | |||
This section is a collection of comments to help an implementer, | This section is a collection of comments to help an implementer, | |||
particularly with an eye to backward compatibility. Previous | particularly with an eye to backward compatibility. Previous | |||
implementations of PGP are not OpenPGP-compliant. Often the | implementations of PGP are not OpenPGP-compliant. Often the | |||
differences are small, but small differences are frequently more | differences are small, but small differences are frequently more | |||
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 | |||
new-format headers or in signature subpacket lengths. | 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 | |||
differs from the S2K symmetric algorithm. This is a bug in its | from the S2K symmetric algorithm. This is a bug in its validation | |||
validation function. | 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 | |||
"BEGIN PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY | PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK". | |||
BLOCK". All previous versions ignore the implied data type, and | All previous versions ignore the implied data type, and look | |||
look directly at the packet data type. | 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 algorithm used. The | a mismatch between the header and the actual algorithm 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 | |||
of enhanced variants of PGP 2.6.x that have been modified for | enhanced variants of PGP 2.6.x that have been modified for SHA-1 | |||
SHA-1 signatures. | 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. | |||
* Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign | * Neither PGP 5.x nor PGP 6.0 recognize Elgamal Encrypt and Sign | |||
keys. They only handle Elgamal Encrypt-only keys. | keys. They only handle Elgamal Encrypt-only keys. | |||
* There are many ways possible for two keys to have the same key | * There are many ways possible for two keys to have the same key | |||
material, but different fingerprints (and thus key ids). Perhaps | material, but different fingerprints (and thus key ids). Perhaps | |||
the most interesting is an RSA key that has been "upgraded" to | the most interesting is an RSA key that has been "upgraded" to V4 | |||
V4 format, but since a V4 fingerprint is constructed by hashing | format, but since a V4 fingerprint is constructed by hashing the | |||
the key creation time along with other things, two V4 keys | key creation time along with other things, two V4 keys created at | |||
created at different times, yet with the same key material will | different times, yet with the same key material will have | |||
have different fingerprints. | different fingerprints. | |||
* If an implementation is using zlib to interoperate with PGP 2.x, | * If an implementation 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 | |||
San Diego, CA 92131 USA | San Diego, CA 92131 USA | |||
Email: jwn2@qualcomm.com | ||||
Tel: +1 619-658-3510 | ||||
The principal authors of this draft are: | Phone: +1 619-658-3510 | |||
EMail: jwn2@qualcomm.com | ||||
Jon Callas | The principal authors of this memo are: | |||
Network Associates, Inc. | ||||
3965 Freedom Circle | ||||
Santa Clara, CA 95054, USA | ||||
Email: jon@pgp.com, jcallas@nai.com | ||||
Tel: +1-408-346-5860 | ||||
Lutz Donnerhacke | Jon Callas | |||
IKS GmbH | Network Associates, Inc. | |||
Wildenbruchstr. 15 | 3965 Freedom Circle | |||
07745 Jena, Germany | Santa Clara, CA 95054, USA | |||
EMail: lutz@iks-jena.de | ||||
Tel: +49-3641-675642 | ||||
Hal Finney | Phone: +1 408-346-5860 | |||
Network Associates, Inc. | EMail: jon@pgp.com, jcallas@nai.com | |||
3965 Freedom Circle | ||||
Santa Clara, CA 95054, USA | ||||
Email: hal@pgp.com | ||||
Rodney Thayer | Lutz Donnerhacke | |||
EIS Corporation | IKS GmbH | |||
Clearwater, FL 33767, USA | Wildenbruchstr. 15 | |||
Email: rodney@unitran.com | 07745 Jena, Germany | |||
This draft also draws on much previous work from a number of other | Phone: +49-3641-675642 | |||
EMail: lutz@iks-jena.de | ||||
Hal Finney | ||||
Network Associates, Inc. | ||||
3965 Freedom Circle | ||||
Santa Clara, CA 95054, USA | ||||
EMail: hal@pgp.com | ||||
Rodney Thayer | ||||
EIS Corporation | ||||
Clearwater, FL 33767, USA | ||||
EMail: rodney@unitran.com | ||||
This memo 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 | |||
Levien, 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," | |||
the version in the proceedings has an error. A revised version is | Eurocrypt 96. Note that the version in the | |||
available at the time of writing from | proceedings has an error. A revised version is | |||
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc/ElGamal.ps> | available at the time of writing from | |||
<ftp://ftp.inf.ethz.ch/pub/publications/papers/ti/isc | ||||
/ElGamal.ps> | ||||
[DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved | [BLOWFISH] Schneier, B. "Description of a New Variable-Length | |||
international version of PGP", | Key, 64-Bit Block Cipher (Blowfish)" Fast Software | |||
ftp://ftp.iks-jena.de/mitarb/lutz/crypt/software/pgp/ | Encryption, Cambridge Security Workshop Proceedings | |||
(December 1993), Springer-Verlag, 1994, pp191-204 | ||||
[ELGAMAL] T. ElGamal, "A Public-Key Cryptosystem and a Signature | <http://www.counterpane.com/bfsverlag.html> | |||
Scheme Based on Discrete Logarithms," IEEE Transactions on | ||||
Information Theory, v. IT-31, n. 4, 1985, pp. 469-472. | ||||
[ISO-10646] ISO/IEC 10646-1:1993. International Standard -- | [DONNERHACKE] Donnerhacke, L., et. al, "PGP263in - an improved | |||
Information technology -- Universal Multiple-Octet Coded Character | international version of PGP", ftp://ftp.iks- | |||
Set (UCS) -- Part 1: Architecture and Basic Multilingual Plane. | jena.de/mitarb/lutz/crypt/software/pgp/ | |||
UTF-8 is described in Annex R, adopted but not yet published. | ||||
UTF-16 is described in Annex Q, adopted but not yet published. | ||||
[MENEZES] Alfred Menezes, Paul van Oorschot, and Scott Vanstone, | [ELGAMAL] T. ElGamal, "A Public-Key Cryptosystem and a | |||
"Handbook of Applied Cryptography," CRC Press, 1996. | Signature Scheme Based on Discrete Logarithms," IEEE | |||
Transactions on Information Theory, v. IT-31, n. 4, | ||||
1985, pp. 469-472. | ||||
[RFC822] D. Crocker, "Standard for the format of ARPA Internet text | [IDEA] Lai, X, "On the design and security of block | |||
messages", RFC 822, August 1982 | ciphers", ETH Series in Information Processing, J.L. | |||
Massey (editor), Vol. 1, Hartung-Gorre Verlag | ||||
Knostanz, Technische Hochschule (Zurich), 1992 | ||||
[RFC1423] D. Balenson, "Privacy Enhancement for Internet Electronic | [ISO-10646] ISO/IEC 10646-1:1993. International Standard -- | |||
Mail: Part III: Algorithms, Modes, and Identifiers", RFC 1423, | Information technology -- Universal Multiple-Octet | |||
October 1993 | Coded Character Set (UCS) -- Part 1: Architecture | |||
and Basic Multilingual Plane. UTF-8 is described in | ||||
Annex R, adopted but not yet published. UTF-16 is | ||||
described in Annex Q, adopted but not yet published. | ||||
[RFC1641] Goldsmith, D., and M. Davis, "Using Unicode with MIME", | [MENEZES] Alfred Menezes, Paul van Oorschot, and Scott | |||
RFC 1641, Taligent inc., July 1994. | Vanstone, "Handbook of Applied Cryptography," CRC | |||
Press, 1996. | ||||
[RFC1750] Eastlake, Crocker, & Schiller., Randomness Recommendations | [RFC822] Crocker, D., "Standard for the format of ARPA | |||
for Security. December 1994. | Internet text messages", STD 11, RFC 822, August | |||
1982. | ||||
[RFC1951] Deutsch, P., DEFLATE Compressed Data Format Specification | [RFC1423] Balenson, D., "Privacy Enhancement for Internet | |||
version 1.3. May 1996. | Electronic Mail: Part III: Algorithms, Modes, and | |||
Identifiers", RFC 1423, October 1993. | ||||
[RFC1983] G. Malkin., Internet Users' Glossary. August 1996. | [RFC1641] Goldsmith, D. and M. Davis, "Using Unicode with | |||
MIME", RFC 1641, July 1994. | ||||
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message | [RFC1750] Eastlake, D., Crocker, S. and J. Schiller, | |||
Exchange Formats", RFC 1991, August 1996. | "Randomness Recommendations for Security", RFC 1750, | |||
December 1994. | ||||
[RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy | [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format | |||
(PGP)", RFC 2015, October 1996. | Specification version 1.3.", RFC 1951, May 1996. | |||
[RFC2231] Borenstein, N., and Freed, N., "Multipurpose Internet Mail | [RFC1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC | |||
Extensions (MIME) Part One: Format of Internet Message Bodies.", | 1983, August 1996. | |||
November 1996 | ||||
[RFC2119] Bradner, S., Key words for use in RFCs to Indicate | [RFC1991] Atkins, D., Stallings, W. and P. Zimmermann, "PGP | |||
Requirement Level. March 1997. | Message Exchange Formats", RFC 1991, August 1996. | |||
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", May 1997 | [RFC2015] Elkins, M., "MIME Security with Pretty Good Privacy | |||
(PGP)", RFC 2015, October 1996. | ||||
[RFC2279] F. Yergeau., UTF-8, a transformation format of Unicode and | [RFC2231] Borenstein, N. and N. Freed, "Multipurpose Internet | |||
ISO 10646. October 1996. | Mail Extensions (MIME) Part One: Format of Internet | |||
Message Bodies.", RFC 2231, November 1996. | ||||
[RFC2313] RSA Laboratories, "PKCS #1: RSA Encryption Standard," | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
version 1.5, November 1993 | Requirement Level", BCP 14, RFC 2119, March 1997. | |||
17. Full Copyright Statement | [RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC | |||
2144, May 1997. | ||||
Copyright 1998 by The Internet Society. All Rights Reserved. | [RFC2279] Yergeau., F., "UTF-8, a transformation format of | |||
Unicode and ISO 10646", RFC 2279, January 1998. | ||||
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Standard | ||||
version 1.5", RFC 2313, March 1998. | ||||
[SAFER] Massey, J.L. "SAFER K-64: One Year Later", B. | ||||
Preneel, editor, Fast Software Encryption, Second | ||||
International Workshop (LNCS 1008) pp212-241, | ||||
Springer-Verlag 1995 | ||||
17. Full Copyright Statement | ||||
Copyright (C) The Internet Society (1998). 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 are | |||
are included on all such copies and derivative works. However, this | included on all such copies and derivative works. However, this | |||
document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
the copyright notice or references to the Internet Society or other | the copyright notice or references to the Internet Society or other | |||
Internet organizations, except as needed for the purpose of | Internet organizations, except as needed for the purpose of | |||
developing Internet standards in which case the procedures for | developing Internet standards in which case the procedures for | |||
copyrights defined in the Internet Standards process must be | copyrights defined in the Internet Standards process must be | |||
followed, or as required to translate it into languages other than | followed, or as required to translate it into languages other than | |||
English. | English. | |||
The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assigns. | |||
This document and the information contained herein is provided on an | ||||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | ||||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | ||||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
End of changes. 230 change blocks. | ||||
784 lines changed or deleted | 824 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |