< draft-ietf-openpgp-rfc4880bis-07.txt   draft-ietf-openpgp-rfc4880bis-08.txt >
Network Working Group W. Koch Network Working Group W. Koch
Internet-Draft GnuPG e.V. Internet-Draft GnuPG e.V.
Obsoletes: 4880, 5581, 6637 (if B. Carlson Obsoletes: 4880, 5581, 6637 (if B. Carlson
approved) approved)
Intended status: Standards Track R. Tse Intended status: Standards Track R. Tse
Expires: November 14, 2019 Ribose Expires: March 9, 2020 Ribose
D. Atkins D. Atkins
May 13, 2019 D. Gillmor
September 6, 2019
OpenPGP Message Format OpenPGP Message Format
draft-ietf-openpgp-rfc4880bis-07 draft-ietf-openpgp-rfc4880bis-08
Abstract Abstract
{ Work in progress to update the OpenPGP specification from RFC4880 } { Work in progress to update the OpenPGP specification from RFC4880 }
This document specifies the message formats used in OpenPGP. OpenPGP This document specifies the message formats used in OpenPGP. OpenPGP
provides encryption with public-key or symmetric cryptographic provides encryption with public-key or symmetric cryptographic
algorithms, digital signatures, compression and key management. 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
skipping to change at page 1, line 47 skipping to change at page 2, line 4
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 March 9, 2020.
This Internet-Draft will expire on November 14, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. General functions . . . . . . . . . . . . . . . . . . . . . . 6 2. General functions . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Confidentiality via Encryption . . . . . . . . . . . . . 7 2.1. Confidentiality via Encryption . . . . . . . . . . . . . 7
2.2. Authentication via Digital Signature . . . . . . . . . . 7 2.2. Authentication via Digital Signature . . . . . . . . . . 8
2.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Compression . . . . . . . . . . . . . . . . . . . . . . . 8
2.4. Conversion to Radix-64 . . . . . . . . . . . . . . . . . 8 2.4. Conversion to Radix-64 . . . . . . . . . . . . . . . . . 8
2.5. Signature-Only Applications . . . . . . . . . . . . . . . 9 2.5. Signature-Only Applications . . . . . . . . . . . . . . . 9
3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 9 3. Data Element Formats . . . . . . . . . . . . . . . . . . . . 9
3.1. Scalar Numbers . . . . . . . . . . . . . . . . . . . . . 9 3.1. Scalar Numbers . . . . . . . . . . . . . . . . . . . . . 9
3.2. Multiprecision Integers . . . . . . . . . . . . . . . . . 9 3.2. Multiprecision Integers . . . . . . . . . . . . . . . . . 9
3.3. Key IDs . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Key IDs . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.4. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4. Text . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.5. Time Fields . . . . . . . . . . . . . . . . . . . . . . . 10 3.5. Time Fields . . . . . . . . . . . . . . . . . . . . . . . 10
3.6. Keyrings . . . . . . . . . . . . . . . . . . . . . . . . 10 3.6. Keyrings . . . . . . . . . . . . . . . . . . . . . . . . 10
skipping to change at page 3, line 4 skipping to change at page 3, line 6
4.2.1. Old Format Packet Lengths . . . . . . . . . . . . . . 15 4.2.1. Old Format Packet Lengths . . . . . . . . . . . . . . 15
4.2.2. New Format Packet Lengths . . . . . . . . . . . . . . 15 4.2.2. New Format Packet Lengths . . . . . . . . . . . . . . 15
4.2.3. Packet Length Examples . . . . . . . . . . . . . . . 17 4.2.3. Packet Length Examples . . . . . . . . . . . . . . . 17
4.3. Packet Tags . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Packet Tags . . . . . . . . . . . . . . . . . . . . . . . 17
5. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . 18 5. Packet Types . . . . . . . . . . . . . . . . . . . . . . . . 18
5.1. Public-Key Encrypted Session Key Packets (Tag 1) . . . . 18 5.1. Public-Key Encrypted Session Key Packets (Tag 1) . . . . 18
5.2. Signature Packet (Tag 2) . . . . . . . . . . . . . . . . 20 5.2. Signature Packet (Tag 2) . . . . . . . . . . . . . . . . 20
5.2.1. Signature Types . . . . . . . . . . . . . . . . . . . 20 5.2.1. Signature Types . . . . . . . . . . . . . . . . . . . 20
5.2.2. Version 3 Signature Packet Format . . . . . . . . . . 22 5.2.2. Version 3 Signature Packet Format . . . . . . . . . . 22
5.2.3. Version 4 and 5 Signature Packet Formats . . . . . . 25 5.2.3. Version 4 and 5 Signature Packet Formats . . . . . . 25
5.2.4. Computing Signatures . . . . . . . . . . . . . . . . 41 5.2.4. Computing Signatures . . . . . . . . . . . . . . . . 44
5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) . . . 44 5.3. Symmetric-Key Encrypted Session Key Packets (Tag 3) . . . 46
5.4. One-Pass Signature Packets (Tag 4) . . . . . . . . . . . 46 5.4. One-Pass Signature Packets (Tag 4) . . . . . . . . . . . 48
5.5. Key Material Packet . . . . . . . . . . . . . . . . . . . 46 5.5. Key Material Packet . . . . . . . . . . . . . . . . . . . 49
5.5.1. Key Packet Variants . . . . . . . . . . . . . . . . . 47 5.5.1. Key Packet Variants . . . . . . . . . . . . . . . . . 49
5.5.2. Public-Key Packet Formats . . . . . . . . . . . . . . 47 5.5.2. Public-Key Packet Formats . . . . . . . . . . . . . . 50
5.5.3. Secret-Key Packet Formats . . . . . . . . . . . . . . 49 5.5.3. Secret-Key Packet Formats . . . . . . . . . . . . . . 51
5.6. Algorithm-specific Parts of Keys . . . . . . . . . . . . 51 5.6. Algorithm-specific Parts of Keys . . . . . . . . . . . . 53
5.6.1. Algorithm-Specific Part for RSA Keys . . . . . . . . 51 5.6.1. Algorithm-Specific Part for RSA Keys . . . . . . . . 53
5.6.2. Algorithm-Specific Part for DSA Keys . . . . . . . . 51 5.6.2. Algorithm-Specific Part for DSA Keys . . . . . . . . 54
5.6.3. Algorithm-Specific Part for Elgamal Keys . . . . . . 52 5.6.3. Algorithm-Specific Part for Elgamal Keys . . . . . . 54
5.6.4. Algorithm-Specific Part for ECDSA Keys . . . . . . . 52 5.6.4. Algorithm-Specific Part for ECDSA Keys . . . . . . . 54
5.6.5. Algorithm-Specific Part for EdDSA Keys . . . . . . . 53 5.6.5. Algorithm-Specific Part for EdDSA Keys . . . . . . . 55
5.6.6. Algorithm-Specific Part for ECDH Keys . . . . . . . . 53 5.6.6. Algorithm-Specific Part for ECDH Keys . . . . . . . . 55
5.7. Compressed Data Packet (Tag 8) . . . . . . . . . . . . . 54 5.7. Compressed Data Packet (Tag 8) . . . . . . . . . . . . . 56
5.8. Symmetrically Encrypted Data Packet (Tag 9) . . . . . . . 54 5.8. Symmetrically Encrypted Data Packet (Tag 9) . . . . . . . 57
5.9. Marker Packet (Obsolete Literal Packet) (Tag 10) . . . . 55 5.9. Marker Packet (Obsolete Literal Packet) (Tag 10) . . . . 58
5.10. Literal Data Packet (Tag 11) . . . . . . . . . . . . . . 56 5.10. Literal Data Packet (Tag 11) . . . . . . . . . . . . . . 58
5.11. Trust Packet (Tag 12) . . . . . . . . . . . . . . . . . . 57 5.11. Trust Packet (Tag 12) . . . . . . . . . . . . . . . . . . 59
5.12. User ID Packet (Tag 13) . . . . . . . . . . . . . . . . . 57 5.12. User ID Packet (Tag 13) . . . . . . . . . . . . . . . . . 59
5.13. User Attribute Packet (Tag 17) . . . . . . . . . . . . . 57 5.13. User Attribute Packet (Tag 17) . . . . . . . . . . . . . 59
5.13.1. The Image Attribute Subpacket . . . . . . . . . . . 58 5.13.1. The Image Attribute Subpacket . . . . . . . . . . . 60
5.13.2. User ID Attribute Subpacket . . . . . . . . . . . . 59 5.13.2. User ID Attribute Subpacket . . . . . . . . . . . . 61
5.14. Sym. Encrypted Integrity Protected Data Packet (Tag 18) . 59 5.14. Sym. Encrypted Integrity Protected Data Packet (Tag 18) . 61
5.15. Modification Detection Code Packet (Tag 19) . . . . . . . 62 5.15. Modification Detection Code Packet (Tag 19) . . . . . . . 64
5.16. AEAD Encrypted Data Packet (Tag 20) . . . . . . . . . . . 63 5.16. AEAD Encrypted Data Packet (Tag 20) . . . . . . . . . . . 65
5.16.1. EAX Mode . . . . . . . . . . . . . . . . . . . . . . 64 5.16.1. EAX Mode . . . . . . . . . . . . . . . . . . . . . . 66
5.16.2. OCB Mode . . . . . . . . . . . . . . . . . . . . . . 64 5.16.2. OCB Mode . . . . . . . . . . . . . . . . . . . . . . 67
6. Radix-64 Conversions . . . . . . . . . . . . . . . . . . . . 65 6. Radix-64 Conversions . . . . . . . . . . . . . . . . . . . . 67
6.1. An Implementation of the CRC-24 in "C" . . . . . . . . . 66 6.1. An Implementation of the CRC-24 in "C" . . . . . . . . . 68
6.2. Forming ASCII Armor . . . . . . . . . . . . . . . . . . . 66 6.2. Forming ASCII Armor . . . . . . . . . . . . . . . . . . . 68
6.3. Encoding Binary in Radix-64 . . . . . . . . . . . . . . . 69 6.3. Encoding Binary in Radix-64 . . . . . . . . . . . . . . . 71
6.4. Decoding Radix-64 . . . . . . . . . . . . . . . . . . . . 70 6.4. Decoding Radix-64 . . . . . . . . . . . . . . . . . . . . 72
6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 71 6.5. Examples of Radix-64 . . . . . . . . . . . . . . . . . . 73
6.6. Example of an ASCII Armored Message . . . . . . . . . . . 71 6.6. Example of an ASCII Armored Message . . . . . . . . . . . 73
7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 72 7. Cleartext Signature Framework . . . . . . . . . . . . . . . . 74
7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 72 7.1. Dash-Escaped Text . . . . . . . . . . . . . . . . . . . . 74
8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 73 8. Regular Expressions . . . . . . . . . . . . . . . . . . . . . 75
9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 74 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 76
9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 74 9.1. Public-Key Algorithms . . . . . . . . . . . . . . . . . . 76
9.2. ECC Curve OID . . . . . . . . . . . . . . . . . . . . . . 75 9.2. ECC Curve OID . . . . . . . . . . . . . . . . . . . . . . 77
9.3. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 76 9.3. Symmetric-Key Algorithms . . . . . . . . . . . . . . . . 78
9.4. Compression Algorithms . . . . . . . . . . . . . . . . . 76 9.4. Compression Algorithms . . . . . . . . . . . . . . . . . 78
9.5. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 77 9.5. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 79
9.6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . 77 9.6. AEAD Algorithms . . . . . . . . . . . . . . . . . . . . . 79
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
10.1. New String-to-Key Specifier Types . . . . . . . . . . . 78 10.1. New String-to-Key Specifier Types . . . . . . . . . . . 80
10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 78 10.2. New Packets . . . . . . . . . . . . . . . . . . . . . . 80
10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 78 10.2.1. User Attribute Types . . . . . . . . . . . . . . . . 80
10.2.2. Image Format Subpacket Types . . . . . . . . . . . . 78 10.2.2. Image Format Subpacket Types . . . . . . . . . . . . 80
10.2.3. New Signature Subpackets . . . . . . . . . . . . . . 79 10.2.3. New Signature Subpackets . . . . . . . . . . . . . . 81
10.2.4. New Packet Versions . . . . . . . . . . . . . . . . 82 10.2.4. New Packet Versions . . . . . . . . . . . . . . . . 84
10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 82 10.3. New Algorithms . . . . . . . . . . . . . . . . . . . . . 84
10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 82 10.3.1. Public-Key Algorithms . . . . . . . . . . . . . . . 84
10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 83 10.3.2. Symmetric-Key Algorithms . . . . . . . . . . . . . . 85
10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 83 10.3.3. Hash Algorithms . . . . . . . . . . . . . . . . . . 85
10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 83 10.3.4. Compression Algorithms . . . . . . . . . . . . . . . 85
11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 84 11. Packet Composition . . . . . . . . . . . . . . . . . . . . . 86
11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 84 11.1. Transferable Public Keys . . . . . . . . . . . . . . . . 86
11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 85 11.2. Transferable Secret Keys . . . . . . . . . . . . . . . . 87
11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 86 11.3. OpenPGP Messages . . . . . . . . . . . . . . . . . . . . 88
11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 86 11.4. Detached Signatures . . . . . . . . . . . . . . . . . . 88
12. Enhanced Key Formats . . . . . . . . . . . . . . . . . . . . 86 12. Enhanced Key Formats . . . . . . . . . . . . . . . . . . . . 88
12.1. Key Structures . . . . . . . . . . . . . . . . . . . . . 87 12.1. Key Structures . . . . . . . . . . . . . . . . . . . . . 89
12.2. Key IDs and Fingerprints . . . . . . . . . . . . . . . . 88 12.2. Key IDs and Fingerprints . . . . . . . . . . . . . . . . 90
13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 90 13. Elliptic Curve Cryptography . . . . . . . . . . . . . . . . . 92
13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 90 13.1. Supported ECC Curves . . . . . . . . . . . . . . . . . . 92
13.2. ECDSA and ECDH Conversion Primitives . . . . . . . . . . 90 13.2. ECDSA and ECDH Conversion Primitives . . . . . . . . . . 92
13.3. EdDSA Point Format . . . . . . . . . . . . . . . . . . . 91 13.3. EdDSA Point Format . . . . . . . . . . . . . . . . . . . 93
13.4. Key Derivation Function . . . . . . . . . . . . . . . . 91 13.4. Key Derivation Function . . . . . . . . . . . . . . . . 93
13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 92 13.5. EC DH Algorithm (ECDH) . . . . . . . . . . . . . . . . . 94
14. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 94 14. Notes on Algorithms . . . . . . . . . . . . . . . . . . . . . 96
14.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 95 14.1. PKCS#1 Encoding in OpenPGP . . . . . . . . . . . . . . . 97
14.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 95 14.1.1. EME-PKCS1-v1_5-ENCODE . . . . . . . . . . . . . . . 97
14.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 95 14.1.2. EME-PKCS1-v1_5-DECODE . . . . . . . . . . . . . . . 97
14.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 96 14.1.3. EMSA-PKCS1-v1_5 . . . . . . . . . . . . . . . . . . 98
14.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 97 14.2. Symmetric Algorithm Preferences . . . . . . . . . . . . 99
14.3. Other Algorithm Preferences . . . . . . . . . . . . . . 98 14.3. Other Algorithm Preferences . . . . . . . . . . . . . . 100
14.3.1. Compression Preferences . . . . . . . . . . . . . . 98 14.3.1. Compression Preferences . . . . . . . . . . . . . . 100
14.3.2. Hash Algorithm Preferences . . . . . . . . . . . . . 99 14.3.2. Hash Algorithm Preferences . . . . . . . . . . . . . 101
14.4. Plaintext . . . . . . . . . . . . . . . . . . . . . . . 99 14.4. Plaintext . . . . . . . . . . . . . . . . . . . . . . . 101
14.5. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 99 14.5. RSA . . . . . . . . . . . . . . . . . . . . . . . . . . 101
14.6. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . 99 14.6. DSA . . . . . . . . . . . . . . . . . . . . . . . . . . 101
14.7. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 100 14.7. Elgamal . . . . . . . . . . . . . . . . . . . . . . . . 102
14.8. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 100 14.8. EdDSA . . . . . . . . . . . . . . . . . . . . . . . . . 102
14.9. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 100 14.9. Reserved Algorithm Numbers . . . . . . . . . . . . . . . 102
14.10. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 101 14.10. OpenPGP CFB Mode . . . . . . . . . . . . . . . . . . . . 103
14.11. Private or Experimental Parameters . . . . . . . . . . . 102 14.11. Private or Experimental Parameters . . . . . . . . . . . 104
14.12. Meta-Considerations for Expansion . . . . . . . . . . . 102 14.12. Meta-Considerations for Expansion . . . . . . . . . . . 104
15. Security Considerations . . . . . . . . . . . . . . . . . . . 103 15. Security Considerations . . . . . . . . . . . . . . . . . . . 105
16. Compatibility Profiles . . . . . . . . . . . . . . . . . . . 110 16. Compatibility Profiles . . . . . . . . . . . . . . . . . . . 112
16.1. OpenPGP ECC Profile . . . . . . . . . . . . . . . . . . 110 16.1. OpenPGP ECC Profile . . . . . . . . . . . . . . . . . . 112
16.2. Suite-B Profile . . . . . . . . . . . . . . . . . . . . 110 16.2. Suite-B Profile . . . . . . . . . . . . . . . . . . . . 112
16.2.1. Security Strength at 192 Bits . . . . . . . . . . . 110 16.2.1. Security Strength at 192 Bits . . . . . . . . . . . 112
16.2.2. Security Strength at 128 Bits . . . . . . . . . . . 111 16.2.2. Security Strength at 128 Bits . . . . . . . . . . . 113
17. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 111 17. Implementation Nits . . . . . . . . . . . . . . . . . . . . . 113
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 112 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 114
18.1. Normative References . . . . . . . . . . . . . . . . . . 112 18.1. Normative References . . . . . . . . . . . . . . . . . . 114
18.2. Informative References . . . . . . . . . . . . . . . . . 115 18.2. Informative References . . . . . . . . . . . . . . . . . 117
Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 116 Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 118
A.1. Sample EdDSA key . . . . . . . . . . . . . . . . . . . . 116 A.1. Sample EdDSA key . . . . . . . . . . . . . . . . . . . . 118
A.2. Sample EdDSA signature . . . . . . . . . . . . . . . . . 117 A.2. Sample EdDSA signature . . . . . . . . . . . . . . . . . 119
A.3. Sample AEAD-EAX encryption and decryption . . . . . . . . 117 A.3. Sample AEAD-EAX encryption and decryption . . . . . . . . 119
A.3.1. Sample Parameters . . . . . . . . . . . . . . . . . . 117 A.3.1. Sample Parameters . . . . . . . . . . . . . . . . . . 119
A.3.2. Sample symmetric-key encrypted session key packet A.3.2. Sample symmetric-key encrypted session key packet
(v5) . . . . . . . . . . . . . . . . . . . . . . . . 118 (v5) . . . . . . . . . . . . . . . . . . . . . . . . 120
A.3.3. Starting AEAD-EAX decryption of CEK . . . . . . . . . 118 A.3.3. Starting AEAD-EAX decryption of CEK . . . . . . . . . 120
A.3.4. Sample AEAD encrypted data packet . . . . . . . . . . 119 A.3.4. Sample AEAD encrypted data packet . . . . . . . . . . 121
A.3.5. Decryption of data . . . . . . . . . . . . . . . . . 119 A.3.5. Decryption of data . . . . . . . . . . . . . . . . . 121
A.3.6. Complete AEAD-EAX encrypted packet sequence . . . . . 120 A.3.6. Complete AEAD-EAX encrypted packet sequence . . . . . 122
A.4. Sample AEAD-OCB encryption and decryption . . . . . . . . 120 A.4. Sample AEAD-OCB encryption and decryption . . . . . . . . 122
A.4.1. Sample Parameters . . . . . . . . . . . . . . . . . . 120 A.4.1. Sample Parameters . . . . . . . . . . . . . . . . . . 122
A.4.2. Sample symmetric-key encrypted session key packet A.4.2. Sample symmetric-key encrypted session key packet
(v5) . . . . . . . . . . . . . . . . . . . . . . . . 121 (v5) . . . . . . . . . . . . . . . . . . . . . . . . 123
A.4.3. Starting AEAD-EAX decryption of CEK . . . . . . . . . 121 A.4.3. Starting AEAD-OCB decryption of CEK . . . . . . . . . 123
A.4.4. Sample AEAD encrypted data packet . . . . . . . . . . 121 A.4.4. Sample AEAD encrypted data packet . . . . . . . . . . 123
A.4.5. Decryption of data . . . . . . . . . . . . . . . . . 122 A.4.5. Decryption of data . . . . . . . . . . . . . . . . . 124
A.4.6. Complete AEAD-OCB encrypted packet sequence . . . . . 123 A.4.6. Complete AEAD-OCB encrypted packet sequence . . . . . 125
Appendix B. ECC Point compression flag bytes . . . . . . . . . . 123 Appendix B. ECC Point compression flag bytes . . . . . . . . . . 125
Appendix C. Changes since RFC-4880 . . . . . . . . . . . . . . . 123 Appendix C. Changes since RFC-4880 . . . . . . . . . . . . . . . 125
Appendix D. The principal authors of RFC-4880 . . . . . . . . . 124 Appendix D. The principal authors of RFC-4880 . . . . . . . . . 127
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 127
1. Introduction 1. Introduction
{ This is work in progress to update OpenPGP. Editorial notes are { This is work in progress to update OpenPGP. Editorial notes are
enclosed in curly braces. } 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 4880, "OpenPGP and key management functions. It is a revision of RFC 4880, "OpenPGP
Message Format", which is a revision of RFC 2440, which itself Message Format", which is a revision of RFC 2440, which itself
skipping to change at page 21, line 21 skipping to change at page 21, line 21
the claim of identity. the claim of identity.
0x13 Positive certification of a User ID and Public-Key packet. The 0x13 Positive certification of a User ID and Public-Key packet. The
issuer of this certification has done substantial verification of issuer of this certification has done substantial verification of
the claim of identity. the claim of identity.
Most OpenPGP implementations make their "key signatures" as 0x10 Most OpenPGP implementations make their "key signatures" as 0x10
certifications. Some implementations can issue 0x11-0x13 certifications. Some implementations can issue 0x11-0x13
certifications, but few differentiate between the types. certifications, but few differentiate between the types.
0x16 Attestion Key Signature. This signature is issued by the
primary key over itself and its user ID (or user attribute). It
MUST contain an "Attested Certifications" subpacket and a
"Signature Creation Time" subpacket. This type of key signature
does not replace or override any standard certification
(0x10-0x13).
Only the most recent Attestation Key Signature is valid for any
given <key,userid> pair. If more than one Certification
Attestation Key Signature is present with the same Signature
Creation Time, the set of attestations should be treated as the
union of all "Attested Certifications" subpackets from all such
signatures with the same timestamp.
0x18 Subkey Binding Signature. This signature is a statement by the 0x18 Subkey Binding Signature. This signature is a statement by the
top-level signing key that indicates that it owns the subkey. top-level signing key that indicates that it owns the subkey.
This signature is calculated directly on the primary key and This signature is calculated directly on the primary key and
subkey, and not on any User ID or other packets. A signature that subkey, and not on any User ID or other packets. A signature that
binds a signing subkey MUST have an Embedded Signature subpacket binds a signing subkey MUST have an Embedded Signature subpacket
in this binding signature that contains a 0x19 signature made by in this binding signature that contains a 0x19 signature made by
the signing subkey on the primary key and subkey. the signing subkey on the primary key and subkey.
0x19 Primary Key Binding Signature. This signature is a statement 0x19 Primary Key Binding Signature. This signature is a statement
by a signing subkey, indicating that it is owned by the primary by a signing subkey, indicating that it is owned by the primary
skipping to change at page 28, line 39 skipping to change at page 28, line 39
| 25 | Primary User ID | | 25 | Primary User ID |
| 26 | Policy URI | | 26 | Policy URI |
| 27 | Key Flags | | 27 | Key Flags |
| 28 | Signer's User ID | | 28 | Signer's User ID |
| 29 | Reason for Revocation | | 29 | Reason for Revocation |
| 30 | Features | | 30 | Features |
| 31 | Signature Target | | 31 | Signature Target |
| 32 | Embedded Signature | | 32 | Embedded Signature |
| 33 | Issuer Fingerprint | | 33 | Issuer Fingerprint |
| 34 | Preferred AEAD Algorithms | | 34 | Preferred AEAD Algorithms |
| 35 | Intended Recipient Fingerprint |
| 37 | Attested Certifications |
| 100 to 110 | Private or experimental | | 100 to 110 | Private or experimental |
+-------------+-----------------------------------------+ +-------------+-----------------------------------------+
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 is of the signature to recognize. If a subpacket is encountered that is
marked critical but is unknown to the evaluating software, the marked critical but is unknown to the evaluating software, the
skipping to change at page 37, line 8 skipping to change at page 37, line 8
Due to its nature a 'hash' notation is not human readable and MUST Due to its nature a 'hash' notation is not human readable and MUST
NOT be marked as such when used. NOT be marked as such when used.
5.2.3.18. Key Server Preferences 5.2.3.18. Key Server Preferences
(N octets of flags) (N octets of flags)
This is a list of one-bit flags that indicate preferences that the This is a list of one-bit flags that indicate preferences that the
key holder has about how the key is handled on a key server. All key holder has about how the key is handled on a key server. All
undefined flags MUST be zero. undefined flags MUST be zero.
First octet: 0x80 = No-modify the key holder requests that this key First octet: 0x80 = No-modify
only be modified or updated by the key holder or an administrator of
the key server. The key holder requests that this key only be modified or updated
by the key holder or an administrator of the key server.
If No-modify is set on the most recent self-sig over a user ID,
then a keyserver should only redistribute those third-party
certifications over that user ID that have been attested to in the
most recent Attestation Key Signature packet (see "Attested
Certifications" below).
This is found only on a self-signature. This is found only on a self-signature.
5.2.3.19. Preferred Key Server 5.2.3.19. Preferred Key Server
(String) (String)
This is a URI of a key server that the key holder prefers be used for This is a URI of a key server that the key holder prefers be used for
updates. Note that keys with multiple User IDs can have a preferred updates. Note that keys with multiple User IDs can have a preferred
key server for each User ID. Note also that since this is a URI, the key server for each User ID. Note also that since this is a URI, the
skipping to change at page 41, line 36 skipping to change at page 42, line 4
(1 signature packet body) (1 signature packet body)
This subpacket contains a complete Signature packet body as specified This subpacket contains a complete Signature packet body as specified
in Section 5.2 above. It is useful when one signature needs to refer in Section 5.2 above. It is useful when one signature needs to refer
to, or be incorporated in, another signature. to, or be incorporated in, another signature.
5.2.3.28. Issuer Fingerprint 5.2.3.28. Issuer Fingerprint
(1 octet key version number, N octets of fingerprint) (1 octet key version number, N octets of fingerprint)
The OpenPGP Key fingerprint of the key issuing the signature. This The OpenPGP Key fingerprint of the key issuing the signature. This
subpacket SHOULD be included in all signatures. If the version of subpacket SHOULD be included in all signatures. If the version of
the issuing key is 4 and an Issuer subpacket is also included in the the issuing key is 4 and an Issuer subpacket is also included in the
signature, the key ID of the Issuer subpacket MUST match the low 64 signature, the key ID of the Issuer subpacket MUST match the low 64
bits of the fingerprint. bits of the fingerprint.
Note that the length N of the fingerprint for a version 4 key is 20 Note that the length N of the fingerprint for a version 4 key is 20
octets; for a version 5 key N is 32. octets; for a version 5 key N is 32.
5.2.3.29. Intended Recipient Fingerprint
(1 octet key version number, N octets of fingerprint)
The OpenPGP Key fingerprint of the intended recipient primary key.
If one or more subpackets of this type are included in a signature,
it SHOULD be considered valid only in an encrypted context, where the
key it was encrypted to is one of the indicated primary keys, or one
of their subkeys. This can be used to prevent forwarding a signature
outside of its intended, encrypted context.
Note that the length N of the fingerprint for a version 4 key is 20
octets; for a version 5 key N is 32.
5.2.3.30. Attested Certifications
(N octets of certification digests)
This subpacket MUST only appear as a hashed subpacket of an
Attestation Key Signature. It has no meaning in any other signature
type. It is used by the primary key to attest to a set of third-
party certifications over the associated User ID or User Attribute.
This enables the holder of an OpenPGP primary key to mark specific
third-party certifications as re-distributable with the rest of the
Transferable Public Key (see the "No-modify" flag in "Key Server
Preferences", above). Implementations MUST include exactly one
Attested Certification subpacket in any generated Attestation Key
Signature.
The contents of the subpacket consists of a series of digests using
the same hash algorithm used by the signature itself. Each digest is
made over one third-party signature (any Certification, i.e.,
signature type 0x10-0x13) that covers the same Primary Key and User
ID (or User Attribute). For example, an Attestation Key Signature
made by key X over user ID U using hash algorithm SHA256 might
contain an Attested Certifications subpacket of 192 octets (6*32
octets) covering six third-party certification Signatures over <X,U>.
They SHOULD be ordered by binary hash value from low to high (e.g., a
hash with hexadecimal value 037a... precedes a hash with value
0392..., etc). The length of this subpacket MUST be an integer
multiple of the length of the hash algorithm used for the enclosing
Attestation Key Signature.
The listed digests MUST be calculated over the third-party
certification's Signature packet as described in the "Computing
Signatures" section, but without a trailer: the hash data starts with
the octet 0x88, followed by the four-octet length of the Signature,
and then the body of the Signature packet. (Note that this is an
old-style packet header for a Signature packet with the length-of-
length field set to zero.) The unhashed subpacket data of the
Signature packet being hashed is not included in the hash, and the
unhashed subpacket data length value is set to zero.
If an implementation encounters more than one such subpacket in an
Attestation Key Signature, it MUST treat it as a single Attested
Certifications subpacket containing the union of all hashes.
The Attested Certifications subpacket in the most recent Attestation
Key Signature over a given user ID supersedes all Attested
Certifications subpackets from any previous Attestation Key
Signature. However, note that if more than one Attestation Key
Signatures has the same (most recent) Signature Creation Time
subpacket, implementations MUST consider the union of the
attestations of all Attestation Key Signatures (this allows the
keyholder to attest to more third-party certifications than could fit
in a single Attestation Key Signature).
If a keyholder Alice has already attested to third-party
certifications from Bob and Carol and she wants to add an attestation
to a certification from David, she should issue a new Attestation Key
Signature (with a more recent Signature Creation timestamp) that
contains an Attested Certifications subpacket covering all three
third-party certifications.
If she later decides that she does not want Carol's certification to
be redistributed with her certificate, she can issue a new
Attestation Key Signature (again, with a more recent Signature
Creation timestamp) that contains an Attested Certifications
subpacket covering only the certifications from Bob and David.
Note that Certification Revocation Signatures are not relevant for
Attestation Key Signatures. To rescind all attestations, the primary
key holder needs only to publish a more recent Attestation Key
Signature with an empty Attested Certifications subpacket.
5.2.4. Computing Signatures 5.2.4. Computing Signatures
All signatures are formed by producing a hash over the signature All signatures are formed by producing a hash over the signature
data, and then using the resulting hash in the signature algorithm. data, and then using the resulting hash in the signature algorithm.
For binary document signatures (type 0x00), the document data is For binary document signatures (type 0x00), the document data is
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.
skipping to change at page 42, line 28 skipping to change at page 44, line 36
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 or V5 certification hashes packet packet, without any header. A V4 or V5 certification hashes
the constant 0xB4 for User ID certifications or the constant 0xD1 for the 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.
An Attestation Key Signature (0x16) hashes the same data boy that a
standard certification signature does: primary key, followed by User
ID or User Attribute.
When a signature is made over a Signature packet (type 0x50, "Third- When a signature is made over a Signature packet (type 0x50, "Third-
Party Confirmation signature"), the hash data starts with the octet Party Confirmation signature"), the hash data starts with the octet
0x88, followed by the four-octet length of the signature, and then 0x88, followed by the four-octet length of the signature, and then
the body of the Signature packet. (Note that this is an old-style the body of the Signature packet. (Note that this is an old-style
packet header for a Signature packet with the length-of-length field packet header for a Signature packet with the length-of-length field
set to zero.) The unhashed subpacket data of the Signature packet set to zero.) The unhashed subpacket data of the Signature packet
being hashed is not included in the hash, and the unhashed subpacket being hashed is not included in the hash, and the unhashed subpacket
data length value is set to zero. data length value is set to zero.
Once the data body is hashed, then a trailer is hashed. This trailer Once the data body is hashed, then a trailer is hashed. This trailer
skipping to change at page 62, line 31 skipping to change at page 64, line 36
Note also that unlike nearly every other OpenPGP subsystem, Note also that unlike nearly every other OpenPGP subsystem,
there are no parameters in the MDC system. It hard-defines there are no parameters in the MDC system. It hard-defines
SHA-1 as its hash function. This is not an accident. It is an SHA-1 as its hash function. This is not an accident. It is an
intentional choice to avoid downgrade and cross-grade attacks intentional choice to avoid downgrade and cross-grade attacks
while making a simple, fast system. (A downgrade attack would while making a simple, fast system. (A downgrade attack would
be an attack that replaced SHA2-256 with SHA-1, for example. A be an attack that replaced SHA2-256 with SHA-1, for example. A
cross-grade attack would replace SHA-1 with another 160-bit cross-grade attack would replace SHA-1 with another 160-bit
hash, such as RIPE-MD/160, for example.) hash, such as RIPE-MD/160, for example.)
However, no update will be needed becuase the MDC will be However, no update will be needed because the MDC will be
replaced by the AEAD encryption described in this document. replaced by the AEAD encryption described in this document.
5.15. Modification Detection Code Packet (Tag 19) 5.15. 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
plaintext data, which is used to detect message modification. It is plaintext data, which is used to detect message modification. It is
only used with a Symmetrically Encrypted Integrity Protected Data only used with a Symmetrically Encrypted Integrity Protected Data
packet. The Modification Detection Code packet MUST be the last packet. The Modification Detection Code packet MUST be the last
packet in the plaintext data that is encrypted in the Symmetrically packet in the plaintext data that is encrypted in the Symmetrically
Encrypted Integrity Protected Data packet, and MUST appear in no Encrypted Integrity Protected Data packet, and MUST appear in no
skipping to change at page 64, line 12 skipping to change at page 66, line 18
size octet, and an eight-octet, big-endian chunk index as additional size octet, and an eight-octet, big-endian chunk index as additional
data. The index of the first chunk is zero. For example, the data. The index of the first chunk is zero. For example, the
additional data of the first chunk using EAX and AES-128 with a chunk additional data of the first chunk using EAX and AES-128 with a chunk
size of 64 kiByte consists of the octets 0xD4, 0x01, 0x07, 0x01, size of 64 kiByte consists of the octets 0xD4, 0x01, 0x07, 0x01,
0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, and 0x00. 0x10, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, and 0x00.
After the final chunk, the AEAD algorithm is used to produce a final After the final chunk, the AEAD algorithm is used to produce a final
authentication tag encrypting the empty string. This AEAD instance authentication tag encrypting the empty string. This AEAD instance
is given the additional data specified above, plus an eight-octet, is given the additional data specified above, plus an eight-octet,
big-endian value specifying the total number of plaintext octets big-endian value specifying the total number of plaintext octets
encrypted. This allows detection of a truncated ciphertext. encrypted. This allows detection of a truncated ciphertext. Please
note that the big-endian number representing the chunk index in the
additional data is increased accordingly, although it's not really a
chunk.
The chunk size octet specifies the size of chunks using the following The chunk size octet specifies the size of chunks using the following
formula (in C), where c is the chunk size octet: formula (in C), where c is the chunk size octet:
chunk_size = ((uint64_t)1 << (c + 6)) chunk_size = ((uint64_t)1 << (c + 6))
An implementation MUST support chunk size octets with values from 0 An implementation MUST support chunk size octets with values from 0
to 56. Chunk size octets with other values are reserved for future to 56. Chunk size octets with other values are reserved for future
extensions. Implementations SHOULD NOT create data with a chunk size extensions. Implementations SHOULD NOT create data with a chunk size
octet value larger than 21 (128 MiB chunks) to facilitate buffering octet value larger than 21 (128 MiB chunks) to facilitate buffering
skipping to change at page 66, line 16 skipping to change at page 68, line 24
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"
<CODE BEGINS> <CODE BEGINS>
#define CRC24_INIT 0xB704CEL #define CRC24_INIT 0xB704CEL
#define CRC24_POLY 0x1864CFBL #define CRC24_POLY 0x864CFBL
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;
skipping to change at page 84, line 26 skipping to change at page 86, line 26
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 as follows: transferable public key are as follows:
o One Public-Key packet o One Public-Key packet
o Zero or more revocation signatures o Zero or more revocation signatures
o Zero or more User ID packets o Zero or more User ID packets
o After each User ID packet, zero or more Signature packets o After each User ID packet, zero or more Signature packets
(certifications) (certifications and attestation key signatures)
o Zero or more User Attribute packets o Zero or more User Attribute packets
o After each User Attribute packet, zero or more Signature packets o After each User Attribute packet, zero or more Signature packets
(certifications) (certifications and attestation key signatures)
o Zero or more Subkey packets o Zero or more Subkey packets
o After each Subkey packet, one Signature packet, plus optionally a o After each Subkey packet, one Signature packet, plus optionally a
revocation revocation
The Public-Key packet occurs first. Each of the following User ID The Public-Key packet occurs first. Each of the following User ID
packets provides the identity of the owner of this public key. If packets provides the identity of the owner of this public key. If
there are multiple User ID packets, this corresponds to multiple there are multiple User ID packets, this corresponds to multiple
means of identifying the same unique individual user; for example, a means of identifying the same unique individual user; for example, a
user may have more than one email address, and construct a User ID user may have more than one email address, and construct a User ID
for each one. for each one.
Immediately following each User ID packet, there are zero or more Immediately following each User ID packet, there are zero or more
Signature packets. Each Signature packet is calculated on the Signature packets. Each Signature packet is calculated on the
immediately preceding User ID packet and the initial Public-Key immediately preceding User ID packet and the initial Public-Key
packet. The signature serves to certify the corresponding public key packet. The signature serves to certify the corresponding public key
and User ID. In effect, the signer is testifying to his or her and User ID. In effect, the signer is testifying to his or her
belief that this public key belongs to the user identified by this belief that this public key belongs to the user identified by this
User ID. User ID. Intermixed with these certifications may be Attestation Key
Signature packets issued by the primary key over the same User ID and
Public Key packet. The most recent of these is used to attest to
third-party certifications over the associated User ID.
Within the same section as the User ID packets, there are zero or Within the same section as the User ID packets, there are zero or
more User Attribute packets. Like the User ID packets, a User more User Attribute packets. Like the User ID packets, a User
Attribute packet is followed by zero or more Signature packets Attribute packet is followed by zero or more Signature packets
calculated on the immediately preceding User Attribute packet and the calculated on the immediately preceding User Attribute packet and the
initial Public-Key packet. initial Public-Key packet.
User Attribute packets and User ID packets may be freely intermixed User Attribute packets and User ID packets may be freely intermixed
in this section, so long as the signatures that follow them are in this section, so long as the signatures that follow them are
maintained on the proper User Attribute or User ID packet. maintained on the proper User Attribute or User ID packet.
skipping to change at page 119, line 11 skipping to change at page 121, line 11
Decrypted CEK: Decrypted CEK:
86 f1 ef b8 69 52 32 9f 24 ac d3 bf d0 e5 34 6d 86 f1 ef b8 69 52 32 9f 24 ac d3 bf d0 e5 34 6d
A.3.4. Sample AEAD encrypted data packet A.3.4. Sample AEAD encrypted data packet
Packet header: Packet header:
d4 4a d4 4a
Version, EAX, AES-128, Chunk bits (14): Version, AES-128, EAX, Chunk bits (14):
01 07 01 0e 01 07 01 0e
IV: IV:
b7 32 37 9f 73 c4 92 8d e2 5f ac fe 65 17 ec 10 b7 32 37 9f 73 c4 92 8d e2 5f ac fe 65 17 ec 10
AEAD-EAX Encrypted data chunk #0: AEAD-EAX Encrypted data chunk #0:
5d c1 1a 81 dc 0c b8 a2 f6 f3 d9 00 16 38 4a 56 5d c1 1a 81 dc 0c b8 a2 f6 f3 d9 00 16 38 4a 56
skipping to change at page 121, line 27 skipping to change at page 123, line 27
99 e3 26 e5 40 0a 90 93 6c ef b4 e8 eb a0 8c 99 e3 26 e5 40 0a 90 93 6c ef b4 e8 eb a0 8c
AEAD encrypted CEK: AEAD encrypted CEK:
67 73 71 6d 1f 27 14 54 0a 38 fc ac 52 99 49 da 67 73 71 6d 1f 27 14 54 0a 38 fc ac 52 99 49 da
Authentication tag: Authentication tag:
c5 29 d3 de 31 e1 5b 4a eb 72 9e 33 00 33 db ed c5 29 d3 de 31 e1 5b 4a eb 72 9e 33 00 33 db ed
A.4.3. Starting AEAD-EAX decryption of CEK A.4.3. Starting AEAD-OCB decryption of CEK
The derived key is: The derived key is:
eb 9d a7 8a 9d 5d f8 0e c7 02 05 96 39 9b 65 08 eb 9d a7 8a 9d 5d f8 0e c7 02 05 96 39 9b 65 08
Authenticated Data: Authenticated Data:
c3 05 07 02 c3 05 07 02
Nonce: Nonce:
skipping to change at page 121, line 51 skipping to change at page 123, line 51
Decrypted CEK: Decrypted CEK:
d1 f0 1b a3 0e 13 0a a7 d2 58 2c 16 e0 50 ae 44 d1 f0 1b a3 0e 13 0a a7 d2 58 2c 16 e0 50 ae 44
A.4.4. Sample AEAD encrypted data packet A.4.4. Sample AEAD encrypted data packet
Packet header: Packet header:
d4 49 d4 49
Version, EAX, AES-128, Chunk bits (14): Version, AES-128, OCB, Chunk bits (14):
01 07 02 0e 01 07 02 0e
IV: IV:
5e d2 bc 1e 47 0a be 8f 1d 64 4c 7a 6c 8a 56 5e d2 bc 1e 47 0a be 8f 1d 64 4c 7a 6c 8a 56
AEAD-EAX Encrypted data chunk #0: AEAD-OCB Encrypted data chunk #0:
7b 0f 77 01 19 66 11 a1 54 ba 9c 25 74 cd 05 62 7b 0f 77 01 19 66 11 a1 54 ba 9c 25 74 cd 05 62
84 a8 ef 68 03 5c 84 a8 ef 68 03 5c
Chunk #0 authentication tag: Chunk #0 authentication tag:
62 3d 93 cc 70 8a 43 21 1b b6 ea f2 b2 7f 7c 18 62 3d 93 cc 70 8a 43 21 1b b6 ea f2 b2 7f 7c 18
Final (zero-size chunk #1) authentication tag: Final (zero-size chunk #1) authentication tag:
skipping to change at page 124, line 45 skipping to change at page 126, line 45
o Suggest limitation of the AEAD chunksize to 128 MiB. o Suggest limitation of the AEAD chunksize to 128 MiB.
o Specified the V5 signature format. o Specified the V5 signature format.
o Deprectated the creation of V3 signatures. o Deprectated the creation of V3 signatures.
o Adapted terms from RFC 8126. o Adapted terms from RFC 8126.
o Removed editorial marks and updated cross-references. o Removed editorial marks and updated cross-references.
o Added the timestamping usage key flag.
o Added Intended Recipient signature subpacket.
o Added Attested Certifications signature subpacket and signature
class.
{ Informational rfcs: [RFC1423] } { Informational rfcs: [RFC1423] }
Appendix D. The principal authors of RFC-4880 Appendix D. The principal authors of RFC-4880
Jon Callas Jon Callas
EMail: jon@callas.org EMail: jon@callas.org
Lutz Donnerhacke Lutz Donnerhacke
EMail: lutz@iks-jena.de EMail: lutz@iks-jena.de
Hal Finney Hal Finney
David Shaw David Shaw
EMail: dshaw@jabberwocky.com EMail: dshaw@jabberwocky.com
skipping to change at line 5806 skipping to change at page 128, line 4
Suite 1111, 1 Pedder Street Suite 1111, 1 Pedder Street
Central, Hong Kong Central, Hong Kong
Hong Kong Hong Kong
Email: ronald.tse@ribose.com Email: ronald.tse@ribose.com
URI: https://www.ribose.com URI: https://www.ribose.com
Derek Atkins Derek Atkins
Email: derek@ihtfp.com Email: derek@ihtfp.com
Daniel Kahn Gillmor
Email: dkg@fifthhorseman.net
 End of changes. 28 change blocks. 
141 lines changed or deleted 267 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/