< draft-ietf-openpgp-crypto-refresh-00.txt   draft-ietf-openpgp-crypto-refresh-01.txt >
Network Working Group W. Koch, Ed. Network Working Group W. Koch, Ed.
Internet-Draft GnuPG e.V. Internet-Draft GnuPG e.V.
Obsoletes: 4880 (if approved) P. Wouters, Ed. Obsoletes: 4880, 5581 (if approved) P. Wouters, Ed.
Intended status: Standards Track 29 January 2021 Intended status: Standards Track 5 February 2021
Expires: 2 August 2021 Expires: 9 August 2021
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-crypto-refresh-00 draft-ietf-openpgp-crypto-refresh-01
Abstract Abstract
{ Work in progress to update the OpenPGP specification from RFC4880 }
This document specifies the message formats used in OpenPGP. OpenPGP
provides encryption with public-key or symmetric cryptographic
algorithms, digital signatures, compression and key management.
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 the information needed to develop interoperable applications based on 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, check, generate, and write conforming packets crossing any read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions. network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid It does, however, discuss implementation issues necessary to avoid
security flaws. security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage. These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 August 2021. This Internet-Draft will expire on 9 August 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 37 skipping to change at page 3, line 31
6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 61 6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 61
6.6. Example of an ASCII Armored Message . . . . . . . . . . . 62 6.6. Example of an ASCII Armored Message . . . . . . . . . . . 62
7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 62 7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 62
7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 63 7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 63
8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 64 8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 64
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 64 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 64
9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 65 9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 65
9.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 65 9.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 65
9.3. Compression Algorithms . . . . . . . . . . . . . . . . . 66 9.3. Compression Algorithms . . . . . . . . . . . . . . . . . 66
9.4. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 67 9.4. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 67
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 67 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 68
10.1. New String-to-Key Specifier Types . . . . . . . . . . . 68 10.1. New String-to-Key Specifier Types . . . . . . . . . . . 68
10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 68 10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 68
10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 68 10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 68
10.2.2. New Signature Subpackets . . . . . . . . . . . . . . 68 10.2.2. New Signature Subpackets . . . . . . . . . . . . . . 69
10.2.3. New Packet Versions . . . . . . . . . . . . . . . . 70 10.2.3. New Packet Versions . . . . . . . . . . . . . . . . 70
10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 70 10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 70
10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 70 10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 71
10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 71 10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 71
10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 71 10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 71
10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 71 10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 71
11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 71 11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 71
11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 71 11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 72
11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 73 11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 73
11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 73 11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 73
11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 74 11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 74
12. Enhanced Key Formats . . . . . . . . . . . . . . . . . . . . 74 12. Enhanced Key Formats . . . . . . . . . . . . . . . . . . . . 74
12.1. Key Structures . . . . . . . . . . . . . . . . . . . . . 74 12.1. Key Structures . . . . . . . . . . . . . . . . . . . . . 74
12.2. Key IDs and Fingerprints . . . . . . . . . . . . . . . . 75 12.2. Key IDs and Fingerprints . . . . . . . . . . . . . . . . 75
13. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 76 13. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 76
13.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 76 13.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 76
13.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 77 13.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 77
13.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 77 13.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 77
13.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 78 13.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 78
13.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 79 13.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 79
13.3. Other Algorithm Preferences . . . . . . . . . . . . . . 80 13.3. Other Algorithm Preferences . . . . . . . . . . . . . . 80
skipping to change at page 4, line 30 skipping to change at page 4, line 24
13.7. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 82 13.7. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 82
13.8. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 82 13.8. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 82
13.9. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 82 13.9. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 82
13.10. Private or Experimental Parameters . . . . . . . . . . . 83 13.10. Private or Experimental Parameters . . . . . . . . . . . 83
13.11. Extension of the MDC System . . . . . . . . . . . . . . 84 13.11. Extension of the MDC System . . . . . . . . . . . . . . 84
13.12. Meta-Considerations for Expansion . . . . . . . . . . . 85 13.12. Meta-Considerations for Expansion . . . . . . . . . . . 85
14. Security Considerations . . . . . . . . . . . . . . . . . . . 85 14. Security Considerations . . . . . . . . . . . . . . . . . . . 85
15. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 89 15. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 89
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 90
16.1. Normative References . . . . . . . . . . . . . . . . . . 90 16.1. Normative References . . . . . . . . . . . . . . . . . . 90
16.2. Informative References . . . . . . . . . . . . . . . . . 92 16.2. Informative References . . . . . . . . . . . . . . . . . 93
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 93 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 93
1. Introduction 1. Introduction
{ This is work in progress to update OpenPGP. Editorial notes are
enclosed in curly braces. }
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 is a revision of RFC 2440, "OpenPGP and key management functions. It is a revision of RFC 4880, "OpenPGP
Message Format", which itself replaces RFC 1991, "PGP Message Message Format", which is a revision of RFC 2440, which itself
Exchange Formats" [RFC1991] [RFC2440]. replaces RFC 1991, "PGP Message Exchange Formats" [RFC1991] [RFC2440]
[RFC4880].
This document obsoletes: RFC 4880 (OpenPGP) and RFC 5581 (Camellia
cipher).
1.1. Terms 1.1. Terms
* OpenPGP - This is a term for security software that uses PGP 5.x * OpenPGP - This is a term for security software that uses PGP 5 as
as a basis, formalized in [RFC2440] and this document. a basis, formalized in this document.
* 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 term * PGP 2 - This version of PGP has many variants; where necessary a
PGP 2.6.x. It used only RSA, MD5, and IDEA for its cryptographic more detailed version number is used here. PGP 2 uses only RSA,
transforms. An informational RFC, [RFC1991], was written MD5, and IDEA for its cryptographic transforms. An informational
describing this version of PGP. RFC, RFC 1991, was written describing this version of PGP.
* PGP 5.x - This version of PGP is formerly known as "PGP 3" in the * PGP 5 - This version of PGP is formerly known as "PGP 3" in the
community and also in the predecessor of this document, [RFC1991]. community. It has new formats and corrects a number of problems
It has new formats and corrects a number of problems in the PGP in the PGP 2 design. It is referred to here as PGP 5 because that
2.6.x design. It is referred to here as PGP 5.x because that
software was the first release of the "PGP 3" code base. software was the first release of the "PGP 3" code base.
* GnuPG - GNU Privacy Guard, also called GPG. GnuPG is an OpenPGP * GnuPG - GNU Privacy Guard, also called GPG. GnuPG is an OpenPGP
implementation that avoids all encumbered algorithms. implementation that avoids all encumbered algorithms.
Consequently, early versions of GnuPG did not include RSA public Consequently, early versions of GnuPG did not include RSA public
keys. GnuPG may or may not have (depending on version) support keys.
for IDEA or other encumbered algorithms.
"PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP
Corporation and are used with permission. The term "OpenPGP" refers Corporation and are used with permission. The term "OpenPGP" refers
to the protocol described in this and related documents. to the protocol described in this and related documents.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME The key words "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME
skipping to change at page 13, line 13 skipping to change at page 13, line 13
they are encrypted, and then the secret-key values themselves. they are encrypted, and then the secret-key values themselves.
3.7.2.2. Symmetric-Key Message Encryption 3.7.2.2. Symmetric-Key Message Encryption
OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet
at the front of a message. This is used to allow S2K specifiers to at the front of a message. This is used to allow S2K specifiers to
be used for the passphrase conversion or to create messages with a be used for the passphrase conversion or to create messages with a
mix of symmetric-key ESKs and public-key ESKs. This allows a message mix of symmetric-key ESKs and public-key ESKs. This allows a message
to be decrypted either with a passphrase or a public-key pair. to be decrypted either with a passphrase or a public-key pair.
PGP 2.X always used IDEA with Simple string-to-key conversion when PGP 2 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
skipping to change at page 18, line 35 skipping to change at page 18, line 35
which the session key is encrypted. If the session key is which the session key is encrypted. If the session key is
encrypted to a subkey, then the Key ID of this subkey is used here encrypted to a subkey, then the Key ID of this subkey is used here
instead of the Key ID of the primary key. instead of the Key ID of the primary key.
* 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 string * A string of octets that is the encrypted session key. This string
takes up the remainder of the packet, and its contents are takes up the remainder of the packet, and its contents 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
skipping to change at page 20, line 36 skipping to change at page 20, line 36
The issuer of this certification has done some casual verification The issuer of this certification has done some casual verification
of the claim of identity. 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 verification The issuer of this certification has done substantial verification
of the claim of identity. Most OpenPGP implementations make their of the claim of identity. Most OpenPGP implementations make their
"key signatures" as 0x10 certifications. Some implementations can "key signatures" as 0x10 certifications. Some implementations can
issue 0x11-0x13 certifications, but few differentiate between the issue 0x11-0x13 certifications, but few differentiate between the
types. types.
0x18: Subkey Binding Signature 0x18: Subkey Binding Signature.
This signature is a statement by the top-level signing key that This signature is a statement by the top-level signing key that
indicates that it owns the subkey. This signature is calculated indicates that it owns the subkey. This signature is calculated
directly on the primary key and subkey, and not on any User ID or directly on the primary key and subkey, and not on any User ID or
other packets. A signature that binds a signing subkey MUST have other packets. A signature that binds a signing subkey MUST have
an Embedded Signature subpacket in this binding signature that an Embedded Signature subpacket in this binding signature that
contains a 0x19 signature made by the signing subkey on the contains a 0x19 signature made by the signing subkey on the
primary key and subkey. primary key and subkey.
0x19: Primary Key Binding Signature 0x19: Primary Key Binding Signature.
This signature is a statement by a signing subkey, indicating that This signature is a statement by a signing subkey, indicating that
it is owned by the primary key and subkey. This signature is it is owned by the primary key and subkey. This signature is
calculated the same way as a 0x18 signature: directly on the calculated the same way as a 0x18 signature: directly on the
primary key and subkey, and not on any User ID or other packets. primary key and subkey, and not on any User ID or other 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 make
about the key itself, rather than the binding between a key and a about the key itself, rather than the binding between a key and a
name. name.
0x20: Key revocation signature 0x20: Key revocation signature.
The signature is calculated directly on the key being revoked. A The signature is calculated directly on the key being revoked. A
revoked key is not to be used. Only revocation signatures by the revoked key is not to be used. Only revocation signatures by the
key being revoked, or by an authorized revocation key, should be key being revoked, or by an authorized revocation key, should be
considered valid revocation signatures. considered valid revocation signatures.
0x28: Subkey revocation signature 0x28: Subkey revocation signature.
The signature is calculated directly on the subkey being revoked. The signature is calculated directly on the subkey being revoked.
A revoked subkey is not to be used. Only revocation signatures by A revoked subkey is not to be used. Only revocation signatures by
the top-level signature key that is bound to this subkey, or by an the top-level signature key that is bound to this subkey, or by an
authorized revocation key, should be considered valid revocation authorized revocation key, should be considered valid revocation
signatures. signatures.
0x30: Certification revocation signature 0x30: Certification revocation signature.
This signature revokes an earlier User ID certification signature This signature revokes an earlier User ID certification signature
(signature class 0x10 through 0x13) or direct-key signature (signature class 0x10 through 0x13) or direct-key signature
(0x1F). It should be issued by the same key that issued the (0x1F). It should be issued by the same key that issued the
revoked signature or an authorized revocation key. The signature revoked signature or an authorized revocation key. The signature
is computed over the same data as the certificate that it revokes, is computed over the same data as the certificate that it revokes,
and should have a later creation date than that certificate. and should have a later creation date than that certificate.
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 in
it. it.
skipping to change at page 22, line 31 skipping to change at page 22, line 31
The concatenation of the data to be signed, the signature type, and The concatenation of the data to be signed, the signature type, and
creation time from the Signature packet (5 additional octets) is creation time from the Signature packet (5 additional octets) is
hashed. The resulting hash value is used in the signature algorithm. hashed. The resulting hash value is used in the signature algorithm.
The high 16 bits (first two octets) of the hash are included in the The high 16 bits (first two octets) of the hash are included in the
Signature packet to provide a quick test to reject some invalid Signature packet to provide a quick test to reject some invalid
signatures. signatures.
Algorithm-Specific Fields for RSA signatures: Algorithm-Specific Fields for RSA signatures:
* multiprecision integer (MPI) of RSA signature value m**d mod n. * Multiprecision integer (MPI) of RSA signature value m**d mod n.
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 signatures than for RSA signatures. DSA signatures than for RSA signatures.
skipping to change at page 24, line 17 skipping to change at page 24, line 17
+============+==========================================+ +============+==========================================+
| MD5 | 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, | | MD5 | 0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, |
| | 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, | | | 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, |
| | 0x02, 0x05, 0x05, 0x00, 0x04, 0x10 | | | 0x02, 0x05, 0x05, 0x00, 0x04, 0x10 |
+------------+------------------------------------------+ +------------+------------------------------------------+
| RIPEMD-160 | 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, | | RIPEMD-160 | 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, |
| | 0x2B, 0x24, 0x03, 0x02, 0x01, 0x05, | | | 0x2B, 0x24, 0x03, 0x02, 0x01, 0x05, |
| | 0x00, 0x04, 0x14 | | | 0x00, 0x04, 0x14 |
+------------+------------------------------------------+ +------------+------------------------------------------+
| SHA-1 | 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, | | SHA-1 | 0x30, 0x21, 0x30, 0x09, 0x06, 0x05, |
| | 0x2b, 0x0E, 0x03, 0x02, 0x1A, 0x05, | | | 0x2B, 0x0E, 0x03, 0x02, 0x1A, 0x05, |
| | 0x00, 0x04, 0x14 | | | 0x00, 0x04, 0x14 |
+------------+------------------------------------------+ +------------+------------------------------------------+
| SHA224 | 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, | | SHA224 | 0x30, 0x2D, 0x30, 0x0D, 0x06, 0x09, |
| | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, |
| | 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C | | | 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C |
+------------+------------------------------------------+ +------------+------------------------------------------+
| SHA256 | 0x30, 0x31, 0x30, 0x0d, 0x06, 0x09, | | SHA256 | 0x30, 0x31, 0x30, 0x0D, 0x06, 0x09, |
| | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, |
| | 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 | | | 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20 |
+------------+------------------------------------------+ +------------+------------------------------------------+
| SHA384 | 0x30, 0x41, 0x30, 0x0d, 0x06, 0x09, | | SHA384 | 0x30, 0x41, 0x30, 0x0D, 0x06, 0x09, |
| | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, |
| | 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30 | | | 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30 |
+------------+------------------------------------------+ +------------+------------------------------------------+
| SHA512 | 0x30, 0x51, 0x30, 0x0d, 0x06, 0x09, | | SHA512 | 0x30, 0x51, 0x30, 0x0D, 0x06, 0x09, |
| | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, | | | 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, |
| | 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40 | | | 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40 |
+------------+------------------------------------------+ +------------+------------------------------------------+
Table 5: Hash hexadecimal prefixes Table 5: Hash hexadecimal prefixes
DSA signatures MUST use hashes that are equal in size to the number DSA signatures MUST use hashes that are equal in size to the number
of bits of q, the group generated by the DSA key's generator value. of bits of q, the group generated by the DSA key's generator value.
If the output size of the chosen hash is larger than the number of If the output size of the chosen hash is larger than the number of
skipping to change at page 39, line 46 skipping to change at page 39, line 46
hashed directly. For text document signatures (type 0x01), the hashed directly. For text document signatures (type 0x01), the
document is canonicalized by converting line endings to <CR><LF>, and document is canonicalized by converting line endings to <CR><LF>, and
the resulting data is hashed. the resulting data is hashed.
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 binding signature a key packet with two-octet length.) A subkey binding signature
(type 0x18) or primary key binding signature (type 0x19) then hashes (type 0x18) or primary key binding signature (type 0x19) then hashes
the subkey using the same format as the main key (also using 0x99 as the subkey using the same format as the main key (also using 0x99 as
the first octet). Key revocation signatures (types 0x20 and 0x28) the first octet). Primary key revocation signatures (type 0x20) hash
hash only the key being revoked. only the key being revoked. Subkey revocation signature (type 0x28)
hash first the primary key and then the subkey being revoked.
A certification signature (type 0x10 through 0x13) hashes the User ID A certification signature (type 0x10 through 0x13) hashes the User ID
being bound to the key into the hash context after the above data. A being bound to the key into the hash context after the above data. A
V3 certification hashes the contents of the User ID or attribute V3 certification hashes the contents of the User ID or attribute
packet packet, without any header. A V4 certification hashes the packet packet, without any header. A V4 certification hashes the
constant 0xB4 for User ID certifications or the constant 0xD1 for constant 0xB4 for User ID certifications or the constant 0xD1 for
User Attribute certifications, followed by a four-octet number giving User Attribute certifications, followed by a four-octet number giving
the length of the User ID or User Attribute data, and then the User the length of the User ID or User Attribute data, and then the User
ID or User Attribute data. ID or User Attribute data.
skipping to change at page 41, line 28 skipping to change at page 41, line 28
Data packet that holds an encrypted message. The message is Data packet that holds an encrypted message. The message is
encrypted with a session key, and the session key is itself encrypted encrypted with a session key, and the session key is itself encrypted
and stored in the Encrypted Session Key packet or the Symmetric-Key and stored in the Encrypted Session Key packet or the Symmetric-Key
Encrypted Session Key packet. Encrypted Session Key packet.
If the Symmetrically Encrypted Data packet is preceded by one or more If the Symmetrically Encrypted Data packet is preceded by one or 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 passphrases. This packet type is new and is not generated by or more passphrases. This packet type is new and is not generated by
PGP 2.x or PGP 5.0. PGP 2 or PGP version 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 is * A one-octet version number. The only currently defined version is
4. 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.
skipping to change at page 43, line 26 skipping to change at page 43, line 26
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 packet. Note: in PGP version 2.6, tag 14 was intended to indicate a comment
This tag was selected for reuse because no previous version of PGP packet. This tag was selected for reuse because no previous version
ever emitted comment packets but they did properly ignore them. of PGP ever emitted comment packets but they did properly ignore
Public-Subkey packets are ignored by PGP 2.6.x and do not cause it to them. Public-Subkey packets are ignored by PGP version 2.6 and do
fail, providing a limited degree of backward compatibility. not cause it to fail, providing a limited degree of backward
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 Key A Secret-Subkey packet (tag 7) is the subkey analog of the Secret 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 4 keys first appeared in were first generated by PGP version 2.6. Version 4 keys first
PGP 5.0 and are the preferred key version for OpenPGP. appeared in PGP 5 and are the preferred key version for OpenPGP.
OpenPGP implementations MUST create keys with version 4 format. V3 OpenPGP implementations MUST create keys with version 4 format. V3
keys are deprecated; an implementation MUST NOT generate a V3 key, keys are deprecated; an implementation MUST NOT generate a V3 key,
but MAY accept it. but MAY accept it.
A version 3 public key or public-subkey packet contains: A version 3 public key or public-subkey packet contains:
* A one-octet version number (3). * A one-octet version number (3).
* A four-octet number denoting the time that the key was created. * A four-octet number denoting the time that the key was created.
skipping to change at page 48, line 51 skipping to change at page 48, line 51
The repetition of 16 bits in the random data prefixed to the message The repetition of 16 bits in the random data prefixed to the message
allows the receiver to immediately check whether the session key is allows the receiver to immediately check whether the session key is
incorrect. See Section 14 for hints on the proper use of this "quick incorrect. See Section 14 for hints on the proper use of this "quick
check". check".
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 with packet, but no released version of PGP generated Literal packets with
this tag. With PGP 5.x, this packet has been reassigned and is this tag. With PGP 5, this packet has been reassigned 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 the Such a packet MUST be ignored when received. It may be placed at the
beginning of a message that uses features not available in PGP 2.6.x beginning of a message that uses features not available in PGP
in order to cause that version to report that newer software is version 2.6 in order to cause that version to report that newer
necessary to process the message. software is 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 54, line 46 skipping to change at page 54, line 46
from Bob. (Note also that if Bob wishes to communicate secretly from Bob. (Note also that if Bob wishes to communicate secretly
with Alice, but without authentication or identification and with with Alice, but without authentication or identification and with
a threat model that includes forgers, he has a problem that a threat model that includes forgers, he has a problem that
transcends mere cryptography.) transcends mere cryptography.)
Note also that unlike nearly every other OpenPGP subsystem, there Note also that unlike nearly every other OpenPGP subsystem, there
are no parameters in the MDC system. It hard-defines SHA-1 as its are no parameters in the MDC system. It hard-defines SHA-1 as its
hash function. This is not an accident. It is an intentional hash function. This is not an accident. It is an intentional
choice to avoid downgrade and cross-grade attacks while making a choice to avoid downgrade and cross-grade attacks while making a
simple, fast system. (A downgrade attack would be an attack that simple, fast system. (A downgrade attack would be an attack that
replaced SHA-256 with SHA-1, for example. A cross-grade attack replaced SHA2-256 with SHA-1, for example. A cross-grade attack
would replace SHA-1 with another 160-bit hash, such as RIPE- would replace SHA-1 with another 160-bit hash, such as RIPE-
MD/160, for example.) MD/160, for example.)
However, given the present state of hash function cryptanalysis However, given the present state of hash function cryptanalysis
and cryptography, it may be desirable to upgrade the MDC system to and cryptography, it may be desirable to upgrade the MDC system to
a new hash function. See Section 13.11 for guidance. a new hash function. See Section 13.11 for guidance.
5.14. Modification Detection Code Packet (Tag 19) 5.14. Modification Detection Code Packet (Tag 19)
The Modification Detection Code packet contains a SHA-1 hash of The Modification Detection Code packet contains a SHA-1 hash of
skipping to change at page 57, line 6 skipping to change at page 57, line 6
around the Radix-64 encoded data, so OpenPGP can reconstruct the data around the Radix-64 encoded data, so OpenPGP can reconstruct the data
later. An OpenPGP implementation MAY use ASCII armor to protect raw later. An OpenPGP implementation MAY use ASCII armor to protect raw
binary data. OpenPGP informs the user what kind of data is encoded binary data. OpenPGP informs the user what kind of data is encoded
in the ASCII armor through the use of the headers. in the ASCII armor through the use of the headers.
Concatenating the following data creates ASCII Armor: Concatenating the following data creates ASCII Armor:
* An Armor Header Line, appropriate for the type of data * An Armor Header Line, appropriate for the type of data
* Armor Headers * Armor Headers
* A blank (zero-length, or containing only whitespace) line * A blank 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 type header line text. The header line text is chosen based upon the type
skipping to change at page 57, line 40 skipping to change at page 57, line 40
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 Header unspecified number of parts. Requires the MESSAGE-ID Armor 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
cleartext signatures. Note that PGP 2.x uses BEGIN PGP MESSAGE cleartext signatures. Note that PGP 2 uses BEGIN PGP MESSAGE for
for detached signatures. detached signatures.
Note that all these Armor Header Lines are to consist of a complete Note that all these Armor Header Lines are to consist of a complete
line. That is to say, there is always a line ending preceding the line. That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and header lines, therefore, MUST start at the beginning of a line, and
MUST NOT have text other than whitespace following them on the same MUST NOT have text other than whitespace -- space (0x20), tab (0x09)
line. These line endings are considered a part of the Armor Header or carriage return (0x0d) -- following them on the same line. These
Line for the purposes of determining the content they delimit. This line endings are considered a part of the Armor Header Line for the
is particularly important when computing a cleartext signature (see purposes of determining the content they delimit. This is
particularly important when computing a cleartext signature (see
below). below).
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 decode receiving OpenPGP implementation some information about how to decode
or use the message. The Armor Headers are a part of the armor, not a or use the message. The Armor Headers are a part of the armor, not a
part of the message, and hence are not protected by any signatures part of the message, and hence are not protected by any 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.
Note that some transport methods are sensitive to line length. While Note that some transport methods are sensitive to line length. While
there is a limit of 76 characters for the Radix-64 data there is a limit of 76 characters for the Radix-64 data
(Section 6.3), there is no limit to the length of Armor Headers. (Section 6.3), there is no limit to the length of Armor Headers.
Care should be taken that the Armor Headers are short enough to Care should be taken that the Armor Headers are short enough to
survive transport. One way to do this is to repeat an Armor Header survive transport. One way to do this is to repeat an Armor Header
key multiple times with different values for each so that no one line Key multiple times with different values for each so that no one line
is overly long. is overly long.
Currently defined Armor Header Keys are as follows: Currently defined Armor Header Keys are as follows:
* "Version", which states the OpenPGP implementation and version * "Version", which states the OpenPGP implementation and version
used to encode the message. used to encode the message.
* "Comment", a user-defined comment. OpenPGP defines all text to be * "Comment", a user-defined comment. OpenPGP defines all text to be
in UTF-8. A comment may be any UTF-8 string. However, the whole in UTF-8. A comment may be any UTF-8 string. However, the whole
point of armoring is to provide seven-bit-clean data. point of armoring is to provide seven-bit-clean data.
skipping to change at page 59, line 17 skipping to change at page 59, line 28
implementation will get best results by translating into and out implementation will get best results by translating into and out
of UTF-8. However, there are many instances where this is easier of UTF-8. However, there are many instances where this is easier
said than done. Also, there are communities of users who have no said than done. Also, there are communities of users who have no
need for UTF-8 because they are all happy with a character set need for UTF-8 because they are all happy with a character set
like ISO Latin-5 or a Japanese character set. In such instances, like ISO Latin-5 or a Japanese character set. In such instances,
an implementation MAY override the UTF-8 default by using this an implementation MAY override the UTF-8 default by using this
header key. An implementation MAY implement this key and any header key. An implementation MAY implement this key and any
translations it cares to; an implementation MAY ignore it and translations it cares to; an implementation MAY ignore it and
assume all text is UTF-8. assume all text is UTF-8.
The blank line can either be zero-length or contain only whitespace,
that is spaces (0x20), tabs (0x09) or carriage returns (0x0d).
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 output The encoding process represents 24-bit groups of input bits as output
strings of 4 encoded characters. Proceeding from left to right, a strings of 4 encoded characters. Proceeding from left to right, a
24-bit input group is formed by concatenating three 8-bit input 24-bit input group is formed by concatenating three 8-bit input
groups. These 24 bits are then treated as four concatenated 6-bit groups. These 24 bits are then treated as four concatenated 6-bit
skipping to change at page 62, line 6 skipping to change at page 62, line 6
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
Input data: 0x14FB9C03D97E Input data: 0x14FB9C03D97E
Hex: 1 4 F B 9 C | 0 3 D 9 7 E Hex: 1 4 F B 9 C | 0 3 D 9 7 E
8-bit: 00010100 11111011 10011100 | 00000011 11011001 11111110 8-bit: 00010100 11111011 10011100 | 00000011 11011001 01111110
6-bit: 000101 001111 101110 011100 | 000000 111101 100111 111110 6-bit: 000101 001111 101110 011100 | 000000 111101 100101 111110
Decimal: 5 15 46 28 0 61 37 62 Decimal: 5 15 46 28 0 61 37 62
Output: F P u c A 9 l + Output: F P u c A 9 l +
Input data: 0x14FB9C03D9 Input data: 0x14FB9C03D9
Hex: 1 4 F B 9 C | 0 3 D 9 Hex: 1 4 F B 9 C | 0 3 D 9
8-bit: 00010100 11111011 10011100 | 00000011 11011001 8-bit: 00010100 11111011 10011100 | 00000011 11011001
pad with 00 pad with 00
6-bit: 000101 001111 101110 011100 | 000000 111101 100100 6-bit: 000101 001111 101110 011100 | 000000 111101 100100
Decimal: 5 15 46 28 0 61 36 Decimal: 5 15 46 28 0 61 36
pad with = pad with =
Output: F P u c A 9 k = Output: F P u c A 9 k =
skipping to change at page 63, line 10 skipping to change at page 63, line 10
is not intended to be reversible. [RFC3156] defines another way to is not intended to be reversible. [RFC3156] defines another way to
sign cleartext messages for environments that support MIME.) sign cleartext messages for environments that support 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 blank 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(s) are used for the signature. If there are no such algorithm(s) are used for the signature. If there are no such
headers, MD5 is used. If MD5 is the only hash used, then an headers, MD5 is used. If MD5 is the only hash used, then an
skipping to change at page 64, line 9 skipping to change at page 64, line 9
As with binary signatures on text documents, a cleartext signature is As with binary signatures on text documents, a cleartext signature is
calculated on the text using canonical <CR><LF> line endings. The calculated on the text using canonical <CR><LF> line endings. 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.
When reversing dash-escaping, an implementation MUST strip the string When reversing dash-escaping, an implementation MUST strip the string
"-" if it occurs at the beginning of a line, and SHOULD warn on "-" "-" if it occurs at the beginning of a line, and SHOULD warn on "-"
and any character other than a space at the beginning of a line. and any character other than a space at the beginning of a line.
Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at Also, any trailing whitespace -- spaces (0x20), tabs (0x09) or
the end of any line is removed when the cleartext signature is carriage returns (0x0d) -- at the end of any line is removed when the
generated. cleartext signature is generated and verified.
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 the first, followed by a match for the second, etc. for 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
skipping to change at page 65, line 39 skipping to change at page 65, line 39
| | for IETF-S/MIME) | | | for IETF-S/MIME) |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
| 100 to | Private/Experimental algorithm | | 100 to | Private/Experimental algorithm |
| 110 | | | 110 | |
+--------+---------------------------------------------------+ +--------+---------------------------------------------------+
Table 13: Public-key algorithm registry Table 13: Public-key algorithm registry
Implementations MUST implement DSA for signatures, and Elgamal for Implementations MUST implement DSA for signatures, and Elgamal for
encryption. Implementations SHOULD implement RSA keys (1). RSA encryption. Implementations SHOULD implement RSA keys (1). RSA
Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and SHOULD NOT
generated, but may be interpreted. See Section 13.5. See be generated, but may be interpreted. See Section 13.5. See
Section 13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal Section 13.8 for notes on Elliptic Curve (18), ECDSA (19), Elgamal
Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement Encrypt or Sign (20), and X9.42 (21). Implementations MAY implement
any other algorithm. 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 |
skipping to change at page 66, line 25 skipping to change at page 66, line 25
| 6 | Reserved | | 6 | Reserved |
+--------+---------------------------------------+ +--------+---------------------------------------+
| 7 | AES with 128-bit key [AES] | | 7 | AES with 128-bit key [AES] |
+--------+---------------------------------------+ +--------+---------------------------------------+
| 8 | AES with 192-bit key | | 8 | AES with 192-bit key |
+--------+---------------------------------------+ +--------+---------------------------------------+
| 9 | AES with 256-bit key | | 9 | AES with 256-bit key |
+--------+---------------------------------------+ +--------+---------------------------------------+
| 10 | Twofish with 256-bit key [TWOFISH] | | 10 | Twofish with 256-bit key [TWOFISH] |
+--------+---------------------------------------+ +--------+---------------------------------------+
| 11 | Camellia with 128-bit key [RFC3713] |
+--------+---------------------------------------+
| 12 | Camellia with 192-bit key |
+--------+---------------------------------------+
| 13 | Camellia with 256-bit key |
+--------+---------------------------------------+
| 100 to | Private/Experimental algorithm | | 100 to | Private/Experimental algorithm |
| 110 | | | 110 | |
+--------+---------------------------------------+ +--------+---------------------------------------+
Table 14: Symmetric-key algorithm registry Table 14: Symmetric-key algorithm registry
Implementations MUST implement TripleDES. Implementations SHOULD Implementations MUST implement TripleDES. Implementations SHOULD
implement AES-128 and CAST5. Implementations that interoperate with implement AES-128 and CAST5. Implementations that interoperate with
PGP 2.6 or earlier need to support IDEA, as that is the only PGP 2.6 or earlier need to support IDEA, as that is the only
symmetric cipher those versions use. Implementations MAY implement symmetric cipher those versions use. Implementations MAY implement
skipping to change at page 67, line 29 skipping to change at page 67, line 36
| 3 | RIPE-MD/160 [HAC] | "RIPEMD160" | | 3 | RIPE-MD/160 [HAC] | "RIPEMD160" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 4 | Reserved | | | 4 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 5 | Reserved | | | 5 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 6 | Reserved | | | 6 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 7 | Reserved | | | 7 | Reserved | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 8 | SHA256 [FIPS180] | "SHA256" | | 8 | SHA2-256 [FIPS180] | "SHA256" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 9 | SHA384 [FIPS180] | "SHA384" | | 9 | SHA2-384 [FIPS180] | "SHA384" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 10 | SHA512 [FIPS180] | "SHA512" | | 10 | SHA2-512 [FIPS180] | "SHA512" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 11 | SHA224 [FIPS180] | "SHA224" | | 11 | SHA2-224 [FIPS180] | "SHA224" |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
| 100 to 110 | Private/Experimental algorithm | | | 100 to 110 | Private/Experimental algorithm | |
+------------+--------------------------------+-------------+ +------------+--------------------------------+-------------+
Table 16: Hash algorithm registry Table 16: Hash algorithm registry
Implementations MUST implement SHA-1. Implementations MAY implement Implementations MUST implement SHA-1. Implementations MAY implement
other algorithms. MD5 is deprecated. other algorithms. MD5 is deprecated.
10. IANA Considerations 10. IANA Considerations
skipping to change at page 68, line 37 skipping to change at page 68, line 44
types of certificate identification. This specification creates a types of certificate identification. This specification creates a
registry of User Attribute types. The registry includes the User registry of User Attribute types. The registry includes the User
Attribute type, the name of the User Attribute, and a reference to Attribute type, the name of the User Attribute, and a reference to
the defining specification. The initial values for this registry can the defining specification. The initial values for this registry can
be found in Section 5.12. Adding a new User Attribute type MUST be be found in Section 5.12. Adding a new User Attribute type MUST be
done through the IETF CONSENSUS method, as described in [RFC2434]. done through the IETF CONSENSUS method, as described in [RFC2434].
10.2.1.1. Image Format Subpacket Types 10.2.1.1. Image Format Subpacket Types
Within User Attribute packets, there is an extensible mechanism for Within User Attribute packets, there is an extensible mechanism for
other types of image-based user attributes. This specification other types of image-based User Attributes. This specification
creates a registry of Image Attribute subpacket types. The registry creates a registry of Image Attribute subpacket types. The registry
includes the Image Attribute subpacket type, the name of the Image includes the Image Attribute subpacket type, the name of the Image
Attribute subpacket, and a reference to the defining specification. Attribute subpacket, and a reference to the defining specification.
The initial values for this registry can be found in Section 5.12.1. The initial values for this registry can be found in Section 5.12.1.
Adding a new Image Attribute subpacket type MUST be done through the Adding a new Image Attribute subpacket type MUST be done through the
IETF CONSENSUS method, as described in [RFC2434]. IETF CONSENSUS method, as described in [RFC2434].
10.2.2. New Signature Subpackets 10.2.2. New Signature Subpackets
OpenPGP signatures contain a mechanism for signed (or unsigned) data OpenPGP signatures contain a mechanism for signed (or unsigned) data
skipping to change at page 73, line 26 skipping to change at page 73, line 33
Transferable public-key packet sequences may be concatenated to allow Transferable public-key packet sequences may be concatenated to allow
transferring multiple public keys in one operation. transferring multiple public keys in one operation.
11.2. Transferable Secret Keys 11.2. Transferable Secret Keys
OpenPGP users may transfer secret keys. The format of a transferable OpenPGP users may transfer secret keys. The format of a transferable
secret key is the same as a transferable public key except that secret key is the same as a transferable public key except that
secret-key and secret-subkey packets are used instead of the public secret-key and secret-subkey packets are used instead of the public
key and public-subkey packets. Implementations SHOULD include self- key and public-subkey packets. Implementations SHOULD include self-
signatures on any user IDs and subkeys, as this allows for a complete signatures on any User IDs and subkeys, as this allows for a complete
public key to be automatically extracted from the transferable secret public key to be automatically extracted from the transferable secret
key. Implementations MAY choose to omit the self-signatures, key. Implementations MAY choose to omit the self-signatures,
especially if a transferable public key accompanies the transferable especially if a transferable public key accompanies the transferable
secret key. secret key.
11.3. OpenPGP Messages 11.3. 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):
skipping to change at page 77, line 9 skipping to change at page 77, line 9
document, adapted from those in PKCS#1 v2.1 [RFC3447]. [RFC3447] document, adapted from those in PKCS#1 v2.1 [RFC3447]. [RFC3447]
should be treated as the ultimate authority on PKCS#1 for OpenPGP. should be treated as the ultimate authority on PKCS#1 for OpenPGP.
Nonetheless, we believe that there is value in having a self- Nonetheless, we believe that there is value in having a self-
contained document that avoids problems in the future with needed contained document that avoids problems in the future with needed
changes in the conventions. changes in the conventions.
13.1.1. EME-PKCS1-v1_5-ENCODE 13.1.1. EME-PKCS1-v1_5-ENCODE
Input: Input:
k = the length in octets of the key modulus k = the length in octets of the key modulus.
M = message to be encoded, an octet string of length mLen, where M = message to be encoded, an octet string of length mLen, where
mLen <= k - 11 mLen <= k - 11.
Output: Output:
EM = encoded message, an octet string of length k EM = encoded message, an octet string of length k.
Error: "message too long" Error: "message too long".
1. Length checking: If mLen > k - 11, output "message too long" and 1. Length checking: If mLen > k - 11, output "message too long" and
stop. stop.
2. Generate an octet string PS of length k - mLen - 3 consisting of 2. Generate an octet string PS of length k - mLen - 3 consisting of
pseudo-randomly generated nonzero octets. The length of PS will pseudo-randomly generated nonzero octets. The length of PS will
be at least eight octets. be at least eight octets.
3. Concatenate PS, the message M, and other padding to form an 3. Concatenate PS, the message M, and other padding to form an
encoded message EM of length k octets as encoded message EM of length k octets as
skipping to change at page 77, line 42 skipping to change at page 77, line 42
4. Output EM. 4. Output EM.
13.1.2. EME-PKCS1-v1_5-DECODE 13.1.2. EME-PKCS1-v1_5-DECODE
Input: Input:
EM = encoded message, an octet string EM = encoded message, an octet string
Output: Output:
M = message, an octet string M = message, an octet string.
Error: "decryption error" Error: "decryption error".
To decode an EME-PKCS1_v1_5 message, separate the encoded message EM To decode an EME-PKCS1_v1_5 message, separate the encoded message EM
into an octet string PS consisting of nonzero octets and a message M into an octet string PS consisting of nonzero octets and a message M
as follows as follows
EM = 0x00 || 0x02 || PS || 0x00 || M. EM = 0x00 || 0x02 || PS || 0x00 || M.
If the first octet of EM does not have hexadecimal value 0x00, if the If the first octet of EM does not have hexadecimal value 0x00, if the
second octet of EM does not have hexadecimal value 0x02, if there is second octet of EM does not have hexadecimal value 0x02, if there is
no octet with hexadecimal value 0x00 to separate PS from M, or if the no octet with hexadecimal value 0x00 to separate PS from M, or if the
skipping to change at page 78, line 20 skipping to change at page 78, line 20
in reporting between a decryption error and a padding error. in reporting between a decryption error and a padding error.
13.1.3. EMSA-PKCS1-v1_5 13.1.3. EMSA-PKCS1-v1_5
This encoding method is deterministic and only has an encoding This encoding method is deterministic and only has an encoding
operation. operation.
Option: Option:
Hash - a hash function in which hLen denotes the length in octets of Hash - a hash function in which hLen denotes the length in octets of
the hash function output the hash function output.
Input: Input:
M = message to be encoded M = message to be encoded.
mL = intended length in octets of the encoded message, at least tLen emLen = intended length in octets of the encoded message, at least
+ 11, where tLen is the octet length of the DER encoding T of a tLen + 11, where tLen is the octet length of the DER encoding T of
certain value computed during the encoding operation a certain value computed during the encoding operation.
Output: Output:
EM = encoded message, an octet string of length emLen EM = encoded message, an octet string of length emLen.
Errors: "message too long"; "intended encoded message length too Errors: "message too long"; "intended encoded message length too
short" short".
Steps: Steps:
1. Apply the hash function to the message M to produce a hash value 1. Apply the hash function to the message M to produce a hash value
H: H:
H = Hash(M). H = Hash(M).
If the hash function outputs "message too long," output "message If the hash function outputs "message too long," output "message
too long" and stop. too long" and stop.
skipping to change at page 81, line 32 skipping to change at page 81, line 32
13.6. DSA 13.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than An implementation SHOULD NOT implement DSA keys of size less than
1024 bits. It MUST NOT implement a DSA key with a q size of less 1024 bits. It MUST NOT implement a DSA key with a q size of less
than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the than 160 bits. DSA keys MUST also be a multiple of 64 bits, and the
q size MUST be a multiple of 8 bits. The Digital Signature Standard q size MUST be a multiple of 8 bits. The Digital Signature Standard
(DSS) [FIPS186] specifies that DSA be used in one of the following (DSS) [FIPS186] specifies that DSA be used in one of the following
ways: ways:
* 1024-bit key, 160-bit q, SHA-1, SHA-224, SHA-256, SHA-384, or * 1024-bit key, 160-bit q, SHA-1, SHA2-224, SHA2-256, SHA2-384, or
SHA-512 hash SHA2-512 hash
* 2048-bit key, 224-bit q, SHA-224, SHA-256, SHA-384, or SHA-512 * 2048-bit key, 224-bit q, SHA2-224, SHA2-256, SHA2-384, or SHA2-512
hash hash
* 2048-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash * 2048-bit key, 256-bit q, SHA2-256, SHA2-384, or SHA2-512 hash
* 3072-bit key, 256-bit q, SHA-256, SHA-384, or SHA-512 hash * 3072-bit key, 256-bit q, SHA2-256, SHA2-384, or SHA2-512 hash
The above key and q size pairs were chosen to best balance the The above key and q size pairs were chosen to best balance the
strength of the key with the strength of the hash. Implementations strength of the key with the strength of the hash. Implementations
SHOULD use one of the above key and q size pairs when generating DSA SHOULD use one of the above key and q size pairs when generating DSA
keys. If DSS compliance is desired, one of the specified SHA hashes keys. If DSS compliance is desired, one of the specified SHA hashes
must be used as well. [FIPS186] is the ultimate authority on DSS, must be used as well. [FIPS186] is the ultimate authority on DSS,
and should be consulted for all questions of DSS compliance. and should be consulted for all questions of DSS compliance.
Note that earlier versions of this standard only allowed a 160-bit q Note that earlier versions of this standard only allowed a 160-bit q
with no truncation allowed, so earlier implementations may not be with no truncation allowed, so earlier implementations may not be
skipping to change at page 83, line 46 skipping to change at page 83, line 46
for an 8-octet block). for an 8-octet block).
11. FR is encrypted to produce FRE. 11. FR is encrypted to produce FRE.
12. FRE is xored with the next BS octets of plaintext, to produce 12. FRE is xored with the next BS octets of plaintext, to produce
the next BS octets of ciphertext. These are loaded into FR, and the next BS octets of ciphertext. These are loaded into FR, and
the process is repeated until the plaintext is used up. the process is repeated until the plaintext is used up.
13.10. Private or Experimental Parameters 13.10. Private or Experimental Parameters
S2K specifiers, Signature subpacket types, user attribute types, S2K specifiers, Signature subpacket types, User Attribute types,
image format types, and algorithms described in Section 9 all reserve image format types, and algorithms described in Section 9 all reserve
the range 100 to 110 for private and experimental use. Packet types the range 100 to 110 for private and experimental use. Packet types
reserve the range 60 to 63 for private and experimental use. These reserve the range 60 to 63 for private and experimental use. These
are intentionally managed with the PRIVATE USE method, as described are intentionally managed with the PRIVATE USE method, as described
in [RFC2434]. in [RFC2434].
However, implementations need to be careful with these and promote However, implementations need to be careful with these and promote
them to full IANA-managed parameters when they grow beyond the them to full IANA-managed parameters when they grow beyond the
original, limited system. original, limited system.
skipping to change at page 85, line 43 skipping to change at page 85, line 43
* 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 [RFC4086]). these numbers (see [RFC4086]).
* The MD5 hash algorithm has been found to have weaknesses, with * The MD5 hash algorithm has been found to have weaknesses, with
collisions found in a number of cases. MD5 is deprecated for use collisions found in a number of cases. MD5 is deprecated for use
in OpenPGP. Implementations MUST NOT generate new signatures in OpenPGP. Implementations MUST NOT generate new signatures
using MD5 as a hash function. They MAY continue to consider old using MD5 as a hash function. They MAY continue to consider old
signatures that used MD5 as valid. signatures that used MD5 as valid.
* SHA-224 and SHA-384 require the same work as SHA-256 and SHA-512, * SHA2-224 and SHA2-384 require the same work as SHA2-256 and
respectively. In general, there are few reasons to use them SHA2-512, respectively. In general, there are few reasons to use
outside of DSS compatibility. You need a situation where one them outside of DSS compatibility. You need a situation where one
needs more security than smaller hashes, but does not want to have needs more security than smaller hashes, but does not want to have
the full 256-bit or 512-bit data length. the full 256-bit or 512-bit data length.
* Many security protocol designers think that it is a bad idea to * Many security protocol designers think that it is a bad idea to
use a single key for both privacy (encryption) and integrity use a single key for both privacy (encryption) and integrity
(signatures). In fact, this was one of the motivating forces (signatures). In fact, this was one of the motivating forces
behind the V4 key format with separate signature and encryption behind the V4 key format with separate signature and encryption
keys. If you as an implementer promote dual-use keys, you should keys. If you as an implementer promote dual-use keys, you should
at least be aware of this controversy. at least be aware of this controversy.
skipping to change at page 89, line 21 skipping to change at page 89, line 21
15. Implementation Nits 15. 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 is a non-comprehensive vexing than large differences. Thus, this is a non-comprehensive
list of potential problems and gotchas for a developer who is trying list of potential problems and gotchas for a developer who is trying
to be backward-compatible. to be backward-compatible.
* The IDEA algorithm is patented, and yet it is required for PGP 2.x * The IDEA algorithm is patented, and yet it is required for PGP 2
interoperability. It is also the de-facto preferred algorithm for interoperability. It is also the de-facto preferred algorithm for
a V3 key with a V3 self-signature (or no self-signature). a V3 key with a V3 self-signature (or no self-signature).
* When exporting a private key, PGP 2.x generates the header "BEGIN * When exporting a private key, PGP 2 generates the header "BEGIN
PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK". PGP SECRET KEY BLOCK" instead of "BEGIN PGP PRIVATE KEY BLOCK".
All previous versions ignore the implied data type, and look All previous versions ignore the implied data type, and look
directly at the packet data type. directly at the packet data type.
* PGP 2.0 through 2.5 generated V2 Public-Key packets. These are * PGP versions 2.0 through 2.5 generated V2 Public-Key packets.
identical to the deprecated V3 keys except for the version number. These are identical to the deprecated V3 keys except for the
An implementation MUST NOT generate them and may accept or reject version number. An implementation MUST NOT generate them and may
them as it sees fit. Some older PGP versions generated V2 PKESK accept or reject them as it sees fit. Some older PGP versions
packets (Tag 1) as well. An implementation may accept or reject generated V2 PKESK packets (Tag 1) as well. An implementation may
V2 PKESK packets as it sees fit, and MUST NOT generate them. accept or reject V2 PKESK packets as it sees fit, and MUST NOT
generate them.
* PGP 2.6.x will not accept key-material packets with versions * PGP version 2.6 will not accept key-material packets with versions
greater than 3. greater than 3.
* 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 V4 the most interesting is an RSA key that has been "upgraded" to V4
format, but since a V4 fingerprint is constructed by hashing the format, but since a V4 fingerprint is constructed by hashing the
key creation time along with other things, two V4 keys created at key creation time along with other things, two V4 keys created at
different times, yet with the same key material will have different times, yet with the same key material will 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,
then the "windowBits" parameter should be set to -13. then the "windowBits" parameter should be set to -13.
* The 0x19 back signatures were not required for signing subkeys * The 0x19 back signatures were not required for signing subkeys
until relatively recently. Consequently, there may be keys in the until relatively recently. Consequently, there may be keys in the
wild that do not have these back signatures. Implementing wild that do not have these back signatures. Implementing
software may handle these keys as it sees fit. software may handle these keys as it sees fit.
* OpenPGP does not put limits on the size of public keys. However, * OpenPGP does not put limits on the size of public keys. However,
larger keys are not necessarily better keys. Larger keys take larger keys are not necessarily better keys. Larger keys take
more computation time to use, and this can quickly become more computation time to use, and this can quickly become
skipping to change at page 92, line 37 skipping to change at page 92, line 37
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <https://www.rfc-editor.org/info/rfc3447>. 2003, <https://www.rfc-editor.org/info/rfc3447>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of
the Camellia Encryption Algorithm", RFC 3713,
DOI 10.17487/RFC3713, April 2004,
<https://www.rfc-editor.org/info/rfc3713>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086, "Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005, DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>. <https://www.rfc-editor.org/info/rfc4086>.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition: [SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996. protocols, algorithms, and source code in C", 1996.
[TWOFISH] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall, [TWOFISH] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall,
C., and N. Ferguson, "The Twofish Encryption Algorithm", C., and N. Ferguson, "The Twofish Encryption Algorithm",
skipping to change at page 93, line 14 skipping to change at page 93, line 16
[BLEICHENBACHER] [BLEICHENBACHER]
Bleichenbacher, D., "Generating ElGamal Signatures Without Bleichenbacher, D., "Generating ElGamal Signatures Without
Knowing the Secret Key", Lecture Notes in Computer Knowing the Secret Key", Lecture Notes in Computer
Science Volume 1070, pp. 10-18, 1996. Science Volume 1070, pp. 10-18, 1996.
[JKS02] Jallad, K., Katz, J., and B. Schneier, "Implementation of [JKS02] Jallad, K., Katz, J., and B. Schneier, "Implementation of
Chosen-Ciphertext Attacks against PGP and GnuPG", 2002, Chosen-Ciphertext Attacks against PGP and GnuPG", 2002,
<http://www.counterpane.com/pgp-attack.html>. <http://www.counterpane.com/pgp-attack.html>.
[MAURER] Maurer, U., "Modelling a Public-Key Infrastructure", Proc.
1996 European Symposium on Research in Computer Security
(ESORICS' 96), Lecture Notes in Computer Science,
Springer-Verlag, vol. 1146, pp. 325-350 , September 1996.
[MZ05] Mister, S. and R. Zuccherato, "An Attack on CFB Mode [MZ05] Mister, S. and R. Zuccherato, "An Attack on CFB Mode
Encryption As Used By OpenPGP", IACR ePrint Archive Report Encryption As Used By OpenPGP", IACR ePrint Archive Report
2005/033, 8 February 2005, 2005/033, 8 February 2005,
<http://eprint.iacr.org/2005/033>. <http://eprint.iacr.org/2005/033>.
[REGEX] Friedl, J., "Mastering Regular Expressions", [REGEX] Friedl, J., "Mastering Regular Expressions",
ISBN 0-596-00289-0, August 2002. ISBN 0-596-00289-0, August 2002.
[RFC1423] Balenson, D., "Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers",
RFC 1423, DOI 10.17487/RFC1423, February 1993,
<https://www.rfc-editor.org/info/rfc1423>.
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message [RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, DOI 10.17487/RFC1991, August Exchange Formats", RFC 1991, DOI 10.17487/RFC1991, August
1996, <https://www.rfc-editor.org/info/rfc1991>. 1996, <https://www.rfc-editor.org/info/rfc1991>.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, [RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, DOI 10.17487/RFC2440, "OpenPGP Message Format", RFC 2440, DOI 10.17487/RFC2440,
November 1998, <https://www.rfc-editor.org/info/rfc2440>. November 1998, <https://www.rfc-editor.org/info/rfc2440>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
<https://www.rfc-editor.org/info/rfc4880>.
[SP800-57] NIST, "Recommendation on Key Management", NIST Special [SP800-57] NIST, "Recommendation on Key Management", NIST Special
Publication 800-57, March 2007, Publication 800-57, March 2007,
<http://csrc.nist.gov/publications/nistpubs/800-57/ <http://csrc.nist.gov/publications/nistpubs/800-57/
SP800-57-Part{1,2}.pdf>. SP800-57-Part{1,2}.pdf>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This memo also draws on much previous work from a number of other This memo also draws on much previous work from a number of other
authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc
Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie,
 End of changes. 82 change blocks. 
128 lines changed or deleted 144 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/