<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.23 (Ruby 3.1.3) --> encoding="utf-8"?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
<!ENTITY zwsp "​">
<!ENTITY nbhy "‑">
<!ENTITY wj "⁠">
]>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
ipr="pre5378Trust200902"
docName="draft-ietf-openpgp-crypto-refresh-13"
number="9580"
category="std"
consensus="true"
submissionType="IETF"
obsoletes="4880, 5581, 6637" tocDepth="4"
updates=""
tocInclude="true"
tocDepth="4"
sortRefs="true" symRefs="true">
symRefs="true"
xml:lang="en"
version="3">
<front>
<title>OpenPGP</title>
<title abbrev="OpenPGP">OpenPGP</title>
<seriesInfo name="RFC" value="9580"/>
<author initials="P." surname="Wouters" fullname="Paul Wouters" role="editor">
<organization>Aiven</organization>
<address>
<email>paul.wouters@aiven.io</email>
</address>
</author>
<author initials="D." surname="Huigens" fullname="Daniel Huigens">
<organization>Proton AG</organization>
<address>
<email>d.huigens@protonmail.com</email>
</address>
</author>
<author initials="J." surname="Winter" fullname="Justus Winter">
<organization>Sequoia-PGP</organization>
<address>
<email>justus@sequoia-pgp.org</email>
</address>
</author>
<author initials="Y." surname="Niibe" fullname="Yutaka Niibe">
<organization>FSIJ</organization>
<address>
<email>gniibe@fsij.org</email>
</address>
</author>
<date year="2024" month="January" day="04"/> month="May"/>
<area>sec</area>
<workgroup>Network Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<workgroup>openpgp</workgroup>
<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->
<abstract>
<t>This document specifies the message formats used in OpenPGP.
OpenPGP provides encryption with public-key or symmetric cryptographic algorithms, digital signatures, compression compression, and key management.</t>
<t>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</t>
<t>This document obsoletes:
<!-- [rfced] In the Abstract, we updated the following text to
reflect the full titles of the RFCs listed for clarity. In the
Introduction (which contains the same text), we left the
abbreviated titles since the title of RFC 4880 is already
included in the preceding paragraph. Please let us know if this
is agreeable or if you would like the full titles to be included
in the Introduction as well.
Original:
This document obsoletes RFCs 4880 (OpenPGP), RFC 5581 (Camellia
in OpenPGP) OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP).</t>
</abstract>
<note title="About OpenPGP).
Current:
This Document" removeInRFC="true">
<t>
The latest revision of this draft can be found at <eref target="https://openpgp-wg.gitlab.io/rfc4880bis/"/>.
Status information for this document may be found at <eref target="https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/"/>.
</t>
<t>
Discussion of this obsoletes RFCs 4880 ("OpenPGP Message Format"),
5581 ("The Camellia Cipher in OpenPGP"), and 6637 ("Elliptic
Curve Cryptography (ECC) in OpenPGP").
-->
<t>This document takes place on the
OpenPGP Working Group mailing list (<eref target="mailto:openpgp@ietf.org"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/openpgp/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/openpgp/"/>.
</t>
<t>Source for this draft obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("The Camellia Cipher in OpenPGP"), and an issue tracker can be found at
<eref target="https://gitlab.com/openpgp-wg/rfc4880bis"/>.</t>
</note> 6637 ("Elliptic Curve Cryptography (ECC) in OpenPGP").</t>
</abstract>
</front>
<middle>
<section anchor="introduction"><name>Introduction</name> anchor="introduction">
<name>Introduction</name>
<t>This document provides information on the message-exchange packet formats used by OpenPGP to provide encryption, decryption, signing, and key management functions.
It is a revision of RFC 4880, "OpenPGP <xref target="RFC4880"/> ("OpenPGP Message Format", Format"), which is a revision of RFC 2440, <xref target="RFC2440"/>, which itself replaces RFC 1991, "PGP Message Exchange Formats" <xref target="RFC1991"/> <xref target="RFC2440"/> <xref target="RFC4880"/>.</t> ("PGP Message Exchange Formats").</t>
<t>This document obsoletes: obsoletes <xref target="RFC4880"/> (OpenPGP), <xref target="RFC5581"/> (Camellia in OpenPGP) OpenPGP), and <xref target="RFC6637"/> (Elliptic Curves in OpenPGP).
This document incorporates all - at At the time of writing - writing, this document incorporates all outstanding verified errata errata, which are listed in <xref target="errata-listing"/>.</t>
<t>Software that has already implemented those previous standards specifications may want to review <xref target="upgrade-guidance"/> for pointers to what has changed.</t>
<section anchor="terms"><name>Terms</name> anchor="terms">
<name>Terms</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
<t>The key words "PRIVATE USE", "SPECIFICATION <bcp14>REQUIRED</bcp14>", "Private Use", "Specification Required", and "RFC <bcp14>REQUIRED</bcp14>" Required" that appear in this document when used to describe namespace allocation are to be interpreted as described in <xref target="RFC8126"/>.</t>
<t>Some terminology used in this document has been improved from previous versions of the OpenPGP specification.
See <xref target="terminology-changes"/> for more details.</t>
</section>
</section>
<section anchor="general-functions"><name>General functions</name> anchor="general-functions">
<name>General Functions</name>
<t>OpenPGP provides data confidentiality and integrity for messages and data files by using public-key and/or symmetric encryption, encryption and digital signatures.
It provides formats for encoding and transferring encrypted and/or signed messages.
In addition, OpenPGP provides functionality for encoding and transferring keys and certificates, though key storage and management is are beyond the scope of this document.</t>
<section anchor="confidentiality-via-encryption"><name>Confidentiality anchor="confidentiality-via-encryption">
<name>Confidentiality via Encryption</name>
<t>OpenPGP combines symmetric-key encryption and (optionally) public-key encryption to provide confidentiality.
When using public keys, first the object is encrypted using a symmetric encryption algorithm.
Each symmetric key is used only once, for a single object.
A new "session key" is generated as a random number for each object (sometimes referred to as a session). "session").
Since it is used only once, the session key is bound to the message and transmitted with it.
To protect the key, it is encrypted with the receiver's public key.
The sequence is as follows:</t>
<t><list style="numbers">
<t>The
<ol spacing="normal" type="1"><li>
The sender creates a message.</t>
<t>The message.
</li>
<li>The sending OpenPGP implementation generates a random session key for this message.</t>
<t>The message.
</li>
<li>The session key is encrypted using each recipient's public key.
These "encrypted session keys" start the message.</t>
<t>The message.
</li>
<li>The sending OpenPGP implementation optionally compresses the message, message and then encrypts it using a message key derived from the session key.
The encrypted message forms the remainder of the OpenPGP message.</t>
<t>The message.
</li>
<li>The receiving OpenPGP implementation decrypts the session key using the recipient's private key.</t>
<t>The key.
</li>
<li>The receiving OpenPGP implementation decrypts the message using the message key derived from the session key.
If the message was compressed, it will be decompressed.</t>
</list></t> decompressed.
</li>
</ol>
<t>When using symmetric-key encryption, a similar process as described above is used, but the session key is encrypted with a symmetric algorithm derived from a shared secret.</t>
<t>Both digital signature and confidentiality services may be applied to the same message.
First, a signature is generated for the message and attached to the message.
Then
Then, the message plus signature is encrypted using a symmetric message key derived from the session key.
Finally, the session key is encrypted using public-key encryption and prefixed to the encrypted block.</t>
</section>
<section anchor="authentication-via-digital-signature"><name>Authentication anchor="authentication-via-digital-signature">
<name>Authentication via Digital Signature</name>
<t>The digital signature uses a cryptographic hash function and a public-key signature algorithm.
The sequence is as follows:</t>
<t><list style="numbers">
<t>The
<ol spacing="normal" type="1"><li>
The sender creates a message.</t>
<t>The message.
</li>
<li>The sending implementation generates a hash digest of the message.</t>
<t>The message.
</li>
<li>The sending implementation generates a signature from the hash digest using the sender's private key.</t>
<t>The key.
</li>
<li>The signature is attached to or transmitted alongside the message.</t>
<t>The message.
</li>
<li>The receiving implementation obtains a copy of the message and the message signature.</t>
<t>The signature.
</li>
<li>The receiving implementation generates a new hash digest for the received message and verifies it using the message's signature.
If the verification is successful, the message is accepted as authentic.</t>
</list></t> authentic.
</li>
</ol>
</section>
<section anchor="compression"><name>Compression</name> anchor="compression">
<name>Compression</name>
<t>An OpenPGP implementation <bcp14>MAY</bcp14> support the compression of data.
Many existing OpenPGP messages are compressed.
Implementers, such as those working on constrained implementations that do not want to support compression, might want to consider at least implementing decompression.</t>
</section>
<section anchor="conversion-to-base64"><name>Conversion anchor="conversion-to-base64">
<name>Conversion to Base64</name>
<t>OpenPGP's underlying native representation for encrypted messages, signatures, keys, and certificates is a stream of arbitrary octets.
Some systems only permit the use of blocks consisting of seven-bit, printable text.
For transporting OpenPGP's native raw binary octets through channels that are not safe to transport raw binary data, a printable encoding of these binary octets is defined.
<!-- [rfced] We do not see mention of "ASCII Armor" in Section 6. Was
Section 6.2 intended?
Original:
The raw 8-bit binary octet stream can be converted to a stream of
printable ASCII characters using base64 encoding, encoding in a format called
"ASCII Armor" (see Section 6).
Perhaps:
The raw 8-bit binary octet stream can be converted to a stream of
printable ASCII Armor characters using base64 encoding in a format called
"ASCII Armor" (see Section 6.2).
-->
The raw 8-bit binary octet stream can be converted to a stream of printable ASCII characters using base64 encoding in a format called "ASCII Armor" (see <xref target="base64"/>).</t>
<t>Implementations <bcp14>SHOULD</bcp14> support base64 conversions.</t>
</section>
<section anchor="signature-only-applications"><name>Signature-Only anchor="signature-only-applications">
<name>Signature-Only Applications</name>
<t>OpenPGP is designed for applications that use both encryption and signatures, but there are a number of use cases that only require a signature-only implementation.
Although this specification requires both encryption and signatures, it is reasonable for there to be subset implementations that are non-conformant only in that they omit encryption support.</t>
</section>
</section>
<section anchor="data-element-formats"><name>Data anchor="data-element-formats">
<name>Data Element Formats</name>
<t>This section describes the data elements used by OpenPGP.</t>
<section anchor="scalar-numbers"><name>Scalar anchor="scalar-numbers">
<name>Scalar Numbers</name>
<t>Scalar numbers are unsigned and are always stored in big-endian format.
Using n[k] to refer to the kth octet being interpreted, the value of a two-octet scalar is ((n[0] << 8) + n[1]).
The value of a four-octet scalar is ((n[0] << 24) + (n[1] << 16) + (n[2] << 8) + n[3]).</t>
</section>
<section anchor="mpi"><name>Multiprecision anchor="mpi">
<name>Multiprecision Integers</name>
<t>Multiprecision integers (also called MPIs) Integers (MPIs) are unsigned integers used to hold large integers such as the ones used in cryptographic calculations.</t>
<t>An MPI consists of two pieces: a two-octet scalar that is the length of the MPI in bits bits, followed by a string of octets that contain the actual integer.</t>
<t>These octets form a big-endian number; a big-endian number can be made into an MPI by prefixing it with the appropriate length.</t>
<t>Examples:</t>
<t>(all
<t>(Note that all numbers in the octet strings identified by square brackets are in hexadecimal)</t>
<t>The hexadecimal.)</t>
<ul empty="true">
<li>The string of octets [00 00] forms an MPI with the value 0.
The 0.</li>
<li>The string of octets [00 01 01] forms an MPI with the value 1.
The 1.</li>
<li>The string [00 09 01 FF] forms an MPI with the value of 511.</t> 511.</li>
</ul>
<t>Additional rules:</t>
<t>The
<ul>
<li>The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.</t>
<t>The octets.</li>
<li>The length field of an MPI describes the length starting from its most significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly.
It should be [00 01 01]. When parsing an MPI in a v6 Key, Signature, or Public-Key Encrypted Session Key (PKESK) packet, the implementation <bcp14>MUST</bcp14> check that the encoded length matches the length starting from the most significant non-zero bit, and bit; if it doesn't match, reject the packet as malformed if not.</t>
<t>Unused malformed.</li>
<li>Unused bits of an MPI <bcp14>MUST</bcp14> be zero.</t> zero.</li>
</ul>
<section anchor="using-mpis-to-encode-other-data"><name>Using anchor="using-mpis-to-encode-other-data">
<name>Using MPIs to encode other data</name> Encode Other Data</name>
<t>Note that MPIs are in some places places, MPIs are used to encode non-integer data, such as an elliptic curve (EC) point (see <xref target="ec-point-wire-formats"/>), target="ec-point-wire-formats"/>) or an octet string of known, fixed length (see <xref target="ec-scalar-wire-formats"/>). The wire representation is the same: two octets of length in bits counted from the first non-zero bit, followed by the smallest series of octets that can represent the value while stripping off any leading zero octets.</t>
</section>
</section>
<section anchor="key-ids-and-fingerprints"><name>Key anchor="key-ids-and-fingerprints">
<name>Key IDs and Fingerprints</name>
<t>A Key ID is an eight-octet scalar that identifies a key.
Implementations <bcp14>SHOULD NOT</bcp14> assume that Key IDs are unique.
A fingerprint is more likely to be unique than a key ID.
The fingerprint and key ID of a key are calculated differently according to the version of the key.</t>
<t><xref target="key-ids-fingerprints"/> describes how Key IDs and Fingerprints are formed.</t>
</section>
<section anchor="text"><name>Text</name> anchor="text">
<name>Text</name>
<t>Unless otherwise specified, the character set for text is the UTF-8 <xref target="RFC3629"/> encoding of Unicode <xref target="ISO10646"/>.</t>
</section>
<section anchor="time-fields"><name>Time anchor="time-fields">
<name>Time Fields</name>
<t>A time field is an unsigned four-octet number containing the number of seconds elapsed since midnight, 1 January 1970 UTC.</t>
</section>
<section anchor="keyrings"><name>Keyrings</name> anchor="keyrings">
<name>Keyrings</name>
<t>A keyring is a collection of one or more keys in a file or database.
Traditionally, a keyring is simply a sequential list of keys, but it may be any suitable database.
It is beyond the scope of this standard specification to discuss the details of keyrings or other databases.</t>
</section>
<section anchor="string-to-key-s2k-specifier"><name>String-to-Key anchor="string-to-key-s2k-specifier">
<name>String-to-Key (S2K) Specifier</name>
<t>A string-to-key (S2K) specifier type is used to convert a passphrase string into a symmetric-key encryption/decryption key. Passphrases requiring use of S2K conversion are currently used in two places: to encrypt the secret part of private keys, keys and for symmetrically encrypted messages.</t>
<section anchor="s2k-types"><name>String-to-Key (S2K) anchor="s2k-types">
<name>S2K Specifier Types</name>
<t>There are four types of S2K Specifier Types currently specified, specified and some reserved values:</t>
<texttable title="OpenPGP
<table anchor="s2k-types-registry">
<name>OpenPGP String-to-Key (S2K) Types registry" anchor="s2k-types-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>S2K Type</ttcol>
<ttcol align='left'>S2K field size (octets)</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Generate?</ttcol>
<c>0</c>
<c>Simple S2K</c>
<c>2</c>
<c><xref target="s2k-simple"/></c>
<c>No</c>
<c>1</c>
<c>Salted S2K</c>
<c>10</c>
<c><xref target="s2k-salted"/></c>
<c>Only Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">S2K Type</th>
<th align="left">S2K Field Size (Octets)</th>
<th align="left">Generate?</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">0</td>
<td align="left">Simple S2K</td>
<td align="left">2</td>
<td align="left">No</td>
<td align="left">[RFC9580], <xref target="s2k-simple"/></td>
</tr>
<tr>
<td align="right">1</td>
<td align="left">Salted S2K</td>
<td align="left">10</td>
<td align="left">Only when string is high entropy</c>
<c>2</c>
<c>Reserved value</c>
<c>-</c>
<c>-</c>
<c>No</c>
<c>3</c>
<c>Iterated entropy</td>
<td align="left">[RFC9580], <xref target="s2k-salted"/></td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">Reserved value</td>
<td align="left">-</td>
<td align="left">No</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">Iterated and Salted S2K</c>
<c>11</c>
<c><xref target="s2k-iter-salted"/></c>
<c>Yes</c>
<c>4</c>
<c>Argon2</c>
<c>20</c>
<c><xref target="s2k-argon2"/></c>
<c>Yes</c>
<c>100 to 110</c>
<c>Private/Experimental S2K</c>
<c>-</c>
<c>-</c>
<c>As appropriate</c>
</texttable>
<t>These S2K</td>
<td align="left">11</td>
<td align="left">Yes</td>
<td align="left">[RFC9580], <xref target="s2k-iter-salted"/></td>
</tr>
<tr>
<td align="right">4</td>
<td align="left">Argon2</td>
<td align="left">20</td>
<td align="left">Yes</td>
<td align="left">[RFC9580], <xref target="s2k-argon2"/></td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private/Experimental S2K</td>
<td align="left">-</td>
<td align="left">As appropriate</td>
<td align="left">[RFC9580]</td>
</tr>
</tbody>
</table>
<t>The S2K Specifier Types are described in the subsections below.
If the "Generate?" column "Yes" is not "Yes", present in the "Generate?" column, the S2K entry is used only for reading in backwards compatibility backward-compatibility mode and <bcp14>SHOULD NOT</bcp14> be used to generate new output.</t>
<section anchor="s2k-simple"><name>Simple anchor="s2k-simple">
<name>Simple S2K</name>
<t>This
<t>Simple S2K directly hashes the string to produce the key data.
See below for how this This hashing is done.</t>
<figure><artwork><![CDATA[ done as shown below.</t>
<artwork><![CDATA[
Octet 0: 0x00
Octet 1: hash algorithm
]]></artwork></figure>
]]></artwork>
<t>Simple S2K hashes the passphrase to produce the session key.
The manner in which this is done depends on the size of the session key (which depends on the cipher the session key will be used with) and the size of the hash algorithm's output.
If the hash size is greater than the session key size, the high-order (leftmost) octets of the hash are used as the key.</t>
<t>If the hash size is less than the key size, multiple instances of the hash context are created --- -- enough to produce the required key data. These instances are preloaded with 0, 1, 2, ...
octets of zeros (that is to say, is, the first instance has no preloading, the second gets preloaded with 1 octet of zero, the third is preloaded with two octets of zeros, and so forth).</t>
<t>As the data is hashed, it is given independently to each hash context. Since the contexts have been initialized differently, they will each produce a different hash output. Once the passphrase is hashed, the output data from the multiple hashes is concatenated, first hash leftmost, to produce the key data, with and any excess octets on the right are discarded.</t>
</section>
<section anchor="s2k-salted"><name>Salted anchor="s2k-salted">
<name>Salted S2K</name>
<t>This
<t>Salted S2K includes a "salt" value in the S2K specifier --- -- some arbitrary data --- -- that gets hashed along with the passphrase string, string to help prevent dictionary attacks.</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
Octet 0: 0x01
Octet 1: hash algorithm
Octets 2-9: 8-octet salt value
]]></artwork></figure>
]]></artwork>
<t>Salted S2K is exactly like Simple S2K, except that the input to the hash function(s) consists of the 8 octets of salt from the S2K specifier, followed by the passphrase.</t>
</section>
<section anchor="s2k-iter-salted"><name>Iterated anchor="s2k-iter-salted">
<name>Iterated and Salted S2K</name>
<t>This
<t>Iterated and Salted S2K includes both a salt and an octet count.
The salt is combined with the passphrase passphrase, and the resulting value is repeated and then hashed.
This further increases the amount of work an attacker must do to try dictionary attacks.</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
Octet 0: 0x03
Octet 1: hash algorithm
Octets 2-9: 8-octet salt value
Octet 10: count, count; a one-octet, one-octet coded value
]]></artwork></figure>
]]></artwork>
<t>The count is coded into a one-octet number using the following formula:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
#define EXPBIAS 6
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
]]></artwork></figure>
]]></artwork>
<t>The above formula is described in <xref target="C99"/>, where "Int32" is a type for a 32-bit integer, and the variable "c" is the coded count, Octet 10.</t>
<t>Iterated-Salted
<t>Iterated and Salted S2K hashes the passphrase and salt data multiple times.
The total number of octets to be hashed is specified in the encoded count in the S2K specifier.
Note that the resulting count value is an octet count of how many octets will be hashed, not an iteration count.</t>
<!-- [rfced] Please clarify "as with" in the following sentences. Is
the intended meaning "with" or "the same as"? Note that there are
2 instances in the text.
Original:
Initially, one or more hash contexts are set up as with the other S2K
algorithms, depending on how many octets of key data are needed.
After the hashing is done, the key data is produced from the hash
digest(s) as with the other S2K algorithms.
-->
<t>Initially, one or more hash contexts are set up as with the other S2K algorithms, depending on how many octets of key data are needed. Then the salt, followed by the passphrase data, is repeatedly processed as input to each hash context until the number of octets specified by the octet count has been hashed.
<!--[rfced] We do not see the term "isize" in any other RFCs - is
"isize" correct in this sentence, or should it be "size"?
Original:
The input is truncated to the octet count, except if the octet
count is less than the initial isize of the salt plus passphrase.
-->
The input is truncated to the octet count, except if the octet count is less than the initial isize of the salt plus passphrase. That is, at least one copy of the full salt plus passphrase will be provided as input to each hash context regardless of the octet count. After the hashing is done, the key data is produced from the hash digest(s) as with the other S2K algorithms.</t>
</section>
<section anchor="s2k-argon2"><name>Argon2</name> anchor="s2k-argon2">
<name>Argon2</name>
<t>This S2K method hashes the passphrase using Argon2, as specified in <xref target="RFC9106"/>.
This provides memory-hardness, memory hardness, further protecting the passphrase against brute-force attacks.</t>
<figure><artwork><![CDATA[
<!-- [rfced] The definition for "Octet 19" was 10 characters over the
72-character limit, so we moved text to the next line. Please
let us know if this is agreeable or if changes are needed.
Original:
Octet 19: one-octet encoded_m, specifying the exponent of the memory size
Current:
Octet 19: one-octet encoded_m, specifying the exponent of
the memory size
-->
<artwork><![CDATA[
Octet 0: 0x04
Octets 1-16: 16-octet salt value
Octet 17: one-octet number of passes t
Octet 18: one-octet degree of parallelism p
Octet 19: one-octet encoded_m, specifying the exponent of
the memory size
]]></artwork></figure>
]]></artwork>
<t>The salt <bcp14>SHOULD</bcp14> be unique for each passphrase.</t>
<t>The number of passes t and the degree of parallelism p <bcp14>MUST</bcp14> be non-zero.</t>
<t>The memory size m is 2**encoded_m kibibytes (KiB) of RAM.
The encoded memory size <bcp14>MUST</bcp14> be a value from 3+ceil(log_2(p)) to 31, such that the decoded memory size m is a value from 8*p to 2**31. Note that memory-hardness size is indicated in kibibytes (KiB), KiB, not octets.</t>
<t>Argon2 is invoked with the passphrase as P, the salt as S, the values of t, p and p, and, m as described above, the required key size as the tag length T, 0x13 as the version v, and Argon2id as the type.</t>
<t>For the recommended values of t, p p, and m, see <xref section="4" sectionFormat="of" target="RFC9106"/>.
If the recommended value of m for a given application is not a power of 2, it is <bcp14>RECOMMENDED</bcp14> to round up to the next power of 2 if the resulting performance would be acceptable, and acceptable; otherwise, round down otherwise (keeping in mind that m must be at least 8*p).</t>
<t>As an example, with the first recommended option (t=1, p=4, m=2**21), the full S2K specifier would be:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
04 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX 01 04 15
]]></artwork></figure>
<t>(where
]]></artwork>
<t>where XX represents a random octet of salt).</t> salt.</t>
</section>
</section>
<section anchor="s2k-usage-octet"><name>String-to-Key anchor="s2k-usage-octet">
<name>S2K Usage</name>
<t>Simple S2K and Salted S2K specifiers can be brute-forced when used with a low-entropy string, such as those typically provided by users.
In addition, the usage of Simple S2K can lead to key and IV initialization vector (IV) reuse (see <xref target="skesk"/>).
Therefore, when generating an S2K specifier, an implementation <bcp14>MUST NOT</bcp14> use Simple S2K.
Furthermore, an implementation <bcp14>SHOULD NOT</bcp14> generate a Salted S2K unless the implementation knows that the input string is high-entropy high entropy (for example, it generated the string itself using a known-good known good source of randomness).</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that implementations use Argon2.
If Argon2 is not available, Iterated and Salted S2K <bcp14>MAY</bcp14> be used if care is taken to use a high octet count and a strong passphrase.
However, this method does not provide memory-hardness, memory hardness, unlike Argon2.</t>
<section anchor="secret-key-encryption"><name>Secret-Key anchor="secret-key-encryption">
<name>Secret-Key Encryption</name>
<t>The first octet following the public key material in a secret key packet (<xref target="secret-key-packet-formats"/>) indicates whether and how the secret key material is passphrase-protected. passphrase protected.
This first octet is known as the "S2K usage octet".</t>
<t>If the S2K usage octet is zero, the secret key data is unprotected.
If it is non-zero, it describes how to use a passphrase to unlock the secret key.</t>
<t>Implementations predating <xref target="RFC2440"/> indicated a protected key by storing a symmetric cipher algorithm ID (see <xref target="symmetric-algos"/>) in the S2K usage octet.
In this case, the MD5 hash function was always used to convert the passphrase to a key for the specified cipher algorithm.</t>
<t>Later implementations indicate a protected secret key by storing a special value 253 (AEAD), 254 (CFB), or 255 (MalleableCFB) in the S2K usage octet. The S2K usage octet is then followed immediately by a set of fields that describe how to convert a passphrase to a symmetric key that can unlock the secret material, plus other parameters relevant to the type of encryption used.</t>
<t>The wire format fields also differ based on the version of the enclosing OpenPGP packet.
The table below, indexed by the S2K usage octet, summarizes the specifics described in <xref target="secret-key-packet-formats"/>.</t>
<!-- [rfced] Regarding tables 2 and 19 (Sections 3.7.2.1 and 9.2) - the width of these two
tables exceeded the 72-character limit in the text output.
Table 2 (was 5 chars over the limit): We trimmed the last column of table 2 to "Gen?" and added explanatory text to the preceding paragraph. Please review and let us know if any updates are required.
Table 19 (was 3 chars over the limit): We combined the Usage and Field Size columns in this document. We tested another possible fix that keeps the 2 columns separate, but forces a break in "EdDSALegacy" within the Usage column. See table 20 in
https://www.rfc-editor.org/authors/rfc9580table20.html#table-20
https://www.rfc-editor.org/authors/rfc9580table20.txt
https://www.rfc-editor.org/authors/rfc9580table20.pdf
Please review and let us know your preference or if you have a suggested alternative.
-->
<t>In the table below, <spanx style="verb">check(x)</spanx> <tt>check(x)</tt> means the "2-octet checksum" meaning checksum", which is the sum of all octets in x mod 65536. The <spanx style="verb">info</spanx> <tt>info</tt> and <spanx style="verb">packetprefix</spanx> <tt>packetprefix</tt> parameters are described in detail in <xref target="secret-key-packet-formats"/>.</t>
<texttable title="OpenPGP target="secret-key-packet-formats"/>. Note that the "Generated?" column header has been shortened to "Gen?" here.</t>
<table anchor="secret-key-protection-registry">
<name>OpenPGP Secret Key Encryption (S2K Usage Octet) registry" anchor="secret-key-protection-registry">
<ttcol align='left'>S2K usage octet</ttcol>
<ttcol align='left'>Shorthand</ttcol>
<ttcol align='left'>Encryption parameter fields</ttcol>
<ttcol align='left'>Encryption</ttcol>
<ttcol align='left'>Generate?</ttcol>
<c>0</c>
<c>Unprotected</c>
<c>-</c>
<c><strong>v3 Registry</name>
<thead>
<tr>
<th align="left">S2K Usage Octet</th>
<th align="left">Shorthand</th>
<th align="left">Encryption Parameter Fields</th>
<th align="left">Encryption</th>
<th align="left">Gen?</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0</td>
<td align="left">Unprotected</td>
<td align="left">-</td>
<td align="left"> <strong>v3 or v4 keys:</strong> [cleartext secrets || check(secrets)] <br /> <br/>
<strong>v6 keys:</strong> [cleartext secrets]</c>
<c>Yes</c>
<c>Known secrets]
</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">Known symmetric cipher algo ID (see <xref target="symmetric-algos"/>)</c>
<c>LegacyCFB</c>
<c>IV</c>
<c>CFB(MD5(passphrase), target="symmetric-algos"/>)</td>
<td align="left">LegacyCFB</td>
<td align="left">IV</td>
<td align="left">CFB(MD5(passphrase), secrets || check(secrets))</c>
<c>No</c>
<c>253</c>
<c>AEAD</c>
<c>params-length check(secrets))</td>
<td align="left">No</td>
</tr>
<tr>
<td align="left">253</td>
<td align="left">AEAD</td>
<td align="left">params-length (<strong>v6-only</strong>), cipher-algo, AEAD-mode, S2K-specifier-length (<strong>v6-only</strong>), S2K-specifier, nonce</c>
<c>AEAD(HKDF(S2K(passphrase), (<strong>v6-only</strong>),S2K-specifier, nonce
</td>
<td align="left">AEAD(HKDF(S2K(passphrase), info), secrets, packetprefix)</c>
<c>Yes</c>
<c>254</c>
<c>CFB</c>
<c>params-length packetprefix)</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">254</td>
<td align="left">CFB</td>
<td align="left">params-length (<strong>v6-only</strong>), cipher-algo, S2K-specifier-length (<strong>v6-only</strong>), S2K-specifier, IV</c>
<c>CFB(S2K(passphrase), IV</td>
<td align="left">CFB(S2K(passphrase), secrets || SHA1(secrets))</c>
<c>Yes</c>
<c>255</c>
<c>MalleableCFB</c>
<c>cipher-algo, SHA1(secrets))</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">255</td>
<td align="left">MalleableCFB</td>
<td align="left">cipher-algo, S2K-specifier, IV</c>
<c>CFB(S2K(passphrase), IV</td>
<td align="left">CFB(S2K(passphrase), secrets || check(secrets))</c>
<c>No</c>
</texttable> check(secrets))</td>
<td align="left">No</td>
</tr>
</tbody>
</table>
<t>When emitting a secret key (with or without passphrase-protection) passphrase protection), an implementation <bcp14>MUST</bcp14> only produce data from a row with "Generate?" marked as "Yes".
Each row with "Generate?" marked as "No" is described for backward compatibility (for reading v4 and earlier keys only), only) and <bcp14>MUST NOT</bcp14> be used to generate new output.
Version 6 secret keys using these formats <bcp14>MUST</bcp14> be rejected.</t>
<t>Note that compared to a version 4 secret key, the parameters of a passphrase-protected version 6 secret key are stored with an additional pair of length counts, each of which is one octet wide.</t>
<t>Argon2 is only used with AEAD Authenticated Encryption with Associated Data (AEAD) (S2K usage octet 253).
An implementation <bcp14>MUST NOT</bcp14> create and <bcp14>MUST</bcp14> reject as malformed any secret key packet where the S2K usage octet is not AEAD (253) and the S2K specifier type is Argon2.</t>
</section>
<section anchor="symmetric-key-message-encryption"><name>Symmetric-Key anchor="symmetric-key-message-encryption">
<name>Symmetric-Key Message Encryption</name>
<t>OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) (SKESK) packet 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 mix of symmetric-key ESKs SKESK packets and public-key ESKs. PKESK packets. This allows a message to be decrypted either with either a passphrase or a public-key pair.</t>
<t>Implementations
<!-- [rfced] FYI: In the last sentence below, we replaced "This" with
"IDEA" for clarity. If that is not correct, please let us know.
Original:
Implementations predating <xref target="RFC2440"/> [RFC2440] always used IDEA with Simple
string-to-key conversion when encrypting a message with a symmetric
algorithm. See Section 5.7. This MUST NOT be generated, but MAY be
consumed for backward-compatibility.
Current:
Implementations predating [RFC2440] always used the
International Data Encryption Algorithm (IDEA) with Simple
S2K conversion when encrypting a message with a symmetric
algorithm; see Section 5.7. IDEA MUST NOT be generated but
MAY be consumed for backward compatibility.
-->
<t>Implementations predating <xref target="RFC2440"/> always used the International Data Encryption Algorithm (IDEA) with Simple S2K conversion when encrypting a message with a symmetric algorithm;
see <xref target="sed"/>.
This IDEA <bcp14>MUST NOT</bcp14> be generated, generated but <bcp14>MAY</bcp14> be consumed for backward-compatibility.</t> backward compatibility.</t>
</section>
</section>
</section>
</section>
<section anchor="packet-syntax"><name>Packet anchor="packet-syntax">
<name>Packet Syntax</name>
<t>This section describes the packets used by OpenPGP.</t>
<section anchor="overview"><name>Overview</name> anchor="overview">
<name>Overview</name>
<t>An OpenPGP message is constructed from a number of records that are traditionally called packets.
A packet is a chunk of data that has a type ID specifying its meaning.
An OpenPGP message, keyring, certificate, detached signature, and so forth consists of a number of packets.
Some of those packets may contain other OpenPGP packets (for example, a compressed data packet, when uncompressed, contains OpenPGP packets).</t>
<t>Each packet consists of a packet header, followed by the packet body.
The packet header is of variable length.</t>
<t>When handling a stream of packets, the length information in each packet header is the canonical source of packet boundaries.
An implementation handling a packet stream that wants to find the next packet <bcp14>MUST</bcp14> look for it at the precise offset indicated in the previous packet header.</t>
<t>Additionally, some packets contain internal length indicators (for example, a subfield within the packet).
In the event that a subfield length indicator within a packet implies inclusion of octets outside the range indicated in the packet header, a parser <bcp14>MUST</bcp14> abort without writing outside the indicated range and <bcp14>MUST</bcp14> treat the packet as malformed and unusable.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> interpret octets outside the range indicated in the packet header as part of the contents of the packet.</t>
</section>
<section anchor="packet-headers"><name>Packet anchor="packet-headers">
<name>Packet Headers</name>
<t>The first octet of the packet denotes the format of the rest of the header, and it encodes the Packet Type ID, indicating the type of the packet (see <xref target="packet-types"/>). The remainder of the packet header is the length of the packet.</t>
<t>There are two packet formats, formats: 1) the (current) OpenPGP packet format specified by this document and its predecessors <xref target="RFC4880"/> and <xref target="RFC2440"/>, target="RFC2440"/> and 2) the Legacy packet format as used by implementations predating any IETF specification of the protocol.</t>
<t>Note that the most significant bit is the leftmost bit, called bit 7. "bit 7".
A mask for this bit is 0x80 in hexadecimal.</t>
<figure><artwork><![CDATA[
┌───────────────┐
<artwork><![CDATA[
+---------------+
Encoded Packet Type ID: │7 |7 6 5 4 3 2 1 0│
└───────────────┘ 0|
+---------------+
OpenPGP format:
Bit 7 -- always one
Bit 6 -- always one
Bits 5 to 0 -- packet type ID
Legacy format:
Bit 7 -- always one
Bit 6 -- always zero
Bits 5 to 2 -- packet type ID
Bits 1 to 0 -- length-type
]]></artwork></figure>
]]></artwork>
<t>Bit 6 of the first octet of the packet header indicates whether the packet is encoded in the OpenPGP or Legacy packet format.
The Legacy packet format <bcp14>MAY</bcp14> be used when consuming packets to facilitate interoperability and accessing archived data.
The Legacy packet format <bcp14>SHOULD NOT</bcp14> be used to generate new data, unless the recipient is known to only support the Legacy packet format. This latter case is extremely unlikely, as the Legacy packet format was obsoleted by <xref target="RFC2440"/> in 1998.</t>
<t>An implementation that consumes and re-distributes redistributes pre-existing OpenPGP data (such as Transferable Public Keys) may encounter packets framed with the Legacy packet format. Such an implementation <bcp14>MAY</bcp14> either re-distribute redistribute these packets in their Legacy format, format or transform them to the current OpenPGP packet format before re-distribution.</t> redistribution.</t>
<t>Note that Legacy format headers only have 4 bits for the packet type ID, ID and hence can only encode packet type IDs less than 16, whereas the OpenPGP format headers can encode IDs as great as 63.</t>
<section anchor="openpgp-packet-format"><name>OpenPGP anchor="openpgp-packet-format">
<name>OpenPGP Format Packet Lengths</name>
<t>OpenPGP format packets have four possible ways of encoding length:</t>
<t><list style="numbers">
<ol spacing="normal" type="1"><li>
<t>A one-octet Body Length header encodes packet lengths of up to 191 octets.</t>
</li>
<li>
<t>A two-octet Body Length header encodes packet lengths of 192 to 8383 octets.</t>
</li>
<li>
<t>A five-octet Body Length header encodes packet lengths of up to 4,294,967,295 (0xFFFFFFFF) octets in length.
(This actually encodes a four-octet scalar number.)</t>
</li>
<li>
<t>When the length of the packet body is not known in advance by the issuer, Partial Body Length headers encode a packet of indeterminate length, effectively making it a stream.</t>
</list></t>
</li>
</ol>
<section anchor="one-octet-lengths"><name>One-Octet anchor="one-octet-lengths">
<name>One-Octet Lengths</name>
<t>A one-octet Body Length header encodes a length of 0 to 191 octets.
This type of length header is recognized because the one octet one-octet value is less than 192.
The body length is equal to:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
bodyLen = 1st_octet;
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="two-octet-lengths"><name>Two-Octet anchor="two-octet-lengths">
<name>Two-Octet Lengths</name>
<t>A two-octet Body Length header encodes a length of 192 to 8383 octets.
It is recognized because its first octet is in the range 192 to 223.
The body length is equal to:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="five-octet-lengths"><name>Five-Octet anchor="five-octet-lengths">
<name>Five-Octet Lengths</name>
<t>A five-octet Body Length header consists of a single octet holding the value 255, followed by a four-octet scalar. The body length is equal to:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet
]]></artwork></figure>
]]></artwork>
<t>This basic set of one, two, and five-octet lengths is also used internally to some packets.</t>
</section>
<section anchor="partial-body-lengths"><name>Partial anchor="partial-body-lengths">
<name>Partial Body Lengths</name>
<t>A Partial Body Length header is one octet long and encodes the length of only part of the data packet.
This length is a power of 2, from 1 to 1,073,741,824 (2 to the 30th power).
It is recognized by its one octet one-octet value that is greater than or equal to 224, and less than 255.
The Partial Body Length is equal to:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
partialBodyLen = 1 << (1st_octet & 0x1F);
]]></artwork></figure>
]]></artwork>
<t>Each Partial Body Length header is followed by a portion of the packet body data.
The data;
the Partial Body Length header specifies this portion's length.
Another length header (one octet, two-octet, five-octet, two octets, five octets, or partial) follows that portion.
The last length header in the packet <bcp14>MUST NOT</bcp14> be a Partial Body Length header.
Partial Body Length headers may only be used for the non-final parts of the packet.</t>
<t>Note also that the last Body Length header can be a zero-length header.</t>
<t>An implementation <bcp14>MAY</bcp14> use Partial Body Lengths for data packets, be whether they are literal, compressed, or encrypted. The first partial length <bcp14>MUST</bcp14> be at least 512 octets long.
Partial Body Lengths <bcp14>MUST NOT</bcp14> be used for any other packet types.</t>
</section>
</section>
<section anchor="legacy-packet-format"><name>Legacy anchor="legacy-packet-format">
<name>Legacy Format Packet Lengths</name>
<t>A zero in bit 6 of the first octet of the packet indicates a Legacy packet format.
Bits 1 and 0 of the first octet of a Legacy packet are the "length-type" field.
The meaning of the length-type in Legacy format packets is:</t> is as follows:</t>
<dl>
<dt>0</dt>
<dd>
<t>The
<dd>The packet has a one-octet length. The header is 2 octets long.</t> long.
</dd>
<dt>1</dt>
<dd>
<t>The
<dd>The packet has a two-octet length. The header is 3 octets long.</t> long.
</dd>
<dt>2</dt>
<dd>
<t>The
<dd>The packet has a four-octet length. The header is 5 octets long.</t> long.
</dd>
<dt>3</dt>
<dd>
<t>The
<dd>The packet is of indeterminate length.
The header is 1 octet long, and the implementation must determine how long the packet is.
If the packet is in a file, this it means that the packet extends until the end of the file.
The OpenPGP format headers have a mechanism for precisely encoding data of indeterminate length.
An implementation <bcp14>MUST NOT</bcp14> generate a Legacy format packet with indeterminate length.
An implementation <bcp14>MAY</bcp14> interpret an indeterminate length Legacy format packet in order to deal with historic data, data or data generated by a legacy system that predates support for <xref target="RFC2440"/>.</t> target="RFC2440"/>.
</dd>
</dl>
</section>
<section anchor="packet-length-examples"><name>Packet anchor="packet-length-examples">
<name>Packet Length Examples</name>
<t>These examples show ways that OpenPGP format packets might encode the packet body lengths.</t>
<t>A
<ul>
<li>A packet body with length 100 may have its length encoded in one octet: 0x64.
This is followed by 100 octets of data.</t>
<t>A data.</li>
<li>A packet body with length 1723 may have its length encoded in two octets: 0xC5, 0xFB.
This header is followed by the 1723 octets of data.</t>
<t>A data.</li>
<li>A packet body with length 100000 may have its length encoded in five octets: 0xFF, 0x00, 0x01, 0x86, 0xA0.</t> 0xA0.</li>
</ul>
<t>It might also be encoded in the following octet stream: 0xEF, stream:</t>
<ul>
<li>0xEF, first 32768 octets of data; 0xE1, data;</li>
<li>0xE1, next two octets of data; 0xE0, data;</li>
<li>0xE0, next one octet of data; 0xF0, data;</li>
<li>0xF0, next 65536 octets of data; 0xC5, and </li>
<li>0xC5, 0xDD, last 1693 octets of data.
This data.</li>
</ul>
<t>This is just one possible encoding, and many variations are possible on the size of the Partial Body Length headers, as long as a regular Body Length header encodes the last portion of the data.</t>
<t>Please note that in all of these explanations, the total length of the packet is the length of the header(s) plus the length of the body.</t>
</section>
</section>
<section anchor="packet-criticality"><name>Packet anchor="packet-criticality">
<name>Packet Criticality</name>
<t>The Packet Type ID space is partitioned into critical packets and non-critical packets.
If an implementation encounters a critical packet where the packet type is unknown in a packet sequence, it <bcp14>MUST</bcp14> reject the whole packet sequence (see <xref target="packet-sequence-composition"/>).
On the other hand, an unknown non-critical packet <bcp14>MUST</bcp14> be ignored.</t>
<t>Packets with Type IDs from 0 to 39 are critical.
Packets with Type IDs from 40 to 63 are non-critical.</t>
</section>
</section>
<section anchor="packet-types"><name>Packet anchor="packet-types">
<name>Packet Types</name>
<t>The defined packet types are as follows:</t>
<texttable title="OpenPGP
<table anchor="packet-types-registry">
<name>OpenPGP Packet Types registry" anchor="packet-types-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Critical</ttcol>
<ttcol align='left'>Packet Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Critical</th>
<th align="left">Packet Type Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Shorthand</ttcol>
<c>0</c>
<c>yes</c>
<c>Reserved Description</th>
<th align="left">Shorthand</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">0</td>
<td align="left">Yes</td>
<!-- [rfced] Should "a packet" be "a packet tag" as shown in the IANA registry <https://www.iana.org/assignments/openpgp>?
Original:
| 0 | yes | Reserved - a packet | | |
| | | MUST NOT have this | | |
| | | packet type ID | | |
IANA description:
Reserved - a packet tag MUST NOT have this packet type ID
-->
<td align="left">Reserved - a packet <bcp14>MUST NOT</bcp14> have this packet type ID</c>
<c> </c>
<c> </c>
<c>1</c>
<c>yes</c>
<c>Public-Key ID</td>
<td align="left"> </td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">1</td>
<td align="left">Yes</td>
<td align="left">Public-Key Encrypted Session Key Packet</c>
<c><xref target="pkesk"/></c>
<c>PKESK</c>
<c>2</c>
<c>yes</c>
<c>Signature Packet</c>
<c><xref target="signature-packet"/></c>
<c>SIG</c>
<c>3</c>
<c>yes</c>
<c>Symmetric-Key Packet</td>
<td align="left">PKESK</td>
<td align="left">[RFC9580],
<xref target="pkesk"/></td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">Yes</td>
<td align="left">Signature Packet</td>
<td align="left">SIG</td>
<td align="left">[RFC9580],
<xref target="signature-packet"/></td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">Yes</td>
<td align="left">Symmetric-Key Encrypted Session Key Packet</c>
<c><xref target="skesk"/></c>
<c>SKESK</c>
<c>4</c>
<c>yes</c>
<c>One-Pass Signature Packet</c>
<c><xref target="one-pass-sig"/></c>
<c>OPS</c>
<c>5</c>
<c>yes</c>
<c>Secret-Key Packet</c>
<c><xref target="seckey"/></c>
<c>SECKEY</c>
<c>6</c>
<c>yes</c>
<c>Public-Key Packet</c>
<c><xref target="pubkey"/></c>
<c>PUBKEY</c>
<c>7</c>
<c>yes</c>
<c>Secret-Subkey Packet</c>
<c><xref target="secsubkey"/></c>
<c>SECSUBKEY</c>
<c>8</c>
<c>yes</c>
<c>Compressed Data Packet</c>
<c><xref target="compressed-data"/></c>
<c>COMP</c>
<c>9</c>
<c>yes</c>
<c>Symmetrically Encrypted Data Packet</c>
<c><xref target="sed"/></c>
<c>SED</c>
<c>10</c>
<c>yes</c>
<c>Marker Packet</c>
<c><xref target="marker-packet"/></c>
<c>MARKER</c>
<c>11</c>
<c>yes</c>
<c>Literal Data Packet</c>
<c><xref target="lit"/></c>
<c>LIT</c>
<c>12</c>
<c>yes</c>
<c>Trust Packet</c>
<c><xref target="trust"/></c>
<c>TRUST</c>
<c>13</c>
<c>yes</c>
<c>User ID Packet</c>
<c><xref target="uid"/></c>
<c>UID</c>
<c>14</c>
<c>yes</c>
<c>Public-Subkey Packet</c>
<c><xref target="pubsubkey"/></c>
<c>PUBSUBKEY</c>
<c>17</c>
<c>yes</c>
<c>User Packet</td>
<td align="left">SKESK</td>
<td align="left">[RFC9580],
<xref target="skesk"/></td>
</tr>
<tr>
<td align="right">4</td>
<td align="left">Yes</td>
<td align="left">One-Pass Signature Packet</td>
<td align="left">OPS</td>
<td align="left">[RFC9580],
<xref target="one-pass-sig"/></td>
</tr>
<tr>
<td align="right">5</td>
<td align="left">Yes</td>
<td align="left">Secret-Key Packet</td>
<td align="left">SECKEY</td>
<td align="left">[RFC9580],
<xref target="seckey"/></td>
</tr>
<tr>
<td align="right">6</td>
<td align="left">Yes</td>
<td align="left">Public-Key Packet</td>
<td align="left">PUBKEY</td>
<td align="left">[RFC9580],
<xref target="pubkey"/></td>
</tr>
<tr>
<td align="right">7</td>
<td align="left">Yes</td>
<td align="left">Secret-Subkey Packet</td>
<td align="left">SECSUBKEY</td>
<td align="left">[RFC9580],
<xref target="secsubkey"/></td>
</tr>
<tr>
<td align="right">8</td>
<td align="left">Yes</td>
<td align="left">Compressed Data Packet</td>
<td align="left">COMP</td>
<td align="left">[RFC9580],
<xref target="compressed-data"/></td>
</tr>
<tr>
<td align="right">9</td>
<td align="left">Yes</td>
<td align="left">Symmetrically Encrypted Data Packet</td>
<td align="left">SED</td>
<td align="left">[RFC9580],
<xref target="compressed-data"/></td>
</tr>
<tr>
<td align="right">10</td>
<td align="left">Yes</td>
<td align="left">Marker Packet</td>
<td align="left">MARKER</td>
<td align="left">[RFC9580],
<xref target="marker-packet"/></td>
</tr>
<tr>
<td align="right">11</td>
<td align="left">Yes</td>
<td align="left">Literal Data Packet</td>
<td align="left">LIT</td>
<td align="left">[RFC9580],
<xref target="marker-packet"/></td>
</tr>
<tr>
<td align="right">12</td>
<td align="left">Yes</td>
<td align="left">Trust Packet</td>
<td align="left">TRUST</td>
<td align="left">[RFC9580],
<xref target="trust"/></td>
</tr>
<tr>
<td align="right">13</td>
<td align="left">Yes</td>
<td align="left">User ID Packet</td>
<td align="left">UID</td>
<td align="left">[RFC9580],
<xref target="uid"/></td>
</tr>
<tr>
<td align="right">14</td>
<td align="left">Yes</td>
<td align="left">Public-Subkey Packet</td>
<td align="left">PUBSUBKEY</td>
<td align="left">[RFC9580],
<xref target="pubsubkey"/></td>
</tr>
<tr>
<td align="right">17</td>
<td align="left">Yes</td>
<td align="left">User Attribute Packet</c>
<c><xref target="user-attribute-packet"/></c>
<c>UAT</c>
<c>18</c>
<c>yes</c>
<c>Symmetrically Packet</td>
<td align="left">UAT</td>
<td align="left">[RFC9580],
<xref target="user-attribute-packet"/></td>
</tr>
<tr>
<td align="right">18</td>
<td align="left">Yes</td>
<td align="left">Symmetrically Encrypted and Integrity Protected Data Packet</c>
<c><xref target="seipd"/></c>
<c>SEIPD</c>
<c>19</c>
<c>yes</c>
<c>Reserved Packet</td>
<td align="left">SEIPD</td>
<td align="left">[RFC9580],
<xref target="seipd"/></td>
</tr>
<tr>
<td align="right">19</td>
<td align="left">Yes</td>
<td align="left">Reserved (formerly Modification Detection Code Packet)</c>
<c>(see <xref target="version-one-seipd"/>)</c>
<c> </c>
<c>20</c>
<c>yes</c>
<c>Reserved</c>
<c> </c>
<c> </c>
<c>21</c>
<c>yes</c>
<c>Padding Packet</c>
<c><xref target="padding-packet"/></c>
<c>PADDING</c>
<c>22 to 39</c>
<c>yes</c>
<c>Unassigned Packet)</td>
<td align="left"> </td>
<td align="left">[RFC9580], <xref target="version-one-seipd"/></td>
</tr>
<tr>
<td align="right">20</td>
<td align="left">Yes</td>
<td align="left">Reserved</td>
<td align="left"> </td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">21</td>
<td align="left">Yes</td>
<td align="left">Padding Packet</td>
<td align="left">PADDING</td>
<td align="left">[RFC9580],
<xref target="padding-packet"/></td>
</tr>
<tr>
<td align="right">22-39</td>
<td align="left">Yes</td>
<td align="left">Unassigned Critical Packet</c>
<c> </c>
<c> </c>
<c>40 to 59</c>
<c>no</c>
<c>Unassigned Packet</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">40-59</td>
<td align="left">No</td>
<td align="left">Unassigned Non-Critical Packet</c>
<c> </c>
<c> </c>
<c>60 to 63</c>
<c>no</c>
<c>Private Packet</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">60-63</td>
<td align="left">No</td>
<td align="left">Private or Experimental Values</c>
<c> </c>
<c> </c>
</texttable> Values</td>
<td align="left"> </td>
<td align="left">[RFC9580]</td>
</tr>
</tbody>
</table>
<t>The labels in the "Shorthand" column are used for compact reference elsewhere in this draft, document, and they may also be used by implementations that provide debugging or inspection affordances for streams of OpenPGP packets.</t>
<section anchor="pkesk"><name>Public-Key anchor="pkesk">
<name>Public-Key Encrypted Session Key Packet (Type ID 1)</name>
<t>Zero or more Public-Key Encrypted Session Key (PKESK) PKESK packets and/or Symmetric-Key Encrypted Session Key SKESK packets (<xref target="skesk"/>) precede an encryption container (that is, a Symmetrically Encrypted Integrity Protected Data (SEIPD) packet or --- -- for historic data --- -- a Symmetrically Encrypted Data (SED) packet), which holds an encrypted message.
The message is encrypted with the session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s). The encryption container is preceded by one Public-Key Encrypted Session Key packet for each OpenPGP key to which the message is encrypted. The recipient of the message finds a session key that is encrypted to their public key, decrypts the session key, and then uses the session key to decrypt the message.</t>
<t>The body of this packet starts with a one-octet number giving the version number of the packet type. The currently defined versions are 3 and 6. The remainder of the packet depends on the version.</t>
<t>The versions differ in how they identify the recipient key, key and in what they encode.
The version of the PKESK packet must align with the version of the SEIPD packet (see <xref target="encrypted-message-versions"/>).
Any new version of the PKESK packet should be registered in the registry established in <xref target="encrypted-message-versions"/>.</t>
<section anchor="v3-pkesk"><name>Version anchor="v3-pkesk">
<name>Version 3 Public-Key Encrypted Session Key Packet Format</name>
<t>A version 3 Public-Key Encrypted Session Key (PKESK) PKESK packet precedes a version 1 Symmetrically Encrypted Integrity Protected Data (v1 SEIPD, see SEIPD packet (see <xref target="version-one-seipd"/>) packet. target="version-one-seipd"/>).
In historic data, it is sometimes found preceding a deprecated Symmetrically Encrypted Data packet (SED, SED packet; see <xref target="sed"/>). target="sed"/>.
A v3 PKESK packet <bcp14>MUST NOT</bcp14> precede a v2 SEIPD packet (see <xref target="encrypted-message-versions"/>).</t>
<t>The v3 PKESK packet consists of:</t>
<t><list style="symbols">
<t>A
<ul spacing="normal">
<li>A one-octet version number with value 3.</t>
<t>An 3.
</li>
<li>An eight-octet number that gives the Key ID of the public key to 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 instead of the Key ID of the primary key.
The Key ID may also be all zeros, for an "anonymous recipient" (see <xref target="pkesk-notes"/>).</t>
<t>A target="pkesk-notes"/>).
</li>
<li>A one-octet number giving the public-key algorithm used.</t>
<t>A used.
</li>
<li>A series of values comprising the encrypted session key.
This is algorithm-specific algorithm specific and described below.</t>
</list></t> below.
</li>
</ul>
<t>The public-key encryption algorithm (described in subsequent sections) is passed two values:</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>The session key.</t> key.
</li>
<li>
<t>The one-octet algorithm identifier that specifies the symmetric encryption algorithm used to encrypt the following v1 SEIPD packet.</t>
</list></t> packet described in the following section.</t>
</li>
</ul>
</section>
<section anchor="v6-pkesk"><name>Version anchor="v6-pkesk">
<name>Version 6 Public-Key Encrypted Session Key Packet Format</name>
<t>A version 6 Public-Key Encrypted Session Key (PKESK) PKESK packet precedes a version 2 Symmetrically Encrypted Integrity Protected Data (v2 SEIPD, see SEIPD packet (see <xref target="version-two-seipd"/>) packet. target="version-two-seipd"/>).
A v6 PKESK packet <bcp14>MUST NOT</bcp14> precede a v1 SEIPD packet or a deprecated Symmetrically Encrypted Data SED packet (see <xref target="encrypted-message-versions"/>).</t>
<t>The v6 PKESK packet consists of the following fields:</t>
<t><list style="symbols">
<t>A
<ul spacing="normal">
<li>A one-octet version number with value 6.</t>
<t>A 6.
</li>
<li>A one-octet size of the following two fields.
This size may be zero, if the key version number field and the fingerprint field are omitted for an "anonymous recipient" (see <xref target="pkesk-notes"/>).</t>
<t>A one octet target="pkesk-notes"/>).
</li>
<li>A one-octet key version number.</t>
<t>The number.
</li>
<li>The fingerprint of the public key or subkey to which the session key is encrypted.
Note that the length N of the fingerprint for a version 4 key is 20 octets; for a version 6 key key, N is 32.</t>
<t>A 32.
</li>
<li>A one-octet number giving the public-key algorithm used.</t>
<t>A used.
</li>
<li>A series of values comprising the encrypted session key.
This is algorithm-specific algorithm specific and described below.</t>
</list></t> below.
</li>
</ul>
<t>The session key is encrypted according to the public-key algorithm used, as described below.
No symmetric encryption algorithm identifier is passed to the public-key algorithm for a v6 PKESK packet, as it is included in the v2 SEIPD packet.</t>
</section>
<section anchor="pkesk-rsa"><name>Algorithm-Specific anchor="pkesk-rsa">
<name>Algorithm-Specific Fields for RSA encryption</name>
<t><list style="symbols">
<t>Multiprecision integer (MPI) Encryption</name>
<ul spacing="normal">
<li>MPI of RSA-encrypted value m**e mod n.</t>
</list></t> n.
</li>
</ul>
<t>To produce the value "m" in the above formula, first concatenate the following values:</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>The one-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet).</t>
<t>The packet).
</li>
<li>The session key.</t>
<t>A key.
</li>
<li>A two-octet checksum of the session key, equal to the sum of the session key octets, modulo 65536.</t>
</list></t> 65536.
</li>
</ul>
<t>Then, the above values are encoded using the PKCS#1 block encoding EME-PKCS1-v1_5 EME-PKCS1-v1_5, as described in step Step 2 of in <xref section="7.2.1" sectionFormat="of" target="RFC8017"/> (see also <xref target="eme-pkcs1-v1-5-encode"/>).
When decoding "m" during decryption, an implementation should follow step Step 3 of in <xref section="7.2.2" sectionFormat="of" target="RFC8017"/> (see also <xref target="eme-pkcs1-v1-5-decode"/>).</t>
<t>Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation <bcp14>MUST</bcp14> make a new PKCS#1 encoding for each key. This defends against attacks such as those discussed in <xref target="HASTAD"/>.</t>
</section>
<section anchor="pkesk-elgamal"><name>Algorithm-Specific anchor="pkesk-elgamal">
<name>Algorithm-Specific Fields for Elgamal encryption</name>
<t><list style="symbols"> Encryption</name>
<ul spacing="normal">
<li>
<t>MPI of Elgamal (Diffie-Hellman) value g**k mod p.</t>
</li>
<li>
<t>MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.</t>
</list></t>
</li>
</ul>
<t>To produce the value "m" in the above formula, first concatenate the following values:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>The one-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet).</t>
</li>
<li>
<t>The session key.</t>
</li>
<li>
<t>A two-octet checksum of the session key, equal to the sum of the session key octets, modulo 65536.</t>
</list></t>
</li>
</ul>
<t>Then, the above values are encoded using the PKCS#1 block encoding EME-PKCS1-v1_5 EME-PKCS1-v1_5, as described in step Step 2 of in <xref section="7.2.1" sectionFormat="of" target="RFC8017"/> (see also <xref target="eme-pkcs1-v1-5-encode"/>).
When decoding "m" during decryption, an implementation should follow step Step 3 of in <xref section="7.2.2" sectionFormat="of" target="RFC8017"/> (see also <xref target="eme-pkcs1-v1-5-decode"/>).</t>
<t>Note that when an implementation forms several PKESKs with one session key, forming a message that can be decrypted by several keys, the implementation <bcp14>MUST</bcp14> make a new PKCS#1 encoding for each key.
This defends against attacks such as those discussed in <xref target="HASTAD"/>.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> generate ElGamal v6 PKESKs.</t>
</section>
<section anchor="pkesk-ecdh"><name>Algorithm-Specific anchor="pkesk-ecdh">
<name>Algorithm-Specific Fields for ECDH encryption</name>
<t><list style="symbols">
<t>MPI Encryption</name>
<ul spacing="normal">
<li>MPI of an EC point representing an ephemeral public key, key in the point format associated with the curve as specified in <xref target="ec-curves"/>.</t>
<t>A target="ec-curves"/>.
</li>
<li>A one-octet size, followed by a symmetric key encoded using the method described in <xref target="ecdh"/>.</t>
</list></t> target="ecdh"/>.
</li>
</ul>
</section>
<section anchor="pkesk-x25519"><name>Algorithm-Specific anchor="pkesk-x25519">
<name>Algorithm-Specific Fields for X25519 encryption</name>
<t><list style="symbols">
<t>32 Encryption</name>
<!-- [rfced] The text "A one-octet size of the following field(s)"
(and variations of) appears in Sections 5.1.2, 5.1.6, 5.1.7,
5.3.2, 5.5.5.4, 5.5.5.5, 5.5.5.6, and 11.5. For clarity, can the
field(s) be named? Or if you prefer to leave the wording as is,
should a semicolon be added after "the following field(s)" and
the bullet points that follow be indented so it's clear what "the
following field(s)" is referring to?
Also, does "one octet" need to be removed in the sentences that
follow "A one-octet size of the following field(s)" to avoid
redundancy? Please advise.
A few examples
Original (Section 5.1.2):
* A one-octet version number with value 6.
* A one-octet size of the following two fields. This size may be
zero, if the key version number field and the fingerprint field
are omitted for an "anonymous recipient" (see Section 5.1.8).
* A one octet key version number.
* The fingerprint of the public key or subkey to which the session
key is encrypted. Note that the length N of the fingerprint for a
version 4 key is 20 octets; for a version 6 key N is 32.
Perhaps (Section 5.1.2):
* A one-octet version number with value 6.
* A one-octet size of the following two fields; the size may be
zero, if the key version number and fingerprint fields
are omitted for an "anonymous recipient" (see Section 5.1.8):
- A key version number.
- The fingerprint of the public key or subkey to which the session
key is encrypted. Note that the length N of the fingerprint for a
version 4 key is 20 octets; for a version 6 key, N is 32.
...
Original (Section 5.1.6):
* 32 octets representing an ephemeral X25519 public key.</t>
<t>A key.
* A one-octet size of the following fields.</t>
<t>The fields.
* The one-octet algorithm identifier, if it was passed (in the case
of a v3 PKESK packet).</t>
<t>The packet).
* The encrypted session key.</t>
</list></t> key.
Perhaps (Section 5.1.6):
* 32 octets representing an ephemeral X25519 public key.
* A one-octet size of the following fields:
- The algorithm identifier, if it was passed (in the case
of a v3 PKESK packet).
- The encrypted session key.
...
Original (Section 5.3.2):
* A one-octet scalar octet count of the following field.
* A string-to-key (S2K) specifier. The length of the string-to-key
specifier depends on its type (see Section 3.7.1).
Perhaps (Section 5.3.2):
* A one-octet scalar octet count of the following field:
- An S2K specifier. The length of the S2K specifier
depends on its type (see Section 3.7.1).
...
Original (Section 5.5.5.4):
The public key is this series of values:
* A variable-length field containing a curve OID, which is formatted
as follows:
- A one-octet size of the following field; values 0 and 0xFF are
reserved for future extensions,
- The octets representing a curve OID (defined in Section 9.2);
Perhaps (Section 5.5.5.4):
The public key is this series of values:
* A variable-length field containing a curve OID, which is formatted
as:
- A one-octet size of the curve OID field; values 0 and 0xFF are
reserved for future extensions.
- A sequence of octets representing a curve OID, as defined in
Section 9.2.
-->
<ul spacing="normal">
<li>32 octets representing an ephemeral X25519 public key.
</li>
<li>A one-octet size of the following fields.
</li>
<li>The one-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet).
</li>
<li>The encrypted session key.
</li>
</ul>
<t>See <xref section="6.1" sectionFormat="of" target="RFC7748"/> for more details on the computation of the ephemeral public key and the shared secret.
HKDF (<xref target="RFC5869"/>) The HMAC-based Key Derivation Function (HKDF) <xref target="RFC5869"/> is then used with SHA256 <xref target="RFC6234"/> and an info parameter of "OpenPGP X25519" and no salt.
The input of HKDF is the concatenation of the following three values:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>32 octets of the ephemeral X25519 public key from this packet.</t>
</li>
<li>
<t>32 octets of the recipient public key material.</t>
</li>
<li>
<t>32 octets of the shared secret.</t>
</list></t>
</li>
</ul>
<t>The key produced from HKDF is used to encrypt the session key with AES-128 key wrap, as defined in <xref target="RFC3394"/>.</t>
<t>Note that unlike ECDH, Elliptic Curve Diffie-Hellman (ECDH), no checksum or padding are appended to the session key before key wrapping. Finally, note that unlike the other public-key algorithms, in the case of a v3 PKESK packet, the symmetric algorithm ID is not encrypted. Instead, it is prepended to the encrypted session key in plaintext.
In this case, the symmetric algorithm used <bcp14>MUST</bcp14> be AES-128, AES-192 AES-192, or AES-256 (algorithm ID IDs 7, 8 8, or 9).</t> 9, respectively).</t>
</section>
<section anchor="pkesk-x448"><name>Algorithm-Specific anchor="pkesk-x448">
<name>Algorithm-Specific Fields for X448 encryption</name>
<t><list style="symbols"> Encryption</name>
<ul spacing="normal">
<li>
<t>56 octets representing an ephemeral X448 public key.</t>
</li>
<li>
<t>A one-octet size of the following fields.</t>
</li>
<li>
<t>The one-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet).</t>
</li>
<li>
<t>The encrypted session key.</t>
</list></t>
</li>
</ul>
<t>See <xref section="6.2" sectionFormat="of" target="RFC7748"/> for more details on the computation of the ephemeral public key and the shared secret.
HKDF (<xref target="RFC5869"/>) <xref target="RFC5869"/> is then used with SHA512 (<xref target="RFC6234"/>) <xref target="RFC6234"/> and an info parameter of "OpenPGP X448" and no salt. The input of HKDF is the concatenation of the following three values:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>56 octets of the ephemeral X448 public key from this packet.</t>
</li>
<li>
<t>56 octets of the recipient public key material.</t>
</li>
<li>
<t>56 octets of the shared secret.</t>
</list></t>
</li>
</ul>
<t>The key produced from HKDF is used to encrypt the session key with AES-256 key wrap, as defined in <xref target="RFC3394"/>.</t>
<t>Note that unlike ECDH, no checksum or padding are appended to the session key before key wrapping.
Finally, note that unlike the other public-key algorithms, in the case of a v3 PKESK packet, the symmetric algorithm ID is not encrypted.
Instead, it is prepended to the encrypted session key in plaintext.
In this case, the symmetric algorithm used <bcp14>MUST</bcp14> be AES-128, AES-192 AES-192, or AES-256 (algorithm ID 7, 8 8, or 9).</t>
</section>
<section anchor="pkesk-notes"><name>Notes anchor="pkesk-notes">
<name>Notes on PKESK</name>
<t>An implementation <bcp14>MAY</bcp14> accept or use a Key ID of all zeros, or an omitted key fingerprint, to hide the intended decryption key.
In this case, the receiving implementation would try all available private keys, checking for a valid decrypted session key.
This format helps reduce traffic analysis of messages.</t>
</section>
</section>
<section anchor="signature-packet"><name>Signature anchor="signature-packet">
<name>Signature Packet (Type ID 2)</name>
<t>A Signature packet describes a binding between some public key and some data.
The most common signatures are a signature of a file or a block of text, text and a signature that is a certification of a User ID.</t>
<t>Three versions of Signature packets are defined.
Version 3 provides basic signature information, while versions 4 and 6 provide an expandable format with subpackets that can specify more information about the signature.</t>
<t>For historical reasons, versions 1, 2, and 5 of the Signature packet are unspecified.
Any new Signature packet version should be registered in the registry established in <xref target="signed-message-versions"/>.</t>
<t>An implementation <bcp14>MUST</bcp14> generate a version 6 signature when signing with a version 6 key.
An implementation <bcp14>MUST</bcp14> generate a version 4 signature when signing with a version 4 key.
Implementations <bcp14>MUST NOT</bcp14> create version 3 signatures; they <bcp14>MAY</bcp14> accept version 3 signatures.
See <xref target="signed-message-versions"/> for more details about packet version correspondence between keys and signatures.</t>
<section anchor="signature-types"><name>Signature anchor="signature-types">
<name>Signature Types</name>
<t>There are a number of possible meanings for a signature, which are indicated by the signature type ID in any given signature. Please note that the vagueness of these meanings is not a flaw, flaw but rather a feature of the system.
Because OpenPGP places final authority for validity upon the receiver of a signature, it may be that one signer's casual act might be more rigorous than some other authority's positive act.
See <xref target="computing-signatures"/> for detailed information on how to compute and verify signatures of each type.</t>
<texttable title="OpenPGP
<table anchor="signature-types-registry">
<name>OpenPGP Signature Types registry" anchor="signature-types-registry">
<ttcol align='left'>ID</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0x00</c>
<c>Binary Signature</c>
<c><xref target="sigtype-binary"/></c>
<c>0x01</c>
<c>Text Signature</c>
<c><xref target="sigtype-text"/></c>
<c>0x02</c>
<c>Standalone Signature</c>
<c><xref target="sigtype-standalone"/></c>
<c>0x10</c>
<c>Generic Certification</c>
<c><xref target="sigtype-generic-cert"/></c>
<c>0x11</c>
<c>Persona Certification</c>
<c><xref target="sigtype-persona-cert"/></c>
<c>0x12</c>
<c>Casual Certification</c>
<c><xref target="sigtype-casual-cert"/></c>
<c>0x13</c>
<c>Positive Certification</c>
<c><xref target="sigtype-positive-cert"/></c>
<c>0x18</c>
<c>Subkey Registry</name>
<thead>
<tr>
<th align="left">ID</th>
<th align="left">Name</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x00</td>
<td align="left">Binary Signature</td>
<td align="left">
<xref target="sigtype-binary"/></td>
</tr>
<tr>
<td align="left">0x01</td>
<td align="left">Text Signature</td>
<td align="left">
<xref target="sigtype-text"/></td>
</tr>
<tr>
<td align="left">0x02</td>
<td align="left">Standalone Signature</td>
<td align="left">
<xref target="sigtype-standalone"/></td>
</tr>
<tr>
<td align="left">0x10</td>
<td align="left">Generic Certification</td>
<td align="left">
<xref target="sigtype-generic-cert"/></td>
</tr>
<tr>
<td align="left">0x11</td>
<td align="left">Persona Certification</td>
<td align="left">
<xref target="sigtype-persona-cert"/></td>
</tr>
<tr>
<td align="left">0x12</td>
<td align="left">Casual Certification</td>
<td align="left">
<xref target="sigtype-casual-cert"/></td>
</tr>
<tr>
<td align="left">0x13</td>
<td align="left">Positive Certification</td>
<td align="left">
<xref target="sigtype-positive-cert"/></td>
</tr>
<tr>
<td align="left">0x18</td>
<td align="left">Subkey Binding Signature</c>
<c><xref target="sigtype-subkey-binding"/></c>
<c>0x19</c>
<c>Primary Signature</td>
<td align="left">
<xref target="sigtype-subkey-binding"/></td>
</tr>
<tr>
<td align="left">0x19</td>
<td align="left">Primary Key Binding Signature</c>
<c><xref target="sigtype-primary-binding"/></c>
<c>0x1F</c>
<c>Direct Key Signature</c>
<c><xref target="sigtype-direct-key"/></c>
<c>0x20</c>
<c>Key Revocation</c>
<c><xref target="sigtype-key-revocation"/></c>
<c>0x28</c>
<c>Subkey Revocation</c>
<c><xref target="sigtype-subkey-revocation"/></c>
<c>0x30</c>
<c>Certification Revocation</c>
<c><xref target="sigtype-certification-revocation"/></c>
<c>0x40</c>
<c>Timestamp Signature</c>
<c><xref target="sigtype-timestamp"/></c>
<c>0x50</c>
<c>Third-Party Confirmation</c>
<c><xref target="sigtype-third-party-confirmation"/></c>
<c>0xFF</c>
<c>Reserved</c>
<c><xref target="sigtype-reserved"/></c>
</texttable>
<t>These Signature</td>
<td align="left">
<xref target="sigtype-primary-binding"/></td>
</tr>
<tr>
<td align="left">0x1F</td>
<td align="left">Direct Key Signature</td>
<td align="left">
<xref target="sigtype-direct-key"/></td>
</tr>
<tr>
<td align="left">0x20</td>
<td align="left">Key Revocation</td>
<td align="left">
<xref target="sigtype-key-revocation"/></td>
</tr>
<tr>
<td align="left">0x28</td>
<td align="left">Subkey Revocation</td>
<td align="left">
<xref target="sigtype-subkey-revocation"/></td>
</tr>
<tr>
<td align="left">0x30</td>
<td align="left">Certification Revocation</td>
<td align="left">
<xref target="sigtype-certification-revocation"/></td>
</tr>
<tr>
<td align="left">0x40</td>
<td align="left">Timestamp Signature</td>
<td align="left">
<xref target="sigtype-timestamp"/></td>
</tr>
<tr>
<td align="left">0x50</td>
<td align="left">Third-Party Confirmation</td>
<td align="left">
<xref target="sigtype-third-party-confirmation"/></td>
</tr>
<tr>
<td align="left">0xFF</td>
<td align="left">Reserved</td>
<td align="left"><xref target="sigtype-reserved"/>
</td>
</tr>
</tbody>
</table>
<t>The meanings of each signature type are described in the subsections below.</t>
<!-- [rfced] Lead-in Sentences
a) Sections 5.1.3-5.1.7 and 5.2.3.1-5.2.3.5 begin with
formulas or lists rather than lead-in sentences. Would
you like to add any lead-in sentences to these sections
or leave it as is?
One example
Original:
5.1.4. Algorithm-Specific Fields for Elgamal encryption
* MPI of Elgamal (Diffie-Hellman) value g**k mod p.
* MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
...
b) In Sections 5.2.1.1 to 5.2.1.16, the lead-in sentences work off of
the titles. For clarity, may we update each lead-in sentence to
include the name of the signature type that is being described rather
than referring to it as "This signature", for example, or beginning a
sentence with "This means"?
One example
Original:
5.2.1.8. Subkey Binding Signature (type ID 0x18)
This signature is a statement by the top-level signing key that
indicates that it owns the subkey.
Perhaps:
5.2.1.8. Subkey Binding Signature (type ID 0x18)
The Subkey Binding Signature (type ID 0x18) is a statement by the
top-level signing key, indicating that it owns the subkey.
...
c) In Sections 5.2.3.11 to 5.2.3.36, the subpacket names are
included in the section titles but not in the lead-in sentences,
and some of the lead-in sentences are fragments (except for
Section 5.2.3.32, which includes the subpacket name). May we add
the subpacket names to the lead-in sentences for clarity and
consistency as shown below?
Two examples
Original:
5.2.3.11. Signature Creation Time
(4-octet time field)
The time the signature was made.
This subpacket MUST be present in the hashed area.
When generating this subpacket, it SHOULD be marked as critical.
Perhaps:
5.2.3.11. Signature Creation Time
(4-octet time field)
The Signature Creation Time subpacket denotes the time the signature
was made. This subpacket MUST be present in the hashed area. When
generating this subpacket, it SHOULD be marked as critical.
...
Original:
5.2.3.12. Issuer Key ID
(8-octet Key ID)
The OpenPGP Key ID of the key issuing the signature. If the version
of that key is greater than 4...
Perhaps:
5.2.3.12. Issuer Key ID
(8-octet Key ID)
The Issuer Key ID subpacket is the OpenPGP Key ID of the key issuing
the signature. If the version of that key is greater than 4...
-->
<section anchor="sigtype-binary"><name>Signature anchor="sigtype-binary">
<name>Signature of a binary document Binary Document (type ID 0x00)</name>
<t>This means the signer owns it, created it, or certifies that it has not been modified.</t>
</section>
<section anchor="sigtype-text"><name>Signature anchor="sigtype-text">
<name>Signature of a canonical text document Canonical Text Document (type ID 0x01)</name>
<t>This means the signer owns it, created it, or certifies that it has not been modified.
The signature is calculated over the text data with its line endings converted to <CR><LF>.</t>
</section>
<section anchor="sigtype-standalone"><name>Standalone signature anchor="sigtype-standalone">
<name>Standalone Signature (type ID 0x02)</name>
<t>This signature is a signature of only its own subpacket contents.
It is calculated identically to a signature over a zero-length binary document.
V3 standalone signatures <bcp14>MUST NOT</bcp14> be generated and <bcp14>MUST</bcp14> be ignored.</t>
</section>
<section anchor="sigtype-generic-cert"><name>Generic certification anchor="sigtype-generic-cert">
<name>Generic Certification of a User ID and Public-Key packet Packet (type ID 0x10)</name>
<t>The issuer of this certification does not make any particular assertion as to how well the certifier has checked that the owner of the key is in fact the person described by the User ID.</t>
</section>
<section anchor="sigtype-persona-cert"><name>Persona certification anchor="sigtype-persona-cert">
<name>Persona Certification of a User ID and Public-Key packet Packet (type ID 0x11)</name>
<t>The issuer of this certification has not done any verification of the claim that the owner of this key is the User ID specified.</t>
</section>
<section anchor="sigtype-casual-cert"><name>Casual certification anchor="sigtype-casual-cert">
<name>Casual Certification of a User ID and Public-Key packet Packet (type ID 0x12)</name>
<t>The issuer of this certification has done some casual verification of the claim of identity.</t>
</section>
<section anchor="sigtype-positive-cert"><name>Positive certification anchor="sigtype-positive-cert">
<name>Positive Certification of a User ID and Public-Key packet Packet (type ID 0x13)</name>
<t>The issuer of this certification has done substantial verification of the claim of identity.</t>
<t>Most OpenPGP implementations make their "key signatures" as generic (type ID 0x10) certifications. Some implementations can issue 0x11-0x13 certifications, but few differentiate between the types.</t>
</section>
<section anchor="sigtype-subkey-binding"><name>Subkey anchor="sigtype-subkey-binding">
<name>Subkey Binding Signature (type ID 0x18)</name>
<t>This signature is a statement by the top-level signing key that indicates key, indicating that it owns the subkey. This signature is calculated directly on the primary key and subkey, and not on any User ID or other packets. A signature that binds a signing subkey <bcp14>MUST</bcp14> have an Embedded Signature subpacket in this binding signature that contains a 0x19 signature made by the signing subkey on the primary key and subkey.</t>
</section>
<section anchor="sigtype-primary-binding"><name>Primary anchor="sigtype-primary-binding">
<name>Primary Key Binding Signature (type ID 0x19)</name>
<t>This signature is a statement by a signing subkey, indicating that it is owned by the primary key.
This signature is calculated the same way as a subkey binding signature (0x18): directly on the primary key and subkey, and not on any User ID or other packets.</t>
</section>
<section anchor="sigtype-direct-key"><name>Direct anchor="sigtype-direct-key">
<name>Direct Key Signature (type ID 0x1F)</name>
<t>This signature is calculated directly on a key.
It binds the information in the Signature subpackets to the key, key and is appropriate to be used for subpackets that provide information about the key, such as the Key Flags subpacket or the (deprecated) Revocation Key. Key subpacket.
It is also appropriate for statements that non-self certifiers want to make about the key itself, itself rather than the binding between a key and a name.</t>
</section>
<section anchor="sigtype-key-revocation"><name>Key revocation signature anchor="sigtype-key-revocation">
<name>Key Revocation Signature (type ID 0x20)</name>
<t>The
<t>This signature is calculated directly on the key being revoked.
A revoked key is not to be used. Only revocation signatures by the key being revoked, or by a (deprecated) Revocation Key, should be considered valid revocation signatures.</t>
</section>
<section anchor="sigtype-subkey-revocation"><name>Subkey revocation signature anchor="sigtype-subkey-revocation">
<name>Subkey Revocation Signature (type ID 0x28)</name>
<t>The
<t>This signature is calculated directly on the primary key and the subkey being revoked.
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 a (deprecated) Revocation Key, should be considered valid revocation signatures.</t>
</section>
<section anchor="sigtype-certification-revocation"><name>Certification revocation signature anchor="sigtype-certification-revocation">
<name>Certification Revocation Signature (type ID 0x30)</name>
<t>This signature revokes an earlier User ID certification signature (signature class 0x10 through 0x13) or direct key signature (0x1F).
It should be issued by the same key that issued the revoked signature or by a (deprecated) Revocation Key.
The signature is computed over the same data as the certification that it revokes, and it should have a later creation date than that certification.</t>
</section>
<section anchor="sigtype-timestamp"><name>Timestamp signature anchor="sigtype-timestamp">
<name>Timestamp Signature (type ID 0x40)</name>
<t>This signature is only meaningful for the timestamp contained in it.</t>
</section>
<section anchor="sigtype-third-party-confirmation"><name>Third-Party anchor="sigtype-third-party-confirmation">
<name>Third-Party Confirmation signature Signature (type ID 0x50)</name>
<t>This signature is a signature over some other OpenPGP Signature packet(s).
It is analogous to a notary seal on the signed data. A third-party signature <bcp14>SHOULD</bcp14> include a Signature Target subpacket(s) to give easy identification. Note that we really do mean <bcp14>SHOULD</bcp14>.
There are plausible uses for this (such as a blind party that only sees the signature, not the key or source document) that cannot include a target subpacket.</t>
</section>
<section anchor="sigtype-reserved"><name>Reserved anchor="sigtype-reserved">
<name>Reserved (type ID 0xFF)</name>
<t>An implementation <bcp14>MUST NOT</bcp14> create any signature with this type, type and <bcp14>MUST NOT</bcp14> validate any signature made with this type.
See <xref target="sig-computation-notes"/> for more details.</t>
</section>
</section>
<section anchor="version-three-sig"><name>Version anchor="version-three-sig">
<name>Version 3 Signature Packet Format</name>
<t>The body of a version 3 Signature packet contains:</t>
<t><list style="symbols">
<t>One-octet
<!-- [rfced] Section 5.2.2. FYI: We updated "(3)" to "with value 3" to
match other instances in the text. If this changes the meaning,
please let us know.
Original:
* One-octet version number (3).</t>
<t>One-octet (3).
Current
* A one-octet version number with value 3.
-->
<ul spacing="normal">
<li>
<t>A one-octet version number with value 3.</t>
</li>
<li>
<t>A one-octet length of the following hashed material. material; it
<bcp14>MUST</bcp14> be 5. <list style="symbols">
<t>One-octet 5: </t>
<ul spacing="normal">
<li>
<t>A one-octet signature type ID.</t>
<t>Four-octet
</li>
<li>
<t>A four-octet creation time.</t>
</list></t>
<t>Eight-octet
</li>
</ul>
</li>
<li>
<t>An eight-octet Key ID of the signer.</t>
<t>One-octet
</li>
<li>
<t>A one-octet public-key algorithm.</t>
<t>One-octet
</li>
<li>
<t>A one-octet hash algorithm.</t>
<t>Two-octet
</li>
<li>
<t>A two-octet field holding left 16 bits of the signed hash value.</t>
</li>
<li>
<t>One or more multiprecision integers MPIs comprising the signature. This portion is algorithm-specific, algorithm specific, as described below.</t>
</list></t>
</li>
</ul>
<t>The concatenation of the data to be signed, the signature type, and the creation time from the Signature packet (5 additional octets) is 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 Signature packet to provide a way to reject some invalid signatures without performing a signature verification.</t>
<t>Algorithm-Specific Fields
<t>Algorithm-specific fields for RSA signatures:</t>
<t><list style="symbols">
<t>Multiprecision integer (MPI)
<ul spacing="normal">
<li>
<t>MPI of RSA signature value m**d mod n.</t>
</list></t>
<t>Algorithm-Specific Fields
</li>
</ul>
<t>Algorithm-specific fields for DSA signatures:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>MPI of DSA value r.</t>
</li>
<li>
<t>MPI of DSA value s.</t>
</list></t>
</li>
</ul>
<t>The signature calculation is based on a hash of the signed data, as described above.
The details of the calculation are different for DSA signatures than for RSA signatures, signatures; see Sections <xref target="sig-rsa"/> target="sig-rsa" format="counter"/> and <xref target="sig-dsa"/>.</t> target="sig-dsa" format="counter"/>.</t>
</section>
<section anchor="version-four-and-six-sig"><name>Version anchor="version-four-and-six-sig">
<name>Versions 4 and 6 Signature Packet Formats</name>
<t>The body of a v4 or v6 Signature packet contains:</t>
<t><list style="symbols">
<t>One-octet
<ul spacing="normal">
<li>
<t>A one-octet version number.
This is 4 for v4 signatures and 6 for v6 signatures.</t>
<t>One-octet
</li>
<li>
<t>A one-octet signature type ID.</t>
<t>One-octet
</li>
<li>
<t>A one-octet public-key algorithm.</t>
<t>One-octet
</li>
<li>
<t>A one-octet hash algorithm.</t>
</li>
<li>
<t>A scalar Scalar octet count for the hashed subpacket data that follows this field. For a v4 signature, this is a two-octet field.
For a v6 signature, this is a four-octet field.
Note that this is the length in octets of all of the hashed subpackets; an implementation's pointer incremented by this number will skip over the hashed subpackets.</t>
<t>Hashed
</li>
<li>
<t>A hashed subpacket data set (zero or more subpackets).</t>
</li>
<li>
<t>A scalar octet count for the unhashed subpacket data that follows this field.
For a v4 signature, this is a two-octet field.
For a v6 signature, this is a four-octet field.
Note that this is the length in octets of all of the unhashed subpackets; an implementation's pointer incremented by this number will skip over the unhashed subpackets.</t>
<t>Unhashed
</li>
<li>
<t>An unhashed subpacket data set (zero or more subpackets).</t>
<t>Two-octet
</li>
<li>
<t>A two-octet field holding the left 16 bits of the signed hash value.</t>
</li>
<li>
<t>Only for v6 signatures, a variable-length field containing: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>A one-octet salt size. The value <bcp14>MUST</bcp14> match the value defined for the hash algorithm as specified in <xref target="hash-algorithms-registry"/>.</t>
</li>
<li>
<t>The salt; salt, which is a random value of the specified size.</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>One or more multiprecision integers MPIs comprising the signature.
This portion is algorithm-specific:</t>
</list></t> algorithm specific.</t>
</li>
</ul>
<section anchor="sig-rsa"><name>Algorithm-Specific anchor="sig-rsa">
<name>Algorithm-Specific Fields for RSA signatures</name>
<t><list style="symbols">
<t>Multiprecision integer (MPI) Signatures</name>
<ul spacing="normal">
<li>
<t>MPI of RSA signature value m**d mod n.</t>
</list></t>
</li>
</ul>
<t>With RSA signatures, the hash value is encoded using PKCS#1 encoding type EMSA-PKCS1-v1_5 EMSA-PKCS1-v1_5, as described in <xref section="9.2" sectionFormat="of" target="RFC8017"/> (see also <xref target="emsa-pkcs1-v1-5"/>).
This requires inserting the hash value as an octet string into an ASN.1 structure.
The object identifier (OID) for the hash algorithm itself is also included in the structure, structure; see the OIDs in <xref target="emsa-hash-oids-registry"/>.</t>
</section>
<section anchor="sig-dsa"><name>Algorithm-Specific anchor="sig-dsa">
<name>Algorithm-Specific Fields for DSA or ECDSA signatures</name>
<t><list style="symbols"> Signatures</name>
<ul spacing="normal">
<li>
<t>MPI of DSA or ECDSA value r.</t>
</li>
<li>
<t>MPI of DSA or ECDSA value s.</t>
</list></t>
</li>
</ul>
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp14>MUST NOT</bcp14> be used with ECDSA.</t> the Elliptic Curve Digital Signature Algorithm (ECDSA).</t>
<t>A DSA signature <bcp14>MUST</bcp14> use a hash algorithm with a digest size of at least the number of bits of q, the group generated by the DSA key's generator value.</t>
<t>If the output size of the chosen hash is larger than the number of bits of q, the hash result is truncated to fit by taking the number of leftmost bits equal to the number of bits of q.
This (possibly truncated) hash function result is treated as a number and used directly in the DSA signature algorithm.</t>
<t>An ECDSA signature <bcp14>MUST</bcp14> use a hash algorithm with a digest size of at least the curve's "fsize" value (see <xref target="ec-curves"/>), except in the case of NIST P-521, for which at least a 512-bit hash algorithm <bcp14>MUST</bcp14> be used.</t>
</section>
<section anchor="sig-eddsa-legacy"><name>Algorithm-Specific anchor="sig-eddsa-legacy">
<name>Algorithm-Specific Fields for EdDSALegacy signatures (deprecated)</name>
<t><list style="symbols"> Signatures (Deprecated)</name>
<ul spacing="normal">
<li>
<t>Two MPI-encoded values, whose contents and formatting depend on the choice of curve used (see <xref target="curve-specific-formats"/>).</t>
</list></t>
</li>
</ul>
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp14>MUST NOT</bcp14> be used with EdDSALegacy.</t>
<t>An EdDSALegacy signature <bcp14>MUST</bcp14> use a hash algorithm with a digest size of at least the curve's "fsize" value (see <xref target="ec-curves"/>).
A verifying implementation <bcp14>MUST</bcp14> reject any EdDSALegacy signature that uses a hash algorithm with a smaller digest size.</t>
<section anchor="algorithm-specific-fields-for-ed25519legacy-signatures-deprecated"><name>Algorithm-Specific anchor="algorithm-specific-fields-for-ed25519legacy-signatures-deprecated">
<name>Algorithm-Specific Fields for Ed25519Legacy signatures (deprecated)</name> Signatures (Deprecated)</name>
<t>The two MPIs for Ed25519Legacy use octet strings R and S as described in <xref target="RFC8032"/>.
Ed25519Legacy <bcp14>MUST NOT</bcp14> be used in signature packets version 6 or above.</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>MPI of an EC point R, represented as a (non-prefixed) native (little-endian) octet string up to 32 octets.</t>
</li>
<li>
<t>MPI of EdDSA the Edwards-curve Digital Signature Algorithm (EdDSA) value S, also in (non-prefixed) native (little-endian) format with a length up to 32 octets.</t>
</list></t>
</li>
</ul>
</section>
</section>
<section anchor="sig-ed25519"><name>Algorithm-Specific anchor="sig-ed25519">
<name>Algorithm-Specific Fields for Ed25519 signatures</name>
<t><list style="symbols"> Signatures</name>
<ul spacing="normal">
<li>
<t>64 octets of the native signature.</t>
</list></t>
</li>
</ul>
<t>For more details, see <xref target="eddsa-notes"/>.</t>
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp14>MUST NOT</bcp14> be used with Ed25519.</t>
<t>An Ed25519 signature <bcp14>MUST</bcp14> use a hash algorithm with a digest size of at least 256 bits.
A verifying implementation <bcp14>MUST</bcp14> reject any Ed25519 signature that uses a hash algorithm with a smaller digest size.</t>
</section>
<section anchor="sig-ed448"><name>Algorithm-Specific anchor="sig-ed448">
<name>Algorithm-Specific Fields for Ed448 signatures</name>
<t><list style="symbols"> Signatures</name>
<ul spacing="normal">
<li>
<t>114 octets of the native signature.</t>
</list></t>
</li>
</ul>
<t>For more details, see <xref target="eddsa-notes"/>.</t>
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp14>MUST NOT</bcp14> be used with Ed448.</t>
<t>An Ed448 signature <bcp14>MUST</bcp14> use a hash algorithm with a digest size of at least 512 bits.
A verifying implementation <bcp14>MUST</bcp14> reject any Ed448 signature that uses a hash algorithm with a smaller digest size.</t>
</section>
<section anchor="notes-on-signatures"><name>Notes anchor="notes-on-signatures">
<name>Notes on Signatures</name>
<t>The concatenation of the data being signed, the signature data from the version number through the hashed subpacket data (inclusive), and (for signature versions later than 3) a six-octet trailer (see <xref target="computing-signatures"/>) is are hashed. The resulting hash value is what is signed. The high 16 bits (first two octets) of the hash are included in the Signature packet to provide a way to reject some invalid signatures without performing a signature verification. When verifying a v6 signature, an implementation <bcp14>MUST</bcp14> reject the signature if these octets don't do not match the first two octets of the computed hash.</t>
<t>There are two fields consisting of Signature subpackets.
The first field is hashed with the rest of the signature data, while the second is not hashed into the signature. The second set of subpackets (the "unhashed section") is not cryptographically protected by the signature and should include only advisory information. See <xref target="subpacket-section-guidance"/> for more information.</t>
<t>The differences between a v4 and v6 signature are two-fold: first, a v6 signature increases the width of the fields that indicate the size of the hashed and unhashed subpackets, making it possible to include significantly more data in subpackets.
Second, the hash is salted with random data (see <xref target="signature-salt-rationale"/>).</t>
<t>The algorithms for converting the hash function result to a signature are described in <xref target="computing-signatures"/>.</t>
</section>
<section anchor="signature-subpacket"><name>Signature anchor="signature-subpacket">
<name>Signature Subpacket Specification</name>
<t>A subpacket data set consists of zero or more Signature subpackets.
In Signature packets, the subpacket data set is preceded by a two-octet (for v4 signatures) or four-octet (for v6 signatures) scalar count of the length in octets of all the subpackets.
A pointer incremented by this number will skip over the subpacket data set.</t>
<t>Each subpacket consists of a subpacket header and a body.
The header consists of:</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>
<t>the subpacket length (1, 2, or 5 octets),</t>
<t>The octets)</t>
</li>
<li>
<t>the encoded subpacket type ID (1 octet),</t>
</list></t> octet)</t>
</li>
</ul>
<t>and is followed by the subpacket-specific data.</t>
<!-- [rfced] In the following sentence, please clarify what "but not
this length" refers to.
Original:
The length includes the encoded subpacket type ID octet but
not this length. Its format is similar to the OpenPGP format packet
header lengths, but cannot have Partial Body Lengths.
-->
<t>The length includes the encoded subpacket type ID octet but not this length. Its format is similar to the OpenPGP format packet header lengths, but it cannot have Partial Body Lengths. That is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
if the 1st octet < 192, then
lengthOfLength = 1
subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then
lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then
lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet]
]]></artwork></figure>
]]></artwork>
<t>Bit 7 of the encoded subpacket type ID is the "critical" bit.
If set, it denotes that the subpacket is one that is critical for the evaluator of the signature to recognize. If a subpacket is encountered that is marked critical but is unknown to the evaluating implementation, the evaluator <bcp14>SHOULD</bcp14> consider the signature to be in error.</t>
<t>An implementation <bcp14>SHOULD</bcp14> ignore any non-critical subpacket of a type that it does not recognize.</t>
<t>An evaluator may "recognize" a subpacket, subpacket but not implement it.
The purpose of the critical bit is to allow the signer to tell an evaluator that it would prefer a new, unknown feature to generate an error rather than being ignored.</t>
<t>The other bits of the encoded subpacket type ID (i.e. (i.e., bits 6-0) contain the subpacket type ID.</t>
<t>The following signature subpackets are defined:</t>
<texttable title="OpenPGP
<table anchor="signature-subpacket-types-registry">
<name>OpenPGP Signature Subpacket Types registry" anchor="signature-subpacket-types-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0</c>
<c>Reserved</c>
<c> </c>
<c>1</c>
<c>Reserved</c>
<c> </c>
<c>2</c>
<c>Signature Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">0</td>
<td align="left">Reserved</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">1</td>
<td align="left">Reserved</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">Signature Creation Time</c>
<c><xref target="signature-creation-subpacket"/></c>
<c>3</c>
<c>Signature Time</td>
<td align="left">[RFC9580],
<xref target="signature-creation-subpacket"/></td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">Signature Expiration Time</c>
<c><xref target="signature-expiration-subpacket"/></c>
<c>4</c>
<c>Exportable Certification</c>
<c><xref target="exportable-certification-subpacket"/></c>
<c>5</c>
<c>Trust Signature</c>
<c><xref target="trust-signature-subpacket"/></c>
<c>6</c>
<c>Regular Expression</c>
<c><xref target="regex-subpacket"/></c>
<c>7</c>
<c>Revocable</c>
<c><xref target="revocable-subpacket"/></c>
<c>8</c>
<c>Reserved</c>
<c> </c>
<c>9</c>
<c>Key Time</td>
<td align="left">[RFC9580],
<xref target="signature-expiration-subpacket"/></td>
</tr>
<tr>
<td align="right">4</td>
<td align="left">Exportable Certification</td>
<td align="left">[RFC9580],
<xref target="exportable-certification-subpacket"/></td>
</tr>
<tr>
<td align="right">5</td>
<td align="left">Trust Signature</td>
<td align="left">[RFC9580],
<xref target="trust-signature-subpacket"/></td>
</tr>
<tr>
<td align="right">6</td>
<td align="left">Regular Expression</td>
<td align="left">[RFC9580],
<xref target="regex-subpacket"/></td>
</tr>
<tr>
<td align="right">7</td>
<td align="left">Revocable</td>
<td align="left">[RFC9580],
<xref target="revocable-subpacket"/></td>
</tr>
<tr>
<td align="right">8</td>
<td align="left">Reserved</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">9</td>
<td align="left">Key Expiration Time</c>
<c><xref target="key-expiration-subpacket"/></c>
<c>10</c>
<c>Placeholder Time</td>
<td align="left">[RFC9580],
<xref target="key-expiration-subpacket"/></td>
</tr>
<tr>
<td align="right">10</td>
<td align="left">Placeholder for backward compatibility</c>
<c> </c>
<c>11</c>
<c>Preferred compatibility</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">11</td>
<td align="left">Preferred Symmetric Ciphers for v1 SEIPD</c>
<c><xref target="preferred-v1-seipd"/></c>
<c>12</c>
<c>Revocation Key (deprecated)</c>
<c><xref target="revocation-key"/></c>
<c>13 to 15</c>
<c>Reserved</c>
<c> </c>
<c>16</c>
<c>Issuer Key ID</c>
<c><xref target="issuer-keyid-subpacket"/></c>
<c>17 to 19</c>
<c>Reserved</c>
<c> </c>
<c>20</c>
<c>Notation Data</c>
<c><xref target="notation-data"/></c>
<c>21</c>
<c>Preferred SEIPD</td>
<td align="left">[RFC9580],
<xref target="preferred-v1-seipd"/></td>
</tr>
<tr>
<td align="right">12</td>
<td align="left">Revocation Key (deprecated)</td>
<td align="left">[RFC9580],
<xref target="revocation-key"/></td>
</tr>
<tr>
<td align="right">13-15</td>
<td align="left">Reserved</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">16</td>
<td align="left">Issuer Key ID</td>
<td align="left">[RFC9580],
<xref target="issuer-keyid-subpacket"/></td>
</tr>
<tr>
<td align="right">17-19</td>
<td align="left">Reserved</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">20</td>
<td align="left">Notation Data</td>
<td align="left">[RFC9580],
<xref target="notation-data"/></td>
</tr>
<tr>
<td align="right">21</td>
<td align="left">Preferred Hash Algorithms</c>
<c><xref target="preferred-hashes-subpacket"/></c>
<c>22</c>
<c>Preferred Algorithms</td>
<td align="left">[RFC9580],
<xref target="preferred-hashes-subpacket"/></td>
</tr>
<tr>
<td align="right">22</td>
<td align="left">Preferred Compression Algorithms</c>
<c><xref target="preferred-compression-subpacket"/></c>
<c>23</c>
<c>Key Algorithms</td>
<td align="left">[RFC9580],
<xref target="preferred-compression-subpacket"/></td>
</tr>
<tr>
<td align="right">23</td>
<td align="left">Key Server Preferences</c>
<c><xref target="key-server-preferences"/></c>
<c>24</c>
<c>Preferred Key Server</c>
<c><xref target="preferred-key-server-subpacket"/></c>
<c>25</c>
<c>Primary User ID</c>
<c><xref target="primary-user-id-subpacket"/></c>
<c>26</c>
<c>Policy URI</c>
<c><xref target="policy-uri-subpacket"/></c>
<c>27</c>
<c>Key Flags</c>
<c><xref target="key-flags"/></c>
<c>28</c>
<c>Signer's User ID</c>
<c><xref target="signers-user-id-subpacket"/></c>
<c>29</c>
<c>Reason for Revocation</c>
<c><xref target="reason-for-revocation"/></c>
<c>30</c>
<c>Features</c>
<c><xref target="features-subpacket"/></c>
<c>31</c>
<c>Signature Target</c>
<c><xref target="signature-target-subpacket"/></c>
<c>32</c>
<c>Embedded Signature</c>
<c><xref target="embedded-signature-subpacket"/></c>
<c>33</c>
<c>Issuer Fingerprint</c>
<c><xref target="issuer-fingerprint-subpacket"/></c>
<c>34</c>
<c>Reserved</c>
<c> </c>
<c>35</c>
<c>Intended Preferences</td>
<td align="left">[RFC9580],
<xref target="key-server-preferences"/></td>
</tr>
<tr>
<td align="right">24</td>
<td align="left">Preferred Key Server</td>
<td align="left">[RFC9580],
<xref target="preferred-key-server-subpacket"/></td>
</tr>
<tr>
<td align="right">25</td>
<td align="left">Primary User ID</td>
<td align="left">[RFC9580],
<xref target="primary-user-id-subpacket"/></td>
</tr>
<tr>
<td align="right">26</td>
<td align="left">Policy URI</td>
<td align="left">[RFC9580],
<xref target="policy-uri-subpacket"/></td>
</tr>
<tr>
<td align="right">27</td>
<td align="left">Key Flags</td>
<td align="left">[RFC9580],
<xref target="key-flags"/></td>
</tr>
<tr>
<td align="right">28</td>
<td align="left">Signer's User ID</td>
<td align="left">[RFC9580],
<xref target="signers-user-id-subpacket"/></td>
</tr>
<tr>
<td align="right">29</td>
<td align="left">Reason for Revocation</td>
<td align="left">[RFC9580],
<xref target="reason-for-revocation"/></td>
</tr>
<tr>
<td align="right">30</td>
<td align="left">Features</td>
<td align="left">[RFC9580],
<xref target="features-subpacket"/></td>
</tr>
<tr>
<td align="right">31</td>
<td align="left">Signature Target</td>
<td align="left">[RFC9580],
<xref target="signature-target-subpacket"/></td>
</tr>
<tr>
<td align="right">32</td>
<td align="left">Embedded Signature</td>
<td align="left">[RFC9580],
<xref target="embedded-signature-subpacket"/></td>
</tr>
<tr>
<td align="right">33</td>
<td align="left">Issuer Fingerprint</td>
<td align="left">[RFC9580],
<xref target="issuer-fingerprint-subpacket"/></td>
</tr>
<tr>
<td align="right">34</td>
<td align="left">Reserved</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">35</td>
<td align="left">Intended Recipient Fingerprint</c>
<c><xref target="intended-recipient-fingerprint"/></c>
<c>37</c>
<c>Reserved Fingerprint</td>
<td align="left">[RFC9580],
<xref target="intended-recipient-fingerprint"/></td>
</tr>
<tr>
<td align="right">37</td>
<td align="left">Reserved (Attested Certifications)</c>
<c> </c>
<c>38</c>
<c>Reserved Certifications)</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">38</td>
<td align="left">Reserved (Key Block)</c>
<c> </c>
<c>39</c>
<c>Preferred AEAD Ciphersuites</c>
<c><xref target="preferred-v2-seipd"/></c>
<c>100 to 110</c>
<c>Private or experimental</c>
<c> </c>
</texttable> Block)</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="right">39</td>
<td align="left">Preferred AEAD Ciphersuites</td>
<td align="left">[RFC9580],
<xref target="preferred-v2-seipd"/></td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private or Experimental</td>
<td align="left">[RFC9580] </td>
</tr>
</tbody>
</table>
<t>Implementations <bcp14>SHOULD</bcp14> implement the four preferred algorithm subpackets (11, 21, 22, and 39), as well as the "Features" subpacket (30) and the "Reason for Revocation" subpacket. (29) subpackets.
To avoid surreptitious forwarding (see <xref target="surreptitious-forwarding"/>), implementations <bcp14>SHOULD</bcp14> also implement the "Intended Recipients" Recipients Fingerprint" (35) subpacket.
Note that if an implementation chooses not to implement some of the preferences subpackets, it <bcp14>MUST</bcp14> default to the mandatory-to-implement algorithms to ensure interoperability.
An encrypting implementation that does not implement the "Features" (30) subpacket <bcp14>SHOULD</bcp14> select the type of encrypted data format based instead on the versions of the recipient keys or external inference (see <xref target="ciphertext-malleability"/> for more details).</t>
</section>
<section anchor="signature-subpacket-types"><name>Signature anchor="signature-subpacket-types">
<name>Signature Subpacket Types</name>
<t>A number of subpackets are currently defined for OpenPGP signatures.
Some subpackets apply to the signature itself and some are attributes of the key.
Subpackets that are found on a self-signature are placed on a certification made by the key itself.
Note that a key may have more than one User ID, ID and thus may have more than one self-signature, self-signature and differing subpackets.</t>
<t>A subpacket may be found either in either the hashed or the unhashed subpacket sections of a signature.
<!-- [rfced] Is "signature proper" correct in the following sentence,
or should it perhaps be "signature property" or "proper
signature"?
Original:
If a subpacket is not hashed, then the information in it
cannot be considered definitive because it is not part of
the signature proper.
-->
If a subpacket is not hashed, then the information in it cannot be considered definitive because it is not part of the signature proper. See <xref target="subpacket-section-guidance"/> for more discussion about hashed and unhashed subpackets.</t>
</section>
<section anchor="notes-on-subpackets"><name>Notes anchor="notes-on-subpackets">
<name>Notes on Subpackets</name>
<t>It is certainly possible for a signature to contain conflicting information in subpackets.
For example, a signature may contain multiple copies of a preference or multiple expiration times.
<!-- [rfced] Is "wishy-washy" the best description of "language" in
this sentence, or could "weak" or "ambiguous" be used instead for
clarity?
Original:
Please note that we are intentionally leaving conflict resolution
to the implementer; most conflicts are simply syntax errors, and
the wishy-washy language here allows a receiver to be generous
in what they accept, while putting pressure on a creator to be
stingy in what they generate.
-->
In most cases, an implementation <bcp14>SHOULD</bcp14> use the last subpacket in the hashed section of the signature, but it <bcp14>MAY</bcp14> use any conflict resolution scheme that makes more sense. Please note that we are intentionally leaving conflict resolution to the implementer; most conflicts are simply syntax errors, and the wishy-washy language here allows a receiver to be generous in what they accept, while putting pressure on a creator to be stingy in what they generate.</t>
<t>Some apparent conflicts may actually make sense --- for sense. For example, suppose a keyholder has a v3 key and a v4 key that share the same RSA key material. Either of these keys can verify a signature created by the other, and it may be reasonable for a signature to contain an Issuer Key ID subpacket (<xref target="issuer-keyid-subpacket"/>) for each key, as a way of explicitly tying those keys to the signature.</t>
</section>
<section anchor="self-sigs"><name>Notes anchor="self-sigs">
<name>Notes on Self-Signatures</name>
<t>A self-signature is a binding signature made by the key to which the signature refers. There are three types of self-signatures, self-signatures: the certification signatures (type IDs 0x10-0x13), the direct key signature (type ID 0x1F), and the subkey binding signature (type ID 0x18). A cryptographically-valid cryptographically valid self-signature should be accepted from any primary key, regardless of what Key Flags (<xref target="key-flags"/>) apply to the primary key.
In particular, a primary key does not need to have 0x01 set in the first octet of the Key Flags order to make a valid self-signature.</t>
<t>For certification self-signatures, each User ID <bcp14>MAY</bcp14> have a self-signature, self-signature and thus different subpackets in those self-signatures.
For subkey binding signatures, each subkey <bcp14>MUST</bcp14> have a self-signature.
Subpackets that appear in a certification self-signature apply to the User ID, and subpackets that appear in the subkey self-signature apply to the subkey.
Lastly, subpackets on the direct key signature apply to the entire key.</t>
<t>An implementation should interpret a self-signature's preference subpackets as narrowly as possible.
For example, suppose a key has two user names, Alice and Bob.
Suppose that Alice prefers the AEAD ciphersuite AES-256 with OCB, and Bob prefers Camellia-256 with GCM. Galois/Counter Mode (GCM). If the implementation locates this key via Alice's name, then the preferred AEAD ciphersuite is AES-256 with OCB; if the implementation locates the key via Bob's name, then the preferred algorithm is Camellia-256 with GCM.
If the key is located by Key ID, the algorithm of the primary User ID of the key provides the preferred AEAD ciphersuite.</t>
<t>Revoking a self-signature or allowing it to expire has a semantic meaning that varies with the signature type.
Revoking the self-signature on a User ID effectively retires that user name.
The self-signature is a statement, "My name X is tied to my signing key K" K", and it is corroborated by other users' certifications.
If another user revokes their certification, they are effectively saying that they no longer believe that name and that key are tied together.
Similarly, if the users themselves revoke their self-signature, then the users no longer go by that name, no longer have that email address, etc.
Revoking a binding signature effectively retires that subkey. Revoking a direct key signature cancels that signature.
Please see <xref target="reason-for-revocation"/> for more relevant detail.</t> details.</t>
<t>Since a self-signature contains important information about the key's use, an implementation <bcp14>SHOULD</bcp14> allow the user to rewrite the self-signature, self-signature and important information in it, such as preferences and key expiration.</t>
<t>When an implementation imports a secret key, it <bcp14>SHOULD</bcp14> verify that the key's internal self-signatures do not advertise features or algorithms that the implementation doesn't support.
If an implementation observes such a mismatch, it <bcp14>SHOULD</bcp14> warn the user and offer to create new self-signatures that advertise the actual set of features and algorithms supported by the implementation.</t>
<t>An implementation that encounters multiple self-signatures on the same object <bcp14>MUST</bcp14> select the most recent valid self-signature, self-signature and ignore all other self-signatures.</t>
<t>By convention, a version 4 key stores information about the primary Public-Key (key flags, key expiration, etc.) and the Transferable Public Key as a whole (features, algorithm preferences, etc.) in a User ID self-signature of type 0x10 or 0x13.
Some To use a v4 key,
some implementations require at least one User ID with a valid self-signature to be present to use a v4 key. present.
For this reason, it is <bcp14>RECOMMENDED</bcp14> to include at least one User ID with a self-signature in v4 keys.</t>
<t>For version 6 keys, it is <bcp14>RECOMMENDED</bcp14> to store information about the primary Public-Key as well as the Transferable Public Key as a whole (key flags, key expiration, features, algorithm preferences, etc.) in a direct key signature (type ID 0x1F) over the Public-Key Public-Key, instead of placing that information in a User ID self-signature.
An implementation <bcp14>MUST</bcp14> ensure that a valid direct key signature is present before using a v6 key.
This prevents certain attacks where an adversary strips a self-signature specifying a key expiration time or certain preferences.</t>
<t>An implementation <bcp14>SHOULD NOT</bcp14> require a User ID self-signature to be present in order to consume or use a key, unless the particular use is contingent on the keyholder identifying themselves with the textual label in the User ID.
For example, when refreshing a key to learn about changes in expiration, advertised features, algorithm preferences, revocation, subkey rotation, and so forth, there is no need to require a User ID self-signature. On the other hand, when verifying a signature over an e-mail email message, an implementation <bcp14>MAY</bcp14> choose to only accept a signature from a key that has a valid self-signature over a User ID that matches the message's From: header, as a way to avoid a signature transplant attack.</t>
</section>
<section anchor="signature-creation-subpacket"><name>Signature anchor="signature-creation-subpacket">
<name>Signature Creation Time</name>
<t>(4-octet time field)</t>
<t>The time the signature was made.</t>
<t>This subpacket <bcp14>MUST</bcp14> be present in the hashed area.</t>
<t>When generating this subpacket, it <bcp14>SHOULD</bcp14> be marked as critical.</t>
</section>
<section anchor="issuer-keyid-subpacket"><name>Issuer anchor="issuer-keyid-subpacket">
<name>Issuer Key ID</name>
<t>(8-octet Key ID)</t>
<t>The OpenPGP Key ID of the key issuing the signature.
If the version of that key is greater than 4, this subpacket <bcp14>MUST NOT</bcp14> be included in the signature.
For these keys, consider the Issuer Fingerprint subpacket (<xref target="issuer-fingerprint-subpacket"/>) instead.</t>
<!-- [rfced] Please review whether any of the notes or usage notes in
this document should be in the <aside> element. It is defined as
"a container for content that is semantically less important or
tangential to the content that surrounds it"
(https://authors.ietf.org/en/rfcxml-vocabulary#aside).
-->
<t>Note: in previous versions of this specification, this subpacket was simply known as the "Issuer" subpacket.</t>
</section>
<section anchor="key-expiration-subpacket"><name>Key anchor="key-expiration-subpacket">
<name>Key Expiration Time</name>
<t>(4-octet time field)</t>
<t>The validity period of the key.
This is the number of seconds after the key creation time that the key expires.
For a direct or certification self-signature, the key creation time is that of the primary key.
For a subkey binding signature, the key creation time is that of the subkey.
If this is not present or has a value of zero, the key never expires.
This is found only on a self-signature.</t>
<t>When an implementation generates this subpacket, it <bcp14>SHOULD</bcp14> be marked as critical.</t>
</section>
<section anchor="preferred-v1-seipd"><name>Preferred anchor="preferred-v1-seipd">
<name>Preferred Symmetric Ciphers for v1 SEIPD</name>
<t>(array of one-octet values)</t>
<t>A series of symmetric cipher algorithm IDs indicating how the keyholder prefers to receive version 1 Symmetrically Encrypted Integrity Protected Data (<xref target="version-one-seipd"/>).
The subpacket body is an ordered list of octets with the most preferred listed first.
It is assumed that only the algorithms listed are supported by the recipient's implementation.
Algorithm IDs are defined in <xref target="symmetric-algos"/>.
This is only found on a self-signature.</t>
<t>When generating a v2 SEIPD packet, this preference list is not relevant.
See <xref target="preferred-v2-seipd"/> instead.</t>
</section>
<section anchor="preferred-v2-seipd"><name>Preferred anchor="preferred-v2-seipd">
<name>Preferred AEAD Ciphersuites</name>
<t>(array of pairs of octets indicating Symmetric Cipher and AEAD algorithms)</t>
<t>A series of paired algorithm IDs indicating how the keyholder prefers to receive version 2 Symmetrically Encrypted Integrity Protected Data (<xref target="version-two-seipd"/>).
Each pair of octets indicates a combination of a symmetric cipher and an AEAD mode that the keyholder prefers to use.
The symmetric cipher algorithm ID precedes the AEAD algorithm ID in each pair.
The subpacket body is an ordered list of pairs of octets with the most preferred algorithm combination listed first.</t>
<t>It is assumed that only the combinations of algorithms listed are supported by the recipient's implementation, with the exception of the mandatory-to-implement combination of AES-128 and OCB.
If AES-128 and OCB are not found in the subpacket, it is implicitly listed at the end.</t>
<t>AEAD algorithm IDs are listed in <xref target="aead-algorithms"/>.
Symmetric cipher algorithm IDs are listed in <xref target="symmetric-algos"/>.</t>
<t>For example, a subpacket with the content of these six octets:</t>
<figure><artwork><![CDATA[ octets</t>
<artwork><![CDATA[
09 02 09 03 13 02
]]></artwork></figure>
<t>Indicates
]]></artwork>
<t>indicates that the keyholder prefers to receive v2 SEIPD using AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB, and finally the implicit AES-128 with OCB.</t>
<t>Note that support for version 2 of the Symmetrically Encrypted Integrity Protected Data packet (<xref target="version-two-seipd"/>) in general is indicated by a Features Flag (<xref target="features-subpacket"/>).</t>
<t>This subpacket is only found on a self-signature.</t>
<t>When generating a v1 SEIPD packet, this preference list is not relevant.
See <xref target="preferred-v1-seipd"/> instead.</t>
</section>
<section anchor="preferred-hashes-subpacket"><name>Preferred anchor="preferred-hashes-subpacket">
<name>Preferred Hash Algorithms</name>
<t>(array of one-octet values)</t>
<t>Message digest algorithm IDs that indicate which algorithms the keyholder prefers to receive.
Like the preferred AEAD ciphersuites, the list is ordered.
Algorithm IDs are defined in <xref target="hash-algos"/>.
This is only found on a self-signature.</t>
</section>
<section anchor="preferred-compression-subpacket"><name>Preferred anchor="preferred-compression-subpacket">
<name>Preferred Compression Algorithms</name>
<t>(array of one-octet values)</t>
<t>Compression algorithm IDs that indicate which algorithms the keyholder prefers to use.
Like the preferred AEAD ciphersuites, the list is ordered.
Algorithm IDs are defined in <xref target="compression-algos"/>.
A zero, or the absence of this subpacket, denotes that uncompressed data is preferred; the keyholder's implementation might have no compression support available.
This is only found on a self-signature.</t>
</section>
<section anchor="signature-expiration-subpacket"><name>Signature anchor="signature-expiration-subpacket">
<name>Signature Expiration Time</name>
<t>(4-octet time field)</t>
<t>The validity period of the signature.
This is the number of seconds after the signature creation time that the signature expires.
If this is not present or has a value of zero, it never expires.</t>
<t>When an implementation generates this subpacket, it <bcp14>SHOULD</bcp14> be marked as critical.</t>
</section>
<section anchor="exportable-certification-subpacket"><name>Exportable anchor="exportable-certification-subpacket">
<name>Exportable Certification</name>
<t>(1 octet of exportability, 0 for not, 1 for exportable)</t>
<t>This
<!-- [rfced] FYI: We updated this sentence for clarity as shown
below. Please let us know of any objections.
Original:
This subpacket denotes whether a certification signature is
"exportable", to be used by other users than the signature's issuer.
Current:
This subpacket denotes whether a certification signature is
"exportable"; it is intended for use by users other than the
signature's issuer.
-->
<t>This subpacket denotes whether a certification signature is "exportable"; it is intended for use by users other than the signature's issuer.
The packet body contains a Boolean flag indicating whether the signature is exportable.
If this packet is not present, the certification is exportable; it is equivalent to a flag containing a 1.</t>
<t>Non-exportable, or "local", certifications are signatures made by a user to mark a key as valid within that user's implementation only.</t>
<t>Thus, when an implementation prepares a user's copy of a key for transport to another user (this is the process of "exporting" the key), any local certification signatures are deleted from the key.</t>
<t>The receiver of a transported key "imports" it, it and likewise trims any local certifications. In normal operation, there won't be any, any local certifications, assuming the import is performed on an exported key. However, there are instances where this can reasonably happen.
For example, if an implementation allows keys to be imported from a key database in addition to an exported key, then this situation can arise.</t>
<t>Some implementations do not represent the interest of a single user (for example, a key server).
Such implementations always trim local certifications from any key they handle.</t>
<t>When an implementation generates this subpacket and denotes the signature as non-exportable, the subpacket <bcp14>MUST</bcp14> be marked as critical.</t>
</section>
<section anchor="revocable-subpacket"><name>Revocable</name> anchor="revocable-subpacket">
<name>Revocable</name>
<t>(1 octet of revocability, 0 for not, 1 for revocable)</t>
<t>Signature's
<t>A Signature's revocability status. The packet body contains a Boolean flag indicating whether the signature is revocable. Signatures that are not revocable have ignore any later revocation signatures ignored. signatures. They represent a commitment by the signer signer's commitment that he cannot revoke his its signature cannot be revoked for the life of his its key.
If this packet is not present, the signature is revocable.</t>
</section>
<section anchor="trust-signature-subpacket"><name>Trust anchor="trust-signature-subpacket">
<name>Trust Signature</name>
<t>(1 octet "level" (depth), 1 octet of trust amount)</t>
<t>Signer
<t>A signer asserts that the key is not only valid but also trustworthy at the specified level. Level 0 has the same meaning as an ordinary validity signature.
Level 1 means that the signed key is asserted to be a valid trusted introducer, with the 2nd octet of the body specifying the degree of trust.
Level 2 means that the signed key is asserted to be trusted to issue level 1 trust signatures; that is, the signed key is a "meta introducer".
Generally, a level n trust signature asserts that a key is trusted to issue level n-1 trust signatures.
The trust amount is in a range from 0-255, interpreted such that values less than 120 indicate partial trust and values of 120 or greater indicate complete trust.
Implementations <bcp14>SHOULD</bcp14> emit values of 60 for partial trust and 120 for complete trust.</t>
</section>
<section anchor="regex-subpacket"><name>Regular anchor="regex-subpacket">
<name>Regular Expression</name>
<t>(null-terminated UTF-8 encoded regular expression)</t>
<t>Used in conjunction with trust Signature packets (of level > 0) to limit the scope of trust that is extended.
Only signatures by the target key on User IDs that match the regular expression in the body of this packet have trust extended by the trust Signature subpacket.
The regular expression uses the same syntax as Henry Spencer's "almost public domain" regular expression <xref target="REGEX"/> package.
A description of the syntax is found in <xref target="regular-expressions"/>.
The regular expression matches (or does not match) a sequence of UTF-8-encoded Unicode characters from User IDs.
The expression itself is also written with UTF-8 characters.</t>
<t>For historical reasons, this subpacket includes a null character (octet (an octet with value zero) after the regular expression.
When an implementation parses a regular expression subpacket, it <bcp14>MUST</bcp14> remove this octet; if it is not present, it <bcp14>MUST</bcp14> reject the subpacket (i.e. (i.e., ignore the subpacket if it's non-critical and reject the signature if it's critical).
When an implementation generates a regular expression subpacket, it <bcp14>MUST</bcp14> include the null terminator.</t>
<t>When generating this subpacket, it <bcp14>SHOULD</bcp14> be marked as critical.</t>
</section>
<section anchor="revocation-key"><name>Revocation Key</name> anchor="revocation-key">
<name>Revocation Key (Deprecated)</name>
<t>(1 octet of class, 1 octet of public-key algorithm ID, 20 octets of v4 fingerprint)</t>
<t>This mechanism is deprecated.
Applications <bcp14>MUST NOT</bcp14> generate such a subpacket.</t>
<t>An application that wants the functionality of delegating revocation can use an escrowed Revocation Signature.
See <xref target="escrowed-revocations"/> for more details.</t>
<t>The remainder of this section describes how some implementations attempt to interpret this deprecated subpacket.</t>
<t>This packet was intended to authorize the specified key to issue revocation signatures for this key.
Class The class octet must have bit 0x80 set.
If the bit 0x40 is set, then this it means that the revocation information is sensitive.
Other bits are for future expansion to other kinds of authorizations.
This is only found on a direct key self-signature (type ID 0x1F).
The use on other types of self-signatures is unspecified.</t>
<t>If the "sensitive" flag is set, the keyholder feels this subpacket contains private trust information that describes a real-world sensitive relationship.
If this flag is set, implementations <bcp14>SHOULD NOT</bcp14> export this signature to other users except in cases where the data needs to be available: available, i.e., when the signature is being sent to the designated revoker, revoker or when it is accompanied by a revocation signature from that revoker.
Note that it may be appropriate to isolate this subpacket within a separate signature so that it is not combined with other subpackets that need to be exported.</t>
</section>
<section anchor="notation-data"><name>Notation anchor="notation-data">
<name>Notation Data</name>
<t>(4 octets of flags, 2 octets of name length (M), 2 octets of value length (N), M octets of name data, N octets of value data)</t>
<t>This subpacket describes a "notation" on the signature that the issuer wishes to make.
The notation has a name and a value, each of which are strings of octets.
There may be more than one notation in a signature.
Notations can be used for any extension the issuer of the signature cares to make.
The "flags" field holds four octets of flags.</t>
<t>All undefined flags <bcp14>MUST</bcp14> be zero.
Defined flags are as follows:</t>
<texttable title="OpenPGP
<table anchor="sig-note-data-note-flags-registry">
<name>OpenPGP Signature Notation Data Subpacket Notation Flags registry" anchor="sig-note-data-note-flags-registry">
<ttcol align='left'>Flag Position</ttcol>
<ttcol align='left'>Shorthand</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0x80000000 Registry</name>
<thead>
<tr>
<th align="left">Flag Position</th>
<th align="left">Shorthand</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x80000000 (first bit of the first octet)</c>
<c>human-readable</c>
<c>Notation octet)</td>
<td align="left">human-readable</td>
<td align="left">Notation value is UTF-8 text.</c>
<c>This document</c>
</texttable> text</td>
<td align="left">[RFC9580]</td>
</tr>
</tbody>
</table>
<t>Notation names are arbitrary strings encoded in UTF-8.
They reside in two namespaces: The the IETF namespace and the user namespace.</t>
<t>The IETF namespace is registered with IANA.
These names <bcp14>MUST NOT</bcp14> contain the "@" character (0x40).
This is a tag for the user namespace.</t>
<texttable title="OpenPGP
<table anchor="sig-note-data-subpacket-types">
<name>OpenPGP Signature Notation Data Subpacket Types registry" anchor="sig-note-data-subpacket-types">
<ttcol align='left'>Notation Name</ttcol>
<ttcol align='left'>Data Type</ttcol>
<ttcol align='left'>Allowed Values</ttcol>
<ttcol align='left'>Reference</ttcol>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
</texttable> Registry</name>
<thead>
<tr>
<th align="left">Notation Name</th>
<th align="left">Data Type</th>
<th align="left">Allowed Values</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<th colspan="4" align="left" rowspan="1">No registrations at this time.</th>
</tr>
</tbody>
</table>
<t>This registry is initially empty.</t>
<t>Names in the user namespace consist of a UTF-8 string tag followed by "@" "@", followed by a DNS domain name.
Note that the tag <bcp14>MUST NOT</bcp14> contain an "@" character.
For example, the "sample" tag used by Example Corporation could be "sample@example.com".</t>
<t>Names in a user space are owned and controlled by the owners of that domain.
Obviously, it's bad form to create a new name in a DNS space that you don't own.</t>
<t>Since the user namespace is in the form of an email address, implementers <bcp14>MAY</bcp14> wish to arrange for that address to reach a person who can be consulted about the use of the named tag.
Note that due to UTF-8 encoding, not all valid user space name tags are valid email addresses.</t>
<t>If there is a critical notation, the criticality applies to that specific notation and not to notations in general.</t>
</section>
<section anchor="key-server-preferences"><name>Key anchor="key-server-preferences">
<name>Key Server Preferences</name>
<t>(N octets of flags)</t>
<t>This is a list of one-bit flags that indicate indicates preferences that the keyholder has about how the key is handled on a key server.
All undefined flags <bcp14>MUST</bcp14> be zero.</t>
<texttable title="OpenPGP
<table anchor="key-server-preference-flags-registry">
<name>OpenPGP Key Server Preference Flags registry" anchor="key-server-preference-flags-registry">
<ttcol align='left'>Flag</ttcol>
<ttcol align='left'>Shorthand</ttcol>
<ttcol align='left'>Definition</ttcol>
<c>0x80...</c>
<c>No-modify</c>
<c>The Registry</name>
<thead>
<tr>
<th align="left">Flag</th>
<th align="left">Shorthand</th>
<th align="left">Definition</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x80...</td>
<td align="left">No-modify</td>
<td align="left">The keyholder requests that this key only be modified or updated by the keyholder or an administrator of the key server.</c>
</texttable> server.</td>
</tr>
</tbody>
</table>
<t>This is found only on a self-signature.</t>
</section>
<section anchor="preferred-key-server-subpacket"><name>Preferred anchor="preferred-key-server-subpacket">
<name>Preferred Key Server</name>
<t>(String)</t>
<t>This is a URI of a key server that the keyholder prefers be used for 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 can actually be a copy of the key retrieved by https, ftp, http, etc.</t>
</section>
<section anchor="primary-user-id-subpacket"><name>Primary anchor="primary-user-id-subpacket">
<name>Primary User ID</name>
<t>(1 octet, Boolean)</t>
<t>This is a flag in a User ID's self-signature that states whether this User ID is the main User ID for this key.
It is reasonable for an implementation to resolve ambiguities in preferences, for example, by referring to the primary User ID.
If this flag is absent, its value is zero.
If more than one User ID in a key is marked as primary, the implementation may resolve the ambiguity in any way it sees fit, but it is <bcp14>RECOMMENDED</bcp14> that priority be given to the User ID with the most recent self-signature.</t>
<t>When appearing on a self-signature on a User ID packet, this subpacket applies only to User ID packets.
When appearing on a self-signature on a User Attribute packet, this subpacket applies only to User Attribute packets. That is to say, is, there are two different and independent "primaries" --- -- one for User IDs, IDs and one for User Attributes.</t>
</section>
<section anchor="policy-uri-subpacket"><name>Policy anchor="policy-uri-subpacket">
<name>Policy URI</name>
<t>(String)</t>
<t>This subpacket contains a URI of a document that describes the policy under which the signature was issued.</t>
</section>
<section anchor="key-flags"><name>Key anchor="key-flags">
<name>Key Flags</name>
<t>(N octets of flags)</t>
<t>This subpacket contains a list of binary flags that hold information about a key.
It is a string of octets, and an implementation <bcp14>MUST NOT</bcp14> assume a fixed size.
This is size so that it can grow over time. If a list is shorter than an implementation expects, the unstated flags are considered to be zero. The defined flags are as follows:</t>
<texttable title="OpenPGP
<table anchor="key-flags-registry">
<name>OpenPGP Key Flags registry" anchor="key-flags-registry">
<ttcol align='left'>Flag</ttcol>
<ttcol align='left'>Definition</ttcol>
<c>0x01...</c>
<c>This Registry</name>
<thead>
<tr>
<th align="left">Flag</th>
<th align="left">Definition</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x01...</td>
<td align="left">This key may be used to make User ID certifications (signature type IDs 0x10-0x13) or direct key signatures (signature type ID 0x1F) over other keys.</c>
<c>0x02...</c>
<c>This keys.</td>
</tr>
<tr>
<td align="left">0x02...</td>
<td align="left">This key may be used to sign data.</c>
<c>0x04...</c>
<c>This data.</td>
</tr>
<tr>
<td align="left">0x04...</td>
<td align="left">This key may be used to encrypt communications.</c>
<c>0x08...</c>
<c>This communications.</td>
</tr>
<tr>
<td align="left">0x08...</td>
<td align="left">This key may be used to encrypt storage.</c>
<c>0x10...</c>
<c>The storage.</td>
</tr>
<tr>
<td align="left">0x10...</td>
<td align="left">The private component of this key may have been split by a secret-sharing mechanism.</c>
<c>0x20...</c>
<c>This mechanism.</td>
</tr>
<tr>
<td align="left">0x20...</td>
<td align="left">This key may be used for authentication.</c>
<c>0x80...</c>
<c>The authentication.</td>
</tr>
<tr>
<td align="left">0x80...</td>
<td align="left">The private component of this key may be in the possession of more than one person.</c>
<c>0x0004...</c>
<c>Reserved (ADSK).</c>
<c>0x0008...</c>
<c>Reserved (timestamping).</c>
</texttable> person.</td>
</tr>
<tr>
<td align="left">0x0004...</td>
<td align="left">Reserved (ADSK)</td>
</tr>
<tr>
<td align="left">0x0008...</td>
<td align="left">Reserved (timestamping)</td>
</tr>
</tbody>
</table>
<t>Usage notes:</t>
<t>The flags in this packet may appear in self-signatures or in certification signatures. They mean different things depending on who is making the statement --- for statement. For example, a certification signature that has the "sign data" flag is stating that the certification is for that use. On the other hand, the "communications encryption" flag in a self-signature is stating a preference that a given key be used for communications.
Note however, However, note that it is a thorny issue to determine determining what is "communications" and what is "storage". "storage" is a thorny issue. This decision is left wholly up to the implementation; the authors of this document do not claim any special wisdom on the issue and realize that accepted opinion may change.</t>
<t>The "split key" (0x10) and "group key" (0x80) flags are placed on a self-signature only; they are meaningless on a certification signature.
They <bcp14>SHOULD</bcp14> be placed only on a direct key signature (type ID 0x1F) or a subkey signature (type ID 0x18), one that refers to the key the flag applies to.</t>
<t>When an implementation generates this subpacket, it <bcp14>SHOULD</bcp14> be marked as critical.</t>
</section>
<section anchor="signers-user-id-subpacket"><name>Signer's anchor="signers-user-id-subpacket">
<name>Signer's User ID</name>
<t>(String)</t>
<t>This subpacket allows a keyholder to state which User ID is responsible for the signing.
Many keyholders use a single key for different purposes, such as business communications as well as personal communications.
This subpacket allows such a keyholder to state which of their roles is making a signature.</t>
<t>This subpacket is not appropriate to use to refer to a User Attribute packet.</t>
</section>
<section anchor="reason-for-revocation"><name>Reason anchor="reason-for-revocation">
<name>Reason for Revocation</name>
<t>(1 octet of revocation code, N octets of reason string)</t>
<t>This subpacket is used only in key revocation and certification revocation signatures.
It describes the reason why the key or certification was revoked.</t>
<t>The first octet contains a machine-readable code that denotes the reason for the revocation:</t>
<texttable title="OpenPGP
<table anchor="reason-for-revocation-code-registry">
<name>OpenPGP Reason for Revocation Code registry" anchor="reason-for-revocation-code-registry">
<ttcol align='right'>Code</ttcol>
<ttcol align='left'>Reason</ttcol>
<c>0</c>
<c>No Registry</name>
<thead>
<tr>
<th align="right">Code</th>
<th align="left">Reason</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">0</td>
<td align="left">No reason specified (key revocations or cert revocations)</c>
<c>1</c>
<c>Key revocations)</td>
</tr>
<tr>
<td align="right">1</td>
<td align="left">Key is superseded (key revocations)</c>
<c>2</c>
<c>Key revocations)</td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">Key material has been compromised (key revocations)</c>
<c>3</c>
<c>Key revocations)</td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">Key is retired and no longer used (key revocations)</c>
<c>32</c>
<c>User revocations)</td>
</tr>
<tr>
<td align="right">32</td>
<td align="left">User ID information is no longer valid (cert revocations)</c>
<c>100-110</c>
<c>Private Use</c>
</texttable> revocations)</td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private Use</td>
</tr>
</tbody>
</table>
<t>Following the revocation code is a string of octets that gives information about the Reason for Revocation in human-readable form (UTF-8).
The string may be null (of zero length).
The length of the subpacket is the length of the reason string plus one.
An implementation <bcp14>SHOULD</bcp14> implement this subpacket, include it in all revocation signatures, and interpret revocations appropriately.
There are important semantic differences between the reasons, and there are thus important reasons for revoking signatures.</t>
<t>If a key has been revoked because of a compromise, all signatures created by that key are suspect. However, if it was merely superseded or retired, old signatures are still valid. If the revoked signature is the self-signature for certifying a User ID, a revocation denotes that that user name is no longer in use.
Such a signature revocation <bcp14>SHOULD</bcp14> include a Reason for Revocation subpacket containing code 32.</t>
<t>Note that any signature certification may be revoked, including a certification on some other person's key. There are many good reasons for revoking a certification signature, such as the case where the keyholder leaves the employ of a business with an email address. A revoked certification is no longer a part of validity calculations.</t>
</section>
<section anchor="features-subpacket"><name>Features</name> anchor="features-subpacket">
<name>Features</name>
<t>(N octets of flags)</t>
<t>The Features subpacket denotes which advanced OpenPGP features a user's implementation supports. This is so that as features are added to OpenPGP that cannot be backwards-compatible, backward compatible, a user can state that they can use that feature. The flags are single bits that indicate that a given feature is supported.</t>
<t>This subpacket is similar to a preferences subpacket, subpacket and only appears in a self-signature.</t>
<t>An implementation <bcp14>SHOULD NOT</bcp14> use a feature listed when sending to a user who does not state that they can use it, unless the implementation can infer support for the feature from another implementation-dependent mechanism.</t>
<t>Defined features are as follows:</t>
<t>First octet:</t>
<texttable title="OpenPGP
<table anchor="features-flags-registry">
<name>OpenPGP Features Flags registry" anchor="features-flags-registry">
<ttcol align='left'>Feature</ttcol>
<ttcol align='left'>Definition</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>0x01...</c>
<c>Symmetrically Registry</name>
<thead>
<tr>
<th align="left">Feature</th>
<th align="left">Definition</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">0x01...</td>
<td align="left">Symmetrically Encrypted Integrity Protected Data packet version 1</c>
<c><xref target="version-one-seipd"/></c>
<c>0x02...</c>
<c>Reserved</c>
<c> </c>
<c>0x04...</c>
<c>Reserved</c>
<c> </c>
<c>0x08...</c>
<c>Symmetrically 1</td>
<td align="left">[RFC9580],
<xref target="version-one-seipd"/></td>
</tr>
<tr>
<td align="left">0x02...</td>
<td align="left">Reserved</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="left">0x04...</td>
<td align="left">Reserved</td>
<td align="left">[RFC9580]</td>
</tr>
<tr>
<td align="left">0x08...</td>
<td align="left">Symmetrically Encrypted Integrity Protected Data packet version 2</c>
<c><xref target="version-two-seipd"/></c>
</texttable> 2</td>
<td align="left">[RFC9580],
<xref target="version-two-seipd"/></td>
</tr>
</tbody>
</table>
<t>If an implementation implements any of the defined features, it <bcp14>SHOULD</bcp14> implement the Features subpacket, too.</t>
<t>See <xref target="ciphertext-malleability"/> for details about how to use the Features subpacket when generating encryption data.</t>
</section>
<section anchor="signature-target-subpacket"><name>Signature anchor="signature-target-subpacket">
<name>Signature Target</name>
<t>(1 octet public-key algorithm, 1 octet hash algorithm, N octets hash)</t>
<t>This subpacket identifies a specific target signature to which a signature refers.
For revocation signatures, this subpacket provides explicit designation of which signature is being revoked. For a third-party or timestamp signature, this designates what signature is signed.
All arguments are an identifier of that target signature.</t>
<t>The N octets of hash data <bcp14>MUST</bcp14> be the size of the hash of the signature. signature's hash. For example, a target signature with a SHA-1 hash <bcp14>MUST</bcp14> have 20 octets of hash data.</t>
</section>
<section anchor="embedded-signature-subpacket"><name>Embedded anchor="embedded-signature-subpacket">
<name>Embedded Signature</name>
<t>(1 signature packet body)</t>
<t>This subpacket contains a complete Signature packet body as specified in <xref target="signature-packet"/>.
It is useful when one signature needs to refer to, or be incorporated in, another signature.</t>
</section>
<section anchor="issuer-fingerprint-subpacket"><name>Issuer anchor="issuer-fingerprint-subpacket">
<name>Issuer Fingerprint</name>
<t>(1 octet key version number, N octets of fingerprint)</t>
<t>The OpenPGP Key fingerprint of the key issuing the signature.
This subpacket <bcp14>SHOULD</bcp14> be included in all signatures.
If the version of the issuing key is 4 and an Issuer Key ID subpacket (<xref target="issuer-keyid-subpacket"/>) is also included in the signature, the key ID of the Issuer Key ID subpacket <bcp14>MUST</bcp14> match the low 64 bits of the fingerprint.</t>
<t>Note that the length N of the fingerprint for a version 4 key is 20 octets; for a version 6 key key, N is 32.
Since the version of the signature is bound to the version of the key, the version octet here <bcp14>MUST</bcp14> match the version of the signature.
If the version octet does not match the signature version, the receiving implementation <bcp14>MUST</bcp14> treat it as a malformed signature (see <xref target="malformed-signatures"/>).</t>
</section>
<section anchor="intended-recipient-fingerprint"><name>Intended anchor="intended-recipient-fingerprint">
<name>Intended Recipient Fingerprint</name>
<t>(1 octet key version number, N octets of fingerprint)</t>
<t>The OpenPGP Key fingerprint of the intended recipient primary key.
If one or more subpackets of this type are included in a signature, it <bcp14>SHOULD</bcp14> be considered valid only in an encrypted context, where the key it was encrypted to is one of the indicated primary keys, keys or one of their subkeys. This can be used to prevent forwarding a signature outside of its intended, encrypted context (see <xref target="surreptitious-forwarding"/>).</t>
<t>Note that the length N of the fingerprint for a version 4 key is 20 octets; for a version 6 key key, N is 32.</t>
<t>An implementation <bcp14>SHOULD</bcp14> generate this subpacket when creating a signed and encrypted message.</t>
<t>When generating this subpacket in a v6 signature, it <bcp14>SHOULD</bcp14> be marked as critical.</t>
</section>
</section>
<section anchor="computing-signatures"><name>Computing anchor="computing-signatures">
<name>Computing Signatures</name>
<t>All signatures are formed by producing a hash over the signature data, data and then using the resulting hash in the signature algorithm.</t>
<t>When creating or verifying a v6 signature, the salt is fed into the hash context before any other data.</t>
<t>For binary document signatures (type ID 0x00), the document data is hashed directly.
For text document signatures (type ID 0x01), the implementation <bcp14>MUST</bcp14> first canonicalize the document by converting line endings to <CR><LF> and encoding it in UTF-8 (see <xref target="RFC3629"/>).
The resulting UTF-8 bytestream byte stream is hashed.</t>
<t>When a v4 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 followed by the body of the key packet.
When a v6 signature is made over a key, the hash data starts with the salt, salt and then octet 0x9B, followed by a four-octet length of the key, and then followed by the body of the key packet.</t>
<t>A subkey binding signature (type ID 0x18) or primary key binding signature (type ID 0x19) then hashes the subkey using the same format as the main key (also using 0x99 or 0x9B as the first octet). Primary key revocation signatures (type ID 0x20) hash only the key being revoked.
Subkey revocation signature signatures (type ID 0x28) hash first hash the primary key and then the subkey being revoked.</t>
<t>A certification signature (type ID 0x10 through 0x13) hashes the User ID being that is bound to the key into the hash context after the above data. A v3 certification hashes the contents of the User ID or User Attribute packet, packet without the packet header. A v4 or v6 certification hashes the constant 0xB4 for User ID certifications or the constant 0xD1 for User Attribute certifications, followed by a four-octet number giving the length of the User ID or User Attribute data, and then followed by the User ID or User Attribute data.</t>
<t>When a signature is made over a Signature packet (type ID 0x50, "Third-Party Confirmation signature"), the hash data starts with the salt (v6 signatures only), followed by the octet 0x88, followed by the four-octet length of the signature, and then the body of the Signature packet. (Note that this is a Legacy 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.</t>
<t>Once the data body is hashed, then a trailer is hashed. This trailer depends on the version of the signature.</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A v3 signature hashes five octets of the packet body, starting from the signature type field. This data is the signature type, followed by the four-octet signature creation time.</t>
</li>
<li>
<t>A v4 or v6 signature hashes the packet body starting from its first field, the version number, through the end of the hashed subpacket data and a final extra trailer. Thus, the hashed fields are: <list style="symbols">
<t>An </t>
<ul spacing="normal">
<li>
<t>an octet indicating the signature version (0x04 for v4, and 0x06 for v6),</t>
<t>The
</li>
<li>
<t>the signature type,</t>
<t>The
</li>
<li>
<t>the public-key algorithm,</t>
<t>The
</li>
<li>
<t>the hash algorithm,</t>
<t>The
</li>
<li>
<t>the hashed subpacket length,</t>
<t>The
</li>
<li>
<t>the hashed subpacket body,</t>
<t>A
</li>
<li>
<t>a second version octet (0x04 for v4, and 0x06 for v6)</t>
<t>A v6),</t>
</li>
<li>
<t>a single octet 0xFF,</t>
<t>A 0xFF, and</t>
</li>
<li>
<t>a number representing the length (in octets) of the hashed data from the Signature packet through the hashed subpacket body. This a four-octet big-endian unsigned integer of the length modulo 2**32.</t>
</list></t>
</list></t>
</li>
</ul>
</li>
</ul>
<t>After all this has been hashed in a single hash context, the resulting hash field is used in the signature algorithm algorithm, and its first two octets are placed in the Signature packet, as described in <xref target="version-four-and-six-sig"/>.</t>
<t>For worked examples of the data hashed during a signature, see <xref target="sig-hashed-data-example"/>.</t>
<section anchor="sig-computation-notes"><name>Notes About anchor="sig-computation-notes">
<name>Notes about Signature Computation</name>
<t>The data actually hashed by OpenPGP varies depending on the signature version, in order to ensure that a signature made using one version cannot be repurposed as a signature with a different version over subtly different data. The hashed data streams differ based on their trailer, most critically in the fifth and sixth octets from the end of the stream.
In particular:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A v3 signature uses the fifth octet from the end to store its signature type ID.
This <bcp14>MUST NOT</bcp14> be signature type ID <spanx style="verb">0xFF</spanx>.</t> <tt>0xFF</tt>.</t>
</li>
<li>
<t>All signature versions later than v3 always use a literal <spanx style="verb">0xFF</spanx> <tt>0xFF</tt> in the fifth octet from the end.
For these later signature versions, the sixth octet from the end (the octet before the <spanx style="verb">0xFF</spanx>) <tt>0xFF</tt>) stores the signature version number.</t>
</list></t>
</li>
</ul>
</section>
</section>
<section anchor="malformed-signatures"><name>Malformed anchor="malformed-signatures">
<name>Malformed and Unknown Signatures</name>
<t>In some cases, a signature packet (or its corresponding One-Pass Signature packet, packet; see <xref target="one-pass-sig"/>) may be malformed or unknown.
For example, it might encounter any of the following problems (this is not an exhaustive list):</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>An unknown signature type</t>
</li>
<li>
<t>An unknown signature version</t>
</li>
<li>
<t>An unsupported signature version</t>
</li>
<li>
<t>An unknown "critical" subpacket (see <xref target="signature-subpacket"/>) in the hashed area</t>
</li>
<li>
<t>A subpacket with a length that diverges from the expected length</t>
</li>
<li>
<t>A hashed subpacket area with length that exceeds the length of the signature packet itself</t>
</li>
<li>
<t>A known-weak hash algorithm (e.g. known to be weak (e.g., MD5)</t>
</li>
<li>
<t>A mismatch between the hash algorithm expected salt length and the actual salt length</t> length of the hash algorithm</t>
</li>
<li>
<t>A mismatch between the One-Pass Signature version and the Signature version (see <xref target="signed-message-versions"/>)</t>
</li>
<li>
<t>A signature with a version other than 6, made by a v6 key</t>
</list></t>
</li>
</ul>
<t>When an implementation encounters such a malformed or unknown signature, it <bcp14>MUST</bcp14> ignore the signature for validation purposes.
It <bcp14>MUST NOT</bcp14> indicate a successful signature validation for such a signature.
At the same time, it <bcp14>MUST NOT</bcp14> halt processing on the packet stream or reject other signatures in the same packet stream just because an unknown or invalid signature exists.</t>
<t>This requirement is necessary for forward-compatibility. forward compatibility.
Producing an output that indicates that no successful signatures were found is preferable to aborting processing entirely.</t>
</section>
</section>
<section anchor="skesk"><name>Symmetric-Key anchor="skesk">
<name>Symmetric-Key Encrypted Session Key Packet (Type ID 3)</name>
<t>The Symmetric-Key Encrypted Session Key (SKESK) packet holds the symmetric-key encryption of a session key used to encrypt a message.
Zero or more Public-Key Encrypted Session Key packets (<xref target="pkesk"/>) and/or Symmetric-Key Encrypted Session Key packets precede an encryption container (that is, a Symmetrically Encrypted Integrity Protected Data packet or --- -- for historic data --- -- a Symmetrically Encrypted Data packet) that holds an encrypted message. The message is encrypted with a session key, and the session key is itself encrypted and stored in the Encrypted Session Key packet(s).</t>
<t>If the encryption container is preceded by one or more Symmetric-Key Encrypted Session Key packets, each specifies 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 or more passphrases.</t>
<t>The body of this packet starts with a one-octet number giving the version number of the packet type.
The currently defined versions are 4 and 6.
The remainder of the packet depends on the version.</t>
<t>The versions differ in how they encrypt the session key with the passphrase, passphrase and in what they encode.
The version of the SKESK packet must align with the version of the SEIPD packet (see <xref target="encrypted-message-versions"/>).
Any new version of the SKESK packet should be registered in the registry established in <xref target="encrypted-message-versions"/>.</t>
<section anchor="v4-skesk"><name>Version anchor="v4-skesk">
<name>Version 4 Symmetric-Key Encrypted Session Key Packet Format</name>
<t>A version 4 Symmetric-Key Encrypted Session Key (SKESK) SKESK packet precedes a version 1 Symmetrically Encrypted Integrity Protected Data (v1 SEIPD, see v1 SEIPD (see <xref target="version-one-seipd"/>) packet. target="version-one-seipd"/>).
In historic data, it is sometimes found preceding a deprecated Symmetrically Encrypted Data SED packet (SED, see (see <xref target="sed"/>). A v4 SKESK packet <bcp14>MUST NOT</bcp14> precede a v2 SEIPD packet (see <xref target="encrypted-message-versions"/>).</t>
<t>A version 4 Symmetric-Key Encrypted Session Key packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet version number with value 4.</t>
</li>
<li>
<t>A one-octet number describing the symmetric algorithm used.</t>
<t>A string-to-key (S2K)
</li>
<li>
<t>An S2K specifier. The length of the string-to-key S2K specifier depends on its type (see <xref target="s2k-types"/>).</t>
</li>
<li>
<t>Optionally, the encrypted session key itself, which is decrypted with the string-to-key S2K object.</t>
</list></t>
</li>
</ul>
<t>If the encrypted session key is not present (which can be detected on the basis of packet length and S2K specifier size), then the S2K algorithm applied to the passphrase produces the session key for decrypting the message, using the symmetric cipher algorithm from the Symmetric-Key Encrypted Session Key packet.</t>
<t>If the encrypted session key is present, the result of applying the S2K algorithm to the passphrase is used to decrypt just that encrypted session key field, using CFB mode with an IV of all zeros.
The decryption result consists of a one-octet algorithm identifier that specifies the symmetric-key encryption algorithm used to encrypt the following encryption container, followed by the session key octets themselves.</t>
<t>Note: because an all-zero IV is used for this decryption, the S2K specifier <bcp14>MUST</bcp14> use a salt value, either a Salted S2K, an Iterated-Salted Iterated and Salted S2K, or Argon2.
The salt value will ensure that the decryption key is not repeated even if the passphrase is reused.</t>
</section>
<section anchor="v6-skesk"><name>Version anchor="v6-skesk">
<name>Version 6 Symmetric-Key Encrypted Session Key Packet Format</name>
<t>A version 6 Symmetric-Key Encrypted Session Key (SKESK) SKESK packet precedes a version 2 Symmetrically Encrypted Integrity Protected Data (v2 SEIPD, see SEIPD packet (see <xref target="version-two-seipd"/>) packet. target="version-two-seipd"/>).
A v6 SKESK packet <bcp14>MUST NOT</bcp14> precede a v1 SEIPD packet or a deprecated Symmetrically Encrypted Data packet (see <xref target="encrypted-message-versions"/>).</t>
<t>A version 6 Symmetric-Key Encrypted Session Key packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet version number with value 6.</t>
</li>
<li>
<t>A one-octet scalar octet count for the 5 fields following this octet.</t>
</li>
<li>
<t>A one-octet symmetric cipher algorithm ID from (from <xref target="symkey-algorithms-registry"/>.</t> target="symkey-algorithms-registry"/>).</t>
</li>
<li>
<t>A one-octet AEAD algorithm identifier from (from <xref target="aead-algorithms-registry"/>.</t> target="aead-algorithms-registry"/>).</t>
</li>
<li>
<t>A one-octet scalar octet count of the following field.</t>
<t>A string-to-key (S2K)
</li>
<li>
<t>An S2K specifier. The length of the string-to-key S2K specifier depends on its type (see <xref target="s2k-types"/>).</t>
</li>
<li>
<t>A starting initialization vector of a size specified by the AEAD algorithm.</t>
</li>
<li>
<t>The encrypted session key itself.</t>
</li>
<li>
<t>An authentication tag for the AEAD mode.</t>
</list></t>
</li>
</ul>
<t>A key-encryption key (KEK) is derived using HKDF (<xref target="RFC5869"/>) <xref target="RFC5869"/> with SHA256 (<xref target="RFC6234"/>) <xref target="RFC6234"/> as the hash algorithm.
The Initial Keying Material (IKM) for HKDF is the key derived from S2K.
No salt is used. The info parameter is comprised of the Packet Type ID in OpenPGP format encoding (bits 7 and 6 are set, and bits 5-0 carry the packet type ID), the packet version, and the cipher-algo and AEAD-mode used to encrypt the key material.</t>
<t>Then, the session key is encrypted using the resulting key, with the AEAD algorithm specified for version 2 of the Symmetrically Encrypted Integrity Protected Data packet.
Note that no chunks are used and that there is only one authentication tag.
The Packet Type ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 carry the packet type ID), the packet version number, the cipher algorithm ID, and the AEAD algorithm ID are given as additional data.
For example, the additional data used with AES-128 with OCB consists of the octets 0xC3, 0x06, 0x07, and 0x02.</t>
</section>
</section>
<section anchor="one-pass-sig"><name>One-Pass anchor="one-pass-sig">
<name>One-Pass Signature Packet (Type ID 4)</name>
<t>The One-Pass Signature packet precedes the signed data and contains enough information to allow the receiver to begin calculating any hashes needed to verify the signature.
It allows the Signature packet to be placed at the end of the message, message so that the signer can compute the entire signed message in one pass.</t>
<t>The body of this packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet version number.
The currently defined versions are 3 and 6.
Any new One-Pass Signature packet version should be registered in the registry established in <xref target="signed-message-versions"/>.</t>
</li>
<li>
<t>A one-octet signature type ID.
Signature types are described in <xref target="signature-types"/>.</t>
</li>
<li>
<t>A one-octet number describing the hash algorithm used.</t>
</li>
<li>
<t>A one-octet number describing the public-key algorithm used.</t>
</li>
<li>
<t>Only for v6 packets, a variable-length field containing: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>A one-octet salt size. The value <bcp14>MUST</bcp14> match the value defined for the hash algorithm as specified in <xref target="hash-algorithms-registry"/>.</t>
</li>
<li>
<t>The salt; a random value of the specified size. The value <bcp14>MUST</bcp14> match the salt field of the corresponding Signature packet.</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Only for v3 packets, an eight-octet number holding the Key ID of the signing key.</t>
</li>
<li>
<t>Only for v6 packets, 32 octets of the fingerprint of the signing key.
Since a v6 signature can only be made by a v6 key, the length of the fingerprint is fixed.</t>
</li>
<li>
<t>A one-octet number holding a flag showing whether the signature is nested.
A zero value indicates that the next packet is another One-Pass Signature packet that describes another signature to be applied to the same message data.</t>
</list></t>
</li>
</ul>
<t>When generating a one-pass signature, the OPS packet version <bcp14>MUST</bcp14> correspond to the version of the associated signature packet, except for the historical accident that v4 keys use a v3 one-pass signature packet (there is no v4 OPS).
See <xref target="signed-message-versions"/> for the full correspondence of versions between Keys, Signatures, and One-Pass Signatures.</t>
<t>Note that if a message contains more than one one-pass signature, then the Signature packets bracket the message; that is, the first Signature packet after the message corresponds to the last one-pass packet and the final Signature packet corresponds to the first one-pass packet.</t>
</section>
<section anchor="key-material-packets"><name>Key anchor="key-material-packets">
<name>Key Material Packets</name>
<t>A key material packet contains all the information about a public or private key.
There are four variants of this packet type, type: two major versions (versions 4 and 6), 6) and two strongly deprecated versions (versions 2 and 3). Consequently, this section is complex.</t>
<t>For historical reasons, versions 1 and 5 of the key packets are unspecified.</t>
<section anchor="key-packet-variants"><name>Key anchor="key-packet-variants">
<name>Key Packet Variants</name>
<section anchor="pubkey"><name>Public-Key anchor="pubkey">
<name>Public-Key Packet (Type ID 6)</name>
<t>A Public-Key packet starts a series of packets that forms an OpenPGP key (sometimes called an OpenPGP certificate).</t>
</section>
<section anchor="pubsubkey"><name>Public-Subkey anchor="pubsubkey">
<name>Public-Subkey Packet (Type ID 14)</name>
<t>A Public-Subkey packet (type ID 14) has exactly the same format as a Public-Key packet, but it denotes a subkey. One or more subkeys may be associated with a top-level key.
By convention, the top-level key offers certification capability, but it does not provide encryption services, while a dedicated subkey provides encryption (see <xref target="common-requirements"/>).</t>
</section>
<section anchor="seckey"><name>Secret-Key anchor="seckey">
<name>Secret-Key Packet (Type ID 5)</name>
<t>A Secret-Key packet contains all the information that is found in a Public-Key packet, including the public-key material, but it also includes the secret-key material after all the public-key fields.</t>
</section>
<section anchor="secsubkey"><name>Secret-Subkey anchor="secsubkey">
<name>Secret-Subkey Packet (Type ID 7)</name>
<t>A Secret-Subkey packet (type ID 7) is the subkey analog of the Secret-Key packet and has exactly the same format.</t>
</section>
</section>
<section anchor="public-key-packet-formats"><name>Public-Key anchor="public-key-packet-formats">
<name>Public-Key Packet Formats</name>
<t>There are four versions of key-material packets.
The V2 and V3 versions have been deprecated since 1998.
The V4 version has been deprecated by this document in 2023.</t> document.</t>
<t>OpenPGP implementations <bcp14>SHOULD</bcp14> create keys with version 6 format.
V4 keys are deprecated; an implementation <bcp14>SHOULD NOT</bcp14> generate a v4 key, key but <bcp14>SHOULD</bcp14> accept it. V3 keys are deprecated; an implementation <bcp14>MUST NOT</bcp14> generate a v3 key, key but <bcp14>MAY</bcp14> accept it. V2 keys are deprecated; an implementation <bcp14>MUST NOT</bcp14> generate a v2 key, key but <bcp14>MAY</bcp14> accept it.</t>
<t>Any new Key version must be registered in the registry established in <xref target="signed-message-versions"/>.</t>
<section anchor="v3-pubkeys"><name>Version anchor="v3-pubkeys">
<name>Version 3 Public Keys</name>
<t>V2 keys are identical to v3 keys except for the version number.
A version 3 public key or public-subkey packet contains:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet version number (3).</t>
</li>
<li>
<t>A four-octet number denoting the time that the key was created.</t>
</li>
<li>
<t>A two-octet number denoting the time in days that this the key is valid.
If this number is zero, then it does not expire.</t>
</li>
<li>
<t>A one-octet number denoting the public-key algorithm of this the key.</t>
</li>
<li>
<t>A series of multiprecision integers comprising the key material: <list style="symbols">
<t>A multiprecision integer (MPI) </t>
<ul spacing="normal">
<li>
<t>MPI of RSA public modulus n;</t>
<t>An MPI n.</t>
</li>
<li>
<t>MPI of RSA public encryption exponent e.</t>
</list></t>
</list></t>
</li>
</ul>
</li>
</ul>
<t>V3 keys are deprecated. They contain three weaknesses.
First, it is relatively easy to construct a v3 key that has the same Key ID as any other key because the Key ID is simply the low 64 bits of the public modulus.
Secondly,
Second, because the fingerprint of a v3 key hashes the key material, but not its length, there is an increased opportunity for fingerprint collisions.
Third, there are weaknesses in the MD5 hash algorithm that make cause developers to prefer other algorithms.
See <xref target="key-ids-fingerprints"/> for a fuller discussion of Key IDs and fingerprints.</t>
</section>
<section anchor="v4-pubkeys"><name>Version anchor="v4-pubkeys">
<name>Version 4 Public Keys</name>
<t>The version 4 format is similar to the version 3 format except for the absence of a validity period.
This has been moved to the Signature packet.
In addition, fingerprints of version 4 keys are calculated differently from version 3 keys, as described in <xref target="key-ids-fingerprints"/>.</t>
<t>A version 4 packet contains:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet version number (4).</t>
</li>
<li>
<t>A four-octet number denoting the time that the key was created.</t>
</li>
<li>
<t>A one-octet number denoting the public-key algorithm of this the key.</t>
</li>
<li>
<t>A series of values comprising the key material.
This is algorithm-specific algorithm specific and described in <xref target="algorithm-specific-parts-of-keys"/>.</t>
</list></t>
</li>
</ul>
</section>
<section anchor="v6-pubkeys"><name>Version anchor="v6-pubkeys">
<name>Version 6 Public Keys</name>
<t>The version 6 format is similar to the version 4 format except for the addition of a count for the key material.
This count helps parsing secret key packets (which are an extension of the public key packet format) in the case of an unknown algorithm.
In addition, fingerprints of version 6 keys are calculated differently from version 4 keys, as described in <xref target="key-ids-fingerprints"/>.</t>
<!-- [rfced] Sections 5.5.2.3 and 5.5.4.3. Regarding "the following
public key material" (1st bullet) and "the following key
material" (e), would it be clearer if "following" was perhaps
removed from both instances as shown below, especially since "key
material" is not mentioned in "(f)"?
Original (Section 5.5.2.3):
* A four-octet scalar octet count for the following public key
material.
* A series of values comprising the public key material. This is
algorithm-specific and described in Section 5.5.5.
Perhaps:
* A four-octet scalar octet count for the public key material.
* A series of values comprising the public key material. This is
algorithm specific and described in Section 5.5.5.
...
Original (Section 5.5.4.3):
e) four-octet scalar octet count for the following key material;
f) algorithm-specific fields.
Perhaps:
e) four-octet scalar octet count for the key material
f) algorithm-specific fields
-->
<t>A version 6 packet contains:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet version number (6).</t>
</li>
<li>
<t>A four-octet number denoting the time that the key was created.</t>
</li>
<li>
<t>A one-octet number denoting the public-key algorithm of this the key.</t>
</li>
<li>
<t>A four-octet scalar octet count for the following public key material.</t>
</li>
<li>
<t>A series of values comprising the public key material.
This is algorithm-specific algorithm specific and described in <xref target="algorithm-specific-parts-of-keys"/>.</t>
</list></t>
</li>
</ul>
</section>
</section>
<section anchor="secret-key-packet-formats"><name>Secret-Key anchor="secret-key-packet-formats">
<name>Secret-Key Packet Formats</name>
<t>The Secret-Key and Secret-Subkey packets contain all the data of the Public-Key and Public-Subkey packets, with additional algorithm-specific secret-key data appended, usually in encrypted form.</t>
<t>The packet contains:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>The fields of a Public-Key or Public-Subkey packet, as described above.</t>
</li>
<li>
<!-- [rfced] In Section 3.7.2.1, the special values 253 (AEAD), 254
(CFB), and 255 (MalleableCFB) are introduced in ascending order,
but in Sections 5.5.3 and 13.7, these values appear in descending
order. Are any updates needed to make these instances
consistent? See a few examples below.
Original:
Later implementations indicate a protected secret key by storing a
special value 253 (AEAD), 254 (CFB), or 255 (MalleableCFB) in the S2K
usage octet.
(Section 5.5.3)
255 (MalleableCFB), 254 (CFB), or 253 (AEAD) indicates that
a string-to-key specifier and other parameters will follow.
- If string-to-key usage octet was 255, 254, or 253, a one-octet
symmetric encryption algorithm.
(Section 13.7)
- Value 255 (MalleableCFB) or raw cipher algorithm: where the
trailing 2-octet checksum does not match.
- Value 254 (CFB): where the SHA1 checksum is mismatched.
- Value 253 (AEAD): where the AEAD authentication tag is invalid.
-->
<t>One octet (the "S2K usage octet") indicating whether and how the secret key material is protected by a passphrase.
Zero indicates that the secret-key data is not encrypted. 255 (MalleableCFB), 254 (CFB), or 253 (AEAD) indicates that a string-to-key specifier and other parameters will follow.
Any other value is a symmetric-key encryption algorithm identifier.
A version 6 packet <bcp14>MUST NOT</bcp14> use the value 255 (MalleableCFB).</t>
</li>
<li>
<t>Only for a version 6 packet where the secret key material is encrypted (that is, where the previous octet is not zero), a one-octet scalar octet count of the cumulative length of all the following conditionally included string-to-key parameter fields.</t>
</li>
<li>
<t>Conditionally included string-to-key parameter fields: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>If the string-to-key usage octet was 255, 254, or 253, a one-octet symmetric encryption algorithm.</t>
</li>
<li>
<t>If the string-to-key usage octet was 253 (AEAD), a one-octet AEAD algorithm.</t>
</li>
<li>
<t>Only for a version 6 packet, and if the string-to-key usage octet was 254, 254 or 253, a one-octet count of the size of the one field following this octet.</t>
</li>
<li>
<t>If the string-to-key usage octet was 255, 254, or 253, a string-to-key (S2K) specifier.
The length of the string-to-key specifier depends on its type (see <xref target="s2k-types"/>).</t>
</li>
<li>
<t>If the string-to-key usage octet was 253 (AEAD), an initialization vector (IV) IV of a size specified by the AEAD algorithm (see <xref target="version-two-seipd"/>), which is used as the nonce for the AEAD algorithm.</t>
</li>
<li>
<t>If the string-to-key usage octet was 255, 254, or a cipher algorithm ID (that is, the secret data uses some form of CFB encryption), an initialization vector (IV) IV of the same length as the cipher's block size.</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Plain or encrypted multiprecision integers comprising the secret key data.
This is algorithm-specific algorithm specific and described in <xref target="algorithm-specific-parts-of-keys"/>.
If the string-to-key usage octet is 253 (AEAD), then an AEAD authentication tag is at the end of that data.
If the string-to-key usage octet is 254 (CFB), a 20-octet SHA-1 hash of the plaintext of the algorithm-specific portion is appended to plaintext and encrypted with it.
If the string-to-key usage octet is 255 (MalleableCFB) or another nonzero non-zero value (that is, a symmetric-key encryption algorithm identifier), a two-octet checksum of the plaintext of the algorithm-specific portion (sum of all octets, mod 65536) is appended to plaintext and encrypted with it.
(This is deprecated and <bcp14>SHOULD NOT</bcp14> be used, used; see below.)</t>
</li>
<li>
<t>Only for a version 3 or 4 packet where the string-to-key usage octet is zero, a two-octet checksum of the algorithm-specific portion (sum of all octets, mod 65536).</t>
</list></t>
</li>
</ul>
<t>The details about storing algorithm-specific secrets above are summarized in <xref target="secret-key-protection-registry"/>.</t>
<t>Note that the version 6 packet format adds two count values to help parsing packets with unknown S2K or public key algorithms.</t>
<t>Secret MPI values can be encrypted using a passphrase. If a string-to-key specifier is given, that it describes the algorithm for converting the passphrase to a key, else key; otherwise, a simple MD5 hash of the passphrase is used. An implementation producing a passphrase-protected secret key packet <bcp14>MUST</bcp14> use a string-to-key specifier; the simple hash is for read-only backward compatibility, though implementations <bcp14>MAY</bcp14> continue to use existing private keys in the old format. The cipher for encrypting the MPIs is specified in the Secret-Key packet.</t>
<t>Encryption/decryption of the secret data is done using the key created from the passphrase and the initialization vector from the packet.
If the string-to-key usage octet is not 253, CFB mode is used.
A different mode is used with v3 keys (which are only RSA) than with other key formats.
With v3 keys, the MPI bit count prefix (that is, the first two octets) is not encrypted.
Only the MPI non-prefix data is encrypted.
Furthermore, the CFB state is resynchronized at the beginning of each new MPI value, value so that the CFB block boundary is aligned with the start of the MPI data.</t>
<t>With v4 and v6 keys, a simpler method is used.
All secret MPI values are encrypted, including the MPI bitcount bit count prefix.</t>
<t>If the string-to-key usage octet is 253, the key encryption key KEK is derived using HKDF (<xref target="RFC5869"/>) <xref target="RFC5869"/> to provide key separation. SHA256 (<xref target="RFC6234"/>) <xref target="RFC6234"/> is used as the hash algorithm for HKDF.
The Initial Keying Material (IKM) IKM for HKDF is the key derived from S2K.
No salt is used. The info parameter is comprised of the Packet Type ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 carry the packet type ID), the packet version, and the cipher-algo and AEAD-mode used to encrypt the key material.</t>
<!-- [rfced] Is "the encrypted MPI values are encrypted as" correct, or
should this be "the MPI values are encrypted as"? And is
"four-octet octet count" correct, or should this be
"four-octet scalar octet count" for consistency?
Original:
Then, the encrypted MPI values are encrypted as one combined
plaintext using one of the AEAD algorithms specified for
version 2 of the Symmetrically Encrypted Integrity Protected
Data packet.
For a version 6 key packet, the second
octet would be 0x06, and the four-octet octet count of the public key
material would be included as well (see Section 5.5.2).
Perhaps:
Then, the MPI values are encrypted as one combined plaintext
using one of the AEAD algorithms specified for version 2 of
the Symmetrically Encrypted Integrity Protected Data packet.
For a version 6 key packet, the second octet would be
0x06, and the four-octet scalar octet count of the
public key material would be included as well (see
Section 5.5.2).
-->
<t>Then, the encrypted MPI values are encrypted as one combined plaintext using one of the AEAD algorithms specified for version 2 of the Symmetrically Encrypted Integrity Protected Data packet.
Note that no chunks are used and that there is only one authentication tag.
As additional data, the Packet Type ID in OpenPGP format encoding (bits 7 and 6 are set, and bits 5-0 carry the packet type ID), followed by the public key packet fields, starting with the packet version number, are passed to the AEAD algorithm. For example, the additional data used with a Secret-Key packet of version 4 consists of the octets 0xC5, 0x04, followed by four octets of creation time, one octet denoting the public-key algorithm, and the algorithm-specific public-key parameters.
For a Secret-Subkey packet, the first octet would be 0xC7.
For a version 6 key packet, the second octet would be 0x06, and the four-octet octet count of the public key material would be included as well (see <xref target="public-key-packet-formats"/>).</t>
<t>The two-octet checksum that follows the algorithm-specific portion is the algebraic sum, mod 65536, of the plaintext of all the algorithm-specific octets (including the MPI prefix and data).
With v3 keys, the checksum is stored in the clear. With v4 keys, the checksum is encrypted like the algorithm-specific data. This value is used to check that the passphrase was correct.
However, this checksum is deprecated; deprecated, and an implementation <bcp14>SHOULD NOT</bcp14> use it, but it; instead, an implementation should rather use the SHA-1 hash denoted with a usage octet of 254.
The reason for this is that there are some attacks that involve undetectably modifying the secret key. key undetected.
If the string-to-key usage octet is 253 253, no checksum or SHA-1 hash is used used, but the authentication tag of the AEAD algorithm follows.</t>
<t>When decrypting the secret key material using any of these schemes (that is, where the usage octet is non-zero), the resulting cleartext octet stream must be well-formed. well formed.
In particular, an implementation <bcp14>MUST NOT</bcp14> interpret octets beyond the unwrapped cleartext octet stream as part of any of the unwrapped MPI objects.
Furthermore, an implementation <bcp14>MUST</bcp14> reject as unusable any secret key material whose cleartext length does not align with the lengths of the unwrapped MPI objects.</t> objects as unusable.</t>
</section>
<section anchor="key-ids-fingerprints"><name>Key anchor="key-ids-fingerprints">
<name>Key IDs and Fingerprints</name>
<t>Every OpenPGP key has a fingerprint and a key ID.
The computation of these values differs based on the key version.
The fingerprint length varies with the key version, but the key ID (which is only used in v3 PKESK packets, packets; see <xref target="v3-pkesk"/>) is always 64 bits.
The following registry represents the subsections below:</t>
<texttable title="OpenPGP
<table anchor="key-id-fingerprint-registry">
<name>OpenPGP Key ID and Fingerprint registry" anchor="key-id-fingerprint-registry">
<ttcol align='left'>Key Version</ttcol>
<ttcol align='left'>Fingerprint</ttcol>
<ttcol align='left'>Fingerprint Registry</name>
<thead>
<tr>
<th align="left">Key Version</th>
<th align="left">Fingerprint</th>
<th align="left">Fingerprint Length (bits)</ttcol>
<ttcol align='left'>Key ID</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>3</c>
<c>MD5(MPIs (Bits)</th>
<th align="left">Key ID</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">3</td>
<td align="left">MD5(MPIs without length octets)</c>
<c>128</c>
<c>low octets)</td>
<td align="left">128</td>
<td align="left">low 64 bits of RSA modulus</c>
<c><xref target="v3-key-id-fingerprint"/></c>
<c>4</c>
<c>SHA1(normalized modulus</td>
<td align="left">
<xref target="v3-key-id-fingerprint"/></td>
</tr>
<tr>
<td align="left">4</td>
<td align="left">SHA1(normalized pubkey packet)</c>
<c>160</c>
<c>last packet)</td>
<td align="left">160</td>
<td align="left">last 64 bits of fingerprint</c>
<c><xref target="v4-key-id-fingerprint"/></c>
<c>6</c>
<c>SHA256(normalized fingerprint</td>
<td align="left">
<xref target="v4-key-id-fingerprint"/></td>
</tr>
<tr>
<td align="left">6</td>
<td align="left">SHA256(normalized pubkey packet)</c>
<c>256</c>
<c>first packet)</td>
<td align="left">256</td>
<td align="left">first 64 bits of fingerprint</c>
<c><xref target="v6-key-id-fingerprint"/></c>
</texttable> fingerprint</td>
<td align="left">
<xref target="v6-key-id-fingerprint"/></td>
</tr>
</tbody>
</table>
<section anchor="v3-key-id-fingerprint"><name>Version anchor="v3-key-id-fingerprint">
<name>Version 3 Key ID and Fingerprint</name>
<t>For a v3 key, the eight-octet Key ID consists of the low 64 bits of the public modulus of the RSA key.</t>
<t>The fingerprint of a v3 key is formed by hashing the body (but not the two-octet length) of the MPIs that form the key material (public modulus n, followed by exponent e) with MD5.
Note that both v3 keys and MD5 are deprecated.</t>
</section>
<section anchor="v4-key-id-fingerprint"><name>Version anchor="v4-key-id-fingerprint">
<name>Version 4 Key ID and Fingerprint</name>
<t>A v4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the two-octet packet length, followed by the entire Public-Key packet starting with the version field.
The Key ID is the low-order 64 bits of the fingerprint.
Here are the fields of the hash material, with the including an example of an Ed25519 key:</t>
<t>a.1) 0x99
<ol type="a.%d)">
<li>0x99 (1 octet)</t>
<t>a.2) two-octet, octet)</li>
<li>two-octet, big-endian scalar octet count of (b)-(e)</t>
<t>b) version (b)-(e)</li>
</ol>
<ol type="%c)" start="2">
<li>version number = 4 (1 octet);</t>
<t>c) timestamp octet)</li>
<li>timestamp of key creation (4 octets);</t>
<t>d) algorithm octets)</li>
<li>algorithm (1 octet): 27 = Ed25519 (example);</t>
<t>e) Algorithm-specific fields.</t>
<t>Algorithm-Specific Fields (example)</li>
<li>algorithm-specific fields</li>
</ol>
<t>Algorithm-specific fields for Ed25519 keys (example):</t>
<t>e.1) 32
<ol type="e.%d)">
<li>32 octets representing the public key.</t> key</li>
</ol>
</section>
<section anchor="v6-key-id-fingerprint"><name>Version anchor="v6-key-id-fingerprint">
<name>Version 6 Key ID and Fingerprint</name>
<t>A v6 fingerprint is the 256-bit SHA2-256 hash of the octet 0x9B, followed by the four-octet packet length, followed by the entire Public-Key packet starting with the version field.
The Key ID is the high-order 64 bits of the fingerprint.
Here are the fields of the hash material, with the including an example of an Ed25519 key:</t>
<t>a.1) 0x9B
<ol type="a.%d)">
<li>0x9B (1 octet)</t>
<t>a.2) four-octet octet)</li>
<li>four-octet scalar octet count of (b)-(f)</t>
<t>b) version (b)-(f)</li>
</ol>
<ol type="%c)" start="2">
<li>version number = 6 (1 octet);</t>
<t>c) timestamp octet)</li>
<li>timestamp of key creation (4 octets);</t>
<t>d) algorithm octets)</li>
<li>algorithm (1 octet): 27 = Ed25519 (example);</t>
<t>e) four-octet (example)</li>
<li>four-octet scalar octet count for the following key material;</t>
<t>f) algorithm-specific fields.</t>
<t>Algorithm-Specific Fields material</li>
<li>algorithm-specific fields</li>
</ol>
<t>Algorithm-specific fields for Ed25519 keys (example):</t>
<t>e.1) 32
<ol type="e.%d)">
<li>32 octets representing the public key.</t> key</li>
</ol>
<t>Note that it is possible for there to be collisions of Key IDs --- -- that is, two different keys with the same Key ID. Note that there is a much smaller, but still non-zero, probability that two different keys have the same fingerprint.</t>
<t>Also note that if v3, v4, and v6 format keys share the same RSA key material, they will have different Key IDs as well as different fingerprints.</t>
<t>Finally, the Key ID and fingerprint of a subkey are calculated in the same way as for a primary key, including the 0x99 (v4 key) or 0x9B (v6 key) as the first octet (even though this is not a valid packet type ID for a public subkey).</t>
</section>
</section>
<section anchor="algorithm-specific-parts-of-keys"><name>Algorithm-specific anchor="algorithm-specific-parts-of-keys">
<name>Algorithm-Specific Parts of Keys</name>
<t>The public and secret key format specifies formats specify algorithm-specific parts of a key.
The following sections describe them in detail.</t>
<section anchor="key-rsa"><name>Algorithm-Specific anchor="key-rsa">
<!-- [rfced] In Sections 5.5.5.1 to 5.5.5.10, the phrases "The public
key is this" and "The secret key is this" are used. Would it read
better if "is" is updated to "comprises" or "consists of"? Please
let us know your preference.
One example
Original:
The public key is this series of multiprecision integers:
Perhaps:
A) For RSA keys, the public key comprises this series of
multiprecision integers:
or
B) For RSA keys, the public key consists of this series of
multiprecision integers:
-->
<name>Algorithm-Specific Part for RSA Keys</name>
<t>The
<t>For RSA keys, the public key is this series of multiprecision integers:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>MPI of RSA public modulus n;</t> n,</t>
</li>
<li>
<t>MPI of RSA public encryption exponent e.</t>
</list></t>
</li>
</ul>
<t>The secret key is this series of multiprecision integers:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>MPI of RSA secret exponent d;</t>
</li>
<li>
<t>MPI of RSA secret prime value p;</t>
</li>
<li>
<t>MPI of RSA secret prime value q (p < q);</t> q); and</t>
</li>
<li>
<t>MPI of u, the multiplicative inverse of p, mod q.</t>
</list></t>
</li>
</ul>
</section>
<section anchor="key-dsa"><name>Algorithm-Specific anchor="key-dsa">
<name>Algorithm-Specific Part for DSA Keys</name>
<t>The
<t>For DSA keys, the public key is this series of multiprecision integers:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>MPI of DSA prime p;</t>
</li>
<li>
<t>MPI of DSA group order q (q is a prime divisor of p-1);</t>
</li>
<li>
<t>MPI of DSA group generator g;</t> g; and</t>
</li>
<li>
<t>MPI of DSA public-key value y (= g**x mod p where x is secret).</t>
</list></t>
</li>
</ul>
<t>The secret key is this single multiprecision integer:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>MPI of DSA secret exponent x.</t>
</list></t>
</li>
</ul>
</section>
<section anchor="key-elgamal"><name>Algorithm-Specific anchor="key-elgamal">
<name>Algorithm-Specific Part for Elgamal Keys</name>
<t>The
<t>For Elgamal keys, the public key is this series of multiprecision integers:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>MPI of Elgamal prime p;</t>
</li>
<li>
<t>MPI of Elgamal group generator g;</t> g; and</t>
</li>
<li>
<t>MPI of Elgamal public key value y (= g**x mod p where x is secret).</t>
</list></t>
</li>
</ul>
<t>The secret key is this single multiprecision integer:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>MPI of Elgamal secret exponent x.</t>
</list></t>
</li>
</ul>
</section>
<section anchor="key-ecdsa"><name>Algorithm-Specific anchor="key-ecdsa">
<name>Algorithm-Specific Part for ECDSA Keys</name>
<t>The
<t>For ECDSA keys, the public key is this series of values:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A variable-length field containing a curve OID, which is formatted as follows: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>A one-octet size of the following field; values 0 and 0xFF are reserved for future extensions,</t> extensions.</t>
</li>
<li>
<t>The octets representing a curve OID (defined OID, as defined in <xref target="ec-curves"/>);</t>
</list></t>
<t>MPI target="ec-curves"/>.</t>
</li>
</ul>
</li>
<li>
<t>An MPI of an EC point representing a public key.</t>
</list></t>
</li>
</ul>
<t>The secret key is this single multiprecision integer:</t>
<t><list style="symbols">
<t>MPI
<ul spacing="normal">
<li>
<t>An MPI of an integer representing the secret key, which is a scalar of the public EC point.</t>
</list></t>
</li>
</ul>
</section>
<section anchor="key-eddsa-legacy"><name>Algorithm-Specific anchor="key-eddsa-legacy">
<name>Algorithm-Specific Part for EdDSALegacy Keys (deprecated)</name>
<t>The (Deprecated)</name>
<t>For EdDSALegal keys (deprecated), the public key is this series of values:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A variable-length field containing a curve OID, formatted as follows: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>A one-octet size of the following field; values 0 and 0xFF are reserved for future extensions,</t> extensions.</t>
</li>
<li>
<t>The octets representing a curve OID, as defined in <xref target="ec-curves"/>;</t>
</list></t> target="ec-curves"/>.</t>
</li>
</ul>
</li>
<li>
<t>An MPI of an EC point representing a public key Q in prefixed native form (see <xref target="ec-point-prefixed-native"/>).</t>
</list></t>
</li>
</ul>
<t>The secret key is this single multiprecision integer:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>An MPI-encoded octet string representing the native form of the secret key, key in the curve-specific format format, as described in <xref target="curve-specific-formats"/>.</t>
</list></t>
</li>
</ul>
<t>Note that the native form for an EdDSA secret key is a fixed-width sequence of unstructured random octets, with size corresponding to the specific curve. That sequence of random octets is used with a cryptographic digest to produce both a curve-specific secret scalar and a prefix used when making a signature.
See <xref section="5.1.5" sectionFormat="of" target="RFC8032"/> for more details about how to use the native octet strings for Ed25519Legacy.
The value stored in an OpenPGP EdDSALegacy secret key packet is the original sequence of random octets.</t>
<t>Note that the only curve defined for use with EdDSALegacy is the Ed25519Legacy OID.</t>
</section>
<section anchor="key-ecdh"><name>Algorithm-Specific anchor="key-ecdh">
<name>Algorithm-Specific Part for ECDH Keys</name>
<t>The
<t>For ECDH keys, the public key is this series of values:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A variable-length field containing a curve OID, which is formatted as follows: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>A one-octet size of the following field; values 0 and 0xFF are reserved for future extensions,</t>
<t>Octets extensions.</t>
</li>
<li>
<t>The octets representing a curve OID, as defined in <xref target="ec-curves"/>;</t>
</list></t>
<t>MPI target="ec-curves"/>.</t>
</li>
</ul>
</li>
<li>
<t>An MPI of an EC point representing a public key, in the point format associated with the curve curve, as specified in <xref target="curve-specific-formats"/>.</t>
</li>
<li>
<t>A variable-length field containing KDF key derivation function (KDF) parameters, which is formatted as follows: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>A one-octet size of the following fields; values 0 and 0xFF are reserved for future extensions,</t> extensions.</t>
</li>
<li>
<t>A one-octet value 1, reserved for future extensions,</t> extensions.</t>
</li>
<li>
<t>A one-octet hash function ID used with a KDF,</t> KDF.</t>
</li>
<li>
<t>A one-octet algorithm ID for the symmetric algorithm that is used to wrap the symmetric key used for the message encryption; see <xref target="ecdh"/> for details.</t>
</list></t>
</list></t>
</li>
</ul>
</li>
</ul>
<t>The secret key is this single multiprecision integer:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>An MPI representing the secret key, in the curve-specific format described in <xref target="curve-specific-formats"/>.</t>
</list></t>
</li>
</ul>
<section anchor="ecdh-secret-key-material"><name>ECDH anchor="ecdh-secret-key-material">
<name>ECDH Secret Key Material</name>
<t>When curve NIST P-256, NIST P-384, NIST P-521, brainpoolP256r1, brainpoolP384r1, or brainpoolP512r1 are used in ECDH, their secret keys are represented as a simple integer in standard MPI form.
Other curves are presented on the wire differently (though still as a single MPI), as described below and in <xref target="curve-specific-formats"/>.</t>
<section anchor="curve25519-secrets"><name>Curve25519Legacy anchor="curve25519-secrets">
<name>Curve25519Legacy ECDH Secret Key Material (deprecated)</name> (Deprecated)</name>
<t>A Curve25519Legacy secret key is stored as a standard integer in big-endian MPI form.
Curve25519Legacy <bcp14>MUST NOT</bcp14> be used in key packets version 6 or above.
Note that this form is in reverse octet order from the little-endian "native" form found in <xref target="RFC7748"/>.</t>
<t>Note also that the integer for a Curve25519Legacy secret key for OpenPGP <bcp14>MUST</bcp14> have the appropriate form: form; that is, it <bcp14>MUST</bcp14> be divisible by 8, <bcp14>MUST</bcp14> be at least 2**254, and <bcp14>MUST</bcp14> be less than 2**255.
The length of this MPI in bits is by definition always 255, so the two leading octets of the MPI will always be <spanx style="verb">00 FF</spanx> <tt>00 FF</tt>, and reversing the following 32 octets from the wire will produce the "native" form.</t>
<t>When generating a new Curve25519Legacy secret key from 32 fully-random fully random octets, the following pseudocode produces the MPI wire format (note the similarity to <spanx style="verb">decodeScalar25519</spanx> from <tt>decodeScalar25519</tt> as described in <xref target="RFC7748"/>):</t>
<figure><artwork><![CDATA[
<sourcecode type="pseudocode"><![CDATA[
def curve25519Legacy_MPI_from_random(octet_list):
octet_list[0] &= 248
octet_list[31] &= 127
octet_list[31] |= 64
mpi_header = [ 0x00, 0xFF ]
return mpi_header || reversed(octet_list)
]]></artwork></figure>
]]></sourcecode>
</section>
</section>
</section>
<section anchor="key-x25519"><name>Algorithm-Specific anchor="key-x25519">
<name>Algorithm-Specific Part for X25519 Keys</name>
<t>The
<t>For X25519 keys, the public key is this single value:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>32 octets of the native public key.</t>
</list></t>
</li>
</ul>
<t>The secret key is this single value:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>32 octets of the native secret key.</t>
</list></t>
</li>
</ul>
<t>See <xref section="6.1" sectionFormat="of" target="RFC7748"/> for more details about how to use the native octet strings.
The value stored in an OpenPGP X25519 secret key packet is the original sequence of random octets.
The value stored in an OpenPGP X25519 public key packet is the value X25519(secretKey, 9).</t>
</section>
<section anchor="key-x448"><name>Algorithm-Specific anchor="key-x448">
<name>Algorithm-Specific Part for X448 Keys</name>
<t>The
<t>For X448 keys, the public key is this single value:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>56 octets of the native public key.</t>
</list></t>
</li>
</ul>
<t>The secret key is this single value:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>56 octets of the native secret key.</t>
</list></t>
</li>
</ul>
<t>See <xref section="6.2" sectionFormat="of" target="RFC7748"/> for more details about how to use the native octet strings.
The value stored in an OpenPGP X448 secret key packet is the original sequence of random octets.
The value stored in an OpenPGP X448 public key packet is the value X448(secretKey, 5).</t>
</section>
<section anchor="key-ed25519"><name>Algorithm-Specific anchor="key-ed25519">
<name>Algorithm-Specific Part for Ed25519 Keys</name>
<t>The
<t>For Ed25519 keys, the public key is this single value:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>32 octets of the native public key.</t>
</list></t>
</li>
</ul>
<t>The secret key is this single value:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>32 octets of the native secret key.</t>
</list></t>
</li>
</ul>
<t>See <xref section="5.1.5" sectionFormat="of" target="RFC8032"/> for more details about how to use the native octet strings.
The value stored in an OpenPGP Ed25519 secret key packet is the original sequence of random octets.</t>
</section>
<section anchor="key-ed448"><name>Algorithm-Specific anchor="key-ed448">
<name>Algorithm-Specific Part for Ed448 Keys</name>
<t>The
<t>For Ed448 keys, the public key is this single value:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>57 octets of the native public key.</t>
</list></t>
</li>
</ul>
<t>The secret key is this single value:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>57 octets of the native secret key.</t>
</list></t>
</li>
</ul>
<t>See <xref section="5.2.5" sectionFormat="of" target="RFC8032"/> for more details about how to use the native octet strings.
The value stored in an OpenPGP Ed448 secret key packet is the original sequence of random octets.</t>
</section>
</section>
</section>
<section anchor="compressed-data"><name>Compressed anchor="compressed-data">
<name>Compressed Data Packet (Type ID 8)</name>
<t>The Compressed Data packet contains compressed data.
Typically, this packet is found as the contents of an encrypted packet, or following a Signature or One-Pass Signature packet, and contains a literal data packet.</t>
<t>The body of this packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<!-- [rfced] Please let us know how we may update this sentence for
clarity as it does not parse (the lead-in sentence is provided
for context). Is there a word(s) missing after "used"? Please let
us know if the perhaps text captures the intended meaning or if
you prefer otherwise.
Original:
The body of this packet consists of:
* One octet that gives the algorithm used to compress
the packet.
Perhaps:
The body of this packet consists of:
* One octet that gives the algorithm used the ability to compress
the packet.
-->
<t>One octet that gives the algorithm used to compress the packet.</t>
</li>
<li>
<t>Compressed data, which makes up the remainder of the packet.</t>
</list></t>
</li>
</ul>
<t>A Compressed Data packet's body contains data that is a compression of a series of OpenPGP packets.
See <xref target="packet-sequence-composition"/> for details on how messages are formed.</t>
<t>A ZIP-compressed series of packets is compressed into raw <xref target="RFC1951"/> DEFLATE blocks.</t> blocks <xref target="RFC1951"/>.</t>
<t>A ZLIB-compressed series of packets is compressed with raw <xref target="RFC1950"/> ZLIB-style blocks.</t> blocks <xref target="RFC1950"/>.</t>
<t>A BZip2-compressed series of packets is compressed using the BZip2 <xref target="BZ2"/> algorithm.</t>
<t>An implementation that generates a Compressed Data packet <bcp14>MUST</bcp14> use the non-legacy non-Legacy format for packet framing (see <xref target="openpgp-packet-format"/>).
It <bcp14>MUST NOT</bcp14> generate a Compressed Data packet with Legacy format (<xref target="legacy-packet-format"/>)</t>
<t>An implementation that deals with either historic data or data generated by legacy implementations predating support for <xref target="RFC2440"/> <bcp14>MAY</bcp14> interpret Compressed Data packets that use the Legacy format for packet framing.</t>
</section>
<section anchor="sed"><name>Symmetrically anchor="sed">
<name>Symmetrically Encrypted Data Packet (Type ID 9)</name>
<t>The Symmetrically Encrypted Data packet contains data encrypted with a symmetric-key algorithm. When it has been decrypted, it contains other packets (usually a literal data packet or compressed data packet, but in theory theory, it could be other Symmetrically Encrypted Data packets or sequences of packets that form whole OpenPGP messages).</t>
<t>This packet is obsolete.
An implementation <bcp14>MUST NOT</bcp14> create this packet.
An implementation <bcp14>SHOULD</bcp14> reject such a packet and stop processing the message.
If an implementation chooses to process the packet anyway, it <bcp14>MUST</bcp14> return a clear warning that a non-integrity protected non-integrity-protected packet has been processed.</t>
<t>This packet format is impossible to handle safely in general because the ciphertext it provides is malleable.
See <xref target="ciphertext-malleability"/> about selecting a better OpenPGP encryption container that does not have this flaw.</t>
<t>The body of this packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A random prefix, containing block-size random octets (for example, 16 octets for a 128-bit block length) followed by a copy of the last two octets, encrypted together using Cipher Feedback (CFB) mode, with an Initial Vector (IV) IV of all zeros.</t>
</li>
<li>
<t>Data encrypted using CFB mode, with the last block-size octets of the first ciphertext as the IV.</t>
</list></t>
</li>
</ul>
<t>The symmetric cipher used may be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Data packet.
In that case, the cipher algorithm ID is prefixed to the session key before it is encrypted.
If no packets of these types precede the encrypted data, the IDEA algorithm is used with the session key calculated as the MD5 hash of the passphrase, though this use is deprecated.</t>
<t>The data is encrypted in CFB mode (see <xref target="cfb-mode"/>).
For the random prefix, the Initial Vector (IV) IV is specified as all zeros. Instead of achieving randomized encryption through an IV, a string of length equal to the block size of the cipher plus two is encrypted for this purpose. The first block-size octets (for example, 16 octets for a 128-bit block length) are random, and the following two octets are copies of the last two octets of the first block-size random octets. For example, for a 16-octet block length, octet 17 is a copy of octet 15 15, and octet 18 is a copy of octet 16. For a cipher of block length 8, octet 9 is a copy of octet 7, and octet 10 is a copy of octet 8. (In both of these examples, we consider the first octet to be numbered 1.)</t>
<t>After encrypting these block-size-plus-two octets, a new CFB context is created for the encryption of the data, with the last block-size octets of the first ciphertext as the IV. (Alternatively and equivalently, the CFB state is resynchronized: the last block-size octets of ciphertext are passed through the cipher cipher, and the block boundary is reset.)</t>
<t>The repetition of two octets in the random prefix allows the receiver to immediately check whether the session key is incorrect.
See <xref target="quick-check-oracle"/> for hints on the proper use of this "quick check".</t>
</section>
<section anchor="marker-packet"><name>Marker anchor="marker-packet">
<name>Marker Packet (Type ID 10)</name>
<t>The body of this the Marker packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).</t>
</list></t>
</li>
</ul>
<t>Such a packet <bcp14>MUST</bcp14> be ignored when received.</t>
</section>
<section anchor="lit"><name>Literal anchor="lit">
<name>Literal Data Packet (Type ID 11)</name>
<t>A Literal Data packet contains the body of a message; that is, data that is not to be further interpreted.</t>
<t>The body of this packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet field that describes how the data is formatted. <vspace blankLines='1'/> </t>
<t>
If it is a <spanx style="verb">b</spanx> <tt>b</tt> (0x62), then the Literal packet contains binary data.
If it is a <spanx style="verb">u</spanx> <tt>u</tt> (0x75), then the Literal packet contains UTF-8-encoded text data, data and thus may need line ends converted to local form, form or other text mode changes. <vspace blankLines='1'/>
Older </t>
<t>
Previous versions of the OpenPGP specification used <spanx style="verb">t</spanx> <tt>t</tt> (0x74) to indicate textual data, data but did not specify the character encoding. Implementations <bcp14>SHOULD NOT</bcp14> emit this value.
An implementation that receives a literal data packet with this value in the format field <bcp14>SHOULD</bcp14> interpret the packet data as UTF-8 encoded text, unless reliable (not attacker-controlled) context indicates a specific alternate text encoding. This mode is deprecated due to its ambiguity. <vspace blankLines='1'/> </t>
<t>
Some implementations predating <xref target="RFC2440"/> also defined a value of <spanx style="verb">l</spanx> <tt>l</tt> as a 'local' "local" mode for machine-local conversions. <xref target="RFC1991"/> incorrectly stated states that this local mode flag as <spanx style="verb">1</spanx> is <tt>1</tt> (ASCII numeral one). Both of these local modes are deprecated.</t>
<t>File
</li>
<li>
<t>The file name as a string (one-octet length, followed by a file name).
This may be a zero-length string. Commonly, if the source of the encrypted data is a file, this it will be the name of the encrypted file. An implementation <bcp14>MAY</bcp14> consider the file name in the Literal packet to be a more authoritative name than the actual file name.</t>
</li>
<li>
<t>A four-octet number that indicates a date associated with the literal data.
Commonly, the date might be the modification date of a file, or the time the packet was created, or a zero that indicates no specific time.</t>
</li>
<li>
<t>The remainder of the packet is literal data. <vspace blankLines='1'/> </t>
<t>
Text data <bcp14>MUST</bcp14> be encoded with UTF-8 (see <xref target="RFC3629"/>) and stored with <CR><LF> text endings (that is, network-normal line endings).
These should be converted to native line endings by the receiving implementation.</t>
</list></t>
</li>
</ul>
<t>Note that OpenPGP signatures do not include the formatting octet, the file name, and the date field of the literal packet in a signature hash and thus hash; therefore, those fields are not protected against tampering in a signed document. A receiving implementation <bcp14>MUST NOT</bcp14> treat those fields as though they were cryptographically secured by the surrounding signature either when either representing them to the user or acting on them.</t>
<t>Due to their inherent malleability, an implementation that generates a literal data packet <bcp14>SHOULD</bcp14> avoid storing any significant data in these fields.
If the implementation is certain that the data is textual and is encoded with UTF-8 (for example, if it will follow this literal data packet with a signature packet of type 0x01 (see <xref target="signature-types"/>), it <bcp14>MAY</bcp14> set the format octet to <spanx style="verb">u</spanx>. <tt>u</tt>.
Otherwise, it <bcp14>MUST</bcp14> set the format octet to <spanx style="verb">b</spanx>. <tt>b</tt>.
It <bcp14>SHOULD</bcp14> set the filename to the empty string (encoded as a single zero octet), octet) and the timestamp to zero (encoded as four zero octets).</t>
<t>An application that wishes to include such filesystem metadata within a signature is advised to sign an encapsulated archive (for example, <xref target="PAX"/>).</t>
<t>An implementation that generates a Literal Data packet <bcp14>MUST</bcp14> use the OpenPGP format for packet framing (see <xref target="openpgp-packet-format"/>).
It <bcp14>MUST NOT</bcp14> generate a Literal Data packet with Legacy format (<xref target="legacy-packet-format"/>)</t> target="legacy-packet-format"/>).</t>
<t>An implementation that deals with either historic data or data generated by an implementation that predates support for <xref target="RFC2440"/> <bcp14>MAY</bcp14> interpret Literal Data packets that use the Legacy format for packet framing.</t>
<section anchor="for-eyes-only"><name>Special anchor="for-eyes-only">
<name>Special Filename _CONSOLE (Deprecated)</name>
<t>The Literal Data packet's filename field has a historical special case for the special name <spanx style="verb">_CONSOLE</spanx>. <tt>_CONSOLE</tt>.
When the filename field is <spanx style="verb">_CONSOLE</spanx>, <tt>_CONSOLE</tt>, the message is considered to be "for your eyes only".
This advises that the message data is unusually sensitive, and the receiving program should process it more carefully, perhaps avoiding storing the received data to disk, for example.</t>
<t>An OpenPGP deployment that generates literal data packets <bcp14>MUST NOT</bcp14> depend on this indicator being honored in any particular way.
It cannot be enforced, and the field itself is not covered by any cryptographic signature.</t>
<t>It is <bcp14>NOT RECOMMENDED</bcp14> to use this special filename in a newly-generated newly generated literal data packet.</t>
</section>
</section>
<section anchor="trust"><name>Trust anchor="trust">
<name>Trust Packet (Type ID 12)</name>
<t>The Trust packet is used only within keyrings and is not normally exported.
Trust packets contain data that record the user's specifications of which keyholders are trustworthy introducers, along with other information that implementation uses for trust information.
The format of Trust packets is defined by a given implementation.</t>
<t>Trust packets <bcp14>SHOULD NOT</bcp14> be emitted to output streams that are transferred to other users, and they <bcp14>SHOULD</bcp14> be ignored on any input other than local keyring files.</t>
</section>
<section anchor="uid"><name>User anchor="uid">
<name>User ID Packet (Type ID 13)</name>
<t>A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the keyholder.
By convention, it includes an <xref target="RFC2822"/> a mail name-addr, name-addr as described in <xref target="RFC2822"/>, but there are no restrictions on its content. The packet length in the header specifies the length of the User ID.</t>
</section>
<section anchor="user-attribute-packet"><name>User anchor="user-attribute-packet">
<name>User Attribute Packet (Type ID 17)</name>
<t>The User Attribute packet is a variation of the User ID packet.
It is capable of storing more types of data than the User ID packet, which is limited to text.
Like the User ID packet, a User Attribute packet may be certified by the key owner ("self-signed") or any other key owner who cares to certify it.
Except as noted, a User Attribute packet may be used anywhere that a User ID packet may be used.</t>
<t>While User Attribute packets are not a required part of the OpenPGP standard, specification, implementations <bcp14>SHOULD</bcp14> provide at least enough compatibility to properly handle a certification signature on the User Attribute packet.
A simple way to do this is by treating the User Attribute packet as a User ID packet with opaque contents, but an implementation may use any method desired.</t>
<t>The User Attribute packet is made up of one or more attribute subpackets.
Each subpacket consists of a subpacket header and a body.
The header consists of:</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>
<t>the subpacket length (1, 2, or 5 octets)</t>
<t>The
</li>
<li>
<t>the subpacket type ID (1 octet)</t>
</list></t>
</li>
</ul>
<t>and is followed by the subpacket specific data.</t>
<t>The following table lists the currently known subpackets:</t>
<texttable title="OpenPGP
<!-- [rfced] Should table 13 include a row for value 0 to match what appears in the IANA registry <https://www.iana.org/assignments/openpgp>?
Registry: OpenPGP User Attribute Subpacket Types registry"
0 Reserved [RFC-ietf-openpgp-crypto-refresh-13]
-->
<table anchor="user-attr-subpacket-types-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Attribute Subpacket</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>1</c>
<c>Image
<name>OpenPGP User Attribute Subpacket Types Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Attribute Subpacket</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">1</td>
<td align="left">Image Attribute Subpacket</c>
<c><xref target="uat-image"/></c>
<c>100-110</c>
<c>Private/Experimental Use</c>
<c> </c>
</texttable> Subpacket</td>
<td align="left">[RFC9580],
<xref target="uat-image"/></td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private/Experimental Use</td>
<td align="left">[RFC9580]</td>
</tr>
</tbody>
</table>
<t>An implementation <bcp14>SHOULD</bcp14> ignore any subpacket of a type that it does not recognize.</t>
<section anchor="uat-image"><name>The Image anchor="uat-image">
<name>Image Attribute Subpacket</name>
<t>The Image Attribute subpacket is used to encode an image, presumably (but not required to be) that of the key owner.</t>
<t>The Image Attribute subpacket begins with an image header.
The first two octets of the image header contain the length of the image header.
Note that unlike other multi-octet numerical values in this document, due to a historical accident accident, this value is encoded as a little-endian number. The image header length is followed by a single octet for the image header version.
The only currently defined version of the image header is 1, which is a 16-octet image header.
The first three octets of a version 1 image header are thus 0x10, 0x00, 0x01.</t>
<texttable title="OpenPGP
<table anchor="image-attribute-version-registry">
<name>OpenPGP Image Attribute Version registry" anchor="image-attribute-version-registry">
<ttcol align='right'>Version</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>1</c>
<c><xref target="uat-image"/></c>
</texttable> Registry</name>
<thead>
<tr>
<th align="right">Version</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">1</td>
<td align="left">
<xref target="uat-image"/></td>
</tr>
</tbody>
</table>
<t>The fourth octet of a version 1 image header designates the encoding format of the image.
The only currently defined encoding format is the value 1 to indicate JPEG.
Image format IDs 100 through 110 are reserved for private Private or experimental use. Experimental Use.
The rest of the version 1 image header is made up of 12 reserved octets, all of which <bcp14>MUST</bcp14> be set to 0.</t>
<texttable title="OpenPGP
<!-- [rfced] Should table 15 include a row for value 0 to match what appears in the IANA registry <https://www.iana.org/assignments/openpgp>?
Registry: OpenPGP Image Attribute Encoding Format registry"
0 Reserved [RFC-ietf-openpgp-crypto-refresh-13]
-->
<table anchor="image-attr-encoding-format-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Encoding</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>1</c>
<c>JPEG</c>
<c>JPEG
<name>OpenPGP Image Attribute Encoding Format Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Encoding</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">1</td>
<td align="left">JPEG</td>
<td align="left">JPEG File Interchange Format (<xref target="JFIF"/>)</c>
<c>100-110</c>
<c>Private/Experimental use</c>
<c> </c>
</texttable> <xref target="JFIF"/></td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private or Experimental Use</td>
<td align="left">[RFC9580]</td>
</tr>
</tbody>
</table>
<t>The rest of the image subpacket contains the image itself.
As the only currently defined image type is JPEG, the image is encoded in the JPEG File Interchange Format (JFIF), a standard file format for JPEG images <xref target="JFIF"/>.</t>
<t>An implementation <bcp14>MAY</bcp14> try to determine the type of an image by examination of the image data if it is unable to handle a particular version of the image header or if a specified encoding format value is not recognized.</t>
</section>
</section>
<section anchor="seipd"><name>Symmetrically anchor="seipd">
<name>Symmetrically Encrypted Integrity Protected Data Packet (Type ID 18)</name>
<t>This
<t>The SEIPD packet (the "SEIPD" packet) contains integrity protected integrity-protected and encrypted data.
When it has been decrypted, it will contain other packets forming an OpenPGP Message (see <xref target="openpgp-messages"/>).</t>
<t>The first octet of this packet is always used to indicate the version number, but different versions contain differently-structured ciphertext. ciphertext that is structured differently. Version 1 of this packet contains data encrypted with a symmetric-key algorithm and is thus protected against modification by the SHA-1 hash algorithm. This mechanism was introduced in <xref target="RFC4880"/> and offers some protections against ciphertext malleability.</t>
<t>Version 2 of this packet contains data encrypted with an authenticated encryption and additional data (AEAD) AEAD construction.
This offers a more cryptographically rigorous defense against ciphertext malleability.
See <xref target="ciphertext-malleability"/> for more details on choosing between these formats.</t>
<t>Any new version of the SEIPD packet should be registered in the registry established in <xref target="encrypted-message-versions"/>.</t>
<section anchor="version-one-seipd"><name>Version anchor="version-one-seipd">
<name>Version 1 Symmetrically Encrypted Integrity Protected Data Packet Format</name>
<t>A version 1 Symmetrically Encrypted Integrity Protected Data packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet version number with value 1.</t>
</li>
<li>
<t>Encrypted data, data -- the output of the selected symmetric-key cipher operating in Cipher Feedback (CFB) CFB mode.</t>
</list></t>
</li>
</ul>
<t>The symmetric cipher used <bcp14>MUST</bcp14> be specified in a Public-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Integrity Protected Data packet. In either case, the cipher algorithm ID is prefixed to the session key before it is encrypted.</t>
<t>The data is encrypted in CFB mode (see <xref target="cfb-mode"/>). The Initial Vector (IV) IV is specified as all zeros. Instead of achieving randomized encryption through an IV, OpenPGP prefixes an octet string to the data before it is encrypted for this purpose.
The length of the octet string equals the block size of the cipher in octets, plus two.
The first octets in the group, of length equal to the block size of the cipher, are random; the last two octets are each copies of their 2nd preceding octet.
For example, with a cipher whose block size is 128 bits or 16 octets, the prefix data will contain 16 random octets, then two more octets, which are copies of the 15th and 16th octets, respectively.
Unlike the deprecated Symmetrically Encrypted Data packet (<xref target="sed"/>), this prefix data is encrypted in the same CFB context, and no special CFB resynchronization is done.</t>
<t>The repetition of 16 bits in the random data prefixed to the message allows the receiver to immediately check whether the session key is incorrect.
See <xref target="quick-check-oracle"/> for hints on the proper use of this "quick check".</t>
<t>Two constant octets with the values 0xD3 and 0x14 are appended to the plaintext. Then, the plaintext of the data to be encrypted is passed through the SHA-1 hash function.
<!-- [rfced] Does the input to the hash function also include all of
the plaintext? If so, may we update the text as follows for
clarity?
Original:
The input to the hash function includes the prefix data described
above; it includes all of the plaintext, including the trailing
constant octets 0xD3, 0x14.
Perhaps:
The input to the hash function is comprised of the prefix data
described above and all of the plaintext, including the trailing
constant octets 0xD3, 0x14.
-->
The input to the hash function includes the prefix data described above; it includes all of the plaintext, including the trailing constant octets 0xD3, 0x14.
The 20 octets of the SHA-1 hash are then appended to the plaintext (after the constant octets 0xD3, 0x14) and encrypted along with the plaintext using the same CFB context.
This trailing checksum is known as the Modification Detection Code (MDC).</t>
<t>During decryption, the plaintext data should be hashed with SHA-1, including the prefix data as well as the trailing constant octets 0xD3, 0x14, but excluding the last 20 octets containing the SHA-1 hash. The computed SHA-1 hash is then compared with the last 20 octets of plaintext.
A mismatch of the hash indicates that the message has been modified and <bcp14>MUST</bcp14> be treated as a security problem. Any failure <bcp14>SHOULD</bcp14> be reported to the user.</t>
<ul empty="true"><li>
<t>NON-NORMATIVE
<t indent="3">NON-NORMATIVE EXPLANATION</t>
<t>The Modification Detection Code (MDC)
<t indent="3">The MDC system, as the integrity
protection mechanism of version 1 of the Symmetrically Encrypted
Integrity Protected Data packet is called, was created to
provide an integrity mechanism that is less strong than a
signature, yet stronger than bare CFB encryption.</t>
<t>It is
<t indent="3">CFB encryption has a limitation of CFB encryption that as damage to the ciphertext
will corrupt the affected cipher blocks and the block following.
Additionally, if data is removed from the end of a CFB-encrypted
block, that removal is undetectable. (Note also that CBC mode has
a similar limitation, but data removed from the front of the block
is undetectable.)</t>
<t>The
<t indent="3">The obvious way to protect or authenticate an encrypted block is
to digitally sign it. However, many people do not wish to
habitually sign data, data for a large number of reasons that are beyond the
scope of this document. Suffice it to say that many people
consider properties such as deniability to be as valuable as
integrity.</t>
<t>OpenPGP
<t indent="3">OpenPGP addresses this desire to have more security than raw
encryption and yet preserve deniability with the MDC system. An
MDC is intentionally not a MAC. Message Authentication Code (MAC). Its name was not selected by
accident. It is analogous to a checksum.</t>
<t>Despite
<t indent="3">Despite the fact that it is a relatively modest system, it has
proved itself in the real world. It is an effective defense to
several attacks that have surfaced since it has been created. It
has met its modest goals admirably.</t>
<t>Consequently,
<t indent="3">Consequently, because it is a modest security system, it has
modest requirements on the hash function(s) it employs. It does
not rely on a hash function being collision-free, collision-free; it relies on a
hash function being one-way. If a forger, Frank, wishes to send
Alice a (digitally) unsigned message that says, "I've always
secretly loved you, signed Bob", it is far easier for him to
construct a new message than it is to modify anything intercepted
from Bob. (Note also that if Bob wishes to communicate secretly
with Alice, but without authentication or identification and with
a threat model that includes forgers, he has a problem that
transcends mere cryptography.)</t>
<t>Note
<t indent="3">Note also that unlike nearly every other OpenPGP subsystem, 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 intentional
choice to avoid downgrade and cross-grade attacks while making a
simple, fast system. (A downgrade attack would be is an attack that
replaced would
replace SHA2-256 with SHA-1, for example. A cross-grade attack
would replace SHA-1 with another 160-bit hash, such as
RIPEMD-160, for example.)</t>
<t>However,
<t indent="3">However, no update will be needed because the MDC has been replaced
by the AEAD encryption described in this document.</t>
</li></ul>
</section>
<section anchor="version-two-seipd"><name>Version anchor="version-two-seipd">
<name>Version 2 Symmetrically Encrypted Integrity Protected Data Packet Format</name>
<t>A version 2 Symmetrically Encrypted Integrity Protected Data packet consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A one-octet version number with value 2.</t>
</li>
<li>
<t>A one-octet cipher algorithm ID.</t>
</li>
<li>
<t>A one-octet AEAD algorithm identifier.</t>
</li>
<li>
<t>A one-octet chunk size.</t>
<t>Thirty-two
</li>
<li>
<t>32 octets of salt.
The salt is used to derive the message key and <bcp14>MUST</bcp14> be securely generated (See (see <xref target="CSPRNG"/>).</t>
</li>
<li>
<t>Encrypted data, data; that is, the output of the selected symmetric-key cipher operating in the given AEAD mode.</t>
</li>
<li>
<t>A final, final summary authentication tag for the AEAD mode.</t>
</list></t>
</li>
</ul>
<t>The decrypted session key and the salt are used to derive an M-bit message key and N-64 bits used as the initialization vector, where M is the key size of the symmetric algorithm and N is the nonce size of the AEAD algorithm. M + N - 64 bits are derived using HKDF (see <xref target="RFC5869"/>). The left-most leftmost M bits are used as a symmetric algorithm key, and the remaining N - 64 bits are used as an initialization vector.
<!-- [rfced] We are having trouble reading this list of items clearly -
is "HKDF" used with all of these items? If so, may we add
semicolons and include articles for clarity as shown below?
Original:
HKDF is used with SHA256 (<xref target="RFC6234"/>) ([RFC6234]) as hash algorithm, the session
key as Initial Keying Material (IKM), the salt as salt, and the
Packet Type ID in OpenPGP format encoding (bits 7 and 6 set, bits 5-0
carry the packet type ID), version number, cipher algorithm ID, AEAD
algorithm ID, and chunk size octet as info parameter.
Perhaps:
HKDF is used with SHA256 [RFC6234] as a hash algorithm; the session
key as IKM; the salt as salt; the Packet Type ID in OpenPGP format
encoding (bits 7 and 6 are set, and bits 5-0 carry the packet type
ID); the version number; the cipher algorithm ID; the AEAD
algorithm ID; and the chunk size octet as the info parameter.
-->
HKDF is used with SHA256 <xref target="RFC6234"/> as hash algorithm, the session key as IKM, the salt as salt, and the Packet Type ID in OpenPGP format encoding (bits 7 and 6 are set, and bits 5-0 carry the packet type ID), version number, cipher algorithm ID, AEAD algorithm ID, and chunk size octet as info parameter.</t>
<t>The KDF mechanism provides key separation between cipher and AEAD algorithms.
Furthermore, an implementation can securely reply to a message even if a recipient's certificate is unknown by reusing the encrypted session key packets and replying with a different salt yielding that yields a new, unique message key.
See <xref target="secure-sessionkey-reuse"/> for guidance on how applications can securely implement this feature.</t>
<t>A v2 SEIPD packet consists of one or more chunks of data. The plaintext of each chunk is of a size specified using by the chunk size octet using the method specified below.</t>
<t>The encrypted data consists of the encryption of each chunk of plaintext, followed immediately by the relevant authentication tag. If the last chunk of plaintext is smaller than the chunk size, the ciphertext for that data may be shorter; nevertheless, it is nevertheless followed by a full authentication tag.</t>
<t>For each chunk, the AEAD construction is given the Packet Type ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 carry the packet type ID), version number, cipher algorithm ID, AEAD algorithm ID, and chunk size octet as additional data.
For example, the additional data of the first chunk using EAX and AES-128 with a chunk size of 2**22 octets consists of the octets 0xD2, 0x02, 0x07, 0x01, and 0x10.</t>
<t>After the final chunk, the AEAD algorithm is used to produce a final authentication tag encrypting the empty string.
This AEAD instance is given the additional data specified above, plus an eight-octet, big-endian value specifying the total number of plaintext octets encrypted. This allows detection of a truncated ciphertext.</t>
<t>The chunk size octet specifies the size of chunks using the following formula (in (see <xref target="C99"/>), where c is the chunk size octet:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
chunk_size = (uint32_t) 1 << (c + 6)
]]></artwork></figure>
]]></artwork>
<t>An implementation <bcp14>MUST</bcp14> accept chunk size octets with values from 0 to 16.
An implementation <bcp14>MUST NOT</bcp14> create data with a chunk size octet value larger than 16 (4 MiB chunks).</t>
<t>The nonce for AEAD mode consists of two parts.
Let N be the size of the nonce.
The left-most leftmost N - 64 bits are the initialization vector derived using HKDF.
The right-most rightmost 64 bits are the chunk index as a big-endian value.
The index of the first chunk is zero.</t>
</section>
<section anchor="aead-mode-eax"><name>EAX anchor="aead-mode-eax">
<name>EAX Mode</name>
<t>The EAX AEAD Algorithm algorithm used in this document is defined in <xref target="EAX"/>.</t>
<t>The EAX algorithm can only use block ciphers with 16-octet blocks.
The nonce is 16 octets long.
EAX authentication tags are 16 octets long.</t>
</section>
<section anchor="aead-mode-ocb"><name>OCB anchor="aead-mode-ocb">
<name>OCB Mode</name>
<t>The OCB AEAD Algorithm algorithm used in this document is defined in <xref target="RFC7253"/>.</t>
<t>The OCB algorithm can only use block ciphers with 16-octet blocks.
The nonce is 15 octets long.
OCB authentication tags are 16 octets long.</t>
</section>
<section anchor="aead-mode-gcm"><name>GCM anchor="aead-mode-gcm">
<name>GCM Mode</name>
<t>The GCM AEAD Algorithm algorithm used in this document is defined in <xref target="SP800-38D"/>.</t>
<t>The GCM algorithm can only use block ciphers with 16-octet blocks.
The nonce is 12 octets long.
GCM authentication tags are 16 octets long.</t>
</section>
</section>
<section anchor="padding-packet"><name>Padding anchor="padding-packet">
<name>Padding Packet (Type ID 21)</name>
<t>The Padding packet contains random data, data and can be used to defend against traffic analysis (see <xref target="traffic-analysis"/>) on version 2 SEIPD messages (see <xref target="version-two-seipd"/>) and Transferable Public Keys (see <xref target="transferable-public-keys"/>).</t>
<t>Such a packet <bcp14>MUST</bcp14> be ignored when received.</t>
<t>Its contents <bcp14>SHOULD</bcp14> be random octets to make the length obfuscation it provides more robust even when compressed.</t>
<t>An implementation adding padding to an OpenPGP stream <bcp14>SHOULD</bcp14> place such a packet:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>At the end of a v6 Transferable Public Key that is transferred over an encrypted channel (see <xref target="transferable-public-keys"/>).</t>
</li>
<li>
<t>As the last packet of an Optionally Padded Message within a version 2 Symmetrically Encrypted Integrity Protected Data packet (see <xref target="unwrapping"/>).</t>
</list></t>
</li>
</ul>
<t>An implementation <bcp14>MUST</bcp14> be able to process padding packets anywhere else in an OpenPGP stream, stream so that future revisions of this document may specify further locations for padding.</t>
<t>Policy about how large to make such a packet to defend against traffic analysis is beyond the scope of this document.</t>
</section>
</section>
<section anchor="base64"><name>Base64 anchor="base64">
<name>Base64 Conversions</name>
<t>As stated in the introduction, OpenPGP's underlying native representation for objects is a stream of arbitrary octets, and some systems desire these objects to be immune to damage caused by character set translation, data conversions, etc.</t>
<t>In principle, any printable encoding scheme that met the requirements of the unsafe channel would suffice, since it would not change the underlying binary bit streams of the native OpenPGP data structures.
The OpenPGP standard specification specifies one such printable encoding scheme to ensure interoperability, interoperability; see <xref target="forming-ascii-armor"/>.</t>
<t>The encoding is composed of two parts: a base64 encoding of the binary data and an optional checksum.
The base64 encoding used is described in <xref section="4" sectionFormat="of" target="RFC4648"/>, and it is wrapped into lines of no more than 76 characters each.</t>
<t>When decoding base64, an OpenPGP implementation <bcp14>MUST</bcp14> ignore all white space.</t> whitespace.</t>
<section anchor="optional-crc24"><name>Optional checksum</name> anchor="optional-crc24">
<name>Optional Checksum</name>
<t>The optional checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to four characters of base64 encoding by the same MIME base64 transformation, preceded by an equal sign (=). The CRC is computed by using the generator 0x864CFB and an initialization of 0xB704CE. The accumulation is done on the data before it is converted to base64, base64 rather than on the converted data. A sample implementation of this algorithm is in <xref target="sample-crc24"/>.</t>
<t>If present, the checksum with its leading equal sign <bcp14>MUST</bcp14> appear on the next line after the base64 encoded base64-encoded data.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> reject an OpenPGP object when the CRC24 footer is present, missing, malformed, or disagrees with the computed CRC24 sum. When forming ASCII Armor, the CRC24 footer <bcp14>SHOULD NOT</bcp14> be generated, unless interoperability with implementations that require the CRC24 footer to be present is a concern.</t>
<t>The CRC24 footer <bcp14>MUST NOT</bcp14> be generated if it can be determined by the context or by the OpenPGP object being encoded that the consuming implementation accepts base64 encoded base64-encoded blocks without a CRC24 footer. Notably:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>An ASCII-armored Encrypted Message packet sequence that ends in an a v2 SEIPD packet <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t>
</li>
<li>
<t>An ASCII-armored sequence of Signature packets that only includes v6 Signature packets <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t>
</li>
<li>
<t>An ASCII-armored Transferable Public Key packet sequence of a v6 key <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t>
</li>
<li>
<t>An ASCII-armored keyring consisting of only v6 keys <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t>
</list></t>
</li>
</ul>
<t>Rationale:
Previous draft versions of this document state stated that the CRC24 footer is optional, but the text was ambiguous. In practice, very few implementations require the CRC24 footer to be present. Computing the CRC24 incurs a significant cost, while providing no meaningful integrity protection.
Therefore, generating it is now discouraged.</t>
<section anchor="sample-crc24"><name>An anchor="sample-crc24">
<name>An Implementation of the CRC-24 CRC24 in "C"</name>
<t>The following code is written in <xref target="C99"/>.</t>
<figure><sourcecode
<sourcecode type="text/x-csrc" name="sample-crc24.c"><![CDATA[
#define CRC24_INIT 0xB704CEL
#define CRC24_GENERATOR 0x864CFBL
typedef unsigned long crc24;
crc24 crc_octets(unsigned char *octets, size_t len)
{
crc24 crc = CRC24_INIT;
int i;
while (len--) {
crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) {
crc <<= 1;
if (crc & 0x1000000) {
crc &= 0XFFFFFF; /* Clear bit 25 to avoid overflow */
crc ^= CRC24_GENERATOR;
}
}
}
return crc & 0xFFFFFFL;
}
]]></sourcecode></figure>
]]></sourcecode>
</section>
</section>
<section anchor="forming-ascii-armor"><name>Forming anchor="forming-ascii-armor">
<name>Forming ASCII Armor</name>
<t>When OpenPGP encodes data into ASCII Armor, it puts specific headers around the base64 encoded base64-encoded data, so OpenPGP can reconstruct the data later.
An OpenPGP implementation <bcp14>MAY</bcp14> use ASCII armor to protect raw binary data.
OpenPGP informs the user what kind of data is encoded in the ASCII armor through the use of the headers.</t>
<t>Concatenating the following data creates ASCII Armor:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>An Armor Header Line, appropriate for the type of data</t>
</li>
<li>
<t>Armor Headers</t>
</li>
<li>
<t>A blank (zero-length, (zero length or containing only whitespace) line</t>
</li>
<li>
<t>The ASCII-Armored data</t>
</li>
<li>
<t>An optional Armor Checksum (discouraged, (discouraged; see <xref target="optional-crc24"/>)</t>
</li>
<li>
<t>The Armor Tail, which depends on the Armor Header Line</t>
</list></t>
</li>
</ul>
<section anchor="armor-header-line"><name>Armor anchor="armor-header-line">
<name>Armor Header Line</name>
<t>An Armor Header Line consists of the appropriate header line text surrounded by five (5) dashes (<spanx style="verb">-</spanx>, (<tt>-</tt>, 0x2D) on either side of the header line text. The header line text is chosen based upon on the type of data that is being encoded in Armor, Armor and how it is being encoded.
Header line texts include the following strings:</t>
<texttable title="OpenPGP
<table anchor="armor-header-line-registry">
<name>OpenPGP Armor Header Line registry" anchor="armor-header-line-registry">
<ttcol align='left'>Armor Header</ttcol>
<ttcol align='left'>Use</ttcol>
<c><spanx style="verb">BEGIN Registry</name>
<thead>
<tr>
<th align="left">Armor Header</th>
<th align="left">Use</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">
<tt>BEGIN PGP MESSAGE</spanx></c>
<c>Used MESSAGE</tt></td>
<td align="left">Used for signed, encrypted, or compressed files.</c>
<c><spanx style="verb">BEGIN files.</td>
</tr>
<tr>
<td align="left">
<tt>BEGIN PGP PUBLIC KEY BLOCK</spanx></c>
<c>Used BLOCK</tt></td>
<td align="left">Used for armoring public keys.</c>
<c><spanx style="verb">BEGIN keys.</td>
</tr>
<tr>
<td align="left">
<tt>BEGIN PGP PRIVATE KEY BLOCK</spanx></c>
<c>Used BLOCK</tt></td>
<td align="left">Used for armoring private keys.</c>
<c><spanx style="verb">BEGIN keys.</td>
</tr>
<tr>
<td align="left">
<tt>BEGIN PGP SIGNATURE</spanx></c>
<c>Used SIGNATURE</tt></td>
<td align="left">Used for detached signatures, OpenPGP/MIME signatures, and cleartext signatures.</c>
</texttable> signatures.</td>
</tr>
</tbody>
</table>
<t>Note that all of these Armor Header Lines are to consist of a complete line.
The
Therefore, the header lines, therefore, lines <bcp14>MUST</bcp14> start at the beginning of a line, line and <bcp14>MUST NOT</bcp14> have text other than whitespace following them on the same line.</t>
</section>
<section anchor="armor-headers"><name>Armor anchor="armor-headers">
<name>Armor Headers</name>
<t>The Armor Headers are pairs of strings that can give the user or the receiving OpenPGP implementation some information about how to decode 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 applied to the message.</t>
<t>The format of an Armor Header is that of a key-value pair. A colon (<spanx style="verb">:</spanx> (<tt>:</tt> 0x3A) and a single space (0x20) separate the key and value.
An OpenPGP implementation may consider improperly formatted Armor Headers to be a corruption of the ASCII Armor, but it <bcp14>SHOULD</bcp14> make an effort to recover. Unknown keys should be silently ignored, and an OpenPGP implementation <bcp14>SHOULD</bcp14> continue to process the message.</t>
<t>Note that some transport methods are sensitive to line length.
For example, the SMTP protocol that transports email messages has a line length limit of 998 characters (see <xref section="2.1.1" sectionFormat="of" target="RFC5322"/>).</t>
<t>While there is a limit of 76 characters for the base64 data (<xref target="base64"/>), there is no limit to for the length of Armor Headers.
Care should be taken to ensure that the Armor Headers are short enough to 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 is overly long.</t>
<t>Currently defined Armor Header Keys are as follows:</t>
<texttable title="OpenPGP
<table anchor="armor-header-key-registry">
<name>OpenPGP Armor Header Key registry" anchor="armor-header-key-registry">
<ttcol align='left'>Key</ttcol>
<ttcol align='left'>Summary</ttcol>
<ttcol align='left'>Reference</ttcol>
<c><spanx style="verb">Version</spanx></c>
<c>Implementation information</c>
<c><xref target="armor-header-key-version"/></c>
<c><spanx style="verb">Comment</spanx></c>
<c>Arbitrary text</c>
<c><xref target="armor-header-key-comment"/></c>
<c><spanx style="verb">Hash</spanx></c>
<c>Hash Registry</name>
<thead>
<tr>
<th align="left">Key</th>
<th align="left">Summary</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">
<tt>Version</tt></td>
<td align="left">Implementation information</td>
<td align="left">
<xref target="armor-header-key-version"/></td>
</tr>
<tr>
<td align="left">
<tt>Comment</tt></td>
<td align="left">Arbitrary text</td>
<td align="left">
<xref target="armor-header-key-comment"/></td>
</tr>
<tr>
<td align="left">
<tt>Hash</tt></td>
<td align="left">Hash algorithms used in some v4 cleartext signed messages</c>
<c><xref target="armor-header-key-hash"/></c>
<c><spanx style="verb">Charset</spanx></c>
<c>Character set</c>
<c><xref target="armor-header-key-charset"/></c>
</texttable> messages</td>
<td align="left">
<xref target="armor-header-key-hash"/></td>
</tr>
<tr>
<td align="left">
<tt>Charset</tt></td>
<td align="left">Character set</td>
<td align="left">
<xref target="armor-header-key-charset"/></td>
</tr>
</tbody>
</table>
<section anchor="armor-header-key-version"><name>"Version" anchor="armor-header-key-version">
<name>"Version" Armor Header</name>
<t>The armor header key <spanx style="verb">Version</spanx> <tt>Version</tt> describes the OpenPGP implementation and version used to encode the message.
To minimize metadata, implementations <bcp14>SHOULD NOT</bcp14> emit this key and its corresponding value except for debugging purposes with explicit user consent.</t>
</section>
<section anchor="armor-header-key-comment"><name>"Comment" anchor="armor-header-key-comment">
<name>"Comment" Armor Header</name>
<t>The armor header key <spanx style="verb">Comment</spanx> <tt>Comment</tt> supplies a user-defined comment.
OpenPGP defines all text to be in UTF-8. A comment may be any UTF-8 string. However, the whole point of armoring is to provide seven-bit-clean seven-bit clean data.
<!-- [rfced] The RFC Production Center has been advised that
"ASCII" and not "US-ASCII" should be used. May we change one
instance of "US-ASCII" in this document to "ASCII"?
Original:
Consequently, if a comment has characters that are outside
the US-ASCII range of UTF, they may very well not survive
transport.
Perhaps:
Consequently, if a comment has characters that are outside
the ASCII range of UTF, they may very well not survive
transport.
-->
Consequently, if a comment has characters that are outside the US-ASCII range of UTF, they may very well not survive transport.</t>
</section>
<section anchor="armor-header-key-hash"><name>"Hash" anchor="armor-header-key-hash">
<name>"Hash" Armor Header</name>
<t>This
<t>The armor header key <tt>Hash</tt> is deprecated, but some older implementations expect it in messages using the Cleartext Signature Framework (<xref target="cleartext-signature"/>). When present, The this armor header key <spanx style="verb">Hash</spanx> contains a comma-separated list of hash algorithms used in the signatures on message, with digest names as specified in the "Text Name" column in <xref target="hash-algorithms-registry"/>.
These headers <bcp14>SHOULD NOT</bcp14> be emitted unless:</t>
<t><list style="symbols">
<t>The
<ul spacing="normal">
<li>
<t>the cleartext signed message contains a v4 signature made using a SHA2-based digest (<spanx style="verb">SHA224</spanx>, <spanx style="verb">SHA256</spanx>, <spanx style="verb">SHA384</spanx>, (<tt>SHA224</tt>, <tt>SHA256</tt>, <tt>SHA384</tt>, or <spanx style="verb">SHA512</spanx>), <tt>SHA512</tt>), and</t>
<t>The
</li>
<li>
<t>the cleartext signed message might be verified by a legacy OpenPGP implementation that requires this header.</t>
</list></t>
</li>
</ul>
<t>A verifying application <bcp14>MUST</bcp14> decline to validate any signature in a message with a non-conformant <spanx style="verb">Hash</spanx> <tt>Hash</tt> header (that is, a <spanx style="verb">Hash</spanx> <tt>Hash</tt> header that contains anything other than a comma-separated list of hash algorithms).
When a conformant <spanx style="verb">Hash</spanx> <tt>Hash</tt> header is present, a verifying application <bcp14>MUST</bcp14> ignore its contents, deferring to the hash algorithm indicated in the embedded signature.</t>
</section>
<section anchor="armor-header-key-charset"><name>"Charset" anchor="armor-header-key-charset">
<name>"Charset" Armor Header</name>
<t>The armor header key <spanx style="verb">Charset</spanx> <tt>Charset</tt> contains a description of the character set that the plaintext is in (see <xref target="RFC2978"/>).
Please note that OpenPGP defines text to be in UTF-8.
An implementation will get the best results by translating into and out of UTF-8.
However, there are many instances where this is easier 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 like ISO Latin-5 or a Japanese character set.
In such instances, an implementation <bcp14>MAY</bcp14> override the UTF-8 default by using this header key.
An implementation <bcp14>MAY</bcp14> implement this key and any translations it cares to; an implementation <bcp14>MAY</bcp14> ignore it and assume all text is UTF-8.</t>
</section>
</section>
<section anchor="armor-tail-line"><name>Armor anchor="armor-tail-line">
<name>Armor Tail Line</name>
<t>The Armor Tail Line is composed in the same manner as the Armor Header Line, except the string "BEGIN" is replaced by the string "END".</t>
</section>
</section>
</section>
<section anchor="cleartext-signature"><name>Cleartext anchor="cleartext-signature">
<name>Cleartext Signature Framework</name>
<t>It is desirable to be able to sign a textual octet stream without ASCII armoring the stream itself, so the signed text is still readable with any tool capable of rendering text.
In order to bind a signature to such a cleartext, this framework the Cleartext Signature Framework is used, which follows the same basic format and restrictions as the ASCII armoring described in <xref target="forming-ascii-armor"/>.
(Note that this framework is not intended to be reversible.
<xref target="RFC3156"/> defines another way to sign cleartext messages for environments that support MIME.)</t>
<section anchor="cleartext-structure"><name>Cleartext anchor="cleartext-structure">
<name>Cleartext Signed Message Structure</name>
<t>An OpenPGP cleartext signed message consists of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>The cleartext header <spanx style="verb">-----BEGIN <tt>-----BEGIN PGP SIGNED MESSAGE-----</spanx> MESSAGE-----</tt> on a single line,</t>
<t>Some implementations <bcp14>MAY</bcp14> include one line.</t>
</li>
<li>
<t>One or more legacy <spanx style="verb">Hash</spanx> <tt>Hash</tt> Armor Headers, which Headers that <bcp14>MAY</bcp14> be included by some implementations and <bcp14>MUST</bcp14> be ignored when well-formed well formed (see <xref target="armor-header-key-hash"/>),</t> target="armor-header-key-hash"/>).</t>
</li>
<li>
<t>An empty line (not included into in the message digest),</t> digest).</t>
</li>
<li>
<t>The dash-escaped cleartext,</t> cleartext.</t>
</li>
<li>
<t>A line ending separating the cleartext and following armored signature (not included into in the message digest),</t> digest).</t>
</li>
<li>
<t>The ASCII armored signature(s) ASCII-armored signature(s), including the <spanx style="verb">-----BEGIN <tt>-----BEGIN PGP SIGNATURE-----</spanx> SIGNATURE-----</tt> Armor Header and Armor Tail Lines.</t>
</list></t>
</li>
</ul>
<t>As with any other text signature (<xref target="sigtype-text"/>), a cleartext signature is calculated on the text using canonical <CR><LF> line endings.
As described above, the line ending before the <spanx style="verb">-----BEGIN <tt>-----BEGIN PGP SIGNATURE-----</spanx> SIGNATURE-----</tt> Armor Header Line of the armored signature is not considered part of the signed text.</t>
<t>Also, any trailing whitespace --- -- spaces (0x20) and tabs (0x09) --- -- at the end of any line is removed before signing or verifying a cleartext signed message.</t>
<t>Between the <spanx style="verb">-----BEGIN <tt>-----BEGIN PGP SIGNED MESSAGE-----</spanx> MESSAGE-----</tt> line and the first empty line, the only Armor Header permitted is a well-formed <spanx style="verb">Hash</spanx> <tt>Hash</tt> Armor Header (see <xref target="armor-header-key-hash"/>).
To reduce the risk of confusion about what has been signed, a verifying implementation <bcp14>MUST</bcp14> decline to validate any signature in a cleartext message if that message has any other Armor Header present in this location.</t>
</section>
<section anchor="dash-escaping"><name>Dash-Escaped anchor="dash-escaping">
<name>Dash-Escaped Text</name>
<t>The cleartext content of the message must also be dash-escaped.</t>
<t>Dash-escaped cleartext is the ordinary cleartext where every line starting with a <u>-</u> is prefixed by the sequence <u>-</u> and <u> </u>.
This prevents the parser from recognizing armor headers of the cleartext itself.
An implementation <bcp14>MAY</bcp14> dash-escape any line, <bcp14>SHOULD</bcp14> dash-escape lines commencing in "From" followed by a space, and <bcp14>MUST</bcp14> dash-escape any line commencing in a dash. The message digest is computed using the cleartext itself, not the dash-escaped form.</t>
<t>When reversing dash-escaping, an implementation <bcp14>MUST</bcp14> strip the string <spanx style="verb">- </spanx> <tt>-</tt> if it occurs at the beginning of a line, and it <bcp14>SHOULD</bcp14> warn on <spanx style="verb">-</spanx> provide a warning for <tt>-</tt> and any character other than a space at the beginning of a line.</t>
</section>
<section anchor="csf-issues"><name>Issues anchor="csf-issues">
<name>Issues with the Cleartext Signature Framework</name>
<t>Since creating a cleartext signed message involves trimming trailing whitespace on every line, the Cleartext Signature Framework will fail to safely round-trip any textual stream that may include semantically meaningful whitespace.</t>
<t>For example, the Unified Diff format <xref target="UNIFIED-DIFF"/> contains semantically meaningful whitespace: an empty line of context will consist of a line with a single <u> </u> character, and any line that has trailing whitespace added or removed will represent such a change with semantically meaningful whitespace.</t>
<t>Furthermore, a Cleartext Signature Framework message that is very large is unlikely to work well.
In particular, it will be difficult for any human reading the message to know which part of the message is covered by the signature because they can't understand the whole message at once, especially in the case where an Armor Header line is placed somewhere in the body.
And, very large Cleartext Signature Framework messages cannot be processed in a single pass, since the signature salt and digest algorithms are only discovered at the end.</t>
<t>An implementation that knows it is working with a textual stream with any of the above characteristics <bcp14>SHOULD NOT</bcp14> use the Cleartext Signature Framework.
Safe alternatives for a semantically meaningful OpenPGP signature over such a file format are:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A Signed Message, as described in <xref target="openpgp-messages"/>.</t>
</li>
<li>
<t>A Detached Signature detached signature, as described in <xref target="detached-signatures"/>.</t>
</list></t>
</li>
</ul>
<t>Either of these alternatives may be ASCII-armored (see <xref target="forming-ascii-armor"/>) if they need to be transmitted across a text-only (or 7-bit clean) channel.</t>
<t>Finally, when a Cleartext Signature Framework message is presented to the user as-is, as is, an attacker can include additional text in the <spanx style="verb">Hash</spanx> <tt>Hash</tt> header, which may mislead the user into thinking it is part of the signed text.
The signature validation constraints described in Sections <xref target="armor-header-key-hash"/> target="armor-header-key-hash" format="counter"/> and <xref target="cleartext-structure"/> target="cleartext-structure" format="counter"/> help to mitigate the risk of arbitrary or misleading text in the Armor Headers.</t>
</section>
</section>
<section anchor="regular-expressions"><name>Regular anchor="regular-expressions">
<name>Regular Expressions</name>
<t>A regular expression is zero or more branches, separated by <spanx style="verb">|</spanx>.
It matches anything that matches one
<!-- [rfced] Section 8: Formatting and Articles
a) Should the paragraphs in Section 8 be formatted as definition lists
for easier readability, or do you prefer the current format?
Example
Original:
A regular expression is zero or more branches, separated by |. It
matches anything that matches one of the branches.
A branch is zero or more pieces, concatenated. It matches a match
for the first, followed by a match for the second, etc.
Perhaps:
This section defines regular expressions.
Regular expression: Zero or more branches, separated by |. It
matches anything that matches one of the branches.
Branch: Zero or more pieces, concatenated. It matches a match
for the first, followed by a match for the second, etc.
b) May we make the following list of items parallel by adding
"a" before ".", "^", and "$"?
Original:
An atom is a regular expression in parentheses (matching a match for
the regular expression), a range (see below), . (matching any
single Unicode character), ^ (matching the null string at the
beginning of the input string), $ (matching the null string at the
end of the input string), a \ followed by a single Unicode character
(matching that character), or a single Unicode character with no
other significance (matching that character).
Perhaps:
An atom is a regular expression in parentheses (matching a match for
the regular expression), a range (see below), a . (matching any
single Unicode character), a ^ (matching the null string at the
beginning of the input string), a $ (matching the null string at the
end of the input string), a \ followed by a single Unicode character
(matching that character), or a single Unicode character with no
other significance (matching that character).
-->
<t>A regular expression is zero or more branches, separated by <tt>|</tt>.
It matches anything that matches one of the branches.</t>
<t>A branch is zero or more pieces, concatenated.
It matches a match for the first, followed by a match for the second, etc.</t>
<t>A piece is an atom possibly followed by <spanx style="verb">*</spanx>, <spanx style="verb">+</spanx>, <tt>*</tt>, <tt>+</tt>, or <spanx style="verb">?</spanx>. <tt>?</tt>.
An atom followed by <spanx style="verb">*</spanx> <tt>*</tt> matches a sequence of 0 or more matches of the atom.
An atom followed by <spanx style="verb">+</spanx> <tt>+</tt> matches a sequence of 1 or more matches of the atom.
An atom followed by <spanx style="verb">?</spanx> <tt>?</tt> matches a match of the atom, atom or the null string.</t>
<t>An atom is a regular expression in parentheses (matching a match for the regular expression), a range (see below), <spanx style="verb">.</spanx> <tt>.</tt> (matching any single Unicode character), <spanx style="verb">^</spanx> <tt>^</tt> (matching the null string at the beginning of the input string), <spanx style="verb">$</spanx> <tt>$</tt> (matching the null string at the end of the input string), a <spanx style="verb">\</spanx> <tt>\</tt> followed by a single Unicode character (matching that character), or a single Unicode character with no other significance (matching that character).</t>
<t>A range is a sequence of characters enclosed in <spanx style="verb">[]</spanx>. <tt>[]</tt>.
It normally matches any single character from the sequence.
If the sequence begins with <spanx style="verb">^</spanx>, <tt>^</tt>, it matches any single Unicode character not from the rest of the sequence. If two characters in the sequence are separated by <spanx style="verb">-</spanx>, <tt>-</tt>, this is shorthand for the full list of Unicode characters between them in codepoint order (for example, <spanx style="verb">[0-9]</spanx> <tt>[0-9]</tt> matches any decimal digit). To include a literal <spanx style="verb">]</spanx> <tt>]</tt> in the sequence, make it the first character (following a possible <spanx style="verb">^</spanx>). <tt>^</tt>). To include a literal <spanx style="verb">-</spanx>, <tt>-</tt>, make it the first or last character.</t>
</section>
<section anchor="constants"><name>Constants</name> anchor="constants">
<name>Constants</name>
<t>This section describes the constants used in OpenPGP.</t>
<t>Note that these tables are not exhaustive lists; an implementation <bcp14>MAY</bcp14> implement an algorithm that is not on these lists, so as long as the algorithm IDs are chosen from the private Private or experimental Experimental Use algorithm range.</t>
<t>See <xref target="notes-on-algorithms"/> for more discussion of the algorithms.</t>
<section anchor="pubkey-algos"><name>Public-Key anchor="pubkey-algos">
<name>Public-Key Algorithms</name>
<texttable title="OpenPGP
<table anchor="pubkey-algo-registry">
<name>OpenPGP Public Key Algorithms registry" anchor="pubkey-algo-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Algorithm</ttcol>
<ttcol align='left'>Public Key Format</ttcol>
<ttcol align='left'>Secret Key Format</ttcol>
<ttcol align='left'>Signature Format</ttcol>
<ttcol align='left'>PKESK Format</ttcol>
<c>0</c>
<c>Reserved</c>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
<c>1</c>
<c>RSA Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Algorithm</th>
<th align="left">Public Key Format</th>
<th align="left">Secret Key Format</th>
<th align="left">Signature Format</th>
<th align="left">PKESK Format</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">0</td>
<td align="left">Reserved</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">1</td>
<td align="left">RSA (Encrypt or Sign) <xref target="FIPS186"/></c>
<c>MPI(n), target="FIPS186"/></td>
<td align="left">MPI(n), MPI(e) [<xref target="key-rsa"/>]</c>
<c>MPI(d), target="key-rsa"/>]</td>
<td align="left">MPI(d), MPI(p), MPI(q), MPI(u)</c>
<c>MPI(m**d MPI(u)</td>
<td align="left">MPI(m**d mod n) [<xref target="sig-rsa"/>]</c>
<c>MPI(m**e target="sig-rsa"/>]</td>
<td align="left">MPI(m**e mod n) [<xref target="pkesk-rsa"/>]</c>
<c>2</c>
<c>RSA target="pkesk-rsa"/>]</td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">RSA Encrypt-Only <xref target="FIPS186"/></c>
<c>MPI(n), target="FIPS186"/></td>
<td align="left">MPI(n), MPI(e) [<xref target="key-rsa"/>]</c>
<c>MPI(d), target="key-rsa"/>]</td>
<td align="left">MPI(d), MPI(p), MPI(q), MPI(u)</c>
<c>N/A</c>
<c>MPI(m**e MPI(u)</td>
<td align="left">N/A</td>
<td align="left">MPI(m**e mod n) [<xref target="pkesk-rsa"/>]</c>
<c>3</c>
<c>RSA target="pkesk-rsa"/>]</td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">RSA Sign-Only <xref target="FIPS186"/></c>
<c>MPI(n), target="FIPS186"/></td>
<td align="left">MPI(n), MPI(e) [<xref target="key-rsa"/>]</c>
<c>MPI(d), target="key-rsa"/>]</td>
<td align="left">MPI(d), MPI(p), MPI(q), MPI(u)</c>
<c>MPI(m**d MPI(u)</td>
<td align="left">MPI(m**d mod n) [<xref target="sig-rsa"/>]</c>
<c>N/A</c>
<c>16</c>
<c>Elgamal target="sig-rsa"/>]</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="right">16</td>
<td align="left">Elgamal (Encrypt-Only) <xref target="ELGAMAL"/></c>
<c>MPI(p), target="ELGAMAL"/></td>
<td align="left">MPI(p), MPI(g), MPI(y) [<xref target="key-elgamal"/>]</c>
<c>MPI(x)</c>
<c>N/A</c>
<c>MPI(g**k target="key-elgamal"/>]</td>
<td align="left">MPI(x)</td>
<td align="left">N/A</td>
<td align="left">MPI(g**k mod p), MPI (m MPI(m * y**k mod p) [<xref target="pkesk-elgamal"/>]</c>
<c>17</c>
<c>DSA target="pkesk-elgamal"/>]</td>
</tr>
<tr>
<td align="right">17</td>
<td align="left">DSA (Digital Signature Algorithm) <xref target="FIPS186"/></c>
<c>MPI(p), target="FIPS186"/></td>
<td align="left">MPI(p), MPI(q), MPI(g), MPI(y) [<xref target="key-dsa"/>]</c>
<c>MPI(x)</c>
<c>MPI(r), target="key-dsa"/>]</td>
<td align="left">MPI(x)</td>
<td align="left">MPI(r), MPI(s) [<xref target="sig-dsa"/>]</c>
<c>N/A</c>
<c>18</c>
<c>ECDH target="sig-dsa"/>]</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="right">18</td>
<td align="left">ECDH public key algorithm</c>
<c>OID, algorithm</td>
<td align="left">OID, MPI(point in curve-specific point format), KDFParams [see [Sections <xref target="curve-specific-formats"/>, target="curve-specific-formats" format="counter"/> and <xref target="key-ecdh"/>]</c>
<c>MPI(value target="key-ecdh" format="counter"/>]</td>
<td align="left">MPI(value in curve-specific format) [<xref target="curve-specific-formats"/>]</c>
<c>N/A</c>
<c>MPI(point target="curve-specific-formats"/>]</td>
<td align="left">N/A</td>
<td align="left">MPI(point in curve-specific point format), size octet, encoded key [<xref target="curve-specific-formats"/>, [Sections <xref target="curve-specific-formats" format="counter"/>, <xref target="pkesk-ecdh"/>, target="pkesk-ecdh" format="counter"/>, and <xref target="ecdh"/>]</c>
<c>19</c>
<c>ECDSA target="ecdh" format="counter"/>]</td>
</tr>
<tr>
<td align="right">19</td>
<td align="left">ECDSA public key algorithm <xref target="FIPS186"/></c>
<c>OID, target="FIPS186"/></td>
<td align="left">OID, MPI(point in SEC1 format) [<xref target="key-ecdsa"/>]</c>
<c>MPI(value)</c>
<c>MPI(r), target="key-ecdsa"/>]</td>
<td align="left">MPI(value)</td>
<td align="left">MPI(r), MPI(s) [<xref target="sig-dsa"/>]</c>
<c>N/A</c>
<c>20</c>
<c>Reserved target="sig-dsa"/>]</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="right">20</td>
<td align="left">Reserved (formerly Elgamal Encrypt or Sign)</c>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
<c>21</c>
<c>Reserved Sign)</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">21</td>
<td align="left">Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME)</c>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
<c>22</c>
<c>EdDSALegacy (deprecated)</c>
<c>OID, IETF-S/MIME)</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">22</td>
<td align="left">EdDSALegacy (deprecated)</td>
<td align="left">OID, MPI(point in prefixed native format) [see [Sections <xref target="ec-point-prefixed-native"/>, target="ec-point-prefixed-native" format="counter"/> and <xref target="key-eddsa-legacy"/>]</c>
<c>MPI(value target="key-eddsa-legacy" format="counter"/>]</td>
<td align="left">MPI(value in curve-specific format) [see <xref target="curve-specific-formats"/>]</c>
<c>MPI, [<xref target="curve-specific-formats"/>]</td>
<td align="left">MPI, MPI [see [Sections <xref target="curve-specific-formats"/>, target="curve-specific-formats" format="counter"/> and <xref target="sig-eddsa-legacy"/>]</c>
<c>N/A</c>
<c>23</c>
<c>Reserved (AEDH)</c>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
<c>24</c>
<c>Reserved (AEDSA)</c>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
<c>25</c>
<c>X25519</c>
<c>32 octets [see <xref target="key-x25519"/>]</c>
<c>32 octets</c>
<c>N/A</c>
<c>32 target="sig-eddsa-legacy" format="counter"/>]</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="right">23</td>
<td align="left">Reserved (AEDH)</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">24</td>
<td align="left">Reserved (AEDSA)</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">25</td>
<td align="left">X25519</td>
<td align="left">32 octets [<xref target="key-x25519"/>]</td>
<td align="left">32 octets</td>
<td align="left">N/A</td>
<td align="left">32 octets, size octet, encoded key [see <xref target="pkesk-x25519"/>]</c>
<c>26</c>
<c>X448</c>
<c>56 octets [see <xref target="key-x448"/>]</c>
<c>56 octets</c>
<c>N/A</c>
<c>56 [<xref target="pkesk-x25519"/>]</td>
</tr>
<tr>
<td align="right">26</td>
<td align="left">X448</td>
<td align="left">56 octets [<xref target="key-x448"/>]</td>
<td align="left">56 octets</td>
<td align="left">N/A</td>
<td align="left">56 octets, size octet, encoded key [see <xref target="pkesk-x448"/>]</c>
<c>27</c>
<c>Ed25519</c>
<c>32 octets [see <xref target="key-ed25519"/>]</c>
<c>32 octets</c>
<c>64 octets [see <xref target="sig-ed25519"/>]</c>
<c> </c>
<c>28</c>
<c>Ed448</c>
<c>57 octets [see <xref target="key-ed448"/>]</c>
<c>57 octets</c>
<c>114 octets [see <xref target="sig-ed448"/>]</c>
<c> </c>
<c>100 to 110</c>
<c>Private/Experimental algorithm</c>
<c> </c>
<c> </c>
<c> </c>
<c> </c>
</texttable> [<xref target="pkesk-x448"/>]</td>
</tr>
<tr>
<td align="right">27</td>
<td align="left">Ed25519</td>
<td align="left">32 octets [<xref target="key-ed25519"/>]</td>
<td align="left">32 octets</td>
<td align="left">64 octets [<xref target="sig-ed25519"/>]</td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">28</td>
<td align="left">Ed448</td>
<td align="left">57 octets [<xref target="key-ed448"/>]</td>
<td align="left">57 octets</td>
<td align="left">114 octets [<xref target="sig-ed448"/>]</td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">100 to 110</td>
<td align="left">Private/Experimental algorithm</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
</tbody>
</table>
<t>Implementations <bcp14>MUST</bcp14> implement Ed25519 (27) for signatures, signatures and X25519 (25) for encryption.
Implementations <bcp14>SHOULD</bcp14> implement Ed448 (28) and X448 (26).</t>
<t>RSA (1) keys are deprecated and <bcp14>SHOULD NOT</bcp14> be generated, generated but may be interpreted.
RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and <bcp14>MUST NOT</bcp14> be generated.
See generated (see <xref target="rsa-notes"/>. target="rsa-notes"/>). Elgamal (16) keys are deprecated and <bcp14>MUST NOT</bcp14> be generated (see <xref target="elgamal-notes"/>). DSA (17) keys are deprecated and <bcp14>MUST NOT</bcp14> be generated (see <xref target="dsa-notes"/>).
See <xref target="reserved-notes"/> for For notes on Elgamal Encrypt or Sign (20), (20) and X9.42 (21). (21), see <xref target="reserved-notes"/>.
Implementations <bcp14>MAY</bcp14> implement any other algorithm.</t>
<t>Note that an implementation conforming to the previous version of this standard (<xref target="RFC4880"/>) specification <xref target="RFC4880"/> has only DSA (17) and Elgamal (16) as its <bcp14>MUST</bcp14>-implement algorithms.</t> the algorithms that <bcp14>MUST</bcp14> be implemented.</t>
<t>A compatible specification of ECDSA is given in <xref target="RFC6090"/> as (as "KT-I Signatures" Signatures") and in <xref target="SEC1"/>; ECDH is defined in <xref target="ecdh"/> of this document.</t>
</section>
<section anchor="ec-curves"><name>ECC anchor="ec-curves">
<name>ECC Curves for OpenPGP</name>
<t>The parameter curve OID is an array of octets that defines a named curve.</t>
<t>The table below specifies the exact sequence of octets for each named curve referenced in this document.
It also specifies which public key algorithms the curve can be used with, as well as the size of expected elements in octets:</t>
<texttable title="OpenPGP
<table anchor="ecc-oid-usage-registry">
<name>OpenPGP ECC Curve OID and Usage registry" anchor="ecc-oid-usage-registry">
<ttcol align='left'>ASN.1 Registry</name>
<thead>
<tr>
<th align="left">ASN.1 Object Identifier</ttcol>
<ttcol align='left'>OID len</ttcol>
<ttcol align='left'>Curve Identifier</th>
<th align="left">OID Len</th>
<th align="left">Curve OID octets in hex</ttcol>
<ttcol align='left'>Curve name</ttcol>
<ttcol align='left'>Usage</ttcol>
<ttcol align='left'>Field Size (fsize)</ttcol>
<c>1.2.840.10045.3.1.7</c>
<c>8</c>
<c>2A Octets</th>
<th align="left">Curve Name</th>
<th align="left">Usage (fsize)</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">1.2.840.10045.3.1.7</td>
<td align="left">8</td>
<td align="left">2A 86 48 CE 3D 03 01 07</c>
<c>NIST P-256</c>
<c>ECDSA, ECDH</c>
<c>32</c>
<c>1.3.132.0.34</c>
<c>5</c>
<c>2B 07</td>
<td align="left">NIST P-256</td>
<td align="left">ECDSA, ECDH (32)</td>
</tr>
<tr>
<td align="left">1.3.132.0.34</td>
<td align="left">5</td>
<td align="left">2B 81 04 00 22</c>
<c>NIST P-384</c>
<c>ECDSA, ECDH</c>
<c>48</c>
<c>1.3.132.0.35</c>
<c>5</c>
<c>2B 22</td>
<td align="left">NIST P-384</td>
<td align="left">ECDSA, ECDH (48)</td>
</tr>
<tr>
<td align="left">1.3.132.0.35</td>
<td align="left">5</td>
<td align="left">2B 81 04 00 23</c>
<c>NIST P-521</c>
<c>ECDSA, ECDH</c>
<c>66</c>
<c>1.3.36.3.3.2.8.1.1.7</c>
<c>9</c>
<c>2B 23</td>
<td align="left">NIST P-521</td>
<td align="left">ECDSA, ECDH (66)</td>
</tr>
<tr>
<td align="left">1.3.36.3.3.2.8.1.1.7</td>
<td align="left">9</td>
<td align="left">2B 24 03 03 02 08 01 01 07</c>
<c>brainpoolP256r1</c>
<c>ECDSA, ECDH</c>
<c>32</c>
<c>1.3.36.3.3.2.8.1.1.11</c>
<c>9</c>
<c>2B 07</td>
<td align="left">brainpoolP256r1</td>
<td align="left">ECDSA, ECDH (32)</td>
</tr>
<tr>
<td align="left">1.3.36.3.3.2.8.1.1.11</td>
<td align="left">9</td>
<td align="left">2B 24 03 03 02 08 01 01 0B</c>
<c>brainpoolP384r1</c>
<c>ECDSA, ECDH</c>
<c>48</c>
<c>1.3.36.3.3.2.8.1.1.13</c>
<c>9</c>
<c>2B 0B</td>
<td align="left">brainpoolP384r1</td>
<td align="left">ECDSA, ECDH (48)</td>
</tr>
<tr>
<td align="left">1.3.36.3.3.2.8.1.1.13</td>
<td align="left">9</td>
<td align="left">2B 24 03 03 02 08 01 01 0D</c>
<c>brainpoolP512r1</c>
<c>ECDSA, ECDH</c>
<c>64</c>
<c>1.3.6.1.4.1.11591.15.1</c>
<c>9</c>
<c>2B 0D</td>
<td align="left">brainpoolP512r1</td>
<td align="left">ECDSA, ECDH (64)</td>
</tr>
<tr>
<td align="left">1.3.6.1.4.1.11591.15.1</td>
<td align="left">9</td>
<td align="left">2B 06 01 04 01 DA 47 0F 01</c>
<c>Ed25519Legacy</c>
<c>EdDSALegacy</c>
<c>32</c>
<c>1.3.6.1.4.1.3029.1.5.1</c>
<c>10</c>
<c>2B 01</td>
<td align="left">Ed25519Legacy</td>
<td align="left">EdDSALegacy (32)</td>
</tr>
<tr>
<td align="left">1.3.6.1.4.1.3029.1.5.1</td>
<td align="left">10</td>
<td align="left">2B 06 01 04 01 97 55 01 05 01</c>
<c>Curve25519Legacy</c>
<c>ECDH</c>
<c>32</c>
</texttable> 01</td>
<td align="left">Curve25519Legacy</td>
<td align="left">ECDH (32)</td>
</tr>
</tbody>
</table>
<t>The "Field Size (fsize)" column represents the field size of the group in number of octets, rounded up, such that x or y coordinates for a point on the curve or native point representations for the curve can be represented in that many octets.
For the The curves specified here, also and scalars such as the base point order and the private key key, can be represented in fsize octets.
Note that, however, there exist However, note that curves exist outside this specification where the representation of scalars requires an additional octet.</t>
<t>The sequence of octets in the third column is the result of applying the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier with subsequent truncation. The truncation removes the two fields of encoded Object Identifier. The first omitted field is one octet representing the Object Identifier tag, and the second omitted field is the length of the Object Identifier body.
For example, the complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A 86 48 CE 3D 03 01 07", from which the first entry in the table above is constructed by omitting the first two octets.
Only the truncated sequence of octets is the valid representation of a curve OID.</t>
<t>The deprecated OIDs for Ed25519Legacy and Curve25519Legacy are used only in version 4 keys and signatures.
Implementations <bcp14>MAY</bcp14> implement these variants for compatibility with existing v4 key material and signatures.
Implementations <bcp14>MUST NOT</bcp14> accept or generate v6 key material using the deprecated OIDs.</t>
<section anchor="curve-specific-formats"><name>Curve-Specific anchor="curve-specific-formats">
<name>Curve-Specific Wire Formats</name>
<t>Some Elliptic Curve Public Key Algorithms elliptic curve public key algorithms use different conventions for specific fields depending on the curve in use. Each field is always formatted as an MPI, but with a curve-specific framing. This table summarizes those distinctions.</t>
<texttable title="OpenPGP
<table anchor="ecc-wire-formats-registry">
<name>OpenPGP ECC Curve-specific Curve-Specific Wire Formats registry" anchor="ecc-wire-formats-registry">
<ttcol align='left'>Curve</ttcol>
<ttcol align='left'>ECDH Registry</name>
<thead>
<tr>
<th align="left">Curve</th>
<th align="left">ECDH Point Format</ttcol>
<ttcol align='left'>ECDH Format</th>
<th align="left">ECDH Secret Key MPI</ttcol>
<ttcol align='left'>EdDSA MPI</th>
<th align="left">EdDSA Secret Key MPI</ttcol>
<ttcol align='left'>EdDSA MPI</th>
<th align="left">EdDSA Signature first MPI</ttcol>
<ttcol align='left'>EdDSA MPI</th>
<th align="left">EdDSA Signature second MPI</ttcol>
<c>NIST P-256</c>
<c>SEC1</c>
<c>integer</c>
<c>N/A</c>
<c>N/A</c>
<c>N/A</c>
<c>NIST P-384</c>
<c>SEC1</c>
<c>integer</c>
<c>N/A</c>
<c>N/A</c>
<c>N/A</c>
<c>NIST P-521</c>
<c>SEC1</c>
<c>integer</c>
<c>N/A</c>
<c>N/A</c>
<c>N/A</c>
<c>brainpoolP256r1</c>
<c>SEC1</c>
<c>integer</c>
<c>N/A</c>
<c>N/A</c>
<c>N/A</c>
<c>brainpoolP384r1</c>
<c>SEC1</c>
<c>integer</c>
<c>N/A</c>
<c>N/A</c>
<c>N/A</c>
<c>brainpoolP512r1</c>
<c>SEC1</c>
<c>integer</c>
<c>N/A</c>
<c>N/A</c>
<c>N/A</c>
<c>Ed25519Legacy</c>
<c>N/A</c>
<c>N/A</c>
<c>32 octets of secret</c>
<c>32 octets of R</c>
<c>32 octets of S</c>
<c>Curve25519Legacy</c>
<c>prefixed native</c>
<c>integer (see <xref target="curve25519-secrets"/>)</c>
<c>N/A</c>
<c>N/A</c>
<c>N/A</c>
</texttable> MPI</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">NIST P-256</td>
<td align="left">SEC1</td>
<td align="left">integer</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="left">NIST P-384</td>
<td align="left">SEC1</td>
<td align="left">integer</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="left">NIST P-521</td>
<td align="left">SEC1</td>
<td align="left">integer</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="left">brainpoolP256r1</td>
<td align="left">SEC1</td>
<td align="left">integer</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="left">brainpoolP384r1</td>
<td align="left">SEC1</td>
<td align="left">integer</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="left">brainpoolP512r1</td>
<td align="left">SEC1</td>
<td align="left">integer</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="left">Ed25519Legacy</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
<td align="left">32 octets of secret</td>
<td align="left">32 octets of R</td>
<td align="left">32 octets of S</td>
</tr>
<tr>
<td align="left">Curve25519Legacy</td>
<td align="left">prefixed native</td>
<td align="left">integer (see <xref target="curve25519-secrets"/>)</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
<td align="left">N/A</td>
</tr>
</tbody>
</table>
<t>For the native octet-string forms of Ed25519Legacy values, see <xref target="RFC8032"/>.
For the native octet-string forms of Curve25519Legacy secret scalars and points, see <xref target="RFC7748"/>.</t>
</section>
</section>
<section anchor="symmetric-algos"><name>Symmetric-Key anchor="symmetric-algos">
<name>Symmetric-Key Algorithms</name>
<texttable title="OpenPGP
<table anchor="symkey-algorithms-registry">
<name>OpenPGP Symmetric Key Algorithms registry" anchor="symkey-algorithms-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Algorithm</ttcol>
<c>0</c>
<c>Plaintext Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Algorithm</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">0</td>
<td align="left">Plaintext or unencrypted data</c>
<c>1</c>
<c>IDEA <xref target="IDEA"/></c>
<c>2</c>
<c>TripleDES (DES-EDE, data</td>
</tr>
<tr>
<td align="right">1</td>
<td align="left">IDEA <xref target="IDEA"/></td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">TripleDES (DES-EDE <xref target="SP800-67"/> - 168 bit -- 168-bit key derived from 192)</c>
<c>3</c>
<c>CAST5 (128 bit 192)</td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">CAST5 (128-bit key, as per <xref target="RFC2144"/>)</c>
<c>4</c>
<c>Blowfish (128 bit target="RFC2144"/>)</td>
</tr>
<tr>
<td align="right">4</td>
<td align="left">Blowfish (128-bit key, 16 rounds) <xref target="BLOWFISH"/></c>
<c>5</c>
<c>Reserved</c>
<c>6</c>
<c>Reserved</c>
<c>7</c>
<c>AES target="BLOWFISH"/></td>
</tr>
<tr>
<td align="right">5</td>
<td align="left">Reserved</td>
</tr>
<tr>
<td align="right">6</td>
<td align="left">Reserved</td>
</tr>
<tr>
<td align="right">7</td>
<td align="left">AES with 128-bit key <xref target="AES"/></c>
<c>8</c>
<c>AES target="AES"/></td>
</tr>
<tr>
<td align="right">8</td>
<td align="left">AES with 192-bit key</c>
<c>9</c>
<c>AES key</td>
</tr>
<tr>
<td align="right">9</td>
<td align="left">AES with 256-bit key</c>
<c>10</c>
<c>Twofish key</td>
</tr>
<tr>
<td align="right">10</td>
<td align="left">Twofish with 256-bit key <xref target="TWOFISH"/></c>
<c>11</c>
<c>Camellia target="TWOFISH"/></td>
</tr>
<tr>
<td align="right">11</td>
<td align="left">Camellia with 128-bit key <xref target="RFC3713"/></c>
<c>12</c>
<c>Camellia target="RFC3713"/></td>
</tr>
<tr>
<td align="right">12</td>
<td align="left">Camellia with 192-bit key</c>
<c>13</c>
<c>Camellia key</td>
</tr>
<tr>
<td align="right">13</td>
<td align="left">Camellia with 256-bit key</c>
<c>100 to 110</c>
<c>Private/Experimental algorithm</c>
<c>253, 254 and 255</c>
<c>Reserved key</td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private/Experimental algorithm</td>
</tr>
<tr>
<td align="right">253-255</td>
<td align="left">Reserved to avoid collision with Secret Key Encryption (see <xref target="secret-key-protection-registry"/> and <xref target="secret-key-packet-formats"/>)</c>
</texttable> target="secret-key-packet-formats"/>)</td>
</tr>
</tbody>
</table>
<t>Implementations <bcp14>MUST</bcp14> implement AES-128.
Implementations <bcp14>SHOULD</bcp14> implement AES-256.
Implementations <bcp14>MUST NOT</bcp14> encrypt data with IDEA, TripleDES, or CAST5.
Implementations <bcp14>MAY</bcp14> decrypt data that uses IDEA, TripleDES, or CAST5 for the sake of reading older messages or new messages from implementations predating support for <xref target="RFC2440"/>.
An Implementation that decrypts data using IDEA, TripleDES, or CAST5 <bcp14>SHOULD</bcp14> generate a deprecation warning about the symmetric algorithm, indicating that message confidentiality is suspect.
Implementations <bcp14>MAY</bcp14> implement any other algorithm.</t>
</section>
<section anchor="compression-algos"><name>Compression anchor="compression-algos">
<name>Compression Algorithms</name>
<texttable title="OpenPGP
<table anchor="compression-algorithms-registry">
<name>OpenPGP Compression Algorithms registry" anchor="compression-algorithms-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Algorithm</ttcol>
<c>0</c>
<c>Uncompressed</c>
<c>1</c>
<c>ZIP <xref target="RFC1951"/></c>
<c>2</c>
<c>ZLIB <xref target="RFC1950"/></c>
<c>3</c>
<c>BZip2 <xref target="BZ2"/></c>
<c>100 to 110</c>
<c>Private/Experimental algorithm</c>
</texttable> Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Algorithm</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">0</td>
<td align="left">Uncompressed [RFC9580]</td>
</tr>
<tr>
<td align="right">1</td>
<td align="left">ZIP <xref target="RFC1951"/></td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">ZLIB <xref target="RFC1950"/></td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">BZip2 <xref target="BZ2"/></td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private/Experimental algorithm</td>
</tr>
</tbody>
</table>
<t>Implementations <bcp14>MUST</bcp14> implement uncompressed data.
Implementations <bcp14>SHOULD</bcp14> implement ZLIB.
For interoperability reasons reasons, implementations <bcp14>SHOULD</bcp14> be able to decompress using ZIP.
Implementations <bcp14>MAY</bcp14> implement any other algorithm.</t>
</section>
<section anchor="hash-algos"><name>Hash anchor="hash-algos">
<name>Hash Algorithms</name>
<texttable title="OpenPGP
<!-- [rfced] Should table 23 include a row for ID 0 to align with the IANA registry <https://www.iana.org/assignments/openpgp>?
Registry: OpenPGP Hash Algorithms registry"
0 Reserved [RFC-ietf-openpgp-crypto-refresh-13]
-->
<table anchor="hash-algorithms-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Algorithm</ttcol>
<ttcol align='left'>Text Name</ttcol>
<ttcol align='left'>V6 signature salt size</ttcol>
<c>1</c>
<c>MD5 <xref target="RFC1321"/></c>
<c>"MD5"</c>
<c>N/A</c>
<c>2</c>
<c>SHA-1 <xref target="FIPS180"/>, <xref target="sha1cd"/></c>
<c>"SHA1"</c>
<c>N/A</c>
<c>3</c>
<c>RIPEMD-160 <xref target="RIPEMD-160"/></c>
<c>"RIPEMD160"</c>
<c>N/A</c>
<c>4</c>
<c>Reserved</c>
<c> </c>
<c> </c>
<c>5</c>
<c>Reserved</c>
<c> </c>
<c> </c>
<c>6</c>
<c>Reserved</c>
<c> </c>
<c> </c>
<c>7</c>
<c>Reserved</c>
<c> </c>
<c> </c>
<c>8</c>
<c>SHA2-256 <xref target="FIPS180"/></c>
<c>"SHA256"</c>
<c>16</c>
<c>9</c>
<c>SHA2-384 <xref target="FIPS180"/></c>
<c>"SHA384"</c>
<c>24</c>
<c>10</c>
<c>SHA2-512 <xref target="FIPS180"/></c>
<c>"SHA512"</c>
<c>32</c>
<c>11</c>
<c>SHA2-224 <xref target="FIPS180"/></c>
<c>"SHA224"</c>
<c>16</c>
<c>12</c>
<c>SHA3-256 <xref target="FIPS202"/></c>
<c>"SHA3-256"</c>
<c>16</c>
<c>13</c>
<c>Reserved</c>
<c> </c>
<c> </c>
<c>14</c>
<c>SHA3-512 <xref target="FIPS202"/></c>
<c>"SHA3-512"</c>
<c>32</c>
<c>100 to 110</c>
<c>Private/Experimental algorithm</c>
<c> </c>
<c> </c>
</texttable>
<texttable title="OpenPGP
<name>OpenPGP Hash Algorithms Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Algorithm</th>
<th align="left">Text Name</th>
<th align="left">V6 Signature Salt Size</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">1</td>
<td align="left">MD5 <xref target="RFC1321"/></td>
<td align="left">"MD5"</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">SHA-1 <xref target="FIPS180"/> <xref target="sha1cd"/></td>
<td align="left">"SHA1"</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">RIPEMD-160 <xref target="RIPEMD-160"/></td>
<td align="left">"RIPEMD160"</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="right">4</td>
<td align="left">Reserved [RFC9580]</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">5</td>
<td align="left">Reserved [RFC9580]</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">6</td>
<td align="left">Reserved [RFC9580]</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">7</td>
<td align="left">Reserved [RFC9580]</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">8</td>
<td align="left">SHA2-256 <xref target="FIPS180"/></td>
<td align="left">"SHA256"</td>
<td align="left">16</td>
</tr>
<tr>
<td align="right">9</td>
<td align="left">SHA2-384 <xref target="FIPS180"/></td>
<td align="left">"SHA384"</td>
<td align="left">24</td>
</tr>
<tr>
<td align="right">10</td>
<td align="left">SHA2-512 <xref target="FIPS180"/></td>
<td align="left">"SHA512"</td>
<td align="left">32</td>
</tr>
<tr>
<td align="right">11</td>
<td align="left">SHA2-224 <xref target="FIPS180"/></td>
<td align="left">"SHA224"</td>
<td align="left">16</td>
</tr>
<tr>
<td align="right">12</td>
<td align="left">SHA3-256 <xref target="FIPS202"/></td>
<td align="left">"SHA3-256"</td>
<td align="left">16</td>
</tr>
<tr>
<td align="right">13</td>
<td align="left">Reserved [RFC9580]</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
<tr>
<td align="right">14</td>
<td align="left">SHA3-512 <xref target="FIPS202"/></td>
<td align="left">"SHA3-512"</td>
<td align="left">32</td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private/Experimental algorithm</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
</tbody>
</table>
<table anchor="emsa-hash-oids-registry">
<name>OpenPGP Hash Algorithm Identifiers for RSA Signatures use Signatures' Use of EMSA-PKCS1-v1_5 EMSA&nbhy;PKCS1&nbhy;v1_5 Padding registry" anchor="emsa-hash-oids-registry">
<ttcol align='left'>Hash Algorithm</ttcol>
<ttcol align='left'>OID</ttcol>
<ttcol align='left'>Full hash prefix</ttcol>
<c>MD5</c>
<c>1.2.840.113549.2.5</c>
<c>0x30, Registry</name>
<thead>
<tr>
<th align="left">Hash Algorithm</th>
<th align="left">OID</th>
<th align="left">Full Hash Prefix</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">MD5</td>
<td align="left">1.2.840.113549.2.5</td>
<td align="left">0x30, 0x20, 0x30, 0x0C, 0x06, 0x08, 0x2A, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x04, 0x10</c>
<c>SHA-1</c>
<c>1.3.14.3.2.26</c>
<c>0x30, 0x10</td>
</tr>
<tr>
<td align="left">SHA-1</td>
<td align="left">1.3.14.3.2.26</td>
<td align="left">0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x0E, 0x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 0x14</c>
<c>RIPEMD-160</c>
<c>1.3.36.3.2.1</c>
<c>0x30, 0x14</td>
</tr>
<tr>
<td align="left">RIPEMD-160</td>
<td align="left">1.3.36.3.2.1</td>
<td align="left">0x30, 0x21, 0x30, 0x09, 0x06, 0x05, 0x2B, 0x24, 0x03, 0x02, 0x01, 0x05, 0x00, 0x04, 0x14</c>
<c>SHA2-256</c>
<c>2.16.840.1.101.3.4.2.1</c>
<c>0x30, 0x14</td>
</tr>
<tr>
<td align="left">SHA2-256</td>
<td align="left">2.16.840.1.101.3.4.2.1</td>
<td align="left">0x30, 0x31, 0x30, 0x0D, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 0x20</c>
<c>SHA2-384</c>
<c>2.16.840.1.101.3.4.2.2</c>
<c>0x30, 0x20</td>
</tr>
<tr>
<td align="left">SHA2-384</td>
<td align="left">2.16.840.1.101.3.4.2.2</td>
<td align="left">0x30, 0x41, 0x30, 0x0D, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 0x30</c>
<c>SHA2-512</c>
<c>2.16.840.1.101.3.4.2.3</c>
<c>0x30, 0x30</td>
</tr>
<tr>
<td align="left">SHA2-512</td>
<td align="left">2.16.840.1.101.3.4.2.3</td>
<td align="left">0x30, 0x51, 0x30, 0x0D, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 0x40</c>
<c>SHA2-224</c>
<c>2.16.840.1.101.3.4.2.4</c>
<c>0x30, 0x40</td>
</tr>
<tr>
<td align="left">SHA2-224</td>
<td align="left">2.16.840.1.101.3.4.2.4</td>
<td align="left">0x30, 0x2D, 0x30, 0x0D, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 0x1C</c>
<c>SHA3-256</c>
<c>2.16.840.1.101.3.4.2.8</c>
<c>0x30, 0x1C</td>
</tr>
<tr>
<td align="left">SHA3-256</td>
<td align="left">2.16.840.1.101.3.4.2.8</td>
<td align="left">0x30, 0x31, 0x30, 0x0D, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x08, 0x05, 0x00, 0x04, 0x20</c>
<c>SHA3-512</c>
<c>2.16.840.1.101.3.4.2.10</c>
<c>0x30, 0x20</td>
</tr>
<tr>
<td align="left">SHA3-512</td>
<td align="left">2.16.840.1.101.3.4.2.10</td>
<td align="left">0x30, 0x51, 0x30, 0x0D, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0a, 0x05, 0x00, 0x04, 0x40</c>
</texttable> 0x40</td>
</tr>
</tbody>
</table>
<t>Implementations <bcp14>MUST</bcp14> implement SHA2-256.
Implementations <bcp14>SHOULD</bcp14> implement SHA2-384 and SHA2-512.
Implementations <bcp14>MAY</bcp14> implement other algorithms.
Implementations <bcp14>SHOULD NOT</bcp14> create messages which that require the use of SHA-1 SHA-1, with the exception of computing version 4 key fingerprints and for purposes of the Modification Detection Code (MDC) MDC in version 1 Symmetrically Encrypted Integrity Protected Data packets.
Implementations <bcp14>MUST NOT</bcp14> generate signatures with MD5, SHA-1, or RIPEMD-160.
Implementations <bcp14>MUST NOT</bcp14> use MD5, SHA-1, or RIPEMD-160 as a hash function in an ECDH KDF.
Implementations <bcp14>MUST NOT</bcp14> generate packets using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF.
Implementations <bcp14>MUST NOT</bcp14> decrypt a secret using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF in a version 6 (or later) packet.
Implementations <bcp14>MUST NOT</bcp14> validate any recent signature that depends on MD5, SHA-1, or RIPEMD-160.
Implementations <bcp14>SHOULD NOT</bcp14> validate any old signature that depends on MD5, SHA-1, or RIPEMD-160 unless the signature's creation date predates known weakness of the algorithm used, and the implementation is confident that the message has been in the secure custody of the user the whole time.</t>
</section>
<section anchor="aead-algorithms"><name>AEAD anchor="aead-algorithms">
<name>AEAD Algorithms</name>
<texttable title="OpenPGP
<table anchor="aead-algorithms-registry">
<!-- [rfced] Should table 25 be updated to include a row for value 0 to match what appears in the IANA registry?
Registry: OpenPGP AEAD Algorithms registry" anchor="aead-algorithms-registry">
<ttcol align='right'>ID</ttcol>
<ttcol align='left'>Name</ttcol>
<ttcol align='left'>Reference</ttcol>
<ttcol align='left'>Nonce length (octets)</ttcol>
<ttcol align='left'>authentication tag length (octets)</ttcol>
<c>1</c>
<c>EAX</c>
<c><xref target="EAX"/></c>
<c>16</c>
<c>16</c>
<c>2</c>
<c>OCB</c>
<c><xref target="RFC7253"/></c>
<c>15</c>
<c>16</c>
<c>3</c>
<c>GCM</c>
<c><xref target="SP800-38D"/></c>
<c>12</c>
<c>16</c>
<c>100 to 110</c>
<c>Private/Experimental algorithm</c>
<c> </c>
<c> </c>
<c> </c>
</texttable>
0 Reserved [RFC-ietf-openpgp-crypto-refresh-13]
-->
<name>OpenPGP AEAD Algorithms Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Name</th>
<th align="left">Nonce Length (Octets)</th>
<th align="left">Authentication Tag Length (Octets)</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">1</td>
<td align="left">EAX</td>
<td align="left">16</td>
<td align="left">16</td>
<td align="left"><xref target="EAX"/></td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">OCB</td>
<td align="left">15</td>
<td align="left">16</td>
<td align="left"><xref target="RFC7253"/></td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">GCM</td>
<td align="left">12</td>
<td align="left">16</td>
<td align="left"><xref target="SP800-38D"/></td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private/Experimental algorithm</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left">[RFC9580]</td>
</tr>
</tbody>
</table>
<t>Implementations <bcp14>MUST</bcp14> implement OCB. Implementations <bcp14>MAY</bcp14> implement EAX, GCM GCM, and other algorithms.</t>
</section>
</section>
<section anchor="packet-sequence-composition"><name>Packet anchor="packet-sequence-composition">
<name>Packet Sequence Composition</name>
<t>OpenPGP packets are assembled into sequences in order to create messages and to transfer keys.
Not all possible packet sequences are meaningful and correct.
This section describes the rules for how packets should be placed into sequences.</t>
<t>There are three distinct sequences of packets:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>Transferable Public Keys (<xref target="transferable-public-keys"/>) and their close counterpart, Transferable Secret Keys (<xref target="transferable-secret-keys"/>)</t>
</li>
<li>
<t>OpenPGP Messages (<xref target="openpgp-messages"/>)</t>
</li>
<li>
<t>Detached Signatures (<xref target="detached-signatures"/>)</t>
</list></t>
</li>
</ul>
<t>Each sequence has an explicit grammar of what packet types (<xref target="packet-types-registry"/>) can appear in what place. The presence of an unknown critical packet, or a known but unexpected packet packet, is a critical error, invalidating the entire sequence (see <xref target="packet-criticality"/>).
On the other hand, unknown non-critical packets can appear anywhere within any sequence. This provides a structured way to introduce new packets into the protocol, while making sure that certain packets will be handled strictly.</t>
<t>An implementation may "recognize" a packet, packet but not implement it.
The purpose of Packet Criticality is to allow the producer to tell the consumer whether it would prefer a new, unknown packet to generate an error or be ignored.</t>
<t>Note
<!-- [rfced] Please confirm that "previous versions of this document" refer to previous versions of the specification (e.g., RFC 4880), rather than the drafts that preceded this document? We have updated the text as shown below. Please let us know if updates are required.
Original:
Note that previous versions of this document did not have a concept
of Packet Criticality, and did not give clear guidance on what to do
when unknown packets are encountered.
Therefore, implementations
Current:
Note that previous versions of older the OpenPGP specification did not have a concept
of Packet Criticality and did not give clear guidance on what to do
when unknown packets are encountered.
-->
<t>Note that previous versions of this document did not have a concept of Packet Criticality and did not give clear guidance on what to do when unknown packets are encountered. Therefore, implementations of the previous versions may reject unknown non-critical packets, packets or accept unknown critical packets.</t>
<t>When generating a sequence of OpenPGP packets according to one of the three grammars, an implementation <bcp14>MUST NOT</bcp14> inject a critical packet of a type that does not adhere to the grammar.</t>
<t>When consuming a sequence of OpenPGP packets according
<t>According to one of the three grammars, when consuming a sequence of OpenPGP packets, an implementation <bcp14>MUST</bcp14> reject the sequence with an error if it encounters a critical packet of an inappropriate type according to the grammar.</t> type.</t>
<section anchor="transferable-public-keys"><name>Transferable anchor="transferable-public-keys">
<name>Transferable Public Keys</name>
<t>OpenPGP users may transfer public keys.
This section describes the structure of public keys in transit to ensure interoperability.
An OpenPGP Transferable Public Key is also known as an OpenPGP certificate, in order to distinguish it from both its constituent Public-Key packets (<xref target="pubkey"/> (Sections <xref target="pubkey" format="counter"/> and <xref target="pubsubkey"/>) target="pubsubkey" format="counter"/>) and the underlying cryptographic key material.</t>
<section anchor="v6-certificate-structures"><name>OpenPGP anchor="v6-certificate-structures">
<name>OpenPGP v6 Certificate Structure</name>
<t>The format of an OpenPGP v6 certificate is as follows.
Entries in square brackets are optional and ellipses indicate repetition.</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
Primary Key
[Revocation Signature...]
Direct Key Signature...
[User ID or User Attribute
[Certification Revocation Signature...]
[Certification Signature...]]...
[Subkey [Subkey Revocation Signature...]
Subkey Binding Signature...]...
[Padding]
]]></artwork></figure>
]]></artwork>
<t>In addition to these rules, a marker packet (<xref target="marker-packet"/>) can appear anywhere in the sequence.</t>
<t>Note,
<t>Note that a v6 key uses a self-signed direct key signature to store algorithm preferences.</t>
<t>Every subkey for a v6 primary key <bcp14>MUST</bcp14> be a v6 subkey.
Every subkey <bcp14>MUST</bcp14> have at least one subkey binding signature.
Every subkey binding signature <bcp14>MUST</bcp14> be a self-signature (that is, made by the v6 primary key).
Like all other signatures, every self-signature made by a v6 key <bcp14>MUST</bcp14> be a v6 signature.</t>
</section>
<section anchor="v6-revocation-certificate"><name>OpenPGP anchor="v6-revocation-certificate">
<name>OpenPGP v6 Revocation Certificate</name>
<t>When a primary v6 Public Key is revoked, it is sometimes distributed with only the revocation signature:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
Primary Key
Revocation Signature
]]></artwork></figure>
]]></artwork>
<t>In this case, the direct key signature is no longer necessary, since the primary key itself has been marked as unusable.</t>
</section>
<section anchor="openpgp-v4-certificate-structure"><name>OpenPGP anchor="openpgp-v4-certificate-structure">
<name>OpenPGP v4 Certificate Structure</name>
<t>The format of an OpenPGP v4 key is as follows.</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
Primary Key
[Revocation Signature]
[Direct Key Signature...]
[User ID or User Attribute [Signature...]]...
[Subkey [Subkey Revocation Signature...]
Subkey Binding Signature...]...
]]></artwork></figure>
]]></artwork>
<t>In addition to these rules, a marker packet (<xref target="marker-packet"/>) can appear anywhere in the sequence.</t>
<t>A subkey always has at least one subkey binding signature after it that is issued using the primary key to tie the two keys together. These binding signatures may be in either v3 or v4 format, but they <bcp14>SHOULD</bcp14> be in v4 format.
Subkeys that can issue signatures <bcp14>MUST</bcp14> have a v4 binding signature due to the <bcp14>REQUIRED</bcp14> embedded primary key binding signature.</t>
<t>Every subkey for a v4 primary key <bcp14>MUST</bcp14> be a v4 subkey.</t>
<t>When a primary v4 Public Key is revoked, the revocation signature is sometimes distributed by itself, without the primary key packet it applies to. This is referred to as a "revocation certificate".
Instead, a v6 revocation certificate <bcp14>MUST</bcp14> include the primary key packet, as described in <xref target="v6-revocation-certificate"/>.</t>
</section>
<section anchor="openpgp-v3-key-structure"><name>OpenPGP anchor="openpgp-v3-key-structure">
<name>OpenPGP v3 Key Structure</name>
<t>The format of an OpenPGP v3 key is as follows.</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
RSA Public Key
[Revocation Signature]
User ID [Signature...]
[User ID [Signature...]]...
]]></artwork></figure>
]]></artwork>
<t>In addition to these rules, a marker packet (<xref target="marker-packet"/>) can appear anywhere in the sequence.</t>
<t>Each signature certifies the RSA public key and the preceding User ID.
The RSA public key can have many User IDs IDs, and each User ID can have many signatures.
V3 keys are deprecated. Implementations <bcp14>MUST NOT</bcp14> generate new v3 keys, keys but <bcp14>MAY</bcp14> continue to use existing ones.</t>
<t>V3 keys <bcp14>MUST NOT</bcp14> have subkeys.</t>
</section>
<section anchor="common-requirements"><name>Common requirements</name> anchor="common-requirements">
<name>Common Requirements</name>
<t>The Public-Key packet occurs first.</t>
<t>The primary key <bcp14>MUST</bcp14> be an algorithm capable of making signatures (that is, not an encryption-only algorithm). This is because the primary key needs to be able to create self-signatures (see <xref target="self-sigs"/>).
The subkeys may be keys of any type. For example, there may be a single-key RSA key, an Ed25519 primary key with an RSA encryption subkey, or an Ed25519 primary key with an X25519 subkey, etc.</t>
<t>Each of the following User ID packets provides the identity of the owner of this public key.
If there are multiple User ID packets, this corresponds to multiple means of identifying the same unique individual user; for example, a user may have more than one email address, address and construct a User ID for each one.
A transferable public key <bcp14>SHOULD</bcp14> include at least one User ID packet unless storage requirements prohibit this.</t>
<t>Immediately following each User ID packet, there are zero or more Signature packets.
Each Signature packet is calculated on the immediately preceding User ID packet and the initial 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 the belief that this public key belongs to the user identified by this User ID.</t>
<t>Within the same section as the User ID packets, there are zero or more User Attribute packets. Like the User ID packets, a User Attribute packet is followed by zero or more Signature packets calculated on the immediately preceding User Attribute packet and the initial Public-Key packet.</t>
<t>User Attribute packets and User ID packets may be freely intermixed in this section, so as long as the signatures that follow them are maintained on the proper User Attribute or User ID packet.</t>
<t>After the sequence of User ID packets and Attribute packets and their associated signatures, zero or more Subkey packets follow, each with their own signatures. In general, subkeys are provided in cases where the top-level public key is a certification-only key.
However, any v4 or v6 key may have subkeys, and the subkeys may be encryption keys, signing keys, authentication keys, etc.
It is good practice to use separate subkeys for every operation (i.e. (i.e., signature-only, encryption-only, authentication-only keys, etc.).</t>
<t>Each Subkey packet <bcp14>MUST</bcp14> be followed by one Signature packet, which should be a subkey binding signature issued by the top-level key.
For subkeys that can issue signatures, the subkey binding signature <bcp14>MUST</bcp14> contain an Embedded Signature subpacket with a primary key binding signature (0x19) issued by the subkey on the top-level key.</t>
<t>Subkey and Key packets may each be followed by a revocation Signature packet to indicate that the key is revoked.
Revocation signatures are only accepted if they are issued by the key itself, itself or by a key that is authorized to issue revocations via a Revocation Key subpacket in a self-signature by the top-level key.</t>
<t>The optional trailing Padding packet is a mechanism to defend against traffic analysis (see <xref target="traffic-analysis"/>).
For maximum interoperability, if the Public-Key packet is a v4 key, the optional Padding packet <bcp14>SHOULD NOT</bcp14> be present unless the recipient has indicated that they are capable of ignoring it successfully.
An implementation that is capable of receiving a transferable public key with a v6 Public-Key primary key <bcp14>MUST</bcp14> be able to accept (and ignore) the trailing optional Padding packet.</t>
<t>Transferable public-key packet sequences may be concatenated to allow transferring multiple public keys in one operation (see <xref target="keyrings"/>).</t>
</section>
</section>
<section anchor="transferable-secret-keys"><name>Transferable anchor="transferable-secret-keys">
<name>Transferable Secret Keys</name>
<t>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 and Secret-Subkey packets can be used in addition to the Public-Key and Public-Subkey packets.
<!-- [rfced] Is Section 6.2 the correct reference here? The
"transferable secret key" is not mentioned in that section, which
is titled "Forming ASCII Armor". Please let us know which section
is intended.
Original:
If a single Secret-Key or Secret-Subkey packet is included
in a packet sequence, it is a transferable secret key and
should be handled and marked as such (see Section 6.2).
-->
If a single Secret-Key or Secret-Subkey packet is included in a packet sequence, it is a transferable secret key and should be handled and marked as such (see <xref target="forming-ascii-armor"/>).
An implementation <bcp14>SHOULD</bcp14> include self-signatures on any User IDs and subkeys, as this allows for a complete public key to be automatically extracted from the transferable secret key. An implementation <bcp14>MAY</bcp14> choose to omit the self-signatures, especially if a transferable public key accompanies the transferable secret key.</t>
</section>
<section anchor="openpgp-messages"><name>OpenPGP anchor="openpgp-messages">
<name>OpenPGP Messages</name>
<!-- [rfced] Section 10.3. We see that the symbol ":-" was used in RFC
4880 as well as a few earlier RFCs; however, it is not commonly
used in recent RFCs. Does this symbol have a special meaning in
this context, or may we replace it with a colon?
One example
Original:
OpenPGP Message :- Encrypted Message | Signed Message | Compressed
Message | Literal Message.
Perhaps:
OpenPGP Message: Encrypted Message | Signed Message | Compressed
Message | Literal Message.
-->
<t>An OpenPGP message is a packet or sequence of packets that corresponds correspond to the following grammatical rules (comma (a comma (,) represents sequential composition, and a vertical bar (|) separates alternatives):</t>
<dl>
<dt>OpenPGP Message :-</dt>
<dd>
<t>Encrypted Message | Signed Message | Compressed Message | Literal Message.</t>
</dd>
<dt>Compressed Message :-</dt>
<dd>
<t>Compressed Data Packet.</t>
</dd>
<dt>Literal Message :-</dt>
<dd>
<t>Literal Data Packet.</t>
</dd>
<dt>ESK :-</dt>
<dd>
<t>Public-Key Encrypted Session Key Packet | Symmetric-Key Encrypted Session Key Packet.</t>
</dd>
<dt>ESK Sequence :-</dt>
<dd>
<t>ESK | ESK Sequence, ESK.</t>
</dd>
<dt>Encrypted Data :-</dt>
<dd>
<t>Symmetrically Encrypted Data Packet | Symmetrically Encrypted Integrity Protected Data Packet</t> Packet.</t>
</dd>
<dt>Encrypted Message :-</dt>
<dd>
<t>Encrypted Data | ESK Sequence, Encrypted Data.</t>
</dd>
<dt>One-Pass Signed Message :-</dt>
<dd>
<t>One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packet.</t>
</dd>
<dt>Signed Message :-</dt>
<dd>
<t>Signature Packet, OpenPGP Message | One-Pass Signed Message.</t>
</dd>
<dt>Optionally Padded Message :-</dt>
<dd>
<t>OpenPGP Message | OpenPGP Message, Padding Packet.</t>
</dd>
</dl>
<t>In addition to these rules, a marker packet (<xref target="marker-packet"/>) can appear anywhere in the sequence.</t>
<section anchor="unwrapping"><name>Unwrapping anchor="unwrapping">
<name>Unwrapping Encrypted and Compressed Messages</name>
<t>In addition to the above grammar, certain messages can be "unwrapped" to yield new messages.
In particular:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>Decrypting a version 2 Symmetrically Encrypted and Integrity Protected Data packet <bcp14>MUST</bcp14> yield a valid Optionally Padded Message.</t>
</li>
<li>
<t>Decrypting a version 1 Symmetrically Encrypted and Integrity Protected Data packet or --- -- for historic data --- -- a Symmetrically Encrypted Data packet <bcp14>MUST</bcp14> yield a valid OpenPGP Message.</t>
</li>
<li>
<t>Decompressing a Compressed Data packet <bcp14>MUST</bcp14> also yield a valid OpenPGP Message.</t>
</list></t>
</li>
</ul>
<t>When any unwrapping is performed, the resulting stream of octets is parsed into a series of OpenPGP packets like any other stream of octets.
The packet boundaries found in the series of octets are expected to align with the length of the unwrapped octet stream.
An implementation <bcp14>MUST NOT</bcp14> interpret octets beyond the boundaries of the unwrapped octet stream as part of any OpenPGP packet.
If an implementation encounters a packet whose header length indicates that it would extend beyond the boundaries of the unwrapped octet stream, the implementation <bcp14>MUST</bcp14> reject that packet as malformed and unusable.</t>
</section>
<section anchor="additional-constraints-on-packet-sequences"><name>Additional anchor="additional-constraints-on-packet-sequences">
<name>Additional Constraints on Packet Sequences</name>
<t>Note that some subtle combinations that are formally acceptable by this grammar are nonetheless unacceptable.</t>
<section anchor="encrypted-message-versions"><name>Packet anchor="encrypted-message-versions">
<name>Packet Versions in Encrypted Messages</name>
<t>As noted above, an Encrypted Message is a sequence of zero or more PKESKs (<xref target="pkesk"/>) and SKESKs (<xref target="skesk"/>), followed by an SEIPD (<xref target="seipd"/>) payload. In some historic data, the payload may be a deprecated SED packet (<xref target="sed"/>) packet instead of SEIPD, though implementations <bcp14>MUST NOT</bcp14> generate SED packets (see <xref target="ciphertext-malleability"/>).
The versions of the preceding ESK packets within an Encrypted Message <bcp14>MUST</bcp14> align with the version of the payload SEIPD packet, as described in this section.</t>
<t>v3 PKESK and v4 SKESK packets both contain in their cleartext the symmetric cipher algorithm ID in addition to and the session key for the subsequent SEIPD packet. packet in their cleartext.
Since a v1 SEIPD does not contain a symmetric algorithm ID, all ESK packets preceding a v1 SEIPD payload <bcp14>MUST</bcp14> be either v3 PKESK or v4 SKESK.</t>
<t>On the other hand, the cleartext of the v6 ESK packets (either PKESK or SKESK) do not contain a symmetric cipher algorithm ID, so they cannot be used in combination with a v1 SEIPD payload.
The payload following any v6 PKESK or v6 SKESK packet <bcp14>MUST</bcp14> be a v2 SEIPD.</t>
<t>Additionally, to avoid potentially conflicting cipher algorithm IDs, and for simplicity, implementations <bcp14>MUST NOT</bcp14> precede a v2 SEIPD payload with either v3 PKESK or v4 SKESK packets.</t>
<t>The versions of packets found in an Encrypted Message are summarized in the following table.
An implementation <bcp14>MUST</bcp14> only generate an Encrypted Message using packet versions that match a row with "Yes" in the "Generate?" column.
Other rows are provided for the purpose of historic interoperability.
A conforming implementation <bcp14>MUST</bcp14> only generate an Encrypted Message using packets whose versions correspond to a single row.</t>
<texttable title="OpenPGP
<table anchor="encrypted-packet-versions-registry">
<name>OpenPGP Encrypted Message Packet Versions registry" anchor="encrypted-packet-versions-registry">
<ttcol align='left'>Version Registry</name>
<thead>
<tr>
<th align="left">Version of Encrypted Data payload</ttcol>
<ttcol align='left'>Version Payload</th>
<th align="left">Version of preceding Preceding Symmetric-Key ESK (if any)</ttcol>
<ttcol align='left'>Version (If Any)</th>
<th align="left">Version of preceding Preceding Public-Key ESK (if any)</ttcol>
<ttcol align='left'>Generate?</ttcol>
<c>SED (<xref target="sed"/>)</c>
<c>-</c>
<c>v2 (If Any)</th>
<th align="left">Generate?</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">SED (<xref target="sed"/>)</td>
<td align="left">-</td>
<td align="left">v2 PKESK (<xref target="RFC2440"/>)</c>
<c>No</c>
<c>SED (<xref target="sed"/>)</c>
<c>v4 <xref target="RFC2440"/></td>
<td align="left">No</td>
</tr>
<tr>
<td align="left">SED (<xref target="sed"/>)</td>
<td align="left">v4 SKESK (<xref target="v4-skesk"/>)</c>
<c>v3 target="v4-skesk"/>)</td>
<td align="left">v3 PKESK (<xref target="v3-pkesk"/>)</c>
<c>No</c>
<c>v1 target="v3-pkesk"/>)</td>
<td align="left">No</td>
</tr>
<tr>
<td align="left">v1 SEIPD (<xref target="version-one-seipd"/>)</c>
<c>v4 target="version-one-seipd"/>)</td>
<td align="left">v4 SKESK (<xref target="v4-skesk"/>)</c>
<c>v3 target="v4-skesk"/>)</td>
<td align="left">v3 PKESK (<xref target="v3-pkesk"/>)</c>
<c>Yes</c>
<c>v2 target="v3-pkesk"/>)</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">v2 SEIPD (<xref target="version-two-seipd"/>)</c>
<c>v6 target="version-two-seipd"/>)</td>
<td align="left">v6 SKESK (<xref target="v6-skesk"/>)</c>
<c>v6 target="v6-skesk"/>)</td>
<td align="left">v6 PKESK (<xref target="v6-pkesk"/>)</c>
<c>Yes</c>
</texttable> target="v6-pkesk"/>)</td>
<td align="left">Yes</td>
</tr>
</tbody>
</table>
<t>An implementation processing an Encrypted Message <bcp14>MUST</bcp14> discard any preceding ESK packet with a version that does not align with the version of the payload.</t>
</section>
<section anchor="signed-message-versions"><name>Packet anchor="signed-message-versions">
<name>Packet Versions in Signatures</name>
<t>OpenPGP key packets and signature packets are also versioned.
The version of a Signature typically matches the version of the signing key.
When a v6 key produces a signature packet, it <bcp14>MUST</bcp14> produce a version 6 signature packet, regardless of the signature packet type.
When a message is signed or verified using the one-pass construction, the version of the One-Pass Signature packet (<xref target="one-pass-sig"/>) should also be aligned to the other versions.</t>
<t>Some legacy implementations have produced unaligned signature versions for older key material, which are also described in the table below for the purpose of historic interoperability.
A conforming implementation <bcp14>MUST</bcp14> only generate signature packets with version numbers matching rows with "Yes" in the "Generate?" column.</t>
<texttable title="OpenPGP
<table anchor="signed-packet-versions-registry">
<name>OpenPGP Key and Signature Versions registry" anchor="signed-packet-versions-registry">
<ttcol align='left'>Signing key version</ttcol>
<ttcol align='left'>Signature packet version</ttcol>
<ttcol align='left'>OPS packet version</ttcol>
<ttcol align='left'>Generate?</ttcol>
<c>3 (<xref target="v3-pubkeys"/>)</c>
<c>3 (<xref target="version-three-sig"/>)</c>
<c>3 <xref target="one-pass-sig"/></c>
<c>No</c>
<c>4 (<xref target="v4-pubkeys"/>)</c>
<c>3 (<xref target="version-three-sig"/>)</c>
<c>3 <xref target="one-pass-sig"/></c>
<c>No</c>
<c>4 (<xref target="v4-pubkeys"/>)</c>
<c>4 (<xref target="version-four-and-six-sig"/>)</c>
<c>3 <xref target="one-pass-sig"/></c>
<c>Yes</c>
<c>6 (<xref target="v6-pubkeys"/>)</c>
<c>6 (<xref target="version-four-and-six-sig"/>)</c>
<c>6 <xref target="one-pass-sig"/></c>
<c>Yes</c>
</texttable> Registry</name>
<thead>
<tr>
<th align="left">Signing Key Version</th>
<th align="left">Signature Packet Version</th>
<th align="left">OPS Packet Version</th>
<th align="left">Generate?</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">3 (<xref target="v3-pubkeys"/>)</td>
<td align="left">3 (<xref target="version-three-sig"/>)</td>
<td align="left">3 (<xref target="one-pass-sig"/>)</td>
<td align="left">No</td>
</tr>
<tr>
<td align="left">4 (<xref target="v4-pubkeys"/>)</td>
<td align="left">3 (<xref target="version-three-sig"/>)</td>
<td align="left">3 (<xref target="one-pass-sig"/>)</td>
<td align="left">No</td>
</tr>
<tr>
<td align="left">4 (<xref target="v4-pubkeys"/>)</td>
<td align="left">4 (<xref target="version-four-and-six-sig"/>)</td>
<td align="left">3 (<xref target="one-pass-sig"/>)</td>
<td align="left">Yes</td>
</tr>
<tr>
<td align="left">6 (<xref target="v6-pubkeys"/>)</td>
<td align="left">6 (<xref target="version-four-and-six-sig"/>)</td>
<td align="left">6 (<xref target="one-pass-sig"/>)</td>
<td align="left">Yes</td>
</tr>
</tbody>
</table>
<t>Note, however, that a version mismatch between these packets does not invalidate the packet sequence as a whole, whole; it merely invalidates the signature, as a signature with an unknown version <bcp14>SHOULD</bcp14> be discarded (see <xref target="malformed-signatures"/>).</t>
</section>
</section>
</section>
<section anchor="detached-signatures"><name>Detached anchor="detached-signatures">
<name>Detached Signatures</name>
<t>Some OpenPGP applications use so-called "detached signatures".
For example, a program bundle may contain a file, and with it a second file that is a detached signature of the first file. These detached signatures are simply one or more Signature packets stored separately from the data for which they are a signature.</t>
<t>In addition, a marker packet (<xref target="marker-packet"/>) and a padding packet (<xref target="padding-packet"/>) can appear anywhere in the sequence.</t>
</section>
</section>
<section anchor="elliptic-curve-cryptography"><name>Elliptic anchor="elliptic-curve-cryptography">
<name>Elliptic Curve Cryptography</name>
<t>This section describes algorithms and parameters used with Elliptic Curve Cryptography (ECC) keys.
A thorough introduction to ECC can be found in <xref target="KOBLITZ"/>.</t>
<t>None of the ECC methods described in this document are allowed with deprecated v3 keys.
<!-- [rfced] We do not see Appendix "B.4.1" in [FIPS186]. Appendix "B.4"
describes how to check for a perfect square. Please confirm
which section should be referenced in the following text.
Original:
Refer to [FIPS186], B.4.1, for the method to
generate a uniformly distributed ECC private key.
-->
Refer to <xref target="FIPS186"/>, Appendix B.4.1, for the method to generate a uniformly distributed ECC private key.</t>
<section anchor="ecc-curves"><name>ECC anchor="ecc-curves">
<name>ECC Curves</name>
<t>This document references three named prime field curves defined in <xref target="FIPS186"/> as "Curve P-256", "Curve P-384", and "Curve P-521"; P-521" and three named prime field curves defined in <xref target="RFC5639"/> as "brainpoolP256r1", "brainpoolP384r1", and "brainpoolP512r1".
<!-- [rfced] FYI: In the second sentence, we updated "The three [FIPS186]
curves and the three [RFC5639] curves" to "All six curves" since
the curves were already referenced in the first sentence. Please
let us know of any objections.
Original:
This document references three named prime field curves defined in
[FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521"; and
three named prime field curves defined in [RFC5639] as
"brainpoolP256r1", "brainpoolP384r1", and "brainpoolP512r1". The
three <xref target="FIPS186"/> [FIPS186] curves and the three <xref target="RFC5639"/> [RFC5639] curves can be used
with ECDSA and ECDH public key algorithms.
Current:
This document references three named prime field curves defined in
[FIPS186] as "Curve P-256", "Curve P-384", and "Curve P-521" and
three named prime field curves defined in [RFC5639] as
"brainpoolP256r1", "brainpoolP384r1", and "brainpoolP512r1". All
six of these curves can be used with ECDSA and ECDH public key
algorithms.
-->
All six curves can be used with ECDSA and ECDH public key algorithms. They are referenced using a sequence of octets, referred to as the curve OID. <xref target="ec-curves"/> describes in detail how this sequence of octets is formed.</t>
<t>Separate algorithms are also defined for the use of X25519 and X448, defined in X448 <xref target="RFC7748"/>; target="RFC7748"/> and Ed25519 and Ed448, defined in Ed448 <xref target="RFC8032"/>.
Additionally, legacy OIDs are defined for "Curve25519Legacy" (for encryption using the ECDH algorithm) and "Ed25519Legacy" (for signing using the EdDSALegacy algorithm).</t>
</section>
<section anchor="ec-point-wire-formats"><name>EC anchor="ec-point-wire-formats">
<name>EC Point Wire Formats</name>
<t>A point on an elliptic curve will always be represented on the wire as an MPI.
Each curve uses a specific point format for the data within the MPI itself.
Each format uses a designated prefix octet to ensure that the high octet has at least one bit set to make the MPI a constant size.</t>
<texttable title="OpenPGP
<table anchor="ec-point-wire-formats-registry">
<name>OpenPGP Elliptic Curve Point Wire Formats registry" anchor="ec-point-wire-formats-registry">
<ttcol align='right'>Name</ttcol>
<ttcol align='left'>Wire Format</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>SEC1</c>
<c>0x04 Registry</name>
<thead>
<tr>
<th align="right">Name</th>
<th align="left">Wire Format</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="right">SEC1</td>
<td align="left">0x04 || x || y</c>
<c><xref target="ec-point-sec1"/></c>
<c>Prefixed native</c>
<c>0x40 y</td>
<td align="left">
<xref target="ec-point-sec1"/></td>
</tr>
<tr>
<td align="right">Prefixed native</td>
<td align="left">0x40 || native</c>
<c><xref target="ec-point-prefixed-native"/></c>
</texttable> native</td>
<td align="left">
<xref target="ec-point-prefixed-native"/></td>
</tr>
</tbody>
</table>
<section anchor="ec-point-sec1"><name>SEC1 anchor="ec-point-sec1">
<name>SEC1 EC Point Wire Format</name>
<t>For a SEC1-encoded (uncompressed) point point, the content of the MPI is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
B = 04 || x || y
]]></artwork></figure>
]]></artwork>
<t>where x and y are coordinates of the point P = (x, y), and each is encoded in the big-endian format and zero-padded to the adjusted underlying field size.
The adjusted underlying field size is the underlying field size rounded up to the nearest 8-bit boundary, as noted in the "fsize" column in <xref target="ec-curves"/>.
This encoding is compatible with the definition given in <xref target="SEC1"/>.</t>
</section>
<section anchor="ec-point-prefixed-native"><name>Prefixed anchor="ec-point-prefixed-native">
<name>Prefixed Native EC Point Wire Format</name>
<t>For a custom compressed point point, the content of the MPI is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
B = 40 || p
]]></artwork></figure>
]]></artwork>
<t>where p is the public key of the point encoded using the rules defined for the specified curve.
This format is used for ECDH keys based on curves expressed in Montgomery form, form and for points when using EdDSA.</t>
</section>
<section anchor="notes-on-ec-point-wire-formats"><name>Notes anchor="notes-on-ec-point-wire-formats">
<name>Notes on EC Point Wire Formats</name>
<t>Given the above definitions, the exact size of the MPI payload for an encoded point is 515 bits for both NIST P-256 and brainpoolP256r1, 771 for both NIST P-384 and brainpoolP384r1, 1059 for NIST P-521, 1027 for brainpoolP512r1, and 263 for both Curve25519Legacy and Ed25519Legacy. For example, the length of a an EdDSALegacy public key for the curve Ed25519Legacy is 263 bits: 7 bits to represent the 0x40 prefix octet and 32 octets for the native value of the public key.</t>
<t>Even though the zero point, also point (also called the point "point at infinity, infinity") may occur as a result of arithmetic operations on points of an elliptic curve, it <bcp14>SHALL NOT</bcp14> appear in data structures defined in this document.</t>
<t>Each particular curve uses a designated wire format for the point found in its public key or ECDH data structure.
An implementation <bcp14>MUST NOT</bcp14> use a different wire format for a point other than the wire format associated with the curve.</t>
</section>
</section>
<section anchor="ec-scalar-wire-formats"><name>EC anchor="ec-scalar-wire-formats">
<name>EC Scalar Wire Formats</name>
<t>Some non-curve values in elliptic curve cryptography (for example, secret keys and signature components) are not points on a curve, but they are also encoded on the wire in OpenPGP as an MPI.</t>
<t>Because of different patterns of deployment, some curves treat these values as opaque bit strings with the high bit set, while others are treated as actual integers, encoded in the standard OpenPGP big-endian form.
The choice of encoding is specific to the public key algorithm in use.</t>
<texttable title="OpenPGP
<table anchor="ec-scalar-wire-formats-registry">
<name>OpenPGP Elliptic Curve Scalar Encodings registry" anchor="ec-scalar-wire-formats-registry">
<ttcol align='left'>Type</ttcol>
<ttcol align='left'>Description</ttcol>
<ttcol align='left'>Reference</ttcol>
<c>integer</c>
<c>An integer, big-endian Registry</name>
<thead>
<tr>
<th align="left">Type</th>
<th align="left">Description</th>
<th align="left">Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">integer</td>
<td align="left">An integer encoded in big-endian format as a standard OpenPGP MPI</c>
<c><xref target="mpi"/></c>
<c>octet string</c>
<c>An MPI</td>
<td align="left">
<xref target="mpi"/></td>
</tr>
<tr>
<td align="left">octet string</td>
<td align="left">An octet string of fixed length, length that may be shorter on the wire due to leading zeros being stripped by the MPI encoding, encoding and may need to be zero-padded before use</c>
<c><xref target="ec-octet-string"/></c>
<c>prefixed use</td>
<td align="left">
<xref target="ec-octet-string"/></td>
</tr>
<tr>
<td align="left">prefixed N octets</c>
<c>An octets</td>
<td align="left">An octet string of fixed length N, prefixed with octet 0x40 to ensure no leading zero octet</c>
<c><xref target="ec-prefix"/></c>
</texttable> octet</td>
<td align="left">
<xref target="ec-prefix"/></td>
</tr>
</tbody>
</table>
<section anchor="ec-octet-string"><name>EC anchor="ec-octet-string">
<name>EC Octet String Wire Format</name>
<t>Some opaque strings of octets are represented on the wire as an MPI by simply stripping the leading zeros and counting the remaining bits.
These strings are of known, fixed length.
They are represented in this document as <spanx style="verb">MPI(N <tt>MPI(N octets of X)</spanx> X)</tt>, where <spanx style="verb">N</spanx> <tt>N</tt> is the expected length in octets of the octet string.</t>
<t>For example, a five-octet opaque string (<spanx style="verb">MPI(5 (<tt>MPI(5 octets of X)</spanx>) X)</tt>) where <spanx style="verb">X</spanx> <tt>X</tt> has the value <spanx style="verb">00 <tt>00 02 EE 19 00</spanx> 00</tt> would be represented on the wire as an MPI like so: <spanx style="verb">00 <tt>00 1A 02 EE 19 00</spanx>.</t> 00</tt>.</t>
<t>To encode <spanx style="verb">X</spanx> <tt>X</tt> to the wire format, we set the MPI's two-octet bit counter to the value of the highest set bit (bit 26, or 0x001A), and do not transfer the leading all-zero octet to the wire.</t>
<t>To reverse the process, an implementation that knows this value has an expected length of 5 octets and can take the following steps:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>Ensure that the MPI's two-octet bitcount bit count is less than or equal to 40 (5 octets of 8 bits)</t>
</li>
<li>
<t>Allocate 5 octets, setting all to zero initially</t>
</li>
<li>
<t>Copy the MPI data octets (without the two count octets) into the lower octets of the allocated space</t>
</list></t>
</li>
</ul>
</section>
<section anchor="ec-prefix"><name>Elliptic Curve anchor="ec-prefix">
<name>EC Prefixed Octet String Wire Format</name>
<t>Another way to ensure that a fixed-length bytestring bytes string is encoded simply to the wire while remaining in MPI format is to prefix the bytestring byte string with a dedicated non-zero octet.
This specification uses 0x40 as the prefix octet.
This is represented in this standard specification as <spanx style="verb">MPI(prefixed <tt>MPI(prefixed N octets of X)</spanx>, X)</tt>, where <spanx style="verb">N</spanx> <tt>N</tt> is the known bytestring byte string length.</t>
<t>For example, a five-octet opaque string using <spanx style="verb">MPI(prefixed <tt>MPI(prefixed 5 octets of X)</spanx> X)</tt> where <spanx style="verb">X</spanx> <tt>X</tt> has the value <spanx style="verb">00 <tt>00 02 EE 19 00</spanx> 00</tt> would be written to the wire form as: <spanx style="verb">00 <tt>00 2F 40 00 02 EE 19 00</spanx>.</t> 00</tt>.</t>
<t>To encode the string, we prefix it with the octet 0x40 (whose 7th bit is set), and then set the MPI's two-octet bit counter to 47 (0x002F, (0x002F -- 7 bits for the prefix octet and 40 bits for the string).</t>
<t>To decode the string from the wire, an implementation that knows that the variable is formed in this way can:</t>
<t><list style="symbols">
<t>Ensure
<ul spacing="normal">
<li>
<t>ensure that the first three octets of the MPI (the two bit-count two-bit count octets plus the prefix octet) are <spanx style="verb">00 <tt>00 2F 40</spanx>, 40</tt>, and</t>
<t>Use
</li>
<li>
<t>use the remainder of the MPI directly off the wire.</t>
</list></t>
</li>
</ul>
<t>Note that this is a similar approach to that used in the EC point encodings found in <xref target="ec-point-prefixed-native"/>.</t>
</section>
</section>
<section anchor="key-derivation-function"><name>Key anchor="key-derivation-function">
<name>Key Derivation Function</name>
<t>A key derivation function (KDF) is necessary to implement EC encryption.
The Concatenation Key Derivation Function (Approved Alternative 1) <xref target="SP800-56A"/> with the KDF hash function that is SHA2-256 <xref target="FIPS180"/> or stronger is <bcp14>REQUIRED</bcp14>.</t>
<t>For convenience, the synopsis of the encoding method is given below with significant simplifications attributable to the restricted choice of hash functions in this document.
However, <xref target="SP800-56A"/> is the normative source of the definition.</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
// Implements KDF( X, oBits, Param );
// Input: point X = (x,y)
// oBits - the desired size of output
// hBits - the size of output of hash function Hash
// Param - octets representing the parameters
// Assumes that oBits <= hBits
// Convert the point X to the octet string:
// ZB' = 04 || x || y
// and extract the x portion from ZB'
ZB = x;
MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param );
return oBits leftmost bits of MB.
]]></artwork></figure>
]]></artwork>
<t>Note that ZB in the KDF description above is the compact representation of X as defined in <xref section="4.2" sectionFormat="of" target="RFC6090"/>.</t>
</section>
<section anchor="ecdh"><name>EC anchor="ecdh">
<!-- [rfced] Section 11.5
a) What is the method being described in this lead-in sentence - is it
the "One-Pass Diffie-Hellman method" (as mentioned in the paragraph
that follows)? If so, may we add it for clarity as shown below?
b) Since "ECDH" is used in this document, may we update the title of
this section to reflect "ECDH Algorithm" instead of "EC DH Algorithm"?
Original:
11.5 EC DH Algorithm (ECDH)
The method is a combination of an ECC Diffie-Hellman method to
establish a shared secret, a key derivation method to process the
shared secret into a derived key, and a key wrapping method that uses
the derived key to protect a session key used to encrypt a message..
Perhaps:
11.5 ECDH Algorithm
This section describes the One-Pass Diffie-Hellman method, which is
a combination of the ECC Diffie-Hellman method that establishes a shared
secret, the key derivation method that processes the shared secret into a
derived key, and the key wrapping method that uses the derived key to
protect a session key used to encrypt a message.
-->
<name>EC DH Algorithm (ECDH)</name>
<t>The method is a combination of an ECC Diffie-Hellman method to establish a shared secret, a key derivation method to process the shared secret into a derived key, and a key wrapping method that uses the derived key to protect a session key used to encrypt a message.</t>
<t>The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) <xref target="SP800-56A"/> <bcp14>MUST</bcp14> be implemented with the following restrictions: the ECC CDH Cofactor Diffie-Hellman (CDH) primitive employed by this method is modified to always assume the cofactor is 1, the KDF specified in <xref target="key-derivation-function"/> is used, and the KDF parameters specified below are used.</t>
<t>The KDF parameters are encoded as a concatenation of the following 5 variable-length and fixed-length fields, which are compatible with the definition of the OtherInfo bitstring bit string <xref target="SP800-56A"/>:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A variable-length field containing a curve OID, which is formatted as follows: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>A one-octet size of the following field,</t> field.</t>
</li>
<li>
<t>The octets representing a curve OID OID, as defined in <xref target="ec-curves"/>;</t>
</list></t> target="ec-curves"/>.</t>
</li>
</ul>
</li>
<li>
<t>A one-octet public key algorithm ID ID, as defined in <xref target="pubkey-algos"/>;</t> target="pubkey-algos"/>.</t>
</li>
<li>
<t>A variable-length field containing KDF parameters, which are identical to the corresponding field in the ECDH public key, key and are formatted as follows: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>A one-octet size of the following fields; values 0 and 0xFF are reserved for future extensions,</t> extensions.</t>
</li>
<li>
<t>A one-octet value 0x01, reserved for future extensions,</t> extensions.</t>
</li>
<li>
<t>A one-octet hash function ID used with the KDF,</t> KDF.</t>
</li>
<li>
<t>A one-octet algorithm ID for the symmetric algorithm that is used to wrap the symmetric key for message encryption; see <xref target="ecdh"/> for details;</t>
</list></t> details.</t>
</li>
</ul>
</li>
<li>
<t>20 octets representing the UTF-8 encoding of the string <spanx style="verb">Anonymous Sender </spanx>, <tt>Anonymous Sender</tt>, which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20;</t> 20.</t>
</li>
<li>
<t>A variable-length field containing the fingerprint of the recipient encryption subkey identifying the key material that is needed for decryption.
For version 4 keys, this field is 20 octets.
For version 6 keys, this field is 32 octets.</t>
</list></t>
</li>
</ul>
<t>The size in octets of the KDF parameters sequence, as defined above, for encrypting to a v4 key is either 54 for curve NIST P-256, P-256; 51 for curves NIST P-384 and NIST P-521, P-521; 55 for curves brainpoolP256r1, brainpoolP384r1 brainpoolP384r1, and brainpoolP512r1, brainpoolP512r1; or 56 for Curve25519Legacy. For encrypting to a v6 key, the size of the sequence is either 66 for curve NIST P-256, P-256; 63 for curves NIST P-384 and NIST P-521, P-521; or 67 for curves brainpoolP256r1, brainpoolP384r1 brainpoolP384r1, and brainpoolP512r1.</t>
<t>The key wrapping method is described in <xref target="RFC3394"/>.
The KDF produces a symmetric key that is used as a key-encryption key (KEK) KEK as specified in <xref target="RFC3394"/>. Refer to <xref target="ecdh-parameters"/> for the details regarding the choice of the KEK algorithm, which <bcp14>SHOULD</bcp14> be one of the three AES algorithms.
Key wrapping and unwrapping is performed with the default initial value of <xref target="RFC3394"/>.</t>
<t>To produce the input to the key wrapping method, first concatenate the following values:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>The one-octet algorithm identifier, if it was passed (in the case of a v3 PKESK packet).</t>
</li>
<li>
<t>The session key.</t>
</li>
<li>
<t>A two-octet checksum of the session key, equal to the sum of the session key octets, modulo 65536.</t>
</list></t>
</li>
</ul>
<t>Then, the above values are padded to an 8-octet granularity using the method described in <xref target="RFC2898"/> to an 8-octet granularity.</t> target="RFC2898"/>.</t>
<t>For example, in a v3 Public-Key Encrypted Session Key packet, an AES-256 session key is encoded as follows, forming a 40 octet 40-octet sequence:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
09 k0 k1 ... k31 s0 s1 05 05 05 05 05
]]></artwork></figure>
]]></artwork>
<t>The octets k0 to k31 above denote the session key, and the octets s0 and s1 denote the checksum of the session key octets.
This encoding allows the sender to obfuscate the size of the symmetric encryption key used to encrypt the data.
For example, assuming that an AES algorithm is used for the session key, the sender <bcp14>MAY</bcp14> use 21, 13, and 5 octets of padding for AES-128, AES-192, and AES-256, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.</t>
<t>In a v6 Public-Key Encrypted Session Key packet, the symmetric algorithm is not included, as described in <xref target="pkesk"/>.
For example, an AES-256 session key would be composed as follows:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
k0 k1 ... k31 s0 s1 06 06 06 06 06 06
]]></artwork></figure>
]]></artwork>
<t>The octets k0 to k31 above again denote the session key, and the octets s0 and s1 denote the checksum.
In this case, assuming that an AES algorithm is used for the session key, the sender <bcp14>MAY</bcp14> use 22, 14, and 6 octets of padding for AES-128, AES-192, and AES-256, respectively, to provide the same number of octets, 40 total, as an input to the key wrapping method.</t>
<t>The output of the method consists of two fields.
The first field is the MPI containing the ephemeral key used to establish the shared secret.
The second field is composed of the following two subfields:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>One octet encoding the size in octets of the result of the key wrapping method; the value 255 is reserved for future extensions;</t> extensions.</t>
</li>
<li>
<t>Up to 254 octets representing the result of the key wrapping method, applied to the 8-octet padded session key, as described above.</t>
</list></t>
</li>
</ul>
<t>Note that for session key sizes 128, 192, and 256 bits, the size of the result of the key wrapping method is, respectively, 32, 40, and 48 octets, unless size obfuscation is used.</t>
<t>For convenience, the synopsis of the encoding method is given below; however, this section, <xref target="SP800-56A"/>, and <xref target="RFC3394"/> are the normative sources of the definition.</t>
<t><list style="symbols">
<!-- [rfced] In Section 11.5, the synopsis of the encoding method is
given as a list, and that list contains inconsistent
semicolons. Are these semicolons a part of the code? If not, we
suggest either removing the semicolons or replacing the
semicolons with periods (and adding periods to the sentences that
do not contain any punctuation) for clarity. Please let us know
your preference.
Original:
* Obtain the authenticated recipient public key R
* Generate an ephemeral, single-use key pair {v, V=vG}
* Compute the shared point S = vR;
* m = symm_alg_ID || session key || checksum || pkcs5_padding;
* curve_OID_len = (octet)len(curve_OID);
* Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 ||
01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || Anonymous
Sender || recipient_fingerprint;
* Z_len = the key size for the KEK_alg_ID used with AESKeyWrap
* Compute Z = KDF( S, Z_len, Param );
* Compute C = AESKeyWrap( Z, m ); (as per [RFC3394])
* Wipe the memory that contained S, v, and Z to avoid leaking
ephemeral secrets
* VB = convert point V to the octet string
* Output (MPI(VB) || len(C) || C).
-->
<ul spacing="normal">
<li>
<t>Obtain the authenticated recipient public key R</t>
</li>
<li>
<t>Generate an ephemeral, single-use key pair {v, V=vG}</t>
</li>
<li>
<t>Compute the shared point S = vR;</t>
</li>
<li>
<t>m = symm_alg_ID || session key || checksum || pkcs5_padding;</t>
</li>
<li>
<t>curve_OID_len = (octet)len(curve_OID);</t>
</li>
<li>
<t>Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || <spanx style="verb">Anonymous Sender </spanx> <tt>Anonymous Sender</tt> || recipient_fingerprint;</t>
</li>
<li>
<t>Z_len = the key size for the KEK_alg_ID used with AESKeyWrap</t>
</li>
<li>
<t>Compute Z = KDF( S, Z_len, Param );</t>
</li>
<li>
<t>Compute C = AESKeyWrap( Z, m ); (as per (per <xref target="RFC3394"/>)</t>
</li>
<li>
<t>Wipe the memory that contained S, v, and Z to avoid leaking ephemeral secrets</t>
</li>
<li>
<t>VB = convert point V to the octet string</t>
</li>
<li>
<t>Output (MPI(VB) || len(C) || C).</t>
</list></t>
</li>
</ul>
<t>The decryption is the inverse of the method given.
Note that the recipient with key pair (r,R) obtains the shared secret by calculating:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
S = rV = rvG
]]></artwork></figure>
]]></artwork>
<section anchor="ecdh-parameters"><name>ECDH anchor="ecdh-parameters">
<name>ECDH Parameters</name>
<t>ECDH keys have a hash algorithm parameter for key derivation and a symmetric algorithm for key encapsulation.</t>
<t>For v6 keys, the following algorithms <bcp14>MUST</bcp14> be used depending on the curve.
An implementation <bcp14>MUST NOT</bcp14> generate a v6 ECDH key over any listed curve that uses different KDF or KEK parameters.
An implementation <bcp14>MUST NOT</bcp14> encrypt any message to a v6 ECDH key over a listed curve that announces a different KDF or KEK parameter.</t>
<t>For v4 keys, the following algorithms <bcp14>SHOULD</bcp14> be used depending on the curve.
An implementation <bcp14>SHOULD</bcp14> only use an AES algorithm as a KEK algorithm.</t>
<texttable title="OpenPGP
<table anchor="ecdh-kdf-kek-parameters-registry">
<name>OpenPGP ECDH KDF and KEK Parameters registry" anchor="ecdh-kdf-kek-parameters-registry">
<ttcol align='left'>Curve</ttcol>
<ttcol align='left'>Hash algorithm</ttcol>
<ttcol align='left'>Symmetric algorithm</ttcol>
<c>NIST P-256</c>
<c>SHA2-256</c>
<c>AES-128</c>
<c>NIST P-384</c>
<c>SHA2-384</c>
<c>AES-192</c>
<c>NIST P-521</c>
<c>SHA2-512</c>
<c>AES-256</c>
<c>brainpoolP256r1</c>
<c>SHA2-256</c>
<c>AES-128</c>
<c>brainpoolP384r1</c>
<c>SHA2-384</c>
<c>AES-192</c>
<c>brainpoolP512r1</c>
<c>SHA2-512</c>
<c>AES-256</c>
<c>Curve25519Legacy</c>
<c>SHA2-256</c>
<c>AES-128</c>
</texttable> Registry</name>
<thead>
<tr>
<th align="left">Curve</th>
<th align="left">Hash Algorithm</th>
<th align="left">Symmetric Algorithm</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">NIST P-256</td>
<td align="left">SHA2-256</td>
<td align="left">AES-128</td>
</tr>
<tr>
<td align="left">NIST P-384</td>
<td align="left">SHA2-384</td>
<td align="left">AES-192</td>
</tr>
<tr>
<td align="left">NIST P-521</td>
<td align="left">SHA2-512</td>
<td align="left">AES-256</td>
</tr>
<tr>
<td align="left">brainpoolP256r1</td>
<td align="left">SHA2-256</td>
<td align="left">AES-128</td>
</tr>
<tr>
<td align="left">brainpoolP384r1</td>
<td align="left">SHA2-384</td>
<td align="left">AES-192</td>
</tr>
<tr>
<td align="left">brainpoolP512r1</td>
<td align="left">SHA2-512</td>
<td align="left">AES-256</td>
</tr>
<tr>
<td align="left">Curve25519Legacy</td>
<td align="left">SHA2-256</td>
<td align="left">AES-128</td>
</tr>
</tbody>
</table>
</section>
</section>
</section>
<section anchor="notes-on-algorithms"><name>Notes anchor="notes-on-algorithms">
<name>Notes on Algorithms</name>
<section anchor="pkcs-encoding"><name>PKCS#1 anchor="pkcs-encoding">
<name>PKCS#1 Encoding in OpenPGP</name>
<t>This standard specification makes use of the PKCS#1 functions EME-PKCS1-v1_5 and EMSA-PKCS1-v1_5. However, the calling conventions of these functions has have changed in the past. To avoid potential confusion and interoperability problems, we are including local copies in this document, adapted from those in PKCS#1 v2.1 <xref target="RFC8017"/>. <xref target="RFC8017"/> should be treated as the ultimate authority on PKCS#1 for OpenPGP. Nonetheless, we believe that there is value in having a self-contained document that avoids problems in the future with needed changes in the conventions.</t>
<section anchor="eme-pkcs1-v1-5-encode"><name>EME-PKCS1-v1_5-ENCODE</name> anchor="eme-pkcs1-v1-5-encode">
<name>EME-PKCS1-v1_5-ENCODE</name>
<t>Input:</t>
<dl>
<dt>k =</dt>
<dd>
<t>the
<dd>key modulus length in octets of the key modulus.</t> octets.
</dd>
<dt>M =</dt>
<dd>
<t>message
<dd>message to be encoded, encoded; an octet string of length mLen, where mLen <= k - 11.</t> 11.
</dd>
</dl>
<t>Output:</t>
<dl>
<dt>EM =</dt>
<dd>
<t>encoded message,
<dd>encoded message; an octet string of length k.</t> k.
</dd>
</dl>
<t>Error: "message too long".</t>
<t><list style="numbers">
<ol spacing="normal" type="1"><li>
<t>Length checking: If mLen > k - 11, output "message too long" and stop.</t>
</li>
<li>
<t>Generate an octet string PS of length k - mLen - 3 consisting of pseudo-randomly pseudorandomly generated nonzero non-zero octets. The length of PS will be at least eight octets.</t>
</li>
<li>
<t>Concatenate PS, the message M, and other padding to form an encoded message EM of length k octets as <vspace blankLines='1'/>
<figure><artwork><![CDATA[ </t>
<artwork><![CDATA[
EM = 0x00 || 0x02 || PS || 0x00 || M.
]]></artwork></figure>
</t>
]]></artwork>
</li>
<li>
<t>Output EM.</t>
</list></t>
</li>
</ol>
</section>
<section anchor="eme-pkcs1-v1-5-decode"><name>EME-PKCS1-v1_5-DECODE</name> anchor="eme-pkcs1-v1-5-decode">
<name>EME-PKCS1-v1_5-DECODE</name>
<!-- [rfced] Sections 12.1.2 and 12.1.3
a) In Section 12.1.2, should "M = message" be updated as
"M = message to be encoded" to match use in Sections 12.1.1
and 12.1.3, or is this instance different than the others?
Original:
M = message, an octet string.
Perhaps:
M = message to be encoded; an octet string.
b) Section 12.1.3. In the encoding method, "Hash" is followed
by a dash whereas the other terms are followed by an equals sign.
Is this intentional, or can we update the dash to be an equals sign
for consistency?
Original:
Hash - a hash function in which hLen denotes the length in octets of
the hash function output.
Input:
M = message to be encoded.
Perhaps:
Hash = hash function in which hLen denotes the length of
the hash function output in octets.
Input:
M = message to be encoded.
-->
<t>Input:</t>
<dl>
<dt>EM =</dt>
<dd>
<t>encoded message, message; an octet string</t> string.</t>
</dd>
</dl>
<t>Output:</t>
<dl>
<dt>M =</dt>
<dd>
<t>message,
<t>message; an octet string.</t>
</dd>
</dl>
<t>Error: "decryption error".</t>
<t>To decode an EME-PKCS1_v1_5 message, separate the encoded message EM into an octet string PS consisting of nonzero non-zero octets and a message M as follows</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
EM = 0x00 || 0x02 || PS || 0x00 || M.
]]></artwork></figure>
]]></artwork>
<t>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 no octet with hexadecimal value 0x00 to separate PS from M, or if the length of PS is less than 8 octets, output "decryption error" and stop. See also <xref target="pkcs1-errors"/> regarding differences in reporting between a decryption error and a padding error.</t>
</section>
<section anchor="emsa-pkcs1-v1-5"><name>EMSA-PKCS1-v1_5</name> anchor="emsa-pkcs1-v1-5">
<name>EMSA-PKCS1-v1_5</name>
<t>This encoding method is deterministic and only has an encoding operation.</t>
<t>Option:</t>
<dl>
<dt>Hash -</dt>
<dd>
<t>a hash
<t>hash function in which hLen denotes the length in octets of the hash function output.</t>
</dd>
</dl>
<t>Input:</t>
<dl>
<dt>M =</dt>
<dd>
<t>message to be encoded.</t>
</dd>
<dt>emLen =</dt>
<dd>
<t>intended length in octets of the encoded message, message in octets, at least tLen + 11, where tLen is the octet length of the DER encoding T of a certain value computed during the encoding operation.</t>
</dd>
</dl>
<t>Output:</t>
<dl>
<dt>EM =</dt>
<dd>
<t>encoded message, message; an octet string of length emLen.</t>
</dd>
</dl>
<t>Errors: "message too long"; "intended encoded message length too short".</t>
<t>Steps:</t>
<t><list style="numbers">
<ol spacing="normal" type="1"><li>
<t>Apply the hash function to the message M to produce a hash value H: <vspace blankLines='1'/> </t>
<t>
H = Hash(M). <vspace blankLines='1'/> </t>
<t>
If the hash function outputs "message too long," output "message too long" and stop.</t>
</li>
<li>
<t>Using the list in <xref target="hash-algos"/>, produce an ASN.1 DER value for the hash function used.
Let T be the full hash prefix from the list, and let tLen be the length in octets of T.</t>
</li>
<li>
<t>If emLen < tLen + 11, output "intended encoded message length too short" and stop.</t>
</li>
<li>
<t>Generate an octet string PS consisting of emLen - tLen - 3 octets with hexadecimal value 0xFF.
The length of PS will be at least 8 octets.</t>
</li>
<li>
<t>Concatenate PS, the hash prefix T, and other padding to form the encoded message EM as <vspace blankLines='1'/>
<figure><artwork><![CDATA[ </t>
<artwork><![CDATA[
EM = 0x00 || 0x01 || PS || 0x00 || T.
]]></artwork></figure>
</t>
]]></artwork>
</li>
<li>
<t>Output EM.</t>
</list></t>
</li>
</ol>
</section>
</section>
<section anchor="symmetric-algorithm-preferences"><name>Symmetric anchor="symmetric-algorithm-preferences">
<name>Symmetric Algorithm Preferences</name>
<t>The symmetric algorithm preference is an ordered list of algorithms that the keyholder accepts.
Since it is found on a self-signature, it is possible that a keyholder may have multiple, different preferences. For example, Alice may have AES-128 only specified for "alice@work.com" but Camellia-256, Twofish, and AES-128 specified for "alice@home.org". Note that it is also possible for preferences to be in a subkey's binding signature.</t>
<t>Since AES-128 is the <bcp14>MUST</bcp14>-implement algorithm, algorithm that <bcp14>MUST</bcp14> be implemented, if it is not explicitly in the list, it is tacitly at the end. However, it is good form to place it there explicitly.
Note also that if an implementation does not implement the preference, then it is implicitly an AES-128-only implementation.
Note further Furthermore, note that implementations conforming to previous versions of this standard specification <xref target="RFC4880"/> have TripleDES as its the only <bcp14>MUST</bcp14>-implement algorithm.</t> algorithm that <bcp14>MUST</bcp14> be implemented.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> use a symmetric algorithm that is not in the recipient's preference list. When encrypting to more than one recipient, the implementation finds a suitable algorithm by taking the intersection of the preferences of the recipients. Note that the <bcp14>MUST</bcp14>-implement algorithm, AES-128, ensures AES-128 algorithm <bcp14>MUST</bcp14> be implemented to ensure that the intersection is non-empty. The implementation may use any mechanism to pick an algorithm in the intersection.</t>
<t>If an implementation can decrypt a message that a keyholder doesn't have in their preferences, the implementation <bcp14>SHOULD</bcp14> decrypt the message anyway, but it <bcp14>MUST</bcp14> warn the keyholder that the protocol has been violated. For example, suppose that Alice, above, Alice (above) has an implementation that implements all algorithms in this specification. Nonetheless, she prefers subsets for work or home. If she is sent a message encrypted with IDEA, which is not in her preferences, the implementation warns her that someone sent her an IDEA-encrypted message, but it would ideally decrypt it anyway.</t>
<section anchor="plaintext"><name>Plaintext</name> anchor="plaintext">
<name>Plaintext</name>
<t>Algorithm 0, "plaintext", may only be used to denote secret keys that are stored in the clear.
An implementation <bcp14>MUST NOT</bcp14> use algorithm 0 as the indicated symmetric cipher for an encrypted data packet (<xref target="sed"/> (Sections <xref target="sed" format="counter"/> or <xref target="seipd"/>); target="seipd" format="counter"/>); it can use a Literal Data packet (<xref target="lit"/>) to encode unencrypted literal data.</t>
</section>
</section>
<section anchor="other-algorithm-preferences"><name>Other anchor="other-algorithm-preferences">
<name>Other Algorithm Preferences</name>
<t>Other algorithm preferences work similarly to the symmetric algorithm preference, preference in that they specify which algorithms the keyholder accepts. There are two interesting cases that other in which further comments need to be made about, though, are needed: the compression preferences and the hash preferences.</t>
<section anchor="compression-preferences"><name>Compression anchor="compression-preferences">
<name>Compression Preferences</name>
<t>Like the algorithm preferences, an implementation <bcp14>MUST NOT</bcp14> use an algorithm that is not in the preference vector.
If Uncompressed (0) is not explicitly in the list, it is tacitly at the end.
That is, uncompressed messages may always be sent.</t>
<t>Note that earlier implementations may assume that the absence of compression preferences means that [ZIP(1), Uncompressed(0)] are preferred, and default to ZIP compression.
Therefore, an implementation that prefers uncompressed data <bcp14>SHOULD</bcp14> explicitly state this in the preferred compression algorithms.</t>
<section anchor="uncompressed"><name>Uncompressed</name> anchor="uncompressed">
<name>Uncompressed</name>
<t>Algorithm 0, "uncompressed", may only be used to denote a preference for uncompressed data.
An implementation <bcp14>MUST NOT</bcp14> use algorithm 0 as the indicated compression algorithm in a Compressed Data packet (<xref target="compressed-data"/>); it can use a Literal Data packet (<xref target="lit"/>) to encode uncompressed literal data.</t>
</section>
</section>
<section anchor="hash-algorithm-preferences"><name>Hash anchor="hash-algorithm-preferences">
<name>Hash Algorithm Preferences</name>
<t>Typically,
<!-- [rfced] FYI: We rephrased the text as shown below for better
readability. Please let us know of any objections.
Original:
Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer rarely knows who is
going to be verifying the signature. This preference, though, allows
a protocol based upon digital signatures ease in negotiation.
Perhaps:
Typically, the signer chooses what hash algorithm to use, rather
than the verifier, because a signer rarely knows who is going
to be verifying the signature. This preference allows a
protocol based upon digital signatures ease during negotiation.
-->
<t>Typically, the signer chooses what hash algorithm to use, rather than the verifier, because a signer rarely knows who is going to be verifying the signature. This preference allows a protocol based upon digital signatures ease in negotiation.</t>
<t>Thus, if Alice is authenticating herself to Bob with a signature, it makes sense for her to use a hash algorithm that Bob's implementation uses. This preference allows Bob to state in his key which algorithms Alice may use.</t> use in his key.</t>
<t>Since SHA2-256 is the <bcp14>MUST</bcp14>-implement hash algorithm, algorithm that <bcp14>MUST</bcp14> be implemented, if it is not explicitly in the list, it is tacitly at the end.
However, it is good form to place it there explicitly.</t>
</section>
</section>
<section anchor="rsa-notes"><name>RSA</name> anchor="rsa-notes">
<name>RSA</name>
<t>The PKCS1-v1_5 padding scheme, used by the RSA algorithms defined in this document, is no longer recommended, and its use is deprecated by <xref target="SP800-131A"/>.
Therefore, an implementation <bcp14>SHOULD NOT</bcp14> generate RSA keys.</t>
<t>There are algorithm types for RSA Sign-Only, Sign-Only and RSA Encrypt-Only keys.
These types are deprecated. The "key flags" subpacket in a signature is a much better way to express the same idea, idea and generalizes generalize it to all algorithms. An implementation <bcp14>MUST NOT</bcp14> create such a key, but it <bcp14>MAY</bcp14> interpret it.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> generate RSA keys of a size less than 3072 bits.
An implementation <bcp14>SHOULD NOT</bcp14> encrypt, sign sign, or verify using RSA keys of a size less than 3072 bits. An implementation <bcp14>MUST NOT</bcp14> encrypt, sign sign, or verify using RSA keys of a size less than 2048 bits. An implementation that decrypts a message using an RSA secret key of a size less than 3072 bits <bcp14>SHOULD</bcp14> generate a deprecation warning that the key is too weak for modern use.</t>
</section>
<section anchor="dsa-notes"><name>DSA</name> anchor="dsa-notes">
<name>DSA</name>
<t>DSA is no longer recommended.
It has also been deprecated in <xref target="FIPS186"/>.
Therefore, an implementation <bcp14>MUST NOT</bcp14> generate DSA keys.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> sign or verify using DSA keys.</t>
</section>
<section anchor="elgamal-notes"><name>Elgamal</name> anchor="elgamal-notes">
<name>Elgamal</name>
<t>The PKCS1-v1_5 padding scheme, used by the Elgamal algorithm defined in this document, is no longer recommended, and its use is deprecated by <xref target="SP800-131A"/>.
Therefore, an implementation <bcp14>MUST NOT</bcp14> generate Elgamal keys.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> encrypt using Elgamal keys.
An implementation that decrypts a message using an Elgamal secret key <bcp14>SHOULD</bcp14> generate a deprecation warning that the key is too weak for modern use.</t>
</section>
<section anchor="eddsa-notes"><name>EdDSA</name> anchor="eddsa-notes">
<name>EdDSA</name>
<t>Although the EdDSA algorithm allows arbitrary data as input, its use with OpenPGP requires that a digest of the message is be used as input (pre-hashed). See <xref target="computing-signatures"/> for details.
Truncation of the resulting digest is never applied; the resulting digest value is used verbatim as input to the EdDSA algorithm.</t>
<t>For clarity: while <xref target="RFC8032"/> describes different variants of EdDSA, OpenPGP uses the "pure" variant (PureEdDSA).
The hashing that happens with OpenPGP is done as part of the standard OpenPGP signature process, and that hash itself is fed as the input message to the PureEdDSA algorithm.</t>
<t>As specified in <xref target="RFC8032"/>, Ed448 also expects a "context string".
In OpenPGP, Ed448 is used with the empty string as a context string.</t>
</section>
<section anchor="reserved-notes"><name>Reserved anchor="reserved-notes">
<name>Reserved Algorithm IDs</name>
<t>A number of algorithm IDs have been reserved for algorithms that would be useful to use in an OpenPGP implementation, yet there are issues that prevent an implementer from actually implementing the algorithm. These are marked as reserved in <xref target="pubkey-algos"/>.</t>
<t>The reserved public-key algorithm X9.42 (21) does not have the necessary parameters, parameter order, or semantics defined. The same is currently true for reserved public-key algorithms AEDH (23) and AEDSA (24).</t>
<t>Previous versions of the OpenPGP specification permitted Elgamal <xref target="ELGAMAL"/> signatures with a public-key algorithm ID of 20. These are no longer permitted. An implementation <bcp14>MUST NOT</bcp14> generate such keys. An implementation <bcp14>MUST NOT</bcp14> generate Elgamal signatures.
See signatures;
see <xref target="BLEICHENBACHER"/>.</t>
</section>
<section anchor="cfb-mode"><name>CFB anchor="cfb-mode">
<name>CFB Mode</name>
<t>The Cipher Feedback (CFB) mode used in this document is defined in Section 6.3 of <xref target="SP800-38A"/>.</t>
<t>The CFB segment size <spanx style="verb">s</spanx> <tt>s</tt> is equal to the block size of the cipher (i.e., n-bit CFB mode mode, where n is the block size is used).</t>
</section>
<section anchor="private-or-experimental-parameters"><name>Private anchor="private-or-experimental-parameters">
<name>Private or Experimental Parameters</name>
<!-- [rfced] Because the ranges are reserved for Private and Experimental Use, may we update this text as follows?
Original:
These are intentionally managed with
the PRIVATE USE method, as described in [RFC8126].
Perhaps;
These are intentionally managed
by the Private Use and Experimental Use policies, as described in [RFC8126].
-->
<t>S2K specifiers, Signature subpacket type IDs, User Attribute subpacket type IDs, image format IDs, and the various algorithm IDs described in <xref target="constants"/> all reserve the range 100 to 110 for private Private and experimental use. Experimental Use.
Packet type IDs reserve the range 60 to 63 for private Private and experimental use. Experimental Use.
These are intentionally managed with by the PRIVATE USE Private Use method, as described in <xref target="RFC8126"/>.</t>
<t>However, implementations need to be careful with these and promote them to full IANA-managed parameters when they grow beyond the original, limited system.</t>
</section>
<section anchor="meta-considerations-for-expansion"><name>Meta-Considerations anchor="meta-considerations-for-expansion">
<name>Meta Considerations for Expansion</name>
<t>If OpenPGP is extended in a way that is not backwards-compatible, backward compatible, meaning that old implementations will not gracefully handle their absence of a new feature, the extension proposal can be declared in the keyholder's self-signature as part of the Features signature subpacket.</t>
<t>We cannot state definitively what extensions will not be upwards-compatible, upward compatible, but typically new algorithms are upwards-compatible, upward compatible, whereas new packets are not.</t>
<t>If an extension proposal does not update the Features system, it <bcp14>SHOULD</bcp14> include an explanation of why this is unnecessary.
If the proposal contains neither an extension to the Features system nor an explanation of why such an extension is unnecessary, the proposal <bcp14>SHOULD</bcp14> be rejected.</t>
</section>
</section>
<section anchor="security-considerations"><name>Security anchor="security-considerations">
<name>Security Considerations</name>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>As with any technology involving cryptography, implementers should check the current literature to determine if any algorithms used here have been found to be vulnerable to an attack.
If so, implementers should consider disallowing such algorithms for new data and warn or prevent warning the enduser end user, or preventing use, when they are trying to consume data protected by such algorithms that are now vulnerable algorithms.</t> vulnerable.</t>
</li>
<li>
<t>This specification uses Public-Key Cryptography technologies.
It is assumed that the private key portion of a public-private key pair is controlled and secured by the proper party or parties.</t>
</li>
<li>
<t>The MD5 and SHA-1 hash algorithms have been found to have weaknesses, with collisions found in a number of cases.
MD5 and SHA-1 are deprecated for use in OpenPGP (See (see <xref target="hash-algos"/>).</t>
</li>
<li>
<t>Many security protocol designers think that it is a bad idea to use a single key for both privacy (encryption) and integrity (signatures).
In fact, this was one of the motivating forces behind the v4 key format with separate signature and encryption keys. Using a single key for encrypting and signing is discouraged.</t>
</li>
<li>
<t>The DSA algorithm will work with any hash, but it is sensitive to the quality of the hash algorithm.
Verifiers should be aware that even if the signer used a strong hash, an attacker could have modified the signature to use a weak one. Only signatures using acceptably strong hash algorithms should be accepted as valid.</t>
</li>
<li>
<t>As OpenPGP combines many different asymmetric, symmetric, and hash algorithms, each with different measures of strength, care should be taken to ensure that the weakest element of an OpenPGP message is still sufficiently strong for the purpose at hand. While consensus about the strength of a given algorithm may evolve, NIST Special Publication 800-57 <xref target="SP800-57"/> contains recommendations current (current at the time of this publication publication) about equivalent security levels of different algorithms.</t>
</li>
<li>
<t>There is a somewhat-related potential security problem in signatures.
If an attacker can find a message that hashes to the same hash with a different algorithm, a bogus signature structure can be constructed that evaluates correctly. <vspace blankLines='1'/> </t>
<t>
For example, suppose Alice DSA signs DSA-signs message M using hash algorithm H.
Suppose that Mallet finds a message M' that has the same hash value as M with H'.
Mallet can then construct a signature block that verifies as Alice's signature of M' with H'.
However, this would also constitute a weakness in either H or H' H', or both.
Should this ever occur, a revision will have to be made to this document to revise the allowed hash algorithms.</t>
</li>
<li>
<t>If you are building an authentication system, the recipient may specify a preferred signing algorithm.
However, the signer would be foolish to use a weak algorithm simply because the recipient requests it.</t>
</li>
<li>
<t>Some of the encryption algorithms mentioned in this document have been analyzed less than others.
For example, although TWOFISH is presently considered reasonably strong, it has been analyzed much less than AES.
Other algorithms may have other concerns surrounding them.</t>
</li>
<li>
<t>In late summer 2002, Jallad, Katz, and Schneier published an interesting attack on older previous versions of the OpenPGP protocol and some of its implementations <xref target="JKS02"/>.
In this attack, the attacker modifies a message and sends it to a user who then returns the erroneously decrypted message to the attacker.
The attacker is thus using the user as a decryption oracle, oracle and can often decrypt the message.
This attack is a particular form of ciphertext malleability.
See <xref target="ciphertext-malleability"/> for information on how to defend against such an attack using more recent versions of OpenPGP.</t>
</list></t>
</li>
</ul>
<section anchor="sha1cd"><name>SHA-1 anchor="sha1cd">
<name>SHA-1 Collision Detection</name>
<t>As described in <xref target="SHAMBLES"/>, the SHA-1 digest algorithm is not collision-resistant. collision resistant.
However, an OpenPGP implementation cannot completely discard the SHA-1 algorithm, because it is required for implementing v4 public keys.
In particular, the v4 fingerprint derivation uses SHA-1.
So as long as an OpenPGP implementation supports v4 public keys, it will need to implement SHA-1 in at least some scenarios.</t>
<t>To avoid the risk of uncertain breakage from a maliciously introduced SHA-1 collision, an OpenPGP implementation <bcp14>MAY</bcp14> attempt to detect when a hash input is likely from a known collision attack, attack and then either deliberately reject the hash input deliberately or modify the hash output.
This should convert an uncertain breakage (where it is unclear what the effect of a collision will be) to an explicit breakage, which is more desirable for a robust implementation.</t>
<t><xref target="STEVENS2013"/> describes a method for detecting indicators of well-known SHA-1 collision attacks.
Some example C code implementing this technique can be found at <xref target="SHA1CD"/>.</t>
</section>
<section anchor="signature-salt-rationale"><name>Advantages anchor="signature-salt-rationale">
<name>Advantages of Salted Signatures</name>
<t>V6 signatures include a salt that is hashed first, which and it's size depends on the hashing algorithm. This makes v6 OpenPGP signatures non-deterministic and protects against a broad class of attacks that depend on creating a signature over a predictable message. By selecting a new random salt for each signature made, the signed hashes and the signatures are not predictable.</t>
<t>While the material to be signed could be attacker-controlled, attacker controlled, hashing the salt first means that there is no attacker controlled attacker-controlled hashed prefix.
An example of this kind of attack is described in the paper "SHA-1 Is A is a Shambles" <xref target="SHAMBLES"/>, which leverages a chosen prefix collision attack against SHA-1.
This means that an adversary carrying out a chosen-message attack will not be able to control the hash that is being signed, signed and will need to break second-preimage resistance instead of the simpler collision resistance to create two messages having the same signature.
The size of the salt is bound to the hash function to match the expected collision resistance level, collision-resistance level and is at least 16 octets.</t>
<t>In some cases, an attacker may be able to induce a signature to be made, even if they do not control the content of the message. In some scenarios, a repeated signature over the exact same message may risk leakage of part or all of the signing key, key; for example example, see discussion of hardware faults over EdDSA and deterministic ECDSA in <xref target="PSSLR17"/>.
Choosing a new random salt for each signature ensures that no repeated signatures are produced, and which mitigates this risk.</t>
</section>
<section anchor="ecc-side-channels"><name>Elliptic anchor="ecc-side-channels">
<name>Elliptic Curve Side Channels</name>
<t>Side channel
<t>Side-channel attacks are a concern when a compliant application's use of the OpenPGP format can be modeled by a decryption or signing oracle, for example, when an application is a network service performing decryption to unauthenticated remote users.
ECC scalar multiplication operations used in ECDSA and ECDH are vulnerable to side channel side-channel attacks. Countermeasures can often be taken at the higher protocol level, such as limiting the number of allowed failures or time-blinding of the operations associated with each network interface. Mitigations at the scalar multiplication level seek to eliminate any measurable distinction between the ECC point addition and doubling operations.</t>
</section>
<section anchor="quick-check-oracle"><name>Risks anchor="quick-check-oracle">
<name>Risks of a Quick Check Oracle</name>
<t>In winter 2005, Serge Mister and Robert Zuccherato from Entrust released a paper describing a way that the "quick check" in v1 SEIPD and SED packets can be used as an oracle to decrypt two octets of every cipher block <xref target="MZ05"/>.
This check was intended for early detection of session key decryption errors, particularly to detect a wrong passphrase, since v4 SKESK packets do not include an integrity check.</t>
<t>There is a danger to when using the quick check if timing or error information about the check can be exposed to an attacker, particularly via an automated service that allows rapidly repeated queries.</t>
<t>Disabling the quick check prevents the attack.</t>
<t>For very large encrypted data whose session key is protected by a passphrase using a version 4 SKESK, the quick check may be convenient to the user, user by informing them early that they typed the wrong passphrase.
But the implementation should use the quick check with care.
The recommended approach for secure and early detection of decryption failure is to encrypt data using v2 SEIPD.
If the session key is public-key encrypted, the quick check is not useful as the public-key encryption of the session key should guarantee that it is the right session key.</t>
<t>The quick check oracle attack is a particular type of attack that exploits ciphertext malleability.
For information about other similar attacks, see <xref target="ciphertext-malleability"/>.</t>
</section>
<section anchor="pkcs1-errors"><name>Avoiding anchor="pkcs1-errors">
<name>Avoiding Leaks From from PKCS#1 Errors</name>
<t>The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted PKESK) has been found to be vulnerable to attacks in which a system that allows distinguishing padding errors from other decryption errors can act as a decryption and/or signing oracle that can leak the session key or allow signing arbitrary data, respectively <xref target="BLEICHENBACHER-PKCS1"/>.
The number of queries required to carry out an attack can range from thousands to millions, depending on how strict and careful an implementation is in processing the padding.</t>
<t>To make the attack more difficult, an implementation <bcp14>SHOULD</bcp14> implement strict, robust, and constant time padding checks.</t>
<t>To prevent the attack, in settings where the attacker does not have access to timing information concerning message decryption, the simplest solution is to report a single error code for all variants of PKESK processing errors as well as SEIPD integrity errors (this includes also includes session key parsing errors, such as on an invalid cipher algorithm for v3 PKESK, or a session key size mismatch for v6 PKESK). If the attacker may have access to timing information, then a constant time solution is also needed. This requires careful design, especially for v3 PKESK, where session key size and cipher information is typically not known in advance, as it is part of the PKESK encrypted payload.</t>
</section>
<section anchor="fingerprint-usability"><name>Fingerprint anchor="fingerprint-usability">
<name>Fingerprint Usability</name>
<t>This specification uses fingerprints in several places on the wire (e.g., Sections <xref target="revocation-key"/>, target="revocation-key" format="counter"/>, <xref target="issuer-fingerprint-subpacket"/>, target="issuer-fingerprint-subpacket" format="counter"/>, and <xref target="intended-recipient-fingerprint"/>), target="intended-recipient-fingerprint" format="counter"/>) and in processing (e.g., in ECDH KDF <xref target="ecdh"/>). An implementation may also use the fingerprint internally, for example example, as an index to a keystore.</t>
<t>Additionally, some OpenPGP users have historically used manual fingerprint comparison to verify the public key of a peer.
For a version 4 fingerprint, this has typically been done with the fingerprint represented as 40 hexadecimal digits, often broken into groups of four digits with whitespace between each group.</t>
<t>When a human is actively involved, the result of such a verification is dubious.
There is little evidence that most humans are good at precise comparison of high-entropy data, particularly when that data is represented in compact textual form like a hexadecimal (<xref target="USENIX-STUDY"/>).</t> <xref target="USENIX-STUDY"/>.</t>
<t>The version 6 fingerprint makes the challenge for a human verifier even worse.
At 256 bits (compared to v4's 160 bit 160-bit fingerprint), a v6 fingerprint is even harder for a human to successfully compare.</t>
<t>An OpenPGP implementation should prioritize mechanical fingerprint transfer and comparison where possible, possible and <bcp14>SHOULD NOT</bcp14> promote manual transfer or comparison of full fingerprints by a human unless there is no other way to achieve the desired result.</t>
<t>While this subsection acknowledges existing practice for human-representable v4 fingerprints, this document does not attempt to standardize any specific human-readable form of v6 fingerprint for this discouraged use case.</t>
<t>NOTE: the topic of interoperable human-in-the-loop key verification needs more work, to which will be done in a separate document.</t>
</section>
<section anchor="ciphertext-malleability"><name>Avoiding anchor="ciphertext-malleability">
<name>Avoiding Ciphertext Malleability</name>
<t>If ciphertext can be modified by an attacker but still subsequently decrypted to some new plaintext, it is considered "malleable". A number of attacks can arise in any cryptosystem that uses malleable encryption, so <xref target="RFC4880"/> and later versions of OpenPGP offer mechanisms to defend against it. However, OpenPGP data may have been created before these defense mechanisms were available. Because OpenPGP implementations deal with historic stored data, they may encounter malleable ciphertexts.</t>
<!-- [rfced] FYI: We updated "indicate a clear error message" to
"generate a clear error message that indicates" for clarity as
shown below. Please let us know of any objections.
Original:
When an OpenPGP implementation discovers that it is decrypting data
that appears to be malleable, it MUST indicate a clear error message
that the integrity of the message is suspect, SHOULD NOT attempt to
parse nor release decrypted data to the user, and SHOULD halt with an
error.
Current:
When an OpenPGP implementation discovers that it is decrypting data
that appears to be malleable, it MUST generate a clear error message
that indicates the integrity of the message is suspect, it SHOULD NOT
attempt to parse nor release decrypted data to the user, and it
SHOULD halt with an error.
-->
<t>When an OpenPGP implementation discovers that it is decrypting data that appears to be malleable, it <bcp14>MUST</bcp14> indicate generate a clear error message that indicates the integrity of the message is suspect, it <bcp14>SHOULD NOT</bcp14> attempt to parse nor release decrypted data to the user, and it <bcp14>SHOULD</bcp14> halt with an error.
Parsing or releasing decrypted data before having confirmed its integrity can leak the decrypted data <xref target="EFAIL"/>, target="EFAIL"/> <xref target="MRLG15"/>.</t>
<t>In the case of AEAD encrypted data, if the authentication tag fails to verify, the implementation <bcp14>MUST NOT</bcp14> attempt to parse nor release decrypted data to the user, and it <bcp14>MUST</bcp14> halt with an error.</t>
<t>An implementation that encounters malleable ciphertext <bcp14>MAY</bcp14> choose to release cleartext to the user if it is not encrypted using AEAD, and it is known to be dealing with historic archived legacy data, and the user is aware of the risks.</t>
<t>In the case of AEAD encrypted messages, if the message is truncated, i.e. i.e., the final zero-octet chunk and possibly (part of) some chunks before it are missing, the implementation <bcp14>MAY</bcp14> choose to release cleartext from the fully authenticated chunks before it to the user if it is operating in a streaming fashion, but it <bcp14>MUST</bcp14> indicate a clear error message as soon as the truncation is detected.</t>
<t>Any of the following OpenPGP data elements indicate that malleable ciphertext is present:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>All Symmetrically Encrypted Data packets (<xref target="sed"/>).</t>
</li>
<li>
<t>Within any encrypted container, any Compressed Data packet (<xref target="compressed-data"/>) where there is a decompression failure.</t>
</li>
<li>
<t>Any version 1 Symmetrically Encrypted Integrity Protected Data packet (<xref target="version-one-seipd"/>) where the internal Modification Detection Code does not validate.</t>
</li>
<li>
<t>Any version 2 Symmetrically Encrypted Integrity Protected Data packet (<xref target="version-two-seipd"/>) where the authentication tag of any chunk fails, fails or where there is no final zero-octet chunk.</t>
</li>
<li>
<t>Any Secret-Key packet with encrypted secret key material (<xref target="secret-key-encryption"/>) where there is an integrity failure, based on the value of the secret key protection octet: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>Value 255 (MalleableCFB) or raw cipher algorithm: where the trailing 2-octet checksum does not match.</t>
</li>
<li>
<t>Value 254 (CFB): where the SHA1 checksum is mismatched.</t>
</li>
<li>
<t>Value 253 (AEAD): where the AEAD authentication tag is invalid.</t>
</list></t>
</list></t>
</li>
</ul>
</li>
</ul>
<t>To avoid these circumstances, an implementation that generates OpenPGP encrypted data <bcp14>SHOULD</bcp14> select the encrypted container format with the most robust protections that can be handled by the intended recipients.
In particular:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>The SED packet is deprecated, deprecated and <bcp14>MUST NOT</bcp14> be generated.</t>
</li>
<li>
<t>When encrypting to one or more public keys: <list style="symbols"> </t>
<ul spacing="normal">
<li>
<t>If all recipient keys indicate support for version 2 of the Symmetrically Encrypted Integrity Protected Data packet in their Features subpacket (<xref target="features-subpacket"/>), or if all recipient keys are v6 keys without a Features subpacket, or the implementation can otherwise infer that all recipients support v2 SEIPD packets, the implementation <bcp14>SHOULD</bcp14> encrypt using a v2 SEIPD packet.</t>
</li>
<li>
<t>If one of the recipients does not support v2 SEIPD packets, then the message generator <bcp14>MAY</bcp14> use a v1 SEIPD packet instead.</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Passphrase-protected secret key material in a v6 Secret Key or v6 Secret Subkey packet <bcp14>SHOULD</bcp14> be protected with AEAD encryption (S2K usage octet 253) unless it will be transferred to an implementation that is known to not support AEAD.
An implementation should be aware that, in scenarios where an attacker has write access to encrypted private keys, CFB-encrypted keys (S2K usage octet 254 or 255) are vulnerable to corruption attacks that can cause leakage of secret data when the secret key is used <xref target="KOPENPGP"/>, target="KOPENPGP"/> <xref target="KR02"/>.</t>
</list></t>
</li>
</ul>
<t>Implementers should implement AEAD (v2 SEIPD and S2K usage octet 253) promptly and encourage its spread.</t>
<t>Users are <bcp14>RECOMMENDED</bcp14> to migrate to AEAD.</t>
</section>
<section anchor="secure-sessionkey-reuse"><name>Secure anchor="secure-sessionkey-reuse">
<name>Secure Use of the v2 SEIPD Session-Key-Reuse Feature</name>
<t>The salted key derivation of v2 SEIPD packets (<xref target="version-two-seipd"/>) allows the recipient of an encrypted message to reply to the sender and all other recipients without needing their public keys but by using the same v6 PKESK packets he it received and a different random salt value.
This ensures a secure mechanism on the cryptographic level that enables the use of message encryption in cases where a sender does not have a copy of an encryption-capable certificate for one or more participants in the conversation and thus can enhance the overall security of an application. However, care must be taken when using this mechanism not to create security vulnerabilities, such as the following.</t>
<t><list style="symbols"> following:</t>
<ul spacing="normal">
<li>
<t>Replying to only a subset of the original recipients and the original sender by use of the session-key-reuse feature would mean that the remaining recipients (including the sender) of the original message could read the encrypted reply message, too.</t>
</li>
<li>
<t>Adding a further recipient to the reply that is encrypted using the session-key-reuse feature gives that further recipient also cryptographic access to the original message that is being replied to (and potentially to a longer history of previous messages).</t>
</li>
<li>
<t>A modification of the list of recipients addressed in the above points needs also needs to be safeguarded when a message is initially composed as a reply with session-key reuse but then first is stored (e.g. (e.g., as a draft) and later reopened for further editing and to be finally sent.</t>
</li>
<li>
<t>There is the potential threat that an attacker with network or mailbox access, who is at the same time a recipient of the original message, silently removes themselves from the message before the victim's client receives it.
The victim's client that then uses the mechanism for replying with session-key reuse would unknowingly compose an encrypted message that could be read by the attacker.
Implementations are encouraged to use the Intended Recipient Fingerprint subpacket (<xref target="intended-recipient-fingerprint"/>) subpacket when composing messages and to use it to check checking the consistency of the set of recipients of a message before replying to it with session-key reuse.</t>
</li>
<li>
<t>When using the session-key-reuse feature in any higher-layer protocol, care should be taken to ensure that there is no other potentially interfering practice of session-key reuse established in that protocol.
<!-- [rfced] The following sentence does not parse (specifically,
"composed by reusing the session key of an existing encrypted
file the access"). Please let us know how the text may be updated
for clarity.
Original:
Such interfering session-key reuse could for instance
be given if an initial message is already composed by reusing the
session key of an existing encrypted file the access to which may
be shared among a group of users already.
-->
Such interfering session-key reuse could be given, for instance, if an initial message is already composed by reusing the session key of an existing encrypted file the access to which may be shared among a group of users already. Using the session-key-reuse feature to compose an encrypted reply to such a message would unknowingly give this whole group of users cryptographic access to the encrypted message.</t>
</li>
<li>
<t>Generally, the use of the session-key-reuse feature should be under the control of the user. Specifically, care should be taken so that this feature is not silently used when the user assumes that proper public-key encryption is used. This can be the case case, for instance instance, when the public key of one of the recipients of the reply is known but has expired. Special care should be taken to ensure that users do not get caught in continued use of the session-key reuse unknowingly but instead receive the chance to switch to proper fresh public-key encryption as soon as possible.</t>
</li>
<li>
<t>Whenever possible, a client should prefer a fresh public key encryption over the session-key reuse.</t>
</list></t>
</li>
</ul>
<t>Even though this is not necessarily being a security aspect, note that initially composing an encrypted reply using the session-key-reuse feature on one client and then storing it (e.g. (e.g., as a draft) and later reopening the stored unfinished reply with another client that does not support the session-key-reuse feature may lead to interoperability problems.</t>
<t>Avoiding the pitfalls described above requires context-specific expertise.
An implementation should only make use of the session-key-reuse feature in any particular application layer when it can follow reasonable documentation about how to deploy the feature safely in the specific application.
At the time of this writing, there is no known documentation about safe reuse of OpenPGP session keys for any specific context. An implementer that intends to make use of this feature should publish their own proposed guidance for others to review.</t>
</section>
<section anchor="escrowed-revocations"><name>Escrowed anchor="escrowed-revocations">
<name>Escrowed Revocation Signatures</name>
<t>A keyholder, Alice, may wish to designate a third party to be able to revoke Alice's her own key.</t>
<t>The preferred way for her Alice to do this is to produce a specific Revocation Signature (signature type IDs 0x20, 0x28, or 0x30) and distribute it securely to her a preferred revoker who can hold it in escrow. The preferred revoker can then publish the escrowed Revocation Signature at whatever time is deemed appropriate, appropriate rather than generating a the revocation signature themselves.</t>
<t>There are multiple advantages of using an escrowed Revocation Signature over the deprecated Revocation Key subpacket (<xref target="revocation-key"/>):</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>The keyholder can constrain what types of revocation the preferred revoker can issue, by only escrowing those specific signatures.</t>
</li>
<li>
<t>There is no public/visible linkage between the keyholder and the preferred revoker.</t>
</li>
<li>
<t>Third parties can verify the revocation without needing to find the key of the preferred revoker.</t>
</li>
<li>
<t>The preferred revoker doesn't even need to have a public OpenPGP key if some other secure transport is possible between them and the keyholder.</t>
</li>
<li>
<t>Implementation support for enforcing a revocation from an authorized Revocation Key subpacket is uneven and unreliable.</t>
</li>
<li>
<t>If the fingerprint mechanism suffers a cryptanalytic flaw, the escrowed Revocation Signature is not affected.</t>
</list></t>
</li>
</ul>
<t>A Revocation Signature may also be split up into shares and distributed among multiple parties, requiring some subset of those parties to collaborate before the escrowed Revocation Signature is recreated.</t>
</section>
<section anchor="CSPRNG"><name>Random anchor="CSPRNG">
<name>Random Number Generation and Seeding</name>
<t>OpenPGP requires a cryptographically secure pseudorandom number generator (CSPRNG). In most cases, the operating system provides an appropriate facility such as a <spanx style="verb">getrandom()</spanx> <tt>getrandom()</tt> syscall on Linux or BSD, which should be used absent other (for example, performance) concerns.
It is <bcp14>RECOMMENDED</bcp14> to use an existing CSPRNG implementation in preference as opposed to crafting a new one.
Many adequate cryptographic libraries are already available under favorable license terms. Should those prove unsatisfactory, <xref target="RFC4086"/> provides guidance on the generation of random values.</t>
<t>OpenPGP uses random data with three different levels of visibility:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>In publicly-visible publicly visible fields such as nonces, IVs, public padding material, or salts,</t> salts.</t>
</li>
<li>
<t>In shared-secret values, such as session keys for encrypted data or padding material within an encrypted packet, and</t> packet.</t>
</li>
<li>
<t>In entirely private data, such as asymmetric key generation.</t>
</list></t>
</li>
</ul>
<t>With a properly functioning CSPRNG, this range of visibility does not present a security problem, as it is not feasible to determine the CSPRNG state from its output.
However, with a broken CSPRNG, it may be possible for an attacker to use visible output to determine the CSPRNG internal state and thereby predict less-visible data like keying material, as documented in <xref target="CHECKOWAY"/>.</t>
<t>An implementation can provide extra security against this form of attack by using separate CSPRNGs to generate random data with different levels of visibility.</t>
</section>
<section anchor="traffic-analysis"><name>Traffic anchor="traffic-analysis">
<name>Traffic Analysis</name>
<t>When sending OpenPGP data through the network, the size of the data may leak information to an attacker. There are circumstances where such a leak could be unacceptable from a security perspective.</t>
<t>For example, if possible cleartext messages for a given protocol are known to be either <spanx style="verb">yes</spanx> <tt>yes</tt> (three octets) and <spanx style="verb">no</spanx> or <tt>no</tt> (two octets) and the messages are sent within a Symmetrically-Encrypted Symmetrically Encrypted Integrity Protected Data packet, the length of the encrypted message will reveal the contents of the cleartext.</t>
<t>In another example, sending an OpenPGP Transferable Public Key over an encrypted network connection might reveal the length of the certificate.
<!-- [rfced] Please clarify who "whom" is referring to in this text.
Original:
Since the length of an OpenPGP certificate varies based
on the content, an external observer interested in metadata (who is
trying to contact whom) may be able to guess the identity of the
certificate sent, if its length is unique.
-->
Since the length of an OpenPGP certificate varies based on the content, an external observer interested in metadata (who is trying to contact whom) may be able to guess the identity of the certificate sent, if its length is unique.</t>
<t>In both cases, an implementation can adjust the size of the compound structure by including a Padding packet (see <xref target="padding-packet"/>).</t>
</section>
<section anchor="surreptitious-forwarding"><name>Surreptitious anchor="surreptitious-forwarding">
<name>Surreptitious Forwarding</name>
<t>When an attacker obtains a signature for some text, e.g. e.g., by receiving a signed message, they may be able to use that signature maliciously by sending a message purporting to come from the original sender, with the same body and signature, to a different recipient.
To prevent this, an implementation <bcp14>SHOULD</bcp14> implement the Intended Recipient Fingerprint signature subpacket (<xref target="intended-recipient-fingerprint"/>).</t>
</section>
<section anchor="subpacket-section-guidance"><name>Hashed anchor="subpacket-section-guidance">
<name>Hashed vs. Unhashed Subpackets</name>
<t>Each OpenPGP signature can have subpackets in two different sections.
The first set of subpackets (the "hashed section") is covered by the signature itself.
The second set has no cryptographic protections, protections and is used for advisory material only, including locally-stored locally stored annotations about the signature.</t>
<t>For example, consider an implementation working with a specific signature that happens to know that the signature was made by a certain key, even though the signature contains no Issuer Fingerprint subpacket (<xref target="issuer-fingerprint-subpacket"/>) in the hashed section.
That implementation <bcp14>MAY</bcp14> synthesize an Issuer Fingerprint subpacket and store it in the unhashed section so that in the future it will be able to recall which key issued the signature.</t> signature in the future.</t>
<t>Some subpackets are only useful when they are in the hashed section, and an implementation <bcp14>SHOULD</bcp14> ignore them when they are found with unknown provenance in the unhashed section.
For example, a Preferred AEAD Ciphersuites subpacket (<xref target="preferred-v2-seipd"/>) in a direct key self-signature indicates the preferences of the keyholder when encrypting SEIPD v2 data to the key.
An implementation that observes such a subpacket found in the unhashed section would open itself to an attack where the recipient's certificate is tampered with to encourage the use of a specific cipher or mode of operation.</t>
</section>
<section anchor="compress-bomb"><name>Malicious anchor="compress-bomb">
<name>Malicious Compressed Data</name>
<t>It is possible to form a compression quine that produces itself upon decompression, leading to infinite regress in any implementation willing to parse arbitrary numbers of layers of compression. This could cause resource exhaustion exhaustion, which itself could lead to it being terminated termination by the operating system.
<!-- [rfced] Is the text below correct, or does the operating system
"create" a report when there is a crash?
Original:
If the operating system would create a "crash report",
that report could contain confidential information.
Perhaps:
If the operating system creates a "crash report",
that report would contain confidential information.
-->
If the operating system would create a "crash report", that report could contain confidential information.</t>
<t>An OpenPGP implementation <bcp14>SHOULD</bcp14> limit the number of layers of compression it is willing to decompress in a single message.</t>
</section>
</section>
<section anchor="implementation-considerations"><name>Implementation anchor="implementation-considerations">
<name>Implementation Considerations</name>
<t>This section is a collection of comments to help an implementer, particularly with an eye to implementer who has a particular interest in backward compatibility. Often the differences are small, but small differences are frequently more vexing than large differences. Thus, this is a non-comprehensive list of potential problems and gotchas for a developer who is trying to be backward-compatible.</t>
<t><list style="symbols"> achieve backward compatibility.</t>
<ul spacing="normal">
<li>
<t>There are many ways possible ways for two keys to have the same key material, material but different fingerprints (and thus different Key IDs). For example, since a v4 fingerprint is constructed by hashing the key creation time along with other things, two v4 keys created at different times, times yet with the same key material will have different fingerprints.</t>
</li>
<li>
<t>OpenPGP does not put limits on the size of public keys.
However, larger keys are not necessarily better keys.
Larger keys take more computation time to use, and this can quickly become impractical.
Different OpenPGP implementations may also use different upper bounds for public key sizes, and so care should be taken when choosing sizes to maintain interoperability.</t>
</li>
<li>
<t>ASCII armor is an optional feature of OpenPGP.
The OpenPGP working group Working Group strives for a minimal set of mandatory-to-implement features, and since there could be useful implementations that only use binary object formats, this is not a "<bcp14>MUST</bcp14>" feature for an implementation.
For example, an implementation that is using OpenPGP as a mechanism for file signatures may find ASCII armor unnecessary.
OpenPGP permits an implementation to declare what features it does and does not support, but ASCII armor is not one of these.
Since most implementations allow binary and armored objects to be used indiscriminately, an implementation that does not implement ASCII armor may find itself with compatibility issues with general-purpose implementations.
Moreover, implementations of OpenPGP-MIME <xref target="RFC3156"/> already have a requirement for ASCII armor armor, so those implementations will necessarily have support.</t>
</li>
<li>
<t>What this document calls Legacy the "Legacy packet format <xref target="legacy-packet-format"/> format" (<xref target="legacy-packet-format"/>) is what older documents called the "old packet format".
It is the packet format used by implementations predating <xref target="RFC2440"/>.
Older RFCs called the
The current OpenPGP "OpenPGP packet format <xref target="openpgp-packet-format"/> format" (<xref target="openpgp-packet-format"/>) was called the "new packet format". format" by older RFCs. This is the format introduced in <xref target="RFC2440"/> and maintained through <xref target="RFC4880"/> to this document.</t>
</list></t>
</li>
</ul>
<section anchor="constrained-legacy-fingerprint-storage-for-v6-keys"><name>Constrained anchor="constrained-legacy-fingerprint-storage-for-v6-keys">
<name>Constrained Legacy Fingerprint Storage for v6 Keys</name>
<t>Some OpenPGP implementations have fixed length constraints for key fingerprint storage that will not fit all 32 octets of a v6 fingerprint.
For example, <xref target="OPENPGPCARD"/> reserves 20 octets for each stored fingerprint.</t>
<t>An OpenPGP implementation <bcp14>MUST NOT</bcp14> attempt to map any part of a v6 fingerprint to such a constrained field unless the relevant spec specification for the constrained environment has explicit guidance for storing a v6 fingerprint that distinguishes it from a v4 fingerprint. An implementation interacting with such a constrained field <bcp14>SHOULD</bcp14> directly calculate the v6 fingerprint from public key material and associated metadata instead of relying on the constrained field.</t>
</section>
</section>
<section anchor="iana-considerations"><name>IANA anchor="iana-considerations">
<name>IANA Considerations</name>
<!-- [rfced] We have included some specific questions about the IANA
text below. In addition to responding to those questions, please
review all of the IANA-related updates carefully and let us know
if any further updates are needed.
a) In the titles of Sections 5.2.1.1, 5.2.1.2, 5.2.1.4-5.2.1.7, and
5.2.1.11-5.2.1.13, should the signature type names be updated to
match how they appear in the "OpenPGP Signature Types" registry
(Table 4) for consistency (with the type ID following the
signature type name)? See examples in the Perhaps text below.
Also, we notice that "Signature" follows "Key Revocation", "Subkey
Revocation", and "Certification Revocation" in the titles, running
text, and a figure; however, "Signature" is not included in the
"OpenPGP Signature Types" registry. Should "Signature" be added to
these terms in the registry? If so, we will ask IANA update
accordingly <https://www.iana.org/assignments/openpgp/>.
Some examples
Original:
5.2.1.2. Signature of a canonical text document (type ID 0x01)
Perhaps:
5.2.1.2. Text Signature (type ID 0x01) of a Canonical Document
Original:
5.2.1.6. Casual certification of a User ID and Public-Key packet
(type ID 0x12)
Perhaps:
5.2.1.6. Casual Certification (type ID 0x12) of a User ID and
Public-Key Packet
Original:
5.2.1.11. Key revocation signature (type ID 0x20)
Perhaps:
5.2.1.11. Key Revocation Signature (type ID 0x20)
or
5.2.1.11. Key Revocation (type ID 0x20) Signature
...
-Table 21 (Section 9.3)-
b) Under ID 2, does "TripleDES (DES-EDE, [SP800-67]" mean
"TripleDES (or DES-EDE) [SP800-67]"? If not,
please clarify.
c) Under IDs 2, 3, and 4, are the parentheses present in the
"Algorithm" column to denote that they are different from the
descriptions for IDs 7-13? If not, can the parentheses be
removed for consistency as shown below?
Original:
2 TripleDES (DES-EDE), [SP800-67] - 168 bit key derived from 192)
3 CAST5 (128 bit key, as per [RFC2144])
4 Blowfish (128 bit key, 16 rounds)
Perhaps:
2 TripleDES (or DES-EDE) [SP800-67] with 168-bit key derived from 192
3 CAST5 with 128-bit key [RFC2144]
4 Blowfish with 128-bit key, 16 rounds [BLOWFISH]
...
d) Sections 15.2 and 15.5.1. May we arrange the registry names
in ascending order by table number (to match how the list is
ordered in Section 15.4)?
...
e) FYI: Sections 15.6.1, 15.6.2, 15.6.3.1, and 15.6.3.3. The text in
these sections suggests that the tables, rather than the registries,
should be updated when registering new items. This may cause
confusion, so we added the registry names with the corresponding
tables in parentheses, as shown in the example below.
One example
Original:
When defining a new version of OpenPGP keys or signatures, Table 27
should be updated, When a new version of OpenPGP key is defined,
Table 12 should also be updated.
Current:
When defining a new version of OpenPGP keys or signatures, the
"OpenPGP Key and Signature Versions" registry (Table 27) should
be updated. When a new version of OpenPGP key is defined, the
"OpenPGP Key ID and Fingerprint" registry (Table 12) should
also be updated.
f) Please consider whether the following registry titles should be plural.
Registry titles:
OpenPGP Secret Key Encryption (S2K Usage Octet)
OpenPGP Reason for Revocation Code
OpenPGP Key ID and Fingerprint
OpenPGP Image Attribute Version
OpenPGP Armor Header Line
OpenPGP Armor Header Key
OpenPGP ECC Curve OID and Usage
Perhaps:
OpenPGP Secret Key Encryption (S2K Usage Octets)
OpenPGP Reason for Revocation Codes
OpenPGP Key IDs and Fingerprints
OpenPGP Image Attribute Versions
OpenPGP Armor Header Lines
OpenPGP Armor Header Keys
OpenPGP ECC Curve OIDs and Usages
g) Please consider whether "Packet" should be plural in the following IANA descriptions within the "OpenPGP Packet Types" registry, as they seemingly refer to more than one ID.
Unassigned Critical Packet
Unassigned Non-Critical Packet
h) Note that we added "[RFC9580]" to entries where a reference column was provided and IANA references this document without a section number.
i) Please consider whether these table entries should be made consistent - perhaps "Private or Experimental Use"?
Private/Experimental S2K
Private or Experimental Values
Private or Experimental
Private/Experimental Use
Private or Experimental Use
Private/Experimental algorithm
j) For tables in which the reference appears in the Description column, would you like a Reference column to be added? For examples, see tables 22, 23, and 24.
-->
<t>This document obsoletes <xref target="RFC4880"/>. IANA is requested to update has updated all registration information that references <xref target="RFC4880"/> to instead reference this RFC.</t> RFC instead.</t>
<section anchor="rename-pretty-good-privacy-pgp-protocol-group-to-openpgp"><name>Rename "Pretty Good Privacy (PGP)" anchor="rename-pretty-good-privacy-pgp-protocol-group-to-openpgp">
<name>Renamed Protocol Group to "OpenPGP"</name> Group</name>
<t>IANA bundles a set of registries associated with a particular protocol into a "protocol group".
This document requests IANA to update has updated the name of the "Pretty Good Privacy (PGP)" protocol group (i.e., the group of registries described at <spanx style="verb">https://www.iana.org/assignments/pgp-parameters/</spanx>) <eref target="https://www.iana.org/assignments/pgp-parameters" brackets="angle"/>) to "OpenPGP".
If renaming the protocol group results in new URLs for the registries in this protocol group, please arrange for IANA has arranged a permanent redirection (e.g., HTTP 301) redirect from the existing URLs URL to the new URLs. URL for the registries in this protocol group. All further updates specified below are for registries within this same "OpenPGP" OpenPGP protocol group.</t>
</section>
<section anchor="registries-to-be-renamed-and-updated"><name>Registries to be Renamed anchor="registries-to-be-renamed-and-updated">
<name>Renamed and Updated</name> Updated Registries</name>
<!-- tab 1 ok -->
<t>IANA is requested to rename has renamed the "PGP String-to-Key (S2K)" registry to "OpenPGP String-to-Key (S2K) Types" and update updated its content to as shown in <xref target="s2k-types-registry"/>.</t>
<!-- tab 3 ok -->
<t>IANA is requested to rename has renamed the "PGP Packet Types/Tags" registry to "OpenPGP Packet Types" and update updated its content to as shown in <xref target="packet-types-registry"/>.</t>
<!-- tab 13 ok -->
<t>IANA is requested to rename has renamed the "PGP User Attribute Types" registry to "OpenPGP User Attribute Subpacket Types" and update updated its content to as shown in <xref target="user-attr-subpacket-types-registry"/>.</t>
<!-- tab 15 ok -->
<t>IANA is requested to rename has renamed the "Image Format Subpacket Types" registry to "OpenPGP Image Attribute Encoding Format" and update updated its content to as shown in <xref target="image-attr-encoding-format-registry"/>.</t>
<!-- tab 8 ok -->
<t>IANA is requested to rename has renamed the "Key Server Preference Extensions" registry to "OpenPGP Key Server Preference Flags" and update updated its contents to as shown in <xref target="key-server-preference-flags-registry"/>.</t>
<!-- tab 10 ok -->
<t>IANA is requested to rename has renamed the "Reason for Revocation Extensions" registry to "OpenPGP Reason for Revocation Code" and update updated its contents to as shown in <xref target="reason-for-revocation-code-registry"/>.</t>
<!-- tab 9 ok -->
<t>IANA is requested to rename has renamed the "Key Flags Extensions" registry to "OpenPGP Key Flags" and update updated its contents to as shown in <xref target="key-flags-registry"/>.</t>
<!-- tab 11 ok -->
<t>IANA is requested to rename has renamed the "Implementation Features" registry to "OpenPGP Features Flags" and update updated its contents to as shown in <xref target="features-flags-registry"/>.</t>
<!-- tab 18 ok -->
<t>IANA is requested to rename has renamed the "Public Key Algorithms" registry to "OpenPGP Public Key Algorithms" and update updated its contents to as shown in <xref target="pubkey-algo-registry"/>.</t>
<!-- tab 21 ok -->
<t>IANA is requested to rename has renamed the "Symmetric Key Algorithms" registry to "OpenPGP Symmetric Key Algorithms" and update updated its contents to as shown in <xref target="symkey-algorithms-registry"/>.</t>
<!-- tab 22 ok -->
<t>IANA is requested to rename has renamed the "Compression Algorithms" registry to "OpenPGP Compression Algorithms" and update updated its contents to as shown in <xref target="compression-algorithms-registry"/>.</t>
<!-- tab 23 ok -->
<t>IANA is requested to rename has renamed the "Hash Algorithms" registry to "OpenPGP Hash Algorithms" and update updated its contents to as shown in <xref target="hash-algorithms-registry"/>.</t>
<!-- tab 5 ok -->
<t>IANA is requested to rename has renamed the "Signature Subpacket Types" registry to "OpenPGP Signature Subpacket Types" and update updated its contents to as shown in <xref target="signature-subpacket-types-registry"/>.</t>
</section>
<section anchor="removed-registries"><name>Registries anchor="removed-registries">
<!-- [rfced] Note that we updated the text as shown below because IANA has not deleted the registry; they have marked it obsolete.
Original:
15.3. Registries to be Removed</name>
<t>IANA Removed
IANA is requested to remove the empty "New Packet Versions" registry.</t> registry.
Current:
15.3. Removed Registry
IANA has marked the empty "New Packet Versions" registry as OBSOLETE.
-->
<name>Removed Registry</name>
<t>IANA has marked the empty "New Packet Versions" registry as OBSOLETE.</t>
<t>A tombstone note should be has been added to the OpenPGP protocol group with the following content: Those content:</t>
<blockquote>Those wishing to use the removed "New Packet Versions" registry should instead register new versions of the relevant packets in the "OpenPGP Key and Signature Versions", "OpenPGP Key ID and Fingerprint" Fingerprint", and "OpenPGP Encrypted Message Packet Versions" registries.</t> registries.</blockquote>
</section>
<section anchor="added-registries"><name>Registries to be Added</name> anchor="added-registries">
<name>Added Registries</name>
<t>IANA is requested to add has added the following registries in the OpenPGP protocol group:</t>
<t><list style="symbols">
<t>OpenPGP group. Note that the initial contents of each registry is shown in the corresponding table.</t>
<ul spacing="normal">
<li>
<!-- tab 2 ok -->
<t>"OpenPGP Secret Key Encryption (S2K Usage Octet) containing <xref target="secret-key-protection-registry"/>.</t>
<t>OpenPGP Octet)" (<xref target="secret-key-protection-registry"/>).</t>
</li>
<!-- tab 4 ok -->
<li>
<t>"OpenPGP Signature Types containing <xref target="signature-types-registry"/>.</t>
<t>OpenPGP Types" (<xref target="signature-types-registry"/>).</t>
</li>
<!-- tab 6 ok -->
<li>
<t>"OpenPGP Signature Notation Data Subpacket Notation Flags containing <xref target="sig-note-data-note-flags-registry"/>.</t>
<t>OpenPGP Flags" (<xref target="sig-note-data-note-flags-registry"/>).</t>
</li>
<!-- tab 7 ok -->
<li>
<t>"OpenPGP Signature Notation Data Subpacket Types containing <xref target="sig-note-data-subpacket-types"/>.</t>
<t>OpenPGP Types" (<xref target="sig-note-data-subpacket-types"/>).</t>
</li>
<!-- tab 12 ok -->
<li>
<t>"OpenPGP Key ID and Fingerprint containing <xref target="key-id-fingerprint-registry"/>.</t>
<t>OpenPGP Fingerprint" (<xref target="key-id-fingerprint-registry"/>).</t>
</li>
<!-- tab 14 ok -->
<li>
<t>"OpenPGP Image Attribute Version containing <xref target="image-attribute-version-registry"/>.</t>
<t>OpenPGP Version" (<xref target="image-attribute-version-registry"/>).</t>
</li>
<!-- tab 16 ok -->
<li>
<t>"OpenPGP Armor Header Line containing <xref target="armor-header-line-registry"/>.</t>
<t>OpenPGP Line" (<xref target="armor-header-line-registry"/>).</t>
</li>
<!-- tab 17 ok -->
<li>
<t>"OpenPGP Armor Header Key containing <xref target="armor-header-key-registry"/>.</t>
<t>OpenPGP Key" (<xref target="armor-header-key-registry"/>).</t>
</li>
<!-- tab 19 ok -->
<li>
<t>"OpenPGP ECC Curve OID and Usage containing <xref target="ecc-oid-usage-registry"/>.</t>
<t>OpenPGP Usage" (<xref target="ecc-oid-usage-registry"/>).</t>
</li>
<!-- tab 20 ok -->
<li>
<t>"OpenPGP ECC Curve-specific Curve-Specific Wire Formats containing <xref target="ecc-wire-formats-registry"/>.</t>
<t>OpenPGP Formats" (<xref target="ecc-wire-formats-registry"/>).</t>
</li>
<!-- tab 24 ok -->
<li>
<t>"OpenPGP Hash Algorithm Identifiers for RSA Signatures use Signatures' Use of EMSA-PKCS1-v1_5 Padding containing <xref target="emsa-hash-oids-registry"/>.</t>
<t>OpenPGP Padding" (<xref target="emsa-hash-oids-registry"/>).</t>
</li>
<!-- tab 25 ok -->
<li>
<t>"OpenPGP AEAD Algorithms containing <xref target="aead-algorithms-registry"/>.</t>
<t>OpenPGP Algorithms" (<xref target="aead-algorithms-registry"/>).</t>
</li>
<!-- tab 26 ok -->
<li>
<t>"OpenPGP Encrypted Message Packet Versions containing <xref target="encrypted-packet-versions-registry"/>.</t>
<t>OpenPGP Versions" (<xref target="encrypted-packet-versions-registry"/>).</t>
</li>
<!-- tab 27 ok -->
<li>
<t>"OpenPGP Key and Signature Versions containing <xref target="signed-packet-versions-registry"/>.</t>
<t>OpenPGP Versions" (<xref target="signed-packet-versions-registry"/>).</t>
</li>
<!-- tab 28 ok -->
<li>
<t>"OpenPGP Elliptic Curve Point Wire Formats containing <xref target="ec-point-wire-formats-registry"/>.</t>
<t>OpenPGP Formats" (<xref target="ec-point-wire-formats-registry"/>).</t>
</li>
<!-- tab 29 ok -->
<li>
<t>"OpenPGP Elliptic Curve Scalar Encodings containing <xref target="ec-scalar-wire-formats-registry"/>.</t>
<t>OpenPGP Encodings" (<xref target="ec-scalar-wire-formats-registry"/>).</t>
</li>
<!-- tab 30 ok -->
<li>
<t>"OpenPGP ECDH KDF and KEK Parameters containing <xref target="ecdh-kdf-kek-parameters-registry"/>.</t>
</list></t> Parameters" (<xref target="ecdh-kdf-kek-parameters-registry"/>).</t>
</li>
</ul>
</section>
<section anchor="registration-policies"><name>Registration anchor="registration-policies">
<name>Registration Policies</name>
<t>IANA is requested to set all
<t>All registries within the OpenPGP protocol group to use the SPECIFICATION <bcp14>REQUIRED</bcp14> registration policy, see <xref section="4.6" sectionFormat="of" target="RFC8126"/> group, with the exception of the registries listed in <xref target="rfc-required-registries"/>, below. use the Specification Required registration policy; see <xref section="4.6" sectionFormat="of" target="RFC8126"/>.
This policy means that review and approval by a designated expert is required, required and that the IDs and their meanings must be documented in a permanent and readily available public specification, in sufficient detail detail, so that interoperability between independent implementations is possible.</t>
<section anchor="rfc-required-registries"><name>Registries that are anchor="rfc-required-registries">
<name>Registries That Use RFC REQUIRED</name> Required</name>
<t>The following registries use the RFC <bcp14>REQUIRED</bcp14> Required registration policy, as described in <xref section="4.7" sectionFormat="of" target="RFC8126"/>:</t>
<t><list style="symbols">
<t>OpenPGP
<ul spacing="normal">
<!-- tab 3 ok -->
<li>
<t>"OpenPGP Packet Types registry Types" (<xref target="packet-types-registry"/>)</t>
<t>OpenPGP target="packet-types-registry"/>).</t>
</li>
<!-- tab 27 ok -->
<li>
<t>"OpenPGP Key and Signature Versions registry Versions" (<xref target="signed-packet-versions-registry"/>)</t>
<t>OpenPGP target="signed-packet-versions-registry"/>).</t>
</li>
<!-- tab 12 ok -->
<li>
<t>"OpenPGP Key ID and Fingerprint registry Fingerprint" (<xref target="key-id-fingerprint-registry"/>)</t>
<t>OpenPGP target="key-id-fingerprint-registry"/>).</t>
</li>
<!-- tab 26 ok -->
<li>
<t>"OpenPGP Encrypted Message Packet Versions registry Versions" (<xref target="encrypted-packet-versions-registry"/>)</t>
</list></t> target="encrypted-packet-versions-registry"/>).</t>
</li>
</ul>
</section>
</section>
<section anchor="designated-experts"><name>Designated anchor="designated-experts">
<name>Designated Experts</name>
<t>The designated experts will determine whether the new registrations retain the security properties that are expected by the base implementation and that whether these new registrations do not cause interoperability issues with existing implementations implementations, other than not producing or consuming the IDs associated with these new registrations.
Registration proposals that fail to meet these criteria could instead be proposed as new work items for the OpenPGP working group Working Group or its successor.</t>
<t>The subsections below describe specific guidance for classes of registry updates that a designated expert will consider.</t>
<t>The designated experts should also consider <xref target="meta-considerations-for-expansion"/> when reviewing proposed additions to the OpenPGP registries.</t> protocol group.</t>
<section anchor="key-and-signature-versions"><name>Key anchor="key-and-signature-versions">
<name>Key and Signature Versions</name>
<t>When defining a new version of OpenPGP keys or signatures, <xref target="signed-packet-versions-registry"/> the "OpenPGP Key and Signature Versions" registry (<xref target="signed-packet-versions-registry"/>) should be updated, updated. When a new version of OpenPGP key is defined, <xref target="key-id-fingerprint-registry"/> the "OpenPGP Key ID and Fingerprint" registry (<xref target="key-id-fingerprint-registry"/>) should also be updated.</t>
</section>
<section anchor="encryption-versions"><name>Encryption anchor="encryption-versions">
<name>Encryption Versions</name>
<t>When defining a new version of the Symmetrically Encrypted Integrity Protected Data Packet (<xref target="seipd"/>), Public Key Encrypted Session Key Packet (<xref target="pkesk"/>), and/or Symmetric Key Encrypted Session Key Packet (<xref target="skesk"/>), the "OpenPGP Encrypted Message Packet Versions" registry from <xref target="encrypted-packet-versions-registry"/> needs to (<xref target="encrypted-packet-versions-registry"/>) should be updated. When the SEIPD is updated, consider also adding a corresponding flag to <xref target="features-flags-registry"/>.</t> the "OpenPGP Features Flags" registry (<xref target="features-flags-registry"/>).</t>
</section>
<section anchor="algorithms"><name>Algorithms</name> anchor="algorithms">
<name>Algorithms</name>
<t><xref target="constants"/> lists the cryptographic and compression algorithms that OpenPGP uses.
Adding new algorithms is usually simple, simple; in some cases as little as cases, allocating an ID and pointing to a reference. reference is only needed. But some algorithm registries require some subtle additional details when a new algorithm is introduced.</t>
<section anchor="elliptic-curve-algorithms"><name>Elliptic anchor="elliptic-curve-algorithms">
<name>Elliptic Curve Algorithms</name>
<t>To register a new elliptic curve for use with OpenPGP, its OID needs to be registered in <xref target="ecc-oid-usage-registry"/>, the "OpenPGP ECC Curve OID and Usage" registry (<xref target="ecc-oid-usage-registry"/>), its wire format needs to be documented in <xref target="ecc-wire-formats-registry"/>, the "OpenPGP ECC Curve-Specific Wire Formats" registry (<xref target="ecc-wire-formats-registry"/>), and if used for ECDH, its KDF and KEK parameters must be populated in <xref target="ecdh-kdf-kek-parameters-registry"/>. the "OpenPGP ECDH KDF and KEK Parameters" registry (<xref target="ecdh-kdf-kek-parameters-registry"/>). If the wire format(s) used are is not already defined in <xref target="ec-point-wire-formats-registry"/> the "OpenPGP Elliptic Curve Point Wire Formats" (<xref target="ec-point-wire-formats-registry"/>) or <xref target="ec-scalar-wire-formats-registry"/>, "OpenPGP Elliptic Curve Scalar Encodings" (<xref target="ec-scalar-wire-formats-registry"/>) registries, they should be defined there as well.</t>
</section>
<section anchor="symmetric-key-algorithms"><name>Symmetric-Key anchor="symmetric-key-algorithms">
<name>Symmetric-Key Algorithms</name>
<t>When registering a new symmetric cipher with a block size of 64 or 128 bits and a key size that is a multiple of 64 bits, no new considerations are needed.</t>
<t>If the new cipher has a different block size, there needs to be additional documentation describing how to use the cipher in CFB mode.</t>
<t>If the new cipher has an unusual key size, then padding needs to be considered for X25519 and X448 keywrap, key wrapping, which currently needs no padding.</t>
</section>
<section anchor="hash-algorithms"><name>Hash anchor="hash-algorithms">
<name>Hash Algorithms</name>
<t>When registering a new hash algorithm (in <xref in the "OpenPGP Hash Algorithms" registry (<xref target="hash-algorithms-registry"/>), if the algorithm is also to be used with RSA signing schemes, it must also have an entry in <xref target="emsa-hash-oids-registry"/>.</t> the "OpenPGP Hash Algorithm Identifiers for RSA Signatures' Use of EMSA-PKCS1-v1_5 Padding" registry (<xref target="emsa-hash-oids-registry"/>).</t>
</section>
</section>
</section>
</section>
</middle>
<back>
<references title='Normative References'>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="BLOWFISH" target="http://www.counterpane.com/bfsverlag.html"> target="https://www.schneier.com/academic/archives/1994/09/description_of_a_new.html">
<front>
<title>Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfish)</title>
<author initials="B." surname="Schneier">
<organization></organization>
<organization/>
</author>
<date year="1993" month="December"/>
</front>
<seriesInfo name="Fast
<refcontent>Fast Software Encryption, Cambridge Security Workshop Proceedings" value="Springer-Verlag, 1994, pp191-204"/> Proceedings, pp. 191-204</refcontent>
</reference>
<reference anchor="BZ2" target="http://www.bzip.org/">
<front>
<title>The
<!--[rfced] The title at "http:/www.bzip.org/" is "bzip2". The title
at "https://sourceware.org/bzip2/" is "bzip2 and libbzip2".
Please let us know if you prefer option A or B for this
reference entry.
Original:
[BZ2] Seward, J., "The Bzip2 and libbzip2 home page</title>
<author initials="J." surname="Seward" fullname="Julian Seward, jseward@acm.org">
<organization></organization> page", 2010,
<http://www.bzip.org/>.
Perhaps:
A) [BZ2] bzip2, "bzip2", 2010,
<http://http://www.bzip.org//>.
or
B) [BZ2] bzip2, "bzip2 and libbzip2", 2010,
<https://sourceware.org/bzip2/>.
-->
<reference anchor="BZ2" target="http://www.bzip.org/">
<front>
<title>bzip2</title>
<author>
<organization>bzip2</organization>
</author>
<date year="2010"/>
</front>
</reference>
<reference anchor="EAX" target="https://seclab.cs.ucdavis.edu/papers/eax.pdf">
<front>
<title>A Conventional Authenticated-Encryption Mode</title>
<author initials="M." surname="Bellare">
<organization></organization>
<organization/>
</author>
<author initials="P." surname="Rogaway">
<organization></organization>
<organization/>
</author>
<author initials="D." surname="Wagner">
<organization></organization>
<organization/>
</author>
<date year="2003" month="April"/>
</front>
</reference>
<reference anchor="ELGAMAL" > anchor="ELGAMAL">
<front>
<title>A Public-Key Public Key Cryptosystem and a Signature Scheme Based on Discrete Logarithms</title>
<author initials="T." surname="Elgamal">
<organization></organization>
<organization/>
</author>
<date month="July" year="1985"/>
</front>
<seriesInfo name="IEEE name="DOI" value="10.1109/TIT.1985.1057074"/>
<refcontent>IEEE Transactions on Information Theory" value="v. IT-31, n. Theory, Vol. 31, Issue 4, 1985, pp. 469-472"/> 469-472</refcontent>
</reference>
<reference anchor="IDEA" > anchor="IDEA">
<front>
<title>On the design Design and security Security of block ciphers</title> Block Ciphers</title>
<author initials="X." surname="Lai">
<organization></organization>
<organization/>
</author>
<date month="January" year="1992"/>
</front>
<seriesInfo name="ETH
<refcontent>ETH Series in Information Processing, J.L. Massey (editor)" value="Vol. Vol. 1, Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich)"/> (Zurich), Dissertation</refcontent>
</reference>
<reference anchor="ISO10646" target="https://www.iso.org/standard/76835.html">
<front>
<title>Information
<!--[rfced] FYI: The most current version of this reference is
"ISO/IEC 10646:2020". We updated the title and document
number to match the information at
"https://www.iso.org/standard/76835.html" as shown below.
Please let us know of any objections.
Original:
[ISO10646] International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Part 1: Architecture and Basic
Multilingual Plane</title>
<author >
<organization>International Organization for Standardization</organization> Plane", ISO Standard 10646-1, 2020,
<https://www.iso.org/standard/76835.html>.
Current:
[ISO10646] ISO, "Information technology - Universal coded
character set (UCS)", ISO/IEC 10646:2020,
December 2020, <https://www.iso.org/standard/76835.html>.
-->
<reference anchor="ISO10646" target="https://www.iso.org/standard/76835.html">
<front>
<title>Information technology - Universal coded character set (UCS)</title>
<author>
<organization>ISO</organization>
</author>
<date month="December" year="2020"/>
</front>
<seriesInfo name="ISO" value="Standard 10646-1"/> name="ISO/IEC" value="10646:2020"/>
</reference>
<reference anchor="JFIF" target="https://www.itu.int/rec/T-REC-T.871-201105-I">
<front>
<title>Information technology – - Digital compression and coding of continuous-tone still images: JPEG File Interchange Format (JFIF)</title>
<author >
<organization>International Telecommunication Union</organization>
<author>
<organization>ITU-T</organization>
</author>
<date year="2011" month="May" day="14"/> month="May"/>
</front>
<seriesInfo name="ISO" value="ISO/IEC 10918-5"/>
</reference>
<reference anchor='RFC1321'>
<front>
<title>The MD5 Message-Digest Algorithm</title>
<author fullname='R. Rivest' initials='R.' surname='Rivest'/>
<date month='April' year='1992'/>
<abstract>
<t>This document describes the MD5 message-digest algorithm. name="Recommendation" value="ITU-T T.871"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1321.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1951.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2144.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2822.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2898.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3156.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3394.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3629.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3713.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5322.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8017.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9106.xml"/>
<!--[rfced] The algorithm takes as input a message of arbitrary length following reference has been withdrawn and produces as output replaced
with a 128-bit "fingerprint" or "message digest" of newer version (see "https://www.iso.org/standard/67116.html").
Would you like to point to the input. This memo provides information 10118-3:2018 version as shown below?
Original:
[RIPEMD-160]
International Organization for the Internet community. It does not specify an Internet standard.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='1321'/>
<seriesInfo name='DOI' value='10.17487/RFC1321'/>
</reference> Standardization, Geneva,
Switzerland, "Information technology - Security techniques
- Hash-functions - Part 3: Dedicated hash-functions,",
ISO ISO/IEC 10118-3, 1998.
Perhaps:
[RIPEMD-160]
ISO, "Information technology - IT Security techniques
- Hash-functions - Part 3: Dedicated hash-functions",
ISO/IEC 10118-3:2018, October 2018.
-->
<reference anchor='RFC1950'> anchor="RIPEMD-160">
<front>
<title>ZLIB Compressed Data Format Specification version 3.3</title>
<author fullname='P. Deutsch' initials='P.' surname='Deutsch'/>
<author fullname='J-L. Gailly' surname='J-L. Gailly'/>
<title>Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions</title>
<author>
<organization>ISO</organization>
</author>
<date month='May' year='1996'/>
<abstract>
<t>This specification defines a lossless compressed data format. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
</abstract> year="1998"/>
</front>
<seriesInfo name='RFC' value='1950'/>
<seriesInfo name='DOI' value='10.17487/RFC1950'/> name="ISO/IEC" value="10118-3"/>
</reference>
<reference anchor='RFC1951'> anchor="SP800-38A" target="https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38a.pdf">
<front>
<title>DEFLATE Compressed Data Format Specification version 1.3</title>
<author fullname='P. Deutsch' initials='P.' surname='Deutsch'/>
<date month='May' year='1996'/>
<abstract>
<t>This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods. This memo provides information
<title>Recommendation for the Internet community. This memo does not specify an Internet standard Block Cipher Modes of any kind.</t>
</abstract> Operation: Methods and Techniques</title>
<author>
<organization>NIST</organization>
</author>
<date year="2001" month="December"/>
</front>
<seriesInfo name='RFC' value='1951'/> name="NIST Special Publication" value="800-38A"/>
<seriesInfo name='DOI' value='10.17487/RFC1951'/> name="DOI" value="10.6028/NIST.SP.800-38A"/>
</reference>
<reference anchor='RFC2144'> anchor="SP800-38D" target="https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-38d.pdf">
<front>
<title>The CAST-128 Encryption Algorithm</title>
<author fullname='C. Adams' initials='C.' surname='Adams'/>
<date month='May' year='1997'/>
<abstract>
<t>There is a need in the Internet community for an unencumbered encryption algorithm with a range of key sizes that can provide security
<title>Recommendation for a variety Block Cipher Modes of cryptographic applications Operation: Galois/Counter Mode (GCM) and protocols. This document describes an existing algorithm that can be used to satisfy this requirement. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind.</t>
</abstract> GMAC</title>
<author>
<organization>NIST</organization>
</author>
<date year="2007" month="November"/>
</front>
<seriesInfo name='RFC' value='2144'/> name="NIST Special Publication" value="800-38D"/>
<seriesInfo name='DOI' value='10.17487/RFC2144'/> name="DOI" value="10.6028/NIST.SP.800-38D"/>
</reference>
<!--[rfced] The following reference has been withdrawn and replaced with
a newer version (see "https://csrc.nist.gov/pubs/sp/800/56/a/r3/final").
Would you like to point to the 800-56A Revision 3 version as shown below?
Original:
[SP800-56A]
Barker, E., Johnson, D., and M. Smid, "Recommendation for
Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography", NIST Special Publication 800-56A
Revision 1, March 2007.
Perhaps:
[SP800-56A]
NIST, "Recommendation for Pair-Wise Key Establishment Schemes
Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A Revision 3, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
nist.sp.800-56Ar3.pdf>
-->
<reference anchor='RFC2822'> anchor="SP800-56A">
<front>
<title>Internet Message Format</title>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'/>
<date month='April' year='2001'/>
<abstract>
<t>This document specifies a syntax
<title>Recommendation for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]</t>
</abstract> Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title>
<author>
<organization>NIST</organization>
</author>
<date year="2007" month="March"/>
</front>
<seriesInfo name='RFC' value='2822'/> name="NIST Special Publication" value="800-56A Revision 1"/>
<seriesInfo name='DOI' value='10.17487/RFC2822'/> name="DOI" value="10.6028/NIST.SP.800-56Ar"/>
</reference>
<!-- Updated REF:
<reference anchor='RFC2898'> anchor="SP800-56A">
<front>
<title>PKCS #5: Password-Based Cryptography Specification Version 2.0</title>
<author fullname='B. Kaliski' initials='B.' surname='Kaliski'/>
<date month='September' year='2000'/>
<abstract>
<t>This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message-authentication schemes, and ASN.1 syntax identifying the techniques. This memo provides information
<title>Recommendation for the Internet community.</t>
</abstract> Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography</title>
<author>
<organization>NIST</organization>
</author>
<date year="2018" month="April"/>
</front>
<seriesInfo name='RFC' value='2898'/> name="NIST Special Publication" value="800-56A Revision 3"/>
<seriesInfo name='DOI' value='10.17487/RFC2898'/> name="DOI" value="10.6028/NIST.SP"/>
</reference>
<reference anchor='RFC3156'>
<front>
<title>MIME Security with OpenPGP</title>
<author fullname='M. Elkins' initials='M.' surname='Elkins'/>
<author fullname='D. Del Torto' initials='D.' surname='Del Torto'/>
<author fullname='R. Levien' initials='R.' surname='Levien'/>
<author fullname='T. Roessler' initials='T.' surname='Roessler'/>
<date month='August' year='2001'/>
<abstract>
<t>This document describes how
-->
<!-- [rfced] The following reference was withdrawn in January
2024, and it does not appear to have a replacement (see the OpenPGP Message Format can be used
withdrawal announcement at
"https://csrc.nist.gov/news/2023/nist-to-withdraw-sp-800-67-rev-2").
Please confirm if you would like to provide privacy and authentication using leave this reference as is, note
that it is 'withdrawn', or point to another reference.
Original:
[SP800-67] NIST, "Recommendation for the Multipurpose Internet Mail Extensions (MIME) security content types described in RFC 1847. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='3156'/>
<seriesInfo name='DOI' value='10.17487/RFC3156'/>
</reference> Triple Data Encryption
Algorithm (TDEA) Block Cipher", NIST Special
Publication 800-67 Rev. 2, DOI 10.6028/NIST.SP.800-67r2,
November 2017, <https://doi.org/10.6028/NIST.SP.800-67r2>.
-->
<reference anchor='RFC3394'> anchor="SP800-67" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-67r2.pdf">
<front>
<title>Advanced
<title>Recommendation for the Triple Data Encryption Standard (AES) Key Wrap Algorithm</title>
<author fullname='J. Schaad' initials='J.' surname='Schaad'/>
<author fullname='R. Housley' initials='R.' surname='Housley'/> Algorithm (TDEA) Block Cipher</title>
<author>
<organization>NIST</organization>
</author>
<date month='September' year='2002'/> year="2017" month="November"/>
</front>
<seriesInfo name='RFC' value='3394'/> name="NIST Special Publication" value="800-67 Rev. 2"/>
<seriesInfo name='DOI' value='10.17487/RFC3394'/> name="DOI" value="10.6028/NIST.SP.800-67r2"/>
</reference>
<reference anchor='RFC3629'> anchor="TWOFISH" target="https://www.schneier.com/wp-content/uploads/2016/02/paper-twofish-paper.pdf">
<front>
<title>UTF-8, a transformation format of ISO 10646</title>
<author fullname='F. Yergeau' initials='F.' surname='Yergeau'/>
<date month='November' year='2003'/>
<abstract>
<t>ISO/IEC 10646-1 defines a large character set called the Universal Character Set (UCS) which encompasses most of the world's writing systems. The originally proposed encodings of the UCS, however, were not compatible with many current applications and protocols, and this has led to the development of UTF-8, the object of this memo. UTF-8 has the characteristic of preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values. This memo obsoletes and replaces RFC 2279.</t>
</abstract>
</front>
<seriesInfo name='STD' value='63'/>
<seriesInfo name='RFC' value='3629'/>
<seriesInfo name='DOI' value='10.17487/RFC3629'/>
</reference>
<reference anchor='RFC3713'>
<front>
<title>A Description of the Camellia Encryption Algorithm</title>
<author fullname='M. Matsui' initials='M.' surname='Matsui'/>
<author fullname='J. Nakajima' initials='J.' surname='Nakajima'/>
<author fullname='S. Moriai' initials='S.' surname='Moriai'/>
<date month='April' year='2004'/>
<abstract>
<t>This document describes the Camellia encryption algorithm. Camellia is a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The algorithm description is presented together with key scheduling part and data randomizing part. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='3713'/>
<seriesInfo name='DOI' value='10.17487/RFC3713'/>
</reference>
<reference anchor='RFC4086'>
<front>
<title>Randomness Requirements for Security</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'/>
<author fullname='J. Schiller' initials='J.' surname='Schiller'/>
<author fullname='S. Crocker' initials='S.' surname='Crocker'/>
<date month='June' year='2005'/>
<abstract>
<t>Security systems are built on strong cryptographic algorithms that foil pattern analysis attempts. However, the security of these systems is dependent on generating secret quantities for passwords, cryptographic keys, and similar quantities. The use of pseudo-random processes to generate secret quantities can result in pseudo-security. A sophisticated attacker may find it easier to reproduce the environment that produced the secret quantities and to search the resulting small set of possibilities than to locate the quantities in the whole of the potential number space.</t>
<t>Choosing random quantities to foil a resourceful and motivated adversary is surprisingly difficult. This document points out many pitfalls in using poor entropy sources or traditional pseudo-random number generation techniques for generating such quantities. It recommends the use of truly random hardware techniques and shows that the existing hardware on many systems can be used for this purpose. It provides suggestions to ameliorate the problem when a hardware solution is not available, and it gives examples of how large such quantities need to be for some applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='106'/>
<seriesInfo name='RFC' value='4086'/>
<seriesInfo name='DOI' value='10.17487/RFC4086'/>
</reference>
<reference anchor='RFC4648'>
<front>
<title>The Base16, Base32, and Base64 Data Encodings</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'/>
<date month='October' year='2006'/>
<abstract>
<t>This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='4648'/>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>
<reference anchor='RFC5322'>
<front>
<title>Internet Message Format</title>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'/>
<date month='October' year='2008'/>
<abstract>
<t>This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5322'/>
<seriesInfo name='DOI' value='10.17487/RFC5322'/>
</reference>
<reference anchor='RFC6234'>
<front>
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title>
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'/>
<author fullname='T. Hansen' initials='T.' surname='Hansen'/>
<date month='May' year='2011'/>
<abstract>
<t>Federal Information Processing Standard, FIPS</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6234'/>
<seriesInfo name='DOI' value='10.17487/RFC6234'/>
</reference>
<reference anchor='RFC7253'>
<front>
<title>The OCB Authenticated-Encryption Algorithm</title>
<author fullname='T. Krovetz' initials='T.' surname='Krovetz'/>
<author fullname='P. Rogaway' initials='P.' surname='Rogaway'/>
<date month='May' year='2014'/>
<abstract>
<t>This document specifies OCB, a shared-key blockcipher-based encryption scheme that provides confidentiality and authenticity for plaintexts and authenticity for associated data. This document is a product of the Crypto Forum Research Group (CFRG).</t>
</abstract>
</front>
<seriesInfo name='RFC' value='7253'/>
<seriesInfo name='DOI' value='10.17487/RFC7253'/>
</reference>
<reference anchor='RFC7748'>
<front>
<title>Elliptic Curves for Security</title>
<author fullname='A. Langley' initials='A.' surname='Langley'/>
<author fullname='M. Hamburg' initials='M.' surname='Hamburg'/>
<author fullname='S. Turner' initials='S.' surname='Turner'/>
<date month='January' year='2016'/>
<abstract>
<t>This memo specifies two elliptic curves over prime fields that offer a high level of practical security in cryptographic applications, including Transport Layer Security (TLS). These curves are intended to operate at the ~128-bit and ~224-bit security level, respectively, and are generated deterministically based on a list of required properties.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='7748'/>
<seriesInfo name='DOI' value='10.17487/RFC7748'/>
</reference>
<reference anchor='RFC8017'>
<front>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title>
<author fullname='K. Moriarty' initials='K.' role='editor' surname='Moriarty'/>
<author fullname='B. Kaliski' initials='B.' surname='Kaliski'/>
<author fullname='J. Jonsson' initials='J.' surname='Jonsson'/>
<author fullname='A. Rusch' initials='A.' surname='Rusch'/>
<date month='November' year='2016'/>
<abstract>
<t>This document provides recommendations for the implementation of public-key cryptography based on the RSA algorithm, covering cryptographic primitives, encryption schemes, signature schemes with appendix, and ASN.1 syntax for representing keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF.</t>
<t>This document also obsoletes RFC 3447.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='8017'/>
<seriesInfo name='DOI' value='10.17487/RFC8017'/>
</reference>
<reference anchor='RFC8032'>
<front>
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'/>
<author fullname='I. Liusvaara' initials='I.' surname='Liusvaara'/>
<date month='January' year='2017'/>
<abstract>
<t>This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='8032'/>
<seriesInfo name='DOI' value='10.17487/RFC8032'/>
</reference>
<reference anchor='RFC8126'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname='M. Cotton' initials='M.' surname='Cotton'/>
<author fullname='B. Leiba' initials='B.' surname='Leiba'/>
<author fullname='T. Narten' initials='T.' surname='Narten'/>
<date month='June' year='2017'/>
<abstract>
<t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 5226.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='26'/>
<seriesInfo name='RFC' value='8126'/>
<seriesInfo name='DOI' value='10.17487/RFC8126'/>
</reference>
<reference anchor='RFC9106'>
<front>
<title>Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications</title>
<author fullname='A. Biryukov' initials='A.' surname='Biryukov'/>
<author fullname='D. Dinu' initials='D.' surname='Dinu'/>
<author fullname='D. Khovratovich' initials='D.' surname='Khovratovich'/>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'/>
<date month='September' year='2021'/>
<abstract>
<t>This document describes the Argon2 memory-hard function for password hashing and proof-of-work applications. We provide an implementer-oriented description with test vectors. The purpose is to simplify adoption of Argon2 for Internet protocols. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='9106'/>
<seriesInfo name='DOI' value='10.17487/RFC9106'/>
</reference>
<reference anchor="RIPEMD-160" >
<front>
<title>Information technology - Security techniques - Hash-functions - Part 3: Dedicated hash-functions,</title>
<author >
<organization>International Organization for Standardization, Geneva, Switzerland</organization>
</author>
<date year="1998"/>
</front>
<seriesInfo name="ISO" value="ISO/IEC 10118-3"/>
</reference>
<reference anchor="SP800-38A" >
<front>
<title>Recommendation for Block Cipher Modes of Operation: Methods and Techniques</title>
<author initials="M." surname="Dworkin">
<organization></organization>
</author>
<date year="2001" month="December"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-38A"/>
</reference>
<reference anchor="SP800-38D" >
<front>
<title>Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC</title>
<author initials="M." surname="Dworkin">
<organization></organization>
</author>
<date year="2007" month="November"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-38D"/>
</reference>
<reference anchor="SP800-56A" >
<front>
<title>Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography</title>
<author initials="E." surname="Barker">
<organization></organization>
</author>
<author initials="D." surname="Johnson">
<organization></organization>
</author>
<author initials="M." surname="Smid">
<organization></organization>
</author>
<date year="2007" month="March"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-56A Revision 1"/>
</reference>
<reference anchor="SP800-67" target="https://doi.org/10.6028/NIST.SP.800-67r2">
<front>
<title>Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher</title>
<author >
<organization>NIST</organization>
</author>
<date year="2017" month="November"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-67 Rev. 2"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-67r2"/>
</reference>
<reference anchor="TWOFISH" target="https://www.schneier.com/wp-content/uploads/2016/02/paper-twofish-paper.pdf">
<front>
<title>The Twofish Encryption Algorithm</title>
<title>Twofish: A 128-Bit Block Cipher</title>
<author initials="B." surname="Schneier">
<organization></organization>
<organization/>
</author>
<author initials="J." surname="Kelsey">
<organization></organization>
<organization/>
</author>
<author initials="D." surname="Whiting">
<organization></organization>
<organization/>
</author>
<author initials="D." surname="Wagner">
<organization></organization>
<organization/>
</author>
<author initials="C." surname="Hall">
<organization></organization>
<organization/>
</author>
<author initials="N." surname="Ferguson">
<organization></organization>
<organization/>
</author>
<date year="1999"/>
</front>
</reference>
<reference anchor='RFC2119'>
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname='S. Bradner' initials='S.' surname='Bradner'/>
<date month='March' year='1997'/>
<abstract>
<t>In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>
<reference anchor='RFC8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'/>
<date month='May' year='2017'/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract> month="June" year="1998"/>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<reference anchor='FIPS186'> anchor="FIPS186" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-5.pdf">
<front>
<title>Digital Signature Standard (DSS)</title>
<author fullname='Lily Chen' initials='L.' surname='Chen'>
<organization/>
</author>
<author fullname='Dustin Moody' initials='D.' surname='Moody'>
<organization/>
</author>
<author fullname='Andrew Regenscheid' initials='A.' surname='Regenscheid'>
<organization/>
</author>
<author fullname='Angela Robinson' initials='A.' surname='Robinson'>
<organization/>
<author>
<organization>NIST</organization>
</author>
<date month='February' year='2023'/> month="February" year="2023"/>
</front>
<seriesInfo name='National Institute of Standards and Technology (U.S.)' value='report'/> name="FIPS PUB" value="186-5"/>
<seriesInfo name='DOI' value='10.6028/nist.fips.186-5'/> name="DOI" value="10.6028/NIST.FIPS.186-5"/>
</reference>
<reference anchor='AES'> anchor="AES" target="https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.197-upd1.pdf">
<front>
<title>Advanced encryption standard Encryption Standard (AES)</title>
<author>
<organization/>
<organization>NIST</organization>
</author>
<date month='November' year='2001'/> month="November" year="2001"/>
</front>
<seriesInfo name='National Institute of Standards and Technology' value='report'/> name="FIPS PUB" value="197"/>
<seriesInfo name='DOI' value='10.6028/nist.fips.197'/> name="DOI" value="10.6028/NIST.FIPS.197-upd1"/>
<refcontent>Updated May 2023</refcontent>
</reference>
<reference anchor='FIPS180'> anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.180-4.pdf">
<front>
<title>Secure Hash Standard</title>
<author fullname='Quynh H. Dang' initials='Q.' surname='Dang'>
<organization/> Standard (SHS)</title>
<author>
<organization>NIST</organization>
</author>
<date month='July' year='2015'/> month="August" year="2015"/>
</front>
<seriesInfo name='National Institute of Standards and Technology' value='report'/> name="FIPS PUB" value="180-4"/>
<seriesInfo name='DOI' value='10.6028/nist.fips.180-4'/> name="DOI" value="10.6028/NIST.FIPS.180-4"/>
</reference>
<reference anchor='FIPS202'> anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.202.pdf">
<front>
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions</title>
<author fullname='Morris J. Dworkin' initials='M.' surname='Dworkin'>
<organization/>
<author>
<organization>NIST</organization>
</author>
<date month='July' year='2015'/> month="August" year="2015"/>
</front>
<seriesInfo name='National Institute of Standards and Technology' value='report'/> name="FIPS PUB" value="202"/>
<seriesInfo name='DOI' value='10.6028/nist.fips.202'/> name="DOI" value="10.6028/NIST.FIPS.202"/>
</reference>
</references>
<references title='Informative References'>
<references>
<name>Informative References</name>
<reference anchor="BLEICHENBACHER" > anchor="BLEICHENBACHER">
<front>
<title>Generating ElGamal Signatures Without Knowing the Secret Key</title>
<author initials="D." surname="Bleichenbacher">
<organization></organization>
<organization/>
</author>
<date month="May" year="1996"/>
</front>
<seriesInfo name="Lecture Notes in Computer Science" value="Volume
<refcontent>EUROCRYPT'96: International Conference on the Theory and Applications of Cryptographic Techniques Proceedings, Vol. 1070, pp. 10-18"/> 10-18</refcontent>
</reference>
<reference anchor="BLEICHENBACHER-PKCS1" target="http://archiv.infsec.ethz.ch/education/fs08/secsem/Bleichenbacher98.pdf">
<front>
<title>Chosen Ciphertext Attacks Against Protocols Based on the RSA Encryption Standard PKCS \#1</title> #1</title>
<author initials="D." surname="Bleichenbacher">
<organization></organization>
<organization/>
</author>
<date month="August" year="1998"/>
</front>
<refcontent>CRYPTO '98: International Cryptology Conference Proceedings, Vol. 1462, pp. 1-12</refcontent>
</reference>
<reference anchor="C99" target="https://www.iso.org/standard/50510.html">
<front>
<title>Programming
<!-- [rfced] The following reference has been withdrawn and replaced with
a newer version (see "https://www.iso.org/standard/74528.html").
Would you like to point to the ISO/IEC 9899:2018 version as shown
below?
Original:
[C99] Standardization, I. O. for., "Programming languages - C:
C99, correction 3:2007, ISO/IEC 9899:1999/Cor 3:2007</title>
<author initials="I. O. for" surname="Standardization" fullname="International Organization for Standardization">
<organization></organization> 3:2007",
November 2007, <https://www.iso.org/standard/50510.html>.
Perhaps:
[C99] ISO, "Information technology - Programming languages: C",
ISO/IEC 9899:2018, June 2018,
<https://www.iso.org/standard/74528.html>.
-->
<reference anchor="C99" target="https://www.iso.org/standard/50510.html">
<front>
<title>Programming languages - C: Technical Corrigendum 3</title>
<author>
<organization>ISO</organization>
</author>
<date year="2007" month="November"/>
</front>
<seriesInfo name="ISO/IEC" value="9899:1999/Cor3:2007"/>
</reference>
<reference anchor="EFAIL" target="https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-poddebniak.pdf">
<front>
<title>Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels</title>
<author initials="D." surname="Poddebniak" fullname="Damian Poddebniak">
<organization></organization>
<organization/>
</author>
<author initials="C." surname="Dresen" fullname="Christian Dresen">
<organization></organization>
<organization/>
</author>
<author initials="J." surname="Müller" fullname="Jens Müller">
<organization></organization>
<organization/>
</author>
<author initials="F." surname="Ising" fullname="Fabian Ising">
<organization></organization>
<organization/>
</author>
<author initials="S." surname="Schinzel" fullname="Sebastian Schinzel">
<organization></organization>
<organization/>
</author>
<author initials="S." surname="Friedberger" fullname="Simon Friedberger">
<organization></organization>
<organization/>
</author>
<author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
<organization></organization>
<organization/>
</author>
<author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
<organization></organization>
<organization/>
</author>
<date month="August" year="2018"/>
</front>
<seriesInfo name="Proceedings
<refcontent>Proceedings of the 27th USENIX Conference on Security Symposium, August 2018, Pages 549–566" value=""/> Symposium</refcontent>
</reference>
<reference anchor="Errata-2199" quote-title="false" target="https://www.rfc-editor.org/errata/eid2199">
<front>
<title>Errata Report 2199 - S2K hash/cipher octet correction</title>
<author >
<organization></organization>
<title>Erratum ID 2199</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2200" quote-title="false" target="https://www.rfc-editor.org/errata/eid2200">
<front>
<title>Errata Report 2200 - No implicit use of IDEA correction</title>
<author >
<organization></organization>
<title>Erratum ID 2200</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2206" quote-title="false" target="https://www.rfc-editor.org/errata/eid2206">
<front>
<title>Errata Report 2206 - PKESK acronym expansion</title>
<author >
<organization></organization>
<title>Erratum ID 2206</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2208" quote-title="false" target="https://www.rfc-editor.org/errata/eid2208">
<front>
<title>Errata Report 2208 - Signature key owner clarification</title>
<author >
<organization></organization>
<title>Erratum ID 2208</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2214" quote-title="false" target="https://www.rfc-editor.org/errata/eid2214">
<front>
<title>Errata Report 2214 - Signature hashing clarification</title>
<author >
<organization></organization>
<title>Erratum ID 2214</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2216" quote-title="false" target="https://www.rfc-editor.org/errata/eid2216">
<front>
<title>Errata Report 2216 - Self signature applies to user
<title>Erratum ID correction</title>
<author >
<organization></organization> 2216</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2219" quote-title="false" target="https://www.rfc-editor.org/errata/eid2219">
<front>
<title>Errata Report 2219 - Session key encryption storage clarification</title>
<author >
<organization></organization>
<title>Erratum ID 2219</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2222" quote-title="false" target="https://www.rfc-editor.org/errata/eid2222">
<front>
<title>Errata Report 2222 - Simple hash MUST/MAY clarification</title>
<title>Erratum ID 2222</title>
<author >
<organization></organization>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2226" quote-title="false" target="https://www.rfc-editor.org/errata/eid2226">
<front>
<title>Errata Report 2226 - Native line endings SHOULD clarification</title>
<title>Erratum ID 2226</title>
<author >
<organization></organization>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2234" quote-title="false" target="https://www.rfc-editor.org/errata/eid2234">
<front>
<title>Errata Report 2234 - Radix-64 / base64 clarification</title>
<title>Erratum ID 2234</title>
<author >
<organization></organization>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2235" quote-title="false" target="https://www.rfc-editor.org/errata/eid2235">
<front>
<title>Errata Report 2235 - ASCII / UTF-8 collation sequence clarification</title>
<title>Erratum ID 2235</title>
<author >
<organization></organization>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2236" quote-title="false" target="https://www.rfc-editor.org/errata/eid2236">
<front>
<title>Errata Report 2236 - Packet Composition is a sequence clarification</title>
<author >
<organization></organization>
<title>Erratum ID 2236</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2238" quote-title="false" target="https://www.rfc-editor.org/errata/eid2238">
<front>
<title>Errata Report 2238 - Subkey packets come after all User
<title>Erratum ID packets clarification</title>
<author >
<organization></organization> 2238</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2240" quote-title="false" target="https://www.rfc-editor.org/errata/eid2240">
<front>
<title>Errata Report 2240 - Subkey removal clarification</title>
<author >
<organization></organization>
<title>Erratum ID 2240</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2242" quote-title="false" target="https://www.rfc-editor.org/errata/eid2242">
<front>
<title>Errata Report 2242 - mL / emLen variable correction</title>
<title>Erratum ID 2242</title>
<author >
<organization></organization>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2243" quote-title="false" target="https://www.rfc-editor.org/errata/eid2243">
<front>
<title>Errata Report 2243 - CFB mode initialization vector (IV) clarification</title>
<author >
<organization></organization>
<title>Erratum ID 2243</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2270" quote-title="false" target="https://www.rfc-editor.org/errata/eid2270">
<front>
<title>Errata Report 2270 - SHA-224 octet sequence correction</title>
<author >
<organization></organization>
<title>Erratum ID 2270</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-2271" quote-title="false" target="https://www.rfc-editor.org/errata/eid2271">
<front>
<title>Errata Report 2271 - Radix-64 correction</title>
<title>Erratum ID 2271</title>
<author >
<organization></organization>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-3298" quote-title="false" target="https://www.rfc-editor.org/errata/eid3298">
<front>
<title>Errata Report 3298 - Key revocation signatures correction</title>
<author >
<organization></organization>
<title>Erratum ID 3298</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-5491" quote-title="false" target="https://www.rfc-editor.org/errata/eid5491">
<front>
<title>Errata Report 5491 - C code fix for CRC24_POLY define</title>
<author >
<organization></organization>
<title>Erratum ID 5491</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="Errata-7545" quote-title="false" target="https://www.rfc-editor.org/errata/eid7545">
<front>
<title>Errata Report 7545 - Armor Header colon hex fix</title>
<author >
<organization></organization>
<title>Erratum ID 7545</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<seriesInfo name="RFC" value="4880"/>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="HASTAD" > anchor="Errata-7889" quote-title="false" target="https://www.rfc-editor.org/errata/eid7889">
<front>
<title>Erratum ID 7889</title>
<author>
<organization>RFC Errata</organization>
</author>
<date />
</front>
<refcontent>RFC 4880</refcontent>
</reference>
<reference anchor="HASTAD">
<front>
<title>Solving Simultaneous Modular Equations of Low Degree</title>
<author initials="J." surname="Hastad" fullname="Johan Hastad">
<organization></organization>
<organization/>
</author>
<date month="April" year="1988"/>
</front>
<seriesInfo name="DOI" value="10.1137/0217019"/>
</reference>
<reference anchor="JKS02" target="http://www.counterpane.com/pgp-attack.html"> target="https://www.schneier.com/academic/archives/2002/01/implementation_of_ch.html">
<front>
<title>Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG</title>
<author initials="K." surname="Jallad" fullname="Kahil Jallad">
<organization></organization>
<organization/>
</author>
<author initials="J." surname="Katz" fullname="Jonathan Katz">
<organization></organization>
<organization/>
</author>
<author initials="B." surname="Schneier" fullname="Bruce Schneier">
<organization></organization>
<organization/>
</author>
<date month="September" year="2002"/>
</front>
<seriesInfo name="DOI" value="0.1007/3-540-45811-5_7"/>
</reference>
<reference anchor="KOBLITZ" > anchor="KOBLITZ">
<front>
<title>A course in number theory and cryptography, Chapter VI. Elliptic Curves</title> cryptography</title>
<author initials="N." surname="Koblitz">
<organization></organization>
<organization/>
</author>
<date year="1997"/>
</front>
<seriesInfo name="ISBN" value="0-387-96576-9"/> name="DOI" value="10.2307/3618498"/>
<refcontent>Chaper VI: Elliptic Curves</refcontent>
</reference>
<!-- [rfced] The URL that was provided for the reference below links
to an article titled "Key Overwriting (KO) Attacks against
OpenPGP" (see "https://www.kopenpgp.com/"). We updated the URL to
point to a document with the original title "Victory by KO:
Attacking OpenPGP Using Key Overwriting" (see
"https://dl.acm.org/doi/10.1145/3548606.3559363"). If this update
is not correct, please let us know.
Current:
[KOPENPGP] Bruseghini, L., Paterson, K. G., and D. Huigens, "Victory
by KO: Attacking OpenPGP Using Key Overwriting",
Proceedings of the ACM SIGSAC Conference on Computer and
Communications Security, pp. 411-423, November 2022,
<https://dl.acm.org/doi/10.1145/3548606.3559363/>.
-->
<reference anchor="KOPENPGP" target="https://www.kopenpgp.com/"> target="https://dl.acm.org/doi/10.1145/3548606.3559363">
<front>
<title>Victory by KO: Attacking OpenPGP Using Key Overwriting</title>
<author initials="L." surname="Bruseghini" fullname="Lara Bruseghini">
<organization></organization>
<organization/>
</author>
<author initials="K. G." surname="Paterson" fullname="Kenneth G. Paterson">
<organization></organization>
<organization/>
</author>
<author initials="D." surname="Huigens" fullname="Daniel Huigens">
<organization></organization>
<organization/>
</author>
<date month="November" year="2022"/>
</front>
<seriesInfo name="Proceedings name="DOI" value="10.1145/3548606.3559363"/>
<refcontent>Proceedings of the 29th ACM SIGSAC Conference on Computer and Communications Security, November 2022 (to appear)" value=""/> pp. 411-423</refcontent>
</reference>
<reference anchor="KR02" target="https://eprint.iacr.org/2002/076">
<front>
<title>Attack on Private Signature Keys of the OpenPGP Format, PGP(TM) Programs and Other Applications Compatible with OpenPGP</title>
<author initials="V." surname="Klíma" fullname="Vlastimil Klíma">
<organization></organization>
<organization/>
</author>
<author initials="T." surname="Rosa" fullname="Tomáš Rosa">
<organization></organization>
<organization/>
</author>
<date year="2002"/> month="March" year="2001"/>
</front>
<seriesInfo name="Cryptology
<refcontent>Cryptology ePrint Archive, Report 2002/076" value=""/> Paper 2002/076</refcontent>
</reference>
<reference anchor="MRLG15" > anchor="MRLG15">
<front>
<title>Format Oracles on OpenPGP</title>
<author initials="F." surname="Maury" fullname="Florian Maury">
<organization></organization>
<organization/>
</author>
<author initials="J.-R." initials="JR." surname="Reinhard" fullname="Jean-René Reinhard">
<organization></organization>
<organization/>
</author>
<author initials="O." surname="Levillain" fullname="Olivier Levillain">
<organization></organization>
<organization/>
</author>
<author initials="H." surname="Gilbert" fullname="Henri Gilbert">
<organization></organization>
<organization/>
</author>
<date month="January" year="2015"/>
</front>
<seriesInfo name="CT-RSA 2015" value="Topics name="DOI" value="10.1007/978-3-319-16715-2_12"/>
<refcontent>Topics in Cryptology –- -- CT-RSA 2015 pp 220–236"/>
<seriesInfo name="DOI" value="10.1007/978-3-319-16715-2_12"/> 2015, Vol. 9048, pp. 220-236</refcontent>
</reference>
<reference anchor="MZ05" target="http://eprint.iacr.org/2005/033">
<front>
<title>An Attack on CFB Mode Encryption As Used By OpenPGP</title>
<author initials="S." surname="Mister" fullname="Serge Mister">
<organization></organization>
<organization/>
</author>
<author initials="R." surname="Zuccherato" fullname="Robert Zuccherato">
<organization></organization>
<organization/>
</author>
<date year="2005" month="February" day="08"/> month="February"/>
</front>
<seriesInfo name="IACR
<refcontent>Cryptology ePrint Archive" value="Report 2005/033"/> Archive, Paper 2005/033</refcontent>
</reference>
<reference anchor="OPENPGPCARD" target="https://gnupg.org/ftp/specs/OpenPGP-smart-card-application-3.4.1.pdf">
<front>
<title>Functional Specification of the OpenPGP application on ISO Smart Card Operating Systems (version 3.4.1)</title> Systems</title>
<author initials="A." surname="Pietig" fullname="Achim Pietig">
<organization></organization>
<organization/>
</author>
<date month="March" year="2020"/>
</front>
<refcontent>Version 3.4.1</refcontent>
</reference>
<!-- [rfced] For this reference entry, the URL and information provided
do not match the DOI. Please let us know if the intention is to
reference "IEEE" (option A) or "The Open Group" (option B).
Original:
[PAX] The Open Group, "IEEE Standard for Information
Technology-Portable Operating System Interface (POSIX(R))
Base Specifications, Issue 7: pax - portable archive
interchange", IEEE Standard 1003.1-2017,
DOI 10.1109/IEEESTD.2018.8277153, 2018,
<https://pubs.opengroup.org/onlinepubs/9699919799/
utilities/pax.html>.
Perhaps:
A) [PAX] IEEE, "IEEE Standard for Information Technology-Portable
Operating System Interface (POSIX(TM)) Base
Specifications, Issue 7", 'pax - portable archive
interchange', IEEE Std 1003.1-2017,
DOI 10.1109/IEEESTD.2018.8277153, January 2018,
<https://ieeexplore.ieee.org/document/8277153>.
or
B) [PAX] The Open Group, "The Open Group Base Specifications", 'pax
- portable archive interchange', Issue 7, 2018 Edition,
IEEE Std 1003.1-2017, 2018,
<https://pubs.opengroup.org/onlinepubs/9699919799/
utilities/pax.html>.
-->
<reference anchor="PAX" target="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html">
<front>
<title>IEEE Standard for Information Technology--Portable Technology-Portable Operating System Interface (POSIX(R)) Base Specifications, Issue 7: pax - portable archive interchange</title>
<author >
<author>
<organization>The Open Group</organization>
</author>
<date year="2018"/>
</front>
<seriesInfo name="IEEE Standard" value="1003.1-2017"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8277153"/>
</reference>
<!--Option B
<reference anchor="PAX" target="https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html">
<front>
<title>The Open Group Base Specifications</title>
<author>
<organization>The Open Group</organization>
</author>
<date year="2018"/>
</front>
<seriesInfo name="IEEE Std" value="1003.1-2017"/>
<refcontent>'pax - portable archive interchange', Issue 7, 2018 Edition</refcontent>
</reference>
Option A (remember the double dash):
<reference anchor="PAX" target="https://ieeexplore.ieee.org/document/8277153">
<front>
<title>IEEE Standard for Information Technology-Portable Operating System Interface (POSIX(TM)) Base Specifications, Issue 7</title>
<author>
<organization>IEEE</organization>
</author>
<date month="January" year="2018"/>
</front>
<seriesInfo name="IEEE Standard" value="1003.1-2017"/>
<seriesInfo name="DOI" value="10.1109/IEEESTD.2018.8277153"/>
<refcontent>'pax - portable archive interchange'</refcontent>
</reference>
-->
<reference anchor="PSSLR17" target="https://eprint.iacr.org/2017/1014">
<front>
<title>Attacking Deterministic Signature Schemes using Fault Attacks</title>
<author initials="D." surname="Poddebniak">
<organization></organization>
<organization/>
</author>
<author initials="J." surname="Somorovsky">
<organization></organization>
<organization/>
</author>
<author initials="S." surname="Schinzel">
<organization></organization>
<organization/>
</author>
<author initials="M." surname="Lochter">
<organization></organization>
<organization/>
</author>
<author initials="P." surname="Rösler">
<organization></organization>
<organization/>
</author>
<date year="2017" month="October"/>
</front>
<refcontent>Cryptology ePrint Archive, Paper 2017/1014 </refcontent>
</reference>
<!-- [rfced] For this reference entry, an ISBN is included, which
points to a book for purchase. We did find the full text
available at "https://archive.org/stream/pdfy-w2BDORIlag2gJwe2/
Mastering+Regular+Expressions~tqw~_darksiderg_djvu.txt"; would
you like to include this URL as shown below?
Original:
[REGEX] Friedl, J., "Mastering Regular Expressions",
ISBN 0-596-00289-0, August 2002.
Perhaps:
[REGEX] Friedl, J. E., "Mastering Regular Expressions",
ISBN 0-596-00289-0, July 2002,
<https://archive.org/stream/pdfy-w2BDORIlag2gJwe2/
Mastering+Regular+Expressions~tqw~_darksiderg_djvu.txt>.
-->
<reference anchor="REGEX" > anchor="REGEX">
<front>
<title>Mastering Regular Expressions</title>
<author initials="J." initials="J. E." surname="Friedl" fullname="Jeffrey E. F. Friedl">
<organization>O'Reilly</organization>
</author>
<date year="2002" month="August"/> month="July"/>
</front>
<seriesInfo name="ISBN" value="0-596-00289-0"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1991.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4880.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5581.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5639.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5869.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6090.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6637.xml"/>
<reference anchor='RFC1991'> anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">
<front>
<title>PGP Message Exchange Formats</title>
<author fullname='D. Atkins' initials='D.' surname='Atkins'/>
<author fullname='W. Stallings' initials='W.' surname='Stallings'/>
<author fullname='P. Zimmermann' initials='P.' surname='Zimmermann'/>
<date month='August' year='1996'/>
<abstract>
<t>This document describes the format of "PGP files", i.e., messages that have been encrypted and/or signed with PGP. This memo provides information
<title>SEC 1: Elliptic Curve Cryptography</title>
<author>
<organization>Standards for the Internet community. This memo does not specify an Internet standard of any kind.</t>
</abstract> Efficient Cryptography Group</organization>
</author>
<date year="2009" month="May"/>
</front>
<seriesInfo name='RFC' value='1991'/>
<seriesInfo name='DOI' value='10.17487/RFC1991'/>
<refcontent></refcontent>
</reference>
<reference anchor='RFC2440'> anchor="SHA1CD" target="https://github.com/cr-marcstevens/sha1collisiondetection">
<front>
<title>OpenPGP Message Format</title>
<author fullname='J. Callas' initials='J.' surname='Callas'/>
<author fullname='L. Donnerhacke' initials='L.' surname='Donnerhacke'/>
<author fullname='H. Finney' initials='H.' surname='Finney'/>
<author fullname='R. Thayer' initials='R.' surname='Thayer'/>
<title>sha1collisiondetection</title>
<author>
<organization/>
</author>
<date month='November' year='1998'/>
<abstract>
<t>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. [STANDARDS-TRACK]</t>
</abstract> month="December" year="2020"/>
</front>
<seriesInfo name='RFC' value='2440'/>
<seriesInfo name='DOI' value='10.17487/RFC2440'/>
<refcontent>commit b4a7b0b</refcontent>
</reference>
<reference anchor='RFC4880'>
<front>
<title>OpenPGP Message Format</title>
<author fullname='J. Callas' initials='J.' surname='Callas'/>
<author fullname='L. Donnerhacke' initials='L.' surname='Donnerhacke'/>
<author fullname='H. Finney' initials='H.' surname='Finney'/>
<author fullname='D. Shaw' initials='D.' surname='Shaw'/>
<author fullname='R. Thayer' initials='R.' surname='Thayer'/>
<date month='November' year='2007'/>
<abstract>
<t>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on
<!-- [rfced] For the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only following entry, the format and methods needed to read, check, generate, and write conforming packets crossing any network. It title does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</t>
<t>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 match the message formats used in OpenPGP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='4880'/>
<seriesInfo name='DOI' value='10.17487/RFC4880'/>
</reference>
<reference anchor='RFC5581'>
<front>
<title>The Camellia Cipher in OpenPGP</title>
<author fullname='D. Shaw' initials='D.' surname='Shaw'/>
<date month='June' year='2009'/>
<abstract>
<t>This document presents
title at the necessary information URL provided. Instead of pointing to use the Camellia symmetric block cipher in the OpenPGP protocol. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5581'/>
<seriesInfo name='DOI' value='10.17487/RFC5581'/>
</reference>
<reference anchor='RFC5639'>
<front>
<title>Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation</title>
<author fullname='M. Lochter' initials='M.' surname='Lochter'/>
<author fullname='J. Merkle' initials='J.' surname='Merkle'/>
<date month='March' year='2010'/>
<abstract>
<t>This memo proposes several elliptic curve domain parameters GitHub, which
may not be stable over finite prime fields for use in cryptographic applications. The domain parameters are consistent with time, may we update the relevant international standards, and can be used in X.509 certificates and certificate revocation lists (CRLs), for Internet Key Exchange (IKE), Transport Layer Security (TLS), XML signatures, URL to
"https://dl.acm.org/doi/abs/10.5555/3489212.3489316", which is
stable and all applications or protocols based on contains the cryptographic message syntax (CMS). This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5639'/>
<seriesInfo name='DOI' value='10.17487/RFC5639'/>
</reference>
<reference anchor='RFC5869'>
<front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title>
<author fullname='H. Krawczyk' initials='H.' surname='Krawczyk'/>
<author fullname='P. Eronen' initials='P.' surname='Eronen'/>
<date month='May' year='2010'/>
<abstract>
<t>This document specifies a simple Hashed Message Authentication Code (HMAC)-based key derivation function (HKDF), which can be used original title, as a building block in various protocols shown below?
Original:
[SHAMBLES] Leurent, G. and applications. The key derivation function (KDF) T. Peyrin, "Sha-1 is intended to support a wide range of applications and requirements, shambles: First
chosen-prefix collision on sha-1 and is conservative in its use of cryptographic hash functions. This document is not an Internet Standards Track specification; it is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5869'/>
<seriesInfo name='DOI' value='10.17487/RFC5869'/>
</reference>
<reference anchor='RFC6090'>
<front>
<title>Fundamental Elliptic Curve Cryptography Algorithms</title>
<author fullname='D. McGrew' initials='D.' surname='McGrew'/>
<author fullname='K. Igoe' initials='K.' surname='Igoe'/>
<author fullname='M. Salter' initials='M.' surname='Salter'/>
<date month='February' year='2011'/>
<abstract>
<t>This note describes application to the fundamental algorithms
PGP web of Elliptic Curve Cryptography (ECC) as they were defined in some seminal references from 1994 trust", 2020, <https://sha-mbles.github.io/>.
Perhaps:
[SHAMBLES] Leurent, G. and earlier. These descriptions may be useful for implementing the fundamental algorithms without using any of the specialized methods that were developed in following years. Only elliptic curves defined over fields of characteristic greater than three are in scope; these curves are those used in Suite B. This document is not an Internet Standards Track specification; it T. Peyrin, "Sha-1 is published for informational purposes.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6090'/>
<seriesInfo name='DOI' value='10.17487/RFC6090'/>
</reference>
<reference anchor='RFC6637'>
<front>
<title>Elliptic Curve Cryptography (ECC) in OpenPGP</title>
<author fullname='A. Jivsov' initials='A.' surname='Jivsov'/>
<date month='June' year='2012'/>
<abstract>
<t>This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards a shambles: first
chosen-prefix collision on sha-1 and Technology. The document specifies application to the conventions for interoperability between compliant OpenPGP implementations that make use
PGP web of this extension and these Elliptic Curves. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6637'/>
<seriesInfo name='DOI' value='10.17487/RFC6637'/>
</reference>
<reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">
<front>
<title>Standards for Efficient Cryptography 1 (SEC 1)</title>
<author >
<organization>Standards for Efficient Cryptography Group</organization>
</author>
<date year="2009" month="May"/>
</front>
</reference>
<reference anchor="SHA1CD" target="https://github.com/cr-marcstevens/sha1collisiondetection">
<front>
<title>sha1collisiondetection</title>
<author initials="M." surname="Stevens" fullname="Marc Stevens">
<organization></organization>
</author>
<author initials="D." surname="Shumow" fullname="Dan Shumow">
<organization></organization>
</author>
<date year="2017"/>
</front>
</reference> trust", August 2020, <https://dl.acm.org/doi/
abs/10.5555/3489212.3489316/>.
-->
<reference anchor="SHAMBLES" target="https://sha-mbles.github.io/">
<front>
<title>Sha-1 is a shambles: First first chosen-prefix collision on sha-1 and application to the PGP web of trust</title>
<author initials="G." surname="Leurent" fullname="Gaëtan Leurent">
<organization></organization>
<organization/>
</author>
<author initials="T." surname="Peyrin" fullname="Thomas Peyrin">
<organization></organization>
<organization/>
</author>
<date month="August" year="2020"/>
</front>
</reference>
<reference anchor="SP800-57" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf">
<front>
<title>Recommendation on for Key Management: Part 1 - General</title>
<author >
<author>
<organization>NIST</organization>
</author>
<date year="2020" month="May"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-57 Part 1 Rev. 1, Revision 5"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
</reference>
<reference anchor="SP800-131A" target="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar2.pdf">
<front>
<title>Transitioning the Use of Cryptographic Algorithms and Key Lengths</title>
<author initials="E." surname="Barker">
<organization></organization>
</author>
<author initials="A." surname="Roginsky">
<organization></organization>
<author>
<organization>NIST</organization>
</author>
<date year="2019" month="March"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-131A value="800-131A, Revision 2"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-131Ar2"/>
</reference>
<reference anchor="STEVENS2013" target="https://eprint.iacr.org/2013/358">
<front>
<title>Counter-cryptanalysis</title>
<author initials="M." surname="Stevens" fullname="Marc Stevens">
<organization></organization>
<organization/>
</author>
<date year="2013" month="June"/>
</front>
<refcontent>Cryptology ePrint Archive, Paper 2013/358</refcontent>
</reference>
<reference anchor="UNIFIED-DIFF" target="https://www.gnu.org/software/diffutils/manual/html_node/Detailed-Unified.html">
<front>
<title>Detailed Description of Unified Format</title>
<author >
<title>Comparing and Merging Files</title>
<author>
<organization>Free Software Foundation</organization>
</author>
<date year="2021" month="January" day="02"/> month="January"/>
</front>
<refcontent>'Detailed Description of Unified Format', Section 2.2.2.2</refcontent>
</reference>
<reference anchor="USENIX-STUDY" target="https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_dechand.pdf">
<front>
<title>An Empirical Study of Textual Key-Fingerprint Representations</title>
<author >
<organization>Usenix</organization> fullname="Sergej Dechand" initials="S." surname="Dechand">
<organization/>
</author>
<author fullname="Dominik Schürmann" initials="D." surname="Schürmann">
<organization/>
</author>
<author fullname="Karoline Busse" initials="K." surname="Busse">
<organization/>
</author>
<author fullname="Yasemin Acar" initials="Y." surname="Acar">
<organization/>
</author>
<author fullname="Sascha Fahl" initials="S." surname="Fahl">
<organization/>
</author>
<author fullname="Matthew Smith" initials="M." surname="Smith">
<organization/>
</author>
<date year="2016" month="August" day="10"/> month="August"/>
</front>
<seriesInfo name="ISBN" value="978-1-931971-32-4"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2978.xml"/>
<reference anchor='RFC2978'>
<front>
<title>IANA Charset Registration Procedures</title>
<author fullname='N. Freed' initials='N.' surname='Freed'/>
<author fullname='J. Postel' initials='J.' surname='Postel'/>
<date month='October' year='2000'/>
<abstract>
<t>Multipurpose Internet Mail Extensions (MIME) and various other Internet protocols are capable of using many different charsets. This in turn means that the ability to label different charsets is essential. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='19'/>
<seriesInfo name='RFC' value='2978'/>
<seriesInfo name='DOI' value='10.17487/RFC2978'/>
</reference>
<reference anchor='CHECKOWAY'> anchor="CHECKOWAY">
<front>
<title>A Systematic Analysis of the Juniper Dual EC Incident</title>
<author fullname='Stephen Checkoway' initials='S.' surname='Checkoway'> fullname="Stephen Checkoway" initials="S." surname="Checkoway">
<organization>University of Illinois at Chicago, Chicago, IL, USA</organization>
</author>
<author fullname='Jacob Maskiewicz' initials='J.' surname='Maskiewicz'> fullname="Jacob Maskiewicz" initials="J." surname="Maskiewicz">
<organization>UC San Diego, La Jolla, CA, USA</organization>
</author>
<author fullname='Christina Garman' initials='C.' surname='Garman'> fullname="Christina Garman" initials="C." surname="Garman">
<organization>Johns Hopkins University, Baltimore, MD, USA</organization>
</author>
<author fullname='Joshua Fried' initials='J.' surname='Fried'> fullname="Joshua Fried" initials="J." surname="Fried">
<organization>University of Pennsylvania, Philadelphia, PA, USA</organization>
</author>
<author fullname='Shaanan Cohney' initials='S.' surname='Cohney'> fullname="Shaanan Cohney" initials="S." surname="Cohney">
<organization>University of Pennsylvania, Philadelphia, PA, USA</organization>
</author>
<author fullname='Matthew Green' initials='M.' surname='Green'> fullname="Matthew Green" initials="M." surname="Green">
<organization>Johns Hopkins University, Baltimore, MD, USA</organization>
</author>
<author fullname='Nadia Heninger' initials='N.' surname='Heninger'> fullname="Nadia Heninger" initials="N." surname="Heninger">
<organization>University of Pennsylvania, Philadelphia, PA, USA</organization>
</author>
<author fullname='Ralf-Philipp Weinmann' initials='R.' surname='Weinmann'> fullname="Ralf-Philipp Weinmann" initials="RP." surname="Weinmann">
<organization>Comsecuris, Duisburg, Germany</organization>
</author>
<author fullname='Eric Rescorla' initials='E.' surname='Rescorla'> fullname="Eric Rescorla" initials="E." surname="Rescorla">
<organization>UC San Diego, La Jolla, CA, USA</organization>
</author>
<author fullname='Hovav Shacham' initials='H.' surname='Shacham'> fullname="Hovav Shacham" initials="H." surname="Shacham">
<organization>UC San Diego, La Jolla, CA, USA</organization>
</author>
<date month='October' year='2016'/> month="October" year="2016"/>
</front>
<seriesInfo name='Proceedings
<refcontent>Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications' value='Security'/> Communications Security</refcontent>
<seriesInfo name='DOI' value='10.1145/2976749.2978395'/> name="DOI" value="10.1145/2976749.2978395"/>
</reference>
</references>
</references>
<section anchor="test-vectors"><name>Test vectors</name> anchor="test-vectors">
<name>Test Vectors</name>
<t>To help implementing with the implementation of this specification specification, a set of non-normative examples follow here.</t> follow.</t>
<section anchor="sample-v4-ed25519legacy-key"><name>Sample anchor="sample-v4-ed25519legacy-key">
<name>Sample v4 Ed25519Legacy key</name> Key</name>
<t>The secret key used for this example is:</t>
<t>D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2</t>
<artwork><![CDATA[
D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2
]]></artwork>
<t>Note that this is the raw secret key used as input to the EdDSA signing operation.
The key was created on 2014-08-19 14:28:27 and thus the fingerprint of the OpenPGP key is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A
]]></artwork></figure>
]]></artwork>
<t>The algorithm-specific input parameters without the MPI length headers are:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
oid: 2b06010401da470f01
q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406
]]></artwork></figure>
]]></artwork>
<t>The entire public key packet is thus:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47
0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19
79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e
43 ee 3b 24 06
]]></artwork></figure>
]]></artwork>
<t>The same packet, packet represented in ASCII-armored form is:</t>
<figure><sourcecode
<sourcecode type="application/pgp-keys" name="v4-ed25519-pubkey-packet.key"><![CDATA[
-----BEGIN PGP PUBLIC KEY BLOCK-----
xjMEU/NfCxYJKwYBBAHaRw8BAQdAPwmJlL3ZFu1AUxl5NOSofIBzOhKA1i+AEJku
Q+47JAY=
-----END PGP PUBLIC KEY BLOCK-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
<section anchor="sample-v4-ed25519legacy-signature"><name>Sample anchor="sample-v4-ed25519legacy-signature">
<name>Sample v4 Ed25519Legacy signature</name> Signature</name>
<t>The signature is created using the sample key over the input data "OpenPGP" on 2015-09-16 12:24:53 UTC and thus the input to the hash function is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
m: 4f70656e504750040016080006050255f95f9504ff0000000c
]]></artwork></figure>
]]></artwork>
<t>Using the SHA2-256 hash algorithm yields the digest:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
]]></artwork></figure>
<t>Which
]]></artwork>
<t>which is fed into the EdDSA signature function and yields this the following signature:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366
s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404
]]></artwork></figure>
]]></artwork>
<t>The entire signature packet is thus:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a
09 10 8c fd e1 21 97 96 5a 9a f6 22 00 ff 56 f9
0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2
7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00
d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e
a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04
]]></artwork></figure>
]]></artwork>
<t>The same packet represented in ASCII-armored form is:</t>
<figure><sourcecode
<sourcecode type="application/pgp-signature" name="v4-ed25519-signature-over-OpenPGP.sig"><![CDATA[
-----BEGIN PGP SIGNATURE-----
iF4EABYIAAYFAlX5X5UACgkQjP3hIZeWWpr2IgD/VvkMypjiECY3vZg/2xbBMd/S
ftgr9N3lYG4NdWrtM2YBANCcT6EVJ/A44PV/IgHYLy6iyQMyZfps60iehUuuYbQE
-----END PGP SIGNATURE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
<section anchor="v6-cert"><name>Sample anchor="v6-cert">
<name>Sample v6 Certificate (Transferable Public Key)</name>
<t>Here is a Transferable Public Key consisting of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A v6 Ed25519 Public-Key packet</t>
</li>
<li>
<t>A v6 direct key self-signature</t>
</li>
<li>
<t>A v6 X25519 Public-Subkey packet</t>
</li>
<li>
<t>A v6 subkey binding signature</t>
</list></t>
</li>
</ul>
<t>The primary key has the fingerprint <spanx style="verb">CB186C4F0609A697E4D52DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9</spanx>.</t> following fingerprint:</t> <t><tt>CB186C4F0609A697E4D52DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9</tt></t>
<t>The subkey has the fingerprint <spanx style="verb">12C83F1E706F6308FE151A417743A1F033790E93E9978488D1DB378DA9930885</spanx>.</t>
<figure><sourcecode following fingerprint:</t> <t><tt>12C83F1E706F6308FE151A417743A1F033790E93E9978488D1DB378DA9930885</tt></t>
<sourcecode type="application/pgp-keys" name="v6-minimal-cert.key"><![CDATA[
-----BEGIN PGP PUBLIC KEY BLOCK-----
xioGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laPCsQYf
GwoAAABCBYJjh3/jAwsJBwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxy
KwwfHifBilZwj2Ul7Ce62azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lw
gyU2kCcUmKfvBXbAf6rhRYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaE
QsiPlR4zxP/TP7mhfVEe7XWPxtnMUMtf15OyA51YBM4qBmOHf+MZAAAAIIaTJINn
+eUBXbki+PSAld2nhJh/LVmFsS+60WyvXkQ1wpsGGBsKAAAALAWCY4d/4wKbDCIh
BssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce62azJAAAAAAQBIKbpGG2dWTX8
j+VjFM21J0hqWlEg+bdiojWnKfA5AQpWUWtnNwDEM0g12vYxoWM8Y81W+bHBw805
I8kWVkXU6vFOi+HWvv/ira7ofJu16NnoUkhclkUrk0mXubZvyl4GBg==
-----END PGP PUBLIC KEY BLOCK-----
]]></sourcecode></figure>
]]></sourcecode>
<t>The corresponding Transferable Secret Key can be found in <xref target="v6-key"/>.</t>
<section anchor="sig-hashed-data-example"><name>Hashed anchor="sig-hashed-data-example">
<name>Hashed Data Stream for Signature Verification</name>
<t>The direct key self-signature in the certificate in <xref target="v6-cert"/> is made over the following sequence of data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
0x0000 10 3e 2d 7d 22 7e c0 e6
0x0008 d7 ce 44 71 db 36 bf c9
0x0010 70 83 25 36 90 27 14 98
0x0018 a7 ef 05 76 c0 7f aa e1
0x0020 9b 00 00 00 2a 06 63 87
0x0028 7f e3 1b 00 00 00 20 f9
0x0030 4d a7 bb 48 d6 0a 61 e5
0x0038 67 70 6a 65 87 d0 33 19
0x0040 99 bb 9d 89 1a 08 24 2e
0x0048 ad 84 54 3d f8 95 a3 06
0x0050 1f 1b 0a 00 00 00 42 05
0x0058 82 63 87 7f e3 03 0b 09
0x0060 07 05 15 0a 0e 08 0c 02
0x0068 16 00 02 9b 03 02 1e 09
0x0070 22 21 06 cb 18 6c 4f 06
0x0078 09 a6 97 e4 d5 2d fa 6c
0x0080 72 2b 0c 1f 1e 27 c1 8a
0x0088 56 70 8f 65 25 ec 27 ba
0x0090 d9 ac c9 05 27 09 02 07
0x0098 02 06 ff 00 00 00 4a
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
0x0000 10 3e 2d 7d 22 7e c0 e6 salt
0x0008 d7 ce 44 71 db 36 bf c9
0x0010 70 83 25 36 90 27 14 98
0x0018 a7 ef 05 76 c0 7f aa e1
[ pubkey begins ]
0x0020 9b v6 pubkey
0x0021 00 00 00 2a pubkey length
0x0025 06 pubkey version
0x0026 63 87 creation time
0x0028 7f e3 (2022-11-30T16:08:03Z)
0x002a 1b key algo: Ed25519
0x002b 00 00 00 20 key length
0x002f f9 Ed25519 public key
0x0030 4d a7 bb 48 d6 0a 61 e5
0x0038 67 70 6a 65 87 d0 33 19
0x0040 99 bb 9d 89 1a 08 24 2e
0x0048 ad 84 54 3d f8 95 a3
[ trailer begins ]
0x004f 06 sig version
0x0050 1f sig type: direct key signature
0x0051 1b sig algo: Ed25519
0x0052 0a hash ago: SHA2-512
0x0053 00 00 00 42 hashed subpackets length
0x0057 05 subpkt length
0x0058 82 critical subpkt: Sig Creation Time
0x0059 63 87 7f e3 Signature Creation Time
0x005d 03 subpkt length
0x005e 0b subpkt type: Pref. v1 SEIPD Ciphers
0x005f 09 Ciphers: [AES256 AES128]
0x0060 07
0x0061 05 subpkt length
0x0062 15 subpkt type: Pref. Hash Algorithms
0x0063 0a 0e Hashes: [SHA2-512 SHA3-512
0x0065 08 0c SHA2-256 SHA3-256]
0x0067 02 subpkt length
0x0068 16 subpkt type: Pref. Compression
0x0069 00 Compression: [none]
0x006a 02 subpkt length
0x006b 9b critical subpkt: Key Flags
0x006c 03 Key Flags: {certify, sign}
0x006d 02 subpkt length
0x006e 1e subpkt type: Features
0x006f 09 Features: {SEIPDv1, SEIPDv2}
0x0070 22 subpkt length
0x0071 21 subpkt type: Issuer Fingerprint
0x0072 06 Fingerprint version 6
0x0073 cb 18 6c 4f 06 Issuer Fingerprint
0x0078 09 a6 97 e4 d5 2d fa 6c
0x0080 72 2b 0c 1f 1e 27 c1 8a
0x0088 56 70 8f 65 25 ec 27 ba
0x0090 d9 ac c9
0x0093 05 subpkt length
0x0094 27 subpkt type: Pref. AEAD Ciphersuites
0x0095 09 02 07 Ciphersuites:
0x0098 02 [ AES256-OCB, AES128-OCB ]
0x0099 06 sig version
0x009a ff sentinel octet
0x009b 00 00 00 4a trailer length
]]></artwork></figure>
]]></artwork>
<t>The subkey binding signature in <xref target="v6-cert"/> is made over the following sequence of data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
0x0000 a6 e9 18 6d 9d 59 35 fc
0x0008 8f e5 63 14 cd b5 27 48
0x0010 6a 5a 51 20 f9 b7 62 a2
0x0018 35 a7 29 f0 39 01 0a 56
0x0020 9b 00 00 00 2a 06 63 87
0x0028 7f e3 1b 00 00 00 20 f9
0x0030 4d a7 bb 48 d6 0a 61 e5
0x0038 67 70 6a 65 87 d0 33 19
0x0040 99 bb 9d 89 1a 08 24 2e
0x0048 ad 84 54 3d f8 95 a3 9b
0x0050 00 00 00 2a 06 63 87 7f
0x0058 e3 19 00 00 00 20 86 93
0x0060 24 83 67 f9 e5 01 5d b9
0x0068 22 f8 f4 80 95 dd a7 84
0x0070 98 7f 2d 59 85 b1 2f ba
0x0078 d1 6c af 5e 44 35 06 18
0x0080 1b 0a 00 00 00 2c 05 82
0x0088 63 87 7f e3 02 9b 0c 22
0x0090 21 06 cb 18 6c 4f 06 09
0x0098 a6 97 e4 d5 2d fa 6c 72
0x00a0 2b 0c 1f 1e 27 c1 8a 56
0x00a8 70 8f 65 25 ec 27 ba d9
0x00b0 ac c9 06 ff 00 00 00 34
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<figure><artwork><![CDATA[
<!-- [rfced] Questions about the Appendix
Appendix A.3.1
a) In the last figure in Appendix A.3.1, should "Issuer" be
added before "Fingerprint" to match how it appears in the second
figure in this section?
Original:
0x0090 21 subpkt type: Issuer Fingerprint
0x0091 06 Fingerprint version 6
0x0092 cb 18 6c 4f 06 09 Fingerprint
Perhaps:
0x0090 21 subpkt type: Issuer Fingerprint
0x0091 06 Fingerprint version 6
0x0092 cb 18 6c 4f 06 09 Issuer Fingerprint
b) Should "direct key signature" be capital since the other sig types
appear as capital?
Original:
0x004f 06 sig version
0x0050 1f sig type: direct key signature
...
Appendix A.6
c) Should "issuer fingerprint" (2 instances) be capital for
consistency with Appendix A.3.1? Should "key version" be
"Key version" to match Appendix A.8.1? Should 2 instances
of "v6 fingerprint" be "Fingerprint version 6" (or vice
versa) for consistency?
Original:
0x0078 21 subpkt type: issuer fingerprint
0x0079 06 key version
0x007a cb 18 6c 4f 06 09 v6 fingerprint
Perhaps:
0x0078 21 subpkt type: Issuer Fingerprint
0x0079 06 Key version
0x007a cb 18 6c 4f 06 09 Fingerprint version 6
d) Should "canonical text" (2 instances) be capital since the other
sig types appear as capital?
0x0069 06 sig version
0x006a 01 sig type: canonical text
-->
<artwork><![CDATA[
0x0000 a6 e9 18 6d 9d 59 35 fc salt
0x0008 8f e5 63 14 cd b5 27 48
0x0010 6a 5a 51 20 f9 b7 62 a2
0x0018 35 a7 29 f0 39 01 0a 56
[ primary pubkey begins ]
0x0020 9b v6 pubkey
0x0021 00 00 00 2a pubkey length
0x0025 06 pubkey version
0x0026 63 87 creation time
0x0028 7f e3 (2022-11-30T16:08:03Z)
0x002a 1b key algo: Ed25519
0x002b 00 00 00 20 key length
0x002f f9 Ed25519 public key
0x0030 4d a7 bb 48 d6 0a 61 e5
0x0038 67 70 6a 65 87 d0 33 19
0x0040 99 bb 9d 89 1a 08 24 2e
0x0048 ad 84 54 3d f8 95 a3
[ subkey pubkey begins ]
0x004f 9b v6 key
0x0050 00 00 00 2a pubkey length
0x0054 06 pubkey version
0x0055 63 87 7f creation time (2022-11-30T16:08:03Z)
0x0058 e3
0x0059 19 key algo: X25519
0x005a 00 00 00 20 key length
0x005e 86 93 X25519 public key
0x0060 24 83 67 f9 e5 01 5d b9
0x0068 22 f8 f4 80 95 dd a7 84
0x0070 98 7f 2d 59 85 b1 2f ba
0x0078 d1 6c af 5e 44 35
[ trailer begins ]
0x007e 06 sig version
0x007f 18 sig type: Subkey Binding sig
0x0080 1b sig algo Ed25519
0x0081 0a hash algo: SHA2-512
0x0082 00 00 00 2c hashed subpackets length
0x0086 05 subpkt length
0x0087 82 critical subpkt: Sig Creation Time
0x0088 63 87 7f e3 Signature Creation Time
0x008c 02 subpkt length
0x008d 9b critical subpkt: Key Flags
0x008e 0c Key Flags: {EncComms, EncStorage}
0x008f 22 subpkt length
0x0090 21 subpkt type: Issuer Fingerprint
0x0091 06 Fingerprint version 6
0x0092 cb 18 6c 4f 06 09 Fingerprint
0x0098 a6 97 e4 d5 2d fa 6c 72
0x00a0 2b 0c 1f 1e 27 c1 8a 56
0x00a8 70 8f 65 25 ec 27 ba d9
0x00b0 ac c9
0x00b2 06 sig version
0x00b3 ff sentinel octet
0x00b4 00 00 00 34 trailer length
]]></artwork></figure>
]]></artwork>
</section>
</section>
<section anchor="v6-key"><name>Sample anchor="v6-key">
<name>Sample v6 Secret Key (Transferable Secret Key)</name>
<t>Here is a Transferable Secret Key consisting of:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>A v6 Ed25519 Secret-Key packet</t>
</li>
<li>
<t>A v6 direct key self-signature</t>
</li>
<li>
<t>A v6 X25519 Secret-Subkey packet</t>
</li>
<li>
<t>A v6 subkey binding signature</t>
</list></t>
<figure><sourcecode
</li>
</ul>
<sourcecode type="application/pgp-keys" name="v6-minimal-secret.key"><![CDATA[
-----BEGIN PGP PRIVATE KEY BLOCK-----
xUsGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laMAGXKB
exK+cH6NX1hs5hNhIB00TrJmosgv3mg1ditlsLfCsQYfGwoAAABCBYJjh3/jAwsJ
BwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lwgyU2kCcUmKfvBXbAf6rh
RYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaEQsiPlR4zxP/TP7mhfVEe
7XWPxtnMUMtf15OyA51YBMdLBmOHf+MZAAAAIIaTJINn+eUBXbki+PSAld2nhJh/
LVmFsS+60WyvXkQ1AE1gCk95TUR3XFeibg/u/tVY6a//1q0NWC1X+yui3O24wpsG
GBsKAAAALAWCY4d/4wKbDCIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJAAAAAAQBIKbpGG2dWTX8j+VjFM21J0hqWlEg+bdiojWnKfA5AQpWUWtnNwDE
M0g12vYxoWM8Y81W+bHBw805I8kWVkXU6vFOi+HWvv/ira7ofJu16NnoUkhclkUr
k0mXubZvyl4GBg==
-----END PGP PRIVATE KEY BLOCK-----
]]></sourcecode></figure>
]]></sourcecode>
<t>The corresponding Transferable Public Key can be found in <xref target="v6-cert"/>.</t>
</section>
<section anchor="v6-locked-key"><name>Sample locked anchor="v6-locked-key">
<name>Sample Locked v6 Secret Key (Transferable Secret Key)</name>
<t>Here is the same secret key as in <xref target="v6-key"/>, but the secret key material is locked with a passphrase using AEAD and Argon2.</t>
<t>The passphrase is the ASCII string:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
correct horse battery staple
]]></artwork></figure>
<figure><sourcecode
]]></artwork>
<sourcecode type="application/pgp-keys" name="v6-minimal-secret-locked.key"><![CDATA[
-----BEGIN PGP PRIVATE KEY BLOCK-----
xYIGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laP9JgkC
FARdb9ccngltHraRe25uHuyuAQQVtKipJ0+r5jL4dacGWSAheCWPpITYiyfyIOPS
3gIDyg8f7strd1OB4+LZsUhcIjOMpVHgmiY/IutJkulneoBYwrEGHxsKAAAAQgWC
Y4d/4wMLCQcFFQoOCAwCFgACmwMCHgkiIQbLGGxPBgmml+TVLfpscisMHx4nwYpW
cI9lJewnutmsyQUnCQIHAgAAAACtKCAQPi19In7A5tfORHHbNr/JcIMlNpAnFJin
7wV2wH+q4UWFs7kDsBJ+xP2i8CMEWi7Ha8tPlXGpZR4UruETeh1mhELIj5UeM8T/
0z+5oX1RHu11j8bZzFDLX9eTsgOdWATHggZjh3/jGQAAACCGkySDZ/nlAV25Ivj0
gJXdp4SYfy1ZhbEvutFsr15ENf0mCQIUBA5hhGgp2oaavg6mFUXcFMwBBBUuE8qf
9Ock+xwusd+GAglBr5LVyr/lup3xxQvHXFSjjA2haXfoN6xUGRdDEHI6+uevKjVR
v5oAxgu7eJpaXNjCmwYYGwoAAAAsBYJjh3/jApsMIiEGyxhsTwYJppfk1S36bHIr
DB8eJ8GKVnCPZSXsJ7rZrMkAAAAABAEgpukYbZ1ZNfyP5WMUzbUnSGpaUSD5t2Ki
Nacp8DkBClZRa2c3AMQzSDXa9jGhYzxjzVb5scHDzTkjyRZWRdTq8U6L4da+/+Kt
ruh8m7Xo2ehSSFyWRSuTSZe5tm/KXgYG
-----END PGP PRIVATE KEY BLOCK-----
]]></sourcecode></figure>
]]></sourcecode>
<section anchor="intermediate-data-for-locked-primary-key"><name>Intermediate anchor="intermediate-data-for-locked-primary-key">
<name>Intermediate Data for Locked Primary Key</name>
<t>The S2K-derived material for the primary key is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
832bd2662a5c2b251ee3fc82aec349a766ca539015880133002e5a21960b3bcf
]]></artwork></figure>
]]></artwork>
<t>After HKDF, the symmetric key used for AEAD encryption of the primary key is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
9e37cb26787f37e18db172795c4c297550d39ac82511d9af4c8706db6a77fd51
]]></artwork></figure>
]]></artwork>
<t>The additional data for AEAD for the primary key is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
c50663877fe31b00000020f94da7bb48d60a61e567706a6587d0331999bb9d89
1a08242ead84543df895a3
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="intermediate-data-for-locked-subkey"><name>Intermediate anchor="intermediate-data-for-locked-subkey">
<name>Intermediate Data for Locked Subkey</name>
<t>The S2K-derived key material for the subkey is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
f74a6ce873a089ef13a3da9ac059777bb22340d15eaa6c9dc0f8ef09035c67cd
]]></artwork></figure>
]]></artwork>
<t>After HKDF, the symmetric key used for AEAD encryption of the subkey is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
3c60cb63285f62f4c3de49835786f011cf6f4c069f61232cd7013ff5fd31e603
]]></artwork></figure>
]]></artwork>
<t>The additional data for AEAD for the subkey is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
c70663877fe319000000208693248367f9e5015db922f8f48095dda784987f2d
5985b12fbad16caf5e4435
]]></artwork></figure>
]]></artwork>
</section>
</section>
<section anchor="sample-csf-message"><name>Sample anchor="sample-csf-message">
<name>Sample Cleartext Signed Message</name>
<t>Here is a signed message that uses the cleartext signature framework Cleartext Signature Framework (<xref target="cleartext-signature"/>). It can be verified with the certificate from (<xref target="v6-cert"/>).</t> <xref target="v6-cert"/>.</t>
<t>Note that this message makes use of dash-escaping (<xref target="dash-escaping"/>) due to its contents.</t>
<figure><sourcecode
<sourcecode type="text/plain" name="cleartext-signed-message.txt"><![CDATA[
-----BEGIN PGP SIGNED MESSAGE-----
What we need from the grocery store:
- - tofu
- - vegetables
- - noodles
-----BEGIN PGP SIGNATURE-----
wpgGARsKAAAAKQWCY5ijYyIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJAAAAAGk2IHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usJ9BvuAqo
/FvLFuGWMbKAdA+epq7V4HOtAPlBWmU8QOd6aud+aSunHQaaEJ+iTFjP2OMW0KBr
NK2ay45cX1IVAQ==
-----END PGP SIGNATURE-----
]]></sourcecode></figure>
]]></sourcecode>
<t>The signature packet here is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
0x0000 c2 packet type: Signature
0x0001 98 packet length
0x0002 06 signature sig version 6
0x0003 01 signature sig type: canonical text
0x0004 1b pubkey algorithm: Ed25519
0x0005 0a hash algorithm used: SHA2-512
0x0006 00 00 hashed subpackets length: 41
0x0008 00 29
0x000a 05 subpkt length
0x000b 82 critical subpkt: Sig Creation Time
0x000c 63 98 a3 63 (2022-12-13T16:08:03Z)
0x0010 22 subpkt length
0x0011 21 subpkt type: issuer fingerprint
0x0012 06 key version
0x0013 cb 18 6c 4f 06 v6 fingerprint
0x001a 09 a6 97 e4 d5 2d fa 6c
0x0020 72 2b 0c 1f 1e 27 c1 8a
0x0028 56 70 8f 65 25 ec 27 ba
0x0030 d9 ac c9
0x0033 00 00 00 00 unhashed subpackets length: 0
0x0037 69 left 16 bits of signed hash
0x0038 36
0x0039 20 salt length
0x003a 76 49 5f 50 21 88 salt
0x0040 90 f7 f5 e2 ee 3c 18 22
0x0048 51 4f 70 50 0f 55 1d 86
0x0050 e5 c9 21 e4 04 e3 4a 53
0x0058 fb ac
0x005a 27 d0 6f b8 0a a8 Ed25519 signature
0x0060 fc 5b cb 16 e1 96 31 b2
0x0068 80 74 0f 9e a6 ae d5 e0
0x0070 73 ad 00 f9 41 5a 65 3c
0x0078 40 e7 7a 6a e7 7e 69 2b
0x0080 a7 1d 06 9a 10 9f a2 4c
0x0088 58 cf d8 e3 16 d0 a0 6b
0x0090 34 ad 9a cb 8e 5c 5f 52
0x0098 15 01
]]></artwork></figure>
]]></artwork>
<t>The signature is made over the following data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
0x0000 76 49 5f 50 21 88 90 f7
0x0008 f5 e2 ee 3c 18 22 51 4f
0x0010 70 50 0f 55 1d 86 e5 c9
0x0018 21 e4 04 e3 4a 53 fb ac
0x0020 57 68 61 74 20 77 65 20
0x0028 6e 65 65 64 20 66 72 6f
0x0030 6d 20 74 68 65 20 67 72
0x0038 6f 63 65 72 79 20 73 74
0x0040 6f 72 65 3a 0d 0a 0d 0a
0x0048 2d 20 74 6f 66 75 0d 0a
0x0050 2d 20 76 65 67 65 74 61
0x0058 62 6c 65 73 0d 0a 2d 20
0x0060 6e 6f 6f 64 6c 65 73 0d
0x0068 0a 06 01 1b 0a 00 00 00
0x0070 29 05 82 63 98 a3 63 22
0x0078 21 06 cb 18 6c 4f 06 09
0x0080 a6 97 e4 d5 2d fa 6c 72
0x0088 2b 0c 1f 1e 27 c1 8a 56
0x0090 70 8f 65 25 ec 27 ba d9
0x0098 ac c9 06 ff 00 00 00 31
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
0x0000 76 49 5f 50 21 88 90 f7 salt
0x0008 f5 e2 ee 3c 18 22 51 4f
0x0010 70 50 0f 55 1d 86 e5 c9
0x0018 21 e4 04 e3 4a 53 fb ac
[ message begins ]
0x0020 57 68 61 74 20 77 65 20 canonicalized message
0x0028 6e 65 65 64 20 66 72 6f
0x0030 6d 20 74 68 65 20 67 72
0x0038 6f 63 65 72 79 20 73 74
0x0040 6f 72 65 3a 0d 0a 0d 0a
0x0048 2d 20 74 6f 66 75 0d 0a
0x0050 2d 20 76 65 67 65 74 61
0x0058 62 6c 65 73 0d 0a 2d 20
0x0060 6e 6f 6f 64 6c 65 73 0d
0x0068 0a
[ trailer begins ]
0x0069 06 sig version
0x006a 01 sigtype: sig type: canonical text
0x006b 1b pubkey algorithm: Ed25519
0x006c 0a hash algorithm: SHA2-512
0x006d 00 00 00 hashed subpackets length
0x0070 29
0x0071 05 subpacket length
0x0072 82 critical subpkt: Sig Creation Time
0x0073 63 98 a3 63 (2022-12-13T16:08:03Z)
0x0077 22 subpkt length
0x0078 21 subpkt type: issuer fingerprint
0x0079 06 key version
0x007a cb 18 6c 4f 06 09 v6 fingerprint
0x0080 a6 97 e4 d5 2d fa 6c 72
0x0088 2b 0c 1f 1e 27 c1 8a 56
0x0090 70 8f 65 25 ec 27 ba d9
0x0098 ac c9
0x009a 06 sig version
0x009b ff sentinel octet
0x009c 00 00 00 31 trailer length
]]></artwork></figure>
]]></artwork>
<t>The calculated SHA2-512 hash digest over this data is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
69365bf44a97af1f0844f1f6ab83fdf6b36f26692efaa621a8aac91c4e29ea07
e894cabc6e2f20eedfce6c03b89141a2cc7cbe245e6e7a5654addbec5000b89b
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="sample-inline-signed-message"><name>Sample inline-signed message</name> anchor="sample-inline-signed-message">
<name>Sample Inline-Signed Message</name>
<t>This is the same message and signature as in <xref target="sample-csf-message"/>, target="sample-csf-message"/> but as an inline-signed message. The hashed data is exactly the same, and all intermediate values and annotated hex dumps are also applicable.</t>
<figure><sourcecode
<sourcecode type="text/plain" name="inline-signed-message.pgp"><![CDATA[
-----BEGIN PGP MESSAGE-----
xEYGAQobIHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usyxhsTwYJppfk
1S36bHIrDB8eJ8GKVnCPZSXsJ7rZrMkBy0p1AAAAAABXaGF0IHdlIG5lZWQgZnJv
bSB0aGUgZ3JvY2VyeSBzdG9yZToKCi0gdG9mdQotIHZlZ2V0YWJsZXMKLSBub29k
bGVzCsKYBgEbCgAAACkFgmOYo2MiIQbLGGxPBgmml+TVLfpscisMHx4nwYpWcI9l
JewnutmsyQAAAABpNiB2SV9QIYiQ9/Xi7jwYIlFPcFAPVR2G5ckh5ATjSlP7rCfQ
b7gKqPxbyxbhljGygHQPnqau1eBzrQD5QVplPEDnemrnfmkrpx0GmhCfokxYz9jj
FtCgazStmsuOXF9SFQE=
-----END PGP MESSAGE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
<section anchor="sample-x25519-aead-ocb-encryption-and-decryption"><name>Sample anchor="sample-x25519-aead-ocb-encryption-and-decryption">
<name>Sample X25519-AEAD-OCB encryption Encryption and decryption</name> Decryption</name>
<t>This example encrypts the cleartext string <spanx style="verb">Hello, world!</spanx> <tt>Hello, world!</tt> for the sample cert (see <xref target="v6-cert"/>), using AES-128 with AEAD-OCB encryption.</t>
<section anchor="sample-public-key-encrypted-session-key-packet-v6"><name>Sample public-key encrypted session key packet anchor="sample-public-key-encrypted-session-key-packet-v6">
<name>Sample Public-Key Encrypted Session Key Packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork
<artwork name="v6pkesk-x25519.hexdump"><![CDATA[
0x0000 c1 5d 06 21 06 12 c8 3f
0x0008 1e 70 6f 63 08 fe 15 1a
0x0010 41 77 43 a1 f0 33 79 0e
0x0018 93 e9 97 84 88 d1 db 37
0x0020 8d a9 93 08 85 19 87 cf
0x0028 18 d5 f1 b5 3f 81 7c ce
0x0030 5a 00 4c f3 93 cc 89 58
0x0038 bd dc 06 5f 25 f8 4a f5
0x0040 09 b1 7d d3 67 64 18 de
0x0048 a3 55 43 79 56 61 79 01
0x0050 e0 69 57 fb ca 8a 6a 47
0x0058 a5 b5 15 3e 8d 3a b7
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics:</t>
<figure><artwork><![CDATA[ semantics, is:</t>
<artwork><![CDATA[
0x0000 c1 packet type: PKESK
0x0001 5d packet length
0x0002 06 PKESK version 6
0x0003 21 length of fingerprint
0x0004 06 Key version 6
0x0005 12 c8 3f Key fingerprint
0x0008 1e 70 6f 63 08 fe 15 1a
0x0010 41 77 43 a1 f0 33 79 0e
0x0018 93 e9 97 84 88 d1 db 37
0x0020 8d a9 93 08 85
0x0025 19 algorithm: X25519
0x0026 87 cf Ephemeral key
0x0028 18 d5 f1 b5 3f 81 7c ce
0x0030 5a 00 4c f3 93 cc 89 58
0x0038 bd dc 06 5f 25 f8 4a f5
0x0040 09 b1 7d d3 67 64
0x0046 18 ESK length
0x0047 de ESK
0x0048 a3 55 43 79 56 61 79 01
0x0050 e0 69 57 fb ca 8a 6a 47
0x0058 a5 b5 15 3e 8d 3a b7
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="x25519-encryptiondecryption-of-the-session-key"><name>X25519 encryption/decryption anchor="x25519-encryptiondecryption-of-the-session-key">
<name>X25519 Encryption/Decryption of the session key</name> Session Key</name>
<t>Ephemeral key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
87 cf 18 d5 f1 b5 3f 81 7c ce 5a 00 4c f3 93 cc
89 58 bd dc 06 5f 25 f8 4a f5 09 b1 7d d3 67 64
]]></artwork></figure>
]]></artwork>
<t>This ephemeral key is derived from the following ephemeral secret key material, which is never placed on the wire:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
af 1e 43 c0 d1 23 ef e8 93 a7 d4 d3 90 f3 a7 61
e3 fa c3 3d fc 7f 3e da a8 30 c9 01 13 52 c7 79
]]></artwork></figure>
]]></artwork>
<t>Public key from the target certificate (see <xref target="v6-cert"/>):</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
86 93 24 83 67 f9 e5 01 5d b9 22 f8 f4 80 95 dd
a7 84 98 7f 2d 59 85 b1 2f ba d1 6c af 5e 44 35
]]></artwork></figure>
]]></artwork>
<t>The corresponding long-lived X25519 private key material (see <xref target="v6-key"/>):</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
4d 60 0a 4f 79 4d 44 77 5c 57 a2 6e 0f ee fe d5
58 e9 af ff d6 ad 0d 58 2d 57 fb 2b a2 dc ed b8
]]></artwork></figure>
]]></artwork>
<t>Shared point:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
67 e3 0e 69 cd c7 ba b2 a2 68 0d 78 ac a4 6a 2f
8b 6e 2a e4 4d 39 8b dc 6f 92 c5 ad 4a 49 25 14
]]></artwork></figure>
]]></artwork>
<t>HKDF output:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
f6 6d ad cf f6 45 92 23 9b 25 45 39 b6 4f f6 07
]]></artwork></figure>
]]></artwork>
<t>Decrypted session key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
dd 70 8f 6f a1 ed 65 11 4d 68 d2 34 3e 7c 2f 1d
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="sample-v2-seipd-packet"><name>Sample anchor="sample-v2-seipd-packet">
<name>Sample v2 SEIPD packet</name> Packet</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork
<artwork name="x25519-v2seipd-aes128-ocb.hexdump"><![CDATA[
0x0000 d2 69 02 07 02 06 61 64
0x0008 16 53 5b e0 b0 71 6d 60
0x0010 e0 52 a5 6c 4c 40 7f 9e
0x0018 b3 6b 0e fa fe 9a d0 a0
0x0020 df 9b 03 3c 69 a2 1b a9
0x0028 eb d2 c0 ec 95 bf 56 9d
0x0030 25 c9 99 ee 4a 3d e1 70
0x0038 58 f4 0d fa 8b 4c 68 2b
0x0040 e3 fb bb d7 b2 7e b0 f5
0x0048 9b b5 00 5f 80 c7 c6 f4
0x0050 03 88 c3 0a d4 06 ab 05
0x0058 13 dc d6 f9 fd 73 76 56
0x0060 28 6e 11 77 d0 0f 88 8a
0x0068 db 31 c4
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics:</t>
<figure><artwork><![CDATA[ semantics, is:</t>
<artwork><![CDATA[
0x0000 d2 packet type: SEIPD
0x0001 69 packet length
0x0002 02 SEIPD version 2
0x0003 07 cipher: AES128
0x0004 02 AEAD mode: OCB
0x0005 06 chunk size (2**12 octets)
0x0006 61 64 salt
0x0008 16 53 5b e0 b0 71 6d 60
0x0010 e0 52 a5 6c 4c 40 7f 9e
0x0018 b3 6b 0e fa fe 9a d0 a0
0x0020 df 9b 03 3c 69 a2
0x0026 1b a9 chunk #0 encrypted data
0x0028 eb d2 c0 ec 95 bf 56 9d
0x0030 25 c9 99 ee 4a 3d e1 70
0x0038 58 f4 0d fa 8b 4c 68 2b
0x0040 e3 fb bb d7 b2 7e b0 f5
0x0048 9b b5 00
0x004b 5f 80 c7 c6 f4 chunk #0 AEAD tag
0x0050 03 88 c3 0a d4 06 ab 05
0x0058 13 dc d6
0x005b f9 fd 73 76 56 final AEAD tag (#1)
0x0060
S0x0060 28 6e 11 77 d0 0f 88 8a
0x0068 db 31 c4
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="decryption-of-data"><name>Decryption anchor="decryption-of-data">
<name>Decryption of data</name> Data</name>
<t>Starting AEAD-OCB decryption of data, using the session key.</t>
<t>HKDF info:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 02 06
]]></artwork></figure>
]]></artwork>
<t>HKDF output:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
45 12 f7 14 9d 86 33 41 52 7c 65 67 d5 bf fc 42
5f af 32 50 21 2f f9
]]></artwork></figure>
]]></artwork>
<t>Message key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
45 12 f7 14 9d 86 33 41 52 7c 65 67 d5 bf fc 42
]]></artwork></figure>
]]></artwork>
<t>Initialization vector:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
5f af 32 50 21 2f f9
]]></artwork></figure>
]]></artwork>
<t>Chunk #0:</t>
<t>Nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
5f af 32 50 21 2f f9 00 00 00 00 00 00 00 00
]]></artwork></figure>
]]></artwork>
<t>Additional authenticated data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 02 06
]]></artwork></figure>
]]></artwork>
<t>Encrypted data chunk:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
1b a9 eb d2 c0 ec 95 bf 56 9d 25 c9 99 ee 4a 3d
e1 70 58 f4 0d fa 8b 4c 68 2b e3 fb bb d7 b2 7e
b0 f5 9b b5 00 5f 80 c7 c6 f4 03 88 c3 0a d4 06
ab 05 13 dc d6
]]></artwork></figure>
]]></artwork>
<t>Decrypted chunk #0.</t>
<t>Literal data packet with the string contents <spanx style="verb">Hello, world!</spanx>:</t>
<figure><artwork><![CDATA[ <tt>Hello, world!</tt>:</t>
<artwork><![CDATA[
cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
6f 72 6c 64 21
]]></artwork></figure>
]]></artwork>
<t>Padding packet:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d5 0e c5 a2 93 07 29 91 62 81 47 d7 2c 8f 86 b7
]]></artwork></figure>
]]></artwork>
<t>Authenticating final tag:</t>
<t>Final nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
5f af 32 50 21 2f f9 00 00 00 00 00 00 00 01
]]></artwork></figure>
]]></artwork>
<t>Final additional authenticated data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 02 06 00 00 00 00 00 00 00 25
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="complete-x25519-aead-ocb-encrypted-packet-sequence"><name>Complete anchor="complete-x25519-aead-ocb-encrypted-packet-sequence">
<name>Complete X25519-AEAD-OCB encrypted packet sequence</name>
<figure><sourcecode Encrypted Packet Sequence</name>
<sourcecode type="application/pgp-encrypted" name="v6pkesk-aes128-ocb.pgp"><![CDATA[
-----BEGIN PGP MESSAGE-----
wV0GIQYSyD8ecG9jCP4VGkF3Q6HwM3kOk+mXhIjR2zeNqZMIhRmHzxjV8bU/gXzO
WgBM85PMiVi93AZfJfhK9QmxfdNnZBjeo1VDeVZheQHgaVf7yopqR6W1FT6NOrfS
aQIHAgZhZBZTW+CwcW1g4FKlbExAf56zaw76/prQoN+bAzxpohup69LA7JW/Vp0l
yZnuSj3hcFj0DfqLTGgr4/u717J+sPWbtQBfgMfG9AOIwwrUBqsFE9zW+f1zdlYo
bhF30A+IitsxxA==
-----END PGP MESSAGE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
</section>
<section anchor="sample-aead-eax-encryption-and-decryption"><name>Sample anchor="sample-aead-eax-encryption-and-decryption">
<name>Sample AEAD-EAX encryption Encryption and decryption</name> Decryption</name>
<t>This example encrypts the cleartext string <spanx style="verb">Hello, world!</spanx> <tt>Hello, world!</tt> with the passphrase <spanx style="verb">password</spanx>, <tt>password</tt>, using AES-128 with AEAD-EAX encryption.</t>
<section anchor="sample-symmetric-key-encrypted-session-key-packet-v6"><name>Sample symmetric-key encrypted session key packet anchor="sample-symmetric-key-encrypted-session-key-packet-v6">
<name>Sample Symmetric-Key Encrypted Session Key Packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork
<artwork name="v6skesk-aes128-eax.hexdump"><![CDATA[
0x0000 c3 40 06 1e 07 01 0b 03
0x0008 08 a5 ae 57 9d 1f c5 d8
0x0010 2b ff 69 22 4f 91 99 93
0x0018 b3 50 6f a3 b5 9a 6a 73
0x0020 cf f8 c5 ef c5 f4 1c 57
0x0028 fb 54 e1 c2 26 81 5d 78
0x0030 28 f5 f9 2c 45 4e b6 5e
0x0038 be 00 ab 59 86 c6 8e 6e
0x0040 7c 55
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics:</t>
<figure><artwork><![CDATA[ semantics, is:</t>
<artwork><![CDATA[
0x0000 c3 packet type: SKESK
0x0001 40 packet length
0x0002 06 SKESK version 6
0x0003 1e length through end of AEAD nonce
0x0004 07 cipher: AES128
0x0005 01 AEAD mode: EAX
0x0006 0b length of S2K
0x0007 03 S2K type: iterated+salted
0x0008 08 S2K hash: SHA2-256
0x0009 a5 ae 57 9d 1f c5 d8 S2K salt
0x0010 2b
0x0011 ff S2K iterations (65011712 octets)
0x0012 69 22 4f 91 99 93 AEAD nonce
0x0018 b3 50 6f a3 b5 9a 6a 73
0x0020 cf f8
0x0022 c5 ef c5 f4 1c 57 encrypted session key
0x0028 fb 54 e1 c2 26 81 5d 78
0x0030 28 f5
0x0032 f9 2c 45 4e b6 5e AEAD tag
0x0038 be 00 ab 59 86 c6 8e 6e
0x0040 7c 55
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="starting-aead-eax-decryption-of-the-session-key"><name>Starting anchor="starting-aead-eax-decryption-of-the-session-key">
<name>Starting AEAD-EAX decryption Decryption of the session key</name> Session Key</name>
<t>The derived key is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
15 49 67 e5 90 aa 1f 92 3e 1c 0a c6 4c 88 f2 3d
]]></artwork></figure>
]]></artwork>
<t>HKDF info:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
c3 06 07 01
]]></artwork></figure>
]]></artwork>
<t>HKDF output:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
2f ce 33 1f 39 dd 95 5c c4 1e 95 d8 70 c7 21 39
]]></artwork></figure>
]]></artwork>
<t>Authenticated Data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
c3 06 07 01
]]></artwork></figure>
]]></artwork>
<t>Nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
69 22 4f 91 99 93 b3 50 6f a3 b5 9a 6a 73 cf f8
]]></artwork></figure>
]]></artwork>
<t>Decrypted session key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
38 81 ba fe 98 54 12 45 9b 86 c3 6f 98 cb 9a 5e
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="sample-v2-seipd-packet-1"><name>Sample anchor="sample-v2-seipd-packet-1">
<name>Sample v2 SEIPD packet</name> Packet</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork
<artwork name="v2seipd-aes128-eax.hexdump"><![CDATA[
0x0000 d2 69 02 07 01 06 9f f9
0x0008 0e 3b 32 19 64 f3 a4 29
0x0010 13 c8 dc c6 61 93 25 01
0x0018 52 27 ef b7 ea ea a4 9f
0x0020 04 c2 e6 74 17 5d 4a 3d
0x0028 22 6e d6 af cb 9c a9 ac
0x0030 12 2c 14 70 e1 1c 63 d4
0x0038 c0 ab 24 1c 6a 93 8a d4
0x0040 8b f9 9a 5a 99 b9 0b ba
0x0048 83 25 de 61 04 75 40 25
0x0050 8a b7 95 9a 95 ad 05 1d
0x0058 da 96 eb 15 43 1d fe f5
0x0060 f5 e2 25 5c a7 82 61 54
0x0068 6e 33 9a
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics:</t>
<figure><artwork><![CDATA[ semantics, is:</t>
<artwork><![CDATA[
0x0000 d2 packet type: SEIPD
0x0001 69 packet length
0x0002 02 SEIPD version 2
0x0003 07 cipher: AES128
0x0004 01 AEAD mode: EAX
0x0005 06 chunk size (2**12 octets)
0x0005 9f f9 salt
0x0008 0e 3b 32 19 64 f3 a4 29
0x0010 13 c8 dc c6 61 93 25 01
0x0018 52 27 ef b7 ea ea a4 9f
0x0020 04 c2 e6 74 17 5d
0x0026 4a 3d chunk #0 encrypted data
0x0028 22 6e d6 af cb 9c a9 ac
0x0030 12 2c 14 70 e1 1c 63 d4
0x0038 c0 ab 24 1c 6a 93 8a d4
0x0040 8b f9 9a 5a 99 b9 0b ba
0x0048 83 25 de
0x004b 61 04 75 40 25 chunk #0 AEAD tag
0x0050 8a b7 95 9a 95 ad 05 1d
0x0058 da 96 eb
0x005b 15 43 1d fe f5 final AEAD tag (#1)
0x0060 f5 e2 25 5c a7 82 61 54
0x0068 6e 33 9a
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="decryption-of-data-1"><name>Decryption anchor="decryption-of-data-1">
<name>Decryption of data</name> Data</name>
<t>Starting AEAD-EAX decryption of data, using the session key.</t>
<t>HKDF info:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 01 06
]]></artwork></figure>
]]></artwork>
<t>HKDF output:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f
78 b8 33 f2 e9 4a 60 c0
]]></artwork></figure>
]]></artwork>
<t>Message key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f
]]></artwork></figure>
]]></artwork>
<t>Initialization vector:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
78 b8 33 f2 e9 4a 60 c0
]]></artwork></figure>
]]></artwork>
<t>Chunk #0:</t>
<t>Nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 00
]]></artwork></figure>
]]></artwork>
<t>Additional authenticated data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 01 06
]]></artwork></figure>
]]></artwork>
<t>Decrypted chunk #0.</t>
<t>Literal data packet with the string contents <spanx style="verb">Hello, world!</spanx>:</t>
<figure><artwork><![CDATA[ <tt>Hello, world!</tt>:</t>
<artwork><![CDATA[
cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
6f 72 6c 64 21
]]></artwork></figure>
]]></artwork>
<t>Padding packet:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d5 0e ae 5b f0 cd 67 05 50 03 55 81 6c b0 c8 ff
]]></artwork></figure>
]]></artwork>
<t>Authenticating final tag:</t>
<t>Final nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 01
]]></artwork></figure>
]]></artwork>
<t>Final additional authenticated data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 01 06 00 00 00 00 00 00 00 25
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="complete-aead-eax-encrypted-packet-sequence"><name>Complete anchor="complete-aead-eax-encrypted-packet-sequence">
<name>Complete AEAD-EAX encrypted packet sequence</name>
<figure><sourcecode Encrypted Packet Sequence</name>
<sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-eax.pgp"><![CDATA[
-----BEGIN PGP MESSAGE-----
w0AGHgcBCwMIpa5XnR/F2Cv/aSJPkZmTs1Bvo7WaanPP+MXvxfQcV/tU4cImgV14
KPX5LEVOtl6+AKtZhsaObnxV0mkCBwEGn/kOOzIZZPOkKRPI3MZhkyUBUifvt+rq
pJ8EwuZ0F11KPSJu1q/LnKmsEiwUcOEcY9TAqyQcapOK1Iv5mlqZuQu6gyXeYQR1
QCWKt5Wala0FHdqW6xVDHf719eIlXKeCYVRuM5o=
-----END PGP MESSAGE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
</section>
<section anchor="sample-aead-ocb-encryption-and-decryption"><name>Sample anchor="sample-aead-ocb-encryption-and-decryption">
<name>Sample AEAD-OCB encryption Encryption and decryption</name> Decryption</name>
<t>This example encrypts the cleartext string <spanx style="verb">Hello, world!</spanx> <tt>Hello, world!</tt> with the passphrase <spanx style="verb">password</spanx>, <tt>password</tt>, using AES-128 with AEAD-OCB encryption.</t>
<section anchor="sample-symmetric-key-encrypted-session-key-packet-v6-1"><name>Sample symmetric-key encrypted session key packet anchor="sample-symmetric-key-encrypted-session-key-packet-v6-1">
<name>Sample Symmetric-Key Encrypted Session Key Packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork
<artwork name="v6skesk-aes128-ocb.hexdump"><![CDATA[
0x0000 c3 3f 06 1d 07 02 0b 03
0x0008 08 56 a2 98 d2 f5 e3 64
0x0010 53 ff cf cc 5c 11 66 4e
0x0018 db 9d b4 25 90 d7 dc 46
0x0020 b0 72 41 b6 12 c3 81 2c
0x0028 ff fb ea 00 f2 34 7b 25
0x0030 64 11 23 f8 87 ae 60 d4
0x0038 fd 61 4e 08 37 d8 19 d3
0x0040 6c
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics:</t>
<figure><artwork><![CDATA[ semantics, is:</t>
<artwork><![CDATA[
0x0000 c3 packet type: SKESK
0x0001 3f packet length
0x0002 06 SKESK version 6
0x0003 1d length through end of AEAD nonce
0x0004 07 cipher: AES128
0x0005 02 AEAD mode: OCB
0x0006 0b length of S2K
0x0007 03 S2K type: iterated+salted
0x0008 08 S2K hash: SHA2-256
0x0009 56 a2 98 d2 f5 e3 64 S2K salt
0x0010 53
0x0011 ff S2K iterations (65011712 octets)
0x0012 cf cc 5c 11 66 4e AEAD nonce
0x0018 db 9d b4 25 90 d7 dc 46
0x0020 b0
0x0021 72 41 b6 12 c3 81 2c encrypted session key
0x0028 ff fb ea 00 f2 34 7b 25
0x0030 64
0x0031 11 23 f8 87 ae 60 d4 AEAD tag
0x0038 fd 61 4e 08 37 d8 19 d3
0x0040 6c
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="starting-aead-ocb-decryption-of-the-session-key"><name>Starting anchor="starting-aead-ocb-decryption-of-the-session-key">
<name>Starting AEAD-OCB decryption Decryption of the session key</name> Session Key</name>
<t>The derived key is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
e8 0d e2 43 a3 62 d9 3b 9d c6 07 ed e9 6a 73 56
]]></artwork></figure>
]]></artwork>
<t>HKDF info:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
c3 06 07 02
]]></artwork></figure>
]]></artwork>
<t>HKDF output:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
38 a9 b3 45 b5 68 0b b6 1b b6 5d 73 ee c7 ec d9
]]></artwork></figure>
]]></artwork>
<t>Authenticated Data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
c3 06 07 02
]]></artwork></figure>
]]></artwork>
<t>Nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
cf cc 5c 11 66 4e db 9d b4 25 90 d7 dc 46 b0
]]></artwork></figure>
]]></artwork>
<t>Decrypted session key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
28 e7 9a b8 23 97 d3 c6 3d e2 4a c2 17 d7 b7 91
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="sample-v2-seipd-packet-2"><name>Sample anchor="sample-v2-seipd-packet-2">
<name>Sample v2 SEIPD packet</name> Packet</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork
<artwork name="v2seipd-aes128-ocb.hexdump"><![CDATA[
0x0000 d2 69 02 07 02 06 20 a6
0x0008 61 f7 31 fc 9a 30 32 b5
0x0010 62 33 26 02 7e 3a 5d 8d
0x0018 b5 74 8e be ff 0b 0c 59
0x0020 10 d0 9e cd d6 41 ff 9f
0x0028 d3 85 62 75 80 35 bc 49
0x0030 75 4c e1 bf 3f ff a7 da
0x0038 d0 a3 b8 10 4f 51 33 cf
0x0040 42 a4 10 0a 83 ee f4 ca
0x0048 1b 48 01 a8 84 6b f4 2b
0x0050 cd a7 c8 ce 9d 65 e2 12
0x0058 f3 01 cb cd 98 fd ca de
0x0060 69 4a 87 7a d4 24 73 23
0x0068 f6 e8 57
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics:</t>
<figure><artwork><![CDATA[ semantics, is:</t>
<artwork><![CDATA[
0x0000 d2 packet type: SEIPD
0x0001 69 packet length
0x0002 02 SEIPD version 2
0x0003 07 cipher: AES128
0x0004 02 AEAD mode: OCB
0x0005 06 chunk size (2**21 octets)
0x0006 20 a6 salt
0x0008 61 f7 31 fc 9a 30 32 b5
0x0010 62 33 26 02 7e 3a 5d 8d
0x0018 b5 74 8e be ff 0b 0c 59
0x0020 10 d0 9e cd d6 41
0x0026 ff 9f chunk #0 encrypted data
0x0028 d3 85 62 75 80 35 bc 49
0x0030 75 4c e1 bf 3f ff a7 da
0x0038 d0 a3 b8 10 4f 51 33 cf
0x0040 42 a4 10 0a 83 ee f4 ca
0x0048 1b 48 01
0x004b a8 84 6b f4 2b chunk #0 authentication tag
0x0050 cd a7 c8 ce 9d 65 e2 12
0x0058 f3 01 cb
0x005b cd 98 fd ca de final AEAD tag (#1)
0x0060 69 4a 87 7a d4 24 73 23
0x0068 f6 e8 57
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="decryption-of-data-2"><name>Decryption anchor="decryption-of-data-2">
<name>Decryption of data</name> Data</name>
<t>Starting AEAD-OCB decryption of data, using the session key.</t>
<t>HKDF info:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 02 06
]]></artwork></figure>
]]></artwork>
<t>HKDF output:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99
eb de 12 bb 57 0d cf
]]></artwork></figure>
]]></artwork>
<t>Message key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99
]]></artwork></figure>
]]></artwork>
<t>Initialization vector:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
eb de 12 bb 57 0d cf
]]></artwork></figure>
]]></artwork>
<t>Chunk #0:</t>
<t>Nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 00
]]></artwork></figure>
]]></artwork>
<t>Additional authenticated data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 02 06
]]></artwork></figure>
]]></artwork>
<t>Decrypted chunk #0.</t>
<t>Literal data packet with the string contents <spanx style="verb">Hello, world!</spanx>:</t>
<figure><artwork><![CDATA[ <tt>Hello, world!</tt>:</t>
<artwork><![CDATA[
cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
6f 72 6c 64 21
]]></artwork></figure>
]]></artwork>
<t>Padding packet:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d5 0e ae 6a a1 64 9b 56 aa 83 5b 26 13 90 2b d2
]]></artwork></figure>
]]></artwork>
<t>Authenticating final tag:</t>
<t>Final nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 01
]]></artwork></figure>
]]></artwork>
<t>Final additional authenticated data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 02 06 00 00 00 00 00 00 00 25
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="complete-aead-ocb-encrypted-packet-sequence"><name>Complete anchor="complete-aead-ocb-encrypted-packet-sequence">
<name>Complete AEAD-OCB encrypted packet sequence</name>
<figure><sourcecode Encrypted Packet Sequence</name>
<sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-ocb.pgp"><![CDATA[
-----BEGIN PGP MESSAGE-----
wz8GHQcCCwMIVqKY0vXjZFP/z8xcEWZO2520JZDX3EawckG2EsOBLP/76gDyNHsl
ZBEj+IeuYNT9YU4IN9gZ02zSaQIHAgYgpmH3MfyaMDK1YjMmAn46XY21dI6+/wsM
WRDQns3WQf+f04VidYA1vEl1TOG/P/+n2tCjuBBPUTPPQqQQCoPu9MobSAGohGv0
K82nyM6dZeIS8wHLzZj9yt5pSod61CRzI/boVw==
-----END PGP MESSAGE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
</section>
<section anchor="sample-aead-gcm-encryption-and-decryption"><name>Sample anchor="sample-aead-gcm-encryption-and-decryption">
<name>Sample AEAD-GCM encryption Encryption and decryption</name> Decryption</name>
<t>This example encrypts the cleartext string <spanx style="verb">Hello, world!</spanx> <tt>Hello, world!</tt> with the passphrase <spanx style="verb">password</spanx>, <tt>password</tt>, using AES-128 with AEAD-GCM encryption.</t>
<section anchor="sample-symmetric-key-encrypted-session-key-packet-v6-2"><name>Sample symmetric-key encrypted session key packet anchor="sample-symmetric-key-encrypted-session-key-packet-v6-2">
<name>Sample Symmetric-Key Encrypted Session Key Packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork
<artwork name="v6skesk-aes128-gcm.hexdump"><![CDATA[
0x0000 c3 3c 06 1a 07 03 0b 03
0x0008 08 e9 d3 97 85 b2 07 00
0x0010 08 ff b4 2e 7c 48 3e f4
0x0018 88 44 57 cb 37 26 b9 b3
0x0020 db 9f f7 76 e5 f4 d9 a4
0x0028 09 52 e2 44 72 98 85 1a
0x0030 bf ff 75 26 df 2d d5 54
0x0038 41 75 79 a7 79 9f
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics:</t>
<figure><artwork><![CDATA[ semantics, is:</t>
<artwork><![CDATA[
0x0000 c3 packet type: SKESK
0x0001 3c packet length
0x0002 06 SKESK version 6
0x0003 1a length through end of AEAD nonce
0x0004 07 cipher: AES128
0x0005 03 AEAD mode: GCM
0x0006 0b length of S2K
0x0007 03 S2K type: iterated+salted
0x0008 08 S2K hash: SHA2-256
0x0009 e9 d3 97 85 b2 07 00 S2K salt
0x0010 08
0x0011 ff S2K iterations (65011712 octets)
0x0012 b4 2e 7c 48 3e f4 AEAD nonce
0x0018 88 44 57 cb 37 26
0x001e b9 b3 encrypted session key
0x0020 db 9f f7 76 e5 f4 d9 a4
0x0028 09 52 e2 44 72 98
0x002e 85 1a AEAD tag
0x0030 bf ff 75 26 df 2d d5 54
0x0038 41 75 79 a7 79 9f
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="starting-aead-gcm-decryption-of-the-session-key"><name>Starting anchor="starting-aead-gcm-decryption-of-the-session-key">
<name>Starting AEAD-GCM decryption Decryption of the session key</name> Session Key</name>
<t>The derived key is:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
25 02 81 71 5b ba 78 28 ef 71 ef 64 c4 78 47 53
]]></artwork></figure>
]]></artwork>
<t>HKDF info:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
c3 06 07 03
]]></artwork></figure>
]]></artwork>
<t>HKDF output:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
7a 6f 9a b7 f9 9f 7e f8 db ef 84 1c 65 08 00 f5
]]></artwork></figure>
]]></artwork>
<t>Authenticated Data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
c3 06 07 03
]]></artwork></figure>
]]></artwork>
<t>Nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
b4 2e 7c 48 3e f4 88 44 57 cb 37 26
]]></artwork></figure>
]]></artwork>
<t>Decrypted session key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
19 36 fc 85 68 98 02 74 bb 90 0d 83 19 36 0c 77
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="sample-v2-seipd-packet-3"><name>Sample anchor="sample-v2-seipd-packet-3">
<name>Sample v2 SEIPD packet</name> Packet</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork octets, is:</t>
<artwork name="v2seipd-aes128-ocb.hexdump"><![CDATA[
0x0000 d2 69 02 07 03 06 fc b9
0x0008 44 90 bc b9 8b bd c9 d1
0x0010 06 c6 09 02 66 94 0f 72
0x0018 e8 9e dc 21 b5 59 6b 15
0x0020 76 b1 01 ed 0f 9f fc 6f
0x0028 c6 d6 5b bf d2 4d cd 07
0x0030 90 96 6e 6d 1e 85 a3 00
0x0038 53 78 4c b1 d8 b6 a0 69
0x0040 9e f1 21 55 a7 b2 ad 62
0x0048 58 53 1b 57 65 1f d7 77
0x0050 79 12 fa 95 e3 5d 9b 40
0x0058 21 6f 69 a4 c2 48 db 28
0x0060 ff 43 31 f1 63 29 07 39
0x0068 9e 6f f9
]]></artwork></figure>
]]></artwork>
<t>The same data, broken out by octet and semantics:</t>
<figure><artwork><![CDATA[ semantics, is:</t>
<artwork><![CDATA[
0x0000 d2 packet type: SEIPD
0x0001 69 packet length
0x0002 02 SEIPD version 2
0x0003 07 cipher: AES128
0x0004 03 AEAD mode: GCM
0x0005 06 chunk size (2**21 octets)
0x0006 fc b9 salt
0x0008 44 90 bc b9 8b bd c9 d1
0x0010 06 c6 09 02 66 94 0f 72
0x0018 e8 9e dc 21 b5 59 6b 15
0x0020 76 b1 01 ed 0f 9f
0x0026 fc 6f chunk #0 encrypted data
0x0028 c6 d6 5b bf d2 4d cd 07
0x0030 90 96 6e 6d 1e 85 a3 00
0x0038 53 78 4c b1 d8 b6 a0 69
0x0040 9e f1 21 55 a7 b2 ad 62
0x0048 58 53 1b
0x004b 57 65 1f d7 77 chunk #0 authentication tag
0x0050 79 12 fa 95 e3 5d 9b 40
0x0058 21 6f 69
0x005b a4 c2 48 db 28 final AEAD tag (#1)
0x0060 ff 43 31 f1 63 29 07 39
0x0068 9e 6f f9
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="decryption-of-data-3"><name>Decryption anchor="decryption-of-data-3">
<name>Decryption of data</name> Data</name>
<t>Starting AEAD-GCM decryption of data, using the session key.</t>
<t>HKDF info:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 03 06
]]></artwork></figure>
]]></artwork>
<t>HKDF output:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d
4d 2b dc 2b
]]></artwork></figure>
]]></artwork>
<t>Message key:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d
]]></artwork></figure>
]]></artwork>
<t>Initialization vector:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
4d 2b dc 2b
]]></artwork></figure>
]]></artwork>
<t>Chunk #0:</t>
<t>Nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
4d 2b dc 2b 00 00 00 00 00 00 00 00
]]></artwork></figure>
]]></artwork>
<t>Additional authenticated data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 03 06
]]></artwork></figure>
]]></artwork>
<t>Decrypted chunk #0.</t>
<t>Literal data packet with the string contents <spanx style="verb">Hello, world!</spanx>:</t>
<figure><artwork><![CDATA[ <tt>Hello, world!</tt>:</t>
<artwork><![CDATA[
cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
6f 72 6c 64 21
]]></artwork></figure>
]]></artwork>
<t>Padding packet:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d5 0e 1c e2 26 9a 9e dd ef 81 03 21 72 b7 ed 7c
]]></artwork></figure>
]]></artwork>
<t>Authenticating final tag:</t>
<t>Final nonce:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
4d 2b dc 2b 00 00 00 00 00 00 00 01
]]></artwork></figure>
]]></artwork>
<t>Final additional authenticated data:</t>
<figure><artwork><![CDATA[
<artwork><![CDATA[
d2 02 07 03 06 00 00 00 00 00 00 00 25
]]></artwork></figure>
]]></artwork>
</section>
<section anchor="complete-aead-gcm-encrypted-packet-sequence"><name>Complete anchor="complete-aead-gcm-encrypted-packet-sequence">
<name>Complete AEAD-GCM encrypted packet sequence</name>
<figure><sourcecode Encrypted Packet Sequence</name>
<sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-gcm.pgp"><![CDATA[
-----BEGIN PGP MESSAGE-----
wzwGGgcDCwMI6dOXhbIHAAj/tC58SD70iERXyzcmubPbn/d25fTZpAlS4kRymIUa
v/91Jt8t1VRBdXmneZ/SaQIHAwb8uUSQvLmLvcnRBsYJAmaUD3LontwhtVlrFXax
Ae0Pn/xvxtZbv9JNzQeQlm5tHoWjAFN4TLHYtqBpnvEhVaeyrWJYUxtXZR/Xd3kS
+pXjXZtAIW9ppMJI2yj/QzHxYykHOZ5v+Q==
-----END PGP MESSAGE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
</section>
<section anchor="sample-messages-encrypted-using-argon2"><name>Sample messages encrypted using anchor="sample-messages-encrypted-using-argon2">
<name>Sample Messages Encrypted Using Argon2</name>
<t>These messages are the literal data "Hello, world!" encrypted using v1 SEIPD, with Argon2 and the passphrase "password", using different session key sizes.
In each example, the choice of symmetric cipher is the same in both the v4 SKESK packet and v1 SEIPD packet.
In all cases, the Argon2 parameters are t = 1, p = 4, and m = 21.</t>
<section anchor="version-4-skesk-using-argon2-with-aes-128"><name>Version anchor="version-4-skesk-using-argon2-with-aes-128">
<name>Version 4 SKESK using Using Argon2 with AES-128</name>
<figure><sourcecode
<sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes128.pgp"><![CDATA[
-----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 128-bit key
Comment: Session key: 01FE16BBACFD1E7B78EF3B865187374F
wycEBwScUvg8J/leUNU1RA7N/zE2AQQVnlL8rSLPP5VlQsunlO+ECxHSPgGYGKY+
YJz4u6F+DDlDBOr5NRQXt/KJIf4m4mOlKyC/uqLbpnLJZMnTq3o79GxBTdIdOzhH
XfA3pqV4mTzF
-----END PGP MESSAGE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
<section anchor="version-4-skesk-using-argon2-with-aes-192"><name>Version anchor="version-4-skesk-using-argon2-with-aes-192">
<name>Version 4 SKESK using Using Argon2 with AES-192</name>
<figure><sourcecode
<sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes192.pgp"><![CDATA[
-----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 192-bit key
Comment: Session key: 27006DAE68E509022CE45A14E569E91001C2955...
Comment: Session key: ...AF8DFE194
wy8ECAThTKxHFTRZGKli3KNH4UP4AQQVhzLJ2va3FG8/pmpIPd/H/mdoVS5VBLLw
F9I+AdJ1Sw56PRYiKZjCvHg+2bnq02s33AJJoyBexBI4QKATFRkyez2gldJldRys
LVg77Mwwfgl2n/d572WciAM=
-----END PGP MESSAGE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
<section anchor="version-4-skesk-using-argon2-with-aes-256"><name>Version anchor="version-4-skesk-using-argon2-with-aes-256">
<name>Version 4 SKESK using Using Argon2 with AES-256</name>
<figure><sourcecode
<sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes256.pgp"><![CDATA[
-----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 256-bit key
Comment: Session key: BBEDA55B9AAE63DAC45D4F49D89DACF4AF37FEF...
Comment: Session key: ...C13BAB2F1F8E18FB74580D8B0
wzcECQS4eJUgIG/3mcaILEJFpmJ8AQQVnZ9l7KtagdClm9UaQ/Z6M/5roklSGpGu
623YmaXezGj80j4B+Ku1sgTdJo87X1Wrup7l0wJypZls21Uwd67m9koF60eefH/K
95D1usliXOEm8ayQJQmZrjf6K6v9PWwqMQ==
-----END PGP MESSAGE-----
]]></sourcecode></figure>
]]></sourcecode>
</section>
</section>
</section>
<section anchor="upgrade-guidance"><name>Upgrade anchor="upgrade-guidance">
<name>Upgrade Guidance (Adapting Implementations from RFC RFCs 4880 and RFC 6637)</name>
<t>This subsection offers a concise, non-normative summary of the substantial additions to and departures from <xref target="RFC4880"/> and <xref target="RFC6637"/>.
It is intended to help implementers who are augmenting an existing implementation from those standards specifications to comply with this standard. specification. Cryptographic algorithms marked with "MTI" are mandatory to implement.</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>Public Key signing algorithms:
<list style="symbols"> Signing Algorithms:
</t>
<ul spacing="normal">
<li>
<t>Ed25519 (<xref target="key-ed25519"/> (Sections <xref target="key-ed25519" format="counter"/> and <xref target="sig-ed25519"/>), target="sig-ed25519" format="counter"/>) -- MTI</t>
</li>
<li>
<t>Ed448 (<xref target="key-ed448"/> (Sections <xref target="key-ed448" format="counter"/> and <xref target="sig-ed448"/>)</t> target="sig-ed448" format="counter"/>)</t>
</li>
<li>
<t>EdDSALegacy with Ed25519Legacy (<xref target="key-eddsa-legacy"/> (Sections <xref target="key-eddsa-legacy" format="counter"/> and <xref target="sig-eddsa-legacy"/>)</t> target="sig-eddsa-legacy" format="counter"/>)</t>
</li>
<li>
<t>ECDSA with Brainpool curves (<xref target="ec-curves"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Public Key encryption algorithms:
<list style="symbols"> Encryption Algorithms:
</t>
<ul spacing="normal">
<li>
<t>X25519 (<xref target="key-x25519"/> (Sections <xref target="key-x25519" format="counter"/> and <xref target="pkesk-x25519"/>), target="pkesk-x25519" format="counter"/>) -- MTI</t>
</li>
<li>
<t>X448 (<xref target="key-x448"/> (Sections <xref target="key-x448" format="counter"/> and <xref target="pkesk-x448"/>)</t> target="pkesk-x448" format="counter"/>)</t>
</li>
<li>
<t>ECDH with Curve25519Legacy (<xref target="ec-curves"/>)</t>
</li>
<li>
<t>ECDH with Brainpool curves (<xref target="ec-curves"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>AEAD Encryption:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Version 2 SEIPD (<xref target="version-two-seipd"/>)</t>
</li>
<li>
<t>AEAD modes:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>OCB mode (<xref target="aead-mode-ocb"/>), target="aead-mode-ocb"/>) -- MTI</t>
</li>
<li>
<t>EAX mode (<xref target="aead-mode-eax"/>)</t>
</li>
<li>
<t>GCM mode (<xref target="aead-mode-gcm"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Version 6 PKESK (<xref target="v6-pkesk"/>)</t>
</li>
<li>
<t>Version 6 SKESK (<xref target="v6-skesk"/>)</t>
</li>
<li>
<t>Features subpacket: add flag for SEIPDv2 (<xref target="features-subpacket"/>)</t>
</li>
<li>
<t>Subpacket: Preferred AEAD Ciphersuites (<xref target="preferred-v2-seipd"/>)</t>
</li>
<li>
<t>Secret key encryption: AEAD "S2K usage octet" (<xref target="s2k-usage-octet"/> (Sections <xref target="s2k-usage-octet" format="counter"/> and <xref target="secret-key-packet-formats"/>)</t>
</list></t> target="secret-key-packet-formats" format="counter"/>)</t>
</li>
</ul>
</li>
<li>
<t>Version 6 Keys and Signatures:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Version 6 Public keys (<xref target="v6-pubkeys"/>)</t>
</li>
<li>
<t>Version 6 Fingerprint and Key ID (<xref target="v6-key-id-fingerprint"/>)</t>
</li>
<li>
<t>Version 6 Secret keys (<xref target="secret-key-packet-formats"/>)</t>
</li>
<li>
<t>Version 6 Signatures (<xref target="version-four-and-six-sig"/>)</t>
</li>
<li>
<t>Version 6 One-Pass Signatures (<xref target="one-pass-sig"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Certificate (Transferable Public Key) Structure:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Preferences subpackets in Direct Key Signatures (<xref target="self-sigs"/>)</t>
</li>
<li>
<t>Self-verifying revocation certificate (<xref target="v6-revocation-certificate"/>)</t>
</li>
<li>
<t>User ID is explicitly optional (<xref target="v6-certificate-structures"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>S2K: Argon2 (<xref target="s2k-argon2"/>)</t>
</li>
<li>
<t>Subpacket: Intended Recipient Fingerprint (<xref target="intended-recipient-fingerprint"/>)</t>
</li>
<li>
<t>Digest algorithms: Algorithms: SHA3-256 and SHA3-512 (<xref target="hash-algos"/>)</t>
</li>
<li>
<t>Packet: Padding (<xref target="padding-packet"/>)</t>
</li>
<li>
<t>Message structure: Structure: Packet Criticality (<xref target="packet-criticality"/>)</t>
</li>
<li>
<t>Deprecations:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Public Key Algorithms:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Avoid RSA weak keys (<xref target="rsa-notes"/>)</t>
</li>
<li>
<t>Avoid DSA (<xref target="dsa-notes"/>)</t>
</li>
<li>
<t>Avoid ElGamal (<xref target="elgamal-notes"/>, (Sections <xref target="elgamal-notes" format="counter"/> and <xref target="pkesk-elgamal"/>)</t> target="pkesk-elgamal" format="counter"/>)</t>
</li>
<li>
<t>For Version 6 Keys: Avoid EdDSA25519Legacy, EdDSA25519Legacy and Curve25519Legacy (<xref target="ec-curves"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Digest Algorithms:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Avoid MD5, SHA1, and RIPEMD160 (<xref target="hash-algos"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Symmetric Key Algorithms:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Avoid IDEA, TripleDES, and CAST5 (<xref target="symmetric-algos"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>S2K Specifier:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Avoid Simple S2K (<xref target="s2k-simple"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Secret Key protections (a.k.a. S2K Protections (a.k.a. S2K Usage):
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Avoid MalleableCFB (<xref target="secret-key-encryption"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Packet Types:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Avoid Symmetrically-Encrypted Symmetrically Encrypted Data (<xref target="sed"/>, (Sections <xref target="ciphertext-malleability"/>)</t>
</list></t> target="sed" format="counter"/> and <xref target="ciphertext-malleability" format="counter"/>)</t>
</li>
</ul>
</li>
<li>
<t>Literal Data packet metadata:
<list style="symbols"> Packet Metadata:
</t>
<ul spacing="normal">
<li>
<t>Avoid Filename and Date fields (<xref target="lit"/>)</t>
</li>
<li>
<t>Avoid Special <spanx style="verb">_CONSOLE</spanx> <tt>_CONSOLE</tt> "filename" (<xref target="for-eyes-only"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Packet Versions:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Avoid Version 3 Public Keys (<xref target="v3-pubkeys"/>)</t>
</li>
<li>
<t>Avoid Version 3 Signatures (<xref target="signature-packet"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Signature Types:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>Avoid Reserved Signature Type type ID 0xFF (<xref target="sigtype-reserved"/>, (Sections <xref target="sigtype-reserved" format="counter"/> and <xref target="sig-computation-notes"/>)</t>
</list></t> target="sig-computation-notes" format="counter"/>)</t>
</li>
</ul>
</li>
<li>
<t>Signature Subpackets:
<list style="symbols">
</t>
<ul spacing="normal">
<li>
<t>For Version 6 Signatures: Avoid Issuer Key ID (<xref target="issuer-keyid-subpacket"/>)</t>
</li>
<li>
<t>Avoid Revocation Key (<xref target="revocation-key"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>ASCII Armor:
<list style="symbols">
<t>Ignore,
</t>
<ul spacing="normal">
<li>
<t>Ignore; do not emit CRC (<xref target="optional-crc24"/>)</t>
</li>
<li>
<t>Do not emit "Version" armor header (<xref target="armor-header-key-version"/>)</t>
</list></t>
</li>
</ul>
</li>
<li>
<t>Cleartext Signature Framework:
<list style="symbols">
<t>Ignore,
</t>
<ul spacing="normal">
<li>
<t>Ignore; avoid emitting unnecessary Hash: headers (<xref target="armor-header-key-hash"/>)</t>
</li>
<li>
<t>Reject CSF signatures with invalid Hash: headers (<xref target="armor-header-key-hash"/>) or any other Armor Header (<xref target="cleartext-structure"/>)</t>
</list></t>
</list></t>
</list></t>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<section anchor="terminology-changes"><name>Terminology anchor="terminology-changes">
<name>Terminology Changes</name>
<t>Note that some of the words used in previous revisions versions of the OpenPGP standard specification have been improved in this document.</t>
<t>In previous revisions, versions, the following terms were used:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t>"Radix-64" was used to refer to OpenPGP's ASCII Armor base64 encoding (<xref target="base64"/>).</t>
</li>
<li>
<t>"Old packet format" was used to refer to the Legacy packet format (<xref target="legacy-packet-format"/>) predating <xref target="RFC2440"/>.</t>
</li>
<li>
<t>"New packet format" was used to refer to the OpenPGP packet format (<xref target="openpgp-packet-format"/>) introduced in <xref target="RFC2440"/>.</t>
</li>
<li>
<t>"Certificate" was used ambiguously to mean multiple things.
In this document, it is used to mean means "Transferable Public Key" exclusively.</t>
</li>
<li>
<t>"Preferred Symmetric Algorithms" was the old name for the "Preferred Symmetric Ciphers for v1 SEIPD" subpacket (<xref target="preferred-v1-seipd"/>)</t> target="preferred-v1-seipd"/>).</t>
</li>
<li>
<t>"Modification Detection Code" or "MDC" was originally described as a distinct packet (packet type ID 19), and its corresponding flag in the Features subpacket (<xref target="features-subpacket"/>) was known as "Modification Detection".
It is now described as an intrinsic part of v1 SEIPD (<xref target="version-one-seipd"/>), and the same corresponding flag is known as "Symmetrically Encrypted Integrity Protected Data packet version 1".</t>
</li>
<li>
<t>"Packet Tag" was used to refer to the Packet Type ID (<xref target="packet-types"/>), target="packet-types"/>) or sometimes to the encoded Packet Type ID (<xref target="packet-headers"/>).</t>
</list></t>
</section>
</li>
</ul>
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>Thanks to the openpgp design team for working on this document to prepare it for working group consumption: Stephen Farrell, Daniel Kahn Gillmor, Daniel Huigens, Jeffrey Lau, Yutaka Niibe, Justus Winter and Paul Wouters.</t>
<t>Thanks to Werner Koch for the early work on rfc4880bis and Andrey Jivsov for <xref target="RFC6637"/>.</t>
<t>This document also draws on much previous work from a number of other authors, including: Derek Atkins, Charles Breed, Dave Del Torto, Marc Dyksterhouse, Gail Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, Raph Levien, Colin Plumb, Will Price, David Shaw, William Stallings, Mark Weaver, and Philip R. Zimmermann.</t>
</section>
<section anchor="errata-listing"><name>Errata addressed anchor="errata-listing">
<name>Errata Addressed by this document</name> This Document</name>
<t>The following verified errata have been incorporated or are otherwise resolved by this document:</t>
<t><list style="symbols">
<ul spacing="normal">
<li>
<t><xref target="Errata-2199"/> - S2K hash/cipher octet correction</t>
</li>
<li>
<t><xref target="Errata-2200"/> - No implicit use of IDEA correction</t>
</li>
<li>
<t><xref target="Errata-2206"/> - PKESK acronym expansion</t>
</li>
<li>
<t><xref target="Errata-2208"/> - Signature key owner clarification</t>
</li>
<li>
<t><xref target="Errata-2214"/> - Signature hashing clarification</t>
</li>
<li>
<t><xref target="Errata-2216"/> - Self signature Self-signature applies to user ID correction</t>
</li>
<li>
<t><xref target="Errata-2219"/> - Session key encryption storage clarification</t>
</li>
<li>
<t><xref target="Errata-2222"/> - Simple hash <bcp14>MUST</bcp14>/<bcp14>MAY</bcp14> clarification</t>
</li>
<li>
<t><xref target="Errata-2226"/> - Native line endings <bcp14>SHOULD</bcp14> clarification</t>
</li>
<li>
<t><xref target="Errata-2234"/> - Radix-64 / base64 Radix-64/base64 clarification</t>
</li>
<li>
<t><xref target="Errata-2235"/> - ASCII / UTF-8 ASCII/UTF-8 collation sequence clarification</t>
</li>
<li>
<t><xref target="Errata-2236"/> - Packet Composition is a sequence clarification</t>
</li>
<li>
<t><xref target="Errata-2238"/> - Subkey packets come after all User ID packets clarification</t>
</li>
<li>
<t><xref target="Errata-2240"/> - Subkey removal clarification</t>
</li>
<li>
<t><xref target="Errata-2242"/> - mL / emLen mL/emLen variable correction</t>
</li>
<li>
<t><xref target="Errata-2243"/> - CFB mode initialization vector (IV) clarification</t>
</li>
<li>
<t><xref target="Errata-2270"/> - SHA-224 octet sequence correction</t>
</li>
<li>
<t><xref target="Errata-2271"/> - Radix-64 correction</t>
</li>
<li>
<t><xref target="Errata-3298"/> - Key revocation signatures correction</t>
</li>
<li>
<t><xref target="Errata-5491"/> - C code fix for CRC24_POLY define</t>
</li>
<li>
<t><xref target="Errata-7545"/> - Armor Header colon hex fix</t>
</list></t>
</li>
<li>
<t><xref target="Errata-7889"/> - Signature/certification correction</t>
</li>
</ul>
</section>
<section anchor="acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>Thanks to the OpenPGP Design Team for working on this document and preparing it for working group consumption: <contact fullname="Stephen Farrell"/>, <contact fullname="Daniel Kahn Gillmor"/>, <contact fullname="Daniel Huigens"/>, <contact fullname="Jeffrey Lau"/>, <contact fullname="Yutaka Niibe"/>, <contact fullname="Justus Winter"/>, and <contact fullname="Paul Wouters"/>.</t>
<!-- [rfced] FYI: It appears that "rfc4880bis" is referring to
"draft-ietf-openpgp-rfc4880bis-10", which was replaced by this
document. Given this, we updated "rfc4880bis" to "earlier
draft versions of this document" as shown below.
Original:
Thanks to Werner Koch for the early work on rfc4880bis and Andrey
Jivsov for [RFC6637].
Current:
Thanks to Werner Koch for the work on earlier draft versions of
this document and Andrey Jivsov for the work on [RFC6637].
-->
<t>Thanks to <contact fullname="Werner Koch"/> for the work on earlier draft versions of this document and <contact fullname="Andrey Jivsov"/> for the work on <xref target="RFC6637"/>.</t>
<t>This document also draws on much previous work from a number of other authors including <contact fullname="Derek Atkins"/>, <contact fullname="Charles Breed"/>, <contact fullname="Dave Del Torto"/>, <contact fullname="Marc Dyksterhouse"/>, <contact fullname="Gail Haspert"/>, <contact fullname="Gene Hoffman"/>, <contact fullname="Paul Hoffman"/>, <contact fullname="Ben Laurie"/>, <contact fullname="Raph Levien"/>, <contact fullname="Colin Plumb"/>, <contact fullname="Will Price"/>, <contact fullname="Daphne Shaw"/>, <contact fullname="William Stallings"/>, <contact fullname="Mark Weaver"/>, and <contact fullname="Philip R. Zimmermann"/>.</t>
</section>
</back>
<!-- ##markdown-source:
H4sIAAAAAAAAA+y9SXMbaZYgeOev8GaYdYBZAEgAXBWZOUlxkRgSJY5ARS6V
ZZlOwEF6yuGOdHeQYoZUVjbnOYxZ1WGO08e2trn2aU6TNn+kfsm89Vt8ASmG
sqy7rKIqIkHA/Vve9763L71eb62MyyR6FrxdROnFi4u1aTZJwzl8Mc3DWdmL
o3LWy+C3xfWiN8nvF2XWy6NZHhU3vcFobRKW0XWW3z8LinK6ll0VWRKVUfEs
2N7f3+oGOzv7g26wuzvaW4sX+bNgkUc7o739y3xZlMOtrYOt4dokS4soLZbw
zn1UrIV5FMJg0WTtLss/XOfZcvEseBOV+Ffwa/hPnF4HL/DrtQ/RPXw7fRac
pWWUp1HZO8YlrxVlmE7/ECZZGvGYxfJqHhdFnKWX9wv47uzk8nRtET9bC4Iy
m/Az9HEaLcobWDv8VWR5Cfss9Nfifm7/vI3SZYSvy/rWBXjrOAxNse4tFb+f
h3EC3wsof4Vw7Wf5Nf4U5hOYdf2mLBfFs81NfBK/im+jvj62iV9sXuXZXRFt
yhib+G4eLTLn3Ws4zPCqP8nm+lTv7nozn03wPK7iAl9J4MyK0nnJPtmX9+PM
eQfmCZflTZbjjnvwbxDEKUDiog8HsgTQF/QdY81FuEy8ryPe+AK+79/x978K
YWspTEIPwO6eBYf4Df2ZZ4iN0TQus9yf77gfvFzG14AsznzHYRpHifeDzDjt
3/CXv1rkWZml+C0Cxk56Qd8Hhy/8eb6HfcWIUs403wPCLgv3e5nlT/TDr4ro
z8ssDnsARjwuO8dYfsCr5c3y237wJo6vImeS3y7L8EPofC1zXKf4za9mRfwn
f/DT8dn3a3E6y/J5WAIE8YCevz45O3p58ub5Ifz33TN6WK74iyiNcngQ0PIk
eRHOwyQYx9dpWC7hOsPe4IyXZfAqze7wkfImgtVP8gi+iu5pHIsG+E9P/tce
z/Mkiic3UXoVwn8ZTFNAtmfB4OBgl/4sojyOClyyjvI6muD8wZsMsBJGCo6y
+QLRJBhP4iidwNs/ZMlyHgWDrT0gKYtFHz71Bvu1vfYuXh2NB96Oj24yIC7B
UbyA9ZTRxzI4LMtw8qEIDq9DWHXJODDJkiJ4HhbRNAB8wI2/Gx8GJynROyAb
wRhJSphPA5wi+P03g58Mjn1eZphfR3AV8SbCReRb3wfwAAHsR+XNX/pw66Pp
EsgsLGNzVmztb8JPRTTf9Ac/2O8vpjMY8+jgwIPAOmzwOg/nczzSJEyvl+E1
wLkXHD3DZ7vBJMtzOALc5egZ0OS9bhCcjd9unp0cBQf7MBos9mDzKMvl5/Xa
wpGE3N3d9eMiI1JVCLA2d7Z2Blv9m3KeOHt/k91G8ys4XhxsJRj5UqwzdScA
AMK+za/hxv+F/gwA8c3RyHe4vJPTw7PXPhROZnSTngN3IbI83jw/Oz8J4FVl
fMEJXjb30JcF3ZSPszgpc57w6CZM0ygp2oGwBHyLPzIc7osSDgpej4pNYHOz
KEd83uRH4BiXeVzeD+hEB/u9RTadRldpHH6Qo1SIDbcG+48A1HE4j8M0uDDD
tDx3dJPHRYmPHsO1F6pbf+x7oJzB+V//nyQR1K0/chpe4TBnCKeWR8bRVciT
jQG1079ESduD8RzgewrUYQrIcd065/fLPPxTMM7mWZ7dFh/u2x7763/Pr3HO
uyj90EJ54GZMImA06XURZDO69sO98iZ4Pz55c/YboEN6YkgUxnJcwfh+vsiK
eDnvBofLa6D+dD5dYHx4r3a2D/71n/55Zxep3UkOWBP2hgNzJQVf1l2EAT7b
Y25HSBPRS5tRPMX31l0k5vGCd8Dxc5gVfoZrPB6+Cm7C4mZzQjQuyCYlEGx7
qVv2/u70iGU0B89mYVJEzrrhgj5p3fDeqnXDz7DuN1kQzxdJPIlLuGgRHsDZ
8cnh11r57hNXvrt65buw8otXJ+NXQTjJs/R+HkQfF2Fa/NTl7j9xufurl7uP
CKIcPgB5OcjuQAQIJiBfxrOYucpPWfhg+2kLH2yvXPhg21s44jeS4q+37Cei
x2A1egwQPcZRMgsKs/ZwAUgOhKHMEM1zQPKvhOKDpxEVeG/1HoioRKQtEcZE
liEWMB5Qua93DsPh0/YwHK7cw3BI6APkhXEnOH8/vtw8P/ztV1z5EzFouBqD
hohBb0iWD5I4jQD6zJ/GL9++f3389dY/euLFHa2+uCO8uO/Cafyxt7sdbAbA
/CP48PWWvfPEZe+sXvYOLPtwfHR2Bmt+f3na24dLmiQs86FqR1LA19vFE5Fn
tBp5RsSdQLsBAQCVKJBSaANxEYR/i108kWmNVjOtETGt5RXSngVtpoDDAPUv
nKFSGCZJ8F4Iqfn5a21p+4kCz/ZqgWd7y24pj+bZLegxX2/NT6Sh26tp6DbS
0PlruA/R/DWo0Lew3PAKCOrX4V7boyeuerR61SPUbE+fB/NsGoEeDhcgTFRb
vIVlg8LYOfth4+uBf++JKLO3GmX2CGVeHiKoRKa3N/irnMDe4IkLH6xe+MDl
AF9jqaPhwZMoDb63Yqn4Myz1Fd3J22wixN7aw77G2kEdfBKY8b0Va8efEdFh
jYDms/gjWUKO3h0Nt/9w8fb1b4NpNAPp4enr3tvZfhKnxfdWrBt/Rk6bg/Ye
vIzCKeoiWQJwv4k+4j6esOKXh+PLw2PP2jPOklsy8sTzZVKGaZQti+A8my7h
0gcnf17SUZPO/zq7C46j6zxiWK02sHyf3YRp8DIsynDqLGRwsL/fsu7jt2fw
+1Z/MBjtbW4NB3tbgwP46ftX462ht+IzlFXnUVoyFsLK2HLZa7Bchmq5fHFB
9qsX6fLihXdWYk3Ek5pkSzSfgY4akVMAzfwhDVS1y4FaPnwEEF6FN3ESfA9s
WIDQBCe4QgiqV2H5l5ZnnudLoGTjyU0axWTrefX2+euzy995UEFrwDIvkJAH
6ZKMhuVNlOX3tG92Rl3n4eLmvouWuQXKBz+c9YOTJIlBY5kER8v8NipaDuds
/PzNs2CrN9rf6x3s7uzt9g4a9k+23Df94FV2lcSyHWPE3aOFX5y8gbPw7Y0/
xMhr7oOre3jgmZwd4qRaG9+TcRGpz9vbKL/LYzTLt5sVP4iPhg7RO7XhY07t
dZiHCPMiugZNOm472yhNo/ImeNEHMRIdNVmbcbDB6/I4+9oBDH94dF4xrhmT
P54r/DFfpsKaC2N467qWY9DwOqBRg3IdhfkGnsK7yo1aZ5Dj6Bd5fAvbcQwK
AHazJD2QU3KidPFadS7PNwKxmxdsIy7RtnaIuryuC9cMH1EkuothV44LsH6E
0SKP07IfhxOmmHjZNrf2dr/8/v2QoD11DnfwVfLX/3setjx2mc3/+l/+v/8S
vMuKsOV4juj+JNk16PgXuDygy+R07Bpubld5/u71i8GOB2EGWPA2DycJsEsA
tLqQH97FaZLlaBQ+D5d5qwk3CtPeuyj963+F9cTpTZi3EZy3SXwLVCR4Hd3G
QJfiNqx9GaV5HLyIE0Ci0gP9YKcNSJc9dAXhEwjURTxhH5WF3b/+0z/33MeC
xQJNb/A1KGRVPrC1tbd5sLffG/VGg4PeYHdvsNMb/mGAB3/+uy0fvodpYHEY
ZdpzZPaOf+KwQE1oGjy/9yDfQOkOj95VzviZc8Y7m1ujkY+JO72tYW/rMV6H
MRrrg/O4KFtN9u8yhHfwu+UEPVVhmTUxq4YbousSAnt0+O74We1Vcnqny8U1
vTUrF5vFIpoUmwKRXjEP87I3AeTphfb69kb97f7A+FkUo5fpRNxMYxjE6AdV
UuEMhGdzNn4bjHGa4AhdhPCUOFnH5AAqgg5QeLKn0awbPvneagAyw+0QTmoe
XMRRGaN75eLwNz6FOzs5ObGeSZQAz9QVDHNdRsBcCUV7vQs4aVLeqmvj0IlZ
CGS4c/F2fPabzruNDfKE+hAousFZUSyjYA89+R9BhlvokBKpEJBnfAJs/zpa
b9gS+asvBYgSwNGCre628NpsjfqDHlytvZpUtXWwiU+PL4/76ITp7w/34EaN
GpFksbwq+shFKWaDsCVL0caGP2we7B4cHAwO9g4ONpdlDJweFrUJO61LSeSL
uxiPX78b7DWjYx2VB3ubg63Btne7jURwHAHg5sCVCxRZLJMC4QhEwkLckKch
iLIqA668l+p9XuEI1DCHFW40emTcb3fb0QPnfRChJzdNd19DRN799b8Xief9
fguiEbNxOtJ3Jy9OfMw+D5Ga4K7fRdcstH9c5GyTbtq78ovZLAd5inyIiYt2
b78FBpIk9w8IgjsHuz3gePsHPVfPME4+Ys+giYDcRzodfBxus8UIPqJ2Ih8x
6Ek/7o4O9OP+rn7c3TrQZzE0Cj+OT44GzdiE0l8RTZi+oae4dzusEq51vS4F
kYGTGdzbGLQJ4VMsIweDoAPTBION1vv5qGHs3WUAnYf3CB0UnscvDwdHbUQa
hKQlRyZN8h6Qywkc8i1Ij5vFTThAc2uM5zuF22CVbtnfiidWc6dzmAZ2RfO0
i7LB+GY5z+78a77H+zl//vpk3LwjWFVvDiSw6Mve4mzTPxV4YCDm15uQHgUm
E+eAThNW7wCrUXs3e0N2UtBbKHW6fAakXWRByH7uoiviSBhE13SU1R2+CP/6
3+BgQTwCspKWbRLjTTYPi+Aius9FgPJY1PhifwuuSAvJS28Toq9IxPrX2e0m
fiDCSmwkTC6WV0Z03nxzNr7sjy/6POKiHOQ7NYx+FwGmgEY8NWwWdaXzMA2v
SVHGSDPguGgG4bCmpBWrcboavgrfrVMDfDqQVQfOsp8FvFyd91102w92Kixp
F8hH0/YMAAejwWGLYeXpMMRBcyIKnu3lMkfPND6u4Vzv2dHuXGfgOIfJNQjj
5Y2oOgjm18Aly5tHsJmTPggL+Yc28n8I5D+7ho/CYPQAQE7AK3bwpCPA3SL0
+cIgUR5fnvxw8mYMI44ezZFHm6OdfRdaR2wp4RhXQLPkvojbmU2NsPDWvl+m
Ee4MRZD3b85Oz06Oe8dnp6ceewOGH8YJCO7HUTHJ44WKmO9TkLfga1as/Cs4
6G3B/69WEDkkMI9AdMhm5V0IMsQpbGpqbdxNvAWEZ2Yt8s7mNJ7NUAYqNudh
ugyTTRSB/pCC8rGpK+/JUlU64oiZ3vjy/fFvqzrMyXwR53CAIFOXy+k9bvQy
+ljCwIhqvVPAzSin80GVhCKS2ApWeBAYAG/e7w2apOUKBN5TeFXrfr88QGuX
2O7uHxYhSM9/mEYo5E4NwWqTJ1DNG/QOQM/bG/RGw972WuqHab799enZ+GUd
YVssd1ezAtSIJLy2IqnBJw+NwuBNdBf8IP6aHt9lhHU32N3uPY/L4HmSgVbJ
psWgA3/dzeLiZqMBtHSLn/ddQ50eyXE0YWsMyEOjFkicgiBnkdGqrl3QlOZX
eTy9jmxgFUZMFzfZwrUbgUiCqAEY0vuBNt/F6bYxCnRwgEoBytTPfzdsheLV
X2KW9T3CCKTwOfwwJIKXxFdX9McNehkXwF98xGtCOSNAR3fWLKEBagmFu9Ev
3eBPBX34VTiZS+zuidHjqvJENKHY7aK/nExDoG/9aLrcJKwrNiPQRSo88hCt
aECARGU9hBXiHxiSP+05dgK0G7gCLUA0QYlt9DB9B/n+eZSABB61y/fZdXgX
tigQoIb8OrxOCXFOXr84PD/04zIPhbz3kOswW+JLyfJPTRuyQbrHcYGhyRHo
H9chsy9nj4OD/Z22Y7tEA/E1Rj+33V9UQIl5hhPxFKS+ak1G6GcBCABnl73R
oBuk/WC7S7NygPL27kFvew/JNQa1eVt+ywHG0whdTbRNJTR4ea/oanIs3yP4
729A/wpjb+MHw5ZtnVy+RGtNzFHW7n7owhWoZnYBqV/3UQEr4EA67OPZoAjs
fgD7fAmyzzK97r1A31jAVzJ4BSACjvmXLtsc4GBgfy9BLYQPyyQKOr+D7U2I
vpyN3w62drd3PYisN5stQLIDNoOmE0Duc9B+4wWQM41vnAIaHN2EORwRhorD
d533R+MNioBA+ewZW7pKiS5HOAPugLhDI4Hef40c6CIB8toqOH5Z5HFdZn5k
mPTe7v5ox1L1Joby1upmAQGwhxHo35+enbZDsrSQ/Nd/+me4MKClYOBBNldd
mt0oGVJaxD3ggGWcLrNl0SszkGMKgFMSxHMMbAW6dnHyApQXOM8za+lRI3AH
l7KxIjS8XPaBw2/m0WTzsvfu5Kh32d/fI6vOYGund/a4E7iMEtIKjHcAEaQC
+AGISTs9sbW0gFLD2wdbB4P93g5r4oPRULX2wcHOlv1olP3B9rZ+3OfINfrI
3mn4OBrs7OrH0YE+O9odqt4/2mMBFc0FW/v67Pbuto6wMzLj7kqIFnzcG+7o
a3t75tn9LbY/0ceRvrY/GOq4BwOOgn13dnFyftwb7G49Cld6liPTt/Gfl5Qv
8DIsbnozsZAWes9GKAhMmedQrJ19pNt6r74wpL9LGt5t2A3Gd3H5FyQ66XTd
J3ptHtjKeQ/gvEdGGRvt+6S5qnTiWjxZCTkpOY7EjooqyXkE+5uy7nRpALZa
L1feenxHWWJNUhXw58GT1CPYlLPB45++wRdhksXFpuhH7IXovDg632Dv8/nh
0VM3W08F+fLNHpvN7uz6p9mw14swznu/jgvyAAYnBVqwQfJFe4Ixt7Jjti5e
eEawhzf8gGYMgtH32U3a5GFVeI3nsRtmoFrzEyEF0LFK88AAbbfFoDPNYmJS
TTaN3b18+BBWoYhzmSPHDo4xAMR1W6m9IehcgnC04WHgY404DuoMngaQ3T02
4Qzl6VYTjmz38tdvm/U1Y6QVHYm0tbtFD9kpINbmcpFk4bRAo8Pu5taQBfpe
eZeh0tWjv6qSPSool/xAI+QeRr+qztZk/X8VJUW0QnC/oZiEhwX7hp+P+sAv
khanwZt+cBrl18vCY92YZrbW6/WC8KooUaxbW7u8iYtgmk2WdEELdkhhLD2A
B65qgbHozMPQSwIMKDY+6P6aOusWeXYbI1VzAtnJYb9gzYOyInLM751HJcip
blwJ/BUa61g3mIoIZYPEujVxCoebGytlv7oJ+DwPQRKCf3m9WY5BUGXGy4Hz
xgDXNEJ5PMzvg9hh0ikoxfASPDuNbqMENGXyuWVIqskT54YnXLnZjAoLHqu/
dkYLSbMSLdNltOhd3ffwf2E32Ycr+JfusASlwLbcoentKZkcrsjtn9zTHDw2
wWAuLNEuOI9C0IWBwk4+dINrTkONuvQwzoIxjbRRnM5E9eYZ6STw1D0MRRng
PHkW8eKnERwGnaVmJuCAsR9LhdyYQGLe7YKmfwcQzPFEi8myKKrvxOjrLJxj
wFiT2yx2dLVZEt4VteN1EuBBAqOQtaAj0N/o0nfoHQo6R+Ec9Oo4dFCW+Sk+
gk6hoFOJYnKfhHnxpgCDmCbR2to3KCfn2XTJbpHKmswFcHFJEENuUS/6KPI8
A9+/VVcmvoDwlIdzrhOAMbKf8XKQJlm/DYGRDRUFQ4y9FM/HzICsaxLqQbri
a856xno3uINLedP8KnrjzANlgXk4ebRIQjhE+h0ddzC0O+zJR0+PKdaDH38U
F9/nz/wZR9XPuLjPn1eduvOYe/D0NZ48ft169vQUHj4+tfL4K0QlnWT5IsM7
VRD9ACJa0vmW8Zws/nqVe0G2LEnxxL/gCrDFmQM4BXRoqkswnoPo048/8o89
/Apeou0bk155AxOB2A+z4hW/txcJ7z36uLDkw22MAZiFcS7Ow/vgLoSFE2W4
jaM7mGa5AJI7jXrXy3gappMIYIBEaJERkaMEqjudjQ9tCiv55hsQuvN5gUfC
GW5YEqII1jHlB9CF/jd485Y+vzv5X9+fvTs5xs/jl4evX5sPa/IEp9nYT/bN
o7fn5ydvjvll+DbwvlpbPz/87Trj/Prbi8uzt28OX68j/ErvpAhmWXAl4RIL
FDGnQVisKUElmD8/uvh//6/BNgDlP5HeOTggBPxPpN/tbcMfdzdRyrMR/eU/
4cDv1zgkDkdBRJiEC+RYQPIAagWQPYy0zSMA3M/+HiHzD8+Cn19NFoPtX8oX
uGHvS4WZ9yXBrP5N7WUGYsNXDdMYaHrfVyDtr/fwt97fCnfnyxpaXLw7++Hw
8gQ9FnTKFydHZ6dnR4f4ZuDgBx0kEg3zHeO6Ba9/sHgCTC2JPfNhkkW4WGB0
DRyGhpi34UDg4QDRAtTm5cLBPeYwEdbSVdzxV4F34yqClcA1BDINj8zybG6v
oMQh1WIfCzfWp782jiKY35muxxeukDs5z3I0YKIvCFngN+qBtfR9rS5+TZHC
IJuHv1JKyyg5jhehcM08Fcdmysz6NL1D7hlkQhwI44ht8MimJ7q5PInerwls
xHjMmpTN4cTwLlvC8MUSrb8zoHz4hYyKhyQTwnDR1CwVxoRTnU5jnri285kJ
K9NNts/1ASNTySwX5SUfCQosWJnj+oYQ2RV1HNYa48nfZzgeHGwxAamQT9nB
D6aXR5UzuI1d9cyeHEi2VyClFha+vUo+KC6hky14b8n9hns2zmOO0FA5//7a
r/ne2IMlCHTh0DFKAreSXf0pmtD+7DnwC2HjyVuJvb92EgI/sw/humIRaohu
ZsBnunQiMBYMmeh0/bVDkP7ugvXCZsKu47squ9KFBREEQAAXTILT6WhxSllz
p4Briyy4ADaHJ8zkIeR8PBoYePk4xijouGxaGp2lk4yLp4wuXQ0HUS3I4NE8
LnFxJBTHsI1Lgj1awen5D+gFjCvQpIfx1xzkXTS4f1s4h9EnEmqSj1DywgsD
9OyueLa2NugH/HtKyRwgBZAQoisDlBvaJ9wA+IrIrYB1oOpunG0KqD2ZcUc6
rgeeKpLQecDG4gVGMlV2BsonDAFCyrp9zRkPxEEQWvLSBTVMvP2oDdl7YXRE
X3VlEoU+O110EVAxBMZtPVrcF4A2NtS8ghO6C2fnrm5cyMmi1oknVKH8dlc7
vCvGgRX7Elm/qOEmL1zwyIJbgu9ppWu7T5lEt2Mn+CLYnM28d+7Cwh7IlG7D
Hfo5rpCl2R9gsQ5taiOBXSIcc6zXhfcM1UWfk4dX2W2kN7sbXC3LpjtduYsu
YTPUzN8oRZTlhK5op4TVPs/gzRrDExePT/GLKL+NUStCQfxKaxQYolKA1GIR
g+LVeJ86pkcH1drnkiLKMLqJqmSKSImneAaLBDUDd+RVVP7x534a09VrpKDV
GZq5Fu6Dw/PsPuyb5Kdlfur43SnLFNip+tqM+5rl0PrpLAsieL7JiUoWqNAg
jnBnjc7ZWk73dWn0CtpMi4ONRMCes1mFMo4ePYzdhDk/d2R71XnRNUKiNNjF
HBfrECkdfojFAK8LlED8BdeIXpWIX6Gljo4oW9xXNqz02/xtVtNE6VYAAyUN
d/d6pYQfT70JRWl3eIWzhG8LdxGW+PFLE7VuBcVygrRqtky63g4QivDLQgUc
RW2VHI2tc23tMG0j3lhoo1guKL0EB3dNpABBFOr7a+do1Ys+slGhyo4KUpJc
YmwSJEGD6eLyb3B9bGG4k1KLMDwWk4RzZ+Oqt6qC9bdpRpZDtT7oMp0ldoN5
fH1jH8EhY7w38HYSYUCTGRgntTyDVCcRsDXhA95/TiUwjFgNJ7REjE7u8e2U
S33kXuCbqgg+Ny+6nt2ZxeSqpiDBxiVc8TnFguVXMcAjv+ccclBVSJMsJDGF
JM0F6nl8UlKIiYhbwTvn84EvC4x17MFw3YCi9cjkjImpQGz1tiEsneOEveoG
w7sAlAm7EJguJ5VmIhXVRL2GY8fzKcIZKclmVHcERCBkSHYZRp/iCwq78CdD
HYgyoqdMKXGwfdyL95zCbRKmyBUndIylyOwOUO28XDJkomEomqshVU90VV2y
xqiBfAJ8CcbkVzkTulOQws2vff6M5t2zCvKK2UTxVeuqGEwrGPUMw+m9xaN1
ExatYkfQEB2WdB/Xb0DHgHhwhfJEhR+6CCiiDLIh/Fd1IIAPvj0JWdqFwQjJ
cuBNMT1nxujRD/4tBb0rEV2XpH3PMKGDFA+ujTUcOK8CJHA8KKGoxvJSLK+K
qGwmEYyDaU9cEkgGeKUp/45mtiDDK+OWRuKDIWsIOzx5YDUsi8m4kEqL1n9C
sWD4QsQv1GzucrCANiBjviEgw2jyNwOdyeUylTMliYHEg7vwviCDARuLruLr
HrLmMDWeIPZ2p7//+w+//wc2x87YHUXaIkCZb8ZVRCzM2quYbdyGyTLimNPy
LpPYrIKXBrvtdGDgLRj45z8P9jeCv8N5Br//hw2+hM7Ls2yZr3x7uI2vd/h9
/GKwq18M/fFHND6CjEPGUBchUowxJ9cIqx+/mS/iz2trld9j/b0TJkWm1/T8
4qzY8MFrHlRz302WTIMEPcL2N8uhMME5sv5JX9SDWSZLrjOENxh4KkyohJfN
dHegwcfoiHrWBGXCyJjnSTjSV4QUHIjOvFRRkNGKKJnQSkOLkS5l5JWkd4Ga
YXSc7Ib8HUhU5XHEHRjGwSZGw++avlRqOg+pIAuSUt4kLIXFa8Ks0lohgBzl
GdBYFPZ4S7CAk48h3lWUZjvkIRXElwUb+k3J5qzrkGcDZin+vMTzu8rFr4h/
xFRxApY0iedhssHieQ0ugH5bwRaiIGvSsnKzUsbgrf6qtwfw/w8MMPAG4NcO
8M3T0wfehMl2BgNEHLE+wqHlSwYTi8d/4RvGb9Olgg99wZS/C/Y2gk2+OkMj
IdCb8gTAEHDbjuDTLXmIbCS4dBLlEd/mGYhJ5AhE2g1UEOnpX6I8Q3TE3S6L
rkFS3vCQ4SRuadx0NNUSLMk9mW0LYAywGkAmF7RiQ1yEuTiLFfPD4HaXw94N
V+yiXuBEHJ8YIUsr3r0yVad4gVXRFl0k5MY2vIDZPAwh0ACyCg+sABDJ26sA
xGJdHv1JrXbilA1RYU8ENPEMAQWn9T5lhhEzvZD900IBUjgmkcNvJLAJCRoS
LV51kFFhA2RAa2tYgZm3RQ/JPSkoKp69qErx5GVctNAIEcqU7MEqIvVfTtB/
yX48lXSiSY/+7t0BO++JFR4EHzofeNe9zripD2l2l6JR+KOFsx2KSWF1LL5U
+GVVvBZyWVC4PtJXubAwkYytdJNzMBwbA5ul/cNyiSuNO0fWgefLwdZVOhum
dkHOXb67wdha3PNiwdueUeQD6Bwk2tKE5o7CeSKqnh2zt8DJogHh4FB+I20A
TgL1mSa2oWQSdQZSq1ukTnTChUWBNbjpRTMzsUWMd0R7+czJ5EFDbUZ+5A9R
ci9CFz8aUGkYmhAG4VNyX9WwAVg+yQbk6EFtUFhlhG6dGaXqAGFAdTXLCUAi
tKjqJWyQzQU//gj/24unRc+ZCt1ZlqDdZHetIKUF8MVTn/PHEq9eggY/ukN3
GFWoIUoiHhnFICgi0eqxkI/gH9cZJD8fxgjDYlw15n0a0x378UeNmSdHIM6N
Pv1TJMx01OTiZzrNx20EFUeqUl7MPF6NBlZkB7k0S6cFXNpwgXe8IJ/EPJ6m
iDvdYBB8j7lgoCkNDva2YOlHBgeJ5eJCPvBnVkExo1VkXcT/NArUb0geLlaI
EOEzJh2o0AAu5KHyMbTdhe6YBZLie1PJEG2ZFKZA9IGUYdRI1KIJF6dYxqyl
2fHPVvvJNEKBfLgSGcS5GuTqlJlYxoB1W9qJo6sGRkSrV2bEYDrj4asNLaUQ
5QimwjzwwTygeJNT9wjjCGLrAyqhqO3CDVzc5FiaQQgjS1OttulNG5XDt+DC
jFCIKoWjiM6PdaStOsk3bpnLJTPeZhRGiRU8EzaAE4idjjoFLNBdwjqyWuvE
TDFzPbXkFqmbOIRTrYRhgD08UIovhh96CK7iM4ksoogi0hMUC91V9U27Lee6
kgaJnA7pco42N6LKKEj9+IzDMn9hgpKa1sdj59E1oGR+vx7Y5fX0y89rQNM+
0ZrwafnIV5cktQ6T9w345V2k5ZE+aduG6H/BoK9nn3q1fz45/6X/XQuCLRye
S+DiLJ9AwPsExARXRTcJ42s+BW+wFssAHw0TEoPo0cGWfZa+p2ffaqSJwT8g
mkAe4BxLENgxkHRIK3cBCF/05F+aawQfzkp1oQLQ/YkHZuIYc3Gd2X9Ldby2
4dNhfp2lONPQLjOk78yDAxAPAT8HtBEp/7R58nEBDJm4WyLz6dIOC1frUHUn
pCgHJyaD8BwtB5IDcRUB4weqwpxm3ZzTOpK/5TxVaXYd1rTOLAHnRXhVHNF4
OXJh9Ch8gMB3R6FSE6kyFZPjhqpaEtQsY76KDLFQmzIZlLNluViyy58MQwYV
+OYIEmgoW8xyNpmhRXiVU2bv/RTLtQk/FQsuRokQBGj1yD6JiGqxboo7SNEU
zqG/b4kRbT3TUOCtj1tb3k8D8xPZwo1zY23NWbyzPocgVtboeYJQvpijjZGi
djjEjRYqC4Qjhms9LTQkUnWmquOow69Wnpaq+9WH1aNIJ4NK24ZxFrjj+xv9
tjCHdub8Ti+gy438NjnLT9UJ8SHGMLySPY4q7iTRrERVY8MRce28uaxPzBQs
KTXNTFKOmdZON5ekPAzrLjFmz5+AAuA/skGNnU7TAMNWo5QNfP6hiXFv6mAY
X0M7OA4EgjOG06urdKuLaYnDbtDv99fsJlFYBmXXWEcykPbFGcgivA5KIVNp
psOStVbYGcoI1zheZcqBqCcyDT8PGJWTAFZ52FcvaFnKbPDaAGKg9u6YAeUG
iWcajx07IwXovEfEY8aFvBfjGlwwayAJe1zoKxzqNpKIMK2F68vPHDXI+EpD
6pGYZ3gSRcy3OoVz+5wlky2GHpXYLaPwKqrIBY7JvYA+izQkcyIfC82lWNtt
oz1dcZOTB4l87gpixtCcHDgowQENFZEdaaBlNUIDmb0IDQToJcspKUPr+Mu6
cDAh/PialdMQj0lesB4W2jB+T1hHmMNgYe+jtd3UJDna6E2ULChSD2E+jTli
DEtdcsmnVXR08Dg66jxUBMPeAT+3r5ohbJl3DATXQgr95R9D4g2ozDmMpEvA
J/FPLCFxigcvepjnxe6AUONZNeGBfedi0OQGWTxQ1xVsCz892TaJgo/ZFSWq
Z02ehJDnJ7t5ajqoLNNSDHP4IyEsBcRNG09SyTvIj4jqGF3N2INC4SIyq0OH
quCFhHHPljkpErAm9FgIdwvnuACK3cbOd6gyEyLAg3OsRzXN2D92/zCu+Mgy
8n/7QmxpQhd/PDMZQRCVOGCy/FJX8rYFyy6JUi1TAe6UbeuZ+4aqqNbRzchA
xjTQx5dJ+Ew3+w27+IKT31w8PzscB7sm60jWEvwi6HTO0nI03BjsovdgEvzn
YLCzsYH+gw789ctfBuRnkBE2vuM1cgyPTBcQ9oDYeXQAKjumG6DmsU7DrrPu
SzocBxWOhuRlFCOZifiy1dTXJ+tqD2AICNTkKm8hRxbk7jmI3SwGEV/BcyFS
ZEguRSAyKpcZCr9W71fDFNlnhFpZt5uVetXGKcfVQBH7jvnQvwf8jrkN/g3D
RaDoOEdiLqtR4UmZCuUpAQcrJSVV7+baGfM05GKuhcHliiw0oPlluUBBx1xd
Vt5xC16GFzFZCSaorovVfwYuOQkpvckJakLYryJXwrwckoDudw4bYznMUNAa
ew9gy3FSMdvIwuxxyZQugE1MuCU6SqkR8fJlysnbQradVw2Bj2e1UWtSocgX
8IMrPyMyUoiXS7MvWSrr2ogKPD03wGa2BAxoetnghgQUPwQ0UL1BBGArXW0T
/bXDWSnCe0Vr6XryBst1JIdMG+OVkL09hFzKq0R9ZdYkeqtwJXyBc+daLjiT
QR6h699SsiNiyj+aCWk0E38+j+Ba3PewgG4KkOgajiORwUpaXUoiNcav8mVJ
RnVMYXgEc9n22cagN9jlnwe7D/GNPR2nRvzRnBRy9Gzlnf36O1Oq5s7v5GiI
T+JiHiwqLx7UXxQS94e5AvZe4RJ9XMBjqRPvhvAkHWjNCgiikls7t4kG9+SV
S+8C674MY2hZvvHnqOtBRnKWEswRTYe//9nvf2a2EnyIr+Kr+5IVs3eH53z7
lZq7b+sEoVBqQvPR302iOOkk2fUfhp0FMEq4ZFjuhtw8htRjCFR1uDmzQmes
/Z8t8HVa4GjgsosKfhq1E3QeKSwB+G130nkVP99grmDcIXKp6KXb7EObjFYE
F11LmODPsRPHwCSiC8Cm1IqGON5uXVGltYoCXYbX6kC67MJtGIz0F7Wq3rIE
wKuNjeaNAgNs4tSG/XE6vbFC+isD+JPraywG9m1JgNTbLyp8bRh8bC6CCWuV
boFJkxC8AOZFyDlUFdRJwKIYEcpAWC6UZaRIae1byi6sBLCIco6kmWCwnvhw
Oc4QhSDxd9KoU0xRsw6VzocoWohRbB7THUGEYREYB1EOAtglmjQ6vDhYoGuR
gLVLFyIcnh90yl8APi9+sd0N5r8g3BwONrqWCflany7eyJxb28FvfvP4/5e3
4DM6r7dB+Fxb67AECd8Zr6CTA2FMDYixG4328fcUucn8ZEnZvPTSZ89uVlGM
zJYKjc9wKP3UyWaTeHQQaHpi5jU6qx+ECTgsZn3DmillC6ao5EchbGmdZKC3
S8SFoLMT0Uqyu4KzHwAq6KEQb2/xISo+qHM3j2C5UZdXe217G2P1NV+DDNNG
Rz6aT3Fwu4j+2inzxjmNXH/PMbwaa2voQnaZilxUix1AJ3ZRVZZ9U7qBcYeY
h6JxXDrx9o5pVpKcNU6evOS96yxD69ISWTYAmPEI6SqFFdbvMwljFb8vAoWJ
FFETS12JQtxif3K6t216N0YAq/UTqMEk5ADtMvwQpdIJEUPJ0XngCpUc6g6b
y6gMgOWaLzVfX1KASEQyZQA0uawm58BZoMlCdyJWIHJUueEfeDhwffh79BNb
Hxq7loR88FKtAkrcxWQTYeBHlJMInJKXkvxhtotZ0AH0tXPwl068gmF3BSI0
yWcID7arR+54diJXNO6JNGftCs6i4U/CDuU464SqfAnxgXW2/Fa+xdesidNZ
gQrFy9SZFN6Ppa4EyyiEuL6D3Zy9b7yHg8oopMadpSEKFujjlO+4m5pv5YQw
MOuhdV5xumQ1jUSM9ja15uzYEBjjTMVf5VyMtuvAhogaoSOGuko00/FOJXnj
jlLjKQyz6tGtuzBCJ9PNiSWoLRcA85o8AdVrq4Dw4OAcmw8OKYzDosFwZxR0
Dk8Oj4H5DXe2g87R6XMOxxnu7ASdcxRF8c7j160Quax/KcaN1GrFMQB4im62
5F7CEZnBkR9Uo/Q1gVpwptEL7ju/aYMmwKaOUHppuqxSsoaGMvY8osjtPEqi
Wwn5V5kMl+XE+C45LexSw4okoFsWTlGjbDX3i69UAlJgwCQr3KQHJgVioCGr
ELnVumT0/8iMtAJW5L7zeZiD9Fm42DKpZZGvIDlkQRHJ1Zn1jxTf1vm48Ueg
qGEqBGOolRfxR5h8nX40WTpLTjcAiUlD7tPgI/org92dndEub+6PWIHkj0TW
/siL4QjQP7oHUfO6cvTFY3bT4Knnw68Qe/TYi9hECuGG57d3phD9GOiZ9eFX
EfxTML5BRw7u6pM7i9mTYoj3q+/W/+T477/gn0/Ov2vo635vCbK4tn/2s9sR
XuPbbYrFePaznwW///sJXGZuKsa7LYLff/r9Jz7bjny1gXHVV/nmL3GI3VUv
w4Psdn9FLKaRzq4msZ+C19F1OLnHLjefUOj7hA1vOkBPO/bCb3RXrXaDIwyQ
jn0KkJDB/9AJFD0NGMR9UNLBz34GY/HiaA1deqGH3vUu3rSeER1b3vWeQVWU
AzVwlM7LV8eniGD+yhHz7Qa6gYv+GwI+pLu08S9a+hPWawBcW6YHYOzm4MGX
F7kDn1x+AH+2L+jRkzWeJof2RpjEJ0zLMrMOqSZYpirGjJGyQRTC/Po22Z9T
n9TZaXyVoHgBy6Gh3XiOOZbyI32dYjmkssBDj77J1iXZRqgZ8naN7aiEdnTc
EBC4rEhO4J4lqHZSyBwueINVZaO8PBT78YOwnl0HcIV1phS2fJqafzjqmPic
NdDQSrV4geFn286gXRFnDBWn0M0m4dS87q6JjfScpyKuXaMwgoiyCOPcic4l
ZQHuEJdamNmSUOQEIKJ8B/qAZxai47YaLRGITpWUA/EAJemwXVnkKAZ7BhKj
7QVmU+hhTfhnJb9BalKtileEKzC2QN/2oJGBFW3GEFNqj6FlrZrKeYSpWb/z
2ofWMPjOyfjVhok9Z4EV7gjbQUM3p5uDaRQTsdTNXdXKIBHAhZMw7ohyTuBh
RtlHslCTDipmiHn8kWwh/urHrzhi18mRxu9kZbQcJ9tZliLBkbCeKCZZUKZw
VkWGMmdQRMNHKyWu1I81wHl8sTT4MaDO7u+cahB+GYj2wgBar6fASDnZtEsh
jOmAI2RFN0dv/HJeoUk9jyZRMpv0Ex/fw34/rsxi07p9jflr2OQSC315ecNO
1jEn7i4nJtreTShEu12uugGVT3LjhDVVS+bHUHRBWo5EvlmmHzTvOLAFy/hC
gVjiWPspd4XF2n7DQrsa/tt1k267JKFS4nlhE03cGB8v9CH0zP+yZMrKJQWB
SqYJJDGYWdOyWGHxVYaiYicKnZRp3q6msrBBL3XrXsjARXVMNBOdsNuCgOiv
Xb68od69Tb5O+vkqm0rknfc8EeKZdX6b7K5fc1BEOk2EzdtcW14U8xeTnWHr
GAJkImexdh7yqIcgmVHrEWsPMyvExiiYn9FE8J2lyPOyIkIfzAwnijaLhVKz
BZyfpKuXaA3N2JBOzjTENcwo9dR1bsjvXKTL24qX24WObk7H0RKZghwx19NO
LIRo8CyvY0ixvOKIYyQoOjUNt9FXdZBjkPi22ReqY+sIBkYIRO4uMAEVW0P/
xXe+LE35hZwqLtYB4KNWSCldWHAaARpeYdqzinpaztAd1Y7H4xsmjSfXnkeF
jy1TYMiAkJyB2cb8TfbrU/eEE2t8fKlReqkNiFI7ANJLIbvcI7uoWyG9V4AA
gQghZFisEplxwpjPBrIoWpILkN+QuS6ZHnZ1F6rbqyXEmU80OVHBOQhfM65q
pYYar6afq2p2fmni+CnVwCtGyjSgI+H7GxW6pfuuxEJ4xRex2BzHc06psive
D7dgp6nByTzchuuwdlqZKbSsrmqIsyIBSoNnJ5enlUx23TdIxdkkSzxpm1zM
1fzAq9hJ8+XwSM4+E+aHv+8h65uHxQdbLUte2/q4v1XJeYUp//Ef/9EJkar+
86//8r//67/805f8//8Bo52Ia9nHqWcw2v+2ByL/DmgNo2AYDIIt+Gbl7P/y
hbP/nzCaX+eYS2Njw6O9AOtKs0QGSoL5frf5+wLWCeR9C3+VMxdhAf1+ggxP
mQOt4pVJhg2TmCcGZhl8X+iq4bn949oaj60BM62kQa9dzbngPMM1kSQAj35Q
QGZ5I+7zTW+8Fa7rh6QOFjTdws7IOcMJipgo4zs1rGNTEzKcSEMabS87tSHh
zfM+IiOCo68cB52pU2b9I1g6CFVFt35NGwQwBiosS8px5zBoEAOA/KFlm11P
lMRWtJMQdA9o8WAiJL5bgxpbNDIlzdhHEb6QdOHeFC2UMcj4EVGgXq26DomE
HfXbXkrdSRLFOCmaGqNvkNyJCMENH/TYZqjcO4EVzWAZ0+h1LgpoIYqWt1Ix
Q+gcjH5x7l+yrinnRKUH4Im5mumFG7QwgyvyEHszcpUeS229ieS2iLmAgue3
tYKCd2NK5ZXkoqM8LdSv6TVJjvafdMPlBrsSNiqo4VMtswYcUMainFTJAMEP
uyOJBPCb1yvVlfaNwY/fYL/jxfXCN5Z/tkYBmVLBTzumDLoF1l6n3vZEz2Y2
N5UpEVcVO3Tip56DzC8zK9FRIUNAkciysEQMBY8MDgY2hGeIw9n6Fl803OBg
iOPtj/ZHdsARDjgD2vH0BW53hwfb3YPdPfjfnaCz9fFU/tlw3ByqxQDR7rDF
gapnGEwoGgucsBLY36BSZr/WCNImsYi0KTUTMZVCqXt6S/E0onhRxXqQ7bAp
D3r16ptVGm/ldZglpm66WOfXVtvoBtFshhr+LRKyefhBCnSoWqamp7dw9BxP
p+1C1x6JD6Gzz60qIhAIVeZMvPcpcHaSgVSEWSxX0SREZzIFXBrLn4kzdu7b
wZAZBwFS1RiAx5+xyEmZmWge/B1WHPwiGBTlH2i872Szl4CYtc0+ClvdzTbh
6VnZsi8iO74PX7gzKxsy2HA4+tLddTpmf0EPx9kwFXQ6w3TKv+Bf8JPs/xTv
UQ0Aq2+XbznQ+rr0NJbMUf1CHdA7vjmh4dJ88T7NZrSG0KegM8qd77CM0Kea
GNrZLm/sMwAXeG9HvxIb2BU1kxPfNUcM32WS6WyhohQlFv+wJFKzts6JXK5C
r1er4RYTvNtvt2/+pnyjqppn0ZB9H44m6tiKVLAx8PUDAsk2R2LpoLu1N+ru
bQ+6+8NtALVy5NEW9lbBVzaakPue8Lp6XzVRz8txRMOFHC5g+TYD115rwBhG
iCaoNCHGgp97bm85JX7Yu/CfMWjzFNM+yAC2Gto+rlLlO0excyi3FVxXDOg2
t8GwHh7u28Jwl8OULYA+RewYQHYtNeo6GEiik2x8Q0uCMrhlDl5agkGUFWrr
mTBci3K4YidYZqCdBaFkSdhXdQZgzNAsZmdP3mASIYGNrpDRkWnJTWSHAxpD
0rZ6ib+4JgMPiKZIb5suHa3PuR1YZYI4DmbDYfBb0g1co6pbuLHvGG3kBBTC
Jthaw1d3Blp/ie5uIxCLut+PYnkxQUWiWYzEqZUURLptEw8T+rkmHR5ysRmu
gvMYJdNql2GLWiDqLN7grZbxqq+G4jBbd3TfdY6lkKxuCUCR4ZzHcOm+YG8U
DKzosLXGLbZURSZ3gJVcrEB3aaxmFFvvH9HaoGkYKxO0DTOqDDNsGsbhfW3j
7FTGGfnjsK29ScCrDzVw+Ia1elXuCacdymgcmkV8xjMk4NhnPm441V5MAGeY
OpGw8iAoz5RZbxOdonRqcSWJdN0t+hIpL+gww5KimDVB7WPY6q7COFVsxeu8
AjQrTMBOyG8TeknZ/cePC5THWpXDtPHV5pnczmG2DRYAF+P7JmLqUNplg4eJ
V/GtlyKwwgvIYIm9HsTugbBzjBFCTjwCEmhNPq2XIV4GbjTDiiMN3qJscpld
UUqqTFMEJyTY3ve0TQEMVvlAhkIHj/RFvndsWYY9PgPWvrttndUu98ZxbIof
s+tV0+4NRw/Na9P+ceKjHUwHOX0u0zfLEAgBGvpLlrKF/zy0GJQGnNWcnnap
+Ab9d4D/3d/F/x5ysqmcC/Haq6hqGLTRz27JXBz25FST+EfDvd39yja+wyew
UTZ6yvyiCObnLfnZCofOr6f6K8UTNrzOQD4+7rJgMNg9qINST/9PS0k6NGYO
W6tX+qrcs5uS7flUeEIfbagTskLkIQMgy+Pcs+x6ier/CoXRyDYVmVKw4QIl
BqqSrGIzt3oypY+jj4sk5Oa64jPhrN9G20KjO4YXhEmNFCtbf4D9u46f6ggd
chPuLvDjNyJPTOyXEkfvewUCbo0Us1eMfJyaAq6vGmKBp0JFeSs/UNh53dxo
rJdcXd97x4nFcW10FM5uzSvG8StF9SmY3Q36wffvQI+Nqk9WvGP6NcVWZAVt
k5xl0gieZTf0OHe5ehuvoWGzRmyMr1MMlUJkEPAQUbhUUyMpaWRYGR1I9RUe
qL/qhW16Y3dkCyCbt2wciBbf8lx/0t2AK2x7YijXIXZ7EdRjdL2RnUBcdwon
/jagIlqKcFjfyUGqY4pI0Qhbt4iWCdKtFtH6VIuobfosFbXuYYn0j1PnqmeR
xQgKRI1Zk6u6dgb+MA9WI5XtYaWrBWc/4VuvTsavpOCWM5gpdOq+ZQtu81po
gPHZC6nG5b7uBZM9uJzCLGcsy9n2x0MLIRada14XCtwYbdWDBXKBsYsxjLFT
WZNN13GnjuDj/efP8PvJ0auT38J7u61wdSG4vKL38IH3z/nFvcYJx/RkZc7C
vg7zjnWEfX+EIxuEQ6XAnTGsrthDck4jHb09v4BBDlrOguxE9iyqIxZSH218
Asg1qODoOXWgdh+n6NTcxYTzw3evTt6tce01593XrN/WJgRyTu8Fr88u4a0K
Bl7myFqdx0v8gl64fPceWzgPKkj3HmM84E477yxj3tN7vDCD7caDrZ8PnG3h
Ha+ez2CvYcbDUj1Q7sQFRjHrLy6U3h/i0vcfd0aUuWi62l2Y0Nf62cULPb2z
C9xrBQkMjelQtEoOs5yDmGLCCI4jCXMGnJvqTsjKySxIwgp7eNVkso01rpvX
MAv8UiVOGIQLoosLZf7Khc3F4fHx2ZsXa8OhsBweA7MR4HpzLVJDr3moNWY2
O/hsmgX+s29gxdXnd5U56fNS1Q91HK+w3w+UMC1FrMMr7Cwhouu6YQGmPp8p
gYbqDsU+TkougU9cA/tjs7BgOi3m4axUGfHeCMltcSCiW3F64jS6Wl5fk+iM
xjW0+HHzghnMPuUKZ1Qkk0RqkloroXkicj2SY3RUzBpsIMMmYr229jsqIyyV
Uh4cqkOMZsMVw7AB4mMYhb7SsVm7pI1HVMLQzauSKDY0Z5amNEjr5Wq9WOrV
4uJcVJPQVYfp2/ZhnSE2tIkweikKZ7HR1I169rrmNHTTc8rzWZtKpRWVZPB6
HSadhg34xirodooNU9GhDk2uRjeJJBcb9Z1H1j63tSsUAym7LjPlE5v3rgFg
GlVh6mVIO7oYzTuhBwM1/FsIsBshzp3UWtNgutZ0zumht9TKWd7wmb7qrkSS
+Eid1tq/KsSXZH6WaOtaKZJr7uVEbisJ2bbRvBWNgqFhq82qfGyasCL1GdEG
dleHzlVqTsoAsgsznOQexqnmDN9rhe/7SrSLARwVxNSWJqx/9t1BjX6LVEBX
Q3ZA0OquU6cdgf88sbNKsKA54Z42HdeVkzZ0SE3e71bObBsAsDoQOddEFYQg
KjCbMeZSVukDE4tdS/NkRo8mrmJR//Gb21FPSeuhWfwjxvEpq17UwsmvGXw5
CezcDhj2WiKkSQAwTpWztGow5GhB27V0RjU5eG0cDj3FGhUc4voIShp0QCzV
tZCkiicd3I78czVqk+EPwe3wKUjEuFsZ3XFDg/7Z84JWKpeY8Jk9khhh00Ob
rVs9Xx7jAo/xrRCcV6ZaPd1ZWxHAI5htTQgdi3lrn0JOdSbhtsvUrjovHhtL
xJqJI3IL3JLQWNErKwWhCasGSqPMS/uAK9ugbUnqlrK7KVjHsPr7OcaqG5qy
bqweeBl6FI7MR+IDvE5H3X7OJiFfUq3xXdtFQWrhkA4Vm4KAjZ1beT+xON5l
VM1KnHBvaJOVJ2WcOV+huRekWVjHS02mYtBUjV5zYooNrcqAx3aX2TLivWq3
2r5+Z6Fj5zG9GQTbXP9w9EDfY7dNh2F91nCrNMKNN7ckcPcJJHC3gQQ+YpyH
SeDwKSRw2EwC0TFXI4GH2CPmQVrkA4zzwr6UEH4B/dptpV+Vk+S88i8garu1
++hasZ3KJneZDG4uElf14u4KUtzDNNiozsj5Iiryus095BegTJl05vwpNEW8
BPUVmKvlzl2nz6hsMdF8NKX2w/TFKv7GeimdrRKa2GRZGW2ovqbvKk9Qij0M
hR7i4f90dLOVddX6s7Suu+tXXJPR32QPUTuHVDqkd8VkAnf/mtHssbirqTiw
ES0rsogQzEMDnrGCh5uy0PjvxofuakX/7uVF+BmPp7n3XIDNuTaomtv4sGdh
yJd3TqX9qKYGyf5+bWx+Zn2+rqv2qtaqa86puV3lCj6fWs2T6PLHHL8uAO/I
tBQKT9EcFTlso9/GA91ASi0v0lCBv2ujweiXxofkcnURTMsk0+ojVKO168BF
7gRSIvVw2hrDF6+Oxt8MuA2qjRs4OT/p4S+D3u3gDzt+jRKQshYYHzJzyvLt
9Yf9gZTm298a7H3+zPSMBCtgBfMI2OakwOF6Oz1eBZE3igamooo4LR7pdJlL
r1nbd7zm8xLtiI+UVzSqr2j46BVxWUcmuJbsUU5HfXLuUoc9YtFmTOcuWjTS
ae8U8VE/t9mU7fHysrFakYzHXWQaYlKIW8/DD5F0UZaTM2dm7BjSCoKqMcxI
mdYSp1LWtFLOTtr/qA758nB8eXhs9MXVd/8kuQ7nsOqG+x/xT0wDLs7wLPTp
zjHo73HUexklyTxMN+RGX+Ot/0C3ftF//Gvz4GfBvf/qfxCM/yAY/0Ew/u0J
xmPiyU6SF3SbVSgpHkdojo5fNlKZyfTGJTEAqJMj6cBoioxKpcxocQMrQ5i5
9laN/c1EkuV81yKbxKFn4+bejmFRrUUdTXr0E5vY6ipHNdTfL+NWv2Ba8tGv
bUb7fBxN/s1wZ2dw0ASsj/QLgWtkIjzboSQDWWA9UqVSderfgFy2SPZSJkTv
9q6hNXt72/tws2fqFTLt7mRG0BuWpZe33IQ01sVxQ7WCuAZOfw3rYaETCCba
2d89oIqKhTHZCy6NXx4Od3Y54nB3ONqWZGwKiZxhIriWUoMFmMARPop1iQ2i
CrludXt4lOY27RWUkzkbcYt5Yt1th6lZZKhtuoYDWhTe+BH6TQNYA3xD1dDG
NyqgpM1RJRqvGL3ussns4zelospH495guM9f5OFCtC52TWgd+dHoYJsuliXj
UksVSQ4WPHP4Lgaes5uYgn0WCy6wrFzXWYCkY+rUCyqzchpLZYu0OpeNjmpS
4wpDpVqvRLdiLPMKfkpCnaPdn7GxVM3gizzyt9J4r3ARiySMpQdTvSho0/R0
UhrNJSfS5Q8HQ4QofsQL0fGWvNfFpjl5cLDxOJq3vb3fSPHge6J3O7uPoHc4
yL8Hajf8H4raYcJHxyF3G4+hd3AUfytqt7PbTu18DGikdbXXH6R1tTf+RrQO
b9F/0Lp/B7TuDVW4gYXwrpWYsVW4La+LmwzgOFx22jrAHLeW9BwXgzShuLXj
cm82W2SoZDBVe+vWYYHuA7bWVtbFTQTQVY1rMNXUKy1zCedUI6FGGvHU0XUq
LS4pl0CyYZIF0nPW8/NwxnbbMLkvOCPI67Vbj8w0UUNDjBqqxY6ii8e+Y+IT
tA5cGFzF3D/pKirvsOsQp7f6dJO+s2mRVMwGOzOgTqpjS+iw/YKxXntGh6Js
I/EAZOxq7XjztAaWhE6pNiGFocYcEpUhQqgxFNmstjutSExUw5bUHNn+OpIK
bN5z6pN1pa27mYALe+6aoDDqVrHAttOIAloWBIlXsbzSBRh1V0rVMeNyy6CF
V1gWi66gLkMaiqiHHwg5FpygnACzGm6diSvaMaEb1cPlJu9Gv7ORGrUn1ZPx
tDANDv5rjtFoUaGddCynqqhZFvcqxiJK2n2x4m1prfXZMPD2IwfeFnpQiQSs
lhC1kSIW47/jOByHbjU9Zco9tsGrLtowdlROaZLlMNoiw56iWEdC7itViKVL
6szIXUfM/k0HbkMd6n24vTKHmjojGZuFEDWnXCJ736hPhKmhJklRzp0W0oT5
GYCE3MPGQfhaagzbOa+XUWo7gBXOMkzPm1kS3nF5TPgcGXrDPA3T5Pprz6Us
g4nJpD7oAScth8vyJiN3NO6MiDX+sVxkqcMMGBrevmPTsp4WTLYvPNj8W+Il
aL7EmFTOybqK+FzzGBhltpQ8eKKmLDuYZXyLKeSYa4LWmUmpOMPCLYbv2tMV
hGFcoctoyUqW2gr8+CZX1YN9IBFySDXWh0GjmTQyaqjDXsEdt966j0TVbulv
QBB2UznWbGKGl5+BGW3w3POYGmHa+SQDAsfuXdGPnz/jwxjpfIn5ZM2PIlPh
BzHAfVwihU7wdJofL8wD9BLF4VNNaGAMRx7/cd+65id6yKH4PVzVBVzQLA1X
vLfgJ5z3cJFHjC7trzE+OW9hNPWFosmK6eQR500MhJcI/OfC8FsAQw/1RCrg
lw84fJtij149OIJEKflDnMIjx9SznEZofpObmvcoIwBeorB3fPpddJs1bBPX
mZuf+BVnny1vyQYrL45wLh+iLe970kl1mG0c5hJD8cpwvmhDVf2dXtmhV7Ab
dQ+zEu+DoyydxXqhvffoIUy9u+9NnIdomNNTN/3AfS2XLz9/1rxfQ06VDFQo
dq2jA3tjrjRkygQSfOOzGaKVfGdtEceOMgG88CKiupdbyrPYzhVMToPsDhuk
YMFE6UQec20MgX8kUlZcSkfwkptmzindwukh7a/OVpilhgiNqxy4qyS68jdb
46XHLkkdSSbLhMbKbqXoH68UY5M4XR1zhjGhnxufFtpshXXB3//86N0vf//z
16e/NBCwtNBO5e536O7XIYxaPNpdX0W+p9IgVB/mLrUCsCmUqvVknF2xFWmi
xXS88XDDfhWQCjL114IfRkHRsKGWCtq2qKyXhUlwUXLfrm7Q205UnIaGWdgN
PIz22AMbRLjMlwn59OcyDbHYv5VyjZ94QgnHaFfjdOKQKjBSin6UcKEFRbCc
EItUz2hqRSg4DRuTrpkLKRZxlAIOxI/c2B2W3KyaxVWNhLH9JAh5t8ljhI+A
kF4bbPFKACJRplKUdZKE8bxx81glknfv7C5wVCPepzDin7RN7xK5jPuRu6Qd
kmQoUmT7TrEUBt0irvhOJ6VCwU/aw8g7Kk+I+KJdAKeAK0oJ9o/dxTmaFFT4
rGZl0fUoKcdk/UPkCrLrVGVRLnLlXnqr05Lt1aFRSaddEar2SMbyX2QtY4bl
SClfA5eMCqHqX0ShbQWfb9rFLHd9+x7N9WWuFrqLxVeJV8llLbMFkMnbKDGa
rc3PMeV9lP8QpxI2bk1QbayHBbHkXm3sTuA5q5oS2c6mbdSC6HIqpgEHdAsc
UYX/iqHnSlOLZOkS1kmkmuvCpMEJqKNTtN1ZEFoWowl+ar6qjG+K5YcBCbD2
53k4jVxN1Zl95W7NVVspCLtnfOBdp4pU/IhDrkKnUuibDzYm3mtJuJcjsPKQ
CQCorN1h8kBhEhYaQNohjH329fGCQdqoGLiQPHUh6WgJTUBsQeNQzDyKemwc
9voS+NY015yXKSOVLKwCPQl5tsiJElRapVTtgGo5bDb/0aA2MoUzOk6T8Lpw
kB1G7dj49Q1XNXklu9KChe7CODlVMEpWg3UiKIXRiBAF9UfAXbAY4i5N8h27
AUhTN1rmD3+rWo1DgwNhkAJS6dHibqyO1CyADj0hqqKcra2UkasIyY4cXBgO
8YGsn/pRRQFETHtkWNYjaV5joXeqNioJ+XRDVxxL17GrUkrAlOyq7BhonK/C
QR6EWxMTeTLoqnfZMot2iNoMpi8Hqs++eIWWgRXc8IOvnsmV+hvD3df/HwL/
yEPbVrNAjUYx8DhNWfqFKYH0BSpnVvsRhKeiIAkHfcLZ8vpGJDc0CTId9UQk
ot2nXNnTwoVEHmuwRS7gwJ5+YyuonLPV0R6Gf5NWy8ZIR6elKUmnFbLnb125
m8BKuvPw8qVsXEJ1R0nxJl2KA15DLbXuDqfnaw0zjQe67R2otdI0cRlSfMWO
MlsmpiymecukdZMBJS7NGtosPY1L2vGX1GYAelBTR7A7Zue6lddJTxdmkoKG
fU02a9TS4X4jcSiwcl2m9bSo+AO7BQ8DZ3HOzFLlXzI0XLNymF9jNIryOCxe
hfX/UYmJwsKkQpsjdAJUETHJgDDN6Axklr7jzVgk4ZJdGJRmbvprmGL66I/E
bkC8YLHlYx+BKLImHrH5E3ETPoAslXsTqVFiw7j78DndaRiUlR0qBtgaIfac
Tz0Jx1jsVsaimt52Lrwl0FMqcle6DxIJrL9DErH/ouOz6jkBNprSVfNY1dKy
7UHXkg81vQ8duVRKyE/uDx0nWs1jqWI9hcC8bUug64w42uhtpUIoDm9DarDx
MxaIMDEugbEU7fSxBLE7QM2nJU+c2rKfhhQhDaD5T5xMZBvIwLbDygKbgkgq
j1Cjav/HSxNVz3l6WqUbO84Eg13uhKBTTnkEiiHSoU1hkXljflMtB83x3Une
mda8a8w/a84Q4zILTfFO3PGNxAhecrfBochI7UFbQ5wavOGdHbcxJUcwUYgX
H7/WcShw/4IUtiS9VP+uLMI5A3z5Bk7ZALvDWRi2YOKGqdFHx0f+Uj9brbbk
MrPRBqScwRdSw45oeJyyLOPIVKalapTb4Hu7YtcKg975BzPh7NDPHpn95s5m
s9+mJvtt9ZzHDXNyKDz+wgPm/cavi35VzlUhV9DS9PYO+QzUTWzZVwVNKX+k
LyXyJNZQLFfOyOQkUYtQwyZYGKkD1FRXANKK2YXaxQr/nuLfFVqqASgtFLVw
SCrVIIangap+bKas29RZeveJhNVNNt1mx/m2u2Ne6Iyn8MTrh0jpTyeFh9qn
Q4gxVpM0UpmQeqtQ29aStsI6hmRxreoAYcvgcqSAUtNsnWSm6gu7zS84xaHN
G25iMj+HKzU9+5xgS1sstLaR4rt6pg6FElCVYiQ1Of0Q2e5qJskcRi0+xAsr
k9cGJ8C+bIQd9lHo/MUtTWVf23j4QJbpv5sjqW/lqx5Kw/AE3vctEHz4YNqE
Bt6rLzg4hLImPCT39avepchH7haqPjyeRQgMTPSMJScvJj1MODC9TxHiTNgl
86uUJH/+UoOB3ZvtxK7WE5vwgZ6Ny7XRKp9FgiPeAfN/h8V+gYKBIMFT6fbN
eLTAfxvB6ZnoCl/CqVmB+JKM9Yd49q9RJ6hyLwN1IyX52V/VBD0i8ifn40M3
tdLjt3ROGvd/sDp/sQidBEZpYRljeNKfl3FOrUzJaypQd9YZksHF1MCmMF8s
XAxfHo7f9AcBdzOmE6IMiCsSuJxaBZ23Z8cbbYgndeHUCluV8czgzP3xq7dY
x5ez4nBXhKdZPK1g6COwAMUOzi1sQoepooOVm8zDLXJV5Xeu6d4Q2ei53DUC
orHdPSmXNCaN5S2Un+Zo7wpQJVJzGl9HhU1cMT04EIo2ZlFJ1p8ZRa/zbLnw
C+nj1zg1SBbfFvoTR/8RUZOiTiBHY36GmyczwYzRlJcXYxPB/No1hrcugl5g
5YK4Sb5MOVKSehGzJ4/bdfnDuB1DCz8pumEuuQMdidq8t/Ns8Apm8KeYNO1S
5LgKG/hJnXUL1zQs2Ouflyt3HaZVvPtpx0k5qHA46zP8eV0wUGvx2BzVjW4Q
faSI20qaxZszmP2itzMccPUrCVPVOUJs3NK7iqsipNH8pR7LI67dyRT2La0e
nFvnGUb5CkZTuIQ9buLwWTgw3reeEk5O68GYWkxMNl2GqTUVCfkl54YvqL9G
qigZc4NsTumlgxNA0TeGl0ibGKnE81Vust264EATLP6NMKHPW9KG8A3GMtGd
0ejVvFDO6ykoHaJ5pcUcu/bm7ooFSx5GE8o9XY0orKeVjBZN7yEUXd5VBO/o
fMYNnJRY52iI7MMfpHaYsWt1Vp+lDbhH+ZlV4ebM9Hddm4aopKSD/kX4bhZ/
xAuA5h1Azk4SlyVIhBixhiUvPDbMnRtNKq1XM2Nq2dC4q6z1kZO4uRmmp199
ssefYZ25RlObi767XcmPk2U5kh/ld7hmU7UFMIUQ4+pXu6S0Nr2glR08/XJi
5heyni+8d9X5f8qde/C4MAGy4bA0jXYw+B/urGBpelLe4p9+Tpiw+oRz8mf/
SadkEgCNtal4yPbLnuZm2y89YAy9FZO/+kLbrT0dkskLOOYNtiB3KDzCtZFy
jlViGxqONsiM+lHU1DLHjIvcsNnG5IxHG5fvxNHNu/2f1JZMlWwselXtLQ19
pSsdWRyfpWb7yNWcZum3pWMAqELDCOfqXEao9N2UJlsVUWsySve5pigft/sf
myzMOdryKTniuGMXsZipiYP0SwTTTTUsQsYgbbNiCri0D0tjUid4qIMPr1v7
DyvI6xs6LmWWZtd5uLiReOqFqaxZy8Ry/OfqoSR3Zzi9jYssv3ejk4zzT9fS
k7l718uY6t67HkDvRTaai1Ucs61sfNAtG7Jd/NBDAgk1mT5j2HcrOMTmslBr
hd/FU9vVSM7WC3mUfVvdTcBHyk3dltZ1+iWbrLfSKPAcgYfoThXBmR8gNYlT
D3XGdIiO0of3OkxM6R0xLEk/d5MOyGlU+GAvD9lFFdm6otZqJe0OKMzfs21U
NbtKRH0tkaONaNWzJcaGeiqLDaUmhbNwfYayjBsMkW4lVM8m2XwBz9IaAROD
U8PYlWL5rgm4U3NNUHiMY/Lt1CyXG2quZkN15raorNt+vTURi32adbe+r770
svWSKdyuzOZ76ULGMXfc4ItYSK2Xs61lbN6VfXU4nxhgob0pN7pOmQ5STu1L
Gq7Qke6T+KyEQ1b74jmkQwU06YZ26UKV7hhf7Pbp+MQwCJvjMGLbY/esNGn0
xEjnMZ6g0NnGLoYKHmlXyMHdErpBgUVNfVwRsDSFdCaWQroD0wz15wF23uZK
36Y5NU/xdiZN434RDMxPZpOV5uUtw//yF9Q7HGH9c+67vXqiYdtEX9ZHvHEt
v3jMAnbqC9BD/0Xw97U24dzEgeQH0C90Hf+whk1ogz1T4KQVQ8RRs679z9ZR
fqJGcwXW2Yix4AEJ7IFJEnECybm5tYYdmhZuauiNUGAjO2GN75MsJZ2yua+d
P65paqe5OZhDhv2cpnYaxL/YdrLTah48aV1i71bWJPFVGudYX+AV9cKJ8jxr
bqasAVqUG0U6gNfIzolBxu0RxDU4z6QvOUDAGezqMFN63fy67sKna260WRBF
ySF9WCzzRVZY66uBFce7I5OjCojGO8V3HpOjQnd6XSgX8FhQnyAuI9g1ANfk
cYw9M0UEBGBe1DOrJrHJISMnAf3sOstWUM24H/X52d0epqewQ6yCjdYlTtKo
CVYqGhimW+eisVFfEzdfkc5tiXZjYndLq75qe75Korf04bMtq6ifnvPn0GuD
d6RhPRirWemGpyE/jtzxWXri2QFOPi7ivHWIyPxaGQR7lsGrWV5SXY96bnVk
fqyE+vrj7JiWanZJpqtar0l0+iyt8N5Jo1FYRS61YvBFOIToY+XxPXocY25x
rfyU/FV5ct+H9YEkVDcBCYPH28BD6fEXWD8BncVYMB7jgOHnuzCfch+uMr6K
sXGo9KW7oMuGhM8U2w+O4sUNukZJ9tIS/dSiTB9Gr56U/JdOdX5osW9dtxun
FXPa+GCEV3mw4218gAA+4+Q1CcTDlzmdDV+Mp96GB3s0yIHfaw2B8CYTukm9
AnCQVL6R/oDSk83uH+MnrMGqqGyYFJLCh/Zw6A2g3Qlx1tZxJvahymAjOfMx
biOXcVk502OnHea9hf2J3tz2luGM4U/tjODPvOOUDdAId36VU6GoeV8F8sFw
l2ocJPEEXnp3xi/Qn71lHlee3ZO9cb6MbmeGf9Hv+0IaqDqHuwTmGkXLEvjc
sfYOu9n9QgBclQe9Kn72f0A1BE4jMaPgo8JcKuc7GngUSyKhfULFwcOV9xAv
GpLiiDzJ120kZjSyN+DUaXrgXAOnhlbl3W3vHozwXM+0rtY7UzeuNqw80jOl
5dwpaOA9r2XiYQkiGupNHvUtNuDBfe9BSr3DalL404GHpYcnh8dKaJZxGVXv
ye3QEBjsIo63nImb7U4YOd0J12p1gVReMkILGSJAog3MJI6R1DXnDFDZwn+l
gtPoYIMCDympW7Ig1hV91h2ZQLNx1htx0nmyjyXDw9sM7XnYxWxBPZqXRHGR
UqMgodYH9/ee/Z1cq9UkWdkzu1+8ja/X8aDwFmRDquKmts+TmywrIpM+ZAfn
ZAVte2RJlmu50f7OIAKFYvzAx+dYHQDEv/temfXsiI41hcoQFmxcAuk8g/MO
mXtRgSmtwFk3l9NGjNhbAUXT0QnkiihReycJeJnbQZDt2qykcqyqaQLltY9r
KNVItZ8IZWEbGN8cp9oKU23UdBWwgkSPDPWyz4YQ/o1VNiCSGtHIY8MPKnJo
vW0eTqCSqBsMSnnY7tuLBdeCqJiDOaLGlJ+jGlXa6dXAgpI6x3YwOiF8lDuh
UdQvjtPzjWJUC0p+9jOP3PRgmwDpInIopTHv2WBAMCQNAdVIYTLa5nBZtD3o
L4qfZ8OpJPzaYD/XtCa1p3h3UUz6hygRYtvE0on12EBTusWvZ9WktVqbtdO6
rJIqGxujiZ9kR2fPlQiupPxWbAbFVJu6Er2g+/dlNmep3W4zaVcbeesOKfPT
mlYoASQAbQyN6GoFrpQ846JarLNh8hWIJEwifMi4s57S1QyRTHS9ofAUdSwO
IEwQjAvp/xM6JI9MpvqIlc850YxMplyNES3kTf4WoUB4EmTQRNdgJYveeswk
Bq96RqyrY5k7ckSm9wYAaHfOkiUnsE2wAC3fEcwkLiT8FEhtU6m3u0g8WBjs
QqZvAD48RBU4m8YXCmH2F+XfaSVKfpgJUYEP3AfFPUDgI+vxhW3nehcXN/e9
O9gvTBam10vsTsAOIw46Dm3pN7aekFUAmajXe5Pr/anTZ7HkEB0SwSnhjggL
6quZjkPOp3t/FLU4YPVjonELuCNI2O2WqLPfpFwSeChBmwBqWuYa/CqWCzKa
EHkSNe2GYjJuR05y9u22zfSkCr581JiO+Y5j45yMqBMmMKYOH/EbLJkhFeVc
nFYvt9BOMo1IurwhWyw6hw/cLhjf19UsvnbalbYNrxVEl8NR0OOJzPbjAqAZ
I3cq79mBkul26l65KrFASm1d2OgBEdpdsN/DZy+xW1S1kmTn8BW/gZl5jO59
4WYycuVnssgQ2/VmE/dIS95wYVIMOWOYypts8CvNucJezQWnCXJrYQivpAn6
QWpeyZ44mH0o2VRkvklaLpqKINlMdIwwugbJNJFykHR1rMbX8RS+DV+U8Cph
AJ20tZW6RGFturuR6NKIYzOJX1PNwcISSXYNs90almJXkeVTphbSpqRpwxJQ
Ujmo6lkS9qqeivRWcp2bhAUSLmwCkiNQ0XoRvyvjM0NqO0udvl6JpbaVmry1
WEQhySFVaaoqernn44lK1aIZdkgH/1aNpkVaXgODS6ikhhlQxOhGjPfGQEaU
i0zZYCo3/vMSdVhUzCor+rZwGbcr4gJ6hcCJ7hKqtKIiRkVC8Cg40W4MYEAT
BZXUgAM6TDDmE+H1PLvCc+AXCGL8G8/PyiTpwhOrC5vC3eSSfnv0vKtDmdeO
YJ4kiUP72Iuj875GRlfgkWRaY0jqbN3GIS/j24JW7MiPC19Dd1cFL1cX9p36
nVpnjMyEsPxV0zkh+g9tT0pZ8CTEyJj/SFcpM5BRS33TllNuzVSaXr11wDLU
4z9IiI2P3cgf1fofk3JL0l8kTL2I5lhia6JFCBgJMPdGQniqriDK6jbTcZiK
P2HqFAuLgK5MUI6nMh5lnKvzzKCjRq/UmZ8pOdMN1s/v6eHgN+S4iZm8zvkG
asmqV+taVQdLHGdXmYnYZ/8KTll8W6vnhZpLap8wdTVKKhTmPd0VoQ1W6G6s
CO8N5OiBNIPTRxMVpirH0a1cLdoB09yQCQgxZt7NdYRLgMvI3mekPYK8tG78
NAco3ZLXBVcoC6zSdIO7/JpdynXGcoMspOv8RPSZfsFG9AlmOqMECpS8nPRd
3Kpz7tYDVkLqvN1IOSeolCX6kmUOIuiz+aHFVmo1uTxKolssP8RWCBSEYySe
tetgCnoBSUBHDLoL2woqfUuZ2yu0Ies+JMwhP+5dHmv0UAO3bZ6VNGFbvsk1
VOFLCDCrsmFCVXNrNR6cbzU205CWXsZ8JNK2cV7zFokPodGnwuaxKgYVyZ5S
uBCchZqhmaZYM5iOV1kOikMYekf8KC/lplWfyq7IHKtt1YJ5XFCsnrvwuzC3
OE0gyVBeIWGfq1dgXfrq+lkAMKsn4ksakAbJmf2QSmM3JAu2Soi/5EamzrdH
HfWF1bWrq9KqJ0gLJDmMZCTHtkfaKKqPadkoBAoqiasdU0iJetXEtLXn9xzt
lTLxqnYlxgYBlOvWhP/KlpxSjx1qkYGyareCk0wpNoygf5mHaTFDcyhAgEcg
JsjKFGiVIPIr9LsOS3QwX4eMXXZSZTUztoNSGSNAStRLWgo0SmafjWt2rGym
lH+ThsFat6Qn4F8cRH0r9f5PtSIMkyjtq/Lu5Ojt+fnJm+OTYzcMcNXsVRaY
yhyFyPxeB4OiZSI60sefaMVt8JhjW4EDX3Kij9AbbXibs2Jj056R8dWWMPTJ
aRvKtHZ+EEO+WGal60rTGjlekJBBWv1wviqFm9pqifDMLWVfiUXQdI+8Y408
ZcpUUDWkMo8XRR0FpOsHj+4Dm8uViCaIwztwXhWfgykD5iq0XSsf5TFoUTVT
NNEueeKlahgYA0N6NeGYLTxMRluKmEaLFY5ki+uJXUmyYkV6MvKNETvR34D0
OglBjlIlzhQX9pQeas0BMIBF31iAwZLhvuV6CyY3IayENFsXbw2PmD6Mwlb8
6Ko6mWcaU8VOBpRKyhuSxBhfQNBSi8BDsMeKd9buBYIZRgPfVYPjHQpIta5h
Oz0S3KQpSGPA/OFvxU2G6+CgbW424o7HxhNr2hPLXxNhlDLbug+x1wLnFn1F
1gISxikM+kwiJh2DWqlORs9+hyQIbnaq/Vbr7iQ/tscNJG6I7Flb62xr2gVV
+MFYb02Ui+ca561jYys6NLH1tRSaMRlqZqdzLRyTNwjyoQpmYo1lpHbHcEUa
bOnBIXyhDRbUvfpmyx+/abFVwt72vbJQsi/1ltlaUVYtBYWxXkpAFFflMPSC
aCiw/msSsSR8bbtb2ZSXilTLV7dzMKNU62/XDzVsiChoMta2hBZsKFeQZm7P
AiaIt+S09t2esansYFU6bzuIAWL758g+danzGj2vtK1NWo2E+vGb1jioVRhp
Gshg6EA29byTl04tEcd9ShkDcKVmpcAST82vauUK/KL9ixHP8OEHbIrdlpFj
kbIrpgwjGbXXAn7kiKpFnsnZqQtQLmGWWwrFpTYwPcCOnWJbaLtlBaE6dbWk
b83G2qJgqZ+leOrFfnQ424/fNASzAeaEec6uCFv0hLO+N9iFkIvrzzbkYzuR
1xawcAtA34gGa7mysf1l6sMylGFg102OpBMTfYABHNfUCOnCZA9RbBvcXq0r
hWuWqJkNMfuYa0fFpWIurpGzEziJOUlKUiaMVEDqkbWG4WPIudGsbqpOFiim
iKGFeZ1V7+QFcvJVNT0TE/FtUdP6Dj0QOkGz0sdMIUNlYigZRvEt4yI3LZEE
DXwDEHoomKAYVopUqWZhgk6sgdNs/VDvd1OckkMjK6hYj3XysG/YgH2LEKDt
nI2DT1XEJqGIprBHUEFWHM0zsf4UFB3+JBTF5B+LopRBg6urb5VSWSfZHDuL
qLM7bLh23NyV9j/Ppj4trm9mWag9dNX91YQlxzzvd/1M2QWDK/+Ce1Y91LYL
Z+dy9+9fw9Z7SG5G+5pkQv3Eu9m1a+VyHk70QUsYV+XotDs2ntfbo+fEcCrf
0aLwtvFFrobcq0KOU4iPWDdTilcI717ttJiSyKNESEK4pU6pKSQk49XkvDpC
AymqBZFYgQdBJ8VCrIu+iD8KHkiy0tZBsDWk/46CwQg+wxn77SEevqJK01hj
rruRyHbtff3i6Fy+rvtcjOdpxt11jakOwW9OTx/1Gv0KbjHPNYRDO2F+Kf2w
cmoTGcEjYdKecP8cp81haON80QeMQzTF+m7U1ZEncpXB1+Eqg4e5SjVe3eUp
tWj1BySbc1YltTiAj/x+2q4U6nGt06uxsr/2Wvswt3vYJD5CoSOU80GRwBSN
+zJpoALJlsB9F6DNYfsPQNUd9+uAlNjX3w6c7i4NVA9F5Jc0u/Cq4HA3VfYs
ffaS95apjqahs+YiwFK+8/dYYzjSl5P8Zik3yVRIKmkx/Z2/9ODbc5BcU8fX
Ui29KgKPUzArsVp1NdPxDqrm9YX6W1xWVbe/mUrWmq314zePyNUCiA9sLI++
QLHR3WCL+AvstwuKEwfZ6YAbNYKu2Hl3Q47gegiMa4FetyOtd93GMb6zOzCl
5dzYEjamSIqkIxU6vY6eZ1mCBfHR0O9K4ro4/5QxRdWsx561HwosR94UaOa9
/53IUWgoBawQp0vIS7HVP+GbAbH0tGffJSqwjoEXCYDFd/RLUKfxw2kgXWh8
t4gjYvsEPGGbJ0oPcWpDFuqUAC81sedlIZbaOpLC3jEgs5DJsMVvtpBayuRP
QeJFhk+kHFRN0glI6LhVZBd5NpEgNkECAMa6kiuKtbun0JNqHzpn60xYk8hE
yxkbkxSacXsWm3VF7IheFy/zOrmsUfxKgODfkYc1j+dF2wI4yDhFJ00SUKqE
iahAuysVabmiqOAuqw1qp+T5iDxzJRkJuE8FaXhd/bWX2R2SDB2Rg4Kxgdwk
Uq8Ld5sLUxtAivFRi0WUVrwJjUkmEtmr0Z5XujQTc8hBgMBLMP2CvFBSMZ6P
1FuvCdSgggPlUvJY0C+Ux4WJ5K26McUnb+qlMYQoN7woNSg/vU7EVd6Z+VI/
R79hjt0Ghn0BW69OECZ3Ie4PjrLxFG14JfsIKMIsnSZPsJpxroJhyl6ZmYLS
x92b7SlbxhrfTtdtYuuP3zSltfqUW55oI9xmgA0MLLGk1H2N4pWWxdelq2bi
vp3XyU5hXNCNSsO7eyk91dw2yWSeX95QbyhFJLJmzOPSbQ2oSfHkCYo0VUPC
j/xOMVrmIIlnxMcllu9R3KBtx9LpppIG/eM37UnQzqGuU1OodUr1LW828CTN
adMAQTjHYA050Ug7pfrKrK6XRDdmCdQsHlPYaJQ79PXdq45vizzT7CAMU2eq
LY7C1LAPDbUL1QzD3WmNhObIZPz+wLQMdiSsyHQi44Wzg/HKRg7T+rhiVJ5N
lxOkjcZOMkQh1MDjRqr7Ox5n/G4K+m4UGYjpcoZftBxdBoZBUIfMRPbEp2BR
8zvRO4pu06DBOijlobOZ9f7aC1arMVYulGHT6rD+sYamkWvzqtJefV18o12c
kT64VOj7WpymWz0qaGKieilziOLyQ9W5AnGTw6EPhltWwVpIrRiZItVKrgh4
fBCulvrgzDuociAH15NpyS+N4EY7o+0yZatPiNNwcSh/WKWltZoCSFT9igJw
99JlkvRgmXO0rAEA3l+e9vZNLYtcRonMKHD33ksBUSCSf9IiVIyklWtv8l+p
rjGe1S+DLer1lMS4SUIZEKssuio6UVojJpdKOzmHGGoPOU6d/sC9O8WjXTgu
bbE/VtevRkDtjOESOo6ppHXo/Ga6ytbcxNvmeZZat4zoh+QkAfl4GaVAOMYL
VHlRrFwPEzbWcuzONJsD41lvGvHHH9+dvDj5zefPtN7wGiNjpMaXZz6VuYzT
jBRxGa9nxxMDR+PiNSigg63lbKtq+JLKIoKgrxo74YspZ/w+jfEDRm3k4YSi
6uim6fnwhO5p+MXTMRITAM/oxKhohxKLKBxYmZGpT2TCouYQNuWlsMB1ktgx
YENEQGl8VmBRe91wVOU6NPptUhLcSa6P2QBBX6uV0ofz7FYkWloGxbrHdQZr
X7C1Eq1rnYrJSCSh/xON9m3hl/FBUtFWdJGe1ic3WvdppcHHblWD59gugVXT
hMJQKaKvFHJRKRCiMqOpCOKLi9Q90RMpmrrNUMw/0m9T8+12O3BiGNQIMI8w
MCkuKLfAViaBG7lAY7ZQdBNnYeoLScSsG5BwmFIqitf/ENuyMvXQMn8hyauw
HtQCrxlujrSIWghnaAZIEKggmwOfsRVP2DCsDzmx2S3N3ZhCIFGaOv2/NV9U
SwwW5PErmvSfEG70fMFJ/iZ/hgaxcPMAcumQZAzt0GoSpJItyxs4qb9EFdlN
IsdYLmiWok0jQJJxj6iZJuPCHGk7EX8sM7X1cX+Ly/FJjA1/ub1FhebYAq9q
YEWocib2ghsLytyk5GhgaKWpHBWKFD5bqukNhhPlk60JH6hjMSqJsnFVzNsM
lG4ApB/85UdqMiWm4uKpzNWWaMhFygysbbuEdbOrdVGPLIAca/Ms4mQBj0Qb
DWsh5TeYw7pg45ILBsFCav3YA+k9mVp4osuDYXITL6zq4i2npagFXkxWV1Wn
d6IpXZOc7TdAudbGMiEFQTFQUM0LxoT8jA1LNV1JyhyLjYwldn4gmoqalpNN
jF5n5hBOqM5SGqsHqrE/rZiFQtX2cq8Eh0nErbSvjoss4dqpfkgVG9GQ1wOX
I8plZZ/MjKn1aMkzqxVPJbS9ktan4ZRXkTGqOPm2TmWlH7/x6yqhhdyhxxLI
PHS+oiQdrWt5vuH/yFxef30Dv55XX+Uivm9qL+H3TVZfi5HrutR1tzWqIJHJ
seBIOcw/jwpNFuX7p6+LSd1kG4l1XfIyKfuVHDp5ZLoAGKe/ZgzL+fq1JswE
fJiWDSjM2bjmNjFHawSJv0yJ7AZq9RsmZCD1NrROx7Pu9JcquERO5QCpLWAC
ZMWUDKF8WrURoVDWXzv2fgvZyCQtwh6oeuejlK1mYr7n/F2/GB6Vdiek4080
r1MLj/y9F1kRS0Go8Q1aEvC8VpbI84ri9T61lcuTonnIfvgfrQKO/AfhZpOQ
sQDazXIeYrfpcCql4MzWTJlxFqAxIruPtemI5Urn2jWDAJxgytDNYapcw9sR
yVSuB+yhwYwJquC29pSmSgMAfKPiGZWPPTu5PLVfmgQTm82KX4tkUXk21iOh
KBeiJmeHbw5pWiwhQUu1bXCdOorrv1p3xXxq6Wy5JLbkvbYt6KoreQomNVVT
dBCoUlHxs4X3m5DK7tFwOAh8PpQSuj+w1l/Dn0Z0qaGOV3rxE/7f2trfo4UQ
zvsfngXfBJ0PeTifYoAsqw9wdxF3bN13UIpj9PTekHZHETAguWG4/B1QKCy6
pT23eNdsVInRMAFSCD2LDh46pThtgLXWJmazN+On9ALhA7K1hPFA3b/D4PjN
WNRjyUJ1m/ZFNEANNYC2eZhRcRqwFEN/rNMA6pE74SeCoyxfZOLQnWjdAnnj
VzJMH2C87u5b/FOC/hh3f5dKiRpcVw67cqpl3GE5OhPAzRsEKfGKQqEppxS1
tKuQOwI5CXRUzpR5Bk2K8OE5aaT7bCmF9GEKk13ZcCaxOSyagFu9VLJKndIr
BeUlIDcjgTwXg5oWXZVXOFwjJG1nAS+hjegmU2ZDSSlUI93mOi1t2Vdc2xTP
wz3j6ZIEFsdABWjDHboxoY4NqA7gCTClcg7+2dsV+ahZlNX8ZaM1pyZBhHyf
8jWqYKSrRVI8BOOStMq1YbV4zlLVLDVc1kYUuTHoDZUZOQy9oS4jyEFvqmxU
LyQt3gTfphH1uWK26QeGuHmqDRFgJIZwWSUbwMndENBhJDqGdUn1H8HFG6hr
49brLLkREM1cucqMuRZVlq4JXfykrLXf7xOv7M0Bf2b3xBddCGC2T1RYl4LU
NyA1i6SrKSucmE61mLplb+wYJEQBls1hEbBGt4K0C7rHx7ZXoosc8LkRRR+a
qnEC1oyJwHqoguU1jSub32lCB40TcsVD3nXh3kxyrxKzNim0xiCLF15qidjg
ImdWU7nH5IjRuOyt4fxyJlvO0rsVULIPVislkTtFnfX6YI7RgdEtn9ZNWS6A
ps3KRZc+S9K8gtmv7YAQbitaai1MXfUTemAWn6FNufq2qCXu0R7L0I0joc3q
/BJEQGxPv/NNGRy3Wy2wVE93zrikFp4FqGvXS7ggzK+8bDnP/Xx1z2WJmEP7
xXXMgVV1bornIjNeYWVRpgXwaGPRPAaS0Bpr8ZOpuhpU4IVzhfdmPxRFJnui
Oluow2C+Wozl79D2E0vV8YYMXDwAmCijMFGs+hXfRqbkmJfwW974id4tOShU
v4bazTSUIPRKbXghnY6TXVgMR19nlceL/pfNc6iVE79ouupbthMC5SyH927Q
BmoBth4RZbqn3LMQ/17nY4yxPibWLsNzRyxTGsEhKd63ZnZTwM+pCww3sqkq
cI3SNRibHMqnmlDVzEQozpMtyeTZVKuLzJKoFU9dbs4MjBk4F6ZaxbMbl6c8
/Ir9yw4LR5LckCUe/v/kvWl3G0eSLvydv6Iu/Z5poBtAEyBIUV56DsWlzdF6
Rdnt28tYRaBI1ggLGwVQ4kia334z1ozMygIhWfbMPW+fGVlCVeUaGRnrE5YH
5CJMq3GgI+kMqQRqEJQp3B94FVTU4yJewsEA9BXhHqGm6ltO7i6ngh0pwaAV
XL2SbVjvC1B1R1LOZTVDZmeVegMiSfYh4hWvrk3N500tAH4bIjmiQWqoSwqB
Kr7TJ3nhlcgBbGTB21Bgv+R4RlE3rRCBJ4JiAyEhlaye+s7m1rNZGDEG3PgG
68cHTXH5FffycP3LjEuLQSWrmY8Bc18ebPYlOObQLwnzlE8KNfGCFdMdc8lZ
MG2R8R2qRVWOFy1J3yNElC5AFQJNq8sFmh/srBkR3n8rsNIvtVqZl/02GxEV
zyBmAKqCZNmG1xdpNrhEO7K8BtX6+Pxxmx8exA8RxXPp7lngWD3wqkO4PEZW
fc0lIJCOy1ngo0ZQSEVIqyGV4K9NUYRsvQGnhWHXYOi9qrjGLF8noKrhTewR
owTZqQ4/2Rz2qvnopGcLMRpvwVI8gCx71qJMVa/EQPVEpj02HZKswjiDXdbL
YHXAKuk+QF3loBMSAzAR1pBVfDZQWL32YYxqFs8z8NfM7tgl5Q7JuCAnaKHl
/6JhExaWPuTDtM3seKzl3CssEo3gHu7CprKmdQGJ4uHJbeQTqfXW46jE0SQv
KTYQ9Vin+TrFHuqVWdMv+5Cd/vufsjyC3Dh35CvSGEE1sGFvmw6yW79tsMb1
dwhpZpuKc8vPB+5nz9stNHNNnJnc4YwIgIvDsQgbMoE9aCPkQVlSb7J2IbrW
RqAmJiu6CQCz40sJ+eQK0T6WfJqN8eBXDI+n2DhT9oCSENJFD9ZITQqL6xVC
hKvxCSZGR3Hs5QbucdE/RF5yLfe2nnLwKbVSMRAJR71KNLXnSFwEqPLwWheQ
fgabHR10A4ZDrBiCX6Mjmp4VO+Ibp0a6Y7nIFvMJuUCZGQZelESKF9qjQh/b
quKCUQyA1SCY+7iGVP0JCG9IIaqlgmLZXDkuQq8WNcAyYn2/y4r4HB6OcsZ6
s7aH5svgmCX97CiLhuI09/v22mPg1sALQKImv6VUWLKgq0ZCnuYjd2EV3vMx
0hxdG5i88IsYeuaTYmN6yY+gZSNHJjegC/0bwRI/kiIiqQpJn/Y/LqL0bK67
pzEPrXCDKllU+1ubqy49JtW6WsExwcKJ8ddtLsj02MBA492NYhmmS82nCLiT
+nLX90GQgmM2gwpe4arhS6xs4q0AQdCE/5qst6367Po7O92wjIdrC+LEBD8z
CstAYklqSkRCcOs3waulicQdlMgVh1b0FtqpBTOB+mK5EgOiWlIXkzzT/CK7
qT2Shj+ay9rj4Di7m22F5exScFmJyiXRzcLxWiVGOYA5PXm2GcVOo3gs8Rme
N7mzKNYeP1GBS1NlYv2MPGa74mCvLPgjv6VR/m9CMGMy6nskXaRfZi1amgBN
AJ6oOzhnI0gHkOYG+bNawflbmtQVCuFDECI3XohV9WcMB4inwYkHk6DUMrny
S3FcaLCRDDSQU5EYQoHoUjkoA0x5TGW7d1H1Q4viGp6wckYS9jkHqGlHpjEh
I0HGazgRNcMGwfq7L3YHQUo3ip3akQLF4wIITdLkwrsC+sAiMagG0MX/u0og
d4RqptD81Xw+ThNMo8zopQ5USCAvyAf8eHkB6hVIAVN3ruacG6aSCkEERo40
iNiVHa6pOn4zci2YoQkGTr4DjDaWaUhQ0ET0918lUtAbbU+F/zCVy4iBJuNb
SMIa+0qqirvZkFPHObRVYDyiXa7M17A3Y47lk7bxLV9TRIrLVV2pLkdKJhIu
2KJITPPQvRL7iL9wVz2jQVMWIcqaGHUXF4026p6UhCwNomhSyjMFZ/PAqWaY
ai5OHdLXq5QWeh/wH0nKMiwGjMDQsIq1dRwBrg0o7Rqs3bRIYAg34H9xUaZ8
RoWEArgFVF8KizbHuY7h111v8jW2Gh/FExCBNeOdekkvKZ0FgAuBZU/Jvmbe
4+FaC18cV9FUudLY/T4XV8KDL0ENsgSYkrHdaXk1b6GzPx18mZEMgpEYsIut
NMav/pOyQ1nkGEd7aXXSsCZWncVA0jOovecbVKfi8GPri55rIZsE93obRZR7
A5AUn47y9Lnynk3Pr9XdM5pVKlTcx5JjPXbzu7JdeJDQswhCs0RuquEDnNAS
BKEyM04UCTmdNyQL1rw7CkgvlVA04JQtmtRJIkhV1TGChXPtLsZduJhQfVP7
ZQgQh5YqDmityJgVmtwwRYziBtyMV0xihK+qK7PQeJh4WVg5tDcbLj9G4krg
ARkf/lPjSfCNOnpChK9T2wFG+T3//rDbpzZ8aYwgR0BHoAgF9VKN779aW6gR
ic13bZJR1/qLNPkrzrqiBKe8Mvoi4Qxp34JUI84jd7wuVxM6SlimTFvUAGex
YGCAMmFHcnwUNt/Ri6EWvJBAi1SMzDREpDl9cOyEjxHKRWjXiPMzQjhN83QD
XM1oqb29zeJkhspCGoyz0B7YrT0UV9xnVTiSDKlGuE4fFOHxQ5t6QjL2WXKA
iL8/DIpZm0ULRHajhT5LvMu1nULMcjd0PS3fRG8g/rJryr0DyoGPUYvWMmRP
GC/D9tXoRcnT978TiwYBPpp2Uxf1/cQmwjy4aFT8aod1OEBjSBSRxAEsQbWE
ezMnc9aEARKMZZkqKOgj4+EhYCk6UuvrsLrjtb4K6695wDRlxxesDGsyYZRa
JtlGtmIPOyrQuE6AEObcWXIPrOHGh0y2IjFi5jNTbxMh095h7Taj0In+7t/D
vAgaocxHEMDMNCpkg/6tUiosiRJkI+tdk4wvbkuyBrjQqyVGVc8vMXJGlrBT
H/8GlVx/y0PbrMFo2lucXQJ3DCER6SKwxdBPlsGo780XJMK43W+kjSZPCaJ0
rQgB0xtm3n81kp/tuaN8hciAwyf3Asv+jFcjmg1JGwKE7zeY0kzYtDVjRD3i
FxAMi7CZ8GnM2b1oKWuhS0dYeGoDChcBG8kneLlfEqjA3ItDQkuMiI9CPt7d
LMeAcMRRKOo0tFEK3vu1syOF5dS5yOBcjLRNPraJlF6AXu9rst9OBn0hAyXH
gDtc8xkG5XIyoDZ5wSU0EGfH6cwzBHJEJ7dbgL9/e/TyT3//9snpn4TeMJCY
TZ8UXczn6+Xp0e7+4KFC3/p9otcu7qBqtduLqZ+s+vUgcTS4tRC9iBHY9Zby
squTpRcWwZM48867hw87URw8KG/0NLQHY6NKXvCLT3Ln4lTsZ5IR7v+iEQJt
cTKkDvZRPFhI/vmFo6UquElI6sgJC+fBVvdb//7DNvVN0IZicYfv/NHE5H2u
0JybSEx4q4UCGb0L+0TlTB4+khdtwk5v64UZVzpB1YxtsNNmNiIArBSIEKhl
51zLIJUMaNs64LZoPMvrAPQ73AJZ57AjqO3YEOFh13PHNbGYr66uM4pwMusq
Dh5qOJDf8LJJciafk59fQOI8MaZDKGoaDsd0xKCoKsdqhbY4sFCDISX3BdeF
cSCw7AF2NUQWu7+2wwq9EjvvHg1tWGMcDsZ2NPP+cT8R8Bh9tuY4Md7fFUma
dfdQ89Sji+j+lz1Ta+QXNf3TUMbeTifbfoXmgxdoPjiazxwxTiNi2m5vwnGy
lmVbFLXaDpfJss+Dg/qzRp5kLs9GzhRPtLfVspKWhH4/Ka7y0V1IUSxG1ZZK
50ej6c4vuzwuSqOE2lfugGBYZBvj1xJlvnHBGsbI546/4SCFWJOEp77ua1MP
PDCN67Zj29p6LuobvivA1UFJcYSnKydgPfZ3JorL8juZkbXsVrOattXNkBt4
ouSDeQmJ4V59MUcbhtQhuoIVUSi9KOYS1723lXHSJIsz9RfX0pZJlLWgmzJu
YS210UfDjUYLugFxchxkqOyK8iaMGL1Ts7G1g9W3lBKOEZEZEn8XukO0AKuq
Yz/GXlH8RZRpNxW5/g04WlI5hoCvHeKRt8MOSHn79I/9doeaelVfYP8gaYP1
jyMjbPggmDSR8Lo3kEp4doymGhkDmqein5HHSfjQ6ak2yIxbcdwi9t0quZOq
He0b7paSbO2Q201PTqmHqOBI0sFNclFedUFCBhfRjHUxUD+vfNI3j23qtJzJ
PBv8/fd//z2pfnhHgz0MWZ/624XVzHycl73bxU4S6D3E7CQKqVkL4sricgwg
+YDPugki5M/jRcJaRhKdxCZRcYrgiri2ndr3DlQ/xWB/O0cFkk3FylJwO2Rr
VotIn+9wHUxIC6aXKDGYW8HGTbXxQ/R0+OGSbiqhX9DIyP+Cecagk76SYWj2
E4/HcSMx0XBh2CC+N2G4sjXDwspq1kU/ltppYPaQI+F9t46mKXZvTNatmi3d
B/npebolsAhA3/dPSep4FdE+KVtS+zoDzM4xXxPlQrhWh3J0RNcnMxDJ45fo
kgdT2zu49Ilo9EAZRkkdRbXDv05cOIryRY3TeQpa9BX+llV8zUD2FB9IW5Kp
ngDwGhjI6x70b60QvlDSxJd7cuNjRFByHk/KJQLZUxvhYtTHCwPydZ+o2Xp/
Avf3Lj3nlpfA2LwAP9AA2lLDMn1HEHNkA81TNY7Crv0wo+pOgbEmaSSFOgcU
IoKALZ2AEkU+hVj5JRUexthVPBvPZ4WTUasqwTjoOIMP98a9QAyiragbOlJI
kaSBxgC1S4Yg15Kj1rN6qRFrN4v5xaSYVh5EGENKIY/mOl9VCHoDgQBtoseZ
dBeRTdMzXmh57Et2NL5CLWzLgdq2LgvlcTWHFlVRMHcR1FvDAxTVsVCZkmI4
AcYYCv55gsL0oWLMr2ETtesNGqfmbGMA3IOuq5pyVCMHAqLDxnG+3bdF/iYS
KrJW0bvqZU+P99r4otS9DWLYok909Ki78CBEyJbatv5Rc7sJypQzI83Vn5j9
cSeELapdOcVuj2hDYi6tvHl5LVxlv2Pgt6lsZmMEu6mpKxWCE8cjstcSbpyB
tQtC3dCoz6h7HB2OfktlmxrPA5H6I8DbBmemoWnfALRXRWFuTtlfeoMPiOl+
UND8NWwRA3nzHWrEdDYCok8ekfYiL6gCLGDr4Uf/AbBXEpaY+/OGqTxcxVFn
UbxzB7/qKQwHVqZEoyewiQJGh2mD84V4GTSICsMrwAylhuoZuBxuVgK6GVaG
mc2T6wjx9rglKyrbTqFPGPYKgUgXBG5uVwoE3AWGhG5BBIaWuQHPkQ9jOecM
K/j1BfOWV3z57bZBAnpTVG9Y4tmkkdb545Pzx21VwBGJCLdAPwZNwgSKEBI3
N0FWwDC7Lfcuib9C5K54r0yp2/RYFAf1/fsbnMZHTIb5o2tgk6nI51xCyri0
KKIZgwEIdJ6xePPPDhdyQ5L8LsHZJNELfm1u1jTRzjRdtQq9b7p6sIf8D8R6
1Te0rLJugjdI2J2Ba5GAQ/23KNeBZKGy/7rVbFVtj2OXXM1SF5xKNBh35Sds
GiN4SRBGhaGdVXVzvcglYjHKpRwXRG1Lv0hsH9F8HFk7RlOzbsvclAFhRFny
VFK9dIjJnAdz8aMRsMcUMq41xOWmME3dBhnKcZH1BeQS2v4RuC5nKPNzSJmK
sqDEUazEvrhdAvRJbS1tJ+JZaHOsK0CYPkGa6KGvkZXa4fyiSMQ7RTLJ1/Mx
TyOyTSHP0UxNBGqeQNKjNhy/bwo7yV2t25m6riG4/w5hf9b1XF0LUpEB0yol
xJ6hmyB4y9GHqOnrO2Z5/Ed1EX8CHz8l78n7r26HXeHih8bb/BncXIvpeVHl
c8pcSmktke1TRS/Vyus0ioAjSvE4UDMwFo4vRRobGQMMwOkGnNPN8kTH4rgB
7TcYCoPdVZlE74O48uSGpPTJu+DDzwDDC+wgrBKbSlXh8Tc4y8Ne/C6/w9YY
NRtq3TwvRANv5M8p2wUKA6IL7nzgqEK4Kxssa7J+8Im+bPkHhoWDuCEC8+AN
47bhQnWz5zcEwjthr6hnusG9hJdSh0MqKWnXXm310cwv/gPTSaKrKG43LMHU
ovY5vATyipGomQ9e5FXJNTqNuRP5mFstM3+IkGwrmm2BT42RDVNV1U1nbi2K
dRAN3gyTInfpLuXd1OrmxqXaXBjR2zY3psYNli4oXEE2RxT23AS1bEI49/qc
xSppLuj/ULz6dM9snqeJH50+omKikhZy9iOV0Zyg66QSuAsVRHic5qwFF68f
q4mZtXhkxT3Sbni4rJgbWiNSslHd62Hnrel0xdSdhluUK6jEt9Fy3MS7mP7m
1kHWVlGN/DJ0dHM82SL/4wxi0MoEKbVcUg2u8xyB5dxHHVzoJYYgjbv2d9fT
4eJqPhtwfp624/bHbYm1fy7DfTHHceH4B/J2COuCPLA6zSwKZl329tz/vNtz
P3F7btbU/bfn51TglUsnvj2DQppySA/BZnDvNRaWuqS8+0+9Qz/16ttsCX/R
1bdfu/oqN4V8ocnNq5lPtNkTD9ulyWEtGaq83tDaosPIT7G2LEDg+HKQPlHm
Y63FqNqtYS/cWlTrdl1biWnWzJ3sav3vvNwPvYuV0UwZZ93t6YjB+zCdwMfS
M98LFwsbe3WPdNBjq20IUBPg02rpaSRU2DrDhZkBOXWoBBwZul6+f3x8CuaF
l6dHewf7ELFG9Hf+/SHU3qUn+4PdIZoeqoShkhjhGU0fSB6afSp54K2zx0/b
OD7sqdSCojoOJA63YQCJolGHxPygYcioBldKPi2WpFxj8i3mk/NOvvC4uowI
p8mHxAM1VK+FkeoPSEckiHf8Za+7A5jUi7tY53TtcWxJmBXlrQt0epCstfp5
Fy/s1PX4xuTIk77JN1UkeXg6SAV7onlD5cLo3HlS+5IFjy1qIxRBvV7N3pDG
jdOk1aBLj0J8GCilSJArbWy0awYwOtq9L7ZpJsihSHE9v6n1MuswU8r0BPck
l/pz9E3uxho0cPQGLRLuWFyqOhDU1PsFgF9HuxQfgH8+oMFh8h/aQxNW/dj8
OQTzZ+B24hD8JldVWGue/fka6aHJQ8UMowWCigtzMjIxoXJNSTQzXWH1A85B
RuvxncSrQHoQnRGKRQ7N92imZ9NVOmxhboB5fOF1WUjVICSfWCdF2cDkFme0
arQ1y5TVxMhYXXm1zsS1+dUuF9E9NqxdsWFlmRhtmrdMevg8002jf6d+I6cc
0OfBj1JsNIiRMGmSdHNuqM1H3jCjyN/3ZbI6j37/nMqeYACVmlpzjHXAopFB
/JyHIZCQJbsicFch7CFuKklscaYQlYOQ5Fe+pqO51XPttJZ4SlLSeCfX/zcZ
1qUD3C2tqoxkru3dM0CcBE2WPw3d2vWgxWANd80azpwmdXW9DPcGrPmyMY+D
FLOKMJ64Fm3DxuwOomi8RMpQ0BDQJIQSRjHqo3zmkZgjb2Qn4eW13UASBEBc
NpGfTJFRe91BRPG0scznrKgQHMCdbgJy4ZDI0I0Gn80gmNlDB0iOZDMziAvf
xEmVUmsmtNBwnUrieTZq12TOkAkBOGGcKPL8xXnMi5DGPB01JNy5tuajMg8j
CCRmgivn6Inxpdvy0QhVC5rs7ZBApEmtd/RYH6aPKxbZxAkw7js38LZUtWrk
gx7GAMvB6Zykip0ybvG4P0aniY80oXu7vmVi3GAf6qXxzuhFG0JGNmxAOlzN
DWghNKGbGxXdpCi4GhH56Hk/IJm2gtNNcshQkBHJlyw+UURoreFEM5zpELZD
Ag5wC1UjSLSpWKvxMFO1vGaMJyyScLfs1aJMD0R8inBfsNwMXgSaB+BveQra
hZDBaf4fXrCuspb+jX1PbZYj30L81mI+u8J7Xm0RiQ8H+MGuo8Yj90+skbgk
e3HpC6ax5jMp3q0pZ6hN9rHJvXpWDAvtQVUugSFmAfJHXgIBUPZe6ljC3AcJ
8wZTP9C6ZF4N/X/gmsVgQrUuM5uDbUJvrwj9qL971wioKahf6As+zaHQjFbu
l/Na4lH2hzzMqjZS/iLOPIAvICLVyfSQfua5pE/oyeuTJaBwwcMR4EfAHg0S
VpFfSU0tzwPZRbqc33Sp5Cl++4hT0mbeqBm84RYUMSPDNJNRfqP1rXFMkoHM
mA7WOAuAISUCuL+9LicFGs4kZ5WzejwShP+MTSKAmTgHCDMNKLGZxucExJsi
nT2MzShGsiHm1U0OtZR71UKlyf3wSFCRYCgMpOMrPGvpT1LHcTQBr8lNxHLQ
GJndojk30OIDnrYhxfCDmBQftDWBgF7IHW+dX6k6X1s2OPdraJePe/1Qk724
opPCU2Oohy59ynHDAbcUfuOGA+9HjJm9Ez8Sg/tx17/vcZttLUcU3foPHx7w
d0OVGTQ+3LyOpjQLTevIYLAz2IV0EmYWDQX8uA7OGy0/4W26sko/smBBKo30
+U0iaM2ALmnacs6CCdEXv0HYt1kJre9u2nq9EiiKOdo2lNSxDQ9+UcODxoY1
fuCxSfmfUgjaF1M5v7Lejl0mUhSpwI+x26WrBujQzpMszXAPgiWBVzYSIGNF
3Jvxd024CwoHRP1VcByFF91nu2/timG4nm+HF4PwIrjdvKCPMSS5ggdyEz5d
t7GFEmCK7uKaM2Ul2IBZJjU2uImSCmqw5Fiaq6F4d1NqblRCxzZdJzVsg4Mu
tnG98qm6y0KBqClFRE250q5lt6pwp7/NWk9fnGGay8vzQ9lBTDJZuel8owlG
7q3oJXOHQTlJxHCHaaePJONA+4JxC3ftQYTvjOtAIQSZhHRQSdFbAHN0EhnW
xMC0zcVqtNRzmwXg5siaWTPOK5NNT+m05Pc02jNByN0wY08AsIRrAQoOZCGB
OGlbi/RoHZvJJKvfk5j8t6wkD8obexH8DYgXrfIYF76agS0Z40lNV6P5ZIL7
SEgXi7EtBuKXVbjI0+O92FjCkW9vYJPcQs8BxJGDSXnhvN1EtDu4mcpxZUFM
RLXLUbEDAi+r0UrB+mmxK7y27FcxjxrGPGpoeNQrw3eGIjqGEICWNe2quyJk
XVgVZ8TIowrr6OZdziUBUm9HqBOu+nbddnM2U8t0J5iXUWUzc/GJ3RahGDjD
Bqw04LLxw+Y4wVp6VHrZo/ChT2Wwwy/IYL8wl7ulIoxrmJom7WBQJrfZVSQ3
oLZoDetvIZBaBam+SGa1a3M/Jsn9BpLcv58kh00kyUQkaLjWDR3Ol+Bs8IXr
YnID6vQCl4Yk7EAxbflatZi0IpVkQ8ZmbmUanKaLIOIqFSGUWHjjpdyI9vc/
jfaHv4T29z+Z9vf/p9G+zVluDkwwGUp+C40XdJNTlPzy1zpMCb3Va0deNUxq
R/ZbjJxLaHeVrzLK2qTNwTeqGTSQslRU7P41bsbEChgllpx4NzcMDLWqVpLf
6D3NMA12c6UI89V1IQEmeOrNMN0+p0YZnQvE4mBTvyT5Yb7fNoRprdDSiL9u
t21GuNjRUa9lD6NhHqpxYryeeK7RvO8jqoBUMPMiYWSPV4ljtHRd4NvB3p4T
OAltdFIcnT6CUuF7w6xFf3XzH+ztZi1wG7fjPvLGSBOE+cW5aXxDRWFkdGLE
AUjvKHBCvklsno++IUdDjemo+icSIbVfn2nonMnrLXlItIZt8STmE038RwBu
BjBkggVAyw9KChhSN4oJcur/igRv48aRo+W5D8jBpUTjehSLcHt8qImadboA
O/LpX7IG4xSw8D1D6ciX3ZIjNQkdRbPWOK3UPvc27kPIM2y9FoYEra3ZbM5q
uL+7htkE22aBVrGIH7ohG6LXPnsp7w0N+3WCwz59W2YNMWStsx/bmwaSyWBS
IZUmunzFefboZJyDchFEkH0GeZl1z5MRha3A9cScQmJjKBlCq0hDzLOn9k3W
RjVpiVlnjCUcCBTBnsxHb7hGoTvPLyY5ohbYHLPNTBSGxZGn9NeQQdhqE5Oh
XfUyJJ4l59PS9tUDBGF4UYBMvtQZbNabXnd5Ntjh82wQjkVKh6VFFC5x89aX
BewD7NISmQRhLvXTEM8RRR2wQW460vgKo7rKdI06cjdOd5v5+Em3Ki6DN9CN
rovRm2o1/ZxVaPF3cGFJ7c3pfJzt7+3t7rc/Y5FaQpHGVo6iqDdUc9ogRWBf
FCBstBvu+V1YvWHisl+3B2RjXLdCn70gLKKGQO/oCYUwhSYpuGIoOCrFMoWq
sv+pFmkj0ZMEWaJLy8TchJCoNRFI3IJj8Gy/nfM1x5qM2zRQfVXzFR0Ad0wU
VRCB1ficBXpXhdD3yHbAmin6EeXwxIGiodSL5Wya7jK3TRjR2InDRoLt4eKF
ioqJ1G0SUecC+VhMuDYbuBm85U4zL+OMmFS5IQuG6r/oerm+ZjUIkjrSE/2G
hQ0cF+GkSkWXfNylqKCcKodkQc47LAxFOkZeJHCNgG5UzlZapg0T7CmDXYML
1I45n4zVsfRK7yUqhjkL0p7cDlMNFBsQlnT0Oao4UR71R5NoItehuWLRSTYr
TDAxrJCUKtLkKbNJEsqRvnbNF2xY3IAvg1iPMpmmNHlKMAA+9gk759gyb+xD
uGsvzw/bFB6Dr3mzOSvkva2/mM87sr5gLecTCnbj8l0km8TgUO2ESvhc0DWh
PXeldLklWW3z6ulqAQMD7z+1D9OnIivoMajuZqPrxXyG/IgZDEbNYlCb20zM
AwfPm57+MKQV2iP5BuExAcYBpRGKZTXpg1wZSIYtkV64RhS7QgFxDHsDRL/I
3JV4PR+brQIYoRo3gj3ROcd+d15zu+Q++e4+Ecej039GKgNiZ1PEA7KEAnQ0
KuubTHCIROPI9SBZDJtkPPy2KQ+/QfD8F8948DdXEx3BNgDXcrO/wPhZL/t4
KDFekFBvqf6fyII4rGUSdFKb++XzWeIkzIRlHS0YBu/SIBwkUypyRoTw3qdY
k/yEHIk8EdYSOKiacyb2MFtiGM4RQ1V8HHEAqknld7lQw30mcH8IUuKr/8Db
86QGTsoMbK8b1qUlht/N5IF8GoLn208ZYLL2LeSMaCymN9EnTDAJs7pvSO1c
UiyXjQvN8UEfRTpPyP0c7ufzOdYrhvxGcbHIQYhfTY0O0EmqWWLwS7TLe9/y
9xLwHL6zUUl3BNhOyQs6fJDJApCYkdMvFz29PtOfeF42Kd8UTcMTzEKK21gF
SePYmr/sjYiGPh0IqQ2qSqLRzA5h4+AlKfIGnn7OJnGX5TWVYCWu6bV9inLU
82rvbbcVg72hILCYYrqklBoGicoYGH7y5dIRkhbYu51PbiFGlQAKnBZ/B3vP
xQpCK8xmoieYSmZzo4Mu7FxktS8YzDthP0neMkLNEi4fIRikrOGspCl6n1vY
yo1qiiDuddt4TYKeddkwvry2CYFIi3QOyGhMCGESngWHt0swahEyZWddYJgv
18rn56K4myvK89sFmCXGTX3n6Oqlg+nBCv1nGJiDGBZVJCM3jIgB0ly7q5lb
FwAOwzKgiVV+ez2vCjMwNgpqqFOErUOPq3vGqFHSEhdiauaAXzDp8XU6mjuV
d0F08zVGD9uoGMJRfoNts4JoQFyVUlhGIlWpCkBMbSEermBp2lfobfSx6rzN
Nx0lfhqF6FoiwgiwruONL0wufqUp/LtdBShD5QNhRDkyiQekdn2NDVQgYw1w
5WD3imxSyZqOEisV7oCt7Ug7EVQH8/Ud4XMJlfgQtBD+6wljKsME2lyj2nWb
qARp/38Lylk/Pd5roR4vFQLEt8Dq5IcMEkA/xMFbEKMmEWwfaE3rM/n4cWsI
RR2/P+y3ZnDrTlBvvLFyBfawD6WtMUvDdHEZTNd1MUx3sU9dOAVpbSegQH1g
AWZdL/vpXuJwz4adxcjPRANbIh/t+iwum4HGzcWy4r0hc/Ir7AeFOsTnyQbM
kS2Ji/nAdSLsH1NFWxI2twyEIi7dbbRxkw5RU5uyVhzfGIq3PoyRk/cdAVpN
5WJujCiwumCci8Mc47i25s1I0swW4U1FeXMwE0eJ3Ysy5SpoKlQTrlWIvV57
kTN3GzJPAtVFBGkGjoBd9UGVTBpdgrJeV9Tue19d3EZEqMHAx0xqz6z3cHDS
yXiwt9d/CPvhOFze67epCoxUVWvDj4O2X4OOBVpPu8FbF+1uq3BfXrTjsKHv
3G5q099sbY3apgQnxe17lag1FDbl3hy3rWdRmvg6GzxwjcosWjw5+MAR4GFd
vFVHun92Ls9OBbJkYZel8q26FSpghXwmaA3+3isx9Vi4ZjJOMqUtwptJkLHj
dULGgy4wviQlP1pb1+E3JOVrxwj/+2j5UY2W10eKCQFfNhDw/m9IwJ8a02Y5
tWvhsp3S8H7TI2DSSpF8b+ZVBbXQZfCaB+yjsW3MMwC2gvXbm+TfaJ4Mimk+
Yr0XOsY4GNzpHYBcitWZF6xPLiGsSfSXDkKVc4Yaf13vEFOEtMOwrughZGzN
bPrs7W4HK2qwGZstZdhQdS0Uji3xvW5oewkh/hh4hX36cai4zwaQvDIPo7jw
09Kg/Bm2UxMcJI8rjDG1OM9OeKY65wusEa8lt2LDOt0aZHxoaxGxFlnx24lq
Yo6mbjFhmMt9GJR4rn4Z2gplCERdNHBO7ksx+heY60mkVHEkIX2KGLteU+Pd
MeC2CVuQNJZrnq45daooiNsSpjrFfBh0DMtNkDhvMEqcGBDCYwqShqtgUeUf
g0GzeMdZuPfksmCMZD3bxKakpJ43ZaO8Cg0Inz0MbkPbHsfj4BeAyiQG8GaD
d/7phNLs2+yfbfvuioifhjZB+8ktmBGBn+OFcUNGvH9usjvH4e6Mv9juQMM0
lWCi8PPVYr664Wombob/JHZGL4/L27IiSK+bbr+d/pRz6dxrV/ELxjxMS+i0
g++yKyiI8w5X5YYNP++oOhYseXsNJZRYGyc933i6MRW822QDTiZX+ZQcXLIJ
Bf30hTZCOkhshjxau6r6vR/Hb7qy0v/nre5RRODFaEMSJzOQ1JS5B7cGovFW
C3cKnwO+lRp1iAGzj43NmCmIGxOhGQHvfSPmqB0Gpjo9xSsN5JLFLfvdLldc
fIBTOSpTOyslypjBZi1BzSGM6VEXH4GPwdIAiKBHTsIhE1DQVCAT/dK9zn3m
YU348u2aFc5VegxsDDLYjUhk7EiEywEiobS8wt4Wqhk7qnGbDy/9ysTzP59m
OlkTzXzD2ImfQjXZ/4ZmyEnkmpzRbYYWGsEKHXWxja681KWXvB/ss0iOxtkV
p76a1cl2GhGfHVYY+cMCI/mkYB2MOkLyVxSaGr7knXq1+DfbJ0qIM6LVaLo5
4SZ135ZjR1yEa0J5jCvOiV2BP43xqyTSD/UMJKIQiUrAimQOOFoQC0GQNG0H
zYWBRI5UQNiaXy3ym2vwu5VXRbXkKBFApiZTWR4vF0+LDzRZ69l5SI2D92ea
vynDQm6SfnrOCC57vX4PEVlenh4d7OwOOAUVcUHCcEbMc5mr343X2xJCoC8S
j+DCAngDelelQU6x/KQeSMeGA8eNrhC+p3FNa+SAHgI6hBbpDEaPy2775V6C
gcPR3fDK/D66Ma//f3JhPv9FjO9TuJ6yDHpPAW9CnBrlKQnwujVsZKMNgKAp
H0DxRfeg+kWbEKRm4jHrdz79S6pYuZoRT3CCjuVPbu6JT0JoZrZANZU7AMYB
DszoJfKKGxBCAffyGug3mVxr7lx9ZFB+ZEu//DZbLzV9oVvqK2QhyCY4YBrs
MBKZx156IttnZ+evshdgyO3I33cPhvr3vYHbWgg9md3M55MX7rVF8IN7F35w
K+R/2+sPFn0fDFbOcCSoEpcLM92KKY7Xo9CKl2hWFSnTfQ7lvscQlQzrR9mZ
zzEegw43xVxpI+wIfgsmZJuw3GJrD5nguCvcNEDQiHI00e0qlWvuX+uvsiN4
w/LyptWPhdeRftjlCH00vtfaC2mO7zWahSyPWTLjJ/GLVmvTlsyUvfI3YWUi
rkC4obTVqFQ3yj4lBngvCrZvUPQLGg80QHpSLpeO1/GYtukm3xbRaSUL7SSC
Bw+GB17WoopLcsPKDMkct26N4A2573GaakXNb5yQ41RtCDyG7r/ONOBE6tVd
sJUDjcUXd9lBR3/PwW0B3mSs4IupXuhJ5McTx0wyDMXm53skjdisOrdasCe4
SySZXTAAbslpNhg0gLlk1Vy8gNAtFZ8NcEChJbTY8lcXUCV0J4M6pTAu2hNh
Nf4W8CZ03SE8MNiUCIHwa7BTSTxMiMheuxPQgesP8EXuupGQG47qpipW4zlI
+2GJFJrkQmHnWmzxLgSvAc3n8+z1uICPz1E+xeG8Fsx9Jaw23pQZLHg2iob9
s+voZ/jgZxpmC4f5M9cKzfh//se/7fwj+5fvssHwIPVwt49P+4MHTU8/fJft
D/Xh9Kb8mcvcf5f9DcIXdzp0M/9D33GLulrM7KsfPsjBG9vhbiBG/kQ+FiNI
vsNf1oiSxC/xzsc7rQZLyxL6J5gc7m/MBrlFmsR+r896BG3uL9Aj7tUaeLl+
kcKwWRf1MGTugj6lt1o0kMcgNjxsb6I2/DQcHgS77f79CXu9t/8F97qpsbV7
Pfjt9hqW6lfdaejgvn1279hd3ttol8V1avXD8f9r5/qLWgg2sAd8gaO9yc5E
B7AYf+IJfPAlT2BDY2t3ZfCb7sovPoQAn3wEKUMFJmRgAksMRHqAQri+1IUY
dN6T+NMYj9V/JZHrdzeUScPh537EJOJKNr5roGDApaC+q+Q0YPFhEYpyg182
XwN63gmLU/iy9WObt7Nx9QaPTYPiMWTIxhmxGprP60DmEg+PfxSuj1gwALSu
ylakmDeUJkWAqPT6A4oBjF9nivMTHNxcR6OwXN4AJqSloKxE35y8IYSEBZ/n
FQrjofoPuiWQNpsMKsZ/pXhyN+C/nr3oGqKoQz2XAdE4bWbuSPYtiaf9h3t9
193xyemTw1cnlMlYUbNPzh59SrtoQ7Ht7rh2sZFqeQcajW/60V/Lm8GntO0z
Z/FT18WjvwIjsFAZ9XxmIiHGV4VNajhamsSMXGM+Y4eOyP2wFZKYtcinmPlF
ppq529mbq5swDwfdD7bEuUF4bRgALt2ToNPW+/c0ilrjjTMdF05tpba4qF5Y
ChooCv4r48HIN55qnGPtRjkmVataIaAkrgLu7GA4hJ2FLGyfopCeGIfVytI+
uWdZe2Gp8VS1uJiPPiRA53FcYXxNpbnwBNeLWAc4FIbA/sKQrQYL2WfcmmYF
U4pR9QTsK8kZM8zuD/hVgGZOlrn5QlCoNphfBW0KU0kjvkOGhjuQwpeEr5DX
LLhA5heVe3NZpNAClL4Zztmw9dTrnOrEeSQVxKjpKnAN8Btbf94YSQlJodbi
6Ho+rwjhgb8zrByyU97md966wjpsTokp2dt8MaNuECQMTn2p2ace8YAb0z3n
jpDz2rXyWI7lVAP+AHrCTW0CcWWXBQG+0eGbBGiwlNKLuTLl0sO9l4BTzzgq
cmn4V7v8DKP4gBUSEkcxAbEJL/CLYgkJzLLNyWrpxDgkM4etVSA5TPK3n1R0
iWUg8st1rEMB+X4X3QKhc7B1aXNS+6qbkZmtPzjAiF/KrZeQfRu0C5fujeY2
YbKFhw3oBPXVrwjEjmu6EvzDaVGMAXmCcHUQ+EBw/WaaXv5jCHRk6r66WR+H
DCSsGGtidnFoZhnimjoQIGhogOW1sx9Fro5rRaIExCUMAu9PDAv4CRUykRCC
AmQb8BpMZ8MvR1hz3RNz6DQpK+/IF0eyqbh3UVyCME/hsga7wZ362dyzNUnE
omJXUn50eW1z1n0a99nxyaHFDrKe6HgAJhCUF78ZQEVhSfA8rAhRJUjlgD2r
IVHA9ijyhlRvuLzAzH2UGE7ZMRQdJJxKghgDkJK8spR5NquWRY5gBfnouixu
MXIBm8VEIsMIltcLnAsWNvZwbfAp247dRULI7jAQj+Ml68K7fQNBlnD4gilr
3unNauGYYiGpcYvkcfgcdoCuHJyZTblWBDvlBhTuO79hITPBL8LT2MSzojx6
Hto+Owrt2DqsxvQfiH5ArIp/3SP4SfrHQfKVfclA5zV2T2wH4B6gNx+mPueK
hdzWTuqVg95Wy51fDLqgk8UTA69vQTx+zLWIbBQzRa9TdoDb5T5gVx1idY4Q
TacqzDp2gUS6lj+zDf/0EWmm7/D0KygOnwZDq7xBrNP9ct7aOpy4Mc8EMR7x
vP65Km/zidb/WYsW8/U9/dteDTwDnzjLKplw6ygy4F1cwvK+Qp31plgq7rOh
XKn5YBmHrdxoC0KWjqePwQkFMSOY2x4USgvLoJYzTXAn6cMtj5snftedL3In
SbGmek1Izhy6sABYeGSNIjZs45fU4zaJ+U/zxRv3Vq1a0A5I9FN8yKrPx83l
EHiPigQoJsUeujOGDzr4d8msdbzTMcxtJxdtw/r98Oq0ewDy73kgl4p/rbya
oakII414OSlpL3vCQn1SO+n3YTJOQEPnavBqrIwszQxzXzEssDJgJiMevkvK
2PYKmF48n1oik+I/IggyAfqVW0xDPxCR0l3LJVs9Xl+8zlo77/YHAoKIah7P
M57iRTkDujawh9rMCpt5sLdJM7hXGp6H54t4Ap2jFVV3guKmTuOaIeRiJRBq
JH+4c5ZPcFJo9CLVChvC23nkhPYrrBCXZc8nwAFtnR0Rp1GaeL2kgQ8R7Eig
h7GtlYLKYAmocozbR3c2JZy5ftwZYr6JiDK4LOmaOaBoFdOS/d9owCSA4qQp
gGm0wR4n3NMDXsz45iTFHEmC+/UqvtGtCM+atyKzW9HJVjP0Ri+KCcYZodeU
ESbciYZdXMyhqFjbs31FbM59fGHOzJkWM1gh1LsEp8yALI4JDg682/n0orxa
OcUIN/EcQC6aLRzWqoGOf4nmyn1Vz9eT1xT28Dsknt9R/2iHBhnLHSciKqIz
LrGRiSnsIZjYlJs61otXypi2gD6k9qCCpevmdd+R1eH50dkZXLO4fe7EtqHF
R3OFya0K8229coo76KdQUWwGOU0csoHCXcuf/lQuJMSN8mdtv9xcMA1lTIkd
o/bgnSOsQwaXZslBsPPVYqRSYiifS3AqIRGVDLp9IUb7aeIzeDlN7gwGaCUV
mXOZ5CNcg5P8B4A1AgoCeQrwKwyjQIvzCM+wttcI/s+wKZ6Ix2jsS8Ts2bMY
Lhtz2yKbQgq9LAbCrggQCj7G24GWjiUkrjagZ9PUGmA8YARcjQbp9Co9atBC
T27PBss47Fk4eqAM4b16UQorwBkTd2Bdx52D3f0BwsKxtWch7/3926OXf/r7
t09O/yRnfYwhth6SZVY4cWfxpktoCMrW4S0mUYRy0RrMAbdnN5D9SFJ+iU3C
mQipKoixFYavgcWA5kjFeAihyfDOpYbKdEJi9OoJbmNQ8ncSEijq8b58KqHg
ydW2RGwVThWGE89lBdlclV/BFemI3MnxBR52bQ0OH1dqA8THpql7sx4AySyj
Diuv/ELOJmT1BDHdaCqoihFGlvMiV6vFAmRaNCbrtNhCzRJVGJw4FX3T3bEL
pGEyaZF8Cbb+Y2L1S4ztK2fXjF1pLGIpIJuaPyB1N0q1uNt5OfbAtgB1A4WO
4TTOBNZzxlxY0osZCynqtaTykFS/iiPKhA2KoIAhf1Xy+ARacYkykylSwFdI
0x1vCckjuWF66c67nb6Cp8dVwttkN3W8teKbn2UD1QCdyMbxkG9LMIqImbXx
/YvX6BXh5dXX3AEhtks7Xkxvlnd6Ucl62LBJ5GaUSe4PlU9Id+3gG/ZbBKDz
36Gh290kWId5ZEjjbUnVt7QaJZmpYYzVXbV0dDktljkuMqxudFDhVhvfluyd
hN/ZzZrfVGJcWjhZwfGicFPfv39x+BMlrWzgw0ppEYEDK0Ir/ILeq1TX/42u
q4YDToIdgNpv5LlKTOpz3FZfZRh64Ro6FZL++ej5s/PnT06y1nEQe+ta6BZ3
RYXgx6zcJkbxu8qfDrovCLrKFB6uuEssvaSR6fwjfvhaBvGaHVjBoaNmHeH6
1zrW8UJeWBKuiKzd5boNHd3BkYJJYPrJNsPnEf2b6i62rDmaYGfiDqsgRB8u
Zn+I/ZXkLjR3oUzlRhfvTrkkqW3kLj6M6+xAHbZrd76IXeMNwxzbGD5Y6lwC
xEH1hqx2fPjoyMmJcdLzZH431erm/tglGGzljwiVpaDrCc0mKGVBdHoBQ7me
z3ygyZ2BfwOkATxs7k6BexwFKDe6EYhuvpo37tGyKiaXYgQYzW+LhRyCuyit
yiRAQdvuExjjy5Oj50+fnjw7Pjn2MTJiRGYxV6RmtMxN7rr+tKWDOhzRv1oA
yF3N7jEAOl/CM6Zves/LkisCT5vcCSd9U9xRYhVfhTBNEvcmBLG0oHKQph1f
x8lbSdyWzxdjFR5+p1byEat97vojC5Dr8HoO2j3JUThYJ2Qur8FNt6Q4YMh/
ySdzgX6Zs83lMqqDHDIhLKiBhxHHal4XFAW6GS+zcDKozJLiiVoYosPXBdPw
o7CoABgIWOqdr5Y3K4EDlFpIOM98Vl0WCz7Pc/aL0VSJ5O6kVWP5mhPtljNo
lA0moCiRAsqbRzclEcYPILo5UqiRxi6Qxqoco0lM3qobqlj8QYVA7F/AtKUQ
g8qMXmtEC67TXiaAbYuRQXMtv05bXSvoXaoQj1U06ZY4GEBoCTYE7XahNUXo
Y8CeGYwAxBTGweCKNBxj1bNlvFhZZm2U46c99gZqAEH1G14Us46HS9eTG0BR
X06saA37183lpdBsGjXgj2BOuWDWth5uR4/ZB5YzJ8gh4a7IhskP536V4zdL
NGISyCalI0/2ALpt7W09EVDW+JO8YdRsheBq617FAHv1/C34s1vbwCe7pPBs
c+kRW9OVXnt7PcdbBIU9au4Oy3ecUKXFHBkQsuH1Q2Hg6TsBDcVggoiqzauY
ygA6YbJRr9HlGZd0HyuMpxXtJPem01RhW2DXNW+kmKHaFhRY4MAJd4VO7iRQ
IY9K2Xvxdm52Nx44KJScQAXgOXDTzjPBt4E9QngovpXT64miTbRwxHRv8n+u
fPQil4yviX6wyFiHwu02g+a7Qw0r2LvnHExzwE5HKCvEoubQUj1OALyjoXsn
UA1AfwgYVm5+51NOucpgkieOwD+nvBb+W2YGrX4nG6AFZ0/Ulvq7AhRk8b7o
/ozRzfw3Ee5xhOyzxKM+weGhkdpp75TJRpVS/GIk4UGjVT7XXl8hszAwocqz
utokaZ8GLRQRP1OtRTigXwP4Z+J/+PNW1nfvn01BDk239f79Kl92S3jj48et
/s5Ot98H/M4XVEvkjyfvwJiCtDaBGabUGDGX431J9gLtAYkDt0pgwTTiBuSV
qxkVxgIlAjajeaiO0+tAaePid32npQexJlWYDo17vYNpi6spIjsrRKYyHJTy
2zRUf4ES4+zd1yuWzqg0jAb7Y7K33v+6392+aep9x3dj2KA30q1miPBNfB7T
Yb2NtiBliVOPS5bSxRjWEb9BoFnloxFWmwq8JN5Ak7P1yCQXSmn7V/Fk5P6v
Iis72zPYDcfKW/BlgCgsaf58GkVUlGTJ1DK6LvsBJopGKjTui/WdItlK+/2w
aYJ0W4GDtY8OVsoa2+n3UlwhphcBiDTsAFs3MoyU0PPMwMMGp87+Vr92kJmz
gavUY6M3zghuC7jrWCTTIg9eXNf1Xbsh8YdBck0/cBP+24uTPzshC0fBbwPc
nWNAmYQJACOqZchLjSPUYw1rWkmIDYimMuKG6YYXX3/ge9D4DKj/JdqSGPgr
subtbLTNJ7IUpzS55HZ3ZcHYTBSzf20k3Hfa9g+69bCW8h90e0EtkQW5cqX/
1vv3/3Z6dgqGqHuY/AqYfLyStH7B5e999/SQ1HSsLbJsJhF6Fy8Etw0w5I5t
w7MZZoHrJwVTandsRjZ6HYy5Cr/HxqtMliBpbATLGCCDgwAH8A9T8JmgfRXG
yjhMOEjEPQbrV6A/0DMy9oh3fzXLw1jY3FpA1rEvN/Ly0vuEE2dL+XJwlY7X
x5E3Fpmp6VYHFFwO9TvDaF+um3xy9uJ4WwG5lRxSccRhtUCSvO4JKEcrv9yE
YVA5TJ/cEj7bnC1tkW1XYrs9JpKN5IriREqFjhfJwUc0GE4iRWcorkHwODVG
Qo0yHgWha/CGfFhUT1l6PxGx8hkx+rjKdWdY4EVlcdjAYZsQf3J1F3DAymqK
rlS1BXmogOHBAYYKYClPrAWAVTR88cJKuzYxYNY55bZCpj74tKnPbHmMMJYT
lY2oqA/XxAaFA3eApQmI7KeRsx+87sRblG5VoC60Y1rFDBSr+6Z0X4B6LWlP
QvgxSLxYvi0KdahJBbktKMANYYIRn8Cjp/jM6velq6MwZWK02AG4hy4m4OAR
lB5ZWTkjInL4OvSePD+XlzCPfv+ViDMQeiEc5dDczZ9ZEWttaFeE40zF/EgM
QXf/SSJqms2GCmU24cKPwYGTgNQbgWOA2ObGoPq1UewqV/zmYez31ho7m4kv
6lcJbv/MMHFUv36reHDNXKT5oY00wMPj+eI00hNtCAIPtbqgTYw454DIpnjz
cqZiqoSe9+LbTQNjEcW086kx7R0TXE41TOOIcayWB/agILC8XGQDvIaABjUc
JAocFzw8mg0VzDEDAcVtcMC48QsfC8+VAU2xy0BIcO/VgU5mOGRkvIrxp4U8
w5D4/t6SQk36+1ovBSG2buBegyjp3tYPMy2lZULvNsm7a0GpX6qETvTQULMz
wOI24eHkn5DAJbeB8MyGZGu4BRRb7aWCpt0CEfhNEDFNTq3oCIvn8n92HPUr
rHY8A8lfqd5XKWCstXfHuwy31h/irtuC1tiR1HHrmQKRtRra4kQNyh6j3FIL
bDfSlUCtSW1NuF242xCKTf0wMYl7eCzEgvomdNqQkhoMOMZpXy6cuAH/iFcK
VqaDy0KjG+xERikrJRKG/ax58bJWjkkQyEIae2pHqoBxL4at+ZTn+CCwBOen
ZcrNkZFWkpis4HtcsHSaHeHd8vT4qI2RVMh0fQHjePdxD7yIBYsh0iguT7za
dusMcP+GG0FaRfHOtoh81++NSS0M98jW7gKeFJSYw71D94fGHSbahmxZfxgO
s6lTA/LlSC8qak2jKGtxDqrKkc7Bip8IOUtObqFwJoiSYyXRKcjTHsq6l26F
wNviPbCOg80llHHJbm23b3/KsuzZ82fdZ89fPj18dfbjSXby04snh8/c358/
2/oTPn+1CQ1kFNrUkU1S7RWb8EqN0Yvml0ZylaOSvgGwkfuEWPQxQkx4x0av
ugnLEMiXNTOatR+MOIcx6tyJEHNK6nWHAL9WB1YnuyMZYw4FIeiVCzjVcLK8
CNTjtTtjHyk6LdXIEb5LfY9zMufMjfAA9IPN8P28WKy4IG/u9C5cAL77CRUh
ygFSd0wPGzlUrY4jrOXOXBTTuVY0JqsliXkw0G4RbAK23JEoCfedu0HRPKNl
HotelrUi+LujR0ckizrKxmZyAT8zK8OmABhUbUTuL77eKY4Bm4l7bhuSnV/c
lqB5siuRSRBduUb3DTFMaN1KGiNG+ly5wWGgEQTilUs3Ny3SOcUwnGIO/koO
5YXQPyG4a6ezLlf+Y9KOKNfPTfxKct8Q+gUrbNrajER1TrDyt7bG3WbZ+erS
nUaUkiFIMOf6K2ZE+L1GtJMMsCwxnA2ENlDIZ2XuPbgXGNwPdz0VZaQl0JMi
9CyiPIdGFAzQQz5Sss7dFiQmKmfCM7LI32IDkaUBDtMN24yDISlrdcyFeUsP
AvexEfhNAjmEotnh/fTwqAfHrqJgjrfkgvcq6AUxJHHM9PSIukbmV0Av6MOR
y1Dmfeyk15INWJf5SIJJ+HQvionk/2ESxVK5IdnllAEVPgRLDAtYq3cxGZuR
ZAWe7pKgmNFswjRVAeWBX8mWWsUlr1YLNy7QscsZEYZeIswIsQOmTDBPLTHU
hMd7NQdlKR9PywX482TaR46AEAMCMxkFbECmLXOVjU5Mml9hr+C0MHJpILe1
qjZ8VkwhdK6itQDvJjZCZlmswQ3utUDeo9g4rYHUvVwUFEYMmUMYV8gcPPUZ
GDkgeA6zyHI4m1dwsE+dRP+mY+J4K8cQiYVO4NTlWUsZQxtg0CkuXm5v3BR3
Jp3Ss332O0BXRmsobyAgQrmpTJAY7uarjoTVP5pfbHd4bS8dY3QsoWS00Oty
KhSgNjhOfDWdzvjj5ZwL7YL/eHlNlhUw+BfKxZGvug4TrNrdC+6BmbyTdqar
GTFLGT5fSu6I4ooQ55ZCmVHlXbC/w1Hz8gMcfHiZbwLwFuaUNDfhMYhcTjvi
FpLoBRHbUczB94hLQyTaCLPzplEiwZ3eB9Ec2c07K3KIWSmwuCuZxjU0ZnUh
1Ay/EzvliC0Pay2nOOBRZ0D9i3GX3DQVC5BgA15WdUrscWYUex9A4KizJsvp
iAqu50CIwKowwWDsxHU35TFFr40W86rq8r+ZU7zFeCGBt2eZhtPPc2VYQA+H
tjX82hcTh+HRT7r+TrCcIOPRmnpWqLdBsu74JIZGpESFqqkpXjG2VNO+SP1J
WLuO3GH46cuzFydPj7vuhbA32Xq9rt3OrW4wbUYSxSC5E64Eg6ECO6mMU6ZG
gg9Z/LF4tLnEAlzr8JoOrb+DL2f9hZKSdevvZ3Twi6y/g178bsKsWXsnKr4t
nAGVkai169WMDFmcVVYulnfdMOSjyidLztzCv9twFSf3lIyaLEwS3TxGk6IU
I7dWPkS5RaaVo/MXL5/9mdxdX9jEjbZEDMrFtWDbNuYEAiQgUPcUa8UlKphL
fIf9Eg3A4vILbEaiDeDKKKS5XxrA18ZTFa/Ps66Um6TARGB0aCsW69gtmoyl
yPlTiU6A760JNIVuj+3LB7M5CCv2k5A+eltPsz+417ta/5LSUxcYj0+2je+h
1IBPD9w72H+oJu5JcbnsTueOvz31n8ucUqN7IzWIKYER2o97X7skvS0cTgAT
QzWYwXDphrc/2B1i9mIVuQ07NZOfe0VM9I+LOxiKh2E/e/yU68fT5lb4Xx/u
/8KHy6FzYRbn86gPHGtjZw/wy30IzOjQVPe6OxDbuiC2FwYKuq5jL27i7Hfi
ww4/4f2kJ5tN9rial+ZmZbKGpfQquiJaIZkV8DLLcuT0MzgYYcf316YfQUle
YQbA9u9IDdDyChhDf4mivuumdB/+rjIxrgVpomQ2u4AmvN3Na5d2czVUd0b3
Hu4v2/O9Nxw39w5SNxSuHFLjSwhlNYdWDMI0hS73g+UQ3UDEKny1Ksc5Yo0S
EKRJXKvCFdDVoRvtspBEEHfbDEKvqQ1dtXGvuMca1s2R7NYWTC4PpIRSAl+B
Irz7yS9hjWBWBtsNg3T9V1j8gOknShiPi4iHqDBmQNZ+Z7LarbVeU38nxS2Y
IOvMWhM50ThYbxh9bVReNdOodz9T6ynE14n352whEdyua7DqLb5h0X8Goo77
Dq1YUTb+CiyoiVGSS0kn3/Fs2Pr7oXW6tRLsxQQaRWzmfwh3iQIaIjcaGtSi
kIcQ+QebJKI7OfyJWcx5F7xr4oMzvV5y/YSBsTUHhOft1QMMd6Q/H1DoY0e8
LBAdd6i+ABQOaltURyYzdbBy/ighSIQQS0G+LPsFsPkSDeyjItz9eK2Mxxhc
K+xMBTsGoBAkqp8zcDKBmKh/ZQ4hc94mZrgFLZfxelOaIPnUxmqNpgDphdOs
cm8aJRs82fRjygjTZ2TzmHWtEpUngKpXE6f/Y+zH0cOH6IckKWgkQk3cDdds
yOjBz/jgu6y1crPbHfy8bGf97Ntvs9bISTr7ydxWFFedWggpJXHjlRHJuR7G
DtAA4H7dD7apScgRBZvqSGiqZA7V34fK3E/LR7xGEgxGYhwwKBVMQ5p/O6dK
wL2tJ67hZwJMYQU/bCOW2mLZizwLCbkrIRNyDCuSIDYWN8SXz2xcvAMeEdOn
uBrhcYIbuM2GwAjW8oArPIVpv/8qL/IxBlp0i/wdhw/DY1yawxB/OtYZbfYe
ktgJpHT3fCP+vMOFjYGhK3X6E8EzRYRwcoxYThsFcQGKiweOw94Wtl1jE7RW
8bs44edHj+oTno8ueMLw+LMmDBUSBnu7Omlo6ItNei+cCLb9KZP+89HT+qSv
RlOeNDz+rEmfvzjY2enuHhzrtKGpLzbtQTgVbHvzabvLfoziZxzYOkBYsht6
GmYLyidxMKIJleDLGtxnVjG9BN+T4o8s8ktEcXJXzZ3jJqLm8e9d+R0UKmQF
aglBEVWRzvmzuv2EYWRecTYruj4oaIxrtWp/+rzrS0BzOOyngb2d+fzOyvpn
A0xbMOHmHB8jMU4Xl6uKt8vC+6K0vZhfQDovqilvxUW9EITh+j2g2zOWqpwm
BpiSfTUHEE1yAdAyGYmWoavwdr9pGdW3apOGIfU89L2BmjcrJputueu/8sK1
SZCCaahLCMgQogNZU1K0jV9uMuNBrmZQpO/GrWET8IaW3uLodQEhuAlOSOWT
P4tJVUTFJGhDuJ4WBONTgcJFcVsqnlzIYEA7EIw4AfmDHGvS9Qh7YkxAaFsv
5m5p70ztC3JOCgmGENsbnNHSujGbXJiOsWSP8qpwd/KRxzpz7OQCfwTDZiXw
ZmwzkxBqchXz2vyOHMAL0p8Zo0mTumkLYLrzC8ALr8hvxQQO5LJwEsECjG2a
rgKoUhCHTQZx79rEiGJphhymJThGcKXYeY92ZNS3PCgfproALU/YyS2qqEy6
kxXLETAGgAUvZ46xT9BGcYf/pERKtdZUo+tiyi6mKYPfhM41klRWM8AK1zNF
9vWKvMYd7yOk3xELgrJB6FtdUMZaBBuhQACEBVcU8wL1AAnP5xsozjM28jaY
CpCy1swRMg4rhMQB7xXaUAWU6f17zl3o5tWoLLs5WHb08tSWSqr+MEeUCCOG
fg3ptER9+q7EFnh0SQqFdzcvMxTjFIZe4gboqq+yqNKl1J8ZZlR7ZrgP9Z+I
0EhpRxZScEWNCfqM5ghZTenxIHg/2PcUVaGyLtXssGgcbhUOp2P5RooVSWbp
ZAIuIXDpuZNNaaPKOX0o2PuvZPLd0WI0GPL1XlsROleDIVqTj+5GwPlfFmOA
oJ053nKEoY2to5dH7RBUDSGVzMwAnDhaVkk8Bm/+07OnJ/IC3Q+CidGRaG2B
9KHgXAy8aH3H1mDXv5DEisF/vJLHLgDHK3beHewPIUSH9z9SONwYd949erAz
PDqhZp1mtgKt0MaNipO7HtIczF82zXWsWBj8pX+PLBaHsARYWzTcVWGtgSUA
KY/e542Ds3F2KZVG2bgku4dCJKhGUqbRrB4pn45A84UMbQZKOQLh+VBFu206
5nUaKFdwMORKzJXklyVt12DoSGS+pERDHfu0xNoOEIEzoQI2mOA+Lt0tvygK
E7uqW01t4dnFYyOpT4SOeQjso1PvNIRFUSeRopPGjIkXMgJT4FgpZNL1Pugq
ERSSkvC1HXtezJibBW/boqfeaUVZcixLa8odXUSMjgowQnSSouWmSAgFX5VQ
RFDfV9MEsB/ZIap4wzkATWIA7KAxwRqiSqSSMC468Wz3pRe6RE6ThBypjYWD
Qg8/yUWxDdpbNTiCPY/6T3VrK2/F1ah4z1Dl0lgEJ+DW3/usrpvk5HjeIleD
v+CzOhJAHbbF8DWH06JmN5nAy5yYffH11gsQOSFGyiIZh5InoZwrGcVnWG4O
BcIhaB4I0yKwXdd6j0QhQGsEYQWjMy6Lt7VztdmR6m0dIRMQPk9vul1dLSoG
3hM4xtG8IqCZScH6FQqV7iIucnAFXq4m9axMCUpfIJPv2PKybJN3IrVjTSN3
1TniHrMpwe3VWYKR4/i6OMBs+2gbEkctF49hNkYMX/x2AYhNs8ybJSmzmvBz
4a0uhMN9t21b6422P27913/9F27BH991R9VitPUVGSZomX4+e3b2Sm+7J9HD
P588O3l5+Or5S70xn2xtgQ0fqtNqVBQGpmN/32zhf+AfP5O43dK3QAbIfi9C
ONgFf0YIk/bWezSe6pfZd2Zo3+AzqHBf0l9p71ruw263nb3XyrPw4b9/l7W4
hz/8oQ0m1/7+N/oGKAmt0rW+801WZt9mB+4/8JpvQ9r59tvvsv43wc+O/7bg
0b+g2R7/F38pX/+L6+GnU/zfN9kff58dYRkhEJsGez6eB7TjS8Dl/P0fk638
+3fxHoQD+rgV/o3+5NpFMlIaxZNvtpAKUAI8rV+LhDRYk7VZ/DRVgRA9mhFN
3USCmxUMFqulR1Hj3GywOWFtwQYJAlVe6QKuN0jOlvg3Fa8AFHPRswh8iXx0
sJzRkHD8NiIYis0FoPLaDGKukZ0BMWTfAlt7U5LJw2Qc2Sz7oBOTzKL5N5KY
DnmpTvcFX8XMwxr5s016ItrpK7uaeotiF99TkvsTdyw7cXVw4q+ccw/N4Zfm
s4riTi4m+cyJ5waTu0MVxTRDgiD2QF9AdaGN0p/gCNGdc8h3jvZjFCfq80jE
zZZhh26LOdM80DM+KkoRffsqLyeScUY4iRpHWlsHZrD1n1OLVvPN2TUU6BXE
L4B7SkCISba6RBDWvbabMwZLtl53X4MPb3CM5khO+4QI7HDnfYMBnpPvBtQE
SOab4aEYZ6sbnqvdTDWrhRJcOZNDB+oL2HPK+lu9re+jPqsIhlqokAueJlGa
6otpoDnwBHRpal3oxiByBB9+QCwkheEAJI7Xj07+fPYsQ0CCk/Pzwz+fvKbX
KA+U7gxTmqsTFcBjAEHTzIsfHj05O8oen/yf7NGT50ePg/ZwqGiM01q00dcv
z36Espb3fc6AKrXvz8/+/Ozw1Q8vw2lAAvvoGkO2BRJc7Vp/RFXXPkBrOVwW
RIj6JAAZB7WeLFW1vWG/11wInqRLWDSozIeEUKPGiqNfSbIhYOYlAMmxdIcw
TTMWK3P8pOMD7ECqpFJwqIB4DdczEosYBoDdc5OzSSOqneWKZKDgJ66MU5IF
gUk244piM/RceyYuBbIUJrbh1kAroEXpDKoDo90Fw10kdFSrDKaHlwcQfDkd
UcpZsA+4FT69qAbU8dkZsNVAyWMsTy3tVGHZBHsojzhgKZoObB/EC5HPF5YS
LA6juZPeHFv7+rXjaruHbUaiY8gp2sGW43dO2uF4rELjAOFV9qM238xgp9Yk
FfdMYAS1Uky0kCTZcyKUEZoDYQM0C9bc0YJNCRUA4YyAn4h6CxnIFK2FWpBP
TKxKqtsk/puOWIEaZsAdwV1ZzlaBiT/cCH9IkbDQfIW40hTBRESicMYZmwLZ
+5MIWDl/+uoFksTc7RIrXNJmxQCm6gC7ZqQxbZDSrmD5Hj48sBY4dmyI1XLQ
6/f6bLnc2wVE07aCTyJrMOlt8FpoqBQZhEU7whJ5/55t/JTCzW3M5twIU7DP
7A8owGlzuE66X0u3wwYRv37uMEJKgCshl2O1uMUFlsVy8t4sBThJ6LCQmRCf
GtDVERwOzHGIGU+GH4Niw+EYElklnhs3SzAO4kaANnyL1M6u1qMawlPcK3MS
Ce3a4FaGoTZdyhQfKHcyvPkhO+fY4wgdzd/N9m/uoubo9tcIjRjWKzCcEyDV
al2zDeHjx63XUMDEfQitHKpHBm+N5Jcjeh2+/N5JXvDZ90EsbaV+dzxrt8Po
5vTJOlW6BwjNxYE5Wq4KHNhR4NFJj4veBsy4r+Da2ubV2Q735H19G2QtiF+T
8sD3MPBSv8y+uJY15cUmupkH9IvAG8OLap45va4E+A4tSdCIBRtWjhIOT2jF
CwB3mFNtDrpBCgLAJTHnYnV1ReIVQncIQv87CD8tl3Qrwy2gSRNu6Zgk7l86
IYampVPaAhx/TAnLsceuHDJuwKt9kriDwhQCR5O3j+u70cU4VT/rBeF0EtC0
hNBp1gksONVJvpmXlMKq8mIpRYcxMRly+2bgQOkCsc5YFw0z8EqW2bBzYOqG
2So2t5NSUOeArn8479LduED3HgFi46jucPBoXMPkesySrPNG3g44X/fvBR4b
xjjzAIEe4IPuZjyTCKRdozXAIRxRXuXMH1HvpDnSY+xNsacQMw51feBq0XPe
VeEIryw0VqgDIU0pxEs0VoUWOu+KZDNGOFtYwusGZkMhbSqTzWdemuP74QqS
IcESh0VwArSibSyD9Mw92wa5azVlax501vWdeY79ESXNSs0JDSDu5KpQgOAm
Rmjn7filB2wmeMeK4s8xx4t0Up5M6zX8Nhg6xfc1JTrw33YP4De3xPCPvf7g
NdVZuW8YWrjKUaaCc+dSX76B4VkPC2ckCygpJUhxmKkt1YIqipPiSQOeA98q
qeKWlawJR2pqAki4yrdbLrzf3DlkwmFS8uWm8ugJ6SO6zJKbaRSjjUlOKBp9
RelxWIdZvm4N2CNscOfd2CHIY2GxmcIBKHiF0n0xvSgw2MbWjWBWTtfiBqyc
789GVi63saFVuhADZSCKvRDRMAi8d6NmSfdfAav/4YMDZBMvAOYcta2oapfc
Cen7oOblxAzDKwQyxuznykmLDGHOkSCUlDsn+D/KI+PW7NXBZQKmVDSBYrGr
TFDiSU7lPOEqL8dERYRbdDip5rYNTuNdMlAT1mpAAHtU0Z1giqUu4cKmm8xk
Rd6R2OmmdO2o584HDNt1xozas/Pn2ROYXXePisb9W36Tz4BJBS+jhwfDP3RS
qawcsNuCiLzQ2wxH5vYid+tp3ff+vsFsmDQkaZTVIiIMrK0J0KnIlUqg/t80
jErPDLVQVatp4eWFspK9NNYLsGCyHTI0a5LlzIaqWOSqKQTwLARVJWHzZUkL
PyDks200PG0Tsgcn50oUBb9x8uwY6+fec6G+/yp1n0o9GIyMkrg2E+JGNau0
KJmiskHMlfiHjZVc8YnoDcJH4GC3Qq4HTZhZwslyL46xN84RBtVtPrEVJhYA
rkRNo5n1DPLQx+wbLNmKIRNGrRCj3HS6DC52qUvB6RVig2YFzO+TuxTLkVha
KKnL1PWQ7QtnHUUKNYQ0tbzloD4mqh/o65kg0g/K/gCHskUFE/t7+x8/erGW
U6pZ48Xd8texCl2ou85uy8V8RpFlZLvgYlhgnoSK0l/FJGTc+OcSDhbSkfz6
MSiatE4uqVU58C/zqX+N6mhocD05FuMxPnxN6BFsu0JTJTSXLOpKpb3IHG6T
2lgK4Ys2sDV0IoTrIPwXBOwuRarItdOgcrY77DuhjBwUTlqmSCRHiRk1jgUx
+vAV+sScwOgoK4eYMk/Q5Oox5Ss1hVKS7HRRgXy9YVYDJvS8fOKADNXbZhDy
I8D8Su0ims15AwPuhzlYIRNFpNfKMwVTkdkMHusUgiOlC0/QCpWnLOuMJzXi
onvigfGgaiN3kmYI829Kj9r6oAjgHeHOkUZot4Gjwz55AfDasObkYI9KKfGl
ZdesldlwVVgzFBX4HiRoNWOidz2TqbcSWy8mGecX+O+dh218Iw/DwWd3auQS
LCeeJwZcgNi7sEJp4/l3w3vkQX03O+gUmqaFzyBnxx8nzt4Hh2awnDcQNLVk
MMI8OLKJ837fMUbjilv11Yh2dlFWmP0J4vqq8t6EtwTgw4AT4tiy8noqfm5D
taXG1amscu7/jXZhPSnhekhEGievSPg4hYoeA5M5YSaDmuv7rzzjgXh4TrnT
IbBuEfk5sinkLSAyy0XIugBUMMnJJM3O3efktPdPOIIejRq4QOitMpnV367+
1P32j6s/BWi7IhtJ2JW+BCTk/pHBPzjn8AZu1xkXtbkBdWRBSXcCG68cU9Vy
0Ur8+AXdPylamjXQY9QR3d4+pEhhMgaNUKo7dQPZjsuDwMk1TrlU87YRJJyx
wiCGPD2InjXp2dHUyK+1jO8iOE0StsxCCoY5GKpJagHkdnRKnhVhX3ez1xz3
OB9RLNc9Pklewrf5AmNsXztGIeK/V04CZZz4X3O7dBTOnPRvY07vFamry26J
37gzco6R+CMpbNXMB93G3M4nt6CVLMopBumkmDWEHSj5dzYYDxUBhhsUgeQu
EQABQhy6uOJ4KbAgzwI6I81pZKQ7OGB+4BQaEyrnhyVJ5tZ/9cOMzDvH5eWl
yM3v3//w7Oz07OS4e3x2eupkVlX07+/ja/TzeamJmC2xBUY39m5vfENLG6NE
KAfdE0NH6YOYrbDq1LpTopGbo9x2b0lPES4q+gVlWWDPmy1bgFtxz14GAGRl
RcZdyuZBeApQ0QnZgrbeXXEUa6mFNHzFCODGJaSLgKZ9yfXvrldTDMLKVWTT
LueIGctCcMKhTaxD640GptLQ1uDEqt8tKQkFE0eMCV3RlCE2F9haOaOitbGH
TmQP1n7B4kx3A6vWVEvtcDbu2EXaaHUrU2aVPb3FWOqjIyUBkrHk2ITzJKyW
mRpPjQ0ZDfcglGBsFK2Tl6maazrDqleSSOKGaS676Nx6sZhlRhBHPbVDfPAo
MCJLYMPaZeltnUOikZtYsaCcoIoxLpvoW7OCfE1AyAXkE2KLzrg1YTyqULPs
EH5loDzXK5X08MtjCbLxY69/LJE43shB1RtOKIKLFqyKZsm+nzDimsXCpCrf
JvGruCNTG2nraHliwTNHdDTeOSzrnLXcUj7ArBp0CrUlowtYQ8lIrm/JErwZ
b/Bm4SLAAnar0i3JCke4bFiwQPG0LeYD3fQsj1ubs+jAsDLTsoJkEt8+q4nl
7I0PjW5USV4Fx4ZlXATqwfDPHPHNo01sEMXxvAWOITVAfHTjnmCtd7cB5ZVE
r4isbpIDFzIfsShptGcYnLD1VfayuMKSRCfvMBqN0xoX9Gu38L8ieBv/nvnf
BVhAjQ4XjkIccQJLUbeA46CvP7zGyqoILF0YfwLfz/Tr3OuI0g76ROgftb5u
ygJtsSONSwVB3PZCf9PIDtSuOpHMGb5SQczuWLIcD6kPxjXMl050vnFEX15g
1I9v5fXvwY/0B3Yh/etrFJfx9egtMzSbOLGjc9KlYLbn2mho7A9NjfU/o7F/
fV1bNPNRR8LQZgDLI15jbYlRZeu0gZe1O7zAjpz+je2S4Bguev1bNHOQFxiZ
FOIkuR9f917bdlCLxGvMCWgYMqA3BLz87/blaPxJSRl+ILh+egka+f82aIQN
CYnP8+z131+niyDWhhz0ky+DudAl1fQh3pYzqWzts0Qg4q2pTSRvWuIyJiGb
vulYqtj5X//tH3SMtUi5Oc8yOj8qxcOWphVkSvuypTPddqFEl2izPmOQabR9
W7Au7AtKRfi5iKtCeqcgNsumICRaXFUYi3VN5kXmH7Dz4uSsjamyBZ2mKO25
5xxIgeb81qXVK17/baf78B+vg/mOi1E5BaQiQOwlu4zeaVqQ/rX7KJpKh4IH
y6WxIhm6MvZRYWAFrHdjD7AO9Rbd6BkejFsmrwwXNoCbQ4ocVBJYUXFoXhgK
pK9pNALLWUHoIYkxmG/tq0QX766d9I1Rh1iwt9Hppf4z4NzqCoYm5lJyCxtA
5w3m/bDfw4J0Ub8c3q701lSL0n+J5wrQNlDAAg9t5UQkExkR1AZzQvSqsqW+
LBgggpr40lCHXgp//9XN6gJkB3gdVrweXmfy9cyHJsbOtFCrQayz+WDbYYDX
D9k5witHv3lhTn568fjk/DH/c13dYonWs/+/le1gcB9V6aSixi/PD7MWp2Fi
oSzXZdst8v86PXtx3j/Y/+74+Vmvv9Pb3xkc/PHZ2fmrHjzouSfdPbfqH7Kn
L85acMHAf4t29ve/vX+PwYVV/vHjP/j5mJ/f8H//yf9dtfmF6d9///sxYEdl
M2rCMd2wCXijsG/cvCmqN/zOVjbgqfBMus9BgH7/nidx/0A3GOezPx5uNpZd
Hgss5ScP5MusmBvrFuD5fMhOJlc5sMCWXRnY4JMnfz58evhERyQ9XfF/7/zI
CmrDj+5duB5XgHj3BgfDrbh7Mvt9dmd/Nwvl23ODfOAaOQYiPCZYdUP0emTa
iRWMVyYx7rFd0Xeycgt+sfLrNg7X7QDW7ej4e5MTYpjRh+w5wA3iGPA2gqtp
5U5UVzPc6HfSZF1vj49PXwC6aeU65HpswftctrYCaAhe8dH4WqmSS5TWeuH2
cRZNDf7D7tOGw/UwcB3NLIIlWNcPDJw3F4cO/+ZJuAV9SAvqdjm5ouHm1lf3
/OSoH8yWl8huLy7Sxls8sIwQBYkpRmPLaYkZovuib7+AywaMl2XR/b6YTMAy
1vrpYW84YPMERZfCW2cnr06755jSA60AnzoZu5V4Qu7klg+QbCfnrp4KBl3x
y0CUVIy6+G5XXuzSi4aWxm7uXXJfR+u1lqjWUyq3Q6d9E7KGTagPhXZjN9iN
w5Pj72GthvGv54fw8577+afB3h5S1a7im8kYYMrv8DH14N+Qo6C/rCN1aoxI
WptzvQNP/Wk4BBaxt5/sewgYL/8InkvPe/uf2jM15vp9gISzftrFuGHe+8P4
ddoNMy/keWOe2IN0635mD3zb/X5D4zx0LEU+z9ZUylZGsLV1FgdjYJCiyp6y
AK3Bg7ZmA9okuZ/k+V6bg1h8Uaa4bbZ22tZh+q3BAXm5f6J/7YNqh1JSv00J
QwRDroULjX+pDhYCMc9sLETAEPcVmlVqskprQL2GgkNrt53qLokEIkDQTgjo
oogMZky9/vv7zaNPA4uwOZMva2nSrQbe1v0Hn9ne2A+vrUPmUy4PcO/w76Bd
NDBlt2Q7bd52YL3u3/12fZtj7UUc3gZn3iZR1uHBKcjWhMPeREgYCoShWFct
U+S5jX4jNOjqwsGYg52hCiG4cF0zWKu3HFLpuSUqm8JiFT2CbldF6hU4zf2d
h1hnusq2H7/qnnnZqtqmFA5EqXLX68eP35DIE8NT0iWeBHH7yn1xlB0Bzye7
v6hJ779ytxLeBRWHAii4O103cM+JFXCxyNEtIeiHiHIt4WoYLz+mjzihkQDD
0IIVYfgW76A4kzW8cJuaimVac1ob5zilqneccVyC74CdWwnxhXVwbNRCWoIV
phPXLxTUW0p2cG8VEwZv03q0ycQuXWlcOti6H9Ckb3TPYjTqzstxd4WVqE3C
9fmzXj97Tog/Z1pzg6QNyLWDBCdt2te9vS7e6ROsp/WB+/yQnQIqvSMmN5fW
JUypvbVOB+2u0VHjtDL9l/1zq98b9A6GO04R3Rnu9XZ7/d4DRLj4kB3AH4PD
7GA/c+z66CTbPc52drOdfrbzgGEw3O3r9NbsBRaoYUG0Q9QO16Rr3DW4O+jt
9HaHFkjD3XPY+KPswLU2zNxF5uS36H/a+O7BsNb48MA2vndf47uNje+h+Bk2
vr+Pje/uwx+wPpCuSevyIXvIjTshClbD/d8g2znAZZGV+QCOgHJ2M59PXriV
WdR74LWJeuj3N+jhUdyDW55ED7xAcQ+7G/RwHPew1x8ketgfYg/7rtkhDn7v
oftzz50I08POPjY5hD+PD7Phg2znFP6OPbDQwQI7/+QleF0m6WJ3Z/DQ/Ye7
QLEn6uLhg2xvD/+Jf/Ihs72w/qlk4LpA5rddP3maMaQBBxXbGOFNi7KNRazh
ZHucdS3QzMAWUOQanbHIht/BVQtJ2hRutVT3LlthZ4bzwYVNGgo9DHE4fTpw
wCf1JWHCUseQxkWZz/qVTZoCh36HefQon+QLX9xwyUnHmbUVSyyBgWloGMSl
wVfvecmgA8n/NjejeAeWax6YT7srq+hyloSNGjQpoBXw0DV9KZ9ZZyuX/SaP
aP1aY6O163Mx1rQxqTMNWSfoyLzh+iLw8zEBga1KLMB7IjCLL1dgEm4dn7xs
i4zTdGlQ9MrqgvMSBXFfgLDMvzkahsv2vp0TQaL3TPSdWvNBAXZ2jBMdl+zO
xHwCXUiZV32cy/zKF8QhL2S9xeV1XEW+3hBFi9QimBQ7gxbKLZ1HrRRSN7dO
IPVsAy84aLq0tjtkGSeBw0SxztxtrntOhToxioNwJcmzTX4XnKiCCuHXvnQW
pLxPKAjHl0tIURetD/rfE6Sb+zlpHSpVAp6DqR+WIeSdsB81VqdllRhxT6Xq
IesXMwuScp98T56I23xRoj/kkrFhQGw2KI14djFhGTsBnxHVVrq3M9FsuCID
VNZhBUfA+rQtHyMZrQynBuFKdM/F8PKXUs386PpJm1K2tjBp4WQygby3EYtn
ab8ExPB4WALEFJ15ZuwtPnQuCVmJAJ8Mpy4xjdwpkiA/68mhqpYGqgNjickg
JOUghUSMbckpAaUWGSEapoJnjuUCuc1xxLA1lDvTWysK+4aDtYtE4rfumSyf
kYpp4fiefYE3hfpY8DfjjwETF1/6jT+r0ZrOW/oZMyL3cCsl+DaIyuuk53XP
tgKxF42oHwjDEKV/Mknpn1uBHLvp2ySY3vt2XdL8hE9EdPyET0QWvPeTkEGF
z70FDa5q2vfo15fxD+dbCVkutuH6AbWM3RS/6VI/WNWgPlqVh7gh7LfLwROE
Vwe2gGBOBEciUGsvT48OdnYHYBraqK3abHgdRHIBholylu3hwQMw/ZGJQEH2
6+5WXy6x2eOqn69xurp2xOka58lHrtf7HKbm7GToK33h6xAtstUsrCnm3gHi
Ojs+OXTzhv98BKxFMPG/WgA+zPHJOUhV592T45OOlvrYf/DxY9bN+vsHCP0I
d4YUsMGLv/9w0HbNgE386PD81V7WglJT/CoaFG4ghRoWetAfIlxelsGZfTSZ
v72EIuThB/19Eu8r8KI9evL8L6dn59/jSPcy6w3O9sN/gsX50M2AqowMDroy
2vfv/5f7vckx/PABtn0QfP1wIF+7Rw/tI8cP/CNUll69neMs4seu31d/eS6D
76PelE8LdxPmqTFC8uOD/i6+O6i/a0fU3609t8P6FAv2YG+34z4e4sFw58a6
MBThUytWc41If6Wc+Kp0zBrovGFMowedNUAQHOJoX0MkYe98ad9rVudyZhuY
yOFNtzRrBCM+Iqa6FByMjj8RGHyFhJ2W5bicqYE5XEG4W2MrPtYQAmww/ZdC
NQllRCO3QUH1NbO5XFac/Ok49ZiyMSTZFVqnszYc7gBTq4P3sskSh80oqCT7
NY+ZF1Zlx1xlRKSKfIEhdJQmhnOrlyvtCA6Dj/v0WbOXVFs3R5EXVNIVyErL
z7OOg6zK+IowuoCHj/yDNVy84XPDw+N2Po+RU4DLDzMPB0lBLn89e0Gb2H+4
1weOAAzhr0/OHumvO/ArsIFHfy1vBsAo/+ouyS/qvFqZYTHAz73nDcZIN3UN
bt6ReYWIBek2TE4+wBVSx0yXbjk+mxIQbCsgAQWpSe99/IHZ9EZ4m3rElALk
uL//uB+nVYDJJiYJSx0fDIUgQTw93uOt3x30Mepg2/20zWIW3eFUiVwjoXYa
I6F2ukN2cV/n/dGYmnNf93176ODWYuXQtf6DXqd/u3/6b4bhdXz/ZW3+eUDj
p5rsEl6xoyNzv0I//X2+jfFVEPzrr7pf4dXBkG9nfNWJ14lX3a/bZKuk25kG
MEi16n6VAfR5rXd5rLjcg51Bw3K7J35sXTOR/m6wBP2hNOsHG37rh/tJp/w+
CjfGI1K0X1oVsBIs6JOn54fdF4+Pzvvd2/7Pe1o1zWqv0yrHRAZw69jTEXVI
jpwP2ekKUVqqa1Y4trom9A8o3i2U+FH6u3vDh+4f8OPOu90dhC7GP+nvO0f4
5z7+eYBPDzuI9Q5/Dg/830+pdOmxKWa6Z/6k1oYdREffojMF49jt9Ydo8seI
Ch1C3wzhoRkCNjZ4hH8/wT93fYf9w4YOh1vm0FGv6GoY9Pqf2OlgGHe602/s
VE/eB8DQ3KcVd7QM/Q+jzndt58emcxzI/k686NTt/p4ZzvD+QQ12tvSMNwxq
YAY1/LKDGqQHtcuD2kMWkBzUrhnU3pcd1G56UEMe1GDQuFJDSzvHX3RQwwaa
OtpSDtkwqINfj6YO1tHU7rrtQ4b6K+1f3rh/9wlicjw3kL/00FCQDxHrfbJT
JDclzMgmXIiL8apaQmZ/W96ELwxinZppTtBPbIwfaZWTwHgOJaCvIOYIU+Yk
9UKRONnn8XQ+9t6qYy2ofATZGK2nx0dta5Tvf27VxHXGdFWDDIAiTtRdWh2a
OOpOnpmvaQyWq/E7tFPTHXm5mnFxc6wrhDZfrBx8/zClABBJ05/R2fng8T19
iRaci8Htl/aVBcUv9zG5FItntHk6awYT4IwAdvrMQuWw+qt1GT5h08w5CPqY
T8af04GU5goSr39XMcTCHGFVC9bxHYkRBvjbIn8zg6/iZBHG/BInYhQWRl43
0rM1vybAVkFUF00sGsFMRqtqOR9rFjbmxvoMd0CTJiUrLCRcSclhk++SBH+O
vrLYz+HnsabFipXCPsNPWEGYvaMtMnCDSTpRTz56yShisQ5GSSgYpHH4U/ZB
alyjBM9iPNwlUJv5g60HDc/2+AUQCaCK8YewdjI8HdArX1Jpd0O5j927KXSo
ZjP4mGu8f+srKZ58Lk7WIwT7Qy8/FlFGe524YLsj/9Rts2yu1orFJPaqmDrl
nvG35EuKIROku/hiQTqeax1eLlTxbE6FIzSNLapDRh2aDH4sRQGgz6Nlb11O
2gJjCuC+gaIJMnqP3c7oDOEEyJPMoJXL60Xh3YFmRO70cHsECtdYwHltIWE5
2OUiw5RMN6sVRujmC0AJto16A229UW94RVNrV4Mgn2oB6hRAAbxZhyfAl5OA
BO0t8sCqo57QmzyQ9tUiB0cqLA7iSknN3rsbapWpDP9tzMdtjILhEo/ljL+d
IADJq2sppMb16GaOwRLTdBuN6A7cDSfU0jPw/65mGuDIA6HihvJZsVhgaaiZ
pPezpxw4y8IEu7ARnAcvnzshA4OHnxNzpTMHqaUdHSDC9IaDrOxUteSy1IWG
7FjNdWW4J66ybYrbjgU5UQoSF2hUlg4UDk9qM0hFuWn+hozKcp2NigVW3JMv
BXcFZgEHm/AjJ3dJ8A8IKN8W0KliWys0k+8dAfqUO5WMqMBSH+wjs6Mjv5qM
Rp5DWquMHyaHjGRZUGEZLguJpbAKXHItInyDwbQQrlu89Xvgy0Z7O/eMth5L
UipQYhCBHUdXJ+oMjkuqW4zotVwy82aZnlqHMVfoC6wGg3AQ2dWqHGNK95yp
nipAIKBGOAPigRDegwwCxvvKV8aJ7a8QQYOeh+bxw/5xCdR19EqnigJNGg5e
JZhapvJgmHteuz9GI4zmw2h2gxBB3Ja5SBqRV8TBckbVW+PBUFgQlqkikW1e
EBBhPqYYuDmHIWIfMnJfbPRXHTivd5Cwzqg4TJIEKKbbXKUnWM5skTCcbDCy
cIZOlmu6nvzVTnDMQBR6OQfFqNbcssqY8FL0H6HcCY1RUZWGWtpBdZ6mwqQY
7VPNmbnTraPArY6Lke5IeEwqfIx9oCEsKvraLuZcaBij1colxg+aVGzZaLis
MI1anZvunxX/ote2rVSOqtLcrfrNNQfnSxAWh1rJeG/3syM/5ACk9na/a2bj
gWKqj4k6SqY98xEuldZn6W2duDuiJKms+ucqJzgXz1C0Qh7MCFzPNxW+TODq
WH9mWTLqIkQBO0kWy7M8Ric6/u9vL4tbhmb0QkSv1/uHloA8LkFSw420L2gD
P4AKAmH/iwz/erh0Y3a3SBGXnvybXzjo7d6O058F7/7DDuQcN1j/u2n7/Pqj
kkLXgndt82xe/8cWYJ5JiC2f14ql1Q4iqSwA/YjPuyNF+oGd6pG8pEJEBB/B
91mHU4okMhD92MDkJpddRjwa0/bA0xCSekmF2kUVvdFsFeD4J4hbRkeCI7Jd
FzdMH1oxGFyA8IBe7IWf4Rt0gUKxVcChAKbKTy94PQ2gf/B17bnpUefHmLta
EwGrSTD+WzheJ8s9AQh50EQ86Iok9hGoYdSsNBYWSdYph4UI7IE1lGV5AXKA
hT6zzEDqneY6ZNdMyCHhwzdgLSBsK8Cco9pQwAjpQFFCEEW5Uoi2jkNH+3Xj
SU8eCCRmFC0ACI8Ck5MUxTW25mANdDIa4Na59i1OnSUeAvL0Ngw8AhjiuZqt
qhzBxcNVHabZ6jrOSQbKiGN+Ep9TXvC3Bib3j/u5nOM3vzVH+o0Y0KEcVQ7V
RX1xk5Oe5ZdLku0FShIBSy3mqyUWmEFZaJA/Ch/uLkYFQYrU1PqofE6sVEq9
3UVU6CGTS1DJj17UZ70tWmNT5RGHaNs37A0+rM9yvFKB9OXJ//7h7OXJsa9j
YieYYIVJBjxsYsBDZcA1NjJsYiNNDKKZuVzcKQCv1FmIt0o08SVXjISN6mWv
GJ8Jb5gFh6nBPbVtBmC44TbAhlbLIies6v0s/Rob0kxd2fpQUliOzVz4Y8x1
dunEb8Jtdhu5DXjn/SZsxnAy4Sd/W89uEszlNzr9ZCtSquFlZKXhZYTDoalR
7mJAUufxk+Egehv6x3OFeVr8JlkXMcVW5h6+Z3MqftxNJY5v4ncBUwttZUX8
AQyxtvom+H40t2NORQGku7AsLR1JTcWYT6eYsYReN8rHxdi2KcZa+l9ZGahp
LYJDjcH/nA+TZAcWPMuULBH7kDEEqtiEGvTMQBkQOqi202YNEes8K5Zu0D1g
jkoBVYkKY/twKFZVPuyUfqYsfUxAY57LnBv/zmj/oAXXc6RQSLtjmRCB57p4
jzp6okDmmeI52LGKUg7v+Tlz92QSWf8hY0DIBwQ9iQeCLQYevk2IVVRPNfmh
wwfjeJbqrXHqr+DBgnVQj4TA8Em9JikOGjXOSHi+YCJuiL4NJnZcUOr2UnP2
sMLMalb+E+FaxqUb4Aqzi4rFN1mAgEe1DXHR6eRRaYl8hvc9VYV1vAcCAbmk
tKSNuU9ltJorT4WkMmvstnxAXOUCdmdFi3Dm4pUDnYZS1s0pcyt+XV5wZUlg
j9Op40GOMBUSFNYh4Cxyd/glD2BMfbaNmshw8+Pf0yU+StN/jSHKl+oShJJa
bi9q7CAGscWgNNxv4sR3bE+1tTMjjqw8+AwrGDv5tqN+TS7eXFRKJ/MMaAsL
D4Bh1V3ul+KUDGgVcROwPrZB/y0lYI3RuaGElfS+9Reyjyslih2KE20TRJ7c
lUjs1q1BtS/ZUJ7+BmZu8T/X7/2n7XCtrw02eis9M7uH+huzw8tFUWCq4xLK
jrwzABS8uDUMRcOfcVdpAeDRlGvElYiV72dJ1bTjaYn+o2MCRQHF/cAuCnCc
0dCx4k5ykuRCy6tqPiopl9So7uHukLwsH9MkOnS4Ja7FNQVmxiAHU6zbk45e
QljznZj1WIDgK5NqvZzfdCfFbTGxtE8uKGuPopsUebhW3oMLzQnmoIxIQudd
IDOYvOLwSjS3Fb0n5W74q9BzTj/i7UQl1a7mgJMHSKDlSKUZLa0ufSF/RvUD
DbmUKlL2ip5fM5xVJxYY4gHo3HkUbbklg21SycWeOeDx8VET/G/v4c2bVUzW
KNkW5DcLdwLkiOo+Ba9jNqDJGsUFJFBeEM3O5GKuLniKnKy6VumDckf9h+1o
5Ny/lIcK58FaKlKLtW8DtSDNR6uaW02qdluhz5FNwxpu8iZQG3tbLxMqoykv
QL4kODGMRZ/X9sLbf1DUwmGhms+2AKChOaTrop5Iu+KHXWW3Ze6+MOOAmful
plIJoSUvTQV4g6qJXMtuSJi09SpPCwDGL6spJTtcAnx0fgWlQwCfIIdCFm4T
8sldVap8y7935XcUc4Hypvm7crqa1nwlHV60hOxfct1cFDeXdtjRaEOUMCkP
YoKW3HVU3pRS39nXWZUNpx0zegM6UBlTv1qNwLAHqMrJMpiyhUGlxFHhBEr0
vTUJenw61ORJM0/pNqxYsMeyhfhS6OBtM9oA72HD8sCe18fQNbzIh4Awx7VQ
9caBza3gwqiAHXnH0IPoOajC3MFHRA01550JA1nrvOOIPXHeBTaJcJn9mwK3
gDIWml+a9kNrfuZLHhHuCAao0j+je9ZiUpU164PdVWiD/xm2gSqOAqabXgGK
LdEpVdnVGoEaoGAAtks+N03rgUgMepdIWAT86s3RiPiytupG6hxEmkusAM8p
GCSwbPibnytM51QBlEx/igVidol17dVy7naeY2WLd0vE+R576OuG2TfVBxtd
zyGGAxzg01Kc2cHw3V2OqAjYYVkjOKtkjBAYYyZWocahbBmbmwQ1BeU7TXkR
3Wi4w404KbTIZbADFThUycl3Tl53iiFrYV3srNVpW4gjBqABqdwEzJFsdgsy
HjRwkS+y1t8/tFWMqoIyLu2v/TmWwqVfd7e+NlHN8vPfP8QVTt0vRz6fz/z6
hFHfn2oRw8R72I35HSOlXwgfjJqgt+XH8FVAA8fH5hz74Z9z0iX8yrExMJMg
J3/d29yBRi7S6rhfXCv2QQf+BS9rWzhKfL0pYNzMIxjUpnHl9Knts2EP8e36
gIPnbuzPZ0X3hdNj4o3G1oKHJLe8YLk3oqCO21ar18cfgGCY6ODedmEGDUOE
wfOdOrnDW7U2/ERb8bDlNtZh/jamarC//jB7u3BvQu9+WxAtqHZywDC70tc/
pkbJuEgchdPRWDtbxAu48za3U4y34cs7BLexOeJRgTSMNj2mwHySmSScftBI
vTCJezIjSICi3nPGW2rczl7jGJozMzYZg+PX3W6X4nVLsNS5WwIz2eHXfP0Z
XjeNgMZk8JLrjeOPmaBtDQOP7muSnGruyvZkgfWligWVcBVvGiCioU5HJdEC
pCus5snRyKCgYNxOIggNC9373Oi4KQ61pBlcAOhGji1dwl897Uvr3D9GF0q4
LEqxgG6rmT4hQpnSbFBbPSkw+Hg9Bh6WDi+KuzmbMMwg13aAsCNcsQvmHy4M
yYe1EQSxdKJsI8gTl+7mqYmiw/KBhpU6gQl0uc8YbieVshHGAfoY6Rzk9wnX
+4XDEoU5HHpEviNTgsy1GAX2VzaOFdy0IDguJ4gWdwEAiqgiU1DQgtWCierl
hGvLBlgJ56Y6LTNwp6OWuJr5l2l4ml7wo8SbOjqr3YnANhW9RuLQuxKi+hFr
ZwPgslaqzhON1CsbBfY9LE1C8XsAXi7Beuf6c8U/RzXDAOD/7MUxvlGUN2P4
8Ca/m8zzMXJgXMmAK9H28jvey2Rw1s5PuD1uja0P6LfGbDroEZqZr66u6zXg
a65HaE8DFBm0qbxxPADLysE2FmwoUIdZGP9r/asgiPjAb44/Tyw388CAGwSY
034NaAWb3OrWuOyo5naXy8igsDykHdIRYZym2M6IZ2GOhFQYXAZ4JLQKQZWf
lJZZsWgpARNsPRMYSTv8HhfGdRy/zw80klhNeilElAyKJ0AImZ2NX3XTnqya
mC58DAqtC0Wi4LKgYJjFaQbovtEV4b243Q96bnGr2iS214Yg86apJBYTfQFL
ro3KpUdFlTdsRc000RTlRqL5msJVM4pi0+nuB1Rg41cG1CK4CpQRgjlZ4Yxu
5kvSxCZ3mBPn1BC8aBOzYeM5QfdPKXXlrh5Dr+ePds8OQ+dCQI7NG2ci5OPT
6D0QfC0nTx+WMxN0Qr29/RIyD264eNHgavMe6h1QQBUvuI7Pl3AEizCU1YWJ
bv8fgGznMWz/mdv9VwH/7W09x4VYgFUicI7IYTP5H8pKE/HgFu7+C0yr4vte
Z+d1/4xELTIpuXGnsR5rrceXncXL0PuN84WkV5Pu+KNnnzUplujqQ2be8dwj
0pkdfbVKFIXaTV9YhTx8XbfPInRgbmR4bX3Iuu7/HeUTcbcMDhWiA85r7yvx
ux9vh125cOHJrm/ldrd745+4ZpRrwEOaS9cJHV29jj+vZUezW3puTdPLt/Og
6X3T9H7Q9L5pej9uOnH0uCgzcbimGxUKxEGVBuCBqUtZeSnvapTMssl9vEY0
M8l+77+iMPCUPCYnwFpy/y97b7rVRrali/7nKWI4fyQMSzgi1Huffe4VQjTG
YIzAGO+qkRmSIoSMulRIgJKd9Sz3We6TnTW71YRCgHNnVd07RpEeTixFrHau
uWb7TQed1s0IBUWJ3+b8JHtkkWVeWKxmUpeZKyXmTMPyXO5K1CK7Qzk1DCXB
NR/gkG8OfsjJOF9/Wh1LtQ8jK/k6+wyHFvEILEMjx89PMc2KYhdMfCqQLhTi
NgEuaBrMmWeOWccYNKQZMK8C1bE5GtcarsYRVy2eWuKB7OAuA/VSraO1Cw79
ybxIoG9IW1bdYyEZYOCUUGYntoi7VW9+Rt5z62RYsA9/7QWwTo14MGSVCWg+
9XTRVLyfXneh5dwG2s+he827BvhMbb4DOoa49Uj/uU4B5qtP5531D9eYeB7e
GP6yVRLWSG4E4mAlhyNCEpvQGXyXpT7i02Xmvv85DZXthpRsNC+qxVZvPb7Q
HvDiqrBou8Hqyw1WNzXIGTQW6D6l0vD6j4cpyUhWkdjUUKHm1jrDmIMiXTcU
edoQfYFq5cZzisyRlzLhNwV6wVC9xBxKeqYMzwSu82Vj6h9pU4Ob301+lpyU
cGYkcgYwdFu87RghMi0CO1fvvJHMccv5/yYTlwlhDpApN/a6S3CpofJsVJFk
iA9NWLweMgAJiGvwlQkD8Nb70uGVCIANj0v8f864SLoGBkPhJJsjuDAVqq89
OBAXKN4zNFACb9NY+eQgt3bINWO/zm4N0wd50PHdYwo9fvLjFu4sXHvL5Cuu
Nhb2teoLIciyVFBKTXWh59r1ttut1g47oZtg6JiTqYMT10U5BzR1todrdejp
6eTT3sfjy28Yc39mJdvC02oUt9N+noVBJzjTrUQWHhyoZZnhAG4IVkkoWdQq
/1jw9qCGSkGrLdSZm0MO0bBwhBQp2BkQMDarvEe2QhUvtB6jyajzKIWYikNB
ZIMUT+HiHk49LFOpEopqMfw+4hAWzD8BNJGOkf6oEgZv/saRY6/vTcn7lWqp
wb1lUNShxwxKuvSaQUJ/w8U5sGd7DtynBLTJA6ZbfiBb14rrjWEds02FUska
TifSKra1TNdzvXUZGjcHBa0spsoEFrvksmJ/WCdlOEEOMxwh1AjbuvLqWRDf
xTrSHFVnHzIjSZnqnRwjC81wWLlUBiysbRShntMeS3w6/Z77uMCwu0YVlhc/
Sa1sezBvsmDsb7gEuok7NDIwbovJESCycJDh+W0R9a1XrepGdpYBnSculpAp
V6HLkNrlFsCsbGoFQQ6D8CvaVQS94Py0TCEeDqmD1kxtCY7kppclmzaviK3e
O41CzVwZyjJQeJtUtKDnuTFFU3hxxH2G0GSngkmh16F3t0PFTOnbtdQ6iGdP
6TWs+i49R7pSOyLW5ls8MpU91hfbqW+Rs+qWpMu4TtbrNsoT16B4n4+Ua6Eq
cxUFgNjz/u2f//ZP75H+t0IQJj0IdYcBuPL5WrUDQOWjN/RHzxWuJa8LdppH
bja1YZdUFiHCN4pSW2jbhlveYeqgqPvJAlH6EkMRKSfe7nl/hxJd/4QZqr/U
5Ux3+iMeH46+s6phidKPjZ+rl7cfC96Ki1JijKfiOjIiJsEuFEed9IeKpJn4
4GFwpBRn5OoVL3b/+zJdoHqokQ5MUS/i6M8/I0Fl+V+aml/S40QJMrGiYYLR
Z18blRwg35Coa1gjSxce4zqRmjVzPpKuh4RZL7p0pbacIGsjJ4FVtJKKUbLn
TZPSGdHNS+SQJSWhDMRdG3sW/vbr6UGRriKFmZDCTBbVuvIcMpDtNvyUwpiy
14qpZcbVLXHRmCSGLOVhDSXg5Bi2CFXNkDXyrRw/ynTU0p2qeQyUpjBHB8vY
GNqpPAcD2+CgkMHzEp/pKqt5nH1r6xC3xkRVmF3jGGyuumnVmYMlNB6HOSev
4aJwWevUqwQVYJNk3kCPk1WsBkaekXUKXq0WrD0syJwZKajgBX6lgU+bMjXw
YVijJlzpiJYqrJZM++tVqsylTp/k1AQzjvrIuUMtSnGr4LmFWtSqwBhgVd57
NVoddTD1rYgvIit17iYYmSlBIx0wo6Uq30KfVsoapDBPxP0JX6InF7eHy+qx
UmkIG8hygpu/KqDaiDmPpBFb9eZQWojhBtPhtUhfTIaUmOsKAqh7d46aHz9S
bS2NRobXt4FisWWobDVavM1NrI4rJFj3OkoUGSlBRAdWf2Dh7dPNR9AdzLMR
FyAyRlbtrWynkeY/kSXnyHVgUmk0r5QCuCSBdbD4To4IRlV5sjIY2g8QYArX
hAoCYeq9K471HPXRSS20QpozVmgMvpxASOYOByss9FZPpAQYZetqCVu4gS3k
DU08qSXvbe1xRqsiG7OcM6g5NidfntIsR9MV7EGBAgWYN0IYiCkHhzOGMsyz
CPIoUUDDSkepWWOU6Fh0E9w2NOqSJI4NUtyxYniQgslFnNJC9orXdaBlRpk7
n+7u3u10SBqKfVNqeVaQ5HI0K12U7WX5kUlFSj1mpcccgrHEx0tAt/qnt4+a
FikYa+JjXuleFhtN1S04KvSPgr0WsmxkVMsuGpVQe3oaz4ZKJtTRPbBO2KLz
iVpFkhSICRfEjYqRIentdA5Jbja9Mf7DiIvFAPsDJYQDxIYYUcSZKTAQ2aIC
h6BTTjWHedvCWxdh4ZADsJRrF9ZSE9HFwM6EZ784G++sYGqIEYoMPo2XgdFN
Ju50+CGRtfF9Ea4VE/mE33aowzV5yhk0sxA+PHJw3AC2F5U3WE02+NECi3jk
bgHlJS9Nbc85JC6jhgo3opgUZRAR2R3R+lpwFs2xPmTKzDq2qtT7VQ1v+8yq
4vZ151dOJvz17FcR+HSIno5as95AD5C1hbtbWbtrou5jWlZ3Ib1t7L7idr8j
/X/9FfVL9F3hZf6r70Mh5HbbCxqe7//KsXKv0Z8pfDGdvsdGgqbTDsRJCGvG
bpkBWVeT4ooxKbZ0Kn5OAfOFJwWck8P95FVH+gD2CspFys9uw19hFdPMAMI9
aLLexPExOp3GphElkxQt2raGSMOfg7NAAyCgLzgPERCZA9AMp3PQQA2kqrPP
avx6c8AOthCV3oSCKBVsRmC07YyZIGeVcJGAqDjtC/LzFaX8BleKmpA60g4x
YCW3dAcab6r+MAGwoi1majUXvDDwMq4NZyuPVvBOazozXAxFGG5624aJAege
GpcgPWsoU7DizjOUHvFAlCAwi9RNQDwlY7kQhvU8o2G+BM588qAywKptb4no
YBd5Q7orSH2f84UplwjzFptq6Q43DGRIp8DoWOphlqVRMzftcgSAapcz8EB8
MoQnmIxOoWeUNZEl83m1xXSD0ZHHjPTdJ8xo/ZIgtlBYZ0sMumvGLuzv1QyI
lEK330o+N/wBbvQwh2rLkzU2ouZI/Cc8AFrPvO9wIZKl5njtPuj1HC6MzGbd
g9sUaVRbkBCHRuDFDmpmk9cyrXIN8nx9PzwoiAamdYSszqW6dB6gge7QBKDk
ljMB47SChXiRJzH3wDrGYDTRxmtNMnBMFDfKZTpc8hmN+e7BBfLflgOvhl+0
D703Gy3XKXfHwztU79ivyKWh26tU6prDAesLOAqzGsRkA+9ekthM2gRIL/hA
gLduPAQpFZFVQY9DmiGzrBaqlchiGVjw8rccVputiaQ1QejAfozeIVjsA66R
AAbqOynASV/p8gnbJ/sHOwidJ4B5mPJscN9bluWdRPqWzkeVNKqcPr3tJswT
KkI2TTKaF+xoQPtKtfnHH4bIoXqDW9lB3LC5Jb6mmJdAWH/qGUE3Y4ZAZaCH
lAOF9LmaTGeQGc2bp5URdr1BMDragCiUhArAg88AGB9asiGOM9E+6YhRIiQd
mCiE8KzB2KW1HmdKaY5OryEZ3HVhvjdBLg4rl06X856WM4yBihG+3r1Tf2lw
qRSWc9v7quSOvSHcoOfgWPV2/mY9O5ktF++Z2r6SVXe1Y77HF70i95YO0T3N
9i91oaqXzbO31rPuM2tLgHXEzJs0rqKczbWa98YhbN5ppgDQzQyEhvm//k5j
kIdasP/zhWX3+KojmCz59b1p9Nvez1mzOH+HVm5KasUGHj0omYmHCLidehGf
/AZm1Eda4FP4HeuXbQPrV605fwfwt3pe/e3syzxeLOcTntIoThbjabog/quW
8XTPYSzqfeYZcHL6lvZKJkwmILRJ9xY5te2/UgC95a/rsHu+vBti2eeDVtVv
+MJcFCfYP7IKsm2DvWgH5Zv+LUOGmdMUOXHbZA8DN/X+MEmGcfEoHo3G0cTy
fKvDow4TQCkrVnkbUTQE2GMKDM5gcS/zFou/RHn2W5LlJEWHGYyrz43pHCpp
SpdgJXrXL3EnC8ICtwP8kW2jDCdFbMY6W+vSjrrLn3JrG4y1BfLd40I6519C
0zUntg1lRiYXngPM5b0nwQvorJ6r+wY5RzwG41FscI/MLo2xKpIkZKGLMsLT
xbSTKNKZIoMNCprWjE0fqUatRdHsTVEOOvEwt7oMvG2FeJiGiOtGZFLo8wJm
nhZ4em1L6Tn30BrsWUULFiJSo6/AlrHRT5TaUYYvuHAkoBJk+ONJgtIFiz7O
9qHA0lwbAIdAUCASBQhoz7+MQrtH2AzHQI7oq4E2IY6MeZjljTDTxj4K9PTl
bZzLWa1uXQ5g+bf+RlMw3eXa6LINUGQcF0qVNl5cBnen7f0g1K4eKY1Ek3ba
MbWkZScnRoOPu9br/5X1TP8m5lUfW/UfDw7Y6MJlr0FATpZoLMaEPgzHLKx3
QgoF1X374Zfdm1StvQlV4eOV85KzWVqOz0ksEoYGvDHzkHh1JDbZiIR/8yjg
Dy+BP/AhClNJcfNDf+PVfnV5UKwbQUxio+k0/aoU5clqDBUyOjFI3f/v/0P/
/WqdE+s6l0iYcuBV2171AP6uNbzqPvxeq3i1EgylUvKqFXygDL/UQvhQ/ryW
WEn30CXnZOAG1WYNz3EN7dCOcdZiLphamRa4LhpKdx4YEtyKd4KyyNSfmlXO
Pl7NfVw70pjRkhc9a+jLMmuNKSAHnnMo7eAcQumLLOBrzl2qIKwxsx3jBC14
lcB8kWY9nrZfs1KxH1xznGacoxmHKXtA1ftKjYBmsq5PdnRmp1E1cEc2d9Dk
ZiZYrW6YIDtcX56geqha+1fnyDuaJ+IM11CIlYBXKjXKFMvAG27lPTinX6gU
mQRev8DnXTA4pUy2T3YQs8YVEayOrHhIYBlFQ2HMPejGRQ7CqRNyaoxSheTZ
PrHLxBNTMBHJa7VTmu2OE7V3Yi8R5UPnJtY7ckAE/l/BSdSGX2eCYBiRxBB4
awh6ltxeOftSYEOGhfKUuYHo5qEqYLdxLmfX4JbzAld4ecBUdgyb2Ob7EeAD
yW+vk5koyHdnV9q25NtdYofGitS7jXt3SjY0h0A/WzCGXfwm9yFtzVVC53I0
VQy4UqoSvXLaCiku4sfE6Oi+G2TCpLxOx2G9UVcEBKd24tV5xIN5NAE3OeZ8
uIZCqhNZehlPRicbT4CC0Axhz8kyzRrZAnkiF/sp+5krioNu/IZ353t3gbe7
u+vdlQIv9b008PyK/Yfx4Ygt36EXDB6VGJXJlGnF2QoRtvm1lCQW1bb1wjN7
aYE82OFNjAVFD0+4AM60myzTnlCswyE188iwiKzWhAcLoWlcQ27K5ZLIND5x
j68TObS2ANYYAU4KnJQYGFOitbGNvhL+Du3A9gZhvUC/NEJ6mjcdhTXwmCiF
itOCOfmUuoMQRMoDsiN90XG5gDwmcrq8xAs4jj8DQ/c8YW6S5oaSGkIAZXko
9JxpmF36fErXJm8ColoXpr18gq5m/jxL0who+JdQ9m6mashfTVCKPIIyDan6
/2mCwtXWtjiLiUKU7jBlee9hyooOY/lxdgsLjGLuzkjB8ew2HiNal3OytSFn
zSjDiNGSasOta4Ja071gWEqEppHhBfhpIiK/5kya9axJsCZea8Py/M3y8Shh
kBxXz+lkqCNcYShpqETaTarNix0XuDiFDoOVK4tvPJfs7YOL58QxBGJ4u3VQ
YS1SDwlPEx0c5u5wka6Lsi8OFdH5XVothUCJ1HK5rolTENCxdb4ZYFB8tv4a
0/zf7GQ5G0zasb/Q2Cy5jGutrhvUdbeORV0RWheTxVAsMYjCagOMnmcZRC7g
lUO7/qMcjYJUBQCuQWnOw7n3dF/wvvz9/vAPcl5DXfPYPi5ks+54f/fuL5Dm
xupX4PK/KJb1i9LjMc7c3nX8QF/r+K/ZXS+t/MIcCVtBxeKXT8f7vyjlFkz+
5PtS/9jWX+3gk2SX/nvmDepEPuJecBV+UWNwxuaX+P8B/V8pF7+A+UI/oOR3
eYGZpbrVrsH0gF9vNgDQ93obfrF0cRz6N56c0DPSo/B1q1djOzF929vxTbWB
XpROgdq0vCjWYy31mGlg2/umBFz1iLcdoRJhEyGGN1wPZzGz4fF0zooVM1a4
4gvePVHvN4M9MoqpcoZhuMRPU2jwCzgbeuzwIML5kufsQKqmi2AbvOBf9nZo
KWH7W/x7a4evDGOCkAtgOKGoE/cWwaO56zg8bVsIrq8m++154WJH8QaYa57N
vrvSUPbonUGpAk7B/Av8dX8ocV37R7QX5BnaMsHjXAwJDWVWYTl5Fukg40wg
p0CeCCUPK44UzVIcFXKHAw2bzgzVQpwxqVZiwUc6o8LuaOdiZYxiXZ8Jr7VS
AQFzh6foKfaPeZieumIXEldv+S9MACno82qkoCgbLfvZLrUrQzUvpj4xhGQG
kNM9IPcsqZr2C6OQNSy/tIZGn//BVeQXMY8f45SzAh+aMBwbQn6gKcwapoD4
5upxQ3ZukGn/tnjXT4p38Z1l0rCiTClc6J/kFTTDsBBBrXrtG7KU8tKWiltW
SsE/ja/8nyJ+blkmJ/6efmWpdMvYoOT7CtaYZ0F1K2OGyu8ka5rK7Sljq8rv
bi0pIbe/LSuno2no5eknUATS4nRSNFSE0aDe+Umr81OgY4TtUOynn+CqLIrg
8YdkK0u8EqS3pZIhCWTHbRm3fvu0XYQPg+J98EuF8ihOO03rM8vRT7aYEaKE
kzSkayovMOzTtAthSAD7PjARIrMIai9drsFSIaTFMhWOlgW9AO2iq05IikFG
6FpBzRBjqaY9fH/GdVydCAV1GfWjmYXnDPFH6iFeg/twN5BUz6AGyqT1Dwvb
2gosh1kASuUYmRtB7S+wvoCsq+INvDe7mJi9IFxAHDrWfbk3lw2ViyMZfojV
uCTzdpQUzb2qI2GJVcHapXpNNOzV0uAdsDmeVl8/Ye0Xpxa5W19sn7U+7bfB
Kz6Oi0BW8Hmxwhl7iOQKcRdbW3fe37fIY7sp0ha9BGArW0Jfp/i8xZW72h2K
Ons2tJpbHX8EwYUC2+B3CJW484peAKZiEgfUYNrUupiyxoKWu7ndO8hGgYrS
7703ZlBU0OWN+i7Y9T7SkyiUwnXuHSc0hP/NIyiIYrreAmn2i+lMNRXuOqK1
M6Dzjj0m1Sp2UPRKot7yqGdpvOxPi3PV7HRsYbtgzKMJeUQHClpCTVis6kLq
1uv813g4uF0YJ0pp1wqKUuyhU2ARifGYSKCjyE+xEKgdpEDBSXbZFUk5k5L4
83RLau/BdmE4MYaTPPohhpJ0+F/46akaVnlXBL72aT617rfzqZUi+yxqfSWB
WCTl0Ovagxb1WJImlih/4wQXQtiIjPkXZK66SV01RmuN7hpSBMg6wbiU4e4/
S4N65ywjl6z+Kxf/2MYJ4YDUBF7WqC0oq97Gj5GaqmKGI+Mb9nUdDraV/OD7
obyvq+JSA8jY8nvEesyyoGo2yOxP0SvFQ3FOhBPYbUwAcp7X9tQ6z52YE6TA
AAkUh0+A+8e4e0R87BHnnccYcgXZEQyEE3nZLjKAJviZJnrnKkZyTyOL3uXG
zzE99GOsXzUBgunRMQaZUqLotfdasgA1Srk6AijrATB5lPHcqymRv+oWuBVZ
L9Nn7wL3fVrmXXM8n7kc1FMxMkV4AqQCTIfe1M/6AReWt4A23iLX5gpU8IHj
hXcxnPfbF2Z9LsnxJCDlRHc9UqHV5byca5ti7or++XsK5y7cJs27rP7mvdHL
kuUi3Ag8i+lVwJs6nAahbrjmbMZ1rjORq1OX/7N1l8Hi8FlagSPScY84XHD7
dIfCOY8373q6PoXCm1dfpFfalQb6G7kBoBeJ2CmYcSrBunOmhDvYRxqtGFHc
YZFtTw36o1p/1HhJlFJXJj7IYdY6NBw6pgtxFDNZ8Tt5RHlJ16taEKLi/2UT
osz69ftnL0f5ebnCvSZiFiwWIl/wEDey1IODV8oSdSNHVPLlCHsZL5+TJTZc
hM9IDsH65QUrXs1KDpaaaiJAzw26EAeS5BhRZvohDAuFNKB+DDYfJEDgCkZ9
s0t+3RIcIAGBpwKXPOTSiEtkxGtltqTizmyaphjEx5k1pj1TN5RLJhXslFsz
oYxTrDmC0AP9MquhdBeYYAfEr4ng0f/7YTq/21UM7g0mBbeiMaQhR+T5uXyY
JsP01viDoKncVm6n43h3OgeJ2ljYuKgQXKF6ngiBYIM9TbmeuNSn+znNrfFN
qypjEFfPVeeyaFIArCgLii1g12L8SNDGiCVnHW16YhHRV7yj6nxaKvDQ1AIk
wlVTGUW0vyS2mMZ56jhfmn8eCr/BwtPjRm1ZrwnnyFDPgso8Wom7U02fagW6
7XLnyXKOB476z8BcWliSlGp1PwSztYuMbtsTUEMu1zGPAcnpcg6UuA8GqhQT
83Ekm7ZhNw8TNpOVn3cSdaAZuoVdQ+3PqX1QYR8Zj9QNiXKL7eq3cwsRJEMo
fQT0N6Q0CTMSCEQmizYZlsFWxrHnBkZe03I2wC7Nmps306t2wVKincVhnE5x
USbFeDyDSJHL9bnAwScz4sotxDcb9u48p941r6zdPmkD6zQLeZYsxlo6xxrL
AtKe/Mzyvoaqt1Yod/nZAirt2/IIoPhFKy4uDnTzEM0nGb6rFwqC36e9KV7m
iqcoklDkPaJi5g6LTJczhF7FN5FfFiREkKXl3FJ9JmUlQpwsfRnotEE7/zBj
D0o1qaQEtM+pasB9sVAw8E9YfHgQvYUTe6k1ljZd48f77aYVXsrnBC/aFxYb
FjD1NIcAiAY4INgdosNPsPGi6VCLrrAJuhbIsB8jaLHs2nDBmyVQQSOoyhE/
LhQL0BSntMU3M/niDaOWAAMRszkWjMQICRvhQlfoYOxJsXAB4P/LuB+mdzHp
mUKOa1D/Bh+HZ9+3auAIsjfsl6mN8TeYOxwQ4mdOWTDz4miICJULnUy5nJhO
RvwOhRdhgTdk4hsEGPoyT3BJiZ44gc+k3z4v7hRoRaWmJZHxSmLbbaEnV965
1CWmIQoC2UlM0iiVAabsJxwzlI7DE2ShNYyjPgbULRdS/4MNz1KWCHHEzQwl
tkbLmloOQsJrWa85q6ZLW+cuXF4KqEtHk+cvKOtSuo8hFwVP85WFeuZt+zt/
XiK5pC4heMFqUtfQgqNkoPtSAuExl486KaMhJCBmJAJ8TfJouLtIcSfGaty0
B+M4ktII//aPb8fn28FOwZmrmuq//TtXPmAQSUYT4NBUtffqPbsDJiSA69iY
jysc1FkDPKJ8iVjrqoQYnP0wdbcIOIg9LzvUllDi7Ylk2Zfd8/McLLJJAvjK
2qD/Nd6VOwcSpDfU8FJsyIygCCP4V9iXNZk1/vUTeQ83KWACec8HXUdLr7nD
4SKcgonLhE8NJixoFDylD/NFRvvL0PMAasMwRZG8MI8QSZryuR9upyTUs6zY
5VdXdi+sd6C1zZXNiUVxmGlkxA6Cg1vOQMYfDpQoObIBluOIvFGTeDBdDMVe
dHm7TFFZIbWNKzpLVXA1HMA7UoojDHNv2hUgBFeNJK+fOrQpEdotxbzSAmRW
FI+RaunnNEt54JNfm69ME/oGuyueKRA11FMYgpW9I4z6SYhIpLZpv2i+3uaO
8b9LeYN796LT9J5+mqdRES2dnCxqWWTFkJH2IMClQIeegYngZWspNqGjFdjS
PaKc8HlMt2JfWCSoVbB3aNPVOM2qDwkcC0pBk1MhNvNLq7i1js+AARLYs3Vp
W7SxmsUklcKDAP1d/ESV6tWo4COO78VPTT3lNOY3CSBXRkzqyRtMyBpFg/TN
Wt1xq/48iLpLgo9fWKAjBKhIZxLiTEHqpOHQnEYYQThccLFph5c/w1t76OKl
esURhS6ihtG8sYrzDRfPq69rqwocDEO4jL+h5NdCxknaGPlhhbMUcE10FY0V
5xP82Q6y0TI/3nzol+sbm6c6LCT/p5auspR6L9CwVUL6mdHLWliRREJIorTo
iGhxOCNezNR7iKM7yvhT19JcgNgAux+Pct86yvDJpqOnpDVGDqZyIujt0IfP
hRp/4eStU8i+OXfP7FLu5livIqbPIALT7dNPMf32Z9iUNGIO/n8vp1pfLxnh
y2smcWAMpOq89ycoVhqwqPY/gTIRjBT2sG9TZ3NkwX/SI1YQGEsbc3Va5gB9
gkIv2ODAr1bQO4HygUQLzePflkNtS4JQt0GcWsH1unqPpMpRkD6gDhXhSo77
O+QEJblxCQKJUyXDTqJVmzxfTnpOirsp8spdY/IoRuVRUPnf8h/jGBkemHq+
q5odmxGyVptZJAnbpjyq9ww3ZYG7Wxj1xpKOWbSMhIoNmkrPGmXhzUzN9408
6m2fq3/is1xaEhZLU8Et4KVOUncr8FBNYrtsK15qWZBFq4CPgUvrS8PpLaOl
o2vBxCjRqlhOVQz9kkG69ti8lEdangJB4zMmKKKuwSF5g4jMj+JweoP5Kjxe
eWVoV8FAOQwMlOKiEgwEqxWWtiSFwSgKALSvBDD+whwOK8XEKWBItkbk105C
RNZXo5OC1DiT5UjkYyo2qHfJYRcFbxWLnIhhaEpPlsMEtnO00Fk8BsxH4Dok
OFLbQC96hbURJDdBs1jvBLdSTyAHoICDnfUjFMxedDEOvjZ2y6G3HQY7mdgL
6NzAJtkABibgGL1dGEaRxuMINBAtwnI2DEpgKYSywskB69Kcfa3PDkspBe39
IzWs0g77kYAot8MyuJDP85wQupoxBDQgHIK++J7aHw+bp82PELJnlCtWi3IX
5Xgfmgx9e83Nnaa7eF2EM4qMm66XzReZGaow1L2P7ePWUftsr6n+vhDkmtbB
nncK6vXTT72kWxxTaBMsfovskwdx3O8qGdrbVo/u4M1ioXLZOJpDRwERwJzq
bonygOl+LtWbmrSg7zQe4Msop/2aIqidkzDbHU17d05aDhtOt4e78W7BmyBU
PTSFQ6P4Cx18Yb3NHIPLWJxznRjAdlaMB6qwTEB/tkPnO+GJZl1AuaY0kdEr
QA+hsqZXKdhPGfsq/5HhGLglow/qWqhoSFCMHmjS5TSZnESpHQH3IOgefAbo
RoNQTC+gYKUg8NnrSZMkmCZrligYnLvDy2muiq1xlv7zjRlKx4ADXbxeneto
YPPp84vjL83LtnfVaZuEr7z0+3oQouRrKdcZU6Jl0u2pnoHJSjcpjVNdaWPO
fkRdHCMvjptnzaKMy0JxQHx8tEcPoOqqVXRcbclgOIGEpREAB6EZP13EYyKl
UyWOFKEuuNIVBe48IbqKMDVOna0xPNNzngG45WIsz/yBfjDr8qbS57QeEamn
lgkYTqSSBPtp0aDyFNBIqqWCKfhMMiuGARbw/mAe9WDBMFwLy4CR58yyxEZq
fR/Unc9WH7xjJdkPFnY2TSEymuoCKRF3FFmeEm20/znNhCFkBZKDmDlqun66
1Ppex1L2mCxBkooG2XZqx8DQrDMQzfTg1p2trw+o3Kb6JUwvU/4n7yXkKFAA
Qz1uV9xU/WjnZc7C6OtwOdPF58xckXwY9R6lfc5FZvjZUWSQmx5uGZoKGNhE
36m7EkVptoICumGkhLvhDIzZaWYIkPO3oU+yVdhNuAMouL2bdJR5/B3hc7Hw
mboGlhjCnjkgTz+l/E3mWGDaX1Mu2Imae9y7nUxH0wGW5ZuOMIbdRqov2AJR
KnH1GFpN9wVJD2wzphKoUx28GFPMhCM94P2GF4mR9Siuhm23yxFct4xvCH6a
xUJRBgQ1gT91umFEPE+oWRZp4OCla80ExgGURtoWlOED/zNFsNxL5IZiDEu4
bQzHInz6FZuXoSdwsJArkRDaSE3G7iaKu1lTcNwRgHWRD2xrZd07Zeb0/gxj
DBE/phAcdPH0bV+5LsymQQKRy7AI5XwPCXGY/Qy16rAKBcamAcUYq8IMcziQ
mWCNBqz9EMskYu90n7JNOkfNYpCx+KZ5O4sfgQ49AScDpFQADfbUAIZSiVXK
hVvKAbocYeJuf65pktwxqVPlYJvkMjvEkNBGToEc5XgYaz/VsACCAu/EnWcH
PKkLgTzkxgzPhbUFngqrmuAi91betkGe2NEpMQPsbttIjju4nWqBlH7BKcUA
nWLBx6jLFVMFKasf/HTdWI2NZZqydA7iDsGGShS1dR1M+hkcDFzMKykS587C
CrmRKhQMSgNlNqfLOVzqmgJciwbeDuit1rwF1p7DDMidQaiAzCtBDMXsGyvi
1FKoPCg+S7KhlcwTPUSCxBtjTSNT1zies92D4Vm5e80/0F0NzVAQnsYftP1D
Zn/R2KP2AgaC5nFLO2HzEvrL1Rlf2R3ah8AaNj5LWiHWPt1lPizUSpCV6Ped
rCxrRqQ9/QXP+hV2J9NbgQpiUTlI/b6SWSj8CIy1izkXb+hh8IXJkIruYhMw
gFMHq03M3hyC0JSR2kWiF7Dn6TJRrGxIGiSvhEZ15qLIaO2YYLDuNVpxgIdC
ZFRKkQJsPJlbFX4o897QF7igYriglNCAiYMdYKKgUyCHI1aKafg1k5EPmWD6
4tbmTome45uLp72AUpESMTezGqURgu1NbR1qU8I8RooGR6lbPGWN38fiEAHP
J8hUxXk8ohp4OoPOZkeQFwaMzNYx8eZzKDmiMLds9Baa+VIdJgIaPtKJAK6v
DxNATrvTwdIREaUKjwigutC33DkxmPSwRhvCIvbI4UYQcGtxWeRDBHYBXaRW
dDqdpIxL8wjm27Fjuk6hVtJCx/Xp93/Wk85MlwyO6uNTmvnRz3iFUDM9ci9P
zKwc5xUptdgwO6CxtA1O4md7lQAZ92e7/SMHH+LBVDPHjoaL5UI4C1yBWCGI
RMkjuGCPfvb4IsH50+nEltDCitWgClgL6h4vTOK4ZA4ygTe487bdAEtcqTck
VoaqxmaYB5KqIrHVdIlXa3c5HPXZhm47sAFYkIVrJzAST6fEGUVWYIZcIQ5j
d/JRmXVre14ynRKEi8OJDXVwHQKJCHCHARbyGJBl0NlX9Kiuik4wkWvQ4tFj
0qbzLC5GhlGy+2j1Oyav6JISsHEa9dBAGInR//L608Fx58gj73tK3FFkVATz
iFKlxJvbA9UVHemoe0Qvqum22e7gjeRGjKUmPlzispSaCYGBivljHUK2WI5p
oyfeiIxfih3OvdCHtK0PijSifsE7iRa/0wXTUZJnDEFGyAzBfUDAPyYejNgR
hMNTCJkbeGyKamshC6UK3hNwcWQ16KenDycdH+u2omyEG0K9MFCbMEC+v212
QEIssAh2IHssxk/puBPINRebUcsyiafL1IQ8WpkLUiGSO4PBXNqdo/lrKYIA
PIo9RambHTadRz2p9w1MZ5os4kleXCx1oKdK14VVbA2DHUAYRtscmt3HwMs4
wxr5Bbl19ANF+wH27AwnJC3i2CZUzRfr8cZwkQAAFtSPYcWUh0JTxOhrdczQ
wbJu2OVEDZTMWyLQQ7F1tlIqdfQ2Cnr9P9BfkTFGqddO9z62O+CwgDWhZthz
tIYqpvUFdYtCkkzkINlvtP2LmQNMD+oOiKm2NVSOt/q07kRhL6QAsOON9AzH
C6CkcAPGk6IrxexbQQR1G7TVwv9AxQ+73t3qYEVmMGIzwNaGeeCdOldHx+25
QGU7wEDDZjsTjUOTA71KEn/wCKZqN8EumlLWKyX1IzsdpnewuYCoQUlzXcWt
7tC4iv4QID4l8dHpkYLnsahmeoee2w4IzQBg5PFsIeYCdQ2jxs0hTuQDg2zP
4Z2uSh9xORbdh2YObOrVV2o/HikS44r2ZDMxaga1PWUuYuXRSXojaenasIAA
NxBSt74i21yVniBKJxjDTJYzZDNK3OotOANRj5kTsXbYvCExS7pRKxIcDx4W
QYgk2UZJANPuMs1mgwCIyFPnsv2lfdYJ/aDkuEcjyStlBy+cS0SiwODD6RwP
80M8GhVpfTM7yasMzg6gHL7tvJaHoYMZtxgwRzBaDKEEDsuPpNpDTSI47kFr
Xxwkzf69OsEY8apG0FHXJ9CRUbUU55B/FFP1bZHsWEoOV7zkS9XWyrSNz4MH
tT2XHN+UDS0Lix4LgnRJBdBFfL6OTw92AIPx7qvrLl1K3VhP02WTUKpZqhKw
51CstTcCUH4gBlpOiV+AcWDZWQhjEsVcS5kEeqOECLVXlM6ib409MGSMeDPJ
okw4A7QEqNJHvVurNZARLbmrLwqDeEqsyelqk6ZnsBij+oZ3l4aRRumT2+tp
lZcvy6IxMxUsx3rMQ8QkdSv8eGGljlt6u7ZU8XZSTiI67YQaRXW7A7VIL/Ia
+DCqpRGYtt4QlR8r2V6J29FYTTB9k7mQiF5Az5sjkUYQ3aqEDEmKzB4RvefM
1omEzPTgYu3DDQp+W3X9kFER9EtpuajFGWrQtrqLTZTXw/AtIXYusIhbQTzR
uROQwXBmP1TyIY+ZXKQQR6mGHkcaDxFlbVx/maX1LIyD4u4gTUAHrjMMitbH
nNjbDFQrUACMWkyEej52PrOisx4HIUjluNzxoDLO0Pty0QVVk+KqrmYqYBql
nB5ghEmqYynLqwiI8qUdu1BXTo9leFpJNT17RzIVr/VplQHoi5e0uRnB02RO
PM0XSz/DKgpRwEjxfh7x/YPIn3O8zMBpOTX2MNgFDIW0Ks0iZD4IPkuKM8ca
OfM+GtUwjj+l3jnOBOP7bfbWbmHMHYht553OxwvC3WndTqfpq1mQkxA3meas
AEMws1jBJUGHi+EgIrACkMjUGkgInVuQFXBMW0pVmoBlBkrE9IqgcxV7/BlU
24Rn+N+aF2PorChOIomguIgxQhjgRCrwzw4ik1wLbIjlCw+85SMypmdUAr03
oh04hYCp34ndHWkDk3hBqUDx/B6sKYwSjkFWpnlQmidZ1Ej00YKCok4B1Gih
orSShiy9WNWkJQCBdhshpQCMDFbI9c2kOQupyIEKvmnTo1F9tK2RxSOsWTk3
6iEfYVJBUnIHCzOx44XIhpFEwxHZNudovCsqaXhiV3SwppQt+ow0KWuKKm0S
9dQZPSUyo3fYLJm7XDhUOE53GNgMQ52Q/37FRldcpD7m8RMvEwQRDHVrSbk1
COzUaID9KYj0NgYFB4peKHon0cH7vITMzxY64D4hDSky/w0+LKJXrkiEhRA6
arIYx6RU/EpB6YhzsJoBfB6BllxMuyDZflv21JuqvylJ2W3Fy0DAnMfARWMC
N5mhUI0XKR117TTHiDocALkF3wDt3Adep318vk+WhPa+du7yAdFo/qImkxrA
qvHD1AJigMt3JXEpZJ17ejr95lcoEhU8WbgYDxhPyH59YjxzVO8XJsPXBi7N
4rhQ9BTrbpRrx3qJmiyatQHWfnY7R1jnFBMhlBbWsfDsU7kPLIezcf7gMHWs
Ph7rfoRRS2jsEkq3lhKvmeGY2AWjzdhavDGe0+O8uOqinHLyknXNZaZ3P4zY
vDcdE/9l1kKCCgWozqPZsI8aFDNpJdTPyQ24P0wjItbsoNmZmlpGFMFdhJ1U
3TsZsOhHpeqSGYB7x7kaWcsvLhirOgluQ2FtLHy1a+xfHWwKDLEA7Q5NDj3E
sRDRmOxJCOAh2ThLA0r+5sXP6uikOIp50h4O+TwjkYasCGxTnZFglXvafbdO
xRblMhPkaqsSPo1LSmt0H9JB1BEN2TU2MXZ6S9aXka0vHGwpBVjXXrVihR1g
aFqQwTJSssEidtAkyOIAoGZuCYjLzAiYS2ywkGGYlRH6yUeh9OopWBk3ms0O
co8TmVB10Uy61gpcbWijhY31WbCiwLJ/VPJZ6h0AOxX8R+QxDPmosadMpL96
RKL8t+UGvujYmdt4E48OMU/AfIr1NHaM6fiZUAoWdTQIVCRxKvaRpytrsByS
qubAWqV0QUzZxJLhn8h+QGTNGkLVwN+tST7UKbwCsuwazZBAO30wLgQnVt5F
Bl8LwCTQLakvY2QHZl/GogdaDKhhpINpNQ6GRVF6gj25TCOwFoBColQquJkL
LiosmFOpJB4bfClmbj0/ghJYOR5c+CcvM9nixlICm0dDViAo5qeoffFMdpgx
+tFICmwrKngS3UhuTtlUgu2W0jEmBEasasOJVMBOBXvLtoO7Qcng5E7J90hX
ln20WLAmiDPSZQyBiEUCRo/mydFS4z9PGYPNRCvQNYimp4TVHjvon+vLmOVl
4lRECRYu+D9JJuZi5ie2ObkYr27OHLJJUvEbq0EjpyKuGrr1RUpxkZyl6A0H
Y7uA+YqcUlJxEwJ3pvOs2bWjpL64zow1E2X2215RnBZhjLL4pPNKhGYpFkZp
uin52EerzDyIFtamgnRPK2DvPWyjiQucLtiIO0RbSIRZuIg+g9eRFbxIO2k4
3SxajaZRnzjtgWVTv0oFa/bpJ8vWXlzK5xpYdz3wyno+JXq/x9xnTCzV1kEs
r70d7w52Ae9fnZQptQGXH9iJnp4wm2BetLvXkZamLIDIp0Xts7Tf+OOPHU7E
cvgD90saGYFCS9m7nby4dcIOSKdaArH9D6gQTChb27YMSFmPfvxIzjNwKwA+
BySZsI5Cb6ERw8qpmXO4l1pg9TxvM95g42gCseZ29xj7qbR3UlY5Nc4IE5JY
qC73GBxvB2jwNlKe1RS72dH5r6mLEv0ghsqULLV6t4vDq/fKvgOghlnegCVJ
yup8CqoqYnkO5tPlDLmLul3n/CB1oW7ShTonkIUsCh4ql/gKGkzJp7GECqxw
/OTKonBLEbZMNQzOYqXYA2MC6C+74HHZNdqDIuwFsEMo3TIRuR0L92JnZNLA
ZGlKcOlBEIC1/mD8UYKXEiUW8+lMrlVHR+AQyIglymHqrOBwoov8gkCEWw2e
SvDYwJStpd1+errqtM+OvxY7l1f7NxSLB1ezqRdo7xMZ3UmvASlrMhDfB62j
IAOQLU4p8SCNNxe62oi3TfOkC/6+/HPqBVUsKG93A4cNOK5zPFJqE8xigh/D
nYLBY4m8l0K7uQtKaNzkriPJV7UN9wGyewJx6mXOhZJsJmnCerm1ScRpBW2N
HfMm0VhC8Pmk6VbwgrR3GmPzHV6HKhXNjOun2LZ3EvE4b1vRMyNfm4rcRLCW
R2DIQEikpSi+p5j8KO6DTTh+ZDjDGdSyHjJ+BvZdNOWhQUp1naVSP1KHZGiB
w/IdSs4dXUAaFK+n24/64jtDJ3pmwylUzQ1xRMbZQxVvS61ym9CyF1PFZTBy
wSCcq3apm+GkqJ4pjqbTGfIw5/jCbcu+PDA4FVg6Rz5FqfMSuWmqszvaRMto
MKeW1gFpRRv0EYydtxQfY5fkuscrxwIOQZoSztelgnELJzQCFhr4PsbpC+ST
IDJYcS1veBSj+M2um+XHygfqCPOh5OqtONjcVkTwXtbtWLol3D0Ohh1ieYIf
KjfdbArBbgY1Lc2Jdhja0QPyHvI6LW7hldJjEPkuZj0DOaQxtZXGdg8PmFx4
r5Ry8pftcRxBPnsA11TEaTVyewooFnFjNEFg6OOkR2ZVa2HM9qb6otnIiZC8
7ym+WSvfIoKDFRkmTXrgbBZH81T7PLg73GxMiRPMGhAz0d9NErkTiIhmES1g
r6cop0vU3go2M7MONYjaWDJJjJAWKdJIbSuOxRRvwevAEcgCxXzOcrtuzbKa
S3u8sey9AmDFIdbgxCglY8GztdVMC09P7YPm8UeSBk8vPh4GaKCkanCmBmaz
3dzPGL805nYm1G4RDdC+kxpRKRcDTucp/ksLiK3kLd+mxHtNkmkuTWKMRw9c
QzFpcTQMpBj83hpBBiFGrw6ZsGDJBKAAniH1gXmoOkDwjHuGorm6se4xYA8r
edAqi5Obekw5mFxy28HC/uJ2iZtTb5lF0gvKlweJDpInRfhUBxxg3nUt0+Xk
jsIE6E5fedus8+ywfxKeSIUgh4SUp5REWIr87X9hndGCQSKL6xpa6yl3R9gV
QYVLMLg+jlDtTMCZD0yZgQRfwxugQu8UxAOS7hYGYmCYso0TMwyaE800THke
hz/HAt6oeyT5N48STRAmlvJrqmtOowqj2mAKXVo4WakGCKTEkeshZIbgnWUI
Qup84CFa/RBSl7GoaG9AbIOAsWmXUgUmKy0qBxsHf6wZ1bm2nGeGwY0UoZav
IB5aph3RDiFr2cgvJpKvBVYXLYWhzUMt/doQw79iiFAAOGeIOUxySjlmdLaQ
Y6KpJbO+k+mG46iH30GYkKIpcsrOQj16C0dEh78gkeB7bl3qvB22vUG8vQXG
GWNDgy7tTPZQ3R27QtDADiNH+Pai90VXkNw+FcrHTHJg/NHDmj3qvbWQSlkY
Iu8Ms3WW9QajYWrX7apMuep2SxDTZd6GiBe2aeFZtl8uedvAUZ23kcXm7Cra
4iRbxo5QBO42nCtBmSI/crEekRlI3r7Js8l4nVhooCAqirlYP9lOjhXyfNCx
OQjP7EtqDNrdmPN+dTad9kvaWMJOsKiusm2cpS4Oj3VLw12v+tClZIg9rYMm
Yy7ZnBQPK1iUaec44Tx3iZ5H0CjNTjnSlCx/+lwzZf7Z461BhE2mrM7kVweJ
86FT23S2g2cZgw+o8h1uBIVMrbeCD+dckj2J2X8g1SMRxFxnCVI9a3GbyV3w
HNKxC1oUZd/d1ctt5fZZXerT9mzfE0fc4K2fmrrAkXG567XGYK5dqqopXsui
carmcbMhV4EmVoj1nskszR90EMVEujBpyaZVLmxpxCZYqW1Ae1ji0InXKFaw
I3YHCV3GYl1kwJhr73UudLMlA9oLB71CMPy6wJqXQUjuDQnGYoZkK8VgWnxQ
xGyb3C1rtEmpVTukWKLlk0MyzZlzGRZTceudnGAaSKRasr/Mjg8FyiUl0or5
4q1j1zkTh7WfAuDz9HTy6bx9plgf6SUnF5RdsXWck0JtvEe4fduaDlG/yttA
MD/NCMueSmCg/QSVpnQ2J+K7QgsxzPei3fp0eto+21ccDv1oAyqiNOWNwyQC
cnxfmQArPQquQQ7Xc/EihgXh4y/p7iDR4CNwEc/hCXavphRXnCm/CbagzEnb
KH5YRegNv6TEyDXlgH1WFlozVfDGyESI0UPTmsUAhJ+BmYj9gcO5zbBRwu6u
rBgRDAoUZ5EePY0uRs2HihKZhD87Kg+FjF2pPERRWpHEHBiUeRZJLDQANR4K
fGIFEGg3FZ0B1iODb46C/YRxo/mAyXJknIdQBXDlLinsQi+akTSvRHkSSMl4
6FxteIkOZxG7cDgIE8NsdWgVJuz0sPFbil+9pVBL2BKdf0n9W9F3lnkIs2bH
cOnrODY8erIrGOkrawcTMxGyun058mCkG8aWD9HRdJBlXwAJ6YsczhgDzevw
NsZNsUlJF6qX73ixuys7ZpGPSVGfEwEi4TQ8CFg2Zpx5PObS61ZH26aIoyHx
nbWhCT1QWDhwhIyURQdFY9IvptNdEMbJPR3p8hfm0PGZ4gPGt0HWYvD8JCG1
mJnrevuUsOmQvOVwzZubG3wNA+Py6tuk5nOSL/GDSICqyFaBFKcLd4h1YQfX
gI21LgSf1K6x97zfZ5VTyoZD7QMKL0zZ9kw1TChQP0piiMQBaZTDXC0jBsK/
ROLemEqUHq83wwzohfVoYbsUBzXhcH62YKLbkmNB5lGy2LHMtfN4qiTyWIrd
0ybE/aHGHkBNDZIj0Rhu5VGjr1AnTi9u4YB5OrZerm4upLmQcgyKgkfd6SNv
ZUEgoyXEE7gpOsojl73n7TeE/o3IPA6xtURK8VjpEPCrLjYla2osxt79UCkK
458VGxpxtiryaspWpRTD7CNyCCcGvNDwGEJqYy6xYWvoQCsld4KcxezrhquL
aoKzrITnlTUYOxnyOGPFjuaxuf37kroLbx2L3nOhl9V23G+/wiNuaQgPlLUN
47cCSZjrMQAgsV0DT0O1tNToVob7ZU8QOpwzGza32O9wsWF5d0Xveg3bYdsR
BT0XR9HKCn1+AZMh45azeQoFL8dzx71mIl0tUohT8LFRIq8UiJD+KeUecs6s
5tabIMqgXFJOu+jGDNXAxZGIf9gsJRoBHVkMpUvNZVZMu/4nxl9oCDSRtCPD
jCmGjQM8uZx7NMYMSvK+YxIjSZ80BAN98vxOoTSec0q0VMc+epnk+iEbINAJ
wgDcTtXIM+N57n5ZO5RAZFQuTkPsv+ouN8S0nPQ5pUTyVPhlGA1uvcTFYA/P
kSIClWqUb1S+hBsSYqgoI5wRDThFGmOTEIVyo0ZZYdGZ0GxG0aZ4h+Z0J27Q
SL56rT+BvdOaI1xZoN/FjzNwZ+tFQNC1vOlPWVLWLsq5DvYeIKjEEmJYMSQC
MiGX7EVe3yU+Sja1oAGdU6/4UvA4+IEzrVLFf3q3XM1xhsikMZRLyV1Ly8gu
gQPCqBBKwoomkHtGxynEGIPgNO9lA3wlPymHHW6173FrGPiYSURQzYYYocMZ
jiISR+wInJgycxkZhIEosufwNTx3SvXCeJZcghGZm+LpLwsougOSaJYTgMdD
BmrJQ9GEQResK3vNpvP8MIGJjVA4ntrRBW79dHCLSEAAEv9wkahVsvMbSfIz
8XyE0VvUIRGILLkYYrTMJhsJ6hoYgfoqLsO3mhWLbecu0S33wPXvELUGlRyD
f2FiHuwYbI1NMBtNSf7QXE2Jr6Z0hJ6Zo7I1cxB9wJAjHjR9nRIvyBsAdMMn
1YoosK6qlGtLWQEnvNy7jv1J1+5DOYcCiJ3FtTiqnELC22A7AIyQcABjCKEf
9iMpQEMYJILwEj9wQpwiBsyPutBRim5GdcwPFE0YI0Eya1jJglRRA7p8YDQW
Cgol154a9bzP2HCkVYgVC9q8izVaDgzexPMbXBgILLJKm/QZtYYCfk3BWr20
eXOxwNQMzKr/GPoF+LuOlmD/seTTsYawdgaPHTKEU0yXuSmzRnFNMAGCDQF6
vUWkT+TstHC7manICxpWyNo+L35uM0D9AKgAZMpIrGjwj8eSDaJEYPWtWxiH
Lb/ERM0O2rmqWhtx6oJI2VEKutU59xor//mhaqZvoe5ZD4Kd2LHkZ0Nkd7R/
w1QcQ8smYjBFmJIQLbjwCErnuu3FxuXGmFtM4kGmRTMg9ojZREI9NpSWrUsq
DkBX3DuAVAIKHg0nd6QEmFw9q0QaW1fWRiPQjnwohpz1aIW3WvNZM/dNCcqL
+3ILUa53krcYUqgRQxcl25vtanyJCwtD63DCKDxIVmz3Q9M73lVDq4yttRBj
PX+9IgQnlItQwoCCAFy4RquE5UHQUuo2/v05WkJYDZwX9L6cqFM7ZCyColSr
dkJHtXoMwHQo/JO4jZBKkCicjKKHwitOJwsvEWJ4UFRC/oM63hr0EHUNASot
xQ2jVpJm+I9oKfpAMskU+OJG1QsTxS1zH9CzkBaqJ6ORuqjQfm5ZGF6c0Dzm
SDZOKyWj8BlF6XFNarGYdpg+n35qdc4vzg7/gALzmUoUkavKsMkG6WmWxsv+
lM3OHAdo3Fbb1OYOekHRocp5+Why0SEnHBaoeCFEOadsnBXOCNiZJCOJGTXy
flXSOHW6vfMrvN9Dm/vE+6iE8ke4E/Y6+xoI5NYqI9AnfGZJANt2ErM53xru
3h0Nr4VFZtSqZhwbXF5Qa7E01bU0ILsEH9mKlQxq0ugRfBLBSqM+YLYv1izx
w+48wmwmKvtEWrYOPmStL4nup+RjgisZwhUhNxugXARhDklrDoLjcgIG8xQQ
SacAQUyhlj7UyDFboEUQZs0DQzXAt2m/0cMA3NapvcFfkteKvOnzOLacFAZQ
ERky7u17hiwjPjZaFYVXJ8N41E/11k+mFAtw/AUSeYnpSZ6TuDcpAycaLdIC
t0p2gyK7zmjYxiq/Ju9l4gem87UucGJUhsLOXCHftJo/9wv2GxRAxI1IIWqa
jk2FT2DYZo0h0JOLI6CSAKk5DJZhSI3DpimBzVlMo5hwQJStibGiYWXjwIMJ
BEx2JUFbYJ1h55muCToceTpWkGYMJe03YexJzqeQEQ4XYrpxSonbRlw+SrLf
1PDGYejQJRoP31XzuLsSCBvE0dPkgxuIqQpqhV0iiUzIuaCU/V+to3br5NN1
8+bv+5+OdwN/NwjKlXdho1atlRu76v/1UoMCPtc1K5AF+PwA4Pfc1n45EJn0
AA5R57Q/7fHT4eE0VbwBdE2KtUP1/HEixn+peA1IRk24FNMhqAUL+qgY8Ud/
cEhxyimOTvSdOri6thGb2SWJz+C76DhqDJm1M8LcxHS75KwT2CN5ZmRtw1Z6
xqalAXg1LpmhZHXvc3IoZ55rRq5kH01wJkZSm5Ip4YMsmga2UA3CDjpljLFf
V3H6K2QNAhMjvALSNX6dTOFzjWKwoyUnY7Kec5FmYRduSE3x1SE1tOwjjZyb
a0Kk+ApI8IwcjBptHdMrQRGwYtIwUK5MBFZ8+SWHauAGEAgvhYvcx5may+KH
UZ1OOIZtjBnf1oDcCVje3l0uOek+ZI3D9gzf033oRNTxVAuCto88YtrFahxz
DWdJ5xwKSSDVbrODyEF9X0SIUTcd72QRgwZLKWsIuVgLK+TdHl2KwxgS9CXP
BcVbgEqjhUcccYNQlMNHov73ZbpYO2toKVuifUuwexHbQJy0kXfOF5XoaJTP
ztdXUUdbcRgGYCPPFpD1t0wB4hQqN5AwmNpfQZkN/uoPk4KgOfi0S9DLNpQS
whuAeEsZJGiDQ48A2D0N+llsVSpfSBaEteRLAQe2wc0MLGF3ZWhWnwKEo54v
9I6OY+Ovy3jMCybcD72D3Wl/pUHRpWjH1I2wEJvzrptOPczdy7WM7Ve4y3KK
eLzKhUZ7ekTQaffprnc1YRy1jrSDUHvyjyJncRVF1lN724akxvWyZmgiAUUz
NS2BbU7xPrMy3BwlL4qTOOZsR/3aNqzAGx4Yv/Jmh/KL7mOrNIFVaBSrpzGy
GMKaYbu3KA5mxGUrUpOTCThGCll+X92Q4I7XYtwUK6WaAzSaEmNmUzDCiYr7
00CYG7Az99bR1SnWCQFYo3bgRjlGC88pQ7cgq6UJzzDPAQAOgkBjap9AVSIG
WOyY5e2XTF2TqXeMOcwuyTmE9myO844YZd0tlFLn60kL6WqiHufM8ec7F8t9
zKY49DBN3I4gOYxNrWQVWDKN6OhCY6REpZB0QAqXS5dxf20LO6yF24Vp0NLE
OChuhZDc2TMg3cbjP5iw7j7OtEYwHkgU5CoiETKeMFBf7hLsulQXcZ1uIFgM
6aM8wnQJKcvu1mqbUvE+NGFvKJj0hwDwTln+brEhiRVOLYMVFZTnW8mYzh4y
0ckUdncfOslIaCnekG3EN7boe9bodd2QXKIg3yw4c6TWoi18WmHomnlC9IV1
a4MUoNYTGRDdCVMr1NHyxlpnl8PuuVYo+iZnRoGDqlZyVa1ljDz9JDkgxe50
3IVETtciB+ZC0BMip2L8b0tSh8jPCubzVOZLFczt1JICOpskuAGdWqBIKDGT
cenB6pBlU4B6Qm9QbpnBYyHjDm46+nvwN6s7QekiOF0MZVXfqAXsgTp0qz6g
Hgj0lgZND2uf2IL9hqT3SVnaPFuRBs5YMyIRJXBEHtTBnAPUJKGLvCnQ2jHW
SE+Qf5GDYjZgnyOOLDXm2cxvPuCIYUdqkk6FzV0k1ritZTZbJvW1Ef5ERwVs
/ZQ1vbpVoATzgg/CMGUQYoMjReBTi5S8IKOZw6fWAMN0WuCK8DC5SJon5bxY
vfyE6Amo/7EA0BN9B5KzKF0Mf117IJnrzGMM7LyPH8maD2mXiBpmvQFUtZQM
ccJIhHhRXLJbKDZzb6LlTMCYOFORLQ+mix7ICqT09UFbRuf6mvCv7g6ZrlW9
zHImUOFPdWoeolXqWjRAFEL7kZjktUxpB97TshiRyUnV39YBrKBgHe9T7SC3
1gYqSVEWbZyTs6V2R3flQPDCAAh0GLgsxr8hAjnu9JR9TgD+U8BZUMmhVCdD
R/aA4fWUSqy6krOTXmBqVuRPFZdUWxq0rWq5oIOk8VhE9XHA163KEkgtcxqu
ABm7UQhYl17e+2g9DvEeRH5UJNlaHVI7JJGUo1QQpIwqUoC4oM4PRWFFGFS1
r6e5KQXcQWsxq7KcASUiNC4RqBWMAbNnITad5serUKicALPiC+R6HhJPy0YZ
UA5cp3V8rNZrPJ1zutp0RrgvJqDCAv2nkEWZl8ixFOoEzo57bU8BAFmqw43H
cQyIDWBiLi6mRaMBSfYPz0zU/nlsWX1I8MquIUkILJl5XXVDQGRtF1HfiV1b
jAKdOt4byKR6o+fFtscspnq2vMfGfBQy1MlaRAS5bgdqYgCbBXEL245uP3vR
nQqEXqZubprX/VSKQ5L/VJYQbhM8PoQq6gajEK/JbDZ8bwKoUqxJQZYX9M5k
V5yw2XilUcSFhsDqgqsu6AEMZAfgA3OGSAW1asM66oFamSjWKPWSsYzABeSs
20dqOuM3ZCEdFaUIVWYKWBFIDXmaW/3U0Hnx9Pi0Ta6QUlCpYnVYcrWwg5Wd
YUTCapj2kFElyelccLkNR2IlGjeI8/kk4E7Dn/Qw3Ocj5bRr6ReTE5+eKNWd
DTlF+lgNFkMQqWApOoqpqRTbYpXnDYQ4OM29MaUGUbJ3ulpyDGd2SmBlJ4EL
Fyssl30q5PIJu1YfOb1K+S1N5Jn5gMg+G8zWJoQjNuVC7RFfSgzJra4DbJWn
kNK3NDBClWZ2iEMii7YNL7LIFFPios4SsqDe4r2wldaOYmxciBgydNSNnbIm
uekGwK1Pho+IV4BWQR0VsSAOigX6bMWY+6BS6IIQnwwpnbEUWui5WYSjjIr4
9MT5Ya3mxb6aMpcpTr3Ql0YMhjeZPpzGnpGA82ApxtFMh4vljc4Kru1Zy4yu
PgumCFEOIIoFVS5dbs5+JZ7cD+fTCVdySk2VDSeESqIB18eB/MhAYRJLZT+D
K2Tlqax4vUZUmIFCxzdNivUEUrIh5DEagcDNNW2zYEXQvyUIaLkKObDBuNZ2
bAvQH7yNQ4KqzK4VjoQUiuZZM1+N0ExIKeJTKKGT2kdFaV3wJoMJkj0dpCWq
zks5tgOIgJDlsXxBpHdpRSBzAE1crHaVw3DUMxzCEE9AynxzPlci3co7BLyz
cynEqahy5w36TdCPc4iiiWr0DZPsmy0ad3cJ2dqUBMfJAThaqv3mQoc7uLPa
RYThHkqq0B+gGPRmN7N4ukAZdmtWCBXEyBQre246bhdSqR1d8RJlbg3fCg5d
eL/eLhaz9P27dw8PD7vDaBLtTueDd2qGSi7Ba+EdcVyp2v3u1x1nuVC5nsOK
6yBUdzCECoYKK7Doq4uPqT6d1qCk1pr7ttI3CbskmjP2KgqPIP1EE1o9OiaY
UUygiEeXl+deyQ92jCVfx11g72xaktGowwpAaJxxRKuvcSER4AnkmoglQmvI
7KcjnDOkOFmUzCyELPWbJAkRnVJe5hV229/KPzRzomgiA8VWOwtgUSAqg/YH
WcWKCHhkK3t78p70LiGi7g0FTxGtISQy16hYAJ5WGt4VMfCuKK1SivBrBsdl
7rGXd5fRIN0wNPu550fD9/2fHRCkG3vNhcR6coe5Y8o8qn0hrxklJAAU1cU2
NxbwPzXkYyzBckDCytoIcodNr5hxtye9KRrzqJXnx40lX2jgMb/HotUPDhwo
rEM+1HPDm9u6XPyGwee/djBCyskfeEojh9BzctoWjaW5mMCbPzj0C4w9xwNu
xcm9OPT81wAR54WRU6w7LLMVcl0EAOM/sea4VK9b59eu6p9Zw4zlUYA4NoxG
43S8ZkgaBOTPjMsKRGjq8pibeFL+s88Obob4F1hR/AdHpuM7Xje4zY8/O750
NZbx0fM/OMqWZZF+cYybHn52hJbN+88PE3zZL49v7alnB6ZLxf+pEZkw29dx
8Weef36DTT285y6efBEE0pX73tNPlLjcLxr55o+NU4QnSa5SOtzKe3OmJCm+
zb8w6KaZIgZJL6bjrlKsJjHldFnYK/1+rAt9rRWHJQnS4DZr3DdegPdKvwdT
ygNXJrDSjHk+LwxO45xolWJAtXBAOMzWrtUaph3VcBu7HBbDpPVG6h4L7lPH
hKBiGQloj/VDJtjrlCNVNs2BSq/kbW4T1/bpJ1zjV2ysei6zzFn5fNMWvbdt
9BZOUDsD93OFM/kERoQd8aWRdcjCSzNRGS79Wj3o9cXjkWlJn4acM5DXxhlH
bZCz1Rw9/Tndr9lOikDJCNxHv+VcTT/SW/5MrE4yZzvTQT5Rue3B4g77TqzG
huFm5UkmOrc5IzfiQ0VBydnQZhOtn0fqlKnj9RFc005raBwt3uLXxZH6+lXt
wLQ3N0OpibmtQLUtKg/3iZftilFJrMagUtxUrRiCHL3YksmpvIbSACR6p+st
QuEAFrA30ot7TXnH6GoGeHPSnS86TTuBj6MN2qedJlU5Kd4Hv1R0eJ87gnEa
FfFeUzPb2D+GhphrMrPGanU33orWwrzEwjIDk8fFvCvsd1P7m7ntOkN4fauZ
4oHnWJHtuQ0tIqrKq3Y1W5iQysiJsrbeMtWZe13TUgYCVuSkfaLWWiw22Wb7
t8W7fqIOx51l1tkkKhCvOp+CoTRON1wcYCGzDHqObWTjrW7d1Z3zduv44LjV
vDz+dOZdtD9fHV+091374AyGsJKaSx02+ZR3q0D5FwetehCCI0bLCvEjhIIP
DUyONTiIARDr/zzpFaX0j31H/lEgww+b66h7u24rJdiSmRXyj+6jkdR25KzY
PidX2/XCxVPMkXqQn8qB4MM5to6EIJBSbsqBbfeCl8DlBH4ik9/DdmCnpglh
2i0hkB+jR/uxIoaRFRmXyS2X9D6o+wG1jOCdrHtiaMMIKGpxhQ9E3gFwt4OW
2UwlYW5YaUoEzhU6hECclnLJIlovIq9JpOaQiCOr2DYoIxRubzQ57byO/9gt
vch+sm3mXON2e8/e4js/xH/tZl/DfneQM+wb+m4jfae0g2t0zy5Nk5rzcBtz
BAlZX+2dhNFgGMLiNnbyjxCewCYrXfOXw70gtD/rbLEPWZrXmRTpxdCztTNg
+4y17XjNH7zQGdiUPQVOxSGByoMrZakt4njKMz6DDQPb3XIYL2X5RyPBJoOT
Cz6zOJap9QCNcj6MOCBCFBnC39RoXdAPFTZdQKST2N/zAzXA+4+4pwhCg3jv
GE2tS3mkbBOXE2eiHB1PGhY3l9xtpjQxr9Nu5vBKJBmJjd7dSFmstxE0m0RS
Pz2Bl6vYc5xVaGRTr0VoHIMrAuJgiHsTQpIsE5c0SrPqaEbR+umZk88JD/04
ofs2shVJGzYC44q4AJ6EuLyCV9jpqeQxKEg5oc0dEYZAMsQK4C8wEGdhTS88
cUufe/WM8YL/UWzgcx2FLIHHBds2Z1pgBFD81Lw0u4vTOymdBXUGXdPZS6+n
+nVLcFiRO+l1nJIx9hbuGl4LSBFXm0v1JlrZALDwkYAdAgJsnM6mlLYCKubL
BlHYKCO6b22BfY0qvympBmUfrqPkIk5xkSEx3hn5ns6qnbW7u8VojLDV1oMY
9LSkjO8h59bZJdapgjOWqIooXqjHsBUTufVQmGZTTmQ8vFRYFVsyhfQsQYHl
Cp0kj13oEmUs86QCbugMmyAOJSSE1m+thri9npdTYyaitmJ5uIcPA+9DoD3g
87xuBWSpoGvalCHtiMyySeGkt7HiHAex2K1kE1OfUTI5zSUxaS6gOFDztvZg
FAMti86mMwxC0J28rEdw2LU17u10h/PqOQJTAqeYP0nbzytVwDhfoSBxlphh
mdIJRRBy9UfZcc0iiq51nRmcbJXhcSYfm2P7JasZ61FLOGoVAZ6DsE5VyAiD
V5dHlFjByEA/0DtdLDs3mWJP7oVGa8fVGmWN8TEaxi3BV+mwUTMeQTqyicc+
JQ7okVXZm6GXRBrX9RwB4hrTGTaPAyqJIU/Qc2bockmSt8diFY0C0vwaVipB
A5fsa7lchxYeFLcSpAaOFoMCktgGQLfokqm4pRlj/8adBHOIxRC2kQg32/53
THUem4lYgKqEewfkAJYaKVeb9m5jjIiGRHc4VfgGhQxi+v98xfT/nI2mWMTA
cwjNuYTSqPcxQDMQX8KIfS2nDgWD2K1xqSNaIDh+QkE397HEf6UCxwWUwpmf
VA7yvuy1+7glHOKm9mNL8uwEZVzzFexYKkkOqcDA/nsviOrdIEn8iqLecj0O
6t2k4gfVaq9aLUddPyzFUc33/VK/Vu834nKQVGqVetQI+vWKn9T74dbWmQaF
W1ixfVDZIjsMLP7O+ADwTLu/b+2GlX5zyYHvkC0nkexQ2sAPykW/XlQ0GJTf
h/X3Yc3gRi8yIDMs6bhiF84af1qNSsPb299regfNUug1w4O612gGFc8r7VVr
Xr11sO+1gzDwGrVG1as0G01aWk1hxrpIc7I4tKAHQf+n58cSMUhGUGQXPA5F
Te+9sOtX/cAv+0E/Ktf8xA/oy9/ee2W/lPiNeqNR7vb7jaCqtsivlAI1pFI5
Lkf1Wq/u10qlSHEzv18Nk7pqp9EI43IpjkvdsOxXadCEZGFHpRnkHlg8syyN
ulcqeX7Zq5S8pORVEs/vekHV8/yGGqjnVz0/gK/V3/3IK9fkPT/BL9SfGpTs
LCXwQr2hGlSss+/1G9CI2kX1nWo5aMh7tYZXKntx2YvqXq3n1X2vVvJKkacY
NPyjX/XCBH4JfK+hRhDLe+WSF8deqeuFaixVgZAfxzrjPlMEEwN+ixIAjclZ
SA1P7z3KckJXP7gK//7mvlyM6VwV2ZXMRSLUr2/+2PqP//gPG8oOw7FAewBO
UCzutQ+Pzzw0ZVztfTxuqdv7xtv7+Kl1gl9vbT1+P21fvTtLWo83H04ebvb2
mkfRxUN9r/m53zx/GH8YfSx9O1gGzavHUeXsU2eaHO/9/un2pBkM3zbbH+6W
W5/flmsfmjd/p/7aZ/vP9KbG+izH0NoOr6CNQyQHz0G0h1buBEEAPiPix0BG
E21FZ7VS9BtFte1B+D4sv1fbfnXZcs+rww2Q6QtQijmrY3UMkppfrVTjil+u
VXx1UhSD8uuKK1X9iq+mkzTgj19WbIx+elDSQEbdOWqGRag6mrlVVoRNQ1lQ
A8W5uUN1JJNqGPpRKalVavWgnJR7YVCrJkm3W613fT8sN3r9cq/X7/mVRq/c
LZWjfr0WJCW/G9TKvjqLWHGzh8gBCdLfGsPjjAaZLayKHg9cEPIIj2n+3qtU
k4bf60WNehwGflgt1br9Rr2U9LtBtReUgn7SD2txvx52k3K/H1eqfjX2+7VK
NYr7pVK1Sg2l772+rwadREFQCWuJX6rHvuLpiZqw4ulhEsZR2Gv4pVJYrSRR
tRd3y/VGXK+Uu1FcDbplv+ywFDOXTRylXvcqMbIMH3iAX4dffOAoFc8PvUrF
SxrAZxoV/CLSHKUBh77e85K+FwcecmJPsWKvEnmNSG2RF4bwRpKopVFt6PeU
+BcBH4tDaCCseqUasCBkbYnXR3bWC7yS4mDqn6HmRIoM6sDjkrLXV11WvKrv
VWPVYN+rqX9EwL4Ub6wSC/Tlvb7iTD1Fol4UeOr6UFdSovhf3fNiNbaKV0tw
nAE2nlgcLAq9XsPzSxAKXlWLEHnVnhd3FWtTF1Hs1SteuetFsVcNvK5avPIa
j/uLWJxxz8KZLkrmkPp4A68zPCPD8DrHh2fNy6uLNnO64UG53dy7OW42bw6a
o6+Vr5WrZmtw9/n7een2+Ft8fT2bh8eD/Xdf7u9OV7Pvw3brpnT/bfAufOzu
nfbfdbaSxWDeOCuNbg7LZ/3r+eI0vNlrnrV6l9X2lw/vmuXy+Zd3x4Ojm4+r
6nD1+XT1LZmlVX8Y314tlzfdz22XQ2aGl2WNVa9lZRRvb4BO2fGefrqvFiH5
+I+trSNdFm4T0gpjm6N8k1BlO+iKuTA/aVUzkwc2JnTLA1+dBpySP/JISh92
h2SsyPB6JSWNITEIHrmN1uWnX1t7Qb3aKh8oLttoVhu1dnm/Eu4fNKutWhju
+a3gIGiHtVZQb1aqNb9+UK2ElXYrrO019xvNVqvxqzFTbuwjCFv1kmpH8feD
akk10g4qQbMc1GrlUjM4UGyo1vDbjVK70ajVy/X6frC/V6rV95uNhnq6XoE+
cum7WuR8Ntyqv+jmHk4Pb8r9d+XHtKl+Bm+vwsnS/37dGh+NvpX2fvt2k3w+
fRx/W1bCD4eDwd3H38L2l/1SeRSdt9LPN8nW4cNUvbfX2rv58P229O578yH9
sPdw9aU1KB/vN4+vm82TbvPhOG51jm/30vSm264ftqLoa+XsavF2/LjaOnl4
SI6Gyd5w9O3he3g1qrXiahj9/mGv0/vQHPRaMKzmiT893mu+/fjVHybp/jio
V9q9fhre10cPW4PVVXjX6l2NT5L7va/dZlKd317cXP++/PzpoT2ptd9FHx+O
Hy6ij2l/vvLffgH74NFtZ1m+OKseXUftrc/p8Hx0Uf798fzd5XltfJt8ace1
r9fnj4vJ6dXpIgkqn1bNSnCzd1r+bW/86Sh5e/oNBnV8HF1+OD6bbL2Nr1TH
d8O3553mqB9Obj/cvvv4ZXyQdt5W/evV/de7z8HDLD083EtP4MWPzesWLvrD
SXe/dXy7lbcwm9YF16P5ee/4pDs7PAz715df61vf3375fnAaBh/829+uR+3B
225/OP1+PTlJmpXm59n11fVicvaw3z71B0F4f/M4vT6t39SD67fdo72Hul/Z
Oq7fXX+5+3pVvT/4NHx7dH1//244j2rT5MMyqJ5Npld3t73R3dX8zh9/XXa/
3a9G5cO9wd9fL7BdYu6HbWh02IsVz8MQ7Bpe4elJUT6CubLdkQFlKLYFy4Ki
MugYyo0m+vQThLgQOgMFubDCyD7B52AmyBJhgzLwcJBXYpIbAp9oydE4GKmY
NdVEgF4Vn4R18B9BlvPgFi/FXqiu4T7cpeqi7vleXKXv1UXbr6l+vXLZqwVw
vZeqXjdRdyt+r971akqMKHlhBb5p+HBDB2UlDdD36v2o5sUJiCO1KrSsbuxI
XfYBfh+q9xtdlEzwTxiB7FItefUafa/eVy/ESqexn/JBIIHvS+r9ch+66Hbh
ZlcKjR/BnR5X6Hv1vlI31RCVgKHEgHoNBIoSqkjwfRn6b8DLjT7oU0EEEpRS
epQggd/D+NU3SmEreyV17ddBkIpKoBTB9xVYvwQHF5nxlZVEQv1X1Pv1kCbE
E1EiidL5fOpfyUCg0qnFUbINNBGjBNdToht9r94Hqc4HWQ4WqgS/BLG8ryYG
e6akN7VsPSV71UHMUdISj69WR0kvqoJ0p9TAfgU2GoUh/L4O+xei6tnDicSw
f0p8q0f0vXpfiX+wxQmsn9rluAePdOl7td+gfEY9FLZQPFPdqSH6tH8N6D+E
wSk50qxPZA4iSlyE/MjwiFOq9EU11jANOh5HUBcTLEnp64jXQ4jL/3QSZlnT
+4c3Y2EgHgCQ0L/bxJ3/owQIeoceDUi4ts6B+eG2ycxBj1fW2gOR33mcvTT0
fHXtefVDVOnCH2ROXe7PduiHYTEIiiX/Mqi+9+vv/dK3HXpTjztYnziMCvTD
9yKf0Sv2g/YRl1fseScbVlPpOFroM2aY/1YWoYlDUQfWmQUsA5s8ypsmA1up
WL+zg8xo8n/gYYjceO/cIFoexfeDTbvC769vTCXUA4rWXiFlH15B/b8SEL+q
2CRj80N5B2CJDJqUtbWV2qbVULQOr9wtnMeJseb/QIwA+F75vfdwH3stIfNL
IfNKA5+2mbP5MVd4zov99VHqd3PGGufOq2s/TtsH+UC7poopY1VRIxupRc2C
H3zv/aPZ7oAtRv0vCOv/bt0x9Gugl3T9Z33gVb3AwfobOQPP+h+wDYci8IYz
Pyg+wbCFiICaSpqaqjlsDm9H50cboPBd9QtPeyNBhblzpZs2/ydnrlbiB71P
xOT7ee9bD6vJTqaTmMeoD5a/Tss5Y7RPb/ZmWSN6nf9E72ZWzbf3RT/63nsi
GRMiD9UJ+IPezaF3Pd6cYebSexCvL6UkRdFrz1G4PKkGiGfjPijQIbkP/7Al
ofyf9THW6CTwvZv/OI1xHZSPGjDccZ1q7Fg2CQ1hgcxedldg8zZ29V8oxNEH
zpnNHML1tWyU3SfC2vrj9tFZw+GjVnIOO4uSnvP0e1uy3PTzD484YfFTa6/A
7BB+57u30di0dd763dvQpzRZJ9EUHY/xiORVej5XoilTKyIK8PoZOXiDNemv
0/MU/cQNJLg+iDLq9itVvKSnhWRFHGCVLYHs2+t7XZTmy3UtJCtmVVF/AlK/
vG7NU/dDFGohWbWmhKywgQbaBlpx1ePV/3/reY2uFr/yBq8GrcURGHzDGXxd
ndiSvoNVb0rJUKNUi6cWWq2PkiO6DX37KO6luk3K4I9TnfdxuvWy5m6K4sHa
jTtXr3jdAAzefISBRfQDYCVRAv4Apeqo7VCjDOqaRWSU1LAHR7seahbhKKmk
bSouEWoWkadkih4KpzGPPym+hN9H8H4OfxL6iOpeLn9SfAm/7wL9kpLpqpKl
8l+mSm44HxlV8j/rlAjbErvx/yiU/6NQ5iqU/5CrIo9CNuqUQDaKQmQOWX7m
/KyTRyVzwzv3Zg55VNbJSXOXDNziM3tPTNVW1YJG3twMGXy1tFcjWmdIYJ0K
8hU05N6eeIIyRPDfwtDFpLDBoFDL1zNpr7JCTW0TpQCTMgYF9nztGbHEvk/y
f8Sc4JzKOjOkdVOC55nQgYw5wWj49rVlvbTRnFDPZVAsy66LsPVNyiKM4JXm
hOwd6vw8Z06oZ1UzW6zNGeu6NmYuhRe0wHo+idAAbC2wPekppXWs7kn1G+O5
kaJV30Q4Ya5ezZJD/s9rFK0GE07uhm5WtBp6EdckFm+9j/8q8YX+9ZzqmD2n
XZuQsvpHjvLRzbJqIynlKx+Oj97yfW1vcIqxix68YBs99LYL7XkPPT35L3jo
uYEf9NC/4NSmyMofdWtfHH9pXrbX/dpX6Z/0a582D7+e7G3Fjydve0fVs6/B
bVq5Pbs93vP9y/mH8TQd3JfGg6A/XIzSjwk6wfN84Fs/4gTP8/Vu/YgTPM8H
vvUjTvA8H/hWvhO8/zHPCZ7nA9/KOsGb7WDQumtULq8uSl8P4mF38G75bvHl
phq9exf85p9dt4Kvb1fLYelTWAaH+dYmj/kPLWKex/y1DvOtTR7z1zrMt17w
mOfT72tc5nZETp7LnGwXTnQ1BOlDKZYf4Tn0Tob1aJRtKxwaI6Etbz3B/S7c
0G2NHKka4dFodMM0nd3OIc+SojPRYgX6Y3M+mE5CqeVrHuNxEO5tihh0HKKH
q9aDcs5QMaALQKAAw7KI1CK8kg/xvP8qdnRz/GfDbBofBnetrYPmRb/b6PUm
g9HiaB5dxGFlebRcLZufP39ZnAxnH/y388r3j+V+1Du87jRv49b1+ez48ma4
SlbHn847W6XB8f5qUE9qaqH6wae98tuP39Kr297x90+nsy9Hg/Hw5t3xcvHh
bjmaxNO9m4d5+/DokU7f58F1a4uO3+nH1ufewcHn6adW86F1MGi2xg+nraPB
3fD4c/fj4eHj+d5gPB69vfzyMZmlvWF6evRYnjzczK63eseN0Yf4YbJcjNPV
56tJ6/PxUXMA7bcWJ63m5/Nh0Die1JqVRfLp4uioezZ/96F3fDo6mzUnBx+G
k63aw5fw4ejtb+Wr64O0dref7n14+3geDuut0/b1sHYU1Rfno6+Hs28X5av5
sn0Z3wbj2/bH4++Vq/i0fvluy//9bWX6Nbg4WgbB93r32+8H+x+/NuLLdPCp
f928PBoMviH/PvwMg2od3q06+9/eTUbNL2Hl+P67vzX48LU/K3duklXw7bbb
vl8uDtJ5UGmfJf5YTedqr1m5vT0czMJpFN0PquODq6+9g9OHvb29q2W7/luy
1fjUu3v7+LBM+28Pm4PR3rzy8ctq/m60nJUeHz/fH3096Hz/3gxvo6/J9Kz6
eHV40d9vHx1X3y7j+5PvXy627ivT5uNgWYs/zKKvZ9/V6t/c0PXTTPX1M0tP
j4ftw9XjbXr5cPNhNkvugk6p2j06nm/t79XjD/XDky+T1vm3ztf0Q23+bX56
hyxyr9kezJZ3N91vwbezZHVeuT69+r17NekczqKrzn5lEZ4Mt86i3qy+f7fX
Gn27iMJeqXn6+ffO/teo8f3w9ub3x++/f+lW0t7R/u+Xd99XF9+uL/qXv9Wv
qkCab9+9PVlszZe39XHt6zSMbzudg9X1RWd52fkWVxbjdydfBzeHr2eQEAwE
2Z3zcdzHuqwYEgSxQB+JtZyzXedEkkg64UmxHwNEfN+wIklUtqMHtaGqXgq7
/bBaDaNKL+yGlSCOS0mvHkZxr1RuRLVqtRdVSg0/qNTrflAq+X4YV6IwaFSV
FNntJTTSZgKJfEcn+wdcrtAps6nzWZDlxSb/VZdkzhlYIy7Vet2wWqvXklIt
Dur9blALa41Kr9wLG7VKxe+XGpEaaSUI+o0oKffqNb/a71ajWi3pVwJzx9jZ
WbKAOJJnF6ZX8avVUl01FpeCLsWoh37SUPtc63bL9X7Vj6pBXKnWVLdRtVKv
9f1SKWg0Gt1uo19vbAWRUjXLYRz16+VKudRP6o1KVHrlzpLoub6pzh0j42eR
VA89qZUhCrxeK6khNOIkKEWlfqQWy680ajU1+jAslf1+UIkj9Vyj3/OTepwo
rapU6VVrvf5fsafZMZV6Vb/XrZbCeiWphmq3Sv243KiXKrV6NfGDoJdU1Yd+
tZFUg7AU9vo1RW1JUkn6pSCu+qUf2M5s172atZMN2cl6tVEKy/VStZY04oqi
b3X/hGFST8p1v1Hpq12uq/HVkrC/VWnUK90gTLpRP1DHIanE5XKpktV0Wrrq
ZYfq7AlixNNPlIRR7KVJkcvMOGqOW5eP8rKwsC+G5+lmrRwESFtCKILtpyf9
gFFnsDbd8ULkJqyXPrRAE5yYP8zI3rZEKqhrl0kQk6GNozsDldSH5Lo47UUz
EGdUC84HUOeqv4ypzJBB29sQ/OtOQsljUo5n8bhg+QS+fTcbReqmzAlib+97
p+1Op3kokeyI8/9AeZoGxHgwn/ZIVppiokbRK6oRJkv85T4exFj4NMV/TqZT
QK/eeilm/mE2OGxekChx8lkJ8pXh95vVnxHiD+/C46NvH74Gzdvhh/1SI/64
VPLG8Oqq8XDVbHw5uumOVp2ju71PZydX75bph8be/bL523Tr3cH9x4Pl4fVp
96TZb76NZ7/VvpSPPi2a56O96/FV/fOnfjVa9t9GneXk6HMUtT+8HV4efD8P
P51e+yd7862zkzBalSu9r4G6jT5nhfi8KHw39YizG26JpPncaSdIb5NLlV9j
q6ATW+SThQaMKBvfsyxC/gvmDx6na85xwhX8YNNLNDx1lqYTtIIBIdL7GbOI
Y7xkC7bOXXL9CTnRMsaKmUl6AlabsWHmG67IJrPRhvneKwfa5QRWTx6KMWpv
DMixV9qeZDZa6pVWzWy0TbUEGx2VPAzsYeu9+lPKWu+DHwvICF4dkEElGO1E
B2rgObLKOiiC58Iw3IoD9Hz0fAhG+EIIRvhCCEYpG4JRyg2k4+giU+FvnW58
en2TPRvClEZxsoBYJ0zQhwKkdKdBm9qBVaJjVyKHi/GcOLsSjZwtLGnqrFW9
MmadVXzYUbCMaycqur98L6lB+lYcYp5pDzaAXc3g/qoEsBdqtdT7fgJJbEHf
q5uQ67gCrmDVcgypW2BsL0depaS9RklXLWXGDRSiG66aeN06nF8w2YoR0g2V
BNdO0vMqXSSMKmTHNaqQz9Y1MdmQSFuGoTViIIooBoqIfe3aqZXAheejC7gc
gEdYbXqpp107ahHimleLMO+tBmHLVUgA1r6VqAYzVsTYiDA3N4F8tnLPhPPU
vV4COW8QdFCFiUVqbl1tcS+VoX/1sppCPfYqPdyMUBu7Ido8yLsdngkvyQkp
Wd9n3FnNudZ2mHZW84e1Haad1c7ytR22dhZoslLz1G5UA9gM9e9aDc+Wr49c
NYYP4A9+X63CIa0m+shV+/haGVup4CM1sfmjGzcBNqe+Ua/VGvhsST2u6Vh9
X8P0QkX6fh/DK+BvTcehbj/BzivW90DH/H0Vh4iDh2cDTcfVENgSfFzi9vEN
TaYwvwT/lO0HNZn6EaeUu7EfmkzDBsWAOFydz2Gt/nzIR91/3mcCZPqcz6Th
P+8zQZ9MbshH8JeFfGyg30zIx38WFRNf+oeW2NdiPTaQt2cEnOHvRhn5H6rX
VK+XNtdPXv2R4D8rRHddNFEPb5Q4nWDdrK/8eYlzLVbXdpq7EmdG2MyL1PVf
EjYtdkC/vhQlvibSm2DYnJj8VwqaTmSsK2XCzzOSZm2TsJPvkWbGlv/zGkmz
9hz9ZCXNmt67HD90jqT5X8ZW6V+Gul92RTuhZ69wRTeyZGw4+OY4WF38q68p
m0ieQCREMAGIP6zuJSy92ihVK92kXI4atSgJEr9eLqv/VaMugDgk1W6pmoTV
aiOMkyiqhkFUj6JeI+iV47ARR35tK643yr2o26vGYRL6cdxPenG155e69UZQ
DqKw16v1unFYrsTVuBZVqpVy1O93414F9Kx6o5u1MQ0niOrtGoy4kpjtthLu
TwU/RQ4TD1aOOYq9WfhEThcE78NnndcIgImwtJr0yjXZRyPCAhXT5n00WnLF
zGgyAeR20AviR6+/HM8IiIvw+sj/RHC4eTYiZ2TaQDQbzF40ELmWocf2zWHz
87T7I6YW29ewJc6GDb6GvZU/C8gpu/c1Ojzwj4/6o+PDyujb9efBt8mH+61u
Z8+PDq8G30of7m/CL6u4s/d7/7Cx+nY5PWkN/YH6fdz/PF2oEY6+hV/8m+sP
6bevpycfO3vLbti42+oefvm9lZ7c7A3a3Rb4mFp3B4Pxp5tpePqiowr8VFvG
UYXDnJ0N98LOl8bn45vh58a7r8Pa94eb49HBee+gef7lIjys9O5uK83L753R
eW3eSj5vdWuDk9/OH7urx+7t6PvhanD0+XzyW7QM4r3f55/3K5+/zEbn7f1J
PJ5PkvHdfPboH45vW8n07vHm98b371sHi9Yg+r2jxrD89PWg0Tn43M6YnZxd
yxwECtQogt0XI/AtAzSWZo3ln3w4BESLn1szraJ31fv1KP4/7V3pciJJkv7P
U7DqH1s1EgV5Z5bZ/uCU0ImETmzNpvOIBKQkE5EcQmX9Lvss+2Tr7pEXkCCp
uqa6emzHeroFZBwZ4ecXHu7gmBxgKlfP+Y/fU0SZN0Z4tPiJJ89O0dKD5Dy3
W8IUdQSy5kwsut0dvQAP/cND1mKSCxPkHc8bmcn29Gmufo7eIfomykQebgTq
UxJHcL15fcltWURUyutZeqEF/AJ8iGzIOSgF7CjqEKQ3t9VBWtqYiCUxXkFF
aJXIpIPPLkPfTzAT4xW8U9CfsoT5VVwKUwX1VmGJ8WpIGBVtYOAi2scOv0Cr
JTaqDqLCwKegc13BCE0dNJKbGKPQB2gxV8BIackt6gLmobJZYowq5JbINqbD
gl5sG0NiFT0xRjG7lY1vBlY6qDNXRxPaVRJjFNSoJeDtX4dCMcEkxBEzkbQS
muUyvZaikjGNUdcplFBB1xssbbDJbRMVqUqJt2Jj1FRw5rBmEsN3BZPX0r7P
/1jzPextJsgK0to5aXZPsihrzt3D4odRVup1F8K6bh9FKdaAYtftlXVgdWW0
k9QYikfZNCpjkuWPb/T/02mYf50zzyT4OGN9ZyKO82PiiRuKxeYYcyFOeF7I
v445+C+5ExU4fI+EkSEjeZtt7TB69ifwGUriKNgvldDlVG0kx5ipRC4UVtY7
yZbFN2PLqm+udtwK13zbWuescaTGsjPgKan5uXBywJUqhPTZnPikOP8nVihn
aP2C3WTzjI1xttnkBU3yCWAX7AqSuShh3gKm4+uYWtGRcZIIcdBHNU5gwCT0
MWyJbhvYGL4soVRDjBSo0KZbKgLsLzCqBttaKHTSTIf8bcxJH9VdNsPTuu5N
N4Hi6rcEz28GzcdvRty7JWQ+J1Q+J2TNC/x+yaM9iIP6sazslK0e1aczp9ix
dOKygznLwBlHbNrAj5hRQiN0VUOAVmWIAkFrF/HgqBWQDggfmBp4TI5KsLCD
X+JLEDeANwdtgbYwxb9eKHQHJmYYo4zAydiwUHgti3Bi28F9gLe2RBpVpxxq
Orp1poxsJbrxUls4J9FEXxKmKxn4DYwEotSAzVRwNkDFsoEULQDlYggBqrDx
LB3aVRExgieBdeBvWcG2Il6Nw1bwEbq1VFwU+BUcqUKD5RhJSXeOE/unlNMN
ngJHVRBodYExRcSugfyAJWFrBWfFEpuL0c34KM73Bxpb3MgqzUVKwF4yWYg3
RgPb2mJ3wUTV+Hoqz3ACIi8SsBV+l1yR8BABBJ9VwcQjKpJPorPga+AnkHoI
CNh4IKDhaUKisyxgDgs3HDgTyAkcdQL5E53luFE+GMnGiQAdCEBHRqJamIVT
xGQoNvKRRWn8DCdRLSIdoRgGkiuQgERZALVKoloUYsIKoQ9ANDBFVY9PKFC1
MEIxLQtzq1iUeMWqJKpHpysJFqUcVCjBKBCsrUKPiT6AmYMqBpkD/ORgktGi
aWWz5oC8AUJ1MPUgpihEBFKNMQ66fKMjaQuk+R1CX6G76LQNQUDU8ELR/s7r
gWu2mvO+U3EkzaytpuZeV9ppq20OxAk+tqLETVutsqaieTrqr9Gl53wjLTsM
BeRgVuuvRfCCtllpqV1nD2Z+lO/7k/iPf4D5xhmLg3H5qBjxxhqs/tM5ZIeV
RrwTv9pvlYyfhwTzyzEV/yILx61yWeZNaHenZv/DjMe/WIH8VjixiKY6qMt4
gOKn34TP38mev1GZnaxBR8te6E6xznwUgE0+urPx1EE2g26qb75Eymzou0Gq
e8SsxM5Xd6DQgKRdngKKTnPAn8AzXBF1Ej+ycGjvwVSS4/ymsP6g4iUxOkkC
1eWCnRSHlWX130f7L7T94XSIRz0cMOf5z5Pu8geuR9v/FcPDfJvtfHwlviDz
T4HKXkTxe+YM09hPybhz4rPg/FVtrjAPJ8XkYc5pWxhpk4FiC1WgU7Z89tlk
m6gVMc82TbTJCLGlaVE+tpgNMuZMzFRAW6dYhSgOa4wkehKyF0FUSdXaNawq
WQs8EZDwuGtt6WU6l8OjLTLVRJuf/sWmID9+s+l4TwBjPKoswGeR7oqCshFt
PJFcW7p0bgg4HHg84NfBYkHPYIgBCYKvVaimO0zFV4i7gbGhxxb97X8vJQlx
D+Z30FN+n6LCpQZm1vHYdCvKiIY03504O8ZurC1j96Vo9fp1i6Tv3eD14rZy
2L586C4bOrMPjcd6R749fGpJl+rR4kx6unjaH90P2o9X4is7f+6dtQdXo6PX
l8db3bop9+9fLwp3/dqZrnTOhrdDQ6r23GN3cGJcjl5c59zv1R5ZINw22G1v
wC6P+uatqy2D8fOVeie0rtXzi4nbLZh0r6E36NV613f79YV9J/Tl1olnNV+q
rqK+mgtNLY8nl8H5vlV9fRkHg9lYNU6r2vFd+XZc8QrLnj/rPkoDu/VYabjP
p9eH/YlcnmmCdrwfdu6s6WXN7Z+5h0b1or1YTG5qz2Grabze7bvCq+M9BAVr
0JIq1f32cBq+vFTXoxV3wca0k83q/b8IL06YNXOL53f8Gx5wft8OFK/OaBUo
TsKu/wqsOMzSLzNftuHFElpSiBQzYjGBslFKiVUG/weTy2TonIJAFlwUIU6a
3wIzeLsUrSSiywcCxTDiLCeRVaYQVmdKKHYNwnk0KbHK0InUsU9GPYMcFtB9
TkwsEOSKjPLeFjG5uE64gKanJpaOMh1EDcguUKUyQ99TYSkkxlA8gAxHhEBF
Ua+D08wSEwt0rKL8GAB3SzaLNadgHcCVc2PpPgjgdt8CcIW1i94RgDsdTIJZ
fwC06SBJke1GYj3fTch6FnluRY6bkADHGbcCeGaHbxBFqaYQc1eMFmxrBjd4
UyyvHZ3SoyYGNttH74I5WUrO/x82xfPRr0nqON6Ge2t51M/bJN4L5wP+J3/f
nMRQ0UB8dlTH6JOqwPPamsOUxq1uMFVxfYPezWD8U3oFfp3divnS6WNcyD8l
g2zwZHHV+fggd5JcXbH/UfS+Afvy6onp/ZtMSRpBQZwLcTQFIVDTxN01RMSa
YEnABoTJgEUJJqErouGZ4z6grahyqZnvO4ARZDNK9eIiKuY4aNwqNvg5yJAG
kZJGJihYTJKxYnNFaaTzB1s14jcJZQtRRMTwBiIHGwMbbHEvWseNB5qUyXDG
PZIILtTRWoV+QdT+JERuDYrbrtJWoDg6BTXcOHEYCQKqZAOEKhhoMyP4Lcex
TsjKYIPbOlr7NoF4BmUCjo4ukOPAMxMpAbAF/zbxH2hvuAnHgdgENmEqhrEJ
GnIKd11iZhIJGUbs16VFtNEDiqJYkZlgtYFxwB0E0gCWA2pUwfmQE6axiWNE
Yl3YVpifbsa/I9OAKwS8Z1DiKUwsZKBItdJ4PJ7a2KFaFzBXTUEdJCoJIqDj
WQtSJ3RhECaM/o+TIAKOiQHQ4LIJdMAjOEgoEftTsDTFR4pE6QjTiziQIie+
vkosYXxn0ud/dygue9KapzP/BBSXG8BHvLEGxf10DtkBxXHc7E0o7ldhqk0o
bpXLdkFx72W8TShulRN3Q3EfY8/3QXGbqvj7oThhKxSHsI2MO23auE1AL2A/
gFkGelWnt1cI9cF07nj+FLXSdLziAa8EepwZSE+wCnYlH4376BBvoHFbx94K
yG1p8eMwOb68f2sQC+1xCyM7bAcNOGASjLengAOdDn6tCson1/0wiPWx1f9u
HEt4P461DjK8H8DaAAD+PIBVqR4e9e1afXHWHpvKvX9Vbon1ednsHneeeqPr
UKjNA+3ONP1OZ//sfv7iXtq35emNbLdH/VtBLpx07pXT5u3F1FP3qyfT3iA0
Lyz/5bYyeqrXFs1Dv/x0cfHa7vU6F08nV522dNYbPC1vajdDdz7dnzwXxsd6
czHrVVqCcNLpHs+E5/KpfzIKm8PFjX3RtB+M6+rz8tI2xxcnQnuujLzn3uxy
pvaX9+zh8kooXNbvTqbKnemZldaR83ynvtw2jlxNMFjbuz9h9Yfbq9mZEnwU
l/rXxTF+Ly61K4Dx18Gltp+nY/QJxcXjvTcO/a7jUopKWDYFCaBSk+LzdjRR
8FaNi/6ObaOiA79cBYGdus0Opdu0ZFSE4P45GpozcpqdGE8gRTyHsXgQpYSi
RbRTj9hFp5hRiJBLQQqaFRvRdKlGxjFFCdEtXaPKcpWsveE6qHZlqu8iaegI
gq3lSIm9odp/JSgl5eIXPxyUWotd/GmgVDLrvLPuvwMolUf6OaBUdAWWg1L5
mNRHQakNjsoFpd7mLv4np7Y8RnsTkXqT//ifUZ2THFbMgaPey5Q5YNTmYfRH
wChGMVtglmPQKllPjoEuGCyiTaAPNAF7hIM4irobjBLzrWd4QXCJLAmhHDBz
MUzMokWnfyt0ks8YglHMxttB7wOjxHUDdpNAthADEsEbSBRsNNPQGwKjDCPM
NIxXhAWR+FqZ6EUKdHKJfpPwFyFRHwkKA+I301JqQGyuhoEPro1vCXQLPrel
JPwLdAC2KDghFQr+kEzcJt1JsV+6KqkzyrBHtaMrsPRGwmbQB9ZLZWgog2sM
TAZPGWkwPqymruAo4J3qFcxFbsHOpCn20Wm10V22XFQJ0BijRs2EXzDARsLN
gYFkF6/BSlIc7I/8Iovo+AsUJKkTdbng+adOs0AJs0HnmDpGc6pUDVZMU+zb
lCIZTHmbnDCVPNe4tBDyq4SNweOAB0EYAvvaZuyD081QMuF1ulkPDA/ePdC4
KCWurqsi5yk/JoD/3w6J+oFBYSDo3w4KI95YQ6J+OofsQKKId95Gon4VptpE
ola5LPMmGaeVErFnMKn3suAmJrXKk7sxqY8x6q8UHqaRlhNNVHeMcAluPggy
/qE6OG/YJbOCFwOMuGw2xjsxNHcsC0/fKhhMnQ9IfbT/NwCp/IG3olF5j//o
8LC/OxQFRplJ4ayGRXY5cSXsEwgRgW5XiBjc9mEo6gNL/y+Kp8oBor4rkmrD
4//zQNSrfnh0adcRiLp9PnmozO8fe61O+VV/sZt3vQtRESvHvca91DQX9tOh
2Awvaqedsqb2G8vzo9Ar9GrNx/02mz2cXxsPN3L73Oj3KuJrlwdIPfTHoyPp
zF2aZ40T4eHxbFT1ZfX+QRSctrpfXoRnhburxqUfSneX7r5bkW+HzkNVmDc9
4frisNwp7/vitP44q9U6N9edzuXz5WU96MyMs8CClwgGh/NK4UQX/eWZ6vRY
u6svjk5fe4/GcqqMu4GjCvWr13bZCm4XHw6QOqyf/WJA1OqMflUgqm+PdgBR
dM8L67JocbneFSCKGXSPSqMrSJyz0rB1vKDokvdDl1hA9kgsvviAFoqu47Uh
4HAb7yDSiQN6aYmFgt6Ti0aQRnlkQHVjYjA5MTdA7CsiuUMyyi2DX7tN04hZ
ZGKA0QE9O3RXCiSXkgJReFlSwftLJt7lQu/gr8Sd7B1tfhzutFZ05KfhTskk
MuY08MffB3fKo/Qc3KmiZ3CnHxMMtcFAubjTBjPxX3KrnBCb7YSZvof7+C+5
A3LGXIedvp9FN0EolLXfD0LhGT4Fg4PNicecJh6HIQTj4jeM8ivZMn4pawgt
7gShpC3msknRQ3TQjefpLnptro7rDAPo/PhdobKudNPlfSCUtG63blLLJmW8
gT0JBp7ygtupE1YGchVdTJnqdFXQHNOl6BnwKMF4/KWxJ1opeBcrjYKC1YD3
sPA7DG6wHLxp4QgpD1M4Hi+5CR6IQekNtbRwHd4iZojkiXRxWjHQsRSUhHOA
YSwBfUNY3wp5zq4dZx1DzoHOweFGOnNxrrKDDmNUl1jiOSENlXJ7ORgsp1P5
xUrm7pRElGjjKI6OECamPMyUVGN4pRsmp1CFPbwbC+5rJqekjl0IZFzjjVMX
YURNSxxfYDS8l0ORGExCWAHse7mSOL7Qs0qBzyYFs8hEw5HspzALF8FcRC4E
yqJn4EZIaTUwg7KWucb/Y095yjXbPk9Z/mjsiXhjDXv66RyyC3siT/VN7OlX
YapN7GmVy96HPb2XBTexp1WefCMe6kOM+j7saVMRfz/2JG3FnpiJMBCG61bQ
crZ0fG/MfFIhtI5ittF90fFLPb47B0Qh0q1/0cqHnD7a7RuQ08p4W5GmzFM/
DmCS/v4AE9hDjGLuMSaQYRwaoxQl8G5A/tCPRYeDmv1hgOntFf9uXEn6YHxT
BiP4TlgJ/fcfACstDg/7dgNhJdW5uB9Y7aNq9bE8rSt6t6FVhs2r++WrPZpZ
HcsvO6LiXvfGVa8rP10tR+0bszAvG8LxVJ8Kt1c1537ks16ZQ0oLS5/ddC/n
p6PTue1f1cKH4+rIvGlIp0Bii8H01pu07s2XQpVVOn75Zf4y7Vlz4/j89ZJd
eiNlehTcPVZb5/L16dHD9Lk29ufNwa3JlpO744ebl+l976p870hP3cL++P7x
vjettu+M8fjsuC0uH8uXr0cvD8uno4ueMt/fqBCwC1KKEvWFmc2JYB6qe0Vm
S5h5DBMCIv94WebaW2GevY2+5gI3IQ4i0Ii6JmtnDW3ai9GmvViQOkPXZRMg
xxXECDV/+AWkEkgyexDDXbwSij0IhrwieloThdsjK0kYh37RCiJhMJcjRCGi
S5xZPOfoOxoMsyfaMM+QjxS9x9jEgh+wHNHqFP+rKBwUx/AfmSddHMGfohDh
YreRFRUPmV3tGFMjgG0LU8gRU1CDiDf+NF9g4U9Y46/F5joVNLt8UsiB1pDS
FKVPdzNOFciSVlNQa7VqvdUQmlpN05stqaariqBrkia3gPmWdrO26No3875+
XPbYzfmNcFXVzsuvTRFLifneqT7pnnY6yq13Gc5872K/WX856nb6hw+HJw/7
hYfjV3mmtvYbDa9Ru5go51eX99PyyXHblUfy6MI7WdbLs+dTa+yfHvfO/Otn
KdCMw5fatdN2Ll4HR4V7tyqNn2/l0fVr620eefdmGeK7N8sQf8ZmGeIbmyVq
YPk0qk1VbyoVoyKK9aasVAW5qahG0xDAuq2LhqJ8+fJlSwfwS7WlN2DLDRl3
Vm/Wq9eD65OXo9b1Ve/wxBtKJ+dH8k1Hxp0dvJ4ei3NTah3q5fFo3O445aPy
yAluu8pt7fR0UWgZ7f2qcyx0F4rauXoYnvQe6/Oj/r5o+c8VMZSk6vFxsKyx
l1pbvjypXreunpbsVex7zrHnXC3DwultX9POFgu374kguBVNvLOH1bN3SML3
7jLiZO/cZXj0J+wyjPLGLtdqzUZVUWpGFXZaalTrstKQW7LR0A340JKrLUlr
NVs7d7kuSLVqTWwJLb0p6K2aJit6paHXKqhM7Wb9siuz45t++7AsjWyzfdo8
bo1Hxzrxc8/wtBMwT5y6NzJuzMtyTz0rK+D4et3D8eGsoIrSw8i8Z6+Hj3rl
Ua7tn8yEsH/tHAe6di/cTWZjzassjpfjnheKws3CUbWR8RS01Apj7lH5pGAo
DWEWesP7i+ZIN5eXx5ej3uTRVU/UudG5WzyfvUcXFm/G/QlWQDicDR0TzJHi
p6pjjsnCaqNewYWJMEzKfXbVqoP9B6YzCnf8oKqShgUrZ7yjUj/q6I8IFgpn
VggWM/cTXFIUaHnawxB0FphsJT+YjGCEOZbHGlG1s7RQVzhFPCBjooVYtYkf
+4DqwdzB0by+fYPJ4MT++IN+p884NyzE2Z6i+sPcv74DtARdDJg3Lg7jF8RZ
LQYBz/g7648ouXMf+gHtGlXzHa4sRpzVLgjRmobxzIlDU6NUzfE3QFlIvQEs
zHgAmjhJpIhVJyZJBc69s+v2Ho09wnbgXCypNlU84hcsBpWpOYpphml6SXdf
wUQtJfU9Pn37BgRcYvxjsh7QLP3u80ERRo2ayWDQJ43gw1oT+uZz9GyjWz1l
fdNe8rlHY0ZfJZ04oVny6Lu1vrI/RF3WoUveWW1iDv1xEIChMZvMYWehP2aX
+Ad8fmUZsueAaytxv7IQL6vrkM0yu7IQ95l1eMkuQ9Qiuw71xhGfcx0nt7YG
K3Neffwdr0hufDN5Of5GsZiOkVesisa/Kk0XQYlA03i0BFCi1cBv8Fwbv8Bm
JjOdEn5AcDXz/jTP6n3Oc8x84V3jI+jLbD4C/kk8ejxTNUq7yuu30RJuPtLN
PBJmH2kxkzN3koD/K8qAouuZfUp+TMswF7GtGz1bSp6Ne+mmjTsTBsIHMw3S
8tTJKA5nYMnTHozjn0tzcXU1u2mKypTivvJe9vCUZ0YIA2Fwe9hVKD6V6LsS
fZcyAK9ui9TFJ1VySfJF254uChA3T0qe1B0Lv64vbZKRMowXmEoshJtLnK0Z
j50i67QbUSuczNApZbLQ5uxRsgA01s7XWGuZzD9Lry7YECWYSSkcvmDK9M12
Fz4rdcAZWusggK/RR4oblYr1bAbOLSWaPxe708nMxl74KnJKQNc7zBaHAJ+o
wYuw4wqtjhyXZA9TooAvqHjhEiXxhM2DCOBbSQpKa5z+WMr8GPd0E4JvBvtB
gQtoKw0xcX0wjvCItPph1K4Uxm8T0Q2Q4NfYXouojxtj0c8pC7Rj/XfFwCcc
ol+ZJQ5oHGtImHP0xDpplGCRqDBBRuTiUaqEJiInWvyAZQygPzxpLeGTsfSO
mTGChJDx+J+llHFLSXnK5FW/Ri2L9ai4xnC65I2JAO3022iODPiZr3nEOhm9
UV1RFiQw58EQVgXVEDOfEkqfgK7yg2ksxtMnUWFhUcltvze9Q3PEN495ffwz
fu4g0SbRD2nTFgi1VRnwNe4OlW5GxRy8T+lEG7Xtdc8aygFuFrjrV+1O86wh
qJXNPSNiT6CEXcvXbjSrB8XryRCslkazC5Osdq8VIskkDGa1W5Cd3TEQmjtk
k9W+umT70BMRSYf0zZpMxumMJ7CydnTIbn55+mJ+oXY3SEGf117Z9DyG4qHe
qq2JslS0x2NEFHe9HLO1N03WA7pbllIXhSrlUrcO32mOvFDt0BEfehjTKPYW
Y7SNDEYLHZscdcyO2Bp6DP0tYrAGlUYdMs8hKoUe1+mPVhU6/v2f9Yvz7sVp
8/finht1QSoKJHaJLUFjBr63XHvhiAbX3jmmTCnDSVyqS6uqJ6/JmjCNP5XW
lHVSDSRnza8YyEk81F99CiVn5aXVivrFc0CQXfxRvgdodtrBaDzjhnuWYbND
JmIyGXeVHzOqOKZ3Xi0nVae8fA5SE2jUNVMk+yKJqsCmKGZS/cAzMHMjrltv
t0Guj4KEN9p9cJXAaXIC8JumRTYC/7d+VSfVGOkLEIW2KKdjNjKP7kVvg64G
9AouELhrE7Lj8HOJfyZuiFR1PJfV+sF8wVpxod/12Zn0mjgi+U0z32c2ynNw
ao4o8IaPE+YOjMInnf0Ve0R9XO+20lIxIbejh/4c5L3z/i6L8MamD5p1imAo
rWvxKFmBTJHfWOfgNBArvmaT0dAPvKC/LNYHpo9A8Lffpum3JZt/+0e2NnEY
jFjsxyKmG/Ky1GBkgGaaD4NZiEbDkDgtfu5izHx002P3sTgw5xjZz3z0BSfB
nHfAqwEF9izyDdt5fR6shV/gfGHpsAouFW1Fl3LvynTABFPlveLCjCYIfieZ
R/hHNJ//DLPEWLTMkKky2sJBrMP5V1SeGXq98JIzDm4ZbukeJxipr5XHSajR
96sGJm4ivKjDj3/IvxdluYL+PYx6zhbvHjVe6I1hA/gBUaqNccH6mQTOzOY7
sD52xgzNjGqOrGF/BrvikTs/YqZfHM28KSpI3ES/H34BQm+v7ehBcUhoRTxz
are3xbjdA6PR9mbhcM68Jc0l9XNStZ2qbD49XIMAdolUSlxJJrdl5CbRQ/Gh
wF6mKNqq5ySknhPM5Azow43PvRss0tLFOviLe8iNe2eNOp8PTK6PB3GwUOC0
gjVn4fIhUOQQ+gIyIB4vE/CBYlcwPvNjBl7IO5v+njzFIS8asOlNbvUbaUJP
frDwcQZbXmKPNo62CZ5cm7RP1DL0Q1g/xKiQvZMDlYwfhO5MvF4HyYEQnc/k
vUl2VisWSAYkRQu/P0HjuMPNotgqiV46jmIR9jitRCaO2d/BLBk7KFJ0EXfg
HoQ0d9hMlHfT4YiFcTOSD9Dd1uaRzOZF3X8rVm18PY85fcK8QkQPTf8p6S9i
TVxrUAUgz8wRUSWqIFykYI2NsB2Q5hhhteF05dH+JJiNEYMMZ6PIm+9OsSaF
X2yZsPCedwCr5oOFVTwxB37xcOh5IPmSL49mYFmjiD1mrjsBJX5qzg6KD2Bh
PJnF8yEQAvw0C6cgj++o3hhtbsececW7YIZg45fs292xiY+GRGAPEmYEbQQb
ixPGF5u4NiKb1pDDAlXfwVGPh/MwmFOTFbCTw67JOlAFM2diLkLsajSDURJ1
QQMQlGkW/dnIgmlggB6pSDwJDyZYRtQHCYOE+BUYYMKeitUpLCP8ANpw4sGO
1yaMObg6oK0asD7XwWQaHIC1PbGLjeVTCG88gNFgVQ7NoYcqewwCEz4xnxWP
Atcdmf4BX5/kUw02A5Z1MoRWV+Z4AJpiDv4oDBp4wNQdD2Z7AMvreUDqQ5vR
8Gj6DswF/34IBNKdAoOgoKXZPMFSwxwnnNk6AzDGx8WrL//7P70hsBOIep/i
94vNyQR5BhxTYEJkCWu5RlvffmP0TMnj6PAfPMItVbcEDQzxVjPvK6PJgS8m
44CilskmAfqkBV8MQwacFwbePGdIUtjfvvGplUTBQDyzlIQzl6NDXh5KR+KD
BNVKI7FSoUbnHFtGqAFZHrccnbftzVRqxuE8054E/nKEYAVopM1ndT6vxE5E
3AzEFszN9sxJIktXWwnyWit8JwpR2dGGzwqRmGwhQTxv4lJoFiEr215LiJYw
c7SegZTDKexRn+2agShGsyZnlao2nt10r8tn1YedzfjEz/mZBxYOxJB8pFJw
xy9uThu7Gkt8pWLLrViO7bFdbRRqw424cvHmulXSYVU8j2u1OBBlZxcRCUQo
DPhTQUjnMaiXzPd1EVEGLwUbo2422smmS0ISeDlGw5Kft/cnV7L9TdgoAI9g
ZwO+XaNTWAM2OgVenMOzZFBtIxFZoiYIFxDmPcyLBCt+at9+3jWwFs30qIpd
RjyaLtmWsTVhdafzn5NEg6/rCS1C4ltm/KX8hops8AHqRVTURXf4QqoEHEpR
/u9/di5OH0DXukCd2VaaIkfElHWggJZgSCycCb0U/g+k9iWUXAsFAA== [rfced] Please review each artwork element and let us know if any should
be marked as sourcecode (or another element) instead.
In addition, please consider whether the "type" attribute of any sourcecode
element should be set and/or has been set correctly.
Note that the following sourcecode type is not on the list of preferred values and is not registered as a media type: text/x-csrc
The lead-in text sounds as though it should be marked as c? Please review.
In addition, what does "text/plain" refer to? Is it a media type?
The current list of preferred values for "type" is available at
https://www.rfc-editor.org/materials/sourcecode-types.txt. If the current
list does not contain an applicable type, feel free to suggest additions
for consideration. Note that it is also acceptable to leave the "type"
attribute not set.
-->
<!-- [rfced] We note that some instances of _ and ^ may indicate a desire for <sub> and <sup>, respectively. Please review and let us know if you would like any updates.
For example, should ** be ^ here (in text, <sup> would display as ^):
The memory size m is 2**encoded_m kibibytes of RAM.
-->
<!-- [rfced] In the html and pdf outputs, the text enclosed in <tt> is output in
fixed-width font. In the txt output, there are no changes to the font,
and the quotation marks have been removed.
Please review carefully and let us know if the output is acceptable or if any
updates are needed.
Also, please review the use of <tt> for each term, as <tt> seems to be applied
inconsistently. Please see the XML file for more examples and update as needed.
Some examples:
<tt>Hello, world!</tt> vs. "Hello, world!"
<tt>0xFF</tt> vs. 0xFF
<tt>SHA256</tt> vs. SHA256
<tt>SHA384</tt> vs. SHA384
<tt>SHA512</tt> vs. SHA512
<tt>packetprefix</tt> vs. packetprefix
<tt>Version</tt> vs. "Version"
-->
<!-- [rfced] Written Numbers vs. Numerals
a) We notice that numbers under 10 are represented in both written and
numeral forms in the running text and in figures. We suggest choosing
one form to make these consistent; please let us know your preference.
A few examples (see the document for more)
Original:
one octet vs. 1 octet
five octets vs. 5 octets
eight octets vs. 8 octets
one bit, two bits, seven-bit vs.
4 bits, 7 bits, 8 bits
b) "Octet 10" is the only capitalized instance in the running text.
Should this perhaps be "octet 10" for consistency, or is the capital
form correct?
Original:
The above formula is in [C99], where "Int32" is a type for a 32-bit
integer, and the variable "c" is the coded count, Octet 10.
-->
<!-- [rfced] Terminology Questions
Note: if changes are made to the IANA terms, we will ask IANA to
update the registries <https://www.iana.org/assignments/openpgp>
accordingly.
-Packet Type Names-
a) We notice inconsistencies with the packet type names throughout the
document. The names are capitalized in Sections 5 and 10.3 and in the
"OpenPGP Packet Types" registry (Table 3), but in the running text,
"packet" appears as lowercase. Will this variation be confusing for
the reader? The packet types are listed below; please consider if
"packet" should be made lowercase in the IANA registry to match the
running text, and let us know if/how any of the variations listed
below should be made consistent. (Also, please keep in mind question b
(hyphenation) when reviewing these terms.)
Compressed Data Packet vs. Compressed Data packet
Literal Data Packet vs. Literal Data packet vs. literal data packet vs. Literal packet
(Note: should the 4 instances of "Literal packet" include "data",
or are these terms different?)
Marker Packet vs. marker packet
One-Pass Signature Packet vs. One-Pass Signature packet vs.
one-pass signature packet vs. one-pass packet
(Note: there are 2 instances of "one-pass packet"; is this term
different, or should "signature" be added to it?)
Padding Packet vs. Padding packet
Public Key Encrypted Session Key Packet vs.
Public Key Encrypted Session Key Packet vs.
Public-Key Encrypted Session Key Packet vs.
Public-Key Encrypted Session Key packet
Public-Key Packet vs. Public-Key packet vs. Public Key packet vs.
public-key packet vs. public key packet
Public-Subkey Packet vs. Public-Subkey packet vs. public-subkey packet
Secret-Key Packet vs. Secret-Key packet vs. secret key packet
Secret-Subkey Packet vs. Secret-Subkey packet vs. Secret Subkey packet
Signature Packet vs. Signature packet vs. signature packet
Symmetric Key Encrypted Session Key Packet vs.
Symmetric-Key Encrypted Session Key Packet vs.
Symmetric-Key Encrypted Session Key packet vs.
Symmetric-key Encrypted Session Key packet
Symmetrically Encrypted Data Packet vs.
Symmetrically Encrypted Data packet
Symmetrically Encrypted Integrity Protected Data Packet vs.
Symmetrically Encrypted Integrity Protected Data packet vs.
Symmetrically Encrypted and Integrity Protected Data Packet
Trust Packet vs. Trust packet
User Attribute Packet vs. User Attribute packet
User ID Packet vs. User ID packet
-Hyphenation in Packet Type Names and General Terms-
b) There are inconsistencies with hyphen use throughout the
document. Please consider removing the hyphen from all instances of
"Public-Key", "Public-Subkey", "Secret-Key", "Secret-Subkey", and
"Symmetric-Key" both in the "OpenPGP Packet Types" registry and
the running text (see some examples of general term inconsistencies
below). In the majority of RFCs, similar terms are not hyphenated,
even when in attributive position (i.e., when followed by a noun),
which is consistent with the PKIX documents and RFC 4253 (see guidance
for "public key" at <https://www.rfc-editor.org/materials/terms-online.txt>).
Please review and let us know your preference.
Some general examples:
public-key algorithm vs. public key algorithm
public-key encryption vs. public key encryption
secret-key material vs. secret key material
symmetric-key encryption
symmetric-key algorithm
-Feature Flags-
c) We notice inconsistencies with the following feature definitions
from the "OpenPGP Features Flags" registry (Table 11). Please confirm
how you would like these terms to appear and we will update
accordingly.
Symmetrically Encrypted Integrity Protected Data packet version 1 vs.
version 1 Symmetrically Encrypted Integrity Protected Data packet vs.
version 1 Symmetrically Encrypted and Integrity Protected Data packet
Symmetrically Encrypted Integrity Protected Data packet version 2 vs.
version 2 Symmetrically Encrypted Integrity Protected Data packet vs.
version 2 Symmetrically Encrypted and Integrity Protected Data packet
v1 SEIPD (20) vs. version 1 SEIPD (1)
v2 SEPID (27) vs. SEIPD v2 (1) vs.
version 2 SEIPD (3) vs. SEIPD version 2 (4)
-OpenPGP Signature Types-
d) Should the signature types that are listed below appear as capital
in the running text to match the "OpenPGP Signature Types" registry
(Table 4), or are they case insensitive? Please advise.
Direct Key Signature vs. direct key signature
Key Revocation vs. key revocation
Primary Key Binding Signature vs. primary key binding signature
Subkey Binding Signature vs. subkey binding signature
Subkey Revocation vs. Subkey Revocation
Text Signature vs. text signature
-OpenPGP Signature Subpacket Types-
e) Should the signature subpacket types that are listed below appear
as capital in the running text to match the "OpenPGP Signature
Subpacket Types" registry (Table 5), or are they case insensitive?
Key Expiration Time vs. key expiration time
Key Flags vs. key flags vs. "key flags"
Preferred AEAD Ciphersuites vs. preferred AEAD ciphersuites
Preferred Compression Algorithms vs. preferred compression algorithms
Preferred Key Server vs. preferred key server
Primary User ID vs. primary User ID
Regular Expression vs. regular expression
Signature Creation Time vs. signature creation time
Intended Recipient Fingerprint subpacket vs. Intended Recipient Fingerprint signature subpacket
(Note: are these terms different or the same?)
-General Terms-
f) Throughout the text, the following terminology appears to be used
inconsistently. Please review these occurrences and let us know if/how
they may be made consistent.
algorithm ID vs. algorithm identifier
Armor Header vs. armor header
Armor Header Key vs. armor header key
Armor Header Line vs. Armor Header line
Armor Tail Line
ASCII Armor vs. ASCII armor (also ASCII armoring and ASCII armored)
Encrypted Session Key packet vs. encrypted session key packet vs. encrypted session key (general use)
Encrypted Message vs. encrypted message
Fingerprint vs. fingerprint (when not "Intended Recipient Fingerprint" or "Issuer Fingerprint")
Key ID vs. key ID
Key version vs. key Version vs. key version
OpenPGP Key fingerprint vs. Open PGP Key ID vs. OpenPGP key packets vs. OpenPGP key
(Note: should the case of "key" be consistent in these terms?)
OpenPGP Message vs. OpenPGP message
Packet Type ID vs. packet type ID
Public Key encryption vs. public key encryption
Revocation Signature vs. revocation Signature vs. revocation signature
(Note: also 'escrowed Revocation Signature')
S2K Specifier Type vs. S2K specifier type vs. S2K specifier
Secret Key vs. Secret key vs. secret key vs. secret-key
Signed Message vs. signed message
Symmetric Cipher vs. symmetric cipher (capital in RFC 4086)
symmetric cipher algorithm ID vs. symmetric cipher algorithm
(Note: should 1 instance in Section 5.3.1 include "ID"?)
symmetric-key encryption algorithm vs. symmetric encryption algorithm
(Note: Should "key" be added to instances of "symmetric encryption
algorithm", or are these terms different?)
Type ID vs. type ID
(Note: We notice that Packet Type IDs (e.g., "Type ID 7") appear as
capital and signature type IDs (e.g., "type ID 0x10") appear as
lowercase in the titles and running text. Is this correct, or
should the signature types appear as capital in the titles?
Transferable Public Key vs. transferable public key
Transferable Secret Key vs. transferable secret key
version 1 vs. v1
version 2 vs. v2
version 3 vs. v3
version 4 vs. v4
version 6 vs. v6
v6 Key vs. v6 key vs. version 6 key
v6 Public Key vs. version 6 Public key
v6 Signature packet vs. version 6 signature packet
Version 6 Signatures
Version 6 Keys
g) We updated the following terms to reflect the form on the right for
consistency; please let us know of any objections.
cleartext signature framework -> Cleartext Signature Framework (1 instance)
CRC-24 -> CRC24 (1 instance; title of Section 6.1.1)
Detached Signature -> detached signature (Section 7.3)
EAX AEAD Algorithm -> EAX AEAD algorithm (per [EAX])
Elliptic Curve -> elliptic curve (1 instance - not part of a term)
GCM AEAD Algorithm -> GCM AEAD algorithm (per [SP800-38D])
OCB AEAD Algorithm -> OCB AEAD algorithm (per RFC 7253)
non-legacy format -> non-Legacy format (for consistency)
Public Key Algorithms -> public key algorithms (1 instance)
-->
<!-- [rfced] Acronyms
a) FYI - We have added expansions for abbreviations upon first use
per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
expansion in the document carefully to ensure correctness.
Cofactor Diffie-Hellman (CDH)
elliptic curve (EC)
Elliptic Curve Diffie-Hellman (ECDH)
Elliptic Curve Digital Signature Algorithm (ECDSA)
Edwards-curve Digital Signature Algorithm (EdDSA)
Galois/Counter Mode (GCM)
HMAC-based Key Derivation Function (HKDF) (RFC 5869)
International Data Encryption Algorithm (IDEA)
Message Authentication Code (MAC)
Session Establishment Data (SED)
b) FYI - We updated "and" to "with" in the following expansion to
match use in RFC 7253. Please let us know of any objections.
authenticated encryption and additional data (AEAD) ->
Authenticated Encryption with Associated Data (AEAD)
c) Please let us know if/how we may expand "CSF" in the following text:
Current:
o Reject CSF signatures with invalid Hash: headers
(Section 6.2.2.3) or any other Armor Header (Section 7.1)
d) When "PKESKs" is used, is the meaning "Public-Key Encrypted Session
Keys" or should it be updated as "PKESK packets"? See the instances
below, plus 1 instance of "SKESKs".
Note that when an implementation forms several PKESKs with one
session key...
An implementation MUST NOT generate ElGamal v6 PKESKs.
As noted above, an Encrypted Message is a sequence of zero or
more PKESKs (Section 5.1) and SKESKs (Section 5.3)
e) According to the Web Portion of the Style Guide
<https://www.rfc-editor.org/styleguide/part2/#ref_repo>,
once an abbreviation has been introduced, we recommend using the the abbreviated
form thereafter. Would you like to apply
this to the following terms (with the exception of
Section 10.3 and any tables where the terms would still
be spelled out)? This may help the reader, for example,
when they come across a section mention that says see
"SED (Section 5.7)" (currently, that section only
contains the spelled out term).
String-to-key ("S2K" after first expansion)
initialization vector ("IV" after first expansion)
Symmetrically Encrypted Data ("SED" after first expansion)
Symmetrically Encrypted Integrity Protected Data ("SEIPD" after first expansion)
Public-Key Encrypted Session Key ("PKESK" after first expansion)
Symmetric-Key Encrypted Session Key ("SKESK" after first expansion)
-->
<!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed.
For example, please consider whether the following term should be updated:
whitespace
native
In addition, please consider whether "traditionally" should be updated
for clarity. While the NIST website <https://www.nist.gov/nist-research-library/
nist-technical-series-publications-author-instructions#table1>
indicates that this term is potentially biased, it is also ambiguous.
"Tradition" is a subjective term, as it is not the same for everyone.
-->
</rfc>