rfc9580xml2.original.xml   rfc9580.xml 
<?xml version="1.0" encoding="UTF-8"?> <?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) -->
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!ENTITY wj "&#8288;">
]> ]>
<rfc ipr="pre5378Trust200902" docName="draft-ietf-openpgp-crypto-refresh-13" cat <rfc xmlns:xi="http://www.w3.org/2001/XInclude"
egory="std" consensus="true" submissionType="IETF" obsoletes="4880, 5581, 6637" ipr="pre5378Trust200902"
tocDepth="4" tocInclude="true" sortRefs="true" symRefs="true"> docName="draft-ietf-openpgp-crypto-refresh-13"
<front> number="9580"
<title>OpenPGP</title> category="std"
consensus="true"
submissionType="IETF"
obsoletes="4880, 5581, 6637"
updates=""
tocInclude="true"
tocDepth="4"
sortRefs="true"
symRefs="true"
xml:lang="en"
version="3">
<front>
<title abbrev="OpenPGP">OpenPGP</title>
<seriesInfo name="RFC" value="9580"/>
<author initials="P." surname="Wouters" fullname="Paul Wouters" role="editor "> <author initials="P." surname="Wouters" fullname="Paul Wouters" role="editor ">
<organization>Aiven</organization> <organization>Aiven</organization>
<address> <address>
<email>paul.wouters@aiven.io</email> <email>paul.wouters@aiven.io</email>
</address> </address>
</author> </author>
<author initials="D." surname="Huigens" fullname="Daniel Huigens"> <author initials="D." surname="Huigens" fullname="Daniel Huigens">
<organization>Proton AG</organization> <organization>Proton AG</organization>
<address> <address>
<email>d.huigens@protonmail.com</email> <email>d.huigens@protonmail.com</email>
skipping to change at line 42 skipping to change at line 54
<email>justus@sequoia-pgp.org</email> <email>justus@sequoia-pgp.org</email>
</address> </address>
</author> </author>
<author initials="Y." surname="Niibe" fullname="Yutaka Niibe"> <author initials="Y." surname="Niibe" fullname="Yutaka Niibe">
<organization>FSIJ</organization> <organization>FSIJ</organization>
<address> <address>
<email>gniibe@fsij.org</email> <email>gniibe@fsij.org</email>
</address> </address>
</author> </author>
<date year="2024" month="January" day="04"/> <date year="2024" month="May"/>
<area>sec</area> <area>sec</area>
<workgroup>Network Working Group</workgroup> <workgroup>openpgp</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document specifies the message formats used in OpenPGP.
OpenPGP provides encryption with public-key or symmetric cryptographic algorithm
s, digital signatures, compression, and key management.</t>
<t>This document is maintained in order to publish all necessary information nee
ded 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 forma
t and methods needed to read, check, generate, and write conforming packets cros
sing 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 specifies the message formats used in OpenPGP. <t>This document obsoletes RFCs 4880 ("OpenPGP Message Format"), 5581 ("Th
OpenPGP provides encryption with public-key or symmetric cryptographic algorithm e Camellia Cipher in OpenPGP"), and 6637 ("Elliptic Curve Cryptography (ECC) in
s, digital signatures, compression and key management.</t> OpenPGP").</t>
<t>This document is maintained in order to publish all necessary information nee
ded 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 wr
ite conforming packets crossing any network.
It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid security flaw
s.</t>
<t>This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in OpenPGP) a
nd RFC 6637 (Elliptic Curves in OpenPGP).</t>
</abstract> </abstract>
<note title="About 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 document takes place on the
OpenPGP Working Group mailing list (<eref target="mailto:openpgp@ietf.or
g"/>),
which is archived at <eref target="https://mailarchive.ietf.org/arch/bro
wse/openpgp/"/>.
Subscribe at <eref target="https://www.ietf.org/mailman/listinfo/openpgp
/"/>.
</t>
<t>Source for this draft and an issue tracker can be found at
<eref target="https://gitlab.com/openpgp-wg/rfc4880bis"/>.</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="introduction">
<section anchor="introduction"><name>Introduction</name> <name>Introduction</name>
<t>This document provides information on the message-exchange packet forma
<t>This document provides information on the message-exchange packet formats use ts used by OpenPGP to provide encryption, decryption, signing, and key managemen
d by OpenPGP to provide encryption, decryption, signing, and key management func t functions.
tions. It is a revision of <xref target="RFC4880"/> ("OpenPGP Message Format"), w
It is a revision of RFC 4880, "OpenPGP Message Format", which is a revision of R hich is a revision of <xref target="RFC2440"/>, which itself replaces <xref targ
FC 2440, which itself replaces RFC 1991, "PGP Message Exchange Formats" <xref ta et="RFC1991"/> ("PGP Message Exchange Formats").</t>
rget="RFC1991"/> <xref target="RFC2440"/> <xref target="RFC4880"/>.</t> <t>This document obsoletes <xref target="RFC4880"/> (OpenPGP), <xref targe
t="RFC5581"/> (Camellia in OpenPGP), and <xref target="RFC6637"/> (Elliptic Curv
<t>This document obsoletes: <xref target="RFC4880"/> (OpenPGP), <xref target="RF es in OpenPGP). At the time of writing, this document incorporates all outstandi
C5581"/> (Camellia in OpenPGP) and <xref target="RFC6637"/> (Elliptic Curves in ng verified errata, which are listed in <xref target="errata-listing"/>.</t>
OpenPGP). <t>Software that has already implemented those previous specifications may
This document incorporates all - at the time of writing - outstanding verified e want to review <xref target="upgrade-guidance"/> for pointers to what has chang
rrata which are listed in <xref target="errata-listing"/>.</t> ed.</t>
<section anchor="terms">
<t>Software that has already implemented those previous standards may want to re <name>Terms</name>
view <xref target="upgrade-guidance"/> for pointers to what has changed.</t> <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp
14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
<section anchor="terms"><name>Terms</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUI
RED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECO MMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be i nterpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<t>The key words "Private Use", "Specification Required", and "RFC Requi
<t>The key words "PRIVATE USE", "SPECIFICATION <bcp14>REQUIRED</bcp14>", and "RF red" that appear in this document when used to describe namespace allocation are
C <bcp14>REQUIRED</bcp14>" that appear in this document when used to describe na to be interpreted as described in <xref target="RFC8126"/>.</t>
mespace allocation are to be interpreted as described in <xref target="RFC8126"/ <t>Some terminology used in this document has been improved from previou
>.</t> s versions of the OpenPGP specification.
<t>Some terminology used in this document has been improved from previous versio
ns of the OpenPGP specification.
See <xref target="terminology-changes"/> for more details.</t> See <xref target="terminology-changes"/> for more details.</t>
</section>
</section> </section>
</section> <section anchor="general-functions">
<section anchor="general-functions"><name>General functions</name> <name>General Functions</name>
<t>OpenPGP provides data confidentiality and integrity for messages and da
<t>OpenPGP provides data confidentiality and integrity for messages and data fil ta files by using public-key and/or symmetric encryption and digital signatures.
es by using public-key and/or symmetric encryption, and digital signatures.
It provides formats for encoding and transferring encrypted and/or signed messag es. It provides formats for encoding and transferring encrypted and/or signed messag es.
In addition, OpenPGP provides functionality for encoding and transferring keys a In addition, OpenPGP provides functionality for encoding and transferring keys a
nd certificates, though key storage and management is beyond the scope of this d nd certificates, though key storage and management are beyond the scope of this
ocument.</t> document.</t>
<section anchor="confidentiality-via-encryption">
<section anchor="confidentiality-via-encryption"><name>Confidentiality via Encry <name>Confidentiality via Encryption</name>
ption</name> <t>OpenPGP combines symmetric-key encryption and (optionally) public-key
encryption to provide confidentiality.
<t>OpenPGP combines symmetric-key encryption and (optionally) public-key encrypt
ion to provide confidentiality.
When using public keys, first the object is encrypted using a symmetric encrypti on algorithm. When using public keys, first the object is encrypted using a symmetric encrypti on algorithm.
Each symmetric key is used only once, for a single object. 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 r eferred to as a session). A new "session key" is generated as a random number for each object (sometimes r eferred to as a "session").
Since it is used only once, the session key is bound to the message and transmit ted with it. Since it is used only once, the session key is bound to the message and transmit ted with it.
To protect the key, it is encrypted with the receiver's public key. To protect the key, it is encrypted with the receiver's public key.
The sequence is as follows:</t> The sequence is as follows:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> The sender creates a message.
<t>The sender creates a message.</t> </li>
<t>The sending OpenPGP implementation generates a random session key for this <li>The sending OpenPGP implementation generates a random session key
message.</t> for this message.
<t>The session key is encrypted using each recipient's public key. </li>
These "encrypted session keys" start the message.</t> <li>The session key is encrypted using each recipient's public key.
<t>The sending OpenPGP implementation optionally compresses the message, and t These "encrypted session keys" start the message.
hen encrypts it using a message key derived from the session key. </li>
The encrypted message forms the remainder of the OpenPGP message.</t> <li>The sending OpenPGP implementation optionally compresses the messa
<t>The receiving OpenPGP implementation decrypts the session key using the rec ge and then encrypts it using a message key derived from the session key.
ipient's private key.</t> The encrypted message forms the remainder of the OpenPGP message.
<t>The receiving OpenPGP implementation decrypts the message using the message </li>
key derived from the session key. <li>The receiving OpenPGP implementation decrypts the session key usin
If the message was compressed, it will be decompressed.</t> g the recipient's private key.
</list></t> </li>
<li>The receiving OpenPGP implementation decrypts the message using th
<t>When using symmetric-key encryption, a similar process as described above is e message key derived from the session key.
used, but the session key is encrypted with a symmetric algorithm derived from a If the message was compressed, it will be decompressed.
shared secret.</t> </li>
</ol>
<t>Both digital signature and confidentiality services may be applied to the sam <t>When using symmetric-key encryption, a similar process as described a
e message. bove is used, but the session key is encrypted with a symmetric algorithm derive
d 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. First, a signature is generated for the message and attached to the message.
Then the message plus signature is encrypted using a symmetric message key deriv ed from the session key. Then, the message plus signature is encrypted using a symmetric message key deri ved from the session key.
Finally, the session key is encrypted using public-key encryption and prefixed t o the encrypted block.</t> Finally, the session key is encrypted using public-key encryption and prefixed t o the encrypted block.</t>
</section>
</section> <section anchor="authentication-via-digital-signature">
<section anchor="authentication-via-digital-signature"><name>Authentication via <name>Authentication via Digital Signature</name>
Digital Signature</name> <t>The digital signature uses a cryptographic hash function and a public
-key signature algorithm.
<t>The digital signature uses a cryptographic hash function and a public-key sig
nature algorithm.
The sequence is as follows:</t> The sequence is as follows:</t>
<ol spacing="normal" type="1"><li>
<t><list style="numbers"> The sender creates a message.
<t>The sender creates a message.</t> </li>
<t>The sending implementation generates a hash digest of the message.</t> <li>The sending implementation generates a hash digest of the message.
<t>The sending implementation generates a signature from the hash digest using </li>
the sender's private key.</t> <li>The sending implementation generates a signature from the hash dig
<t>The signature is attached to or transmitted alongside the message.</t> est using the sender's private key.
<t>The receiving implementation obtains a copy of the message and the message </li>
signature.</t> <li>The signature is attached to or transmitted alongside the message.
<t>The receiving implementation generates a new hash digest for the received m </li>
essage and verifies it using the message's signature. <li>The receiving implementation obtains a copy of the message and the
If the verification is successful, the message is accepted as authentic.</t> message signature.
</list></t> </li>
<li>The receiving implementation generates a new hash digest for the r
</section> eceived message and verifies it using the message's signature.
<section anchor="compression"><name>Compression</name> If the verification is successful, the message is accepted as authentic.
</li>
<t>An OpenPGP implementation <bcp14>MAY</bcp14> support the compression of data. </ol>
</section>
<section anchor="compression">
<name>Compression</name>
<t>An OpenPGP implementation <bcp14>MAY</bcp14> support the compression
of data.
Many existing OpenPGP messages are compressed. Many existing OpenPGP messages are compressed.
Implementers, such as those working on constrained implementations that do not w ant to support compression, might want to consider at least implementing decompr ession.</t> Implementers, such as those working on constrained implementations that do not w ant to support compression, might want to consider at least implementing decompr ession.</t>
</section>
</section> <section anchor="conversion-to-base64">
<section anchor="conversion-to-base64"><name>Conversion to Base64</name> <name>Conversion to Base64</name>
<t>OpenPGP's underlying native representation for encrypted messages, si
<t>OpenPGP's underlying native representation for encrypted messages, signatures gnatures, keys, and certificates is a stream of arbitrary octets.
, keys, and certificates is a stream of arbitrary octets.
Some systems only permit the use of blocks consisting of seven-bit, printable te xt. Some systems only permit the use of blocks consisting of seven-bit, printable te xt.
For transporting OpenPGP's native raw binary octets through channels that are no For transporting OpenPGP's native raw binary octets through channels that are no
t safe to transport raw binary data, a printable encoding of these binary octets t safe to transport raw binary data, a printable encoding of these binary octets
is defined. is defined. The raw 8-bit binary octet stream can be converted to a stream of p
The raw 8-bit binary octet stream can be converted to a stream of printable ASCI rintable ASCII characters using base64 encoding in a format called "ASCII Armor"
I characters using base64 encoding, in a format called ASCII Armor (see <xref ta (see <xref target="base64"/>).</t>
rget="base64"/>).</t> <t>Implementations <bcp14>SHOULD</bcp14> support base64 conversions.</t>
</section>
<t>Implementations <bcp14>SHOULD</bcp14> support base64 conversions.</t> <section anchor="signature-only-applications">
<name>Signature-Only Applications</name>
</section> <t>OpenPGP is designed for applications that use both encryption and sig
<section anchor="signature-only-applications"><name>Signature-Only Applications< natures, but there are a number of use cases that only require a signature-only
/name> implementation.
<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 implemen
tation.
Although this specification requires both encryption and signatures, it is reaso nable for there to be subset implementations that are non-conformant only in tha t they omit encryption support.</t> Although this specification requires both encryption and signatures, it is reaso nable for there to be subset implementations that are non-conformant only in tha t they omit encryption support.</t>
</section>
</section> </section>
</section> <section anchor="data-element-formats">
<section anchor="data-element-formats"><name>Data Element Formats</name> <name>Data Element Formats</name>
<t>This section describes the data elements used by OpenPGP.</t>
<t>This section describes the data elements used by OpenPGP.</t> <section anchor="scalar-numbers">
<name>Scalar Numbers</name>
<section anchor="scalar-numbers"><name>Scalar Numbers</name> <t>Scalar numbers are unsigned and always stored in big-endian format.
<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] &lt;&lt; 8) + n[1]). Using n[k] to refer to the kth octet being interpreted, the value of a two-octet scalar is ((n[0] &lt;&lt; 8) + n[1]).
The value of a four-octet scalar is ((n[0] &lt;&lt; 24) + (n[1] &lt;&lt; 16) + ( n[2] &lt;&lt; 8) + n[3]).</t> The value of a four-octet scalar is ((n[0] &lt;&lt; 24) + (n[1] &lt;&lt; 16) + ( n[2] &lt;&lt; 8) + n[3]).</t>
</section>
<section anchor="mpi">
<name>Multiprecision Integers</name>
<t>Multiprecision Integers (MPIs) are unsigned integers used to hold lar
ge 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, followed by a string of octets that contain the actual integ
er.</t>
<t>These octets form a big-endian number; a big-endian number can be mad
e into an MPI by prefixing it with the appropriate length.</t>
<t>Examples:</t>
<t>(Note that all numbers in the octet strings identified by square brac
kets are in hexadecimal.)</t>
</section> <ul empty="true">
<section anchor="mpi"><name>Multiprecision Integers</name> <li>The string of octets [00 00] forms an MPI with the value 0.</li>
<li>The string of octets [00 01 01] forms an MPI with the value 1.</li>
<t>Multiprecision integers (also called MPIs) are unsigned integers used to hold <li>The string [00 09 01 FF] forms an MPI with the value 511.</li>
large integers such as the ones used in cryptographic calculations.</t> </ul>
<t>Additional rules:</t>
<t>An MPI consists of two pieces: a two-octet scalar that is the length of the M <ul>
PI in bits followed by a string of octets that contain the actual integer.</t> <li>The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.</li>
<li>The length field of an MPI describes the length starting from its mo
<t>These octets form a big-endian number; a big-endian number can be made into a st significant non-zero bit. Thus, the MPI [00 02 01] is not formed correctly.
n MPI by prefixing it with the appropriate length.</t> It should be [00 01 01]. When parsing an MPI in a v6 Key, Signature, or Public-K
ey Encrypted Session Key (PKESK) packet, the implementation <bcp14>MUST</bcp14>
<t>Examples:</t> check that the encoded length matches the length starting from the most signific
ant non-zero bit; if it doesn't match, reject the packet as malformed.</li>
<t>(all numbers in the octet strings identified by square brackets are in hexade <li>Unused bits of an MPI <bcp14>MUST</bcp14> be zero.</li>
cimal)</t> </ul>
<section anchor="using-mpis-to-encode-other-data">
<t>The string of octets [00 00] forms an MPI with the value 0. <name>Using MPIs to Encode Other Data</name>
The string of octets [00 01 01] forms an MPI with the value 1. <t>Note that in some places, MPIs are used to encode non-integer data,
The string [00 09 01 FF] forms an MPI with the value of 511.</t> such as an elliptic curve (EC) point (see <xref target="ec-point-wire-formats"/
>) or an octet string of known, fixed length (see <xref target="ec-scalar-wire-f
<t>Additional rules:</t> ormats"/>). The wire representation is the same: two octets of length in bits co
unted from the first non-zero bit, followed by the smallest series of octets tha
<t>The size of an MPI is ((MPI.length + 7) / 8) + 2 octets.</t> t can represent the value while stripping off any leading zero octets.</t>
</section>
<t>The length field of an MPI describes the length starting from its most signif </section>
icant non-zero bit. <section anchor="key-ids-and-fingerprints">
Thus, the MPI [00 02 01] is not formed correctly. <name>Key IDs and Fingerprints</name>
It should be [00 01 01]. <t>A Key ID is an eight-octet scalar that identifies a key.
When parsing an MPI in a v6 Key, Signature, or Public-Key Encrypted Session Key
packet, the implementation <bcp14>MUST</bcp14> check that the encoded length mat
ches the length starting from the most significant non-zero bit, and reject the
packet as malformed if not.</t>
<t>Unused bits of an MPI <bcp14>MUST</bcp14> be zero.</t>
<section anchor="using-mpis-to-encode-other-data"><name>Using MPIs to encode oth
er data</name>
<t>Note that MPIs are in some places used to encode non-integer data, such as an
elliptic curve point (see <xref 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 t
he first non-zero bit, followed by the smallest series of octets that can repres
ent the value while stripping off any leading zero octets.</t>
</section>
</section>
<section 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. Implementations <bcp14>SHOULD NOT</bcp14> assume that Key IDs are unique.
A fingerprint is more likely to be unique than a key ID. 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> 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 Finge
<t><xref target="key-ids-fingerprints"/> describes how Key IDs and Fingerprints rprints are formed.</t>
are formed.</t> </section>
<section anchor="text">
</section> <name>Text</name>
<section 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>
<t>Unless otherwise specified, the character set for text is the UTF-8 <xref tar </section>
get="RFC3629"/> encoding of Unicode <xref target="ISO10646"/>.</t> <section anchor="time-fields">
<name>Time Fields</name>
</section> <t>A time field is an unsigned four-octet number containing the number o
<section anchor="time-fields"><name>Time Fields</name> f seconds elapsed since midnight, 1 January 1970 UTC.</t>
</section>
<t>A time field is an unsigned four-octet number containing the number of second <section anchor="keyrings">
s elapsed since midnight, 1 January 1970 UTC.</t> <name>Keyrings</name>
<t>A keyring is a collection of one or more keys in a file or database.
</section> Typically, a keyring is simply a sequential list of keys, but it may be any suit
<section anchor="keyrings"><name>Keyrings</name> able database.
It is beyond the scope of this specification to discuss the details of keyrings
<t>A keyring is a collection of one or more keys in a file or database. or other databases.</t>
Traditionally, a keyring is simply a sequential list of keys, but may be any sui </section>
table database. <section anchor="string-to-key-s2k-specifier">
It is beyond the scope of this standard to discuss the details of keyrings or ot <name>String-to-Key (S2K) Specifier</name>
her databases.</t> <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
</section> of S2K conversion are currently used in two places: to encrypt the secret part
<section anchor="string-to-key-s2k-specifier"><name>String-to-Key (S2K) Specifie of private keys and for symmetrically encrypted messages.</t>
r</name> <section anchor="s2k-types">
<name>S2K Specifier Types</name>
<t>A string-to-key (S2K) specifier type is used to convert a passphrase string i <t>There are four types of S2K Specifier Types currently specified and
nto a symmetric-key encryption/decryption key. some reserved values:</t>
Passphrases requiring use of S2K conversion are currently used in two places: to <table anchor="s2k-types-registry">
encrypt the secret part of private keys, and for symmetrically encrypted messag <name>OpenPGP String-to-Key (S2K) Types Registry</name>
es.</t> <thead>
<tr>
<section anchor="s2k-types"><name>String-to-Key (S2K) Specifier Types</name> <th align="right">ID</th>
<th align="left">S2K Type</th>
<t>There are four types of S2K Specifier Types currently specified, and some res <th align="left">S2K Field Size (Octets)</th>
erved values:</t> <th align="left">Generate?</th>
<th align="left">Reference</th>
<texttable title="OpenPGP String-to-Key (S2K) Types registry" anchor="s2k-types- </tr>
registry"> </thead>
<ttcol align='right'>ID</ttcol> <tbody>
<ttcol align='left'>S2K Type</ttcol> <tr>
<ttcol align='left'>S2K field size (octets)</ttcol> <td align="right">0</td>
<ttcol align='left'>Reference</ttcol> <td align="left">Simple S2K</td>
<ttcol align='left'>Generate?</ttcol> <td align="left">2</td>
<c>0</c> <td align="left">No</td>
<c>Simple S2K</c> <td align="left"><xref target="s2k-simple"/></td>
<c>2</c> </tr>
<c><xref target="s2k-simple"/></c> <tr>
<c>No</c> <td align="right">1</td>
<c>1</c> <td align="left">Salted S2K</td>
<c>Salted S2K</c> <td align="left">10</td>
<c>10</c> <td align="left">Only when string is high entropy</td>
<c><xref target="s2k-salted"/></c> <td align="left"><xref target="s2k-salted"/></td>
<c>Only when string is high entropy</c> </tr>
<c>2</c> <tr>
<c>Reserved value</c> <td align="right">2</td>
<c>-</c> <td align="left">Reserved value</td>
<c>-</c> <td align="left">-</td>
<c>No</c> <td align="left">No</td>
<c>3</c> <td align="left"></td>
<c>Iterated and Salted S2K</c> </tr>
<c>11</c> <tr>
<c><xref target="s2k-iter-salted"/></c> <td align="right">3</td>
<c>Yes</c> <td align="left">Iterated and Salted S2K</td>
<c>4</c> <td align="left">11</td>
<c>Argon2</c> <td align="left">Yes</td>
<c>20</c> <td align="left"><xref target="s2k-iter-salted"/></td>
<c><xref target="s2k-argon2"/></c> </tr>
<c>Yes</c> <tr>
<c>100 to 110</c> <td align="right">4</td>
<c>Private/Experimental S2K</c> <td align="left">Argon2</td>
<c>-</c> <td align="left">20</td>
<c>-</c> <td align="left">Yes</td>
<c>As appropriate</c> <td align="left"><xref target="s2k-argon2"/></td>
</texttable> </tr>
<tr>
<t>These are described in the subsections below. <td align="right">100-110</td>
If the "Generate?" column is not "Yes", the S2K entry is used only for reading i <td align="left">Private or Experimental Use</td>
n backwards compatibility mode and <bcp14>SHOULD NOT</bcp14> be used to generate <td align="left">-</td>
new output.</t> <td align="left">As appropriate</td>
<td align="left"></td>
<section anchor="s2k-simple"><name>Simple S2K</name> </tr>
</tbody>
<t>This directly hashes the string to produce the key data. </table>
See below for how this hashing is done.</t> <t>The S2K Specifier Types are described in the subsections below.
If "Yes" is not present in the "Generate?" column, the S2K entry is used only fo
<figure><artwork><![CDATA[ r reading in backward-compatibility mode and <bcp14>SHOULD NOT</bcp14> be used t
o generate new output.</t>
<section anchor="s2k-simple">
<name>Simple S2K</name>
<t>Simple S2K directly hashes the string to produce the key data. Th
is hashing is done as shown below.</t>
<artwork><![CDATA[
Octet 0: 0x00 Octet 0: 0x00
Octet 1: hash algorithm Octet 1: hash algorithm
]]></artwork></figure> ]]></artwork>
<t>Simple S2K hashes the passphrase to produce the session key.
<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 d epends on the cipher the session key will be used with) and the size of the hash algorithm's output. The manner in which this is done depends on the size of the session key (which d epends 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> 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
<t>If the hash size is less than the key size, multiple instances of the hash co the hash context are created -- enough to produce the required key data. These
ntext are created --- enough to produce the required key data. instances are preloaded with 0, 1, 2, ...
These instances are preloaded with 0, 1, 2, ... octets of zeros (that is, the first instance has no preloading, the second gets
octets of zeros (that is to say, the first instance has no preloading, the secon preloaded with 1 octet of zero, the third is preloaded with two octets of zeros,
d gets preloaded with 1 octet of zero, the third is preloaded with two octets of and so forth).</t>
zeros, and so forth).</t> <t>As the data is hashed, it is given independently to each hash con
text. Since the contexts have been initialized differently, they will each produ
<t>As the data is hashed, it is given independently to each hash context. ce a different hash output. Once the passphrase is hashed, the output data from
Since the contexts have been initialized differently, they will each produce dif the multiple hashes is concatenated, first hash leftmost, to produce the key dat
ferent hash output. a, and any excess octets on the right are discarded.</t>
Once the passphrase is hashed, the output data from the multiple hashes is conca </section>
tenated, first hash leftmost, to produce the key data, with any excess octets on <section anchor="s2k-salted">
the right discarded.</t> <name>Salted S2K</name>
<t>Salted S2K includes a "salt" value in the S2K specifier -- some a
</section> rbitrary data -- that gets hashed along with the passphrase string to help preve
<section anchor="s2k-salted"><name>Salted S2K</name> nt dictionary attacks.</t>
<artwork><![CDATA[
<t>This includes a "salt" value in the S2K specifier --- some arbitrary data ---
that gets hashed along with the passphrase string, to help prevent dictionary a
ttacks.</t>
<figure><artwork><![CDATA[
Octet 0: 0x01 Octet 0: 0x01
Octet 1: hash algorithm Octet 1: hash algorithm
Octets 2-9: 8-octet salt value Octets 2-9: 8-octet salt value
]]></artwork></figure> ]]></artwork>
<t>Salted S2K is exactly like Simple S2K, except that the input to t
<t>Salted S2K is exactly like Simple S2K, except that the input to the hash func he hash function(s) consists of the 8 octets of salt from the S2K specifier, fol
tion(s) consists of the 8 octets of salt from the S2K specifier, followed by the lowed by the passphrase.</t>
passphrase.</t> </section>
<section anchor="s2k-iter-salted">
</section> <name>Iterated and Salted S2K</name>
<section anchor="s2k-iter-salted"><name>Iterated and Salted S2K</name> <t>Iterated and Salted S2K includes both a salt and an octet count.
The salt is combined with the passphrase, and the resulting value is repeated an
<t>This includes both a salt and an octet count. d then hashed.
The salt is combined with the 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> This further increases the amount of work an attacker must do to try dictionary attacks.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
Octet 0: 0x03 Octet 0: 0x03
Octet 1: hash algorithm Octet 1: hash algorithm
Octets 2-9: 8-octet salt value Octets 2-9: 8-octet salt value
Octet 10: count, a one-octet, coded value Octet 10: count; a one-octet coded value
]]></artwork></figure> ]]></artwork>
<t>The count is coded into a one-octet number using the following fo
<t>The count is coded into a one-octet number using the following formula:</t> rmula:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
#define EXPBIAS 6 #define EXPBIAS 6
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS);
]]></artwork></figure> ]]></artwork>
<t>The above formula is described in <xref target="C99"/>, where "In
<t>The above formula is in <xref target="C99"/>, where "Int32" is a type for a 3 t32" is a type for a 32-bit integer, and the variable "c" is the coded count, oc
2-bit integer, and the variable "c" is the coded count, Octet 10.</t> tet 10.</t>
<t>Iterated and Salted S2K hashes the passphrase and salt data multi
<t>Iterated-Salted S2K hashes the passphrase and salt data multiple times. ple times.
The total number of octets to be hashed is specified in the encoded count in the S2K specifier. 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 Note that the resulting count value is an octet count of how many oct
hashed, not an iteration count.</t> ets will be hashed, not an iteration count.</t>
<t>Initially, one or more hash contexts are set up as with the other S2K algorit
hms, 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 ha
s been hashed.
The input is truncated to the octet count, except if the octet count is less tha
n 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 w
ith the other S2K algorithms.</t>
</section>
<section anchor="s2k-argon2"><name>Argon2</name>
<t>This S2K method hashes the passphrase using Argon2, specified in <xref target <t>Initially, one or more hash contexts are set up the same as the o
="RFC9106"/>. ther S2K algorithms, depending on how many octets of key data are needed. Then t
This provides memory-hardness, further protecting the passphrase against brute-f he salt, followed by the passphrase data, is repeatedly processed as input to ea
orce attacks.</t> ch hash context until the number of octets specified by the octet count has been
hashed. The input is truncated to the octet count, except if the octet count is
less than the initial size of the salt plus passphrase. That is, at least one c
opy of the full salt plus passphrase will be provided as input to each hash cont
ext regardless of the octet count. After the hashing is done, the key data is pr
oduced from the hash digest(s), which is the same way it is produced for the oth
er S2K algorithms.</t>
</section>
<section 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, further protecting the passphrase agai
nst brute-force attacks.</t>
<figure><artwork><![CDATA[ <artwork><![CDATA[
Octet 0: 0x04 Octet 0: 0x04
Octets 1-16: 16-octet salt value Octets 1-16: 16-octet salt value
Octet 17: one-octet number of passes t Octet 17: one-octet number of passes t
Octet 18: one-octet degree of parallelism p Octet 18: one-octet degree of parallelism p
Octet 19: one-octet encoded_m, specifying the exponent of the memory si Octet 19: one-octet encoded_m, specifying the exponent of
ze the memory size
]]></artwork></figure> ]]></artwork>
<t>The salt <bcp14>SHOULD</bcp14> be unique for each passphrase.</t>
<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>MUS
T</bcp14> be non-zero.</t>
<t>The number of passes t and the degree of parallelism p <bcp14>MUST</bcp14> be <t>The memory size m is 2<sup><tt>encoded_m</tt></sup> kibibytes (Ki
non-zero.</t> B) of RAM.
The encoded memory size <bcp14>MUST</bcp14> be a value from 3+ceil(log<sub>2</su
<t>The memory size m is 2**encoded_m kibibytes of RAM. b>(p)) to 31, such that the decoded memory size m is a value from 8*p to 2<sup>3
The encoded memory size <bcp14>MUST</bcp14> be a value from 3+ceil(log_2(p)) to 1</sup>. Note that memory-hardness size is indicated in KiB, not octets.</t>
31, such that the decoded memory size m is a value from 8*p to 2**31. <t>Argon2 is invoked with the passphrase as P, the salt as S, the va
Note that memory-hardness size is indicated in kibibytes (KiB), not octets.</t> lues of t, 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>Argon2 is invoked with the passphrase as P, the salt as S, the values of t, p <t>For the recommended values of t, p, and m, see <xref section="4"
and m as described above, the required key size as the tag length T, 0x13 as th sectionFormat="of" target="RFC9106"/>.
e version v, and Argon2id as the type.</t> 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
<t>For the recommended values of t, p and m, see <xref section="4" sectionFormat performance would be acceptable; otherwise, round down (keeping in mind that m m
="of" target="RFC9106"/>. ust be at least 8*p).</t>
If the recommended value of m for a given application is not a power of 2, it is <t>As an example, with the first recommended option (t=1, p=4, m=2<s
<bcp14>RECOMMENDED</bcp14> to round up to the next power of 2 if the resulting up>21</sup>), the full S2K specifier would be:</t>
performance would be acceptable, and round down otherwise (keeping in mind that <artwork><![CDATA[
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 ful
l S2K specifier would be:</t>
<figure><artwork><![CDATA[
04 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX 04 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX 01 04 15 XX 01 04 15
]]></artwork></figure> ]]></artwork>
<t>where XX represents a random octet of salt.</t>
<t>(where XX represents a random octet of salt).</t> </section>
</section>
</section> <section anchor="s2k-usage-octet">
</section> <name>S2K Usage</name>
<section anchor="s2k-usage-octet"><name>String-to-Key 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.
<t>Simple S2K and Salted S2K specifiers can be brute-forced when used with a low In addition, the usage of Simple S2K can lead to key and initialization vector (
-entropy string, such as those typically provided by users. IV) reuse (see <xref target="skesk"/>).
In addition, the usage of Simple S2K can lead to key and IV reuse (see <xref tar
get="skesk"/>).
Therefore, when generating an S2K specifier, an implementation <bcp14>MUST NOT</ bcp14> use Simple S2K. 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 u Furthermore, an implementation <bcp14>SHOULD NOT</bcp14> generate a Salted S2K u
nless the implementation knows that the input string is high-entropy (for exampl nless the implementation knows that the input string is high entropy (for exampl
e, it generated the string itself using a known-good source of randomness).</t> e, it generated the string itself using a known good source of randomness).</t>
<t>It is <bcp14>RECOMMENDED</bcp14> that implementations use Argon2.
<t>It is <bcp14>RECOMMENDED</bcp14> that implementations use Argon2.
If Argon2 is not available, Iterated and Salted S2K <bcp14>MAY</bcp14> be used i f care is taken to use a high octet count and a strong passphrase. If Argon2 is not available, Iterated and Salted S2K <bcp14>MAY</bcp14> be used i f care is taken to use a high octet count and a strong passphrase.
However, this method does not provide memory-hardness, unlike Argon2.</t> However, this method does not provide memory hardness, unlike Argon2.</t>
<section anchor="secret-key-encryption">
<section anchor="secret-key-encryption"><name>Secret-Key Encryption</name> <name>Secret-Key Encryption</name>
<t>The first octet following the public key material in a secret key
<t>The first octet following the public key material in a secret key packet (<xr packet (<xref target="secret-key-packet-formats"/>) indicates whether and how t
ef target="secret-key-packet-formats"/>) indicates whether and how the secret ke he secret key material is passphrase protected.
y material is passphrase-protected.
This first octet is known as the "S2K usage octet".</t> This first octet is known as the "S2K usage octet".</t>
<t>If the S2K usage octet is zero, the secret key data is unprotecte
<t>If S2K usage octet is zero, the secret key data is unprotected. d.
If it is non-zero, it describes how to use a passphrase to unlock the secret key .</t> 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 pr
<t>Implementations predating <xref target="RFC2440"/> indicated a protected key otected key by storing a symmetric cipher algorithm ID (see <xref target="symmet
by storing a symmetric cipher algorithm ID (see <xref target="symmetric-algos"/> ric-algos"/>) in the S2K usage octet.
) 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> 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
one of the special values 253 (AEAD), 254 (CFB), or 255 (MalleableCFB) in the S2
K usage octet. The S2K usage octet is then followed immediately by a set of fiel
ds 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 us
ed.</t>
<t>The wire format fields also differ based on the version of the en
closing OpenPGP packet.
The table below, indexed by the S2K usage octet, summarizes the speci
fics described in <xref target="secret-key-packet-formats"/>.</t>
<t>Later implementations indicate a protected secret key by storing a special va <t>In the table below, <tt>check(x)</tt> means the "2-octet checksum
lue 253 (AEAD), 254 (CFB), or 255 (MalleableCFB) in the S2K usage octet. ", which is the sum of all octets in x mod 65536. The <tt>info</tt> and <tt>pack
The S2K usage octet is then followed immediately by a set of fields that describ etprefix</tt> parameters are described in detail in <xref target="secret-key-pac
e how to convert a passphrase to a symmetric key that can unlock the secret mate ket-formats"/>. Note that the "Generate?" column header has been shortened to "
rial, plus other parameters relevant to the type of encryption used.</t> Gen?" here.</t>
<table anchor="secret-key-protection-registry">
<t>The wire format fields also differ based on the version of the enclosing Open <name>OpenPGP Secret Key Encryption (S2K Usage Octet) Registry</na
PGP packet. me>
The table below, indexed by S2K usage octet, summarizes the specifics described <thead>
in <xref target="secret-key-packet-formats"/>.</t> <tr>
<th align="left">S2K Usage Octet</th>
<t>In the table below, <spanx style="verb">check(x)</spanx> means the "2-octet c <th align="left">Shorthand</th>
hecksum" meaning the sum of all octets in x mod 65536. <th align="left">Encryption Parameter Fields</th>
The <spanx style="verb">info</spanx> and <spanx style="verb">packetprefix</spanx <th align="left">Encryption</th>
> parameters are described in detail in <xref target="secret-key-packet-formats" <th align="left">Gen?</th>
/>.</t> </tr>
</thead>
<texttable title="OpenPGP Secret Key Encryption (S2K Usage Octet) registry" anch <tbody>
or="secret-key-protection-registry"> <tr>
<ttcol align='left'>S2K usage octet</ttcol> <td align="left">0</td>
<ttcol align='left'>Shorthand</ttcol> <td align="left">Unprotected</td>
<ttcol align='left'>Encryption parameter fields</ttcol> <td align="left">-</td>
<ttcol align='left'>Encryption</ttcol> <td align="left"> <strong>v3 or v4 keys:</strong> [cleartext s
<ttcol align='left'>Generate?</ttcol> ecrets || check(secrets)] <br/>
<c>0</c> <strong>v6 keys:</strong> [cleartext secrets]
<c>Unprotected</c> </td>
<c>-</c> <td align="left">Yes</td>
<c><strong>v3 or v4 keys:</strong> [cleartext secrets || check(secrets)] < </tr>
br /> <strong>v6 keys:</strong> [cleartext secrets]</c> <tr>
<c>Yes</c> <td align="left">Known symmetric cipher algo ID (see <xref tar
<c>Known symmetric cipher algo ID (see <xref target="symmetric-algos"/>)</ get="symmetric-algos"/>)</td>
c> <td align="left">LegacyCFB</td>
<c>LegacyCFB</c> <td align="left">IV</td>
<c>IV</c> <td align="left">CFB(MD5(passphrase), secrets || check(secrets
<c>CFB(MD5(passphrase), secrets || check(secrets))</c> ))</td>
<c>No</c> <td align="left">No</td>
<c>253</c> </tr>
<c>AEAD</c> <tr>
<c>params-length (<strong>v6-only</strong>), cipher-algo, AEAD-mode, S2K-s <td align="left">253</td>
pecifier-length (<strong>v6-only</strong>), S2K-specifier, nonce</c> <td align="left">AEAD</td>
<c>AEAD(HKDF(S2K(passphrase), info), secrets, packetprefix)</c> <td align="left">params-length (<strong>v6-only</strong>), cip
<c>Yes</c> her-algo, AEAD-mode, S2K-specifier-length (<strong>v6-only</strong>),S2K-specifi
<c>254</c> er, nonce
<c>CFB</c> </td>
<c>params-length (<strong>v6-only</strong>), cipher-algo, S2K-specifier-le <td align="left">AEAD(HKDF(S2K(passphrase), info), secrets, pa
ngth (<strong>v6-only</strong>), S2K-specifier, IV</c> cketprefix)</td>
<c>CFB(S2K(passphrase), secrets || SHA1(secrets))</c> <td align="left">Yes</td>
<c>Yes</c> </tr>
<c>255</c> <tr>
<c>MalleableCFB</c> <td align="left">254</td>
<c>cipher-algo, S2K-specifier, IV</c> <td align="left">CFB</td>
<c>CFB(S2K(passphrase), secrets || check(secrets))</c> <td align="left">params-length (<strong>v6-only</strong>), cip
<c>No</c> her-algo, S2K-specifier-length (<strong>v6-only</strong>), S2K-specifier, IV</td
</texttable> >
<td align="left">CFB(S2K(passphrase), secrets || SHA1(secrets)
<t>When emitting a secret key (with or without passphrase-protection) an impleme )</td>
ntation <bcp14>MUST</bcp14> only produce data from a row with "Generate?" marked <td align="left">Yes</td>
as "Yes". </tr>
Each row with "Generate?" marked as "No" is described for backward compatibility <tr>
(for reading v4 and earlier keys only), and <bcp14>MUST NOT</bcp14> be used to <td align="left">255</td>
generate new output. <td align="left">MalleableCFB</td>
<td align="left">cipher-algo, S2K-specifier, IV</td>
<td align="left">CFB(S2K(passphrase), secrets || check(secrets
))</td>
<td align="left">No</td>
</tr>
</tbody>
</table>
<t>When emitting a secret key (with or without passphrase protection
), an implementation <bcp14>MUST</bcp14> only produce data from a row with "Gene
rate?" marked as "Yes".
Each row with "Generate?" marked as "No" is described for backward compatibility
(for reading v4 and earlier keys only) and <bcp14>MUST NOT</bcp14> be used to g
enerate new output.
Version 6 secret keys using these formats <bcp14>MUST</bcp14> be rejected.</t> 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
<t>Note that compared to a version 4 secret key, the parameters of a passphrase- passphrase-protected version 6 secret key are stored with an additional pair of
protected version 6 secret key are stored with an additional pair of length coun length counts, each of which is one octet wide.</t>
ts, each of which is one octet wide.</t> <t>Argon2 is only used with Authenticated Encryption with Associated
Data (AEAD) (S2K usage octet 253).
<t>Argon2 is only used with 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) a nd the S2K specifier type is Argon2.</t> 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) a nd the S2K specifier type is Argon2.</t>
</section>
</section> <section anchor="symmetric-key-message-encryption">
<section anchor="symmetric-key-message-encryption"><name>Symmetric-Key Message E <name>Symmetric-Key Message Encryption</name>
ncryption</name> <t>OpenPGP can create a Symmetric-key Encrypted Session Key (SKESK)
packet at the front of a message.
<t>OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet at the This is used to allow S2K specifiers to be used for the passphrase co
front of a message. nversion or to create messages with a mix of SKESK packets and PKESK packets. Th
This is used to allow S2K specifiers to be used for the passphrase conversion or is allows a message to be decrypted with either a passphrase or a public-key pai
to create messages with a mix of symmetric-key ESKs and public-key ESKs. r.</t>
This allows a message to be decrypted either with a passphrase or a public-key p <t>Implementations predating <xref target="RFC2440"/> always used th
air.</t> e International Data Encryption Algorithm (IDEA) with Simple S2K conversion when
encrypting a message with a symmetric algorithm;
<t>Implementations predating <xref target="RFC2440"/> always used IDEA with Simp see <xref target="sed"/>. IDEA <bcp14>MUST NOT</bcp14> be generated but <bcp14>M
le string-to-key conversion when encrypting a message with a symmetric algorithm AY</bcp14> be consumed for backward compatibility.</t>
. </section>
See <xref target="sed"/>. </section>
This <bcp14>MUST NOT</bcp14> be generated, but <bcp14>MAY</bcp14> be consumed fo </section>
r backward-compatibility.</t> </section>
<section anchor="packet-syntax">
</section> <name>Packet Syntax</name>
</section> <t>This section describes the packets used by OpenPGP.</t>
</section> <section anchor="overview">
</section> <name>Overview</name>
<section anchor="packet-syntax"><name>Packet Syntax</name> <t>An OpenPGP message is constructed from a number of records that are t
ypically called packets.
<t>This section describes the packets used by OpenPGP.</t>
<section anchor="overview"><name>Overview</name>
<t>An OpenPGP message is constructed from a number of records that are tradition
ally called packets.
A packet is a chunk of data that has a type ID specifying its meaning. 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 consi sts of a number of packets. An OpenPGP message, keyring, certificate, detached signature, and so forth consi sts of a number of packets.
Some of those packets may contain other OpenPGP packets (for example, a compress ed data packet, when uncompressed, contains OpenPGP packets).</t> Some of those packets may contain other OpenPGP packets (for example, a compress ed data packet, when uncompressed, contains OpenPGP packets).</t>
<t>Each packet consists of a packet header, followed by the packet body.
<t>Each packet consists of a packet header, followed by the packet body.
The packet header is of variable length.</t> The packet header is of variable length.</t>
<t>When handling a stream of packets, the length information in each pac
<t>When handling a stream of packets, the length information in each packet head ket header is the canonical source of packet boundaries.
er is the canonical source of packet boundaries.
An implementation handling a packet stream that wants to find the next packet <b cp14>MUST</bcp14> look for it at the precise offset indicated in the previous pa cket header.</t> An implementation handling a packet stream that wants to find the next packet <b cp14>MUST</bcp14> look for it at the precise offset indicated in the previous pa cket header.</t>
<t>Additionally, some packets contain internal length indicators (for ex
<t>Additionally, some packets contain internal length indicators (for example, a ample, a subfield within the packet).
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</bcp1 4> treat the packet as malformed and unusable.</t> 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</bcp1 4> treat the packet as malformed and unusable.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> interpret octets outside th
<t>An implementation <bcp14>MUST NOT</bcp14> interpret octets outside the range e range indicated in the packet header as part of the contents of the packet.</t
indicated in the packet header as part of the contents of the packet.</t> >
</section>
</section> <section anchor="packet-headers">
<section anchor="packet-headers"><name>Packet Headers</name> <name>Packet Headers</name>
<t>The first octet of the packet denotes the format of the rest of the h
<t>The first octet of the packet denotes the format of the rest of the header, a eader, and it encodes the Packet Type ID, indicating the type of the packet (see
nd encodes the Packet Type ID, indicating the type of the packet (see <xref targ <xref target="packet-types"/>). The remainder of the packet header is the lengt
et="packet-types"/>). h of the packet.</t>
The remainder of the packet header is the length of the packet.</t> <t>There are two packet formats: 1) the (current) OpenPGP packet format
specified by this document and its predecessors <xref target="RFC4880"/> and <xr
<t>There are two packet formats, the (current) OpenPGP packet format specified b ef target="RFC2440"/> and 2) the Legacy packet format as used by implementations
y this document and its predecessors <xref target="RFC4880"/> and <xref target=" predating any IETF specification of OpenPGP.</t>
RFC2440"/>, and the Legacy packet format as used by implementations predating an <t>Note that the most significant bit is the leftmost bit, called "bit 7
y IETF specification of the protocol.</t> ".
<t>Note that the most significant bit is the leftmost bit, called bit 7.
A mask for this bit is 0x80 in hexadecimal.</t> A mask for this bit is 0x80 in hexadecimal.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[ +---------------+
┌───────────────┐ Encoded Packet Type ID: |7 6 5 4 3 2 1 0|
Encoded Packet Type ID: │7 6 5 4 3 2 1 0│ +---------------+
└───────────────┘
OpenPGP format: OpenPGP format:
Bit 7 -- always one Bit 7 -- always one
Bit 6 -- always one Bit 6 -- always one
Bits 5 to 0 -- packet type ID Bits 5 to 0 -- packet type ID
Legacy format: Legacy format:
Bit 7 -- always one Bit 7 -- always one
Bit 6 -- always zero Bit 6 -- always zero
Bits 5 to 2 -- packet type ID Bits 5 to 2 -- packet type ID
Bits 1 to 0 -- length-type Bits 1 to 0 -- length-type
]]></artwork></figure> ]]></artwork>
<t>Bit 6 of the first octet of the packet header indicates whether the p
<t>Bit 6 of the first octet of the packet header indicates whether the packet is acket is encoded in the OpenPGP or Legacy packet format.
encoded in the OpenPGP or Legacy packet format.
The Legacy packet format <bcp14>MAY</bcp14> be used when consuming packets to fa cilitate interoperability and accessing archived data. The Legacy packet format <bcp14>MAY</bcp14> be used when consuming packets to fa cilitate interoperability and accessing archived data.
The Legacy packet format <bcp14>SHOULD NOT</bcp14> be used to generate new 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. unless the recipient is known to only support the Legacy packet format. This la
This latter case is extremely unlikely, as the Legacy packet format was obsolete tter case is extremely unlikely, as the Legacy packet format was obsoleted by <x
d by <xref target="RFC2440"/> in 1998.</t> ref target="RFC2440"/> in 1998.</t>
<t>An implementation that consumes and redistributes pre-existing OpenPG
<t>An implementation that consumes and re-distributes pre-existing OpenPGP data P data (such as Transferable Public Keys) may encounter packets framed with the
(such as Transferable Public Keys) may encounter packets framed with the Legacy Legacy packet format. Such an implementation <bcp14>MAY</bcp14> either redistrib
packet format. ute these packets in their Legacy format or transform them to the current OpenPG
Such an implementation <bcp14>MAY</bcp14> either re-distribute these packets in P packet format before redistribution.</t>
their Legacy format, or transform them to the current OpenPGP packet format befo <t>Note that Legacy format headers only have 4 bits for the packet type
re re-distribution.</t> ID and hence can only encode packet type IDs less than 16, whereas the OpenPGP f
ormat headers can encode IDs as great as 63.</t>
<t>Note that Legacy format headers only have 4 bits for the packet type ID, and <section anchor="openpgp-packet-format">
hence can only encode packet type IDs less than 16, whereas the OpenPGP format h <name>OpenPGP Format Packet Lengths</name>
eaders can encode IDs as great as 63.</t> <t>OpenPGP format packets have four possible ways of encoding length:<
/t>
<section anchor="openpgp-packet-format"><name>OpenPGP Format Packet Lengths</nam <ol spacing="normal" type="1"><li>
e> <t>A one-octet Body Length header encodes packet lengths of up to
191 octets.</t>
<t>OpenPGP format packets have four possible ways of encoding length:</t> </li>
<li>
<t><list style="numbers"> <t>A two-octet Body Length header encodes packet lengths of 192 to
<t>A one-octet Body Length header encodes packet lengths of up to 191 octets.< 8383 octets.</t>
/t> </li>
<t>A two-octet Body Length header encodes packet lengths of 192 to 8383 octets <li>
.</t> <t>A five-octet Body Length header encodes packet lengths of up to
<t>A five-octet Body Length header encodes packet lengths of up to 4,294,967,2 4,294,967,295 (0xFFFFFFFF) octets in length.
95 (0xFFFFFFFF) octets in length.
(This actually encodes a four-octet scalar number.)</t> (This actually encodes a four-octet scalar number.)</t>
<t>When the length of the packet body is not known in advance by the issuer, P </li>
artial Body Length headers encode a packet of indeterminate length, effectively <li>
making it a stream.</t> <t>When the length of the packet body is not known in advance by t
</list></t> he issuer, Partial Body Length headers encode a packet of indeterminate length,
effectively making it a stream.</t>
<section anchor="one-octet-lengths"><name>One-Octet Lengths</name> </li>
</ol>
<t>A one-octet Body Length header encodes a length of 0 to 191 octets. <section anchor="one-octet-lengths">
This type of length header is recognized because the one octet value is less tha <name>One-Octet Lengths</name>
n 192. <t>A one-octet Body Length header encodes a length of 0 to 191 octet
s.
This type of length header is recognized because the one-octet value is less tha
n 192.
The body length is equal to:</t> The body length is equal to:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
bodyLen = 1st_octet; bodyLen = 1st_octet;
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="two-octet-lengths">
<section anchor="two-octet-lengths"><name>Two-Octet Lengths</name> <name>Two-Octet Lengths</name>
<t>A two-octet Body Length header encodes a length of 192 to 8383 oc
<t>A two-octet Body Length header encodes a length of 192 to 8383 octets. tets.
It is recognized because its first octet is in the range 192 to 223. It is recognized because its first octet is in the range 192 to 223.
The body length is equal to:</t> The body length is equal to:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 bodyLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="five-octet-lengths">
<section anchor="five-octet-lengths"><name>Five-Octet Lengths</name> <name>Five-Octet Lengths</name>
<t>A five-octet Body Length header consists of a single octet holdin
<t>A five-octet Body Length header consists of a single octet holding the value g the value 255, followed by a four-octet scalar. The body length is equal to:</
255, followed by a four-octet scalar. t>
The body length is equal to:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
bodyLen = (2nd_octet << 24) | (3rd_octet << 16) | bodyLen = (2nd_octet << 24) | (3rd_octet << 16) |
(4th_octet << 8) | 5th_octet (4th_octet << 8) | 5th_octet
]]></artwork></figure> ]]></artwork>
<t>This basic set of one, two, and five-octet lengths is also used i
<t>This basic set of one, two, and five-octet lengths is also used internally to nternally to some packets.</t>
some packets.</t> </section>
<section anchor="partial-body-lengths">
</section> <name>Partial Body Lengths</name>
<section anchor="partial-body-lengths"><name>Partial Body Lengths</name> <t>A Partial Body Length header is one octet long and encodes the le
ngth of only part of the data packet.
<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). 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 value that is greater than or equal to 224, an d less than 255. It is recognized by its one-octet value that is greater than or equal to 224, an d less than 255.
The Partial Body Length is equal to:</t> The Partial Body Length is equal to:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
partialBodyLen = 1 << (1st_octet & 0x1F); partialBodyLen = 1 << (1st_octet & 0x1F);
]]></artwork></figure> ]]></artwork>
<t>Each Partial Body Length header is followed by a portion of the p
<t>Each Partial Body Length header is followed by a portion of the packet body d acket body data;
ata. the Partial Body Length header specifies this portion's length.
The Partial Body Length header specifies this portion's length. Another length header (one-octet, two-octet, five-octet, or partial) follows tha
Another length header (one octet, two-octet, five-octet, or partial) follows tha t portion.
t portion.
The last length header in the packet <bcp14>MUST NOT</bcp14> be a Partial Body L ength header. The last length header in the packet <bcp14>MUST NOT</bcp14> be a Partial Body L ength header.
Partial Body Length headers may only be used for the non-final parts of the pack et.</t> Partial Body Length headers may only be used for the non-final parts of the pack et.</t>
<t>Note also that the last Body Length header can be a zero-length h
<t>Note also that the last Body Length header can be a zero-length header.</t> eader.</t>
<t>An implementation <bcp14>MAY</bcp14> use Partial Body Lengths for
<t>An implementation <bcp14>MAY</bcp14> use Partial Body Lengths for data packet data packets, whether they are literal, compressed, or encrypted. The first par
s, be they literal, compressed, or encrypted. tial length <bcp14>MUST</bcp14> be at least 512 octets long.
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> Partial Body Lengths <bcp14>MUST NOT</bcp14> be used for any other packet types. </t>
</section>
</section> </section>
</section> <section anchor="legacy-packet-format">
<section anchor="legacy-packet-format"><name>Legacy Format Packet Lengths</name> <name>Legacy Format Packet Lengths</name>
<t>A zero in bit 6 of the first octet of the packet indicates a Legacy
<t>A zero in bit 6 of the first octet of the packet indicates a Legacy packet fo packet format.
rmat.
Bits 1 and 0 of the first octet of a Legacy packet are the "length-type" field. 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> The meaning of length-type in Legacy format packets is as follows:</t>
<dl>
<dl> <dt>0</dt>
<dt>0</dt> <dd>The packet has a one-octet length. The header is 2 octets long.
<dd> </dd>
<t>The packet has a one-octet length. <dt>1</dt>
The header is 2 octets long.</t> <dd>The packet has a two-octet length. The header is 3 octets long.
</dd> </dd>
<dt>1</dt> <dt>2</dt>
<dd> <dd>The packet has a four-octet length. The header is 5 octets long.
<t>The packet has a two-octet length. </dd>
The header is 3 octets long.</t> <dt>3</dt>
</dd> <dd>The packet is of indeterminate length.
<dt>2</dt>
<dd>
<t>The packet has a four-octet length.
The header is 5 octets long.</t>
</dd>
<dt>3</dt>
<dd>
<t>The packet is of indeterminate length.
The header is 1 octet long, and the implementation must determine how long the p acket is. The header is 1 octet long, and the implementation must determine how long the p acket is.
If the packet is in a file, this means that the packet extends until the end of the file. If the packet is in a file, it means that the packet extends until the end of th e file.
The OpenPGP format headers have a mechanism for precisely encoding data of indet erminate length. The OpenPGP format headers have a mechanism for precisely encoding data of indet erminate length.
An implementation <bcp14>MUST NOT</bcp14> generate a Legacy format packet with i ndeterminate length. An implementation <bcp14>MUST NOT</bcp14> generate a Legacy format packet with i ndeterminate length.
An implementation <bcp14>MAY</bcp14> interpret an indeterminate length Legacy fo An implementation <bcp14>MAY</bcp14> interpret an indeterminate length Legacy fo
rmat packet in order to deal with historic data, or data generated by a legacy s rmat packet in order to deal with historic data or data generated by a legacy sy
ystem that predates support for <xref target="RFC2440"/>.</t> stem that predates support for <xref target="RFC2440"/>.
</dd> </dd>
</dl> </dl>
</section>
</section> <section anchor="packet-length-examples">
<section anchor="packet-length-examples"><name>Packet Length Examples</name> <name>Packet Length Examples</name>
<t>These examples show ways that OpenPGP format packets might encode t
<t>These examples show ways that OpenPGP format packets might encode the packet he packet body lengths.</t>
body lengths.</t> <ul>
<li>A packet body with length 100 may have its length encoded in one o
<t>A packet body with length 100 may have its length encoded in one octet: 0x64. ctet: 0x64.
This is followed by 100 octets of data.</t> This is followed by 100 octets of data.</li>
<li>A packet body with length 1723 may have its length encoded in two
<t>A packet body with length 1723 may have its length encoded in two octets: 0xC octets: 0xC5, 0xFB.
5, 0xFB. This header is followed by the 1723 octets of data.</li>
This header is followed by the 1723 octets of data.</t> <li>A packet body with length 100000 may have its length encoded in five octets:
0xFF, 0x00, 0x01, 0x86, 0xA0.</li>
<t>A packet body with length 100000 may have its length encoded in five octets: </ul>
0xFF, 0x00, 0x01, 0x86, 0xA0.</t> <t>It might also be encoded in the following octet stream:</t>
<ul>
<t>It might also be encoded in the following octet stream: 0xEF, first 32768 oct <li>0xEF, first 32768 octets of data;</li>
ets of data; 0xE1, next two octets of data; 0xE0, next one octet of data; 0xF0, <li>0xE1, next two octets of data;</li>
next 65536 octets of data; 0xC5, 0xDD, last 1693 octets of data. <li>0xE0, next one octet of data;</li>
This is just one possible encoding, and many variations are possible on the size <li>0xF0, next 65536 octets of data; and </li>
of the Partial Body Length headers, as long as a regular Body Length header enc <li>0xC5, 0xDD, last 1693 octets of data.</li>
odes the last portion of the data.</t> </ul>
<t>This is just one possible encoding, and many variations are possible on the s
<t>Please note that in all of these explanations, the total length of the packet ize of the Partial Body Length headers, as long as a regular Body Length header
is the length of the header(s) plus the length of the body.</t> encodes the last portion of the data.</t>
<t>Please note that in all of these explanations, the total length of
</section> the packet is the length of the header(s) plus the length of the body.</t>
</section> </section>
<section anchor="packet-criticality"><name>Packet Criticality</name> </section>
<section anchor="packet-criticality">
<t>The Packet Type ID space is partitioned into critical packets and non-critica <name>Packet Criticality</name>
l packets. <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 unkno wn in a packet sequence, it <bcp14>MUST</bcp14> reject the whole packet sequence (see <xref target="packet-sequence-composition"/>). If an implementation encounters a critical packet where the packet type is unkno wn 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> 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.
<t>Packets with Type IDs from 0 to 39 are critical.
Packets with Type IDs from 40 to 63 are non-critical.</t> Packets with Type IDs from 40 to 63 are non-critical.</t>
</section>
</section> </section>
</section> <section anchor="packet-types">
<section anchor="packet-types"><name>Packet Types</name> <name>Packet Types</name>
<t>The defined packet types are as follows:</t>
<t>The defined packet types are as follows:</t> <table anchor="packet-types-registry">
<name>OpenPGP Packet Types Registry</name>
<texttable title="OpenPGP Packet Types registry" anchor="packet-types-registry"> <thead>
<ttcol align='right'>ID</ttcol> <tr>
<ttcol align='left'>Critical</ttcol> <th align="right">ID</th>
<ttcol align='left'>Packet Type Description</ttcol> <th align="left">Critical</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Packet Type Description</th>
<ttcol align='left'>Shorthand</ttcol> <th align="left">Shorthand</th>
<c>0</c> <th align="left">Reference</th>
<c>yes</c> </tr>
<c>Reserved - a packet <bcp14>MUST NOT</bcp14> have this packet type ID</c </thead>
> <tbody>
<c>&#160;</c> <tr>
<c>&#160;</c> <td align="right">0</td>
<c>1</c> <td align="left">Yes</td>
<c>yes</c> <td align="left">Reserved - this packet type ID <bcp14>MUST NOT</bcp
<c>Public-Key Encrypted Session Key Packet</c> 14> be used</td>
<c><xref target="pkesk"/></c> <td align="left"> </td>
<c>PKESK</c> <td align="left"></td>
<c>2</c> </tr>
<c>yes</c> <tr>
<c>Signature Packet</c> <td align="right">1</td>
<c><xref target="signature-packet"/></c> <td align="left">Yes</td>
<c>SIG</c> <td align="left">Public-Key Encrypted Session Key Packet</td>
<c>3</c> <td align="left">PKESK</td>
<c>yes</c> <td align="left"><xref target="pkesk"/></td>
<c>Symmetric-Key Encrypted Session Key Packet</c> </tr>
<c><xref target="skesk"/></c> <tr>
<c>SKESK</c> <td align="right">2</td>
<c>4</c> <td align="left">Yes</td>
<c>yes</c> <td align="left">Signature Packet</td>
<c>One-Pass Signature Packet</c> <td align="left">SIG</td>
<c><xref target="one-pass-sig"/></c> <td align="left"><xref target="signature-packet"/></td>
<c>OPS</c> </tr>
<c>5</c> <tr>
<c>yes</c> <td align="right">3</td>
<c>Secret-Key Packet</c> <td align="left">Yes</td>
<c><xref target="seckey"/></c> <td align="left">Symmetric-Key Encrypted Session Key Packet</td>
<c>SECKEY</c> <td align="left">SKESK</td>
<c>6</c> <td align="left"><xref target="skesk"/></td>
<c>yes</c> </tr>
<c>Public-Key Packet</c> <tr>
<c><xref target="pubkey"/></c> <td align="right">4</td>
<c>PUBKEY</c> <td align="left">Yes</td>
<c>7</c> <td align="left">One-Pass Signature Packet</td>
<c>yes</c> <td align="left">OPS</td>
<c>Secret-Subkey Packet</c> <td align="left"><xref target="one-pass-sig"/></td>
<c><xref target="secsubkey"/></c> </tr>
<c>SECSUBKEY</c> <tr>
<c>8</c> <td align="right">5</td>
<c>yes</c> <td align="left">Yes</td>
<c>Compressed Data Packet</c> <td align="left">Secret-Key Packet</td>
<c><xref target="compressed-data"/></c> <td align="left">SECKEY</td>
<c>COMP</c> <td align="left"><xref target="seckey"/></td>
<c>9</c> </tr>
<c>yes</c> <tr>
<c>Symmetrically Encrypted Data Packet</c> <td align="right">6</td>
<c><xref target="sed"/></c> <td align="left">Yes</td>
<c>SED</c> <td align="left">Public-Key Packet</td>
<c>10</c> <td align="left">PUBKEY</td>
<c>yes</c> <td align="left"><xref target="pubkey"/></td>
<c>Marker Packet</c> </tr>
<c><xref target="marker-packet"/></c> <tr>
<c>MARKER</c> <td align="right">7</td>
<c>11</c> <td align="left">Yes</td>
<c>yes</c> <td align="left">Secret-Subkey Packet</td>
<c>Literal Data Packet</c> <td align="left">SECSUBKEY</td>
<c><xref target="lit"/></c> <td align="left"><xref target="secsubkey"/></td>
<c>LIT</c> </tr>
<c>12</c> <tr>
<c>yes</c> <td align="right">8</td>
<c>Trust Packet</c> <td align="left">Yes</td>
<c><xref target="trust"/></c> <td align="left">Compressed Data Packet</td>
<c>TRUST</c> <td align="left">COMP</td>
<c>13</c> <td align="left"><xref target="compressed-data"/></td>
<c>yes</c> </tr>
<c>User ID Packet</c> <tr>
<c><xref target="uid"/></c> <td align="right">9</td>
<c>UID</c> <td align="left">Yes</td>
<c>14</c> <td align="left">Symmetrically Encrypted Data Packet</td>
<c>yes</c> <td align="left">SED</td>
<c>Public-Subkey Packet</c> <td align="left"><xref target="compressed-data"/></td>
<c><xref target="pubsubkey"/></c> </tr>
<c>PUBSUBKEY</c> <tr>
<c>17</c> <td align="right">10</td>
<c>yes</c> <td align="left">Yes</td>
<c>User Attribute Packet</c> <td align="left">Marker Packet</td>
<c><xref target="user-attribute-packet"/></c> <td align="left">MARKER</td>
<c>UAT</c> <td align="left"><xref target="marker-packet"/></td>
<c>18</c> </tr>
<c>yes</c> <tr>
<c>Symmetrically Encrypted and Integrity Protected Data Packet</c> <td align="right">11</td>
<c><xref target="seipd"/></c> <td align="left">Yes</td>
<c>SEIPD</c> <td align="left">Literal Data Packet</td>
<c>19</c> <td align="left">LIT</td>
<c>yes</c> <td align="left"><xref target="marker-packet"/></td>
<c>Reserved (formerly Modification Detection Code Packet)</c> </tr>
<c>(see <xref target="version-one-seipd"/>)</c> <tr>
<c>&#160;</c> <td align="right">12</td>
<c>20</c> <td align="left">Yes</td>
<c>yes</c> <td align="left">Trust Packet</td>
<c>Reserved</c> <td align="left">TRUST</td>
<c>&#160;</c> <td align="left"><xref target="trust"/></td>
<c>&#160;</c> </tr>
<c>21</c> <tr>
<c>yes</c> <td align="right">13</td>
<c>Padding Packet</c> <td align="left">Yes</td>
<c><xref target="padding-packet"/></c> <td align="left">User ID Packet</td>
<c>PADDING</c> <td align="left">UID</td>
<c>22 to 39</c> <td align="left"><xref target="uid"/></td>
<c>yes</c> </tr>
<c>Unassigned Critical Packet</c> <tr>
<c>&#160;</c> <td align="right">14</td>
<c>&#160;</c> <td align="left">Yes</td>
<c>40 to 59</c> <td align="left">Public-Subkey Packet</td>
<c>no</c> <td align="left">PUBSUBKEY</td>
<c>Unassigned Non-Critical Packet</c> <td align="left"><xref target="pubsubkey"/></td>
<c>&#160;</c> </tr>
<c>&#160;</c> <tr>
<c>60 to 63</c> <td align="right">17</td>
<c>no</c> <td align="left">Yes</td>
<c>Private or Experimental Values</c> <td align="left">User Attribute Packet</td>
<c>&#160;</c> <td align="left">UAT</td>
<c>&#160;</c> <td align="left"><xref target="user-attribute-packet"/></td>
</texttable> </tr>
<tr>
<t>The labels in the "Shorthand" column are used for compact reference elsewhere <td align="right">18</td>
in this draft, and may also be used by implementations that provide debugging o <td align="left">Yes</td>
r inspection affordances for streams of OpenPGP packets.</t> <td align="left">Symmetrically Encrypted and Integrity Protected Dat
a Packet</td>
<section anchor="pkesk"><name>Public-Key Encrypted Session Key Packet (Type ID 1 <td align="left">SEIPD</td>
)</name> <td align="left"><xref target="seipd"/></td>
</tr>
<t>Zero or more Public-Key Encrypted Session Key (PKESK) packets and/or Symmetri <tr>
c-Key Encrypted Session Key packets (<xref target="skesk"/>) precede an encrypti <td align="right">19</td>
on container (that is, a Symmetrically Encrypted Integrity Protected Data packet <td align="left">Yes</td>
or --- for historic data --- a Symmetrically Encrypted Data packet), which hold <td align="left">Reserved (formerly Modification Detection Code Pack
s an encrypted message. et)</td>
The message is encrypted with the session key, and the session key is itself enc <td align="left"> </td>
rypted and stored in the Encrypted Session Key packet(s). <td align="left"><xref target="version-one-seipd"/></td>
The encryption container is preceded by one Public-Key Encrypted Session Key pac </tr>
ket for each OpenPGP key to which the message is encrypted. <tr>
The recipient of the message finds a session key that is encrypted to their publ <td align="right">20</td>
ic key, decrypts the session key, and then uses the session key to decrypt the m <td align="left">Yes</td>
essage.</t> <td align="left">Reserved</td>
<td align="left"> </td>
<t>The body of this packet starts with a one-octet number giving the version num <td align="left"></td>
ber of the packet type. </tr>
The currently defined versions are 3 and 6. <tr>
The remainder of the packet depends on the version.</t> <td align="right">21</td>
<td align="left">Yes</td>
<t>The versions differ in how they identify the recipient key, and in what they <td align="left">Padding Packet</td>
encode. <td align="left">PADDING</td>
<td align="left"><xref target="padding-packet"/></td>
</tr>
<tr>
<td align="right">22-39</td>
<td align="left">Yes</td>
<td align="left">Unassigned Critical Packets</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 Packets</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 Use</td>
<td align="left"> </td>
<td align="left"></td>
</tr>
</tbody>
</table>
<t>The labels in the "Shorthand" column are used for compact reference els
ewhere in this document, and they may also be used by implementations that provi
de debugging or inspection affordances for streams of OpenPGP packets.</t>
<section anchor="pkesk">
<name>Public-Key Encrypted Session Key Packet (Type ID 1)</name>
<t>Zero or more PKESK packets and/or SKESK packets (<xref target="skesk"
/>) precede an encryption container (that is, a Symmetrically Encrypted Integrit
y Protected Data (SEIPD) packet or -- for historic data -- a Symmetrically Encry
pted Data (SED) packet), which holds an encrypted message.
The message is encrypted with the session key, and the session key is itself enc
rypted and stored in the Encrypted Session Key packet(s). The encryption contain
er is preceded by one Public-Key Encrypted Session Key packet for each OpenPGP k
ey to which the message is encrypted. The recipient of the message finds a sessi
on 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 ver
sion 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 and in wha
t they encode.
The version of the PKESK packet must align with the version of the SEIPD packet (see <xref target="encrypted-message-versions"/>). 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 establi shed in <xref target="encrypted-message-versions"/>.</t> Any new version of the PKESK packet should be registered in the registry establi shed in <xref target="encrypted-message-versions"/>.</t>
<section anchor="v3-pkesk">
<section anchor="v3-pkesk"><name>Version 3 Public-Key Encrypted Session Key Pack <name>Version 3 Public-Key Encrypted Session Key Packet Format</name>
et Format</name> <t>A version 3 PKESK packet precedes a version 1 SEIPD packet (see <xr
ef target="version-one-seipd"/>).
<t>A version 3 Public-Key Encrypted Session Key (PKESK) packet precedes a versio In historic data, it is sometimes found preceding a deprecated SED packet; see <
n 1 Symmetrically Encrypted Integrity Protected Data (v1 SEIPD, see <xref target xref target="sed"/>.
="version-one-seipd"/>) packet.
In historic data, it is sometimes found preceding a deprecated Symmetrically Enc
rypted Data packet (SED, see <xref target="sed"/>).
A v3 PKESK packet <bcp14>MUST NOT</bcp14> precede a v2 SEIPD packet (see <xref t arget="encrypted-message-versions"/>).</t> A v3 PKESK packet <bcp14>MUST NOT</bcp14> precede a v2 SEIPD packet (see <xref t arget="encrypted-message-versions"/>).</t>
<t>The v3 PKESK packet consists of:</t>
<t>The v3 PKESK packet consists of:</t> <ul spacing="normal">
<li>A one-octet version number with value 3.
<t><list style="symbols"> </li>
<t>A one-octet version number with value 3.</t> <li>An eight-octet number that gives the Key ID of the public key to
<t>An eight-octet number that gives the Key ID of the public key to which the which the session key is encrypted.
session key is encrypted.
If the session key is encrypted to a subkey, then the Key ID of this subkey is u sed here instead of the Key ID of the primary key. If the session key is encrypted to a subkey, then the Key ID of this subkey is u sed 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 The Key ID may also be all zeros, for an "anonymous recipient" (see <xref target
="pkesk-notes"/>).</t> ="pkesk-notes"/>).
<t>A one-octet number giving the public-key algorithm used.</t> </li>
<t>A series of values comprising the encrypted session key. <li>A one-octet number giving the public-key algorithm used.
This is algorithm-specific and described below.</t> </li>
</list></t> <li>A series of values comprising the encrypted session key.
This is algorithm specific and described below.
<t>The public-key encryption algorithm (described in subsequent sections) is pas </li>
sed two values:</t> </ul>
<t>The public-key encryption algorithm (described in subsequent sectio
<t><list style="symbols"> ns) is passed two values:</t>
<t>The session key.</t> <ul spacing="normal">
<t>The one-octet algorithm identifier that specifies the symmetric encryption <li>The session key.
algorithm used to encrypt the following v1 SEIPD packet.</t> </li>
</list></t> <li>
<t>The one-octet algorithm identifier that specifies the symmetric
</section> encryption algorithm used to encrypt the v1 SEIPD packet described in the follo
<section anchor="v6-pkesk"><name>Version 6 Public-Key Encrypted Session Key Pack wing section.</t>
et Format</name> </li>
</ul>
<t>A version 6 Public-Key Encrypted Session Key (PKESK) packet precedes a versio </section>
n 2 Symmetrically Encrypted Integrity Protected Data (v2 SEIPD, see <xref target <section anchor="v6-pkesk">
="version-two-seipd"/>) packet. <name>Version 6 Public-Key Encrypted Session Key Packet Format</name>
A v6 PKESK packet <bcp14>MUST NOT</bcp14> precede a v1 SEIPD packet or a depreca <t>A version 6 PKESK packet precedes a version 2 SEIPD packet (see <xr
ted Symmetrically Encrypted Data packet (see <xref target="encrypted-message-ver ef target="version-two-seipd"/>).
sions"/>).</t> A v6 PKESK packet <bcp14>MUST NOT</bcp14> precede a v1 SEIPD packet or a depreca
ted SED packet (see <xref target="encrypted-message-versions"/>).</t>
<t>The v6 PKESK packet consists of the following fields:</t> <t>The v6 PKESK packet consists of the following fields:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>A one-octet version number with value 6.
<t>A one-octet version number with value 6.</t> </li>
<t>A one-octet size of the following two fields. <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 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 are omitted for an "anonymous recipient" (see <xref target="pkesk-notes"/>).
> </li>
<t>A one octet key version number.</t> <li>A one-octet key version number.
<t>The fingerprint of the public key or subkey to which the session key is enc </li>
rypted. <li>The fingerprint of the public key or subkey to which the session
Note that the length N of the fingerprint for a version 4 key is 20 octets; for key is encrypted.
a version 6 key N is 32.</t> Note that the length N of the fingerprint for a version 4 key is 20 octets; for
<t>A one-octet number giving the public-key algorithm used.</t> a version 6 key, N is 32.
<t>A series of values comprising the encrypted session key. </li>
This is algorithm-specific and described below.</t> <li>A one-octet number giving the public-key algorithm used.
</list></t> </li>
<li>A series of values comprising the encrypted session key.
<t>The session key is encrypted according to the public-key algorithm used, as d This is algorithm specific and described below.
escribed 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 algorit hm for a v6 PKESK packet, as it is included in the v2 SEIPD packet.</t> No symmetric encryption algorithm identifier is passed to the public-key algorit hm for a v6 PKESK packet, as it is included in the v2 SEIPD packet.</t>
</section>
</section> <section anchor="pkesk-rsa">
<section anchor="pkesk-rsa"><name>Algorithm-Specific Fields for RSA encryption</ <name>Algorithm-Specific Fields for RSA Encryption</name>
name> <ul spacing="normal">
<li>MPI of RSA-encrypted value m<sup>e</sup> mod n.
<t><list style="symbols"> </li>
<t>Multiprecision integer (MPI) of RSA-encrypted value m**e mod n.</t> </ul>
</list></t> <t>To produce the value "m" in the above formula, first concatenate th
e following values:</t>
<t>To produce the value "m" in the above formula, first concatenate the followin <ul spacing="normal">
g values:</t> <li>The one-octet algorithm identifier, if it was passed (in the cas
e of a v3 PKESK packet).
<t><list style="symbols"> </li>
<t>The one-octet algorithm identifier, if it was passed (in the case of a v3 P <li>The session key.
KESK packet).</t> </li>
<t>The session key.</t> <li>A two-octet checksum of the session key, equal to the sum of the
<t>A two-octet checksum of the session key, equal to the sum of the session ke session key octets, modulo 65536.
y octets, modulo 65536.</t> </li>
</list></t> </ul>
<t>Then, the above values are encoded using the PKCS#1 block encoding
<t>Then, the above values are encoded using the PKCS#1 block encoding EME-PKCS1- EME-PKCS1-v1_5, as described in Step 2 in <xref section="7.2.1" sectionFormat="o
v1_5 described in step 2 of <xref section="7.2.1" sectionFormat="of" target="RFC f" target="RFC8017"/> (see also <xref target="eme-pkcs1-v1-5-encode"/>).
8017"/> (see also <xref target="eme-pkcs1-v1-5-encode"/>). When decoding "m" during decryption, an implementation should follow St
When decoding "m" during decryption, an implementation should follow step 3 of < ep 3 in <xref section="7.2.2" sectionFormat="of" target="RFC8017"/> (see also <x
xref section="7.2.2" sectionFormat="of" target="RFC8017"/> (see also <xref targe ref target="eme-pkcs1-v1-5-decode"/>).</t>
t="eme-pkcs1-v1-5-decode"/>).</t> <t>Note that when an implementation forms several PKESK packets with o
ne session key, forming a message that can be decrypted by several keys, the imp
<t>Note that when an implementation forms several PKESKs with one session key, f lementation <bcp14>MUST</bcp14> make a new PKCS#1 encoding for each key. This de
orming a message that can be decrypted by several keys, the implementation <bcp1 fends against attacks such as those discussed in <xref target="HASTAD"/>.</t>
4>MUST</bcp14> make a new PKCS#1 encoding for each key. </section>
This defends against attacks such as those discussed in <xref target="HASTAD"/>. <section anchor="pkesk-elgamal">
</t> <name>Algorithm-Specific Fields for Elgamal Encryption</name>
<ul spacing="normal">
</section> <li>
<section anchor="pkesk-elgamal"><name>Algorithm-Specific Fields for Elgamal encr <t>MPI of Elgamal (Diffie-Hellman) value g<sup>k</sup> mod p.</t>
yption</name> </li>
<li>
<t><list style="symbols"> <t>MPI of Elgamal (Diffie-Hellman) value m * y<sup>k</sup> mod p.<
<t>MPI of Elgamal (Diffie-Hellman) value g**k mod p.</t> /t>
<t>MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.</t> </li>
</list></t> </ul>
<t>To produce the value "m" in the above formula, first concatenate th
<t>To produce the value "m" in the above formula, first concatenate the followin e following values:</t>
g values:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>The one-octet algorithm identifier, if it was passed (in the ca
<t>The one-octet algorithm identifier, if it was passed (in the case of a v3 P se of a v3 PKESK packet).</t>
KESK packet).</t> </li>
<t>The session key.</t> <li>
<t>A two-octet checksum of the session key, equal to the sum of the session ke <t>The session key.</t>
y octets, modulo 65536.</t> </li>
</list></t> <li>
<t>A two-octet checksum of the session key, equal to the sum of th
<t>Then, the above values are encoded using the PKCS#1 block encoding EME-PKCS1- e session key octets, modulo 65536.</t>
v1_5 described in step 2 of <xref section="7.2.1" sectionFormat="of" target="RFC </li>
8017"/> (see also <xref target="eme-pkcs1-v1-5-encode"/>). </ul>
When decoding "m" during decryption, an implementation should follow step 3 of < <t>Then, the above values are encoded using the PKCS#1 block encoding
xref section="7.2.2" sectionFormat="of" target="RFC8017"/> (see also <xref targe EME-PKCS1-v1_5, as described in Step 2 in <xref section="7.2.1" sectionFormat="o
t="eme-pkcs1-v1-5-decode"/>).</t> f" target="RFC8017"/> (see also <xref target="eme-pkcs1-v1-5-encode"/>).
When decoding "m" during decryption, an implementation should follow Step 3 in <
<t>Note that when an implementation forms several PKESKs with one session key, f xref section="7.2.2" sectionFormat="of" target="RFC8017"/> (see also <xref targe
orming a message that can be decrypted by several keys, the implementation <bcp1 t="eme-pkcs1-v1-5-decode"/>).</t>
4>MUST</bcp14> make a new PKCS#1 encoding for each key. <t>Note that when an implementation forms several PKESK packets with o
ne session key, forming a message that can be decrypted by several keys, the imp
lementation <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> This defends against attacks such as those discussed in <xref target="HASTAD"/>. </t>
<t>An implementation <bcp14>MUST NOT</bcp14> generate ElGamal v6 PKESK
packets.</t>
</section>
<section anchor="pkesk-ecdh">
<name>Algorithm-Specific Fields for ECDH Encryption</name>
<ul spacing="normal">
<li>MPI of an EC point representing an ephemeral public key in the p
oint format associated with the curve as specified in <xref target="ec-curves"/>
.
</li>
<li>A one-octet size, followed by a symmetric key encoded using the
method described in <xref target="ecdh"/>.
</li>
</ul>
</section>
<section anchor="pkesk-x25519">
<name>Algorithm-Specific Fields for X25519 Encryption</name>
<t>An implementation <bcp14>MUST NOT</bcp14> generate ElGamal v6 PKESKs.</t> <ul spacing="normal">
<li>32 octets representing an ephemeral X25519 public key.
</section> </li>
<section anchor="pkesk-ecdh"><name>Algorithm-Specific Fields for ECDH encryption <li>A one-octet size of the following fields.
</name> </li>
<li>The one-octet algorithm identifier, if it was passed (in the cas
<t><list style="symbols"> e of a v3 PKESK packet).
<t>MPI of an EC point representing an ephemeral public key, in the point forma </li>
t associated with the curve as specified in <xref target="ec-curves"/>.</t> <li>The encrypted session key.
<t>A one-octet size, followed by a symmetric key encoded using the method desc </li>
ribed in <xref target="ecdh"/>.</t> </ul>
</list></t> <t>See <xref section="6.1" sectionFormat="of" target="RFC7748"/> for m
ore details on the computation of the ephemeral public key and the shared secret
</section> . The HMAC-based Key Derivation Function (HKDF) <xref target="RFC5869"/> is then
<section anchor="pkesk-x25519"><name>Algorithm-Specific Fields for X25519 encryp used with SHA256 <xref target="RFC6234"/> and an info parameter of "OpenPGP X25
tion</name> 519" and no salt.
<t><list style="symbols">
<t>32 octets representing an ephemeral X25519 public key.</t>
<t>A one-octet size of the following fields.</t>
<t>The one-octet algorithm identifier, if it was passed (in the case of a v3 P
KESK packet).</t>
<t>The encrypted session key.</t>
</list></t>
<t>See <xref section="6.1" sectionFormat="of" target="RFC7748"/> for more detail
s on the computation of the ephemeral public key and the shared secret.
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">
<t>32 octets of the ephemeral X25519 public key from this packet.</t>
<t>32 octets of the recipient public key material.</t>
<t>32 octets of the shared secret.</t>
</list></t>
<t>The key produced from HKDF is used to encrypt the session key with AES-128 ke
y 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 P
KESK 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-1
92 or AES-256 (algorithm ID 7, 8 or 9).</t>
</section>
<section anchor="pkesk-x448"><name>Algorithm-Specific Fields for X448 encryption
</name>
<t><list style="symbols">
<t>56 octets representing an ephemeral X448 public key.</t>
<t>A one-octet size of the following fields.</t>
<t>The one-octet algorithm identifier, if it was passed (in the case of a v3 P
KESK packet).</t>
<t>The encrypted session key.</t>
</list></t>
<t>See <xref section="6.2" sectionFormat="of" target="RFC7748"/> for more detail
s on the computation of the ephemeral public key and the shared secret.
HKDF (<xref target="RFC5869"/>) is then used with SHA512 (<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> The input of HKDF is the concatenation of the following three values:</t>
<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>
</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><list style="symbols"> <t>Note that unlike Elliptic Curve Diffie-Hellman (ECDH), no checksum
<t>56 octets of the ephemeral X448 public key from this packet.</t> or padding are appended to the session key before key wrapping. Finally, note th
<t>56 octets of the recipient public key material.</t> at unlike the other public-key algorithms, in the case of a v3 PKESK packet, the
<t>56 octets of the shared secret.</t> symmetric algorithm ID is not encrypted. Instead, it is prepended to the encryp
</list></t> ted session key in plaintext.
In this case, the symmetric algorithm used <bcp14>MUST</bcp14> be AES-128, AES-1
<t>The key produced from HKDF is used to encrypt the session key with AES-256 ke 92, or AES-256 (algorithm IDs 7, 8, or 9, respectively).</t>
y wrap, as defined in <xref target="RFC3394"/>.</t> </section>
<section anchor="pkesk-x448">
<t>Note that unlike ECDH, no checksum or padding are appended to the session key <name>Algorithm-Specific Fields for X448 Encryption</name>
before key wrapping. <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 ca
se of a v3 PKESK packet).</t>
</li>
<li>
<t>The encrypted session key.</t>
</li>
</ul>
<t>See <xref section="6.2" sectionFormat="of" target="RFC7748"/> for m
ore details on the computation of the ephemeral public key and the shared secret
.
HKDF <xref target="RFC5869"/> is then used with SHA512 <xref target="RFC6234"/>
and an info parameter of "OpenPGP X448" and no salt. The input of HKDF is the co
ncatenation of the following three values:</t>
<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>
</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 s
ession key before key wrapping.
Finally, note that unlike the other public-key algorithms, in the case of a v3 P KESK packet, the symmetric algorithm ID is not encrypted. Finally, note that unlike the other public-key algorithms, in the case of a v3 P KESK packet, the symmetric algorithm ID is not encrypted.
Instead, it is prepended to the encrypted session key in plaintext. 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-1 In this case, the symmetric algorithm used <bcp14>MUST</bcp14> be AES-128, AES-1
92 or AES-256 (algorithm ID 7, 8 or 9).</t> 92, or AES-256 (algorithm ID 7, 8, or 9).</t>
</section>
</section> <section anchor="pkesk-notes">
<section anchor="pkesk-notes"><name>Notes on PKESK</name> <name>Notes on PKESK</name>
<t>An implementation <bcp14>MAY</bcp14> accept or use a Key ID of all
<t>An implementation <bcp14>MAY</bcp14> accept or use a Key ID of all zeros, or zeros, or an omitted key fingerprint, to hide the intended decryption key.
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. 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> This format helps reduce traffic analysis of messages.</t>
</section>
</section> </section>
</section> <section anchor="signature-packet">
<section anchor="signature-packet"><name>Signature Packet (Type ID 2)</name> <name>Signature Packet (Type ID 2)</name>
<t>A Signature packet describes a binding between some public key and so
<t>A Signature packet describes a binding between some public key and some data. me data.
The most common signatures are a signature of a file or a block of text, and a s The most common signatures are a signature of a file or a block of text and a si
ignature that is a certification of a User ID.</t> gnature that is a certification of a User ID.</t>
<t>Three versions of Signature packets are defined.
<t>Three versions of Signature packets are defined.
Version 3 provides basic signature information, while versions 4 and 6 provide a n expandable format with subpackets that can specify more information about the signature.</t> Version 3 provides basic signature information, while versions 4 and 6 provide a n 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
<t>For historical reasons, versions 1, 2, and 5 of the Signature packet are unsp are unspecified.
ecified.
Any new Signature packet version should be registered in the registry establishe d in <xref target="signed-message-versions"/>.</t> Any new Signature packet version should be registered in the registry establishe d in <xref target="signed-message-versions"/>.</t>
<t>An implementation <bcp14>MUST</bcp14> generate a version 6 signature
<t>An implementation <bcp14>MUST</bcp14> generate a version 6 signature when sig when signing with a version 6 key.
ning with a version 6 key.
An implementation <bcp14>MUST</bcp14> generate a version 4 signature when signin g with a version 4 key. An implementation <bcp14>MUST</bcp14> generate a version 4 signature when signin g with a version 4 key.
Implementations <bcp14>MUST NOT</bcp14> create version 3 signatures; they <bcp14 >MAY</bcp14> accept version 3 signatures. 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 versi on correspondence between keys and signatures.</t> See <xref target="signed-message-versions"/> for more details about packet versi on correspondence between keys and signatures.</t>
<section anchor="signature-types">
<section anchor="signature-types"><name>Signature Types</name> <name>Signature Types</name>
<t>There are a number of possible meanings for a signature, which are
<t>There are a number of possible meanings for a signature, which are indicated indicated by the signature type ID in any given signature. Please note that the
by the signature type ID in any given signature. vagueness of these meanings is not a flaw but rather a feature of the system.
Please note that the vagueness of these meanings is not a flaw, but a feature of
the system.
Because OpenPGP places final authority for validity upon the receiver of a signa ture, it may be that one signer's casual act might be more rigorous than some ot her authority's positive act. Because OpenPGP places final authority for validity upon the receiver of a signa ture, it may be that one signer's casual act might be more rigorous than some ot her authority's positive act.
See <xref target="computing-signatures"/> for detailed information on how to com pute and verify signatures of each type.</t> See <xref target="computing-signatures"/> for detailed information on how to com pute and verify signatures of each type.</t>
<table anchor="signature-types-registry">
<name>OpenPGP Signature Types 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 Signature</td>
<td align="left">
<xref target="sigtype-generic-cert"/></td>
</tr>
<tr>
<td align="left">0x11</td>
<td align="left">Persona Certification Signature</td>
<td align="left">
<xref target="sigtype-persona-cert"/></td>
</tr>
<tr>
<td align="left">0x12</td>
<td align="left">Casual Certification Signature</td>
<td align="left">
<xref target="sigtype-casual-cert"/></td>
</tr>
<tr>
<td align="left">0x13</td>
<td align="left">Positive Certification Signature</td>
<td align="left">
<xref target="sigtype-positive-cert"/></td>
</tr>
<tr>
<td align="left">0x18</td>
<td align="left">Subkey Binding 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</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 Signature</td>
<td align="left">
<xref target="sigtype-key-revocation"/></td>
</tr>
<tr>
<td align="left">0x28</td>
<td align="left">Subkey Revocation Signature</td>
<td align="left">
<xref target="sigtype-subkey-revocation"/></td>
</tr>
<tr>
<td align="left">0x30</td>
<td align="left">Certification Revocation Signature</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 Signature</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 subsection
s below.</t>
<texttable title="OpenPGP Signature Types registry" anchor="signature-types-regi <section anchor="sigtype-binary">
stry"> <name>Binary Signature (type ID 0x00) of a Document</name>
<ttcol align='left'>ID</ttcol> <t>This means the signer owns it, created it, or certifies that it h
<ttcol align='left'>Name</ttcol> as not been modified.</t>
<ttcol align='left'>Reference</ttcol> </section>
<c>0x00</c> <section anchor="sigtype-text">
<c>Binary Signature</c> <name>Text Signature (type ID 0x01) of a Canonical Document</name>
<c><xref target="sigtype-binary"/></c> <t>This means the signer owns it, created it, or certifies that it h
<c>0x01</c> as not been modified.
<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 Binding Signature</c>
<c><xref target="sigtype-subkey-binding"/></c>
<c>0x19</c>
<c>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 meanings of each signature type are described in the subsections below.
</t>
<section anchor="sigtype-binary"><name>Signature of a binary document (type ID 0
x00)</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 of a canonical text document (typ
e 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 t o &lt;CR&gt;&lt;LF&gt;.</t> The signature is calculated over the text data with its line endings converted t o &lt;CR&gt;&lt;LF&gt;.</t>
</section>
</section> <section anchor="sigtype-standalone">
<section anchor="sigtype-standalone"><name>Standalone signature (type ID 0x02)</ <name>Standalone Signature (type ID 0x02)</name>
name> <t>This signature is a signature of only its own subpacket contents.
<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. 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> V3 standalone signatures <bcp14>MUST NOT</bcp14> be generated and <bcp14>MUST</ bcp14> be ignored.</t>
</section>
</section> <section anchor="sigtype-generic-cert">
<section anchor="sigtype-generic-cert"><name>Generic certification of a User ID <name>Generic Certification Signature (type ID 0x10) of a User ID an
and Public-Key packet (type ID 0x10)</name> d Public-Key Packet</name>
<t>The issuer of this certification does not make any particular ass
<t>The issuer of this certification does not make any particular assertion as to ertion as to how well the certifier has checked that the owner of the key is in
how well the certifier has checked that the owner of the key is in fact the per fact the person described by the User ID.</t>
son described by the User ID.</t> </section>
<section anchor="sigtype-persona-cert">
</section> <name>Persona Certification Signature (type ID 0x11) of a User ID an
<section anchor="sigtype-persona-cert"><name>Persona certification of a User ID d Public-Key Packet</name>
and Public-Key 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>
<t>The issuer of this certification has not done any verification of the claim t </section>
hat the owner of this key is the User ID specified.</t> <section anchor="sigtype-casual-cert">
<name>Casual Certification Signature (type ID 0x12) of a User ID and
</section> Public-Key Packet</name>
<section anchor="sigtype-casual-cert"><name>Casual certification of a User ID an <t>The issuer of this certification has done some casual verificatio
d Public-Key packet (type ID 0x12)</name> n of the claim of identity.</t>
</section>
<t>The issuer of this certification has done some casual verification of the cla <section anchor="sigtype-positive-cert">
im of identity.</t> <name>Positive Certification Signature (type ID 0x13) of a User ID a
nd Public-Key Packet</name>
</section> <t>The issuer of this certification has done substantial verificatio
<section anchor="sigtype-positive-cert"><name>Positive certification of a User I n of the claim of identity.</t>
D and Public-Key packet (type ID 0x13)</name> <t>Most OpenPGP implementations make their "key signatures" as gener
ic (type ID 0x10) certifications. Some implementations can issue 0x11-0x13 certi
<t>The issuer of this certification has done substantial verification of the cla fications, but few differentiate between the types.</t>
im of identity.</t> </section>
<section anchor="sigtype-subkey-binding">
<t>Most OpenPGP implementations make their "key signatures" as generic (type ID <name>Subkey Binding Signature (type ID 0x18)</name>
0x10) certifications. <t>This signature is a statement by the top-level signing key, indic
Some implementations can issue 0x11-0x13 certifications, but few differentiate b ating that it owns the subkey. This signature is calculated directly on the prim
etween the types.</t> ary key and subkey, and not on any User ID or other packets. A signature that bi
nds a signing subkey <bcp14>MUST</bcp14> have an Embedded Signature subpacket in
</section> this binding signature that contains a 0x19 signature made by the signing subke
<section anchor="sigtype-subkey-binding"><name>Subkey Binding Signature (type ID y on the primary key and subkey.</t>
0x18)</name> </section>
<section anchor="sigtype-primary-binding">
<t>This signature is a statement by the top-level signing key that indicates tha <name>Primary Key Binding Signature (type ID 0x19)</name>
t it owns the subkey. <t>This signature is a statement by a signing subkey, indicating tha
This signature is calculated directly on the primary key and subkey, and not on t it is owned by the primary key.
any User ID or other packets.
A signature that binds a signing subkey <bcp14>MUST</bcp14> have an Embedded Sig
nature subpacket in this binding signature that contains a 0x19 signature made b
y the signing subkey on the primary key and subkey.</t>
</section>
<section anchor="sigtype-primary-binding"><name>Primary Key Binding Signature (t
ype ID 0x19)</name>
<t>This signature is a statement by a signing subkey, indicating that it is owne
d 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> 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> <section anchor="sigtype-direct-key">
<section anchor="sigtype-direct-key"><name>Direct Key Signature (type ID 0x1F)</ <name>Direct Key Signature (type ID 0x1F)</name>
name> <t>This signature is calculated directly on a key.
It binds the information in the Signature subpackets to the key and is appropria
<t>This signature is calculated directly on a key. te to be used for subpackets that provide information about the key, such as the
It binds the information in the Signature subpackets to the key, and is appropri Key Flags subpacket or the (deprecated) Revocation Key subpacket.
ate to be used for subpackets that provide information about the key, such as th It is also appropriate for statements that non-self certifiers want to make abou
e Key Flags subpacket or (deprecated) Revocation Key. t the key itself rather than the binding between a key and a name.</t>
It is also appropriate for statements that non-self certifiers want to make abou </section>
t the key itself, rather than the binding between a key and a name.</t> <section anchor="sigtype-key-revocation">
<name>Key Revocation Signature (type ID 0x20)</name>
</section> <t>This signature is calculated directly on the key being revoked.
<section anchor="sigtype-key-revocation"><name>Key revocation signature (type ID A revoked key is not to be used. Only revocation signatures by the key being rev
0x20)</name> oked, or by a (deprecated) Revocation Key, should be considered valid revocation
signatures.</t>
<t>The signature is calculated directly on the key being revoked. </section>
A revoked key is not to be used. <section anchor="sigtype-subkey-revocation">
Only revocation signatures by the key being revoked, or by a (deprecated) Revoca <name>Subkey Revocation Signature (type ID 0x28)</name>
tion Key, should be considered valid revocation signatures.</t> <t>This signature is calculated directly on the primary key and the
subkey being revoked.
</section>
<section anchor="sigtype-subkey-revocation"><name>Subkey revocation signature (t
ype ID 0x28)</name>
<t>The signature is calculated directly on the primary key and the subkey being
revoked.
A revoked subkey is not to be used. 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 revocati on signatures.</t> 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 revocati on signatures.</t>
</section>
</section> <section anchor="sigtype-certification-revocation">
<section anchor="sigtype-certification-revocation"><name>Certification revocatio <name>Certification Revocation Signature (type ID 0x30)</name>
n 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).
<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 (d eprecated) Revocation Key. It should be issued by the same key that issued the revoked signature or by a (d eprecated) Revocation Key.
The signature is computed over the same data as the certification that it revoke The signature is computed over the same data as the certification that it revoke
s, and should have a later creation date than that certification.</t> s, and it should have a later creation date than that certification.</t>
</section>
</section> <section anchor="sigtype-timestamp">
<section anchor="sigtype-timestamp"><name>Timestamp signature (type ID 0x40)</na <name>Timestamp Signature (type ID 0x40)</name>
me> <t>This signature is only meaningful for the timestamp contained in
it.</t>
<t>This signature is only meaningful for the timestamp contained in it.</t> </section>
<section anchor="sigtype-third-party-confirmation">
</section> <name>Third-Party Confirmation Signature (type ID 0x50)</name>
<section anchor="sigtype-third-party-confirmation"><name>Third-Party Confirmatio <t>This signature is a signature over some other OpenPGP Signature p
n signature (type ID 0x50)</name> acket(s).
It is analogous to a notary seal on the signed data. A third-party signature <bc
<t>This signature is a signature over some other OpenPGP Signature packet(s). p14>SHOULD</bcp14> include one or more Signature Target subpackets to give easy
It is analogous to a notary seal on the signed data. identification. Note that we really do mean <bcp14>SHOULD</bcp14>.
A third-party signature <bcp14>SHOULD</bcp14> include 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 sign ature, not the key or source document) that cannot include a target subpacket.</ t> There are plausible uses for this (such as a blind party that only sees the sign ature, not the key or source document) that cannot include a target subpacket.</ t>
</section>
</section> <section anchor="sigtype-reserved">
<section anchor="sigtype-reserved"><name>Reserved (type ID 0xFF)</name> <name>Reserved (type ID 0xFF)</name>
<t>An implementation <bcp14>MUST NOT</bcp14> create any signature wi
<t>An implementation <bcp14>MUST NOT</bcp14> create any signature with this type th this type and <bcp14>MUST NOT</bcp14> validate any signature made with this t
, and <bcp14>MUST NOT</bcp14> validate any signature made with this type. ype.
See <xref target="sig-computation-notes"/> for more details.</t> See <xref target="sig-computation-notes"/> for more details.</t>
</section>
</section> </section>
</section> <section anchor="version-three-sig">
<section anchor="version-three-sig"><name>Version 3 Signature Packet Format</nam <name>Version 3 Signature Packet Format</name>
e> <t>The body of a version 3 Signature packet contains:</t>
<ul spacing="normal">
<t>The body of a version 3 Signature packet contains:</t> <li>
<t>A one-octet version number with value 3.</t>
<t><list style="symbols"> </li>
<t>One-octet version number (3).</t> <li>
<t>One-octet length of following hashed material. <t>A one-octet length of the following hashed material; it
<bcp14>MUST</bcp14> be 5. <list style="symbols"> <bcp14>MUST</bcp14> be 5: </t>
<t>One-octet signature type ID.</t> <ul spacing="normal">
<t>Four-octet creation time.</t> <li>
</list></t> <t>A one-octet signature type ID.</t>
<t>Eight-octet Key ID of signer.</t> </li>
<t>One-octet public-key algorithm.</t> <li>
<t>One-octet hash algorithm.</t> <t>A four-octet creation time.</t>
<t>Two-octet field holding left 16 bits of signed hash value.</t> </li>
<t>One or more multiprecision integers comprising the signature. </ul>
This portion is algorithm-specific, as described below.</t> </li>
</list></t> <li>
<t>An eight-octet Key ID of the signer.</t>
<t>The concatenation of the data to be signed, the signature type, and creation </li>
time from the Signature packet (5 additional octets) is hashed. <li>
<t>A one-octet public-key algorithm.</t>
</li>
<li>
<t>A one-octet hash algorithm.</t>
</li>
<li>
<t>A two-octet field holding left 16 bits of the signed hash value
.</t>
</li>
<li>
<t>One or more MPIs comprising the signature. This portion is algo
rithm specific, as described below.</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 resulting hash value is used in the signature algorithm.
The high 16 bits (first two octets) of the hash are included in the Signature pa cket to provide a way to reject some invalid signatures without performing a sig nature verification.</t> The high 16 bits (first two octets) of the hash are included in the Signature pa cket to provide a way to reject some invalid signatures without performing a sig nature verification.</t>
<t>Algorithm-specific fields for RSA signatures:</t>
<t>Algorithm-Specific Fields for RSA signatures:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>MPI of RSA signature value m<sup>d</sup> mod n.</t>
<t>Multiprecision integer (MPI) of RSA signature value m**d mod n.</t> </li>
</list></t> </ul>
<t>Algorithm-specific fields for DSA signatures:</t>
<t>Algorithm-Specific Fields for DSA signatures:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>MPI of DSA value r.</t>
<t>MPI of DSA value r.</t> </li>
<t>MPI of DSA value s.</t> <li>
</list></t> <t>MPI of DSA value s.</t>
</li>
<t>The signature calculation is based on a hash of the signed data, as described </ul>
above. <t>The signature calculation is based on a hash of the signed data, as
The details of the calculation are different for DSA signatures than for RSA sig described above.
natures, see <xref target="sig-rsa"/> and <xref target="sig-dsa"/>.</t> The details of the calculation are different for DSA signatures than for RSA sig
natures; see Sections <xref target="sig-rsa" format="counter"/> and <xref target
</section> ="sig-dsa" format="counter"/>.</t>
<section anchor="version-four-and-six-sig"><name>Version 4 and 6 Signature Packe </section>
t Formats</name> <section 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>The body of a v4 or v6 Signature packet contains:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>One-octet version number. <t>A one-octet version number.
This is 4 for v4 signatures and 6 for v6 signatures.</t> This is 4 for v4 signatures and 6 for v6 signatures.</t>
<t>One-octet signature type ID.</t> </li>
<t>One-octet public-key algorithm.</t> <li>
<t>One-octet hash algorithm.</t> <t>A one-octet signature type ID.</t>
<t>A scalar octet count for the hashed subpacket data that follows this field. </li>
For a v4 signature, this is a two-octet field. <li>
<t>A one-octet public-key algorithm.</t>
</li>
<li>
<t>A one-octet hash algorithm.</t>
</li>
<li>
<t>A 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. 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 imple mentation's pointer incremented by this number will skip over the hashed subpack ets.</t> Note that this is the length in octets of all of the hashed subpackets; an imple mentation's pointer incremented by this number will skip over the hashed subpack ets.</t>
<t>Hashed subpacket data set (zero or more subpackets).</t> </li>
<t>A scalar octet count for the unhashed subpacket data that follows this fiel <li>
d. <t>A hashed subpacket data set (zero or more subpackets).</t>
</li>
<li>
<t>A scalar octet count for the unhashed subpacket data that follo
ws this field.
For a v4 signature, this is a two-octet field. For a v4 signature, this is a two-octet field.
For a v6 signature, this is a four-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 imp lementation's pointer incremented by this number will skip over the unhashed sub packets.</t> Note that this is the length in octets of all of the unhashed subpackets; an imp lementation's pointer incremented by this number will skip over the unhashed sub packets.</t>
<t>Unhashed subpacket data set (zero or more subpackets).</t> </li>
<t>Two-octet field holding the left 16 bits of the signed hash value.</t> <li>
<t>Only for v6 signatures, a variable-length field containing: <list style="s <t>An unhashed subpacket data set (zero or more subpackets).</t>
ymbols"> </li>
<t>A one-octet salt size. The value <bcp14>MUST</bcp14> match the value de <li>
fined for the hash algorithm as specified in <xref target="hash-algorithms-regis <t>A two-octet field holding the left 16 bits of the signed hash v
try"/>.</t> alue.</t>
<t>The salt; a random value of the specified size.</t> </li>
</list></t> <li>
<t>One or more multiprecision integers comprising the signature. <t>Only for v6 signatures, a variable-length field containing: </
This portion is algorithm-specific:</t> t>
</list></t> <ul spacing="normal">
<li>
<section anchor="sig-rsa"><name>Algorithm-Specific Fields for RSA signatures</na <t>A one-octet salt size. The value <bcp14>MUST</bcp14> match
me> the value defined for the hash algorithm as specified in <xref target="hash-algo
rithms-registry"/>.</t>
<t><list style="symbols"> </li>
<t>Multiprecision integer (MPI) of RSA signature value m**d mod n.</t> <li>
</list></t> <t>The salt, which is a random value of the specified size.</t
>
<t>With RSA signatures, the hash value is encoded using PKCS#1 encoding type EMS </li>
A-PKCS1-v1_5 as described in <xref section="9.2" sectionFormat="of" target="RFC8 </ul>
017"/> (see also <xref target="emsa-pkcs1-v1-5"/>). </li>
<li>
<t>One or more MPIs comprising the signature.
This portion is algorithm specific.</t>
</li>
</ul>
<section anchor="sig-rsa">
<name>Algorithm-Specific Fields for RSA Signatures</name>
<ul spacing="normal">
<li>
<t>MPI of RSA signature value m<sup>d</sup> mod n.</t>
</li>
</ul>
<t>With RSA signatures, the hash value is encoded using PKCS#1 encod
ing type 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 structur e. This requires inserting the hash value as an octet string into an ASN.1 structur e.
The object identifier (OID) for the hash algorithm itself is also included in th The object identifier (OID) for the hash algorithm itself is also included in th
e structure, see the OIDs in <xref target="emsa-hash-oids-registry"/>.</t> e structure; see the OIDs in <xref target="emsa-hash-oids-registry"/>.</t>
</section>
</section> <section anchor="sig-dsa">
<section anchor="sig-dsa"><name>Algorithm-Specific Fields for DSA or ECDSA signa <name>Algorithm-Specific Fields for DSA or ECDSA Signatures</name>
tures</name> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>MPI of DSA or ECDSA value r.</t>
<t>MPI of DSA or ECDSA value r.</t> </li>
<t>MPI of DSA or ECDSA value s.</t> <li>
</list></t> <t>MPI of DSA or ECDSA value s.</t>
</li>
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp14>MUST NOT< </ul>
/bcp14> be used with ECDSA.</t> <t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp
14>MUST NOT</bcp14> be used with the Elliptic Curve Digital Signature Algorithm
<t>A DSA signature <bcp14>MUST</bcp14> use a hash algorithm with a digest size o (ECDSA).</t>
f at least the number of bits of q, the group generated by the DSA key's generat <t>A DSA signature <bcp14>MUST</bcp14> use a hash algorithm with a d
or value.</t> igest size of at least the number of bits of q, the group generated by the DSA k
ey's generator value.</t>
<t>If the output size of the chosen hash is larger than the number of bits of q, <t>If the output size of the chosen hash is larger than the number o
the hash result is truncated to fit by taking the number of leftmost bits equal f bits of q, the hash result is truncated to fit by taking the number of leftmos
to the number of bits of q. t bits equal to the number of bits of q.
This (possibly truncated) hash function result is treated as a number and used d irectly in the DSA signature algorithm.</t> This (possibly truncated) hash function result is treated as a number and used d irectly in the DSA signature algorithm.</t>
<t>An ECDSA signature <bcp14>MUST</bcp14> use a hash algorithm with
<t>An ECDSA signature <bcp14>MUST</bcp14> use a hash algorithm with a digest siz a digest size of at least the curve's "fsize" value (see <xref target="ec-curves
e of at least the curve's "fsize" value (see <xref target="ec-curves"/>), except "/>), except in the case of NIST P-521, for which at least a 512-bit hash algori
in the case of NIST P-521, for which at least a 512-bit hash algorithm <bcp14>M thm <bcp14>MUST</bcp14> be used.</t>
UST</bcp14> be used.</t> </section>
<section anchor="sig-eddsa-legacy">
</section> <name>Algorithm-Specific Fields for EdDSALegacy Signatures (Deprecat
<section anchor="sig-eddsa-legacy"><name>Algorithm-Specific Fields for EdDSALega ed)</name>
cy signatures (deprecated)</name> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>Two MPI-encoded values, whose contents and formatting depend
<t>Two MPI-encoded values, whose contents and formatting depend on the choice on the choice of curve used (see <xref target="curve-specific-formats"/>).</t>
of curve used (see <xref target="curve-specific-formats"/>).</t> </li>
</list></t> </ul>
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp14>MUST NOT< 14>MUST NOT</bcp14> be used with EdDSALegacy.</t>
/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-
<t>An EdDSALegacy signature <bcp14>MUST</bcp14> use a hash algorithm with a dige curves"/>).
st 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> 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-signatu
<section anchor="algorithm-specific-fields-for-ed25519legacy-signatures-deprecat res-deprecated">
ed"><name>Algorithm-Specific Fields for Ed25519Legacy signatures (deprecated)</n <name>Algorithm-Specific Fields for Ed25519Legacy Signatures (Depr
ame> ecated)</name>
<t>The two MPIs for Ed25519Legacy represent the octet strings R an
<t>The two MPIs for Ed25519Legacy use octet strings R and S as described in <xre d S of the Edwards-curve Digital Signature Algorithm (EdDSA) described in <xref
f target="RFC8032"/>. target="RFC8032"/>.
Ed25519Legacy <bcp14>MUST NOT</bcp14> be used in signature packets version 6 or </t>
above.</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>MPI of an EC point R, represented as a (non-prefixed) nativ
<t>MPI of an EC point R, represented as a (non-prefixed) native (little-endian e (little-endian) octet string up to 32 octets.</t>
) octet string up to 32 octets.</t> </li>
<t>MPI of EdDSA value S, also in (non-prefixed) native (little-endian) format <li>
with a length up to 32 octets.</t> <t>MPI of EdDSA value S, also in (non-prefixed) native (little
</list></t> -endian) format with a length up to 32 octets.</t>
</li>
</section> </ul>
</section> <t>
<section anchor="sig-ed25519"><name>Algorithm-Specific Fields for Ed25519 signat Ed25519Legacy <bcp14>MUST NOT</bcp14> be used in signature packets version 6 or
ures</name> above.
</t>
<t><list style="symbols"> </section>
<t>64 octets of the native signature.</t> </section>
</list></t> <section anchor="sig-ed25519">
<name>Algorithm-Specific Fields for Ed25519 Signatures</name>
<t>For more details, see <xref target="eddsa-notes"/>.</t> <ul spacing="normal">
<li>
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp14>MUST NOT< <t>64 octets of the native signature.</t>
/bcp14> be used with Ed25519.</t> </li>
</ul>
<t>An Ed25519 signature <bcp14>MUST</bcp14> use a hash algorithm with a digest s <t>For more details, see <xref target="eddsa-notes"/>.</t>
ize of at least 256 bits. <t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp
14>MUST NOT</bcp14> be used with Ed25519.</t>
<t>An Ed25519 signature <bcp14>MUST</bcp14> use a hash algorithm wit
h 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> A verifying implementation <bcp14>MUST</bcp14> reject any Ed25519 signature that uses a hash algorithm with a smaller digest size.</t>
</section>
</section> <section anchor="sig-ed448">
<section anchor="sig-ed448"><name>Algorithm-Specific Fields for Ed448 signatures <name>Algorithm-Specific Fields for Ed448 Signatures</name>
</name> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>114 octets of the native signature.</t>
<t>114 octets of the native signature.</t> </li>
</list></t> </ul>
<t>For more details, see <xref target="eddsa-notes"/>.</t>
<t>For more details, see <xref target="eddsa-notes"/>.</t> <t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp
14>MUST NOT</bcp14> be used with Ed448.</t>
<t>A version 3 signature <bcp14>MUST NOT</bcp14> be created and <bcp14>MUST NOT< <t>An Ed448 signature <bcp14>MUST</bcp14> use a hash algorithm with
/bcp14> be used with Ed448.</t> a digest size of at least 512 bits.
<t>An Ed448 signature <bcp14>MUST</bcp14> use a hash algorithm with a digest siz
e of at least 512 bits.
A verifying implementation <bcp14>MUST</bcp14> reject any Ed448 signature that u ses a hash algorithm with a smaller digest size.</t> A verifying implementation <bcp14>MUST</bcp14> reject any Ed448 signature that u ses a hash algorithm with a smaller digest size.</t>
</section>
</section> <section anchor="notes-on-signatures">
<section anchor="notes-on-signatures"><name>Notes on Signatures</name> <name>Notes on Signatures</name>
<t>The concatenation of the data being signed, the signature data fr
<t>The concatenation of the data being signed, the signature data from the versi om the version number through the hashed subpacket data (inclusive), and (for si
on number through the hashed subpacket data (inclusive), and (for signature vers gnature versions later than 3) a six-octet trailer (see <xref target="computing-
ions later than 3) a six-octet trailer (see <xref target="computing-signatures"/ signatures"/>) is hashed. The resulting hash value is what is signed. The high 1
>) is hashed. 6 bits (first two octets) of the hash are included in the Signature packet to pr
The resulting hash value is what is signed. ovide a way to reject some invalid signatures without performing a signature ver
The high 16 bits (first two octets) of the hash are included in the Signature pa ification. When verifying a v6 signature, an implementation <bcp14>MUST</bcp14>
cket to provide a way to reject some invalid signatures without performing a sig reject the signature if these octets do not match the first two octets of the co
nature verification. mputed hash.</t>
When verifying a v6 signature, an implementation <bcp14>MUST</bcp14> reject the <t>There are two fields consisting of Signature subpackets.
signature if these octets don't match the first two octets of the computed hash. The first field is hashed with the rest of the signature data, while the second
</t> is not hashed into the signature. The second set of subpackets (the "unhashed se
ction") is not cryptographically protected by the signature and should include o
<t>There are two fields consisting of Signature subpackets. nly advisory information. See <xref target="subpacket-section-guidance"/> for mo
The first field is hashed with the rest of the signature data, while the second re information.</t>
is not hashed into the signature. <t>The differences between a v4 and v6 signature are two-fold: first
The second set of subpackets (the "unhashed section") is not cryptographically p , a v6 signature increases the width of the fields that indicate the size of the
rotected by the signature and should include only advisory information. hashed and unhashed subpackets, making it possible to include significantly mor
See <xref target="subpacket-section-guidance"/> for more information.</t> e data in subpackets.
<t>The differences between a v4 and v6 signature are two-fold: first, a v6 signa
ture 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 su
bpackets.
Second, the hash is salted with random data (see <xref target="signature-salt-ra tionale"/>).</t> Second, the hash is salted with random data (see <xref target="signature-salt-ra tionale"/>).</t>
<t>The algorithms for converting the hash function result to a signa
<t>The algorithms for converting the hash function result to a signature are des ture are described in <xref target="computing-signatures"/>.</t>
cribed in <xref target="computing-signatures"/>.</t> </section>
<section anchor="signature-subpacket">
</section> <name>Signature Subpacket Specification</name>
<section anchor="signature-subpacket"><name>Signature Subpacket Specification</n <t>A subpacket data set consists of zero or more Signature subpacket
ame> s.
<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 octe ts of all the 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 octe ts of all the subpackets.
A pointer incremented by this number will skip over the subpacket data set.</t> 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.
<t>Each subpacket consists of a subpacket header and a body.
The header consists of:</t> The header consists of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>The encoded subpacket length (1, 2, or 5 octets).
<t>The subpacket length (1, 2, or 5 octets),</t> </li>
<t>The encoded subpacket type ID (1 octet),</t> <li>The encoded subpacket type ID (1 octet).
</list></t> </li>
<li>The subpacket-specific data.
<t>and is followed by the subpacket-specific data.</t> </li>
</ul>
<t>The length includes the encoded subpacket type ID octet but not this length. <t>The subpacket length field covers the encoded subpacket type ID a
Its format is similar to the OpenPGP format packet header lengths, but cannot ha nd the subpacket-specific data, and it does not include the subpacket length fie
ve Partial Body Lengths. ld itself. It is encoded similarly to a one-octet, two-octet, or five-octet Open
That is:</t> PGP format packet header. The encoded subpacket length can be decoded as follows
:</t>
<figure><artwork><![CDATA[ <artwork><![CDATA[
if the 1st octet < 192, then if the 1st octet < 192, then
lengthOfLength = 1 lengthOfLength = 1
subpacketLen = 1st_octet subpacketLen = 1st_octet
if the 1st octet >= 192 and < 255, then if the 1st octet >= 192 and < 255, then
lengthOfLength = 2 lengthOfLength = 2
subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192 subpacketLen = ((1st_octet - 192) << 8) + (2nd_octet) + 192
if the 1st octet = 255, then if the 1st octet = 255, then
lengthOfLength = 5 lengthOfLength = 5
subpacket length = [four-octet scalar starting at 2nd_octet] 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.
<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
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 crit
of the signature to recognize. ical but is unknown to the evaluating implementation, the evaluator <bcp14>SHOUL
If a subpacket is encountered that is marked critical but is unknown to the eval D</bcp14> consider the signature to be in error.</t>
uating implementation, the evaluator <bcp14>SHOULD</bcp14> consider the signatur <t>An implementation <bcp14>SHOULD</bcp14> ignore any non-critical s
e to be in error.</t> ubpacket of a type that it does not recognize.</t>
<t>An evaluator may "recognize" a subpacket but not implement it.
<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, 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 i gnored.</t> 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 i gnored.</t>
<t>The other bits of the encoded subpacket type ID (i.e., bits 6-0)
contain the subpacket type ID.</t>
<t>The following signature subpackets are defined:</t>
<table anchor="signature-subpacket-types-registry">
<name>OpenPGP Signature Subpacket Types 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"></td>
</tr>
<tr>
<td align="right">1</td>
<td align="left">Reserved</td>
<td align="left"></td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">Signature Creation Time</td>
<td align="left"><xref target="signature-creation-subpacket"/>
</td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">Signature Expiration Time</td>
<td align="left"><xref target="signature-expiration-subpacket"
/></td>
</tr>
<tr>
<td align="right">4</td>
<td align="left">Exportable Certification</td>
<td align="left"> <xref target="exportable-certification-subpa
cket"/></td>
</tr>
<tr>
<td align="right">5</td>
<td align="left">Trust Signature</td>
<td align="left"><xref target="trust-signature-subpacket"/></t
d>
</tr>
<tr>
<td align="right">6</td>
<td align="left">Regular Expression</td>
<td align="left"><xref target="regex-subpacket"/></td>
</tr>
<tr>
<td align="right">7</td>
<td align="left">Revocable</td>
<td align="left"><xref target="revocable-subpacket"/></td>
</tr>
<tr>
<td align="right">8</td>
<td align="left">Reserved</td>
<td align="left"></td>
</tr>
<tr>
<td align="right">9</td>
<td align="left">Key Expiration Time</td>
<td align="left"><xref target="key-expiration-subpacket"/></td
>
</tr>
<tr>
<td align="right">10</td>
<td align="left">Placeholder for backward compatibility</td>
<td align="left"></td>
</tr>
<tr>
<td align="right">11</td>
<td align="left">Preferred Symmetric Ciphers for v1 SEIPD</td>
<td align="left"><xref target="preferred-v1-seipd"/></td>
</tr>
<tr>
<td align="right">12</td>
<td align="left">Revocation Key (deprecated)</td>
<td align="left"><xref target="revocation-key"/></td>
</tr>
<tr>
<td align="right">13-15</td>
<td align="left">Reserved</td>
<td align="left"></td>
</tr>
<tr>
<td align="right">16</td>
<td align="left">Issuer Key ID</td>
<td align="left"><xref target="issuer-keyid-subpacket"/></td>
</tr>
<tr>
<td align="right">17-19</td>
<td align="left">Reserved</td>
<td align="left"></td>
</tr>
<tr>
<td align="right">20</td>
<td align="left">Notation Data</td>
<td align="left"><xref target="notation-data"/></td>
</tr>
<tr>
<td align="right">21</td>
<td align="left">Preferred Hash Algorithms</td>
<td align="left"><xref target="preferred-hashes-subpacket"/></
td>
</tr>
<tr>
<td align="right">22</td>
<td align="left">Preferred Compression Algorithms</td>
<td align="left"><xref target="preferred-compression-subpacket
"/></td>
</tr>
<tr>
<td align="right">23</td>
<td align="left">Key Server Preferences</td>
<td align="left"><xref target="key-server-preferences"/></td>
</tr>
<tr>
<td align="right">24</td>
<td align="left">Preferred Key Server</td>
<td align="left"><xref target="preferred-key-server-subpacket"
/></td>
</tr>
<tr>
<td align="right">25</td>
<td align="left">Primary User ID</td>
<td align="left"><xref target="primary-user-id-subpacket"/></t
d>
</tr>
<tr>
<td align="right">26</td>
<td align="left">Policy URI</td>
<td align="left"><xref target="policy-uri-subpacket"/></td>
</tr>
<tr>
<td align="right">27</td>
<td align="left">Key Flags</td>
<td align="left"><xref target="key-flags"/></td>
</tr>
<tr>
<td align="right">28</td>
<td align="left">Signer's User ID</td>
<td align="left"><xref target="signers-user-id-subpacket"/></t
d>
</tr>
<tr>
<td align="right">29</td>
<td align="left">Reason for Revocation</td>
<td align="left"><xref target="reason-for-revocation"/></td>
</tr>
<tr>
<td align="right">30</td>
<td align="left">Features</td>
<td align="left"><xref target="features-subpacket"/></td>
</tr>
<tr>
<td align="right">31</td>
<td align="left">Signature Target</td>
<td align="left"><xref target="signature-target-subpacket"/></
td>
</tr>
<tr>
<td align="right">32</td>
<td align="left">Embedded Signature</td>
<td align="left"><xref target="embedded-signature-subpacket"/>
</td>
</tr>
<tr>
<td align="right">33</td>
<td align="left">Issuer Fingerprint</td>
<td align="left"><xref target="issuer-fingerprint-subpacket"/>
</td>
</tr>
<tr>
<td align="right">34</td>
<td align="left">Reserved</td>
<td align="left"></td>
</tr>
<tr>
<td align="right">35</td>
<td align="left">Intended Recipient Fingerprint</td>
<td align="left"><xref target="intended-recipient-fingerprint"
/></td>
</tr>
<tr>
<td align="right">37</td>
<td align="left">Reserved (Attested Certifications)</td>
<td align="left"></td>
</tr>
<tr>
<td align="right">38</td>
<td align="left">Reserved (Key Block)</td>
<td align="left"></td>
</tr>
<tr>
<td align="right">39</td>
<td align="left">Preferred AEAD Ciphersuites</td>
<td align="left"><xref target="preferred-v2-seipd"/></td>
</tr>
<tr>
<td align="right">100-110</td>
<td align="left">Private or Experimental Use</td>
<td align="left"></td>
</tr>
</tbody>
</table>
<t>The other bits of the encoded subpacket type ID (i.e. bits 6-0) contain the s <t>Implementations <bcp14>SHOULD</bcp14> implement the four preferre
ubpacket type ID.</t> d algorithm subpackets (11, 21, 22, and 39), as well as the "Features" (30) and
"Reason for Revocation" (29) subpackets.
<t>The following signature subpackets are defined:</t> To avoid surreptitious forwarding (see <xref target="surreptitious-forwarding"/>
), implementations <bcp14>SHOULD</bcp14> also implement the "Intended Recipients
<texttable title="OpenPGP Signature Subpacket Types registry" anchor="signature- Fingerprint" (35) subpacket.
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>&#160;</c>
<c>1</c>
<c>Reserved</c>
<c>&#160;</c>
<c>2</c>
<c>Signature Creation Time</c>
<c><xref target="signature-creation-subpacket"/></c>
<c>3</c>
<c>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>&#160;</c>
<c>9</c>
<c>Key Expiration Time</c>
<c><xref target="key-expiration-subpacket"/></c>
<c>10</c>
<c>Placeholder for backward compatibility</c>
<c>&#160;</c>
<c>11</c>
<c>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>&#160;</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>&#160;</c>
<c>20</c>
<c>Notation Data</c>
<c><xref target="notation-data"/></c>
<c>21</c>
<c>Preferred Hash Algorithms</c>
<c><xref target="preferred-hashes-subpacket"/></c>
<c>22</c>
<c>Preferred Compression Algorithms</c>
<c><xref target="preferred-compression-subpacket"/></c>
<c>23</c>
<c>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>&#160;</c>
<c>35</c>
<c>Intended Recipient Fingerprint</c>
<c><xref target="intended-recipient-fingerprint"/></c>
<c>37</c>
<c>Reserved (Attested Certifications)</c>
<c>&#160;</c>
<c>38</c>
<c>Reserved (Key Block)</c>
<c>&#160;</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>&#160;</c>
</texttable>
<t>Implementations <bcp14>SHOULD</bcp14> implement the four preferred algorithm
subpackets (11, 21, 22, and 39), as well as the "Features" subpacket and the "Re
ason for Revocation" subpacket.
To avoid surreptitious forwarding (see <xref target="surreptitious-forwarding"/>
), implementations <bcp14>SHOULD</bcp14> also implement the "Intended Recipients
" 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 algorit hms to ensure interoperability. Note that if an implementation chooses not to implement some of the preferences subpackets, it <bcp14>MUST</bcp14> default to the mandatory-to-implement algorit hms to ensure interoperability.
An encrypting implementation that does not implement the "Features" subpacket <b An encrypting implementation that does not implement the "Features" (30) subpack
cp14>SHOULD</bcp14> select the type of encrypted data format based instead on th et <bcp14>SHOULD</bcp14> select the type of encrypted data format based on the v
e versions of the recipient keys or external inference (see <xref target="cipher ersions of the recipient keys or external inference (see <xref target="ciphertex
text-malleability"/> for more details).</t> t-malleability"/> for more details).</t>
</section>
</section> <section anchor="signature-subpacket-types">
<section anchor="signature-subpacket-types"><name>Signature Subpacket Types</nam <name>Signature Subpacket Types</name>
e> <t>A number of subpackets are currently defined for OpenPGP signatur
es.
<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 . 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. 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, and thus may have more than one Note that a key may have more than one User ID and thus may have more than one s
self-signature, and differing subpackets.</t> elf-signature and differing subpackets.</t>
<t>A subpacket may be found in either the hashed or the unhashed subpacket secti
<t>A subpacket may be found either in the hashed or unhashed subpacket sections ons of a signature. If a subpacket is not hashed, then the information in it can
of a signature. not be considered definitive because it is not covered by the cryptographic sign
If a subpacket is not hashed, then the information in it cannot be considered de ature. See <xref target="subpacket-section-guidance"/> for more discussion about
finitive because it is not part of the signature proper. hashed and unhashed subpackets.</t>
See <xref target="subpacket-section-guidance"/> for more discussion about hashed </section>
and unhashed subpackets.</t> <section anchor="notes-on-subpackets">
<name>Notes on Subpackets</name>
</section> <t>It is certainly possible for a signature to contain conflicting i
<section anchor="notes-on-subpackets"><name>Notes on Subpackets</name> nformation in subpackets.
For example, a signature may contain multiple copies of a preference or multiple
<t>It is certainly possible for a signature to contain conflicting information i expiration times. In most cases, an implementation <bcp14>SHOULD</bcp14> use th
n subpackets. e last subpacket in the hashed section of the signature, but it <bcp14>MAY</bcp1
For example, a signature may contain multiple copies of a preference or multiple 4> use any conflict resolution scheme that makes more sense. Please note that co
expiration times. nflict resolution is intentionally left to the implementer; most conflicts are s
In most cases, an implementation <bcp14>SHOULD</bcp14> use the last subpacket in imply syntax errors, and the ambiguous language here allows a receiver to be gen
the hashed section of the signature, but <bcp14>MAY</bcp14> use any conflict re erous in what they accept, while putting pressure on a creator to be stingy in w
solution scheme that makes more sense. hat they generate.</t>
Please note that we are intentionally leaving conflict resolution to the impleme <t>Some apparent conflicts may actually make sense. For example, sup
nter; most conflicts are simply syntax errors, and the wishy-washy language here pose a keyholder has a v3 key and a v4 key that share the same RSA key material.
allows a receiver to be generous in what they accept, while putting pressure on Either of these keys can verify a signature created by the other, and it may be
a creator to be stingy in what they generate.</t> 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 key
<t>Some apparent conflicts may actually make sense --- for example, suppose a ke s to the signature.</t>
yholder has a v3 key and a v4 key that share the same RSA key material. </section>
Either of these keys can verify a signature created by the other, and it may be <section anchor="self-sigs">
reasonable for a signature to contain an Issuer Key ID subpacket (<xref target=" <name>Notes on Self-Signatures</name>
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 on Self-Signatures</name>
<t>A self-signature is a binding signature made by the key to which the signatur
e refers.
There are three types of self-signatures, the certification signatures (type IDs
0x10-0x13), the direct key signature (type ID 0x1F), and the subkey binding sig
nature (type ID 0x18).
A 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 o
f Key Flags order to make a valid self-signature.</t>
<t>For certification self-signatures, each User ID <bcp14>MAY</bcp14> have a sel <t>A self-signature is a binding signature made by the key to which
f-signature, and thus different subpackets in those self-signatures. the signature refers. There are three types of self-signatures: the certificatio
n signatures (type IDs 0x10-0x13), the direct key signature (type ID 0x1F), and
the subkey binding signature (type ID 0x18). A cryptographically valid self-sign
ature should be accepted from any primary key, regardless of what Key Flags (<xr
ef target="key-flags"/>) apply to the primary key.
In particular, a primary key does not need to have 0x01 set in the first octet o
f 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 and thus different subpackets in those self-signatures.
For subkey binding signatures, each subkey <bcp14>MUST</bcp14> have a self-signa ture. For subkey binding signatures, each subkey <bcp14>MUST</bcp14> have a self-signa ture.
Subpackets that appear in a certification self-signature apply to the User ID, a nd subpackets that appear in the subkey self-signature apply to the subkey. Subpackets that appear in a certification self-signature apply to the User ID, a nd 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> Lastly, subpackets on the direct key signature apply to the entire key.</t>
<t>An implementation should interpret a self-signature's preference
<t>An implementation should interpret a self-signature's preference subpackets a subpackets as narrowly as possible.
s narrowly as possible.
For example, suppose a key has two user names, Alice and Bob. 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 prefer Suppose that Alice prefers the AEAD ciphersuite AES-256 with OCB, and Bob prefer
s Camellia-256 with GCM. s Camellia-256 with GCM. If the implementation locates this key via Alice's name
If the implementation locates this key via Alice's name, then the preferred AEAD , then the preferred AEAD ciphersuite is AES-256 with OCB; if the implementation
ciphersuite is AES-256 with OCB; if the implementation locates the key via Bob' locates the key via Bob's name, then the preferred algorithm is Camellia-256 wi
s name, then the preferred algorithm is Camellia-256 with GCM. th 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> 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
<t>Revoking a self-signature or allowing it to expire has a semantic meaning tha meaning that varies with the signature type.
t varies with the signature type.
Revoking the self-signature on a User ID effectively retires that user name. 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" and i s corroborated by other users' certifications. The self-signature is a statement, "My name X is tied to my signing key K", and it is corroborated by other users' certifications.
If another user revokes their certification, they are effectively saying that th ey no longer believe that name and that key are tied together. If another user revokes their certification, they are effectively saying that th ey no longer believe that name and that key are tied together.
Similarly, if the users themselves revoke their self-signature, then the users n o longer go by that name, no longer have that email address, etc. Similarly, if the users themselves revoke their self-signature, then the users n o longer go by that name, no longer have that email address, etc.
Revoking a binding signature effectively retires that subkey. Revoking a binding signature effectively retires that subkey. Revoking a direct
Revoking a direct key signature cancels that signature. key signature cancels that signature.
Please see <xref target="reason-for-revocation"/> for more relevant detail.</t> Please see <xref target="reason-for-revocation"/> for more relevant details.</t>
<t>Since a self-signature contains important information about the k
<t>Since a self-signature contains important information about the key's use, an ey's use, an implementation <bcp14>SHOULD</bcp14> allow the user to rewrite the
implementation <bcp14>SHOULD</bcp14> allow the user to rewrite the self-signatu self-signature and important information in it, such as preferences and key expi
re, and important information in it, such as preferences and key expiration.</t> ration.</t>
<t>When an implementation imports a secret key, it <bcp14>SHOULD</bc
<t>When an implementation imports a secret key, it <bcp14>SHOULD</bcp14> verify p14> verify that the key's internal self-signatures do not advertise features or
that the key's internal self-signatures do not advertise features or algorithms algorithms that the implementation doesn't support.
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 f eatures and algorithms supported by the implementation.</t> 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 f eatures and algorithms supported by the implementation.</t>
<t>An implementation that encounters multiple self-signatures on the
<t>An implementation that encounters multiple self-signatures on the same object same object <bcp14>MUST</bcp14> select the most recent valid self-signature and
<bcp14>MUST</bcp14> select the most recent valid self-signature, and ignore all ignore all other self-signatures.</t>
other self-signatures.</t> <t>By convention, a version 4 key stores information about the prima
ry Public-Key (key flags, key expiration, etc.) and the Transferable Public Key
<t>By convention, a version 4 key stores information about the primary Public-Ke as a whole (features, algorithm preferences, etc.) in a User ID self-signature o
y (key flags, key expiration, etc.) and the Transferable Public Key as a whole ( f type 0x10 or 0x13. To use a v4 key,
features, algorithm preferences, etc.) in a User ID self-signature of type 0x10 some implementations require at least one User ID with a valid self-signature to
or 0x13. be present.
Some implementations require at least one User ID with a valid self-signature to
be present to use a v4 key.
For this reason, it is <bcp14>RECOMMENDED</bcp14> to include at least one User I D with a self-signature in v4 keys.</t> For this reason, it is <bcp14>RECOMMENDED</bcp14> to include at least one User I D with a self-signature in v4 keys.</t>
<t>For version 6 keys, it is <bcp14>RECOMMENDED</bcp14> to store inf
<t>For version 6 keys, it is <bcp14>RECOMMENDED</bcp14> to store information abo ormation about the primary Public-Key as well as the Transferable Public Key as
ut the primary Public-Key as well as the Transferable Public Key as a whole (key a whole (key flags, key expiration, features, algorithm preferences, etc.) in a
flags, key expiration, features, algorithm preferences, etc.) in a direct key s direct key signature (type ID 0x1F) over the Public-Key, instead of placing that
ignature (type ID 0x1F) over the Public-Key instead of placing that information information in a User ID self-signature.
in a User ID self-signature.
An implementation <bcp14>MUST</bcp14> ensure that a valid direct key signature i s present before using a v6 key. An implementation <bcp14>MUST</bcp14> ensure that a valid direct key signature i s present before using a v6 key.
This prevents certain attacks where an adversary strips a self-signature specify ing a key expiration time or certain preferences.</t> This prevents certain attacks where an adversary strips a self-signature specify ing a key expiration time or certain preferences.</t>
<t>An implementation <bcp14>SHOULD NOT</bcp14> require a User ID sel
<t>An implementation <bcp14>SHOULD NOT</bcp14> require a User ID self-signature f-signature to be present in order to consume or use a key, unless the particula
to be present in order to consume or use a key, unless the particular use is con r use is contingent on the keyholder identifying themselves with the textual lab
tingent on the keyholder identifying themselves with the textual label in the Us el in the User ID.
er ID. For example, when refreshing a key to learn about changes in expiration, adverti
For example, when refreshing a key to learn about changes in expiration, adverti sed features, algorithm preferences, revocation, subkey rotation, and so forth,
sed 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 ve
there is no need to require a User ID self-signature. rifying a signature over an email message, an implementation <bcp14>MAY</bcp14>
On the other hand, when verifying a signature over an e-mail message, an impleme choose to only accept a signature from a key that has a valid self-signature ove
ntation <bcp14>MAY</bcp14> choose to only accept a signature from a key that has r a User ID that matches the message's From: header, as a way to avoid a signatu
a valid self-signature over a User ID that matches the message's From: header, re transplant attack.</t>
as a way to avoid a signature transplant attack.</t>
</section>
<section anchor="signature-creation-subpacket"><name>Signature Creation Time</na
me>
<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 critica
l.</t>
</section> </section>
<section anchor="issuer-keyid-subpacket"><name>Issuer Key ID</name> <section anchor="signature-creation-subpacket">
<name>Signature Creation Time</name>
<t>(8-octet Key ID)</t> <t>(4-octet time field)</t>
<t>The time the signature was made.</t>
<t>The OpenPGP Key ID of the key issuing the signature. <t>This subpacket <bcp14>MUST</bcp14> be present in the hashed area.
</t>
<t>When generating this subpacket, it <bcp14>SHOULD</bcp14> be marke
d as critical.</t>
</section>
<section 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</bc p14> be included in the signature. If the version of that key is greater than 4, this subpacket <bcp14>MUST NOT</bc p14> be included in the signature.
For these keys, consider the Issuer Fingerprint subpacket (<xref target="issuer- For these keys, consider the Issuer Fingerprint subpacket (<xref targ
fingerprint-subpacket"/>) instead.</t> et="issuer-fingerprint-subpacket"/>) instead.</t>
<t>Note: in previous versions of this specification, this subpacket was simply k
nown as the "Issuer" subpacket.</t>
</section>
<section anchor="key-expiration-subpacket"><name>Key Expiration Time</name>
<t>(4-octet time field)</t>
<t>The validity period of the key. <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 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. 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 t he primary key. For a direct or certification self-signature, the key creation time is that of t he primary key.
For a subkey binding signature, the key creation time is that of the subkey. 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. If this is not present or has a value of zero, the key never expires.
This is found only on a self-signature.</t> This is found only on a self-signature.</t>
<t>When an implementation generates this subpacket, it <bcp14>SHOULD
<t>When an implementation generates this subpacket, it <bcp14>SHOULD</bcp14> be </bcp14> be marked as critical.</t>
marked as critical.</t> </section>
<section anchor="preferred-v1-seipd">
</section> <name>Preferred Symmetric Ciphers for v1 SEIPD</name>
<section anchor="preferred-v1-seipd"><name>Preferred Symmetric Ciphers for v1 SE <t>(array of one-octet values)</t>
IPD</name> <t>A series of symmetric cipher algorithm IDs indicating how the key
holder prefers to receive version 1 Symmetrically Encrypted Integrity Protected
<t>(array of one-octet values)</t> Data (<xref target="version-one-seipd"/>).
<t>A series of symmetric cipher algorithm IDs indicating how the keyholder prefe
rs 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 f irst. The subpacket body is an ordered list of octets with the most preferred listed f irst.
It is assumed that only algorithms listed are supported by the recipient's imple mentation. It is assumed that only the algorithms listed are supported by the recipient's i mplementation.
Algorithm IDs are defined in <xref target="symmetric-algos"/>. Algorithm IDs are defined in <xref target="symmetric-algos"/>.
This is only found on a self-signature.</t> This is only found on a self-signature.</t>
<t>When generating a v2 SEIPD packet, this preference list is not re
<t>When generating a v2 SEIPD packet, this preference list is not relevant. levant.
See <xref target="preferred-v2-seipd"/> instead.</t> See <xref target="preferred-v2-seipd"/> instead.</t>
</section>
</section> <section anchor="preferred-v2-seipd">
<section anchor="preferred-v2-seipd"><name>Preferred AEAD Ciphersuites</name> <name>Preferred AEAD Ciphersuites</name>
<t>(array of pairs of octets indicating Symmetric Cipher and AEAD al
<t>(array of pairs of octets indicating Symmetric Cipher and AEAD algorithms)</t gorithms)</t>
> <t>A series of paired algorithm IDs indicating how the keyholder pre
fers to receive version 2 Symmetrically Encrypted Integrity Protected Data (<xre
<t>A series of paired algorithm IDs indicating how the keyholder prefers to rece f target="version-two-seipd"/>).
ive version 2 Symmetrically Encrypted Integrity Protected Data (<xref target="ve
rsion-two-seipd"/>).
Each pair of octets indicates a combination of a symmetric cipher and an AEAD mo de that the keyholder prefers to use. Each pair of octets indicates a combination of a symmetric cipher and an AEAD mo de that the keyholder prefers to use.
The symmetric cipher algorithm ID precedes the AEAD algorithm ID in each pair. 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> 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
<t>It is assumed that only the combinations of algorithms listed are supported b supported by the recipient's implementation, with the exception of the mandator
y the recipient's implementation, with the exception of the mandatory-to-impleme y-to-implement combination of AES-128 and OCB.
nt combination of AES-128 and OCB.
If AES-128 and OCB are not found in the subpacket, it is implicitly listed at th e end.</t> If AES-128 and OCB are not found in the subpacket, it is implicitly listed at th e end.</t>
<t>AEAD algorithm IDs are listed in <xref target="aead-algorithms"/>
<t>AEAD algorithm IDs are listed in <xref target="aead-algorithms"/>. .
Symmetric cipher algorithm IDs are listed in <xref target="symmetric-algos"/>.</ t> Symmetric cipher algorithm IDs are listed in <xref target="symmetric-algos"/>.</ t>
<t>For example, a subpacket containing the six octets</t>
<t>For example, a subpacket with content of these six octets:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
09 02 09 03 13 02 09 02 09 03 13 02
]]></artwork></figure> ]]></artwork>
<t>indicates that the keyholder prefers to receive v2 SEIPD using AE
<t>Indicates that the keyholder prefers to receive v2 SEIPD using AES-256 with O S-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB, and finally t
CB, then AES-256 with GCM, then Camellia-256 with OCB, and finally the implicit he implicit AES-128 with OCB.</t>
AES-128 with OCB.</t> <t>Note that support for version 2 of the Symmetrically Encrypted In
tegrity Protected Data packet (<xref target="version-two-seipd"/>) in general is
<t>Note that support for version 2 of the Symmetrically Encrypted Integrity Prot indicated by a Features Flag (<xref target="features-subpacket"/>).</t>
ected Data packet (<xref target="version-two-seipd"/>) in general is indicated b <t>This subpacket is only found on a self-signature.</t>
y a Features Flag (<xref target="features-subpacket"/>).</t> <t>When generating a v1 SEIPD packet, this preference list is not re
levant.
<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> See <xref target="preferred-v1-seipd"/> instead.</t>
</section>
</section> <section anchor="preferred-hashes-subpacket">
<section anchor="preferred-hashes-subpacket"><name>Preferred Hash Algorithms</na <name>Preferred Hash Algorithms</name>
me> <t>(array of one-octet values)</t>
<t>Message digest algorithm IDs that indicate which algorithms the k
<t>(array of one-octet values)</t> eyholder prefers to receive.
<t>Message digest algorithm IDs that indicate which algorithms the keyholder pre
fers to receive.
Like the preferred AEAD ciphersuites, the list is ordered. Like the preferred AEAD ciphersuites, the list is ordered.
Algorithm IDs are defined in <xref target="hash-algos"/>. Algorithm IDs are defined in <xref target="hash-algos"/>.
This is only found on a self-signature.</t> This is only found on a self-signature.</t>
</section>
</section> <section anchor="preferred-compression-subpacket">
<section anchor="preferred-compression-subpacket"><name>Preferred Compression Al <name>Preferred Compression Algorithms</name>
gorithms</name> <t>(array of one-octet values)</t>
<t>Compression algorithm IDs that indicate which algorithms the keyh
<t>(array of one-octet values)</t> older prefers to use.
<t>Compression algorithm IDs that indicate which algorithms the keyholder prefer
s to use.
Like the preferred AEAD ciphersuites, the list is ordered. Like the preferred AEAD ciphersuites, the list is ordered.
Algorithm IDs are defined in <xref target="compression-algos"/>. Algorithm IDs are defined in <xref target="compression-algos"/>.
A zero, or the absence of this subpacket, denotes that uncompressed data is pref erred; the keyholder's implementation might have no compression support availabl e. A zero, or the absence of this subpacket, denotes that uncompressed data is pref erred; the keyholder's implementation might have no compression support availabl e.
This is only found on a self-signature.</t> This is only found on a self-signature.</t>
</section>
</section> <section anchor="signature-expiration-subpacket">
<section anchor="signature-expiration-subpacket"><name>Signature Expiration Time <name>Signature Expiration Time</name>
</name> <t>(4-octet time field)</t>
<t>The validity period of the signature.
<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 signatu re expires. This is the number of seconds after the signature creation time that the signatu re expires.
If this is not present or has a value of zero, it never expires.</t> 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
<t>When an implementation generates this subpacket, it <bcp14>SHOULD</bcp14> be </bcp14> be marked as critical.</t>
marked as critical.</t> </section>
<section anchor="exportable-certification-subpacket">
</section> <name>Exportable Certification</name>
<section anchor="exportable-certification-subpacket"><name>Exportable Certificat <t>(1 octet of exportability, 0 for not, 1 for exportable)</t>
ion</name> <t>This subpacket denotes whether a certification signature is "expo
rtable"; it is intended for use by users other than the signature's issuer.
<t>(1 octet of exportability, 0 for not, 1 for exportable)</t>
<t>This subpacket denotes whether a certification signature is "exportable", to
be used by other users than the signature's issuer.
The packet body contains a Boolean flag indicating whether the signature is expo rtable. The packet body contains a Boolean flag indicating whether the signature is expo rtable.
If this packet is not present, the certification is exportable; it is equivalent to a flag containing a 1.</t> 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
<t>Non-exportable, or "local", certifications are signatures made by a user to m a user to mark a key as valid within that user's implementation only.</t>
ark 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 loca
<t>Thus, when an implementation prepares a user's copy of a key for transport to l certification signatures are deleted from the key.</t>
another user (this is the process of "exporting" the key), any local certificat <t>The receiver of a transported key "imports" it and likewise trims
ion signatures are deleted from the key.</t> any local certifications. In normal operation, there won't be any local certifi
cations, assuming the import is performed on an exported key. However, there are
<t>The receiver of a transported key "imports" it, and likewise trims any local instances where this can reasonably happen.
certifications.
In normal operation, there won't be any, assuming the import is performed on an
exported key.
However, there are instances where this can reasonably happen.
For example, if an implementation allows keys to be imported from a key database in addition to an exported key, then this situation can arise.</t> 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 us
<t>Some implementations do not represent the interest of a single user (for exam er (for example, a key server).
ple, a key server).
Such implementations always trim local certifications from any key they handle.< /t> Such implementations always trim local certifications from any key they handle.< /t>
<t>When an implementation generates this subpacket and denotes the s
<t>When an implementation generates this subpacket and denotes the signature as ignature as non-exportable, the subpacket <bcp14>MUST</bcp14> be marked as criti
non-exportable, the subpacket <bcp14>MUST</bcp14> be marked as critical.</t> cal.</t>
</section>
</section> <section anchor="revocable-subpacket">
<section anchor="revocable-subpacket"><name>Revocable</name> <name>Revocable</name>
<t>(1 octet of revocability, 0 for not, 1 for revocable)</t>
<t>(1 octet of revocability, 0 for not, 1 for revocable)</t> <t>A Signature's revocability status. The packet body contains a Boo
lean flag indicating whether the signature is revocable. Signatures that are not
<t>Signature's revocability status. revocable ignore any later revocation signatures. They represent the signer's c
The packet body contains a Boolean flag indicating whether the signature is revo ommitment that its signature cannot be revoked for the life of its key.
cable.
Signatures that are not revocable have any later revocation signatures ignored.
They represent a commitment by the signer that he cannot revoke his signature fo
r the life of his key.
If this packet is not present, the signature is revocable.</t> If this packet is not present, the signature is revocable.</t>
</section>
</section> <section anchor="trust-signature-subpacket">
<section anchor="trust-signature-subpacket"><name>Trust Signature</name> <name>Trust Signature</name>
<t>(1 octet "level" (depth), 1 octet of trust amount)</t>
<t>(1 octet "level" (depth), 1 octet of trust amount)</t> <t>The signer asserts that the key is not only valid but also trustw
orthy at the specified level. Level 0 has the same meaning as an ordinary validi
<t>Signer asserts that the key is not only valid but also trustworthy at the spe ty signature.
cified 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 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 tru st signatures; that is, the signed key is a "meta introducer". Level 2 means that the signed key is asserted to be trusted to issue level 1 tru st signatures; that is, the signed key is a "meta introducer".
Generally, a level n trust signature asserts that a key is trusted to issue leve l n-1 trust signatures. Generally, a level n trust signature asserts that a key is trusted to issue leve l n-1 trust signatures.
The trust amount is in a range from 0-255, interpreted such that values less tha n 120 indicate partial trust and values of 120 or greater indicate complete trus t. The trust amount is in a range from 0-255, interpreted such that values less tha n 120 indicate partial trust and values of 120 or greater indicate complete trus t.
Implementations <bcp14>SHOULD</bcp14> emit values of 60 for partial trust and 12 0 for complete trust.</t> Implementations <bcp14>SHOULD</bcp14> emit values of 60 for partial trust and 12 0 for complete trust.</t>
</section>
</section> <section anchor="regex-subpacket">
<section anchor="regex-subpacket"><name>Regular Expression</name> <name>Regular Expression</name>
<t>(null-terminated UTF-8 encoded regular expression)</t>
<t>(null-terminated UTF-8 encoded regular expression)</t> <t>Used in conjunction with trust Signature packets (of level &gt; 0
) to limit the scope of trust that is extended.
<t>Used in conjunction with trust Signature packets (of level &gt; 0) to limit t
he 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. 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 do main" regular expression <xref target="REGEX"/> package. The regular expression uses the same syntax as Henry Spencer's "almost public do main" regular expression <xref target="REGEX"/> package.
A description of the syntax is found in <xref target="regular-expressions"/>. 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 U nicode characters from User IDs. The regular expression matches (or does not match) a sequence of UTF-8-encoded U nicode characters from User IDs.
The expression itself is also written with UTF-8 characters.</t> The expression itself is also written with UTF-8 characters.</t>
<t>For historical reasons, this subpacket includes a null character
<t>For historical reasons, this subpacket includes a null character (octet with (an octet with value zero) after the regular expression.
value zero) after the regular expression. When an implementation parses a regular expression subpacket, it <bcp14>MUST</bc
When an implementation parses a regular expression subpacket, it <bcp14>MUST</bc p14> remove this octet; if it is not present, it <bcp14>MUST</bcp14> reject the
p14> remove this octet; if it is not present, it <bcp14>MUST</bcp14> reject the subpacket (i.e., ignore the subpacket if it's non-critical and reject the signat
subpacket (i.e. ignore the subpacket if it's non-critical and reject the signatu ure if it's critical).
re if it's critical).
When an implementation generates a regular expression subpacket, it <bcp14>MUST< /bcp14> include the null terminator.</t> 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 marke
<t>When generating this subpacket, it <bcp14>SHOULD</bcp14> be marked as critica d as critical.</t>
l.</t> </section>
<section anchor="revocation-key">
</section> <name>Revocation Key (Deprecated)</name>
<section anchor="revocation-key"><name>Revocation Key</name> <t>(1 octet of class, 1 octet of public-key algorithm ID, 20 octets
of v4 fingerprint)</t>
<t>(1 octet of class, 1 octet of public-key algorithm ID, 20 octets of v4 finger <t>This mechanism is deprecated.
print)</t>
<t>This mechanism is deprecated.
Applications <bcp14>MUST NOT</bcp14> generate such a subpacket.</t> Applications <bcp14>MUST NOT</bcp14> generate such a subpacket.</t>
<t>An application that wants the functionality of delegating revocat
<t>An application that wants the functionality of delegating revocation can use ion can use an escrowed Revocation Signature.
an escrowed Revocation Signature.
See <xref target="escrowed-revocations"/> for more details.</t> See <xref target="escrowed-revocations"/> for more details.</t>
<t>The remainder of this section describes how some implementations
<t>The remainder of this section describes how some implementations attempt to i attempt to interpret this deprecated subpacket.</t>
nterpret this deprecated subpacket.</t> <t>This packet was intended to authorize the specified key to issue
revocation signatures for this key. The class octet must have bit 0x80 set.
<t>This packet was intended to authorize the specified key to issue revocation s If bit 0x40 is set, it means the revocation information is sensitive.
ignatures for this key.
Class octet must have bit 0x80 set.
If the bit 0x40 is set, then this means that the revocation information is sensi
tive.
Other bits are for future expansion to other kinds of authorizations. Other bits are for future expansion to other kinds of authorizations.
This is only found on a direct key self-signature (type ID 0x1F). This is only found on a direct key self-signature (type ID 0x1F).
The use on other types of self-signatures is unspecified.</t> The use on other types of self-signatures is unspecified.</t>
<t>If the "sensitive" flag is set, the keyholder feels this subpacke
<t>If the "sensitive" flag is set, the keyholder feels this subpacket contains p t contains private trust information that describes a real-world sensitive relat
rivate trust information that describes a real-world sensitive relationship. ionship.
If this flag is set, implementations <bcp14>SHOULD NOT</bcp14> export this signa If this flag is set, implementations <bcp14>SHOULD NOT</bcp14> export this signa
ture to other users except in cases where the data needs to be available: when t ture to other users except in cases where the data needs to be available, i.e.,
he signature is being sent to the designated revoker, or when it is accompanied when the signature is being sent to the designated revoker or when it is accompa
by a revocation signature from that revoker. nied by a revocation signature from that revoker.
Note that it may be appropriate to isolate this subpacket within a separate sign ature so that it is not combined with other subpackets that need to be exported. </t> Note that it may be appropriate to isolate this subpacket within a separate sign ature so that it is not combined with other subpackets that need to be exported. </t>
</section>
</section> <section anchor="notation-data">
<section anchor="notation-data"><name>Notation Data</name> <name>Notation Data</name>
<t>(4 octets of flags, 2 octets of name length (M), 2 octets of valu
<t>(4 octets of flags, 2 octets of name length (M), 2 octets of value length (N) e length (N), M octets of name data, N octets of value data)</t>
, M octets of name data, N octets of value data)</t> <t>This subpacket describes a "notation" on the signature that the i
ssuer wishes to make.
<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. 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. There may be more than one notation in a signature.
Notations can be used for any extension the issuer of the signature cares to mak e. Notations can be used for any extension the issuer of the signature cares to mak e.
The "flags" field holds four octets of flags.</t> The "flags" field holds four octets of flags.</t>
<t>All undefined flags <bcp14>MUST</bcp14> be zero.
<t>All undefined flags <bcp14>MUST</bcp14> be zero.
Defined flags are as follows:</t> Defined flags are as follows:</t>
<table anchor="sig-note-data-note-flags-registry">
<name>OpenPGP Signature Notation Data Subpacket Notation Flags Reg
istry</name>
<thead>
<tr>
<th align="left">Flag Position</th>
<th align="left">Shorthand</th>
<th align="left">Description</th>
<texttable title="OpenPGP Signature Notation Data Subpacket Notation Flags regis </tr>
try" anchor="sig-note-data-note-flags-registry"> </thead>
<ttcol align='left'>Flag Position</ttcol> <tbody>
<ttcol align='left'>Shorthand</ttcol> <tr>
<ttcol align='left'>Description</ttcol> <td align="left">0x80000000 (first bit of the first octet)</td
<ttcol align='left'>Reference</ttcol> >
<c>0x80000000 (first bit of first octet)</c> <td align="left">human-readable</td>
<c>human-readable</c> <td align="left">Notation value is UTF-8 text</td>
<c>Notation value is UTF-8 text.</c>
<c>This document</c>
</texttable>
<t>Notation names are arbitrary strings encoded in UTF-8.
They reside in two namespaces: The IETF namespace and the user namespace.</t>
<t>The IETF namespace is registered with IANA. </tr>
</tbody>
</table>
<t>Notation names are arbitrary strings encoded in UTF-8.
They reside in two namespaces: 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). These names <bcp14>MUST NOT</bcp14> contain the "@" character (0x40).
This is a tag for the user namespace.</t> This is a tag for the user namespace.</t>
<table anchor="sig-note-data-subpacket-types">
<name>OpenPGP Signature Notation Data Subpacket Types Registry</na
me>
<thead>
<tr>
<th align="left">Notation Name</th>
<th align="left">Data Type</th>
<th align="left">Allowed Values</th>
<texttable title="OpenPGP Signature Notation Data Subpacket Types registry" anch </tr>
or="sig-note-data-subpacket-types"> </thead>
<ttcol align='left'>Notation Name</ttcol> <tbody>
<ttcol align='left'>Data Type</ttcol> <tr>
<ttcol align='left'>Allowed Values</ttcol> <th colspan="3" align="left" rowspan="1">No registrations at th
<ttcol align='left'>Reference</ttcol> is time.</th>
<c>&#160;</c> </tr>
<c>&#160;</c> </tbody>
<c>&#160;</c> </table>
<c>&#160;</c> <t>This registry is initially empty.</t>
</texttable> <t>Names in the user namespace consist of a UTF-8 string tag followe
d by "@", followed by a DNS domain name.
<t>This registry is initially empty.</t>
<t>Names in the user namespace consist of a UTF-8 string tag followed by "@" fol
lowed by a DNS domain name.
Note that the tag <bcp14>MUST NOT</bcp14> contain an "@" character. Note that the tag <bcp14>MUST NOT</bcp14> contain an "@" character.
For example, the "sample" tag used by Example Corporation could be "sample@examp le.com".</t> For example, the "sample" tag used by Example Corporation could be "sample@examp le.com".</t>
<t>Names in a user space are owned and controlled by the owners of t
<t>Names in a user space are owned and controlled by the owners of that domain. hat domain.
Obviously, it's bad form to create a new name in a DNS space that you don't own. </t> 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, impl
<t>Since the user namespace is in the form of an email address, implementers <bc ementers <bcp14>MAY</bcp14> wish to arrange for that address to reach a person w
p14>MAY</bcp14> wish to arrange for that address to reach a person who can be co ho can be consulted about the use of the named tag.
nsulted about the use of the named tag.
Note that due to UTF-8 encoding, not all valid user space name tags are valid em ail addresses.</t> Note that due to UTF-8 encoding, not all valid user space name tags are valid em ail addresses.</t>
<t>If there is a critical notation, the criticality applies to that
<t>If there is a critical notation, the criticality applies to that specific not specific notation and not to notations in general.</t>
ation and not to notations in general.</t> </section>
<section anchor="key-server-preferences">
</section> <name>Key Server Preferences</name>
<section 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 indicates preferences that t
<t>(N octets of flags)</t> he keyholder has about how the key is handled on a key server.
<t>This is a list of one-bit flags that indicate preferences that the keyholder
has about how the key is handled on a key server.
All undefined flags <bcp14>MUST</bcp14> be zero.</t> All undefined flags <bcp14>MUST</bcp14> be zero.</t>
<table anchor="key-server-preference-flags-registry">
<texttable title="OpenPGP Key Server Preference Flags registry" anchor="key-serv <name>OpenPGP Key Server Preference Flags Registry</name>
er-preference-flags-registry"> <thead>
<ttcol align='left'>Flag</ttcol> <tr>
<ttcol align='left'>Shorthand</ttcol> <th align="left">Flag</th>
<ttcol align='left'>Definition</ttcol> <th align="left">Shorthand</th>
<c>0x80...</c> <th align="left">Definition</th>
<c>No-modify</c> </tr>
<c>The keyholder requests that this key only be modified or updated by the </thead>
keyholder or an administrator of the key server.</c> <tbody>
</texttable> <tr>
<td align="left">0x80...</td>
<t>This is found only on a self-signature.</t> <td align="left">No-modify</td>
<td align="left">The keyholder requests that this key only be
</section> modified or updated by the keyholder or an administrator of the key server.</td>
<section anchor="preferred-key-server-subpacket"><name>Preferred Key Server</nam </tr>
e> </tbody>
</table>
<t>(String)</t> <t>This is found only on a self-signature.</t>
</section>
<t>This is a URI of a key server that the keyholder prefers be used for updates. <section 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 U ser ID. Note that keys with multiple User IDs can have a preferred key server for each U ser 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> 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> <section anchor="primary-user-id-subpacket">
<section anchor="primary-user-id-subpacket"><name>Primary User ID</name> <name>Primary User ID</name>
<t>(1 octet, Boolean)</t>
<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.
<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, fo r example, by referring to the primary User ID. It is reasonable for an implementation to resolve ambiguities in preferences, fo r example, by referring to the primary User ID.
If this flag is absent, its value is zero. 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 r esolve 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> If more than one User ID in a key is marked as primary, the implementation may r esolve 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 subp
<t>When appearing on a self-signature on a User ID packet, this subpacket applie acket applies only to User ID packets.
s only to User ID packets. When appearing on a self-signature on a User Attribute packet, this subpacket ap
When appearing on a self-signature on a User Attribute packet, this subpacket ap plies only to User Attribute packets. That is, there are two different and indep
plies only to User Attribute packets. endent "primaries" -- one for User IDs and one for User Attributes.</t>
That is to say, there are two different and independent "primaries" --- one for </section>
User IDs, and one for User Attributes.</t> <section anchor="policy-uri-subpacket">
<name>Policy URI</name>
</section> <t>(String)</t>
<section anchor="policy-uri-subpacket"><name>Policy URI</name> <t>This subpacket contains a URI of a document that describes the po
licy under which the signature was issued.</t>
<t>(String)</t> </section>
<section anchor="key-flags">
<t>This subpacket contains a URI of a document that describes the policy under w <name>Key Flags</name>
hich the signature was issued.</t> <t>(N octets of flags)</t>
<t>This subpacket contains a list of binary flags that hold informat
</section> ion about a key.
<section anchor="key-flags"><name>Key Flags</name> It is a string of octets, and an implementation <bcp14>MUST NOT</bcp14> assume a
fixed size, so that it can grow over time. If a list is shorter than an impleme
<t>(N octets of flags)</t> ntation expects, the unstated flags are considered to be zero. The defined flags
are as follows:</t>
<t>This subpacket contains a list of binary flags that hold information about a <table anchor="key-flags-registry">
key. <name>OpenPGP Key Flags Registry</name>
It is a string of octets, and an implementation <bcp14>MUST NOT</bcp14> assume a <thead>
fixed size. <tr>
This is so it can grow over time. <th align="left">Flag</th>
If a list is shorter than an implementation expects, the unstated flags are cons <th align="left">Definition</th>
idered to be zero. </tr>
The defined flags are as follows:</t> </thead>
<tbody>
<texttable title="OpenPGP Key Flags registry" anchor="key-flags-registry"> <tr>
<ttcol align='left'>Flag</ttcol> <td align="left">0x01...</td>
<ttcol align='left'>Definition</ttcol> <td align="left">This key may be used to make User ID certific
<c>0x01...</c> ations (signature type IDs 0x10-0x13) or direct key signatures (signature type I
<c>This key may be used to make User ID certifications (signature type IDs D 0x1F) over other keys.</td>
0x10-0x13) or direct key signatures (signature type ID 0x1F) over other keys.</ </tr>
c> <tr>
<c>0x02...</c> <td align="left">0x02...</td>
<c>This key may be used to sign data.</c> <td align="left">This key may be used to sign data.</td>
<c>0x04...</c> </tr>
<c>This key may be used to encrypt communications.</c> <tr>
<c>0x08...</c> <td align="left">0x04...</td>
<c>This key may be used to encrypt storage.</c> <td align="left">This key may be used to encrypt communication
<c>0x10...</c> s.</td>
<c>The private component of this key may have been split by a secret-shari </tr>
ng mechanism.</c> <tr>
<c>0x20...</c> <td align="left">0x08...</td>
<c>This key may be used for authentication.</c> <td align="left">This key may be used to encrypt storage.</td>
<c>0x80...</c> </tr>
<c>The private component of this key may be in the possession of more than <tr>
one person.</c> <td align="left">0x10...</td>
<c>0x0004...</c> <td align="left">The private component of this key may have be
<c>Reserved (ADSK).</c> en split by a secret-sharing mechanism.</td>
<c>0x0008...</c> </tr>
<c>Reserved (timestamping).</c> <tr>
</texttable> <td align="left">0x20...</td>
<td align="left">This key may be used for authentication.</td>
<t>Usage notes:</t> </tr>
<tr>
<t>The flags in this packet may appear in self-signatures or in certification si <td align="left">0x80...</td>
gnatures. <td align="left">The private component of this key may be in t
They mean different things depending on who is making the statement --- for exam he possession of more than one person.</td>
ple, a certification signature that has the "sign data" flag is stating that the </tr>
certification is for that use. <tr>
On the other hand, the "communications encryption" flag in a self-signature is s <td align="left">0x0004...</td>
tating a preference that a given key be used for communications. <td align="left">Reserved (ADSK)</td>
Note however, that it is a thorny issue to determine what is "communications" an </tr>
d what is "storage". <tr>
This decision is left wholly up to the implementation; the authors of this docum <td align="left">0x0008...</td>
ent do not claim any special wisdom on the issue and realize that accepted opini <td align="left">Reserved (timestamping)</td>
on may change.</t> </tr>
</tbody>
<t>The "split key" (0x10) and "group key" (0x80) flags are placed on a self-sign </table>
ature only; they are meaningless on a certification signature. <t>Usage notes:</t>
<t>The flags in this packet may appear in self-signatures or in cert
ification signatures. They mean different things depending on who is making the
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 "commu
nications encryption" flag in a self-signature is stating a preference that a gi
ven key be used for communications. However, note that determining what is "comm
unications" and what is "storage" is a thorny issue. This decision is left wholl
y up to the implementation; the authors of this document do not claim any specia
l 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 0x1 F) or a subkey signature (type ID 0x18), one that refers to the key the flag app lies to.</t> They <bcp14>SHOULD</bcp14> be placed only on a direct key signature (type ID 0x1 F) or a subkey signature (type ID 0x18), one that refers to the key the flag app lies to.</t>
<t>When an implementation generates this subpacket, it <bcp14>SHOULD
<t>When an implementation generates this subpacket, it <bcp14>SHOULD</bcp14> be </bcp14> be marked as critical.</t>
marked as critical.</t> </section>
<section anchor="signers-user-id-subpacket">
</section> <name>Signer's User ID</name>
<section 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 respo
<t>(String)</t> nsible for the signing.
<t>This subpacket allows a keyholder to state which User ID is responsible for t
he signing.
Many keyholders use a single key for different purposes, such as business commun ications as well as personal communications. Many keyholders use a single key for different purposes, such as business commun ications as well as personal communications.
This subpacket allows such a keyholder to state which of their roles is making a signature.</t> 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 Attri
<t>This subpacket is not appropriate to use to refer to a User Attribute packet. bute packet.</t>
</t> </section>
<section anchor="reason-for-revocation">
</section> <name>Reason for Revocation</name>
<section 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 r
<t>(1 octet of revocation code, N octets of reason string)</t> evocation signatures.
<t>This subpacket is used only in key revocation and certification revocation si
gnatures.
It describes the reason why the key or certification was revoked.</t> 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>
<t>The first octet contains a machine-readable code that denotes the reason for <table anchor="reason-for-revocation-code-registry">
the revocation:</t> <name>OpenPGP Reason for Revocation (Revocation Octet) Registry</n
ame>
<texttable title="OpenPGP Reason for Revocation Code registry" anchor="reason-fo <thead>
r-revocation-code-registry"> <tr>
<ttcol align='right'>Code</ttcol> <th align="right">Code</th>
<ttcol align='left'>Reason</ttcol> <th align="left">Reason</th>
<c>0</c> </tr>
<c>No reason specified (key revocations or cert revocations)</c> </thead>
<c>1</c> <tbody>
<c>Key is superseded (key revocations)</c> <tr>
<c>2</c> <td align="right">0</td>
<c>Key material has been compromised (key revocations)</c> <td align="left">No reason specified (key revocations or cert
<c>3</c> revocations)</td>
<c>Key is retired and no longer used (key revocations)</c> </tr>
<c>32</c> <tr>
<c>User ID information is no longer valid (cert revocations)</c> <td align="right">1</td>
<c>100-110</c> <td align="left">Key is superseded (key revocations)</td>
<c>Private Use</c> </tr>
</texttable> <tr>
<td align="right">2</td>
<t>Following the revocation code is a string of octets that gives information ab <td align="left">Key material has been compromised (key revoca
out the Reason for Revocation in human-readable form (UTF-8). tions)</td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">Key is retired and no longer used (key revoca
tions)</td>
</tr>
<tr>
<td align="right">32</td>
<td align="left">User ID information is no longer valid (cert
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 in
formation about the Reason for Revocation in human-readable form (UTF-8).
The string may be null (of zero length). The string may be null (of zero length).
The length of the subpacket is the length of the reason string plus one. 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. 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> 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
<t>If a key has been revoked because of a compromise, all signatures created by created by that key are suspect. However, if it was merely superseded or retire
that key are suspect. d, old signatures are still valid. If the revoked signature is the self-signatur
However, if it was merely superseded or retired, old signatures are still valid. e for certifying a User ID, a revocation denotes that that user name is no longe
If the revoked signature is the self-signature for certifying a User ID, a revoc r in use.
ation denotes that that user name is no longer in use.
Such a signature revocation <bcp14>SHOULD</bcp14> include a Reason for Revocatio n subpacket containing code 32.</t> Such a signature revocation <bcp14>SHOULD</bcp14> include a Reason for Revocatio n subpacket containing code 32.</t>
<t>Note that any certification may be revoked, including a certifica
<t>Note that any signature may be revoked, including a certification on some oth tion on some other person's key. There are many good reasons for revoking a cert
er person's key. ification signature, such as the case where the keyholder leaves the employ of a
There are many good reasons for revoking a certification signature, such as the business with an email address. A revoked certification is no longer a part of
case where the keyholder leaves the employ of a business with an email address. validity calculations.</t>
A revoked certification is no longer a part of validity calculations.</t> </section>
<section anchor="features-subpacket">
</section> <name>Features</name>
<section anchor="features-subpacket"><name>Features</name> <t>(N octets of flags)</t>
<t>The Features subpacket denotes which advanced OpenPGP features a
<t>(N octets of flags)</t> user's implementation supports. This is so that as features are added to OpenPGP
that cannot be backward compatible, a user can state that they can use that fea
<t>The Features subpacket denotes which advanced OpenPGP features a user's imple ture. The flags are single bits that indicate that a given feature is supported.
mentation supports. </t>
This is so that as features are added to OpenPGP that cannot be backwards-compat <t>This subpacket is similar to a preferences subpacket and only app
ible, a user can state that they can use that feature. ears in a self-signature.</t>
The flags are single bits that indicate that a given feature is supported.</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 imple
<t>This subpacket is similar to a preferences subpacket, and only appears in a s mentation can infer support for the feature from another implementation-dependen
elf-signature.</t> t mechanism.</t>
<t>Defined features are as follows:</t>
<t>An implementation <bcp14>SHOULD NOT</bcp14> use a feature listed when sending <t>First octet:</t>
to a user who does not state that they can use it, unless the implementation ca <table anchor="features-flags-registry">
n infer support for the feature from another implementation-dependent mechanism. <name>OpenPGP Features Flags Registry</name>
</t> <thead>
<tr>
<t>Defined features are as follows:</t> <th align="left">Feature</th>
<th align="left">Definition</th>
<t>First octet:</t> <th align="left">Reference</th>
</tr>
<texttable title="OpenPGP Features Flags registry" anchor="features-flags-regist </thead>
ry"> <tbody>
<ttcol align='left'>Feature</ttcol> <tr>
<ttcol align='left'>Definition</ttcol> <td align="left">0x01...</td>
<ttcol align='left'>Reference</ttcol> <td align="left">Symmetrically Encrypted Integrity Protected D
<c>0x01...</c> ata packet version 1</td>
<c>Symmetrically Encrypted Integrity Protected Data packet version 1</c> <td align="left"><xref target="version-one-seipd"/></td>
<c><xref target="version-one-seipd"/></c> </tr>
<c>0x02...</c> <tr>
<c>Reserved</c> <td align="left">0x02...</td>
<c>&#160;</c> <td align="left">Reserved</td>
<c>0x04...</c> <td align="left"></td>
<c>Reserved</c> </tr>
<c>&#160;</c> <tr>
<c>0x08...</c> <td align="left">0x04...</td>
<c>Symmetrically Encrypted Integrity Protected Data packet version 2</c> <td align="left">Reserved</td>
<c><xref target="version-two-seipd"/></c> <td align="left"></td>
</texttable> </tr>
<tr>
<t>If an implementation implements any of the defined features, it <bcp14>SHOULD <td align="left">0x08...</td>
</bcp14> implement the Features subpacket, too.</t> <td align="left">Symmetrically Encrypted Integrity Protected D
ata packet version 2</td>
<t>See <xref target="ciphertext-malleability"/> for details about how to use the <td align="left"><xref target="version-two-seipd"/></td>
Features subpacket when generating encryption data.</t> </tr>
</tbody>
</section> </table>
<section anchor="signature-target-subpacket"><name>Signature Target</name> <t>If an implementation implements any of the defined features, it <
bcp14>SHOULD</bcp14> implement the Features subpacket, too.</t>
<t>(1 octet public-key algorithm, 1 octet hash algorithm, N octets hash)</t> <t>See <xref target="ciphertext-malleability"/> for details about ho
w to use the Features subpacket when generating encryption data.</t>
<t>This subpacket identifies a specific target signature to which a signature re </section>
fers. <section anchor="signature-target-subpacket">
For revocation signatures, this subpacket provides explicit designation of which <name>Signature Target</name>
signature is being revoked. <t>(1 octet public-key algorithm, 1 octet hash algorithm, N octets h
For a third-party or timestamp signature, this designates what signature is sign ash)</t>
ed. <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 desi
gnates what signature is signed.
All arguments are an identifier of that target signature.</t> 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
<t>The N octets of hash data <bcp14>MUST</bcp14> be the size of the hash of the signature's hash. For example, a target signature with a SHA-1 hash <bcp14>MUST<
signature. /bcp14> have 20 octets of hash data.</t>
For example, a target signature with a SHA-1 hash <bcp14>MUST</bcp14> have 20 oc </section>
tets of hash data.</t> <section anchor="embedded-signature-subpacket">
<name>Embedded Signature</name>
</section> <t>(1 signature packet body)</t>
<section anchor="embedded-signature-subpacket"><name>Embedded Signature</name> <t>This subpacket contains a complete Signature packet body as speci
fied in <xref target="signature-packet"/>.
<t>(1 signature packet body)</t>
<t>This subpacket contains a complete Signature packet body as specified in <xre
f target="signature-packet"/>.
It is useful when one signature needs to refer to, or be incorporated in, anothe r signature.</t> It is useful when one signature needs to refer to, or be incorporated in, anothe r signature.</t>
</section>
</section> <section anchor="issuer-fingerprint-subpacket">
<section anchor="issuer-fingerprint-subpacket"><name>Issuer Fingerprint</name> <name>Issuer Fingerprint</name>
<t>(1 octet key version number, N octets of fingerprint)</t>
<t>(1 octet key version number, N octets of fingerprint)</t> <t>The OpenPGP Key fingerprint of the key issuing the signature.
<t>The OpenPGP Key fingerprint of the key issuing the signature.
This subpacket <bcp14>SHOULD</bcp14> be included in all signatures. 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 tar get="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 fi ngerprint.</t> If the version of the issuing key is 4 and an Issuer Key ID subpacket (<xref tar get="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 fi ngerprint.</t>
<t>Note that the length N of the fingerprint for a version 4 key is
<t>Note that the length N of the fingerprint for a version 4 key is 20 octets; f 20 octets; for a version 6 key, N is 32.
or a version 6 key N is 32.
Since the version of the signature is bound to the version of the key, the versi on octet here <bcp14>MUST</bcp14> match the version of the signature. Since the version of the signature is bound to the version of the key, the versi on octet here <bcp14>MUST</bcp14> match the version of the signature.
If the version octet does not match the signature version, the receiving impleme ntation <bcp14>MUST</bcp14> treat it as a malformed signature (see <xref target= "malformed-signatures"/>).</t> If the version octet does not match the signature version, the receiving impleme ntation <bcp14>MUST</bcp14> treat it as a malformed signature (see <xref target= "malformed-signatures"/>).</t>
</section>
<section 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>SH
OULD</bcp14> be considered valid only in an encrypted context, where the key it
was encrypted to is one of the indicated primary keys or one of their subkeys. T
his can be used to prevent forwarding a signature outside of its intended, encry
pted 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, N is 32.</t>
<t>An implementation <bcp14>SHOULD</bcp14> generate this subpacket w
hen creating a signed and encrypted message.</t>
<t>When generating this subpacket in a v6 signature, it <bcp14>SHOUL
D</bcp14> be marked as critical.</t>
</section>
</section>
<section anchor="computing-signatures">
<name>Computing Signatures</name>
</section> <t>All signatures are formed by producing a hash over the signature da
<section anchor="intended-recipient-fingerprint"><name>Intended Recipient Finger ta and then using the resulting hash in the signature algorithm.</t>
print</name> <t>When creating or verifying a v6 signature, the salt is fed into the
hash context before any other data.</t>
<t>(1 octet key version number, N octets of fingerprint)</t> <t>For binary document signatures (type ID 0x00), the document data is
hashed directly.
<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>SH
OULD</bcp14> be considered valid only in an encrypted context, where the key it
was encrypted to is one of the indicated primary keys, or one of their subkeys.
This can be used to prevent forwarding a signature outside of its intended, encr
ypted context (see <xref target="surreptitious-forwarding"/>).</t>
<t>Note that the length N of the fingerprint for a version 4 key is 20 octets; f
or a version 6 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 Signatures</name>
<t>All signatures are formed by producing a hash over the signature data, and th
en using the resulting hash in the signature algorithm.</t>
<t>When creating or verifying a v6 signature, the salt is fed into the hash cont
ext before any other data.</t>
<t>For binary document signatures (type ID 0x00), the document data is hashed di
rectly.
For text document signatures (type ID 0x01), the implementation <bcp14>MUST</bcp 14> first canonicalize the document by converting line endings to &lt;CR&gt;&lt; LF&gt; and encoding it in UTF-8 (see <xref target="RFC3629"/>). For text document signatures (type ID 0x01), the implementation <bcp14>MUST</bcp 14> first canonicalize the document by converting line endings to &lt;CR&gt;&lt; LF&gt; and encoding it in UTF-8 (see <xref target="RFC3629"/>).
The resulting UTF-8 bytestream is hashed.</t> The resulting UTF-8 byte stream is hashed.</t>
<t>When a v4 signature is made over a key, the hash data starts with t
<t>When a v4 signature is made over a key, the hash data starts with the octet 0 he octet 0x99, followed by a two-octet length of the key, followed by the body o
x99, followed by a two-octet length of the key, and then the body of the key pac f the key packet.
ket. When a v6 signature is made over a key, the hash data starts with the salt and t
When a v6 signature is made over a key, the hash data starts with the salt, then hen octet 0x9B, followed by a four-octet length of the key, followed by the body
octet 0x9B, followed by a four-octet length of the key, and then the body of th of the key packet.</t>
e key packet.</t> <t>A subkey binding signature (type ID 0x18) or primary key binding si
gnature (type ID 0x19) then hashes the subkey using the same format as the main
<t>A subkey binding signature (type ID 0x18) or primary key binding signature (t key (also using 0x99 or 0x9B as the first octet). Primary key revocation signatu
ype ID 0x19) then hashes the subkey using the same format as the main key (also res (type ID 0x20) hash only the key being revoked.
using 0x99 or 0x9B as the first octet). A subkey revocation signature (type ID 0x28) first hashes the primary key and th
Primary key revocation signatures (type ID 0x20) hash only the key being revoked en the subkey being revoked.</t>
. <t>A certification signature (type ID 0x10 through 0x13) hashes the User ID that
Subkey revocation signature (type ID 0x28) hash first the primary key and then t is bound to the key into the hash context after the above data. A v3 certificat
he subkey being revoked.</t> ion hashes the contents of the User ID or User Attribute packet without the pack
et header. A v4 or v6 certification hashes the constant 0xB4 for User ID certifi
<t>A certification signature (type ID 0x10 through 0x13) hashes the User ID bein cations or the constant 0xD1 for User Attribute certifications, followed by a fo
g bound to the key into the hash context after the above data. ur-octet number giving the length of the User ID or User Attribute data, followe
A v3 certification hashes the contents of the User ID or User Attribute packet, d by the User ID or User Attribute data.</t>
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 nu
mber giving the length of the User ID or User Attribute data, and then 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 signatur
e, 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 pack
et being hashed is not included in the hash, and the unhashed subpacket data len
gth 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">
<t>A v3 signature hashes five octets of the packet body, starting from the sig
nature type field.
This data is the signature type, followed by the four-octet signature creation t
ime.</t>
<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 ext
ra trailer.
Thus, the hashed fields are: <list style="symbols">
<t>An octet indicating the signature version (0x04 for v4, 0x06 for v6),</
t>
<t>The signature type,</t>
<t>The public-key algorithm,</t>
<t>The hash algorithm,</t>
<t>The hashed subpacket length,</t>
<t>The hashed subpacket body,</t>
<t>A second version octet (0x04 for v4, 0x06 for v6)</t>
<t>A single octet 0xFF,</t>
<t>A number representing the length (in octets) of the hashed data from th
e 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>
<t>After all this has been hashed in a single hash context, the resulting hash f
ield is used in the signature algorithm and its first two octets are placed in t
he 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 Signature Computation<
/name>
<t>The data actually hashed by OpenPGP varies depending on signature version, in <t>A third-party confirmation signature (type ID 0x50) hashes the salt (v6 signa
order to ensure that a signature made using one version cannot be repurposed as tures only), followed by the octet 0x88, followed by the four-octet length of th
a signature with a different version over subtly different data. e signature, and then the body of the Signature packet. (Note that this is a Leg
The hashed data streams differ based on their trailer, most critically in the fi acy packet header for a Signature packet with the length-of-length field set to
fth and sixth octets from the end of the stream. zero.) The unhashed subpacket data of the Signature packet being hashed is not i
ncluded 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 traile
r depends on the version of the signature.</t>
<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 f
irst field, the version number, through the end of the hashed subpacket data and
a final extra trailer. Thus, the hashed fields are: </t>
<ul spacing="normal">
<li>
<t>an octet indicating the signature version (0x04 for v4, and
0x06 for v6),</t>
</li>
<li>
<t>the signature type,</t>
</li>
<li>
<t>the public-key algorithm,</t>
</li>
<li>
<t>the hash algorithm,</t>
</li>
<li>
<t>the hashed subpacket length,</t>
</li>
<li>
<t>the hashed subpacket body,</t>
</li>
<li>
<t>a second version octet (0x04 for v4, and 0x06 for v6),</t>
</li>
<li>
<t>a single octet 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-oc
tet big-endian unsigned integer of the length modulo 2<sup>32</sup>.</t>
</li>
</ul>
</li>
</ul>
<t>After all this has been hashed in a single hash context, the result
ing hash field is used in the signature algorithm, and its first two octets are
placed in the Signature packet, as described in <xref target="version-four-and-s
ix-sig"/>.</t>
<t>For worked examples of the data hashed during a signature, see <xre
f target="sig-hashed-data-example"/>.</t>
<section anchor="sig-computation-notes">
<name>Notes about Signature Computation</name>
<t>The data actually hashed by OpenPGP varies depending on the signa
ture 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> In particular:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>A v3 signature uses the fifth octet from the end to store its signature typ <t>A v3 signature uses the fifth octet from the end to store its
e ID. signature type ID.
This <bcp14>MUST NOT</bcp14> be signature type ID <spanx style="verb">0xFF</span This <bcp14>MUST NOT</bcp14> be signature type ID <tt>0xFF</tt>.</t>
x>.</t> </li>
<t>All signature versions later than v3 always use a literal <spanx style="ver <li>
b">0xFF</spanx> in the fifth octet from the end. <t>All signature versions later than v3 always use a literal <tt
For these later signature versions, the sixth octet from the end (the octet befo >0xFF</tt> in the fifth octet from the end.
re the <spanx style="verb">0xFF</spanx>) stores the signature version number.</t For these later signature versions, the sixth octet from the end (the octet befo
> re the <tt>0xFF</tt>) stores the signature version number.</t>
</list></t> </li>
</ul>
</section> </section>
</section> </section>
<section anchor="malformed-signatures"><name>Malformed and Unknown Signatures</n <section anchor="malformed-signatures">
ame> <name>Malformed and Unknown Signatures</name>
<t>In some cases, a signature packet (or its corresponding One-Pass Si
<t>In some cases, a signature packet (or its corresponding One-Pass Signature pa gnature packet; see <xref target="one-pass-sig"/>) may be malformed or unknown.
cket, 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 ex haustive list):</t> For example, it might encounter any of the following problems (this is not an ex haustive list):</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>An unknown signature type</t> <t>An unknown signature type</t>
<t>An unknown signature version</t> </li>
<t>An unsupported signature version</t> <li>
<t>An unknown "critical" subpacket (see <xref target="signature-subpacket"/>) <t>An unknown signature version</t>
in the hashed area</t> </li>
<t>A subpacket with a length that diverges from the expected length</t> <li>
<t>A hashed subpacket area with length that exceeds the length of the signatur <t>An unsupported signature version</t>
e packet itself</t> </li>
<t>A known-weak hash algorithm (e.g. MD5)</t> <li>
<t>A mismatch between the hash algorithm expected salt length and the actual s <t>An unknown "critical" subpacket (see <xref target="signature-su
alt length</t> bpacket"/>) in the hashed area</t>
<t>A mismatch between the One-Pass Signature version and the Signature version </li>
(see <xref target="signed-message-versions"/>)</t> <li>
<t>A signature with a version other than 6, made by a v6 key</t> <t>A subpacket with a length that diverges from the expected lengt
</list></t> h</t>
</li>
<t>When an implementation encounters such a malformed or unknown signature, it < <li>
bcp14>MUST</bcp14> ignore the signature for validation purposes. <t>A hashed subpacket area with length that exceeds the length of
the signature packet itself</t>
</li>
<li>
<t>A hash algorithm known to be weak (e.g., MD5)</t>
</li>
<li>
<t>A mismatch between the expected salt length of the hash algorit
hm and the actual salt length</t>
</li>
<li>
<t>A mismatch between the One-Pass Signature version and the Signa
ture 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>
</li>
</ul>
<t>When an implementation encounters such a malformed or unknown signa
ture, it <bcp14>MUST</bcp14> ignore the signature for validation purposes.
It <bcp14>MUST NOT</bcp14> indicate a successful signature validation for such a signature. 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 strea m or reject other signatures in the same packet stream just because an unknown o r invalid signature exists.</t> At the same time, it <bcp14>MUST NOT</bcp14> halt processing on the packet strea m or reject other signatures in the same packet stream just because an unknown o r invalid signature exists.</t>
<t>This requirement is necessary for forward compatibility.
<t>This requirement is necessary for forward-compatibility.
Producing an output that indicates that no successful signatures were found is p referable to aborting processing entirely.</t> Producing an output that indicates that no successful signatures were found is p referable to aborting processing entirely.</t>
</section>
</section> </section>
</section> <section anchor="skesk">
<section anchor="skesk"><name>Symmetric-Key Encrypted Session Key Packet (Type I <name>Symmetric-Key Encrypted Session Key Packet (Type ID 3)</name>
D 3)</name> <t>The Symmetric-Key Encrypted Session Key (SKESK) packet holds the symm
etric-key encryption of a session key used to encrypt a message.
<t>The Symmetric-Key Encrypted Session Key (SKESK) packet holds the symmetric-ke Zero or more Public-Key Encrypted Session Key packets (<xref target="pkesk"/>) a
y encryption of a session key used to encrypt a message. nd/or Symmetric-Key Encrypted Session Key packets precede an encryption containe
Zero or more Public-Key Encrypted Session Key packets (<xref target="pkesk"/>) a r (that is, a Symmetrically Encrypted Integrity Protected Data packet or -- for
nd/or Symmetric-Key Encrypted Session Key packets precede an encryption containe historic data -- a Symmetrically Encrypted Data packet) that holds an encrypted
r (that is, a Symmetrically Encrypted Integrity Protected Data packet or --- for message. The message is encrypted with a session key, and the session key is its
historic data --- a Symmetrically Encrypted Data packet) that holds an encrypte elf encrypted and stored in the Encrypted Session Key packet(s).</t>
d message. <t>If the encryption container is preceded by one or more Symmetric-Key
The message is encrypted with a session key, and the session key is itself encry Encrypted Session Key packets, each specifies a passphrase that may be used to d
pted and stored in the Encrypted Session Key packet(s).</t> ecrypt the message.
<t>If the encryption container is preceded by one or more Symmetric-Key Encrypte
d Session Key packets, each specifies a passphrase that may be used to decrypt t
he message.
This allows a message to be encrypted to a number of public keys, and also to on e or more passphrases.</t> This allows a message to be encrypted to a number of public keys, and also to on e or more passphrases.</t>
<t>The body of this packet starts with a one-octet number giving the ver
<t>The body of this packet starts with a one-octet number giving the version num sion number of the packet type.
ber of the packet type.
The currently defined versions are 4 and 6. The currently defined versions are 4 and 6.
The remainder of the packet depends on the version.</t> The remainder of the packet depends on the version.</t>
<t>The versions differ in how they encrypt the session key with the pass
<t>The versions differ in how they encrypt the session key with the passphrase, phrase and in what they encode.
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"/>). 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 establi shed in <xref target="encrypted-message-versions"/>.</t> Any new version of the SKESK packet should be registered in the registry establi shed in <xref target="encrypted-message-versions"/>.</t>
<section anchor="v4-skesk">
<section anchor="v4-skesk"><name>Version 4 Symmetric-Key Encrypted Session Key P <name>Version 4 Symmetric-Key Encrypted Session Key Packet Format</nam
acket Format</name> e>
<t>A version 4 SKESK packet precedes a v1 SEIPD (see <xref target="ver
<t>A version 4 Symmetric-Key Encrypted Session Key (SKESK) packet precedes a ver sion-one-seipd"/>).
sion 1 Symmetrically Encrypted Integrity Protected Data (v1 SEIPD, see <xref tar In historic data, it is sometimes found preceding a deprecated SED packet (see <
get="version-one-seipd"/>) packet. xref target="sed"/>). A v4 SKESK packet <bcp14>MUST NOT</bcp14> precede a v2 SEI
In historic data, it is sometimes found preceding a deprecated Symmetrically Enc PD packet (see <xref target="encrypted-message-versions"/>).</t>
rypted Data packet (SED, see <xref target="sed"/>). <t>A version 4 Symmetric-Key Encrypted Session Key packet consists of:
A v4 SKESK packet <bcp14>MUST NOT</bcp14> precede a v2 SEIPD packet (see <xref t </t>
arget="encrypted-message-versions"/>).</t> <ul spacing="normal">
<li>
<t>A version 4 Symmetric-Key Encrypted Session Key packet consists of:</t> <t>A one-octet version number with value 4.</t>
</li>
<t><list style="symbols"> <li>
<t>A one-octet version number with value 4.</t> <t>A one-octet number describing the symmetric algorithm used.</t>
<t>A one-octet number describing the symmetric algorithm used.</t> </li>
<t>A string-to-key (S2K) specifier. <li>
The length of the string-to-key specifier depends on its type (see <xref target= <t>An S2K specifier. The length of the S2K specifier depends on it
"s2k-types"/>).</t> s type (see <xref target="s2k-types"/>).</t>
<t>Optionally, the encrypted session key itself, which is decrypted with the s </li>
tring-to-key object.</t> <li>
</list></t> <t>Optionally, the encrypted session key itself, which is decrypte
d with the S2K object.</t>
<t>If the encrypted session key is not present (which can be detected on the bas </li>
is of packet length and S2K specifier size), then the S2K algorithm applied to t </ul>
he passphrase produces the session key for decrypting the message, using the sym <t>If the encrypted session key is not present (which can be detected
metric cipher algorithm from the Symmetric-Key Encrypted Session Key packet.</t> on the basis of packet length and S2K specifier size), then the S2K algorithm ap
plied to the passphrase produces the session key for decrypting the message, usi
<t>If the encrypted session key is present, the result of applying the S2K algor ng the symmetric cipher algorithm from the Symmetric-Key Encrypted Session Key p
ithm to the passphrase is used to decrypt just that encrypted session key field, acket.</t>
using CFB mode with an IV of all zeros. <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 specifie s the symmetric-key encryption algorithm used to encrypt the following encryptio n container, followed by the session key octets themselves.</t> The decryption result consists of a one-octet algorithm identifier that specifie s the symmetric-key encryption algorithm used to encrypt the following encryptio n container, followed by the session key octets themselves.</t>
<t>Note: because an all-zero IV is used for this decryption, the S2K s
<t>Note: because an all-zero IV is used for this decryption, the S2K specifier < pecifier <bcp14>MUST</bcp14> use a salt value, a Salted S2K, an Iterated and Sal
bcp14>MUST</bcp14> use a salt value, either a Salted S2K, an Iterated-Salted S2K ted S2K, or Argon2.
, or Argon2.
The salt value will ensure that the decryption key is not repeated even if the p assphrase is reused.</t> The salt value will ensure that the decryption key is not repeated even if the p assphrase is reused.</t>
</section>
</section> <section anchor="v6-skesk">
<section anchor="v6-skesk"><name>Version 6 Symmetric-Key Encrypted Session Key P <name>Version 6 Symmetric-Key Encrypted Session Key Packet Format</nam
acket Format</name> e>
<t>A version 6 SKESK packet precedes a version 2 SEIPD packet (see <xr
<t>A version 6 Symmetric-Key Encrypted Session Key (SKESK) packet precedes a ver ef target="version-two-seipd"/>).
sion 2 Symmetrically Encrypted Integrity Protected Data (v2 SEIPD, see <xref tar
get="version-two-seipd"/>) packet.
A v6 SKESK packet <bcp14>MUST NOT</bcp14> precede a v1 SEIPD packet or a depreca ted Symmetrically Encrypted Data packet (see <xref target="encrypted-message-ver sions"/>).</t> A v6 SKESK packet <bcp14>MUST NOT</bcp14> precede a v1 SEIPD packet or a depreca ted Symmetrically Encrypted Data packet (see <xref target="encrypted-message-ver sions"/>).</t>
<t>A version 6 Symmetric-Key Encrypted Session Key packet consists of:
<t>A version 6 Symmetric-Key Encrypted Session Key packet consists of:</t> </t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>A one-octet version number with value 6.</t> <t>A one-octet version number with value 6.</t>
<t>A one-octet scalar octet count for the 5 fields following this octet.</t> </li>
<t>A one-octet symmetric cipher algorithm ID from <xref target="symkey-algorit <li>
hms-registry"/>.</t> <t>A one-octet scalar octet count for the 5 fields following this
<t>A one-octet AEAD algorithm identifier from <xref target="aead-algorithms-re octet.</t>
gistry"/>.</t> </li>
<t>A one-octet scalar octet count of the following field.</t> <li>
<t>A string-to-key (S2K) specifier. <t>A one-octet symmetric cipher algorithm ID (from <xref target="s
The length of the string-to-key specifier depends on its type (see <xref target= ymkey-algorithms-registry"/>).</t>
"s2k-types"/>).</t> </li>
<t>A starting initialization vector of size specified by the AEAD algorithm.</ <li>
t> <t>A one-octet AEAD algorithm identifier (from <xref target="aead-
<t>The encrypted session key itself.</t> algorithms-registry"/>).</t>
<t>An authentication tag for the AEAD mode.</t> </li>
</list></t> <li>
<t>A one-octet scalar octet count of the following field.</t>
<t>A key-encryption key is derived using HKDF (<xref target="RFC5869"/>) with SH </li>
A256 (<xref target="RFC6234"/>) as the hash algorithm. <li>
<t>An S2K specifier. The length of the S2K specifier depends on it
s type (see <xref target="s2k-types"/>).</t>
</li>
<li>
<t>A starting IV of the 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>
</li>
</ul>
<t>A key-encryption key (KEK) is derived using HKDF <xref target="RFC5
869"/> with SHA256 <xref target="RFC6234"/> as the hash algorithm.
The Initial Keying Material (IKM) for HKDF is the key derived from S2K. The Initial Keying Material (IKM) for HKDF is the key derived from S2K.
No salt is used. No salt is used. The info parameter is comprised of the Packet Type ID in OpenPG
The info parameter is comprised of the Packet Type ID in OpenPGP format encoding P format encoding (bits 7 and 6 are set, and bits 5-0 carry the packet type ID),
(bits 7 and 6 set, bits 5-0 carry the packet type ID), the packet version, and the packet version, and the cipher-algo and AEAD-mode used to encrypt the key m
the cipher-algo and AEAD-mode used to encrypt the key material.</t> aterial.</t>
<t>Then, the session key is encrypted using the resulting key, with th
<t>Then, the session key is encrypted using the resulting key, with the AEAD alg e AEAD algorithm specified for version 2 of the Symmetrically Encrypted Integrit
orithm specified for version 2 of the Symmetrically Encrypted Integrity Protecte y Protected Data packet.
d Data packet.
Note that no chunks are used and that there is only one authentication tag. 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 set, bits 5-0 carry t he packet type ID), the packet version number, the cipher algorithm ID, and the AEAD algorithm ID are given as additional data. 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 octe ts 0xC3, 0x06, 0x07, and 0x02.</t> For example, the additional data used with AES-128 with OCB consists of the octe ts 0xC3, 0x06, 0x07, and 0x02.</t>
</section>
</section> </section>
</section> <section anchor="one-pass-sig">
<section anchor="one-pass-sig"><name>One-Pass Signature Packet (Type ID 4)</name <name>One-Pass Signature Packet (Type ID 4)</name>
> <t>The One-Pass Signature packet precedes the signed data and contains e
nough information to allow the receiver to begin calculating any hashes needed t
<t>The One-Pass Signature packet precedes the signed data and contains enough in o verify the signature.
formation to allow the receiver to begin calculating any hashes needed to verify It allows the Signature packet to be placed at the end of the message so that th
the signature. e signer can compute the entire signed message in one pass.</t>
It allows the Signature packet to be placed at the end of the message, so that t <t>The body of this packet consists of:</t>
he signer can compute the entire signed message in one pass.</t> <ul spacing="normal">
<li>
<t>The body of this packet consists of:</t> <t>A one-octet version number.
<t><list style="symbols">
<t>A one-octet version number.
The currently defined versions are 3 and 6. The currently defined versions are 3 and 6.
Any new One-Pass Signature packet version should be registered in the registry e stablished in <xref target="signed-message-versions"/>.</t> Any new One-Pass Signature packet version should be registered in the registry e stablished in <xref target="signed-message-versions"/>.</t>
<t>A one-octet signature type ID. </li>
<li>
<t>A one-octet signature type ID.
Signature types are described in <xref target="signature-types"/>.</t> Signature types are described in <xref target="signature-types"/>.</t>
<t>A one-octet number describing the hash algorithm used.</t> </li>
<t>A one-octet number describing the public-key algorithm used.</t> <li>
<t>Only for v6 packets, a variable-length field containing: <list style="symb <t>A one-octet number describing the hash algorithm used.</t>
ols"> </li>
<t>A one-octet salt size. The value <bcp14>MUST</bcp14> match the value de <li>
fined for the hash algorithm as specified in <xref target="hash-algorithms-regis <t>A one-octet number describing the public-key algorithm used.</t>
try"/>.</t> </li>
<t>The salt; a random value of the specified size. The value <bcp14>MUST</ <li>
bcp14> match the salt field of the corresponding Signature packet.</t> <t>Only for v6 packets, a variable-length field containing: </t>
</list></t> <ul spacing="normal">
<t>Only for v3 packets, an eight-octet number holding the Key ID of the signin <li>
g key.</t> <t>A one-octet salt size. The value <bcp14>MUST</bcp14> match th
<t>Only for v6 packets, 32 octets of the fingerprint of the signing key. e value defined for the hash algorithm as specified in <xref target="hash-algori
thms-registry"/>.</t>
</li>
<li>
<t>The salt; a random value of the specified size. The value <bc
p14>MUST</bcp14> match the salt field of the corresponding Signature packet.</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> Since a v6 signature can only be made by a v6 key, the length of the fingerprint is fixed.</t>
<t>A one-octet number holding a flag showing whether the signature is nested. </li>
<li>
<t>A one-octet number holding a flag showing whether the signature i
s 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> 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</bcp <t>When generating a one-pass signature, the OPS packet version <bcp14>M
14> correspond to the version of the associated signature packet, except for the UST</bcp14> correspond to the version of the associated signature packet, except
historical accident that v4 keys use a v3 one-pass signature packet (there is n for the historical accident that v4 keys use a v3 one-pass signature packet (th
o v4 OPS). ere is no v4 OPS).
See <xref target="signed-message-versions"/> for the full correspondence of vers ions between Keys, Signatures, and One-Pass Signatures.</t> See <xref target="signed-message-versions"/> for the full correspondence of vers ions between Keys, Signatures, and One-Pass Signatures.</t>
<t>Note that if a message contains more than one one-pass signature, the
<t>Note that if a message contains more than one one-pass signature, then the Si n the Signature packets bracket the message; that is, the first Signature packet
gnature packets bracket the message; that is, the first Signature packet after t after the message corresponds to the last one-pass packet and the final Signatu
he message corresponds to the last one-pass packet and the final Signature packe re packet corresponds to the first one-pass packet.</t>
t corresponds to the first one-pass packet.</t> </section>
<section anchor="key-material-packets">
</section> <name>Key Material Packets</name>
<section anchor="key-material-packets"><name>Key Material Packets</name> <t>A key material packet contains all the information about a public or
private key.
<t>A key material packet contains all the information about a public or private There are four variants of this packet type: two major versions (versions 4 and
key. 6) and two strongly deprecated versions (versions 2 and 3). Consequently, this s
There are four variants of this packet type, two major versions (versions 4 and ection is complex.</t>
6), and two strongly deprecated versions (versions 2 and 3). <t>For historical reasons, versions 1 and 5 of the key packets are unspe
Consequently, this section is complex.</t> cified.</t>
<section anchor="key-packet-variants">
<t>For historical reasons, versions 1 and 5 of the key packets are unspecified.< <name>Key Packet Variants</name>
/t> <section anchor="pubkey">
<name>Public-Key Packet (Type ID 6)</name>
<section anchor="key-packet-variants"><name>Key Packet Variants</name> <t>A Public-Key packet starts a series of packets that forms an Open
PGP key (sometimes called an OpenPGP certificate).</t>
<section anchor="pubkey"><name>Public-Key Packet (Type ID 6)</name> </section>
<section anchor="pubsubkey">
<t>A Public-Key packet starts a series of packets that forms an OpenPGP key (som <name>Public-Subkey Packet (Type ID 14)</name>
etimes called an OpenPGP certificate).</t> <t>A Public-Subkey packet (type ID 14) has exactly the same format a
s a Public-Key packet, but it denotes a subkey. One or more subkeys may be assoc
</section> iated with a top-level key.
<section anchor="pubsubkey"><name>Public-Subkey Packet (Type ID 14)</name> By convention, the top-level key offers certification capability, but it does no
t provide encryption services, while a dedicated subkey provides encryption (see
<t>A Public-Subkey packet (type ID 14) has exactly the same format as a Public-K <xref target="common-requirements"/>).</t>
ey packet, but denotes a subkey. </section>
One or more subkeys may be associated with a top-level key. <section anchor="seckey">
By convention, the top-level key offers certification capability, but does not p <name>Secret-Key Packet (Type ID 5)</name>
rovide encryption services, while a dedicated subkey provides encryption (see <x <t>A Secret-Key packet contains all the information that is found in
ref target="common-requirements"/>).</t> a Public-Key packet, including the public-key material, but it also includes th
e secret-key material after all the public-key fields.</t>
</section> </section>
<section anchor="seckey"><name>Secret-Key Packet (Type ID 5)</name> <section anchor="secsubkey">
<name>Secret-Subkey Packet (Type ID 7)</name>
<t>A Secret-Key packet contains all the information that is found in a Public-Ke <t>A Secret-Subkey packet (type ID 7) is the subkey analog of the Se
y packet, including the public-key material, but also includes the secret-key ma cret-Key packet and has exactly the same format.</t>
terial after all the public-key fields.</t> </section>
</section>
</section> <section anchor="public-key-packet-formats">
<section anchor="secsubkey"><name>Secret-Subkey Packet (Type ID 7)</name> <name>Public-Key Packet Formats</name>
<t>There are four versions of key-material packets.
<t>A Secret-Subkey packet (type ID 7) is the subkey analog of the Secret-Key pac
ket and has exactly the same format.</t>
</section>
</section>
<section anchor="public-key-packet-formats"><name>Public-Key Packet Formats</nam
e>
<t>There are four versions of key-material packets.
The V2 and V3 versions have been deprecated since 1998. The V2 and V3 versions have been deprecated since 1998.
The V4 version has been deprecated by this document in 2023.</t> The V4 version has been deprecated by this document.</t>
<t>OpenPGP implementations <bcp14>SHOULD</bcp14> create keys with vers
<t>OpenPGP implementations <bcp14>SHOULD</bcp14> create keys with version 6 form ion 6 format.
at. V4 keys are deprecated; an implementation <bcp14>SHOULD NOT</bcp14> generate a v
V4 keys are deprecated; an implementation <bcp14>SHOULD NOT</bcp14> generate a v 4 key but <bcp14>SHOULD</bcp14> accept it. V3 keys are deprecated; an implementa
4 key, but <bcp14>SHOULD</bcp14> accept it. tion <bcp14>MUST NOT</bcp14> generate a v3 key but <bcp14>MAY</bcp14> accept it.
V3 keys are deprecated; an implementation <bcp14>MUST NOT</bcp14> generate a v3 V2 keys are deprecated; an implementation <bcp14>MUST NOT</bcp14> generate a v2
key, but <bcp14>MAY</bcp14> accept it. key but <bcp14>MAY</bcp14> accept it.</t>
V2 keys are deprecated; an implementation <bcp14>MUST NOT</bcp14> generate a v2 <t>Any new Key version must be registered in the registry established
key, but <bcp14>MAY</bcp14> accept it.</t> in <xref target="signed-message-versions"/>.</t>
<section anchor="v3-pubkeys">
<t>Any new Key version must be registered in the registry established in <xref t <name>Version 3 Public Keys</name>
arget="signed-message-versions"/>.</t> <t>V2 keys are identical to v3 keys except for the version number.
<section 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> A version 3 public key or public-subkey packet contains:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>A one-octet version number (3).</t> <t>A one-octet version number (3).</t>
<t>A four-octet number denoting the time that the key was created.</t> </li>
<t>A two-octet number denoting the time in days that this key is valid. <li>
<t>A four-octet number denoting the time that the key was create
d.</t>
</li>
<li>
<t>A two-octet number denoting the time in days that the key is
valid.
If this number is zero, then it does not expire.</t> If this number is zero, then it does not expire.</t>
<t>A one-octet number denoting the public-key algorithm of this key.</t> </li>
<t>A series of multiprecision integers comprising the key material: <list sty <li>
le="symbols"> <t>A one-octet number denoting the public-key algorithm of the k
<t>A multiprecision integer (MPI) of RSA public modulus n;</t> ey.</t>
<t>An MPI of RSA public encryption exponent e.</t> </li>
</list></t> <li>
</list></t> <t>A series of multiprecision integers comprising the key materi
al: </t>
<t>V3 keys are deprecated. <ul spacing="normal">
They contain three weaknesses. <li>
<t>MPI of RSA public modulus n.</t>
</li>
<li>
<t>MPI of RSA public encryption exponent e.</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 a ny other key because the Key ID is simply the low 64 bits of the public modulus. First, it is relatively easy to construct a v3 key that has the same Key ID as a ny other key because the Key ID is simply the low 64 bits of the public modulus.
Secondly, because the fingerprint of a v3 key hashes the key material, but not i Second, because the fingerprint of a v3 key hashes the key material, but not its
ts length, there is an increased opportunity for fingerprint collisions. length, there is an increased opportunity for fingerprint collisions.
Third, there are weaknesses in the MD5 hash algorithm that make developers prefe Third, there are weaknesses in the MD5 hash algorithm that cause developers to p
r other algorithms. refer other algorithms.
See <xref target="key-ids-fingerprints"/> for a fuller discussion of Key IDs and fingerprints.</t> See <xref target="key-ids-fingerprints"/> for a fuller discussion of Key IDs and fingerprints.</t>
</section>
</section> <section anchor="v4-pubkeys">
<section anchor="v4-pubkeys"><name>Version 4 Public Keys</name> <name>Version 4 Public Keys</name>
<t>The version 4 format is similar to the version 3 format except fo
<t>The version 4 format is similar to the version 3 format except for the absenc r the absence of a validity period.
e of a validity period.
This has been moved to the Signature packet. This has been moved to the Signature packet.
In addition, fingerprints of version 4 keys are calculated differently from vers ion 3 keys, as described in <xref target="key-ids-fingerprints"/>.</t> In addition, fingerprints of version 4 keys are calculated differently from vers ion 3 keys, as described in <xref target="key-ids-fingerprints"/>.</t>
<t>A version 4 packet contains:</t>
<t>A version 4 packet contains:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>A one-octet version number (4).</t>
<t>A one-octet version number (4).</t> </li>
<t>A four-octet number denoting the time that the key was created.</t> <li>
<t>A one-octet number denoting the public-key algorithm of this key.</t> <t>A four-octet number denoting the time that the key was create
<t>A series of values comprising the key material. d.</t>
This is algorithm-specific and described in <xref target="algorithm-specific-par </li>
ts-of-keys"/>.</t> <li>
</list></t> <t>A one-octet number denoting the public-key algorithm of the k
ey.</t>
</section> </li>
<section anchor="v6-pubkeys"><name>Version 6 Public Keys</name> <li>
<t>A series of values comprising the key material.
<t>The version 6 format is similar to the version 4 format except for the additi This is algorithm specific and described in <xref target="algorithm-specific-par
on of a count for the key material. ts-of-keys"/>.</t>
</li>
</ul>
</section>
<section anchor="v6-pubkeys">
<name>Version 6 Public Keys</name>
<t>The version 6 format is similar to the version 4 format except fo
r the addition of a count for the key material.
This count helps parsing secret key packets (which are an extension of the publi c key packet format) in the case of an unknown algorithm. This count helps parsing secret key packets (which are an extension of the publi c key packet format) in the case of an unknown algorithm.
In addition, fingerprints of version 6 keys are calculated differently from vers In addition, fingerprints of version 6 keys are calculated differentl
ion 4 keys, as described in <xref target="key-ids-fingerprints"/>.</t> y from version 4 keys, as described in <xref target="key-ids-fingerprints"/>.</t
>
<t>A version 6 packet contains:</t>
<t><list style="symbols">
<t>A one-octet version number (6).</t>
<t>A four-octet number denoting the time that the key was created.</t>
<t>A one-octet number denoting the public-key algorithm of this key.</t>
<t>A four-octet scalar octet count for the following public key material.</t>
<t>A series of values comprising the public key material.
This is algorithm-specific and described in <xref target="algorithm-specific-par
ts-of-keys"/>.</t>
</list></t>
</section>
</section>
<section anchor="secret-key-packet-formats"><name>Secret-Key Packet Formats</nam
e>
<t>The Secret-Key and Secret-Subkey packets contain all the data of the Public-K
ey 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"> <t>A version 6 packet contains:</t>
<t>The fields of a Public-Key or Public-Subkey packet, as described above.</t> <ul spacing="normal">
<t>One octet (the "S2K usage octet") indicating whether and how the secret key <li>
material is protected by a passphrase. <t>A one-octet version number (6).</t>
Zero indicates that the secret-key data is not encrypted. </li>
255 (MalleableCFB), 254 (CFB), or 253 (AEAD) indicates that a string-to-key spec <li>
ifier and other parameters will follow. <t>A four-octet number denoting the time that the key was create
d.</t>
</li>
<li>
<t>A one-octet number denoting the public-key algorithm of the k
ey.</t>
</li>
<li>
<t>A four-octet scalar octet count for the public key material s
pecified in the next field.</t>
</li>
<li>
<t>A series of values comprising the public key material.
This is algorithm specific and described in <xref target="algorithm-specific-par
ts-of-keys"/>.</t>
</li>
</ul>
</section>
</section>
<section anchor="secret-key-packet-formats">
<name>Secret-Key Packet Formats</name>
<t>The Secret-Key and Secret-Subkey packets contain all the data of th
e Public-Key and Public-Subkey packets, with additional algorithm-specific secre
t-key data appended, usually in encrypted form.</t>
<t>The packet contains:</t>
<ul spacing="normal">
<li>
<t>The fields of a Public-Key or Public-Subkey packet, as describe
d above.</t>
</li>
<li>
<t>One octet (the "S2K usage octet") indicating whether and how th
e secret key material is protected by a passphrase.
Zero indicates that the secret-key data is not encrypted. 253 (AEAD), 254 (CFB)
, or 255 (MalleableCFB) indicates that an S2K specifier and other parameters wil
l follow.
Any other value is a symmetric-key encryption algorithm identifier. Any other value is a symmetric-key encryption algorithm identifier.
A version 6 packet <bcp14>MUST NOT</bcp14> use the value 255 (MalleableCFB).</t> A version 6 packet <bcp14>MUST NOT</bcp14> use the value 255 (MalleableCFB).</t>
<t>Only for a version 6 packet where the secret key material is encrypted (tha </li>
t is, where the previous octet is not zero), a one-octet scalar octet count of t <li>
he cumulative length of all the following conditionally included string-to-key p <t>Only for a version 6 packet where the secret key material is en
arameter fields.</t> crypted (that is, where the previous octet is not zero), a one-octet scalar octe
<t>Conditionally included string-to-key parameter fields: <list style="symbol t count of the cumulative length of all the following conditionally included S2K
s"> parameter fields.</t>
<t>If string-to-key usage octet was 255, 254, or 253, a one-octet symmetri </li>
c encryption algorithm.</t> <li>
<t>If string-to-key usage octet was 253 (AEAD), a one-octet AEAD algorithm <t>Conditionally included S2K parameter fields: </t>
.</t> <ul spacing="normal">
<t>Only for a version 6 packet, and if string-to-key usage octet was 254, <li>
or 253, a one-octet count of the size of the one field following this octet.</t> <t>If the S2K usage octet was 253, 254, or 255, a one-octet sy
<t>If string-to-key usage octet was 255, 254, or 253, a string-to-key (S2K mmetric encryption algorithm.</t>
) specifier. </li>
The length of the string-to-key specifier depends on its type (see <xref target= <li>
"s2k-types"/>).</t> <t>If the S2K usage octet was 253 (AEAD), a one-octet AEAD alg
<t>If string-to-key usage octet was 253 (AEAD), an initialization vector ( orithm.</t>
IV) of size specified by the AEAD algorithm (see <xref target="version-two-seipd </li>
"/>), which is used as the nonce for the AEAD algorithm.</t> <li>
<t>If string-to-key usage octet was 255, 254, or a cipher algorithm ID (th <t>Only for a version 6 packet, and if the S2K usage octet was
at is, the secret data uses some form of CFB encryption), an initialization vect 253 or 254, a one-octet count of the size of the one field following this octet
or (IV) of the same length as the cipher's block size.</t> .</t>
</list></t> </li>
<t>Plain or encrypted multiprecision integers comprising the secret key data. <li>
This is algorithm-specific and described in <xref target="algorithm-specific-par <t>If the S2K usage octet was 253, 254, or 255, an S2K specifi
ts-of-keys"/>. er. The length of the S2K specifier depends on its type (see <xref target="s2k-t
If the string-to-key usage octet is 253 (AEAD), then an AEAD authentication tag ypes"/>).</t>
is at the end of that data. </li>
If the string-to-key usage octet is 254 (CFB), a 20-octet SHA-1 hash of the plai <li>
ntext of the algorithm-specific portion is appended to plaintext and encrypted w <t>If the S2K usage octet was 253 (AEAD), an IV of a size spec
ith it. ified by the AEAD algorithm (see <xref target="version-two-seipd"/>), which is u
If the string-to-key usage octet is 255 (MalleableCFB) or another nonzero value sed as the nonce for the AEAD algorithm.</t>
(that is, a symmetric-key encryption algorithm identifier), a two-octet checksum </li>
of the plaintext of the algorithm-specific portion (sum of all octets, mod 6553 <li>
6) is appended to plaintext and encrypted with it. <t>If the S2K usage octet was 254, 255, or a cipher algorithm
(This is deprecated and <bcp14>SHOULD NOT</bcp14> be used, see below.)</t> ID (that is, the secret data uses some form of CFB encryption), an IV of the sam
<t>Only for a version 3 or 4 packet where the string-to-key usage octet is zer e length as the cipher's block size.</t>
o, a two-octet checksum of the algorithm-specific portion (sum of all octets, mo </li>
d 65536).</t> </ul>
</list></t> </li>
<li>
<t>The details about storing algorithm-specific secrets above are summarized in <t>Plain or encrypted multiprecision integers comprising the secre
<xref target="secret-key-protection-registry"/>.</t> t key data.
This is algorithm specific and described in <xref target="algorithm-specific-par
<t>Note that the version 6 packet format adds two count values to help parsing p ts-of-keys"/>.
ackets with unknown S2K or public key algorithms.</t> If the S2K usage octet is 253 (AEAD), then an AEAD authentication tag is at the
end of that data.
<t>Secret MPI values can be encrypted using a passphrase. If the S2K usage octet is 254 (CFB), a 20-octet SHA-1 hash of the plaintext of t
If a string-to-key specifier is given, that describes the algorithm for converti he algorithm-specific portion is appended to plaintext and encrypted with it.
ng the passphrase to a key, else a simple MD5 hash of the passphrase is used. If the S2K usage octet is 255 (MalleableCFB) or another non-zero value (that is,
An implementation producing a passphrase-protected secret key packet <bcp14>MUST a symmetric-key encryption algorithm identifier), a two-octet checksum of the p
</bcp14> use a string-to-key specifier; the simple hash is for read-only backwar laintext of the algorithm-specific portion (sum of all octets, mod 65536) is app
d compatibility, though implementations <bcp14>MAY</bcp14> continue to use exist ended to plaintext and encrypted with it.
ing private keys in the old format. (This is deprecated and <bcp14>SHOULD NOT</bcp14> be used; see below.)</t>
The cipher for encrypting the MPIs is specified in the Secret-Key packet.</t> </li>
<li>
<t>Encryption/decryption of the secret data is done using the key created from t <t>Only for a version 3 or 4 packet where the S2K usage octet is z
he passphrase and the initialization vector from the packet. ero, a two-octet checksum of the algorithm-specific portion (sum of all octets,
If the string-to-key usage octet is not 253, CFB mode is used. mod 65536).</t>
</li>
</ul>
<t>The details about storing algorithm-specific secrets above are summ
arized 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 an S2K sp
ecifier is given, it describes the algorithm for converting the passphrase to a
key; otherwise, a simple MD5 hash of the passphrase is used. An implementation p
roducing a passphrase-protected secret key packet <bcp14>MUST</bcp14> use an S2K
specifier; the simple hash is for read-only backward compatibility, though impl
ementations <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 crea
ted from the passphrase and the IV from the packet.
If the S2K 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 f ormats. A different mode is used with v3 keys (which are only RSA) than with other key f ormats.
With v3 keys, the MPI bit count prefix (that is, the first two octets) is not en crypted. With v3 keys, the MPI bit count prefix (that is, the first two octets) is not en crypted.
Only the MPI non-prefix data is encrypted. Only the MPI non-prefix data is encrypted.
Furthermore, the CFB state is resynchronized at the beginning of each new MPI va Furthermore, the CFB state is resynchronized at the beginning of each new MPI va
lue, so that the CFB block boundary is aligned with the start of the MPI data.</ lue so that the CFB block boundary is aligned with the start of the MPI data.</t
t> >
<t>With v4 and v6 keys, a simpler method is used.
<t>With v4 and v6 keys, a simpler method is used. All secret MPI values are encrypted, including the MPI bit count prefix.</t>
All secret MPI values are encrypted, including the MPI bitcount prefix.</t> <t>If the S2K usage octet is 253, the KEK is derived using HKDF <xref
target="RFC5869"/> to provide key separation. SHA256 <xref target="RFC6234"/> is
<t>If the string-to-key usage octet is 253, the key encryption key is derived us used as the hash algorithm for HKDF. IKM for HKDF is the key derived from S2K.
ing HKDF (<xref target="RFC5869"/>) to provide key separation. No salt is used. The info parameter is comprised of the Packet Type ID
SHA256 (<xref target="RFC6234"/>) is used as the hash algorithm for HKDF. encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 carry the packet t
The Initial Keying Material (IKM) for HKDF is the key derived from S2K. ype ID), the packet version, and the cipher-algo and AEAD-mode used to encrypt t
No salt is used. he key material.</t>
The info parameter is comprised of the Packet Type ID encoded in OpenPGP format <t>Then, the encrypted MPI values are encrypted as one combined plaint
(bits 7 and 6 set, bits 5-0 carry the packet type ID), the packet version, and t ext using one of the AEAD algorithms specified for version 2 of the Symmetricall
he cipher-algo and AEAD-mode used to encrypt the key material.</t> y Encrypted Integrity Protected Data packet.
<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 Encrypte
d Integrity Protected Data packet.
Note that no chunks are used and that there is only one authentication tag. 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 As additional data, the Packet Type ID in OpenPGP format encoding (bits 7 and 6
set, bits 5-0 carry the packet type ID), followed by the public key packet field are set, and bits 5-0 carry the packet type ID), followed by the public key pack
s, starting with the packet version number, are passed to the AEAD algorithm. et fields, starting with the packet version number, are passed to the AEAD algor
For example, the additional data used with a Secret-Key packet of version 4 cons ithm. For example, the additional data used with a Secret-Key packet of version
ists of the octets 0xC5, 0x04, followed by four octets of creation time, one oct 4 consists of the octets 0xC5, 0x04, followed by four octets of creation time, o
et denoting the public-key algorithm, and the algorithm-specific public-key para ne octet denoting the public-key algorithm, and the algorithm-specific public-ke
meters. y parameters.
For a Secret-Subkey packet, the first octet would be 0xC7. 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 o ctet count of the public key material would be included as well (see <xref targe t="public-key-packet-formats"/>).</t> For a version 6 key packet, the second octet would be 0x06, and the four-octet o ctet count of the public key material would be included as well (see <xref targe t="public-key-packet-formats"/>).</t>
<t>The two-octet checksum that follows the algorithm-specific portion
<t>The two-octet checksum that follows the algorithm-specific portion is the alg is the algebraic sum, mod 65536, of the plaintext of all the algorithm-specific
ebraic sum, mod 65536, of the plaintext of all the algorithm-specific octets (in octets (including the MPI prefix and data).
cluding MPI prefix and data). With v3 keys, the checksum is stored in the clear. With v4 keys, the checksum is
With v3 keys, the checksum is stored in the clear. encrypted like the algorithm-specific data. This value is used to check that th
With v4 keys, the checksum is encrypted like the algorithm-specific data. e passphrase was correct.
This value is used to check that the passphrase was correct. However, this checksum is deprecated, and an implementation <bcp14>SHOULD NOT</b
However, this checksum is deprecated; an implementation <bcp14>SHOULD NOT</bcp14 cp14> use it; instead, an implementation should use the SHA-1 hash denoted with
> use it, but should rather use the SHA-1 hash denoted with a usage octet of 254 a usage octet of 254.
. The reason for this is that there are some attacks that involve modifying the se
The reason for this is that there are some attacks that involve undetectably mod cret key undetected.
ifying the secret key. If the S2K usage octet is 253, no checksum or SHA-1 hash is used, but the authen
If the string-to-key usage octet is 253 no checksum or SHA-1 hash is used but th tication tag of the AEAD algorithm follows.</t>
e 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 stre
<t>When decrypting the secret key material using any of these schemes (that is, am must be well formed.
where the usage octet is non-zero), the resulting cleartext octet stream must be
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 object s. In particular, an implementation <bcp14>MUST NOT</bcp14> interpret octets beyond the unwrapped cleartext octet stream as part of any of the unwrapped MPI object s.
Furthermore, an implementation <bcp14>MUST</bcp14> reject as unusable any secret Furthermore, an implementation <bcp14>MUST</bcp14> reject any secret key materia
key material whose cleartext length does not align with the lengths of the unwr l whose cleartext length does not align with the lengths of the unwrapped MPI ob
apped MPI objects.</t> jects as unusable.</t>
</section>
</section> <section anchor="key-ids-fingerprints">
<section anchor="key-ids-fingerprints"><name>Key IDs and Fingerprints</name> <name>Key IDs and Fingerprints</name>
<t>Every OpenPGP key has a fingerprint and a key ID.
<t>Every OpenPGP key has a fingerprint and a key ID.
The computation of these values differs based on the key version. 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 onl y used in v3 PKESK packets, see <xref target="v3-pkesk"/>) is always 64 bits. The fingerprint length varies with the key version, but the key ID (which is onl y used in v3 PKESK packets; see <xref target="v3-pkesk"/>) is always 64 bits.
The following registry represents the subsections below:</t> The following registry represents the subsections below:</t>
<texttable title="OpenPGP Key ID and Fingerprint registry" anchor="key-id-finger <table anchor="key-id-fingerprint-registry">
print-registry"> <name>OpenPGP Key IDs and Fingerprints Registry</name>
<ttcol align='left'>Key Version</ttcol> <thead>
<ttcol align='left'>Fingerprint</ttcol> <tr>
<ttcol align='left'>Fingerprint Length (bits)</ttcol> <th align="left">Key Version</th>
<ttcol align='left'>Key ID</ttcol> <th align="left">Fingerprint</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Fingerprint Length (Bits)</th>
<c>3</c> <th align="left">Key ID</th>
<c>MD5(MPIs without length octets)</c> <th align="left">Reference</th>
<c>128</c> </tr>
<c>low 64 bits of RSA modulus</c> </thead>
<c><xref target="v3-key-id-fingerprint"/></c> <tbody>
<c>4</c> <tr>
<c>SHA1(normalized pubkey packet)</c> <td align="left">3</td>
<c>160</c> <td align="left">MD5(MPIs without length octets)</td>
<c>last 64 bits of fingerprint</c> <td align="left">128</td>
<c><xref target="v4-key-id-fingerprint"/></c> <td align="left">low 64 bits of RSA modulus</td>
<c>6</c> <td align="left">
<c>SHA256(normalized pubkey packet)</c> <xref target="v3-key-id-fingerprint"/></td>
<c>256</c> </tr>
<c>first 64 bits of fingerprint</c> <tr>
<c><xref target="v6-key-id-fingerprint"/></c> <td align="left">4</td>
</texttable> <td align="left">SHA1(normalized pubkey packet)</td>
<td align="left">160</td>
<section anchor="v3-key-id-fingerprint"><name>Version 3 Key ID and Fingerprint</ <td align="left">last 64 bits of fingerprint</td>
name> <td align="left">
<xref target="v4-key-id-fingerprint"/></td>
<t>For a v3 key, the eight-octet Key ID consists of the low 64 bits of the publi </tr>
c modulus of the RSA key.</t> <tr>
<td align="left">6</td>
<t>The fingerprint of a v3 key is formed by hashing the body (but not the two-oc <td align="left">SHA256(normalized pubkey packet)</td>
tet length) of the MPIs that form the key material (public modulus n, followed b <td align="left">256</td>
y exponent e) with MD5. <td align="left">first 64 bits of fingerprint</td>
<td align="left">
<xref target="v6-key-id-fingerprint"/></td>
</tr>
</tbody>
</table>
<section 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 no
t 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> Note that both v3 keys and MD5 are deprecated.</t>
</section>
</section> <section anchor="v4-key-id-fingerprint">
<section anchor="v4-key-id-fingerprint"><name>Version 4 Key ID and Fingerprint</ <name>Version 4 Key ID and Fingerprint</name>
name> <t>A v4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, fol
lowed by the two-octet packet length, followed by the entire Public-Key packet s
<t>A v4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, followed by the tarting with the version field.
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. The Key ID is the low-order 64 bits of the fingerprint.
Here are the fields of the hash material, with the example of an Ed25519 key:</t Here are the fields of the hash material, including an example of an Ed25519 key
> :</t>
<ol type="a.%d)">
<t>a.1) 0x99 (1 octet)</t> <li>0x99 (1 octet)</li>
<li>two-octet, big-endian scalar octet count of (b)-(e)</li>
<t>a.2) two-octet, big-endian scalar octet count of (b)-(e)</t> </ol>
<ol type="%c)" start="2">
<t>b) version number = 4 (1 octet);</t> <li>version number = 4 (1 octet)</li>
<li>timestamp of key creation (4 octets)</li>
<t>c) timestamp of key creation (4 octets);</t> <li>algorithm (1 octet): 27 = Ed25519 (example)</li>
<li>algorithm-specific fields</li>
<t>d) algorithm (1 octet): 27 = Ed25519 (example);</t> </ol>
<t>Algorithm-specific fields for Ed25519 keys (example):</t>
<t>e) Algorithm-specific fields.</t>
<t>Algorithm-Specific Fields for Ed25519 keys (example):</t>
<t>e.1) 32 octets representing the public key.</t>
</section>
<section 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 <ol type="e.%d)">
the four-octet packet length, followed by the entire Public-Key packet starting <li>32 octets representing the public key</li>
with the version field. </ol>
</section>
<section 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 pack
et starting with the version field.
The Key ID is the high-order 64 bits of the fingerprint. The Key ID is the high-order 64 bits of the fingerprint.
Here are the fields of the hash material, with the example of an Ed25519 key:</t Here are the fields of the hash material, including an example of an
> Ed25519 key:</t>
<t>a.1) 0x9B (1 octet)</t>
<t>a.2) four-octet scalar octet count of (b)-(f)</t>
<t>b) version number = 6 (1 octet);</t>
<t>c) timestamp of key creation (4 octets);</t>
<t>d) algorithm (1 octet): 27 = Ed25519 (example);</t>
<t>e) four-octet scalar octet count for the following key material;</t>
<t>f) algorithm-specific fields.</t>
<t>Algorithm-Specific Fields for Ed25519 keys (example):</t>
<t>e.1) 32 octets representing the public key.</t>
<t>Note that it is possible for there to be collisions of Key IDs --- two differ
ent keys with the same Key ID.
Note that there is a much smaller, but still non-zero, probability that two diff
erent 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 wa
y as for a primary key, including the 0x99 (v4 key) or 0x9B (v6 key) as the firs
t octet (even though this is not a valid packet type ID for a public subkey).</t
>
</section> <ol type="a.%d)">
</section> <li>0x9B (1 octet)</li>
<section anchor="algorithm-specific-parts-of-keys"><name>Algorithm-specific Part <li>four-octet scalar octet count of (b)-(f)</li>
s of Keys</name> </ol>
<ol type="%c)" start="2">
<li>version number = 6 (1 octet)</li>
<li>timestamp of key creation (4 octets)</li>
<li>algorithm (1 octet): 27 = Ed25519 (example)</li>
<li>four-octet scalar octet count for the key material specified in
the next field</li>
<li>algorithm-specific public key material</li>
</ol>
<t>Algorithm-specific fields for Ed25519 keys (example):</t>
<t>The public and secret key format specifies algorithm-specific parts of a key. <ol type="f.%d)">
<li>32 octets representing the public 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 sma
ller, but still non-zero, probability that two different keys have the same fing
erprint.</t>
<t>Also note that if v3, v4, and v6 format keys share the same RSA k
ey 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 Parts of Keys</name>
<t>The public and secret key formats specify algorithm-specific parts
of a key.
The following sections describe them in detail.</t> The following sections describe them in detail.</t>
<section anchor="key-rsa">
<section anchor="key-rsa"><name>Algorithm-Specific Part for RSA Keys</name> <name>Algorithm-Specific Part for RSA Keys</name>
<t>For RSA keys, the public key consists of this series of multiprec
<t>The public key is this series of multiprecision integers:</t> ision integers:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>MPI of RSA public modulus n;</t> <t>MPI of RSA public modulus n,</t>
<t>MPI of RSA public encryption exponent e.</t> </li>
</list></t> <li>
<t>MPI of RSA public encryption exponent e.</t>
<t>The secret key is this series of multiprecision integers:</t> </li>
</ul>
<t><list style="symbols"> <t>The secret key consists of this series of multiprecision integers
<t>MPI of RSA secret exponent d;</t> :</t>
<t>MPI of RSA secret prime value p;</t> <ul spacing="normal">
<t>MPI of RSA secret prime value q (p &lt; q);</t> <li>
<t>MPI of u, the multiplicative inverse of p, mod q.</t> <t>MPI of RSA secret exponent d;</t>
</list></t> </li>
<li>
</section> <t>MPI of RSA secret prime value p;</t>
<section anchor="key-dsa"><name>Algorithm-Specific Part for DSA Keys</name> </li>
<li>
<t>The public key is this series of multiprecision integers:</t> <t>MPI of RSA secret prime value q (p &lt; q); and</t>
</li>
<t><list style="symbols"> <li>
<t>MPI of DSA prime p;</t> <t>MPI of u, the multiplicative inverse of p, mod q.</t>
<t>MPI of DSA group order q (q is a prime divisor of p-1);</t> </li>
<t>MPI of DSA group generator g;</t> </ul>
<t>MPI of DSA public-key value y (= g**x mod p where x is secret).</t> </section>
</list></t> <section anchor="key-dsa">
<name>Algorithm-Specific Part for DSA Keys</name>
<t>The secret key is this single multiprecision integer:</t> <t>For DSA keys, the public key consists of this series of multiprec
ision integers:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>MPI of DSA secret exponent x.</t> <li>
</list></t> <t>MPI of DSA prime p;</t>
</li>
</section> <li>
<section anchor="key-elgamal"><name>Algorithm-Specific Part for Elgamal Keys</na <t>MPI of DSA group order q (q is a prime divisor of p-1);</t>
me> </li>
<li>
<t>The public key is this series of multiprecision integers:</t> <t>MPI of DSA group generator g; and</t>
</li>
<t><list style="symbols"> <li>
<t>MPI of Elgamal prime p;</t> <t>MPI of DSA public-key value y (= g<sup>x</sup> mod p where x
<t>MPI of Elgamal group generator g;</t> is secret).</t>
<t>MPI of Elgamal public key value y (= g**x mod p where x is secret).</t> </li>
</list></t> </ul>
<t>The secret key consists of this single multiprecision integer:</t
<t>The secret key is this single multiprecision integer:</t> >
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>MPI of Elgamal secret exponent x.</t> <t>MPI of DSA secret exponent x.</t>
</list></t> </li>
</ul>
</section> </section>
<section anchor="key-ecdsa"><name>Algorithm-Specific Part for ECDSA Keys</name> <section anchor="key-elgamal">
<name>Algorithm-Specific Part for Elgamal Keys</name>
<t>The public key is this series of values:</t> <t>For Elgamal keys, the public key consists of this series of multi
precision integers:</t>
<t><list style="symbols"> <ul spacing="normal">
<t>A variable-length field containing a curve OID, which is formatted as follo <li>
ws: <list style="symbols"> <t>MPI of Elgamal prime p;</t>
<t>A one-octet size of the following field; values 0 and 0xFF are reserved </li>
for future extensions,</t> <li>
<t>The octets representing a curve OID (defined in <xref target="ec-curves <t>MPI of Elgamal group generator g; and</t>
"/>);</t> </li>
</list></t> <li>
<t>MPI of an EC point representing a public key.</t> <t>MPI of Elgamal public key value y (= g<sup>x</sup> mod p wher
</list></t> e x is secret).</t>
</li>
<t>The secret key is this single multiprecision integer:</t> </ul>
<t>The secret key consists of this single multiprecision integer:</t
<t><list style="symbols"> >
<t>MPI of an integer representing the secret key, which is a scalar of the pub <ul spacing="normal">
lic EC point.</t> <li>
</list></t> <t>MPI of Elgamal secret exponent x.</t>
</li>
</section> </ul>
<section anchor="key-eddsa-legacy"><name>Algorithm-Specific Part for EdDSALegacy </section>
Keys (deprecated)</name> <section anchor="key-ecdsa">
<name>Algorithm-Specific Part for ECDSA Keys</name>
<t>The public key is this series of values:</t> <t>For ECDSA keys, the public key consists of this series of values:
</t>
<t><list style="symbols"> <ul spacing="normal">
<t>A variable-length field containing a curve OID, formatted as follows: <lis <li>
t style="symbols"> <t>A variable-length field containing a curve OID, which is form
<t>A one-octet size of the following field; values 0 and 0xFF are reserved atted as follows: </t>
for future extensions,</t> <ul spacing="normal">
<t>The octets representing a curve OID, defined in <xref target="ec-curves <li>
"/>;</t> <t>A one-octet size of the following field; values 0 and 0xF
</list></t> F are reserved for future extensions.</t>
<t>An MPI of an EC point representing a public key Q in prefixed native form ( </li>
see <xref target="ec-point-prefixed-native"/>).</t> <li>
</list></t> <t>The octets representing a curve OID, as defined in <xref
target="ec-curves"/>.</t>
<t>The secret key is this single multiprecision integer:</t> </li>
</ul>
<t><list style="symbols"> </li>
<t>An MPI-encoded octet string representing the native form of the secret key, <li>
in the curve-specific format described in <xref target="curve-specific-formats" <t>An MPI of an EC point representing a public key.</t>
/>.</t> </li>
</list></t> </ul>
<t>The secret key consists of this single multiprecision integer:</t
<t>Note that the native form for an EdDSA secret key is a fixed-width sequence o >
f unstructured random octets, with size corresponding to the specific curve. <ul spacing="normal">
That sequence of random octets is used with a cryptographic digest to produce bo <li>
th a curve-specific secret scalar and a prefix used when making a signature. <t>An MPI of an integer representing the secret key, which is a
scalar of the public EC point.</t>
</li>
</ul>
</section>
<section anchor="key-eddsa-legacy">
<name>Algorithm-Specific Part for EdDSALegacy Keys (Deprecated)</nam
e>
<t>For EdDSALegacy keys (deprecated), the public key consists of thi
s series of values:</t>
<ul spacing="normal">
<li>
<t>A variable-length field containing a curve OID, formatted as
follows: </t>
<ul spacing="normal">
<li>
<t>A one-octet size of the following field; values 0 and 0xF
F are reserved for future extensions.</t>
</li>
<li>
<t>The octets representing a curve OID, as defined in <xref
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>
</li>
</ul>
<t>The secret key consists of this single multiprecision integer:</t
>
<ul spacing="normal">
<li>
<t>An MPI-encoded octet string representing the native form of t
he secret key in the curve-specific format, as described in <xref target="curve-
specific-formats"/>.</t>
</li>
</ul>
<t>Note that the native form for an EdDSA secret key is a fixed-widt
h sequence of unstructured random octets, with size corresponding to the specifi
c curve. That sequence of random octets is used with a cryptographic digest to p
roduce both a curve-specific secret scalar and a prefix used when making a signa
ture.
See <xref section="5.1.5" sectionFormat="of" target="RFC8032"/> for more details about how to use the native octet strings for Ed25519Legacy. 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 seq uence of random octets.</t> The value stored in an OpenPGP EdDSALegacy secret key packet is the original seq uence of random octets.</t>
<t>Note that the only curve defined for use with EdDSALegacy is the
<t>Note that the only curve defined for use with EdDSALegacy is the Ed25519Legac Ed25519Legacy OID.</t>
y OID.</t> </section>
<section anchor="key-ecdh">
</section> <name>Algorithm-Specific Part for ECDH Keys</name>
<section anchor="key-ecdh"><name>Algorithm-Specific Part for ECDH Keys</name> <t>For ECDH keys, the public key consists of this series of values:<
/t>
<t>The public key is this series of values:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>A variable-length field containing a curve OID, which is form
<t>A variable-length field containing a curve OID, which is formatted as follo atted as follows: </t>
ws: <list style="symbols"> <ul spacing="normal">
<t>A one-octet size of the following field; values 0 and 0xFF are reserved <li>
for future extensions,</t> <t>A one-octet size of the following field; values 0 and 0xF
<t>Octets representing a curve OID, defined in <xref target="ec-curves"/>; F are reserved for future extensions.</t>
</t> </li>
</list></t> <li>
<t>MPI of an EC point representing a public key, in the point format associate <t>The octets representing a curve OID, as defined in <xref
d with the curve as specified in <xref target="curve-specific-formats"/>.</t> target="ec-curves"/>.</t>
<t>A variable-length field containing KDF parameters, which is formatted as fo </li>
llows: <list style="symbols"> </ul>
<t>A one-octet size of the following fields; values 0 and 0xFF are reserve </li>
d for future extensions,</t> <li>
<t>A one-octet value 1, reserved for future extensions,</t> <t>An MPI of an EC point representing a public key, in the point
<t>A one-octet hash function ID used with a KDF,</t> format associated with the curve, as specified in <xref target="curve-specific-
<t>A one-octet algorithm ID for the symmetric algorithm used to wrap the s formats"/>.</t>
ymmetric key used for the message encryption; see <xref target="ecdh"/> for deta </li>
ils.</t> <li>
</list></t> <t>A variable-length field containing key derivation function (K
</list></t> DF) parameters, which is formatted as follows: </t>
<ul spacing="normal">
<t>The secret key is this single multiprecision integer:</t> <li>
<t>A one-octet size of the following fields; values 0 and 0x
<t><list style="symbols"> FF are reserved for future extensions.</t>
<t>An MPI representing the secret key, in the curve-specific format described </li>
in <xref target="curve-specific-formats"/>.</t> <li>
</list></t> <t>A one-octet value 1, reserved for future extensions.</t>
</li>
<section anchor="ecdh-secret-key-material"><name>ECDH Secret Key Material</name> <li>
<t>A one-octet hash function ID used with a KDF.</t>
<t>When curve NIST P-256, NIST P-384, NIST P-521, brainpoolP256r1, brainpoolP384 </li>
r1, or brainpoolP512r1 are used in ECDH, their secret keys are represented as a <li>
simple integer in standard MPI form. <t>A one-octet algorithm ID for the symmetric algorithm that
is used to wrap the symmetric key for message encryption; see <xref target="ecd
h"/> for details.</t>
</li>
</ul>
</li>
</ul>
<t>The secret key consists of this single multiprecision integer:</t
>
<ul spacing="normal">
<li>
<t>An MPI representing the secret key, in the curve-specific for
mat described in <xref target="curve-specific-formats"/>.</t>
</li>
</ul>
<section 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 rep
resented 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> 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">
<section anchor="curve25519-secrets"><name>Curve25519Legacy ECDH Secret Key Mate <name>Curve25519Legacy ECDH Secret Key Material (Deprecated)</na
rial (deprecated)</name> me>
<t>A Curve25519Legacy secret key is stored as a standard integer
<t>A Curve25519Legacy secret key is stored as a standard integer in big-endian M in big-endian MPI form.
PI form.
Curve25519Legacy <bcp14>MUST NOT</bcp14> be used in key packets version 6 or abo ve. Curve25519Legacy <bcp14>MUST NOT</bcp14> be used in key packets version 6 or abo ve.
Note that this form is in reverse octet order from the little-endian "native" fo rm found in <xref target="RFC7748"/>.</t> Note that this form is in reverse octet order from the little-endian "native" fo rm found in <xref target="RFC7748"/>.</t>
<t>Note also that the integer for a Curve25519Legacy secret key
<t>Note also that the integer for a Curve25519Legacy secret key for OpenPGP <bcp for OpenPGP <bcp14>MUST</bcp14> have the appropriate form; that is, it <bcp14>MU
14>MUST</bcp14> have the appropriate form: that is, it <bcp14>MUST</bcp14> be di ST</bcp14> be divisible by 8, <bcp14>MUST</bcp14> be at least 2<sup>254</sup>, a
visible by 8, <bcp14>MUST</bcp14> be at least 2**254, and <bcp14>MUST</bcp14> be nd <bcp14>MUST</bcp14> be less than 2<sup>255</sup>.
less than 2**255. The length of this MPI in bits is by definition always 255, so the two leading o
The length of this MPI in bits is by definition always 255, so the two leading o ctets of the MPI will always be <tt>00 FF</tt>, and reversing the following 32 o
ctets of the MPI will always be <spanx style="verb">00 FF</spanx> and reversing ctets from the wire will produce the "native" form.</t>
the following 32 octets from the wire will produce the "native" form.</t> <t>When generating a new Curve25519Legacy secret key from 32 ful
ly random octets, the following pseudocode produces the MPI wire format (note th
<t>When generating a new Curve25519Legacy secret key from 32 fully-random octets e similarity to <tt>decodeScalar25519</tt> as described in <xref target="RFC7748
, the following pseudocode produces the MPI wire format (note the similarity to "/>):</t>
<spanx style="verb">decodeScalar25519</spanx> from <xref target="RFC7748"/>):</t <sourcecode type="pseudocode"><![CDATA[
>
<figure><artwork><![CDATA[
def curve25519Legacy_MPI_from_random(octet_list): def curve25519Legacy_MPI_from_random(octet_list):
octet_list[0] &= 248 octet_list[0] &= 248
octet_list[31] &= 127 octet_list[31] &= 127
octet_list[31] |= 64 octet_list[31] |= 64
mpi_header = [ 0x00, 0xFF ] mpi_header = [ 0x00, 0xFF ]
return mpi_header || reversed(octet_list) return mpi_header || reversed(octet_list)
]]></artwork></figure> ]]></sourcecode>
</section>
</section> </section>
</section> </section>
</section> <section anchor="key-x25519">
<section anchor="key-x25519"><name>Algorithm-Specific Part for X25519 Keys</name <name>Algorithm-Specific Part for X25519 Keys</name>
> <t>For X25519 keys, the public key consists of this single value:</t
>
<t>The public key is this single value:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>32 octets of the native public key.</t>
<t>32 octets of the native public key.</t> </li>
</list></t> </ul>
<t>The secret key consists of this single value:</t>
<t>The secret key is this single value:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>32 octets of the native secret key.</t>
<t>32 octets of the native secret key.</t> </li>
</list></t> </ul>
<t>See <xref section="6.1" sectionFormat="of" target="RFC7748"/> for
<t>See <xref section="6.1" sectionFormat="of" target="RFC7748"/> for more detail more details about how to use the native octet strings.
s 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 secret key packet is the original sequence of random octets.
The value stored in an OpenPGP X25519 public key packet is the value X25519(secr etKey, 9).</t> The value stored in an OpenPGP X25519 public key packet is the value X25519(secr etKey, 9).</t>
</section>
</section> <section anchor="key-x448">
<section anchor="key-x448"><name>Algorithm-Specific Part for X448 Keys</name> <name>Algorithm-Specific Part for X448 Keys</name>
<t>For X448 keys, the public key consists of this single value:</t>
<t>The public key is this single value:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>56 octets of the native public key.</t>
<t>56 octets of the native public key.</t> </li>
</list></t> </ul>
<t>The secret key consists of this single value:</t>
<t>The secret key is this single value:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>56 octets of the native secret key.</t>
<t>56 octets of the native secret key.</t> </li>
</list></t> </ul>
<t>See <xref section="6.2" sectionFormat="of" target="RFC7748"/> for
<t>See <xref section="6.2" sectionFormat="of" target="RFC7748"/> for more detail more details about how to use the native octet strings.
s about how to use the native octet strings.
The value stored in an OpenPGP X448 secret key packet is the original sequence o f random octets. The value stored in an OpenPGP X448 secret key packet is the original sequence o f random octets.
The value stored in an OpenPGP X448 public key packet is the value X448(secretKe y, 5).</t> The value stored in an OpenPGP X448 public key packet is the value X448(secretKe y, 5).</t>
</section>
</section> <section anchor="key-ed25519">
<section anchor="key-ed25519"><name>Algorithm-Specific Part for Ed25519 Keys</na <name>Algorithm-Specific Part for Ed25519 Keys</name>
me> <t>For Ed25519 keys, the public key consists of this single value:</
t>
<t>The public key is this single value:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>32 octets of the native public key.</t>
<t>32 octets of the native public key.</t> </li>
</list></t> </ul>
<t>The secret key consists of this single value:</t>
<t>The secret key is this single value:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>32 octets of the native secret key.</t>
<t>32 octets of the native secret key.</t> </li>
</list></t> </ul>
<t>See <xref section="5.1.5" sectionFormat="of" target="RFC8032"/> f
<t>See <xref section="5.1.5" sectionFormat="of" target="RFC8032"/> for more deta or more details about how to use the native octet strings.
ils about how to use the native octet strings.
The value stored in an OpenPGP Ed25519 secret key packet is the original sequenc e of random octets.</t> The value stored in an OpenPGP Ed25519 secret key packet is the original sequenc e of random octets.</t>
</section>
</section> <section anchor="key-ed448">
<section anchor="key-ed448"><name>Algorithm-Specific Part for Ed448 Keys</name> <name>Algorithm-Specific Part for Ed448 Keys</name>
<t>For Ed448 keys, the public key consists of this single value:</t>
<t>The public key is this single value:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>57 octets of the native public key.</t>
<t>57 octets of the native public key.</t> </li>
</list></t> </ul>
<t>The secret key consists of this single value:</t>
<t>The secret key is this single value:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>57 octets of the native secret key.</t>
<t>57 octets of the native secret key.</t> </li>
</list></t> </ul>
<t>See <xref section="5.2.5" sectionFormat="of" target="RFC8032"/> f
<t>See <xref section="5.2.5" sectionFormat="of" target="RFC8032"/> for more deta or more details about how to use the native octet strings.
ils 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> The value stored in an OpenPGP Ed448 secret key packet is the original sequence of random octets.</t>
</section>
</section> </section>
</section> </section>
</section> <section anchor="compressed-data">
<section anchor="compressed-data"><name>Compressed Data Packet (Type ID 8)</name <name>Compressed Data Packet (Type ID 8)</name>
> <t>The Compressed Data packet contains compressed data.
<t>The Compressed Data packet contains compressed data.
Typically, this packet is found as the contents of an encrypted packet, or follo wing a Signature or One-Pass Signature packet, and contains a literal data packe t.</t> Typically, this packet is found as the contents of an encrypted packet, or follo wing a Signature or One-Pass Signature packet, and contains a literal data packe t.</t>
<t>The body of this packet consists of:</t>
<t>The body of this packet consists of:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>One octet specifiying the algorithm used to compress the packet.<
<t>One octet that gives the algorithm used to compress the packet.</t> /t>
<t>Compressed data, which makes up the remainder of the packet.</t> </li>
</list></t> <li>
<t>Compressed data, which makes up the remainder of the packet.</t>
<t>A Compressed Data packet's body contains data that is a compression of a seri </li>
es of OpenPGP packets. </ul>
<t>A Compressed Data packet's body contains data that is a compression o
f a series of OpenPGP packets.
See <xref target="packet-sequence-composition"/> for details on how messages are formed.</t> 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 DEFLATE blo
<t>A ZIP-compressed series of packets is compressed into raw <xref target="RFC19 cks <xref target="RFC1951"/>.</t>
51"/> DEFLATE blocks.</t> <t>A ZLIB-compressed series of packets is compressed with raw ZLIB-style
blocks <xref target="RFC1950"/>.</t>
<t>A ZLIB-compressed series of packets is compressed with raw <xref target="RFC1 <t>A BZip2-compressed series of packets is compressed using the BZip2 <x
950"/> ZLIB-style blocks.</t> ref target="BZ2"/> algorithm.</t>
<t>An implementation that generates a Compressed Data packet <bcp14>MUST
<t>A BZip2-compressed series of packets is compressed using the BZip2 <xref targ </bcp14> use the OpenPGP format for packet framing (see <xref target="openpgp-pa
et="BZ2"/> algorithm.</t> cket-format"/>).
<t>An implementation that generates a Compressed Data packet <bcp14>MUST</bcp14>
use the 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> 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 genera
<t>An implementation that deals with either historic data or data generated by l ted by legacy implementations predating support for <xref target="RFC2440"/> <bc
egacy implementations predating support for <xref target="RFC2440"/> <bcp14>MAY< p14>MAY</bcp14> interpret Compressed Data packets that use the Legacy format for
/bcp14> interpret Compressed Data packets that use the Legacy format for packet packet framing.</t>
framing.</t> </section>
<section anchor="sed">
</section> <name>Symmetrically Encrypted Data Packet (Type ID 9)</name>
<section anchor="sed"><name>Symmetrically Encrypted Data Packet (Type ID 9)</nam <t>The Symmetrically Encrypted Data packet contains data encrypted with
e> 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, it cou
<t>The Symmetrically Encrypted Data packet contains data encrypted with a symmet ld be another sequence of packets that forms a valid OpenPGP message.</t>
ric-key algorithm. <t>This packet is obsolete.
When it has been decrypted, it contains other packets (usually a literal data pa
cket or compressed data packet, but in theory 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>MUST NOT</bcp14> create this packet.
An implementation <bcp14>SHOULD</bcp14> reject such a packet and stop processing the message. 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 If an implementation chooses to process the packet anyway, it <bcp14>MUST</bcp14
> return a clear warning that a non-integrity protected packet has been processe > return a clear warning that a non-integrity-protected packet has been processe
d.</t> d.</t>
<t>This packet format is impossible to handle safely in general because
<t>This packet format is impossible to handle safely in general because the ciph the ciphertext it provides is malleable.
ertext it provides is malleable.
See <xref target="ciphertext-malleability"/> about selecting a better OpenPGP en cryption container that does not have this flaw.</t> See <xref target="ciphertext-malleability"/> about selecting a better OpenPGP en cryption container that does not have this flaw.</t>
<t>The body of this packet consists of:</t>
<t>The body of this packet consists of:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>A random prefix, containing block-size random octets (for example
<t>A random prefix, containing block-size random octets (for example, 16 octet , 16 octets for a 128-bit block length) followed by a copy of the last two octet
s for a 128-bit block length) followed by a copy of the last two octets, encrypt s, encrypted together using Cipher Feedback (CFB) mode, with an IV of all zeros.
ed together using Cipher Feedback (CFB) mode, with an Initial Vector (IV) of all </t>
zeros.</t> </li>
<t>Data encrypted using CFB mode, with the last block-size octets of the first <li>
ciphertext as the IV.</t> <t>Data encrypted using CFB mode, with the last block-size octets of
</list></t> the first ciphertext as the IV.</t>
</li>
<t>The symmetric cipher used may be specified in a Public-Key or Symmetric-Key E </ul>
ncrypted Session Key packet that precedes the Symmetrically Encrypted Data packe <t>The symmetric cipher used may be specified in a Public-Key or Symmetr
t. ic-Key Encrypted Session Key packet that precedes the Symmetrically Encrypted Da
ta packet.
In that case, the cipher algorithm ID is prefixed to the session key before it i s encrypted. In that case, the cipher algorithm ID is prefixed to the session key before it i s encrypted.
If no packets of these types precede the encrypted data, the IDEA algorithm is u sed with the session key calculated as the MD5 hash of the passphrase, though th is use is deprecated.</t> If no packets of these types precede the encrypted data, the IDEA algorithm is u sed with the session key calculated as the MD5 hash of the passphrase, though th is use is deprecated.</t>
<t>The data is encrypted in CFB mode (see <xref target="cfb-mode"/>).
<t>The data is encrypted in CFB mode (see <xref target="cfb-mode"/>). For the random prefix, the IV is specified as all zeros. Instead of achieving ra
For the random prefix, the Initial Vector (IV) is specified as all zeros. ndomized encryption through an IV, a string of length equal to the block size of
Instead of achieving randomized encryption through an IV, a string of length equ the cipher plus two is encrypted for this purpose. The first block-size octets
al to the block size of the cipher plus two is encrypted for this purpose. (for example, 16 octets for a 128-bit block length) are random, and the followin
The first block-size octets (for example, 16 octets for a 128-bit block length) g two octets are copies of the last two octets of the first block-size random oc
are random, and the following two octets are copies of the last two octets of th tets. For example, for a 16-octet block length, octet 17 is a copy of octet 15,
e first block-size random octets. and octet 18 is a copy of octet 16. For a cipher of block length 8, octet 9 is a
For example, for a 16-octet block length, octet 17 is a copy of octet 15 and oct copy of octet 7, and octet 10 is a copy of octet 8. (In both of these examples,
et 18 is a copy of octet 16. we consider the first octet to be numbered 1.)</t>
For a cipher of block length 8, octet 9 is a copy of octet 7, and octet 10 is a <t>After encrypting these block-size-plus-two octets, a new CFB context
copy of octet 8. is created for the encryption of the data, with the last block-size octets of th
(In both these examples, we consider the first octet to be numbered 1.)</t> e first ciphertext as the IV. (Alternatively and equivalently, the CFB state is
resynchronized: the last block-size octets of ciphertext are passed through the
<t>After encrypting these block-size-plus-two octets, a new CFB context is creat cipher, and the block boundary is reset.)</t>
ed for the encryption of the data, with the last block-size octets of the first <t>The repetition of two octets in the random prefix allows the receiver
ciphertext as the IV. to immediately check whether the session key is incorrect.
(Alternatively and equivalently, the CFB state is resynchronized: the last block
-size octets of ciphertext are passed through the cipher and the block boundary
is reset.)</t>
<t>The repetition of two octets in the random prefix allows the receiver to imme
diately check whether the session key is incorrect.
See <xref target="quick-check-oracle"/> for hints on the proper use of this "qui ck check".</t> See <xref target="quick-check-oracle"/> for hints on the proper use of this "qui ck check".</t>
</section>
</section> <section anchor="marker-packet">
<section anchor="marker-packet"><name>Marker Packet (Type ID 10)</name> <name>Marker Packet (Type ID 10)</name>
<t>The body of the Marker packet consists of:</t>
<t>The body of this packet consists of:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).</
<t>The three octets 0x50, 0x47, 0x50 (which spell "PGP" in UTF-8).</t> t>
</list></t> </li>
</ul>
<t>Such a packet <bcp14>MUST</bcp14> be ignored when received.</t> <t>Such a packet <bcp14>MUST</bcp14> be ignored when received.</t>
</section>
</section> <section anchor="lit">
<section anchor="lit"><name>Literal Data Packet (Type ID 11)</name> <name>Literal Data Packet (Type ID 11)</name>
<t>A Literal Data packet contains the body of a message; that is, data t
<t>A Literal Data packet contains the body of a message; data that is not to be hat is not to be further interpreted.</t>
further interpreted.</t> <t>The body of this packet consists of:</t>
<ul spacing="normal">
<t>The body of this packet consists of:</t> <li>
<t>A one-octet field that describes how the data is formatted. </t>
<t><list style="symbols"> <t>
<t>A one-octet field that describes how the data is formatted. <vspace blankL If it is a <tt>b</tt> (0x62), then the Literal packet contains binary data.
ines='1'/> If it is a <tt>u</tt> (0x75), then the Literal packet contains UTF-8-encoded tex
If it is a <spanx style="verb">b</spanx> (0x62), then the Literal packet contain t data and thus may need line ends converted to local form or other text mode ch
s binary data. anges. </t>
If it is a <spanx style="verb">u</spanx> (0x75), then the Literal packet contain <t>
s UTF-8-encoded text data, and thus may need line ends converted to local form, Previous versions of the OpenPGP specification used <tt>t</tt> (0x74) to indicat
or other text mode changes. <vspace blankLines='1'/> e textual data but did not specify the character encoding. Implementations <bcp1
Older versions of OpenPGP used <spanx style="verb">t</spanx> (0x74) to indicate 4>SHOULD NOT</bcp14> emit this value.
textual data, but did not specify the character encoding. An implementation that receives a literal data packet with this value in the for
Implementations <bcp14>SHOULD NOT</bcp14> emit this value. mat field <bcp14>SHOULD</bcp14> interpret the packet data as UTF-8 encoded text,
An implementation that receives a literal data packet with this value in the for unless reliable (not attacker-controlled) context indicates a specific alternat
mat field <bcp14>SHOULD</bcp14> interpret the packet data as UTF-8 encoded text, e text encoding. This mode is deprecated due to its ambiguity. </t>
unless reliable (not attacker-controlled) context indicates a specific alternat <t>
e text encoding. Some implementations predating <xref target="RFC2440"/> also defined a value of
This mode is deprecated due to its ambiguity. <vspace blankLines='1'/> <tt>l</tt> as a "local" mode for machine-local conversions. <xref target="RFC199
Some implementations predating <xref target="RFC2440"/> also defined a value of 1"/> incorrectly states that this local mode flag is <tt>1</tt> (ASCII numeral o
<spanx style="verb">l</spanx> as a 'local' mode for machine-local conversions. ne). Both of these local modes are deprecated.</t>
<xref target="RFC1991"/> incorrectly stated this local mode flag as <spanx style </li>
="verb">1</spanx> (ASCII numeral one). <li>
Both of these local modes are deprecated.</t> <t>The file name as a string (one-octet length, followed by a file n
<t>File name as a string (one-octet length, followed by a file name). ame).
This may be a zero-length string. This may be a zero-length string. Commonly, if the source of the encr
Commonly, if the source of the encrypted data is a file, this will be the name o ypted data is a file, it will be the name of the encrypted file. An implementati
f the encrypted file. on <bcp14>MAY</bcp14> consider the file name in the Literal packet to be a more
An implementation <bcp14>MAY</bcp14> consider the file name in the Literal packe authoritative name than the actual file name.</t>
t to be a more authoritative name than the actual file name.</t> </li>
<t>A four-octet number that indicates a date associated with the literal data. <li>
<t>A four-octet number that indicates a date associated with the lit
eral data.
Commonly, the date might be the modification date of a file, or the time the pac ket was created, or a zero that indicates no specific time.</t> Commonly, the date might be the modification date of a file, or the time the pac ket was created, or a zero that indicates no specific time.</t>
<t>The remainder of the packet is literal data. <vspace blankLines='1'/> </li>
<li>
<t>The remainder of the packet is literal data. </t>
<t>
Text data <bcp14>MUST</bcp14> be encoded with UTF-8 (see <xref target="RFC3629"/ >) and stored with &lt;CR&gt;&lt;LF&gt; text endings (that is, network-normal li ne endings). Text data <bcp14>MUST</bcp14> be encoded with UTF-8 (see <xref target="RFC3629"/ >) and stored with &lt;CR&gt;&lt;LF&gt; text endings (that is, network-normal li ne endings).
These should be converted to native line endings by the receiving implementation .</t> 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 na <t>Note that OpenPGP signatures do not include the formatting octet, the
me, and the date field of the literal packet in a signature hash and thus those file name, and the date field of the literal packet in a signature hash; theref
fields are not protected against tampering in a signed document. ore, those fields are not protected against tampering in a signed document. A re
A receiving implementation <bcp14>MUST NOT</bcp14> treat those fields as though ceiving implementation <bcp14>MUST NOT</bcp14> treat those fields as though they
they were cryptographically secured by the surrounding signature either when rep were cryptographically secured by the surrounding signature when either represe
resenting them to the user or acting on them.</t> nting them to the user or acting on them.</t>
<t>Due to their inherent malleability, an implementation that generates
<t>Due to their inherent malleability, an implementation that generates a litera a literal data packet <bcp14>SHOULD</bcp14> avoid storing any significant data i
l data packet <bcp14>SHOULD</bcp14> avoid storing any significant data in these n these fields.
fields. If the implementation is certain that the data is textual and is encoded with UT
If the implementation is certain that the data is textual and is encoded with UT F-8 (for example, if it will follow this literal data packet with a signature pa
F-8 (for example, if it will follow this literal data packet with a signature pa cket of type 0x01 (see <xref target="signature-types"/>), it <bcp14>MAY</bcp14>
cket of type 0x01 (see <xref target="signature-types"/>), it <bcp14>MAY</bcp14> set the format octet to <tt>u</tt>.
set the format octet to <spanx style="verb">u</spanx>. Otherwise, it <bcp14>MUST</bcp14> set the format octet to <tt>b</tt>.
Otherwise, it <bcp14>MUST</bcp14> set the format octet to <spanx style="verb">b< It <bcp14>SHOULD</bcp14> set the filename to the empty string (encoded as a sing
/spanx>. le zero octet) and the timestamp to zero (encoded as four zero octets).</t>
It <bcp14>SHOULD</bcp14> set the filename to the empty string (encoded as a sing <t>An application that wishes to include such filesystem metadata within
le zero octet), and the timestamp to zero (encoded as four zero octets).</t> a signature is advised to sign an encapsulated archive (for example, <xref targ
et="PAX"/>).</t>
<t>An application that wishes to include such filesystem metadata within a signa <t>An implementation that generates a Literal Data packet <bcp14>MUST</b
ture is advised to sign an encapsulated archive (for example, <xref target="PAX" cp14> use the OpenPGP format for packet framing (see <xref target="openpgp-packe
/>).</t> t-format"/>).
It <bcp14>MUST NOT</bcp14> generate a Literal Data packet with Legacy format (<x
<t>An implementation that generates a Literal Data packet <bcp14>MUST</bcp14> us ref target="legacy-packet-format"/>).</t>
e the OpenPGP format for packet framing (see <xref target="openpgp-packet-format <t>An implementation that deals with either historic data or data genera
"/>). ted by an implementation that predates support for <xref target="RFC2440"/> <bcp
It <bcp14>MUST NOT</bcp14> generate a Literal Data packet with Legacy format (<x 14>MAY</bcp14> interpret Literal Data packets that use the Legacy format for pac
ref target="legacy-packet-format"/>)</t> ket framing.</t>
<section anchor="for-eyes-only">
<t>An implementation that deals with either historic data or data generated by a <name>Special Filename _CONSOLE (Deprecated)</name>
n implementation that predates support for <xref target="RFC2440"/> <bcp14>MAY</ <t>The Literal Data packet's filename field has a historical special c
bcp14> interpret Literal Data packets that use the Legacy format for packet fram ase for the special name <tt>_CONSOLE</tt>.
ing.</t> When the filename field is <tt>_CONSOLE</tt>, the message is considered to be "f
or your eyes only".
<section anchor="for-eyes-only"><name>Special Filename _CONSOLE (Deprecated)</na
me>
<t>The Literal Data packet's filename field has a historical special case for th
e special name <spanx style="verb">_CONSOLE</spanx>.
When the filename field is <spanx style="verb">_CONSOLE</spanx>, the message is
considered to be "for your eyes only".
This advises that the message data is unusually sensitive, and the receiving pro gram should process it more carefully, perhaps avoiding storing the received dat a to disk, for example.</t> This advises that the message data is unusually sensitive, and the receiving pro gram should process it more carefully, perhaps avoiding storing the received dat a to disk, for example.</t>
<t>An OpenPGP deployment that generates literal data packets <bcp14>MU
<t>An OpenPGP deployment that generates literal data packets <bcp14>MUST NOT</bc ST NOT</bcp14> depend on this indicator being honored in any particular way.
p14> 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> 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 i
<t>It is <bcp14>NOT RECOMMENDED</bcp14> to use this special filename in a newly- n a newly generated literal data packet.</t>
generated literal data packet.</t> </section>
</section>
</section> <section anchor="trust">
</section> <name>Trust Packet (Type ID 12)</name>
<section anchor="trust"><name>Trust Packet (Type ID 12)</name> <t>The Trust packet is used only within keyrings and is not normally exp
orted.
<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 keyhol ders are trustworthy introducers, along with other information that implementati on uses for trust information. Trust packets contain data that record the user's specifications of which keyhol ders are trustworthy introducers, along with other information that implementati on uses for trust information.
The format of Trust packets is defined by a given implementation.</t> The format of Trust packets is defined by a given implementation.</t>
<t>Trust packets <bcp14>SHOULD NOT</bcp14> be emitted to output streams
<t>Trust packets <bcp14>SHOULD NOT</bcp14> be emitted to output streams that are that are transferred to other users, and they <bcp14>SHOULD</bcp14> be ignored o
transferred to other users, and they <bcp14>SHOULD</bcp14> be ignored on any in n any input other than local keyring files.</t>
put other than local keyring files.</t> </section>
<section anchor="uid">
</section> <name>User ID Packet (Type ID 13)</name>
<section 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.
<t>A User ID packet consists of UTF-8 text that is intended to represent the nam By convention, it includes a mail name-addr as described in <xref target="RFC282
e and email address of the keyholder. 2"/>, but there are no restrictions on its content. The packet length in the hea
By convention, it includes an <xref target="RFC2822"/> mail name-addr, but there der specifies the length of the User ID.</t>
are no restrictions on its content. </section>
The packet length in the header specifies the length of the User ID.</t> <section anchor="user-attribute-packet">
<name>User Attribute Packet (Type ID 17)</name>
</section> <t>The User Attribute packet is a variation of the User ID packet.
<section 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 li mited to text. It is capable of storing more types of data than the User ID packet, which is li mited to text.
Like the User ID packet, a User Attribute packet may be certified by the key own er ("self-signed") or any other key owner who cares to certify it. Like the User ID packet, a User Attribute packet may be certified by the key own er ("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 pac ket may be used.</t> Except as noted, a User Attribute packet may be used anywhere that a User ID pac ket may be used.</t>
<t>While User Attribute packets are not a required part of the OpenPGP s
<t>While User Attribute packets are not a required part of the OpenPGP standard, pecification, implementations <bcp14>SHOULD</bcp14> provide at least enough comp
implementations <bcp14>SHOULD</bcp14> provide at least enough compatibility to atibility to properly handle a certification signature on the User Attribute pac
properly handle a certification signature on the User Attribute packet. ket.
A simple way to do this is by treating the User Attribute packet as a User ID pa cket with opaque contents, but an implementation may use any method desired.</t> A simple way to do this is by treating the User Attribute packet as a User ID pa cket 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 subpack
<t>The User Attribute packet is made up of one or more attribute subpackets. ets.
Each subpacket consists of a subpacket header and a body. Each subpacket consists of a subpacket header and a body.
The header consists of:</t> The header consists of:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The subpacket length (1, 2, or 5 octets)</t> <t>the subpacket length (1, 2, or 5 octets)</t>
<t>The subpacket type ID (1 octet)</t> </li>
</list></t> <li>
<t>the subpacket type ID (1 octet)</t>
<t>and is followed by the subpacket specific data.</t> </li>
</ul>
<t>The following table lists the currently known subpackets:</t> <t>and is followed by the subpacket specific data.</t>
<t>The following table lists the currently known subpackets:</t>
<texttable title="OpenPGP User Attribute Subpacket Types registry" anchor="user- <table anchor="user-attr-subpacket-types-registry">
attr-subpacket-types-registry"> <name>OpenPGP User Attribute Subpacket Types Registry</name>
<ttcol align='right'>ID</ttcol> <thead>
<ttcol align='left'>Attribute Subpacket</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <th align="right">ID</th>
<c>1</c> <th align="left">Attribute Subpacket</th>
<c>Image Attribute Subpacket</c> <th align="left">Reference</th>
<c><xref target="uat-image"/></c> </tr>
<c>100-110</c> </thead>
<c>Private/Experimental Use</c> <tbody>
<c>&#160;</c> <tr>
</texttable> <td align="right">0</td>
<td align="left">Reserved</td>
<t>An implementation <bcp14>SHOULD</bcp14> ignore any subpacket of a type that i <td align="left"></td>
t does not recognize.</t> </tr>
<tr>
<section anchor="uat-image"><name>The Image Attribute Subpacket</name> <td align="right">1</td>
<td align="left">Image Attribute Subpacket</td>
<t>The Image Attribute subpacket is used to encode an image, presumably (but not <td align="left"><xref target="uat-image"/></td>
required to be) that of the key owner.</t> </tr>
<tr>
<t>The Image Attribute subpacket begins with an image header. <td align="right">100-110</td>
<td align="left">Private or Experimental Use</td>
<td align="left"></td>
</tr>
</tbody>
</table>
<t>An implementation <bcp14>SHOULD</bcp14> ignore any subpacket of a typ
e that it does not recognize.</t>
<section anchor="uat-image">
<name>Image Attribute Subpacket</name>
<t>The Image Attribute subpacket is used to encode an image, presumabl
y (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. 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 h Note that unlike other multi-octet numerical values in this document, due to a h
istorical accident this value is encoded as a little-endian number. istorical accident, this value is encoded as a little-endian number. The image h
The image header length is followed by a single octet for the image header versi eader length is followed by a single octet for the image header version.
on.
The only currently defined version of the image header is 1, which is a 16-octet image header. 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 > The first three octets of a version 1 image header are thus 0x10, 0x00, 0x01.</t >
<table anchor="image-attribute-version-registry">
<texttable title="OpenPGP Image Attribute Version registry" anchor="image-attrib <name>OpenPGP Image Attribute Versions Registry</name>
ute-version-registry"> <thead>
<ttcol align='right'>Version</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <th align="right">Version</th>
<c>1</c> <th align="left">Reference</th>
<c><xref target="uat-image"/></c> </tr>
</texttable> </thead>
<tbody>
<t>The fourth octet of a version 1 image header designates the encoding format o <tr>
f the image. <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 encodin
g format of the image.
The only currently defined encoding format is the value 1 to indicate JPEG. The only currently defined encoding format is the value 1 to indicate JPEG.
Image format IDs 100 through 110 are reserved for private or experimental use. Image format IDs 100 through 110 are reserved for Private or 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> 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>
<table anchor="image-attr-encoding-format-registry">
<name>OpenPGP Image Attribute Encoding Format Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Encoding</th>
<texttable title="OpenPGP Image Attribute Encoding Format registry" anchor="imag </tr>
e-attr-encoding-format-registry"> </thead>
<ttcol align='right'>ID</ttcol> <tbody>
<ttcol align='left'>Encoding</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <td align="right">0</td>
<c>1</c> <td align="left">Reserved</td>
<c>JPEG</c>
<c>JPEG File Interchange Format (<xref target="JFIF"/>)</c>
<c>100-110</c>
<c>Private/Experimental use</c>
<c>&#160;</c>
</texttable>
<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 JP
EG 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 </tr>
examination of the image data if it is unable to handle a particular version of <tr>
the image header or if a specified encoding format value is not recognized.</t> <td align="right">1</td>
<td align="left">JPEG <xref target="JFIF"/></td>
</section> </tr>
</section> <tr>
<section anchor="seipd"><name>Symmetrically Encrypted Integrity Protected Data P <td align="right">100-110</td>
acket (Type ID 18)</name> <td align="left">Private or Experimental Use</td>
<t>This packet (the "SEIPD" packet) contains integrity protected and encrypted d </tr>
ata. </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 JP
EG 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 a
n 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 recog
nized.</t>
</section>
</section>
<section anchor="seipd">
<name>Symmetrically Encrypted Integrity Protected Data Packet (Type ID 1
8)</name>
<t>The SEIPD packet contains integrity-protected and encrypted data.
When it has been decrypted, it will contain other packets forming an OpenPGP Mes sage (see <xref target="openpgp-messages"/>).</t> When it has been decrypted, it will contain other packets forming an OpenPGP Mes sage (see <xref target="openpgp-messages"/>).</t>
<t>The first octet of this packet is always used to indicate the version
<t>The first octet of this packet is always used to indicate the version number, number, but different versions contain ciphertext that is structured differentl
but different versions contain differently-structured ciphertext. y. Version 1 of this packet contains data encrypted with a symmetric-key algorit
Version 1 of this packet contains data encrypted with a symmetric-key algorithm hm and is thus protected against modification by the SHA-1 hash algorithm. This
and protected against modification by the SHA-1 hash algorithm. mechanism was introduced in <xref target="RFC4880"/> and offers some protections
This mechanism was introduced in <xref target="RFC4880"/> and offers some protec against ciphertext malleability.</t>
tions against ciphertext malleability.</t> <t>Version 2 of this packet contains data encrypted with an AEAD constru
ction.
<t>Version 2 of this packet contains data encrypted with an authenticated encryp
tion and additional data (AEAD) construction.
This offers a more cryptographically rigorous defense against ciphertext malleab ility. This offers a more cryptographically rigorous defense against ciphertext malleab ility.
See <xref target="ciphertext-malleability"/> for more details on choosing betwee n these formats.</t> See <xref target="ciphertext-malleability"/> for more details on choosing betwee n these formats.</t>
<t>Any new version of the SEIPD packet should be registered in the regis
<t>Any new version of the SEIPD packet should be registered in the registry esta try established in <xref target="encrypted-message-versions"/>.</t>
blished in <xref target="encrypted-message-versions"/>.</t> <section anchor="version-one-seipd">
<name>Version 1 Symmetrically Encrypted Integrity Protected Data Packe
<section anchor="version-one-seipd"><name>Version 1 Symmetrically Encrypted Inte t Format</name>
grity Protected Data Packet Format</name> <t>A version 1 Symmetrically Encrypted Integrity Protected Data packet
consists of:</t>
<t>A version 1 Symmetrically Encrypted Integrity Protected Data packet consists <ul spacing="normal">
of:</t> <li>
<t>A one-octet version number with value 1.</t>
<t><list style="symbols"> </li>
<t>A one-octet version number with value 1.</t> <li>
<t>Encrypted data, the output of the selected symmetric-key cipher operating i <t>Encrypted data -- the output of the selected symmetric-key ciph
n Cipher Feedback (CFB) mode.</t> er operating in CFB mode.</t>
</list></t> </li>
</ul>
<t>The symmetric cipher used <bcp14>MUST</bcp14> be specified in a Public-Key or <t>The symmetric cipher used <bcp14>MUST</bcp14> be specified in a Pub
Symmetric-Key Encrypted Session Key packet that precedes the Symmetrically Encr lic-Key or Symmetric-Key Encrypted Session Key packet that precedes the Symmetri
ypted Integrity Protected Data packet. cally Encrypted Integrity Protected Data packet. In either case, the cipher algo
In either case, the cipher algorithm ID is prefixed to the session key before it rithm ID is prefixed to the session key before it is encrypted.</t>
is encrypted.</t> <t>The data is encrypted in CFB mode (see <xref target="cfb-mode"/>).
The IV is specified as all zeros. Instead of achieving randomized encryption thr
<t>The data is encrypted in CFB mode (see <xref target="cfb-mode"/>). ough an IV, OpenPGP prefixes an octet string to the data before it is encrypted
The Initial Vector (IV) is specified as all zeros. for this purpose.
Instead of achieving randomized encryption through an IV, OpenPGP prefixes an oc
tet 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, pl us two. The length of the octet string equals the block size of the cipher in octets, pl us 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. 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 t he 15th and 16th octets, respectively. 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 t he 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 resy nchronization is done.</t> Unlike the deprecated Symmetrically Encrypted Data packet (<xref target="sed"/>) , this prefix data is encrypted in the same CFB context, and no special CFB resy nchronization is done.</t>
<t>The repetition of 16 bits in the random data prefixed to the messag
<t>The repetition of 16 bits in the random data prefixed to the message allows t e allows the receiver to immediately check whether the session key is incorrect.
he receiver to immediately check whether the session key is incorrect.
See <xref target="quick-check-oracle"/> for hints on the proper use of this "qui ck check".</t> See <xref target="quick-check-oracle"/> for hints on the proper use of this "qui ck check".</t>
<t>Two constant octets with the values 0xD3 and 0x14 are appended to t
<t>Two constant octets with the values 0xD3 and 0x14 are appended to the plainte he plaintext. Then, the plaintext of the data to be encrypted is passed through
xt. the SHA-1 hash function. The input to the hash function is comprised of the pref
Then, the plaintext of the data to be encrypted is passed through the SHA-1 hash ix data described above and all of the plaintext, including the trailing constan
function. t octets 0xD3, 0x14.
The input to the hash function includes the prefix data described above; it incl
udes 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 co nstant octets 0xD3, 0x14) and encrypted along with the plaintext using the same CFB context. The 20 octets of the SHA-1 hash are then appended to the plaintext (after the co nstant 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> 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, bu
t excluding the last 20 octets containing the SHA-1 hash. The computed SHA-1 has
h is then compared with the last 20 octets of plaintext.
A mismatch of the hash indicates that the message has been modified and <bcp14>M
UST</bcp14> be treated as a security problem. Any failure <bcp14>SHOULD</bcp14>
be reported to the user.</t>
<t>During decryption, the plaintext data should be hashed with SHA-1, including <t indent="3">NON-NORMATIVE EXPLANATION</t>
the prefix data as well as the trailing constant octets 0xD3, 0x14, but excludin <t indent="3">The MDC system, as the integrity
g 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>M
UST</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 EXPLANATION</t>
<t>The Modification Detection Code (MDC) system, as the integrity
protection mechanism of version 1 of the Symmetrically Encrypted protection mechanism of version 1 of the Symmetrically Encrypted
Integrity Protected Data packet is called, was created to Integrity Protected Data packet is called, was created to
provide an integrity mechanism that is less strong than a provide an integrity mechanism that is less strong than a
signature, yet stronger than bare CFB encryption.</t> signature, yet stronger than bare CFB encryption.</t>
<t indent="3">CFB encryption has a limitation as damage to the cip
<t>It is a limitation of CFB encryption that damage to the ciphertext hertext
will corrupt the affected cipher blocks and the block following. will corrupt the affected cipher blocks and the block following.
Additionally, if data is removed from the end of a CFB-encrypted Additionally, if data is removed from the end of a CFB-encrypted
block, that removal is undetectable. (Note also that CBC mode has block, that removal is undetectable. (Note also that CBC mode has
a similar limitation, but data removed from the front of the block a similar limitation, but data removed from the front of the block
is undetectable.)</t> is undetectable.)</t>
<t indent="3">The obvious way to protect or authenticate an encryp
<t>The obvious way to protect or authenticate an encrypted block is ted block is
to digitally sign it. However, many people do not wish to to digitally sign it. However, many people do not wish to
habitually sign data, for a large number of reasons beyond the habitually sign data for a large number of reasons that are beyond the
scope of this document. Suffice it to say that many people scope of this document. Suffice it to say that many people
consider properties such as deniability to be as valuable as consider properties such as deniability to be as valuable as
integrity.</t> integrity.</t>
<t indent="3">OpenPGP addresses this desire to have more security
<t>OpenPGP addresses this desire to have more security than raw than raw
encryption and yet preserve deniability with the MDC system. An encryption and yet preserve deniability with the MDC system. An
MDC is intentionally not a MAC. Its name was not selected by MDC is intentionally not a Message Authentication Code (MAC). Its name was no t selected by
accident. It is analogous to a checksum.</t> accident. It is analogous to a checksum.</t>
<t indent="3">Despite the fact that it is a relatively modest syst
<t>Despite the fact that it is a relatively modest system, it has em, it has
proved itself in the real world. It is an effective defense to proved itself in the real world. It is an effective defense to
several attacks that have surfaced since it has been created. It several attacks that have surfaced since it has been created. It
has met its modest goals admirably.</t> has met its modest goals admirably.</t>
<t indent="3">Consequently, because it is a modest security system
<t>Consequently, because it is a modest security system, it has , it has
modest requirements on the hash function(s) it employs. It does modest requirements on the hash function(s) it employs. It does
not rely on a hash function being collision-free, it relies on a not rely on a hash function being collision-free; it relies on a
hash function being one-way. If a forger, Frank, wishes to send hash function being one-way. If a forger, Frank, wishes to send
Alice a (digitally) unsigned message that says, "I've always Alice a (digitally) unsigned message that says, "I've always
secretly loved you, signed Bob", it is far easier for him to secretly loved you, signed Bob", it is far easier for him to
construct a new message than it is to modify anything intercepted construct a new message than it is to modify anything intercepted
from Bob. (Note also that if Bob wishes to communicate secretly from Bob. (Note also that if Bob wishes to communicate secretly
with Alice, but without authentication or identification and with with Alice, but without authentication or identification and with
a threat model that includes forgers, he has a problem that a threat model that includes forgers, he has a problem that
transcends mere cryptography.)</t> transcends mere cryptography.)</t>
<t indent="3">Note also that unlike nearly every other OpenPGP sub
<t>Note also that unlike nearly every other OpenPGP subsystem, there system, there
are no parameters in the MDC system. It hard-defines SHA-1 as its are no parameters in the MDC system. It hard-defines SHA-1 as its
hash function. This is not an accident. It is an intentional hash function. This is not an accident. It is an intentional
choice to avoid downgrade and cross-grade attacks while making a choice to avoid downgrade and cross-grade attacks while making a
simple, fast system. (A downgrade attack would be an attack that simple, fast system. (A downgrade attack is an attack that would
replaced SHA2-256 with SHA-1, for example. A cross-grade attack replace SHA2-256 with SHA-1, for example. A cross-grade attack
would replace SHA-1 with another 160-bit hash, such as would replace SHA-1 with another 160-bit hash, such as
RIPEMD-160, for example.)</t> RIPEMD-160, for example.)</t>
<t indent="3">However, no update will be needed because the MDC ha
<t>However, no update will be needed because the MDC has been replaced s been replaced
by the AEAD encryption described in this document.</t> by the AEAD encryption described in this document.</t>
</li></ul>
</section>
<section anchor="version-two-seipd"><name>Version 2 Symmetrically Encrypted Inte
grity Protected Data Packet Format</name>
<t>A version 2 Symmetrically Encrypted Integrity Protected Data packet consists
of:</t>
<t><list style="symbols">
<t>A one-octet version number with value 2.</t>
<t>A one-octet cipher algorithm ID.</t>
<t>A one-octet AEAD algorithm identifier.</t>
<t>A one-octet chunk size.</t>
<t>Thirty-two octets of salt.
The salt is used to derive the message key and <bcp14>MUST</bcp14> be securely g
enerated (See <xref target="CSPRNG"/>).</t>
<t>Encrypted data, the output of the selected symmetric-key cipher operating i
n the given AEAD mode.</t>
<t>A final, summary authentication tag for the AEAD mode.</t>
</list></t>
<t>The decrypted session key and the salt are used to derive an M-bit message ke
y and N-64 bits used as initialization vector, where M is the key size of the sy
mmetric 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 M bits are used as symmetric algorithm key, the remaining N - 64 b
its are used as initialization vector.
HKDF is used with SHA256 (<xref target="RFC6234"/>) as hash algorithm, the sessi
on key as Initial Keying Material (IKM), the salt as salt, and the Packet Type I
D in OpenPGP format encoding (bits 7 and 6 set, bits 5-0 carry the packet type I
D), 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. </section>
Furthermore, an implementation can securely reply to a message even if a recipie <section anchor="version-two-seipd">
nt's certificate is unknown by reusing the encrypted session key packets and rep <name>Version 2 Symmetrically Encrypted Integrity Protected Data Packe
lying with a different salt yielding a new, unique message key. t Format</name>
<t>A version 2 Symmetrically Encrypted Integrity Protected Data packet
consists of:</t>
<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>
</li>
<li>
<t>32 octets of salt.
The salt is used to derive the message key and <bcp14>MUST</bcp14> be securely g
enerated (see <xref target="CSPRNG"/>).</t>
</li>
<li>
<t>Encrypted data; that is, the output of the selected symmetric-k
ey cipher operating in the given AEAD mode.</t>
</li>
<li>
<t>A final summary authentication tag for the AEAD mode.</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 IV, where M is the key size of the symmetr
ic algorithm and N is the nonce size of the AEAD algorithm. M + N - 64 bits are
derived using HKDF (see <xref target="RFC5869"/>). The leftmost M bits are used
as a symmetric algorithm key, and the remaining N - 64 bits are used as an IV. H
KDF is used with SHA256 <xref target="RFC6234"/> as hash algorithm. The session
key is used as IKM and the salt as salt. The Packet Type ID in OpenPGP format en
coding (bits 7 and 6 are set, and bits 5-0 carry the packet type ID), version nu
mber, cipher algorithm ID, AEAD algorithm ID, and chunk size octet are used as i
nfo parameter.</t>
<t>The KDF mechanism provides key separation between cipher and AEAD a
lgorithms.
Furthermore, an implementation can securely reply to a message even if a recipie
nt's certificate is unknown by reusing the encrypted session key packets and rep
lying with a different salt that yields a new, unique message key.
See <xref target="secure-sessionkey-reuse"/> for guidance on how applications ca n securely implement this feature.</t> See <xref target="secure-sessionkey-reuse"/> for guidance on how applications ca n securely implement this feature.</t>
<t>A v2 SEIPD packet consists of one or more chunks of data. The plain
<t>A v2 SEIPD packet consists of one or more chunks of data. text of each chunk is of a size specified by the chunk size octet using the meth
The plaintext of each chunk is of a size specified using the chunk size octet us od specified below.</t>
ing the method specified below.</t> <t>The encrypted data consists of the encryption of each chunk of plai
ntext, followed immediately by the relevant authentication tag. If the last chun
<t>The encrypted data consists of the encryption of each chunk of plaintext, fol k of plaintext is smaller than the chunk size, the ciphertext for that data may
lowed immediately by the relevant authentication tag. be shorter; nevertheless, it is followed by a full authentication tag.</t>
If the last chunk of plaintext is smaller than the chunk size, the ciphertext fo <t>For each chunk, the AEAD construction is given the Packet Type ID e
r that data may be shorter; it is nevertheless followed by a full authentication ncoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 carry the packet ty
tag.</t> pe ID), version number, cipher algorithm ID, AEAD algorithm ID, and chunk size o
ctet as additional data.
<t>For each chunk, the AEAD construction is given the Packet Type ID encoded in For example, the additional data of the first chunk using EAX and AES-128 with a
OpenPGP format (bits 7 and 6 set, bits 5-0 carry the packet type ID), version nu chunk size of 2<sup>22</sup> octets consists of the octets 0xD2, 0x02, 0x07, 0x
mber, cipher algorithm ID, AEAD algorithm ID, and chunk size octet as additional 01, and 0x10.</t>
data. <t>After the final chunk, the AEAD algorithm is used to produce a fina
For example, the additional data of the first chunk using EAX and AES-128 with a l authentication tag encrypting the empty string.
chunk size of 2**22 octets consists of the octets 0xD2, 0x02, 0x07, 0x01, and 0 This AEAD instance is given the additional data specified above, plus an eight-o
x10.</t> ctet, big-endian value specifying the total number of plaintext octets encrypted
. This allows detection of a truncated ciphertext.</t>
<t>After the final chunk, the AEAD algorithm is used to produce a final authenti <t>The chunk size octet specifies the size of chunks using the followi
cation tag encrypting the empty string. ng formula (in C <xref target="C99"/>), where c is the chunk size octet:</t>
This AEAD instance is given the additional data specified above, plus an eight-o <artwork><![CDATA[
ctet, 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 <xref target="C99"/>), where c is the chunk size octet:</t>
<figure><artwork><![CDATA[
chunk_size = (uint32_t) 1 << (c + 6) chunk_size = (uint32_t) 1 << (c + 6)
]]></artwork></figure> ]]></artwork>
<t>An implementation <bcp14>MUST</bcp14> accept chunk size octets with
<t>An implementation <bcp14>MUST</bcp14> accept chunk size octets with values fr values from 0 to 16.
om 0 to 16.
An implementation <bcp14>MUST NOT</bcp14> create data with a chunk size octet va lue larger than 16 (4 MiB chunks).</t> An implementation <bcp14>MUST NOT</bcp14> create data with a chunk size octet va lue larger than 16 (4 MiB chunks).</t>
<t>The nonce for AEAD mode consists of two parts.
<t>The nonce for AEAD mode consists of two parts. Let N be the size of the nonce. The leftmost N - 64 bits are the IV derived usin
Let N be the size of the nonce. g HKDF.
The left-most N - 64 bits are the initialization vector derived using HKDF. The rightmost 64 bits are the chunk index as a big-endian value.
The right-most 64 bits are the chunk index as big-endian value.
The index of the first chunk is zero.</t> The index of the first chunk is zero.</t>
</section>
</section> <section anchor="aead-mode-eax">
<section anchor="aead-mode-eax"><name>EAX Mode</name> <name>EAX Mode</name>
<t>The EAX AEAD algorithm used in this document is defined in <xref ta
<t>The EAX AEAD Algorithm used in this document is defined in <xref target="EAX" rget="EAX"/>.</t>
/>.</t> <t>The EAX algorithm can only use block ciphers with 16-octet blocks.
<t>The EAX algorithm can only use block ciphers with 16-octet blocks.
The nonce is 16 octets long. The nonce is 16 octets long.
EAX authentication tags are 16 octets long.</t> EAX authentication tags are 16 octets long.</t>
</section>
</section> <section anchor="aead-mode-ocb">
<section anchor="aead-mode-ocb"><name>OCB Mode</name> <name>OCB Mode</name>
<t>The OCB AEAD algorithm used in this document is defined in <xref ta
<t>The OCB AEAD Algorithm used in this document is defined in <xref target="RFC7 rget="RFC7253"/>.</t>
253"/>.</t> <t>The OCB algorithm can only use block ciphers with 16-octet blocks.
<t>The OCB algorithm can only use block ciphers with 16-octet blocks.
The nonce is 15 octets long. The nonce is 15 octets long.
OCB authentication tags are 16 octets long.</t> OCB authentication tags are 16 octets long.</t>
</section>
</section> <section anchor="aead-mode-gcm">
<section anchor="aead-mode-gcm"><name>GCM Mode</name> <name>GCM Mode</name>
<t>The GCM AEAD algorithm used in this document is defined in <xref ta
<t>The GCM AEAD Algorithm used in this document is defined in <xref target="SP80 rget="SP800-38D"/>.</t>
0-38D"/>.</t> <t>The GCM algorithm can only use block ciphers with 16-octet blocks.
<t>The GCM algorithm can only use block ciphers with 16-octet blocks.
The nonce is 12 octets long. The nonce is 12 octets long.
GCM authentication tags are 16 octets long.</t> GCM authentication tags are 16 octets long.</t>
</section>
</section> </section>
</section> <section anchor="padding-packet">
<section anchor="padding-packet"><name>Padding Packet (Type ID 21)</name> <name>Padding Packet (Type ID 21)</name>
<t>The Padding packet contains random data and can be used to defend aga
<t>The Padding packet contains random data, and can be used to defend against tr inst traffic analysis (see <xref target="traffic-analysis"/>) on version 2 SEIPD
affic analysis (see <xref target="traffic-analysis"/>) on version 2 SEIPD messag messages (see <xref target="version-two-seipd"/>) and Transferable Public Keys
es (see <xref target="version-two-seipd"/>) and Transferable Public Keys (see <x (see <xref target="transferable-public-keys"/>).</t>
ref 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 lengt
<t>Such a packet <bcp14>MUST</bcp14> be ignored when received.</t> h obfuscation it provides more robust even when compressed.</t>
<t>An implementation adding padding to an OpenPGP stream <bcp14>SHOULD</
<t>Its contents <bcp14>SHOULD</bcp14> be random octets to make the length obfusc bcp14> place such a packet:</t>
ation it provides more robust even when compressed.</t> <ul spacing="normal">
<li>
<t>An implementation adding padding to an OpenPGP stream <bcp14>SHOULD</bcp14> p <t>At the end of a v6 Transferable Public Key that is transferred ov
lace such a packet:</t> er an encrypted channel (see <xref target="transferable-public-keys"/>).</t>
</li>
<t><list style="symbols"> <li>
<t>At the end of a v6 Transferable Public Key that is transferred over an encr <t>As the last packet of an Optionally Padded Message within a versi
ypted channel (see <xref target="transferable-public-keys"/>).</t> on 2 Symmetrically Encrypted Integrity Protected Data packet (see <xref target="
<t>As the last packet of an Optionally Padded Message within a version 2 Symme unwrapping"/>).</t>
trically Encrypted Integrity Protected Data packet (see <xref target="unwrapping </li>
"/>).</t> </ul>
</list></t> <t>An implementation <bcp14>MUST</bcp14> be able to process padding pack
ets anywhere else in an OpenPGP stream so that future revisions of this document
<t>An implementation <bcp14>MUST</bcp14> be able to process padding packets anyw may specify further locations for padding.</t>
here else in an OpenPGP stream, so that future revisions of this document may sp <t>Policy about how large to make such a packet to defend against traffi
ecify further locations for padding.</t> c analysis is beyond the scope of this document.</t>
</section>
<t>Policy about how large to make such a packet to defend against traffic analys </section>
is is beyond the scope of this document.</t> <section anchor="base64">
<name>Base64 Conversions</name>
</section> <t>As stated in the introduction, OpenPGP's underlying native representati
</section> on for objects is a stream of arbitrary octets, and some systems desire these ob
<section anchor="base64"><name>Base64 Conversions</name> jects to be immune to damage caused by character set translation, data conversio
ns, etc.</t>
<t>As stated in the introduction, OpenPGP's underlying native representation for <t>In principle, any printable encoding scheme that met the requirements o
objects is a stream of arbitrary octets, and some systems desire these objects f the unsafe channel would suffice, since it would not change the underlying bin
to be immune to damage caused by character set translation, data conversions, et ary bit streams of the native OpenPGP data structures.
c.</t> The OpenPGP specification specifies one such printable encoding scheme to ensure
interoperability; see <xref target="forming-ascii-armor"/>.</t>
<t>In principle, any printable encoding scheme that met the requirements of the <t>The encoding is composed of two parts: a base64 encoding of the binary
unsafe channel would suffice, since it would not change the underlying binary bi data and an optional checksum.
t streams of the native OpenPGP data structures.
The OpenPGP standard specifies one such printable encoding scheme to ensure inte
roperability, <xref target="forming-ascii-armor"/>.</t>
<t>The encoding is composed of two parts: a base64 encoding of the binary data a
nd an optional checksum.
The base64 encoding used is described in <xref section="4" sectionFormat="of" ta rget="RFC4648"/>, and it is wrapped into lines of no more than 76 characters eac h.</t> The base64 encoding used is described in <xref section="4" sectionFormat="of" ta rget="RFC4648"/>, and it is wrapped into lines of no more than 76 characters eac h.</t>
<t>When decoding base64, an OpenPGP implementation <bcp14>MUST</bcp14> ign
<t>When decoding base64, an OpenPGP implementation <bcp14>MUST</bcp14> ignore al ore all whitespace.</t>
l white space.</t> <section anchor="optional-crc24">
<name>Optional Checksum</name>
<section anchor="optional-crc24"><name>Optional checksum</name> <t>The optional checksum is a 24-bit Cyclic Redundancy Check (CRC) conve
rted to four characters of base64 encoding by the same MIME base64 transformatio
<t>The optional checksum is a 24-bit Cyclic Redundancy Check (CRC) converted to n, preceded by an equal sign (=). The CRC is computed by using the generator 0x8
four characters of base64 encoding by the same MIME base64 transformation, prece 64CFB and an initialization of 0xB704CE. The accumulation is done on the data be
ded by an equal sign (=). fore it is converted to base64 rather than on the converted data. A sample imple
The CRC is computed by using the generator 0x864CFB and an initialization of 0xB mentation of this algorithm is in <xref target="sample-crc24"/>.</t>
704CE. <t>If present, the checksum with its leading equal sign <bcp14>MUST</bcp14> appe
The accumulation is done on the data before it is converted to base64, rather th ar on the next line after the base64-encoded data.</t>
an on the converted data. <t>An implementation <bcp14>MUST NOT</bcp14> reject an OpenPGP object when the C
A sample implementation of this algorithm is in <xref target="sample-crc24"/>.</ RC24 footer is present, missing, malformed, or disagrees with the computed CRC24
t> sum. When forming ASCII Armor, the CRC24 footer <bcp14>SHOULD NOT</bcp14> be ge
nerated, unless interoperability with implementations that require the CRC24 foo
<t>If present, the checksum with its leading equal sign <bcp14>MUST</bcp14> appe ter to be present is a concern.</t>
ar on the next line after the base64 encoded data.</t> <t>The CRC24 footer <bcp14>MUST NOT</bcp14> be generated if it can be de
termined by the context or by the OpenPGP object being encoded that the consumin
<t>An implementation <bcp14>MUST NOT</bcp14> reject an OpenPGP object when the C g implementation accepts base64-encoded blocks without a CRC24 footer. Notably:<
RC24 footer is present, missing, malformed, or disagrees with the computed CRC24 /t>
sum. <ul spacing="normal">
When forming ASCII Armor, the CRC24 footer <bcp14>SHOULD NOT</bcp14> be generate <li>
d, unless interoperability with implementations that require the CRC24 footer to <t>An ASCII-armored Encrypted Message packet sequence that ends in a
be present is a concern.</t> v2 SEIPD packet <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t>
</li>
<t>The CRC24 footer <bcp14>MUST NOT</bcp14> be generated if it can be determined <li>
by context or by the OpenPGP object being encoded that the consuming implementa <t>An ASCII-armored sequence of Signature packets that only includes
tion accepts base64 encoded blocks without CRC24 footer. v6 Signature packets <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t>
Notably:</t> </li>
<li>
<t><list style="symbols"> <t>An ASCII-armored Transferable Public Key packet sequence of a v6
<t>An ASCII-armored Encrypted Message packet sequence that ends in an v2 SEIPD key <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t>
packet <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t> </li>
<t>An ASCII-armored sequence of Signature packets that only includes v6 Signat <li>
ure packets <bcp14>MUST NOT</bcp14> contain a CRC24 footer.</t> <t>An ASCII-armored keyring consisting of only v6 keys <bcp14>MUST N
<t>An ASCII-armored Transferable Public Key packet sequence of a v6 key <bcp14 OT</bcp14> contain a CRC24 footer.</t>
>MUST NOT</bcp14> contain a CRC24 footer.</t> </li>
<t>An ASCII-armored keyring consisting of only v6 keys <bcp14>MUST NOT</bcp14> </ul>
contain a CRC24 footer.</t> <t>Rationale:
</list></t> Previous draft versions of this document stated that the CRC24 footer is optiona
l, but the text was ambiguous. In practice, very few implementations require the
<t>Rationale: CRC24 footer to be present. Computing the CRC24 incurs a significant cost, whil
Previous versions of this document state that the CRC24 footer is optional, but e providing no meaningful integrity protection.
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 int
egrity protection.
Therefore, generating it is now discouraged.</t> Therefore, generating it is now discouraged.</t>
<section anchor="sample-crc24">
<section anchor="sample-crc24"><name>An Implementation of the CRC-24 in "C"</nam <name>An Implementation of the CRC24 in "C"</name>
e> <t>The following code is written in <xref target="C99"/>.</t>
<sourcecode type="text/c" name="sample-crc24.c"><![CDATA[
<t>The following code is written in <xref target="C99"/>.</t>
<figure><sourcecode type="text/x-csrc" name="sample-crc24.c"><![CDATA[
#define CRC24_INIT 0xB704CEL #define CRC24_INIT 0xB704CEL
#define CRC24_GENERATOR 0x864CFBL #define CRC24_GENERATOR 0x864CFBL
typedef unsigned long crc24; typedef unsigned long crc24;
crc24 crc_octets(unsigned char *octets, size_t len) crc24 crc_octets(unsigned char *octets, size_t len)
{ {
crc24 crc = CRC24_INIT; crc24 crc = CRC24_INIT;
int i; int i;
while (len--) { while (len--) {
crc ^= (*octets++) << 16; crc ^= (*octets++) << 16;
for (i = 0; i < 8; i++) { for (i = 0; i < 8; i++) {
crc <<= 1; crc <<= 1;
if (crc & 0x1000000) { if (crc & 0x1000000) {
crc &= 0XFFFFFF; /* Clear bit 25 to avoid overflow */ crc &= 0XFFFFFF; /* Clear bit 25 to avoid overflow */
crc ^= CRC24_GENERATOR; crc ^= CRC24_GENERATOR;
} }
} }
} }
return crc & 0xFFFFFFL; return crc & 0xFFFFFFL;
} }
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="forming-ascii-armor">
<section anchor="forming-ascii-armor"><name>Forming ASCII Armor</name> <name>Forming ASCII Armor</name>
<t>When OpenPGP encodes data into ASCII Armor, it puts specific headers
<t>When OpenPGP encodes data into ASCII Armor, it puts specific headers around t around the base64-encoded data, so OpenPGP can reconstruct the data later.
he base64 encoded data, so OpenPGP can reconstruct the data later.
An OpenPGP implementation <bcp14>MAY</bcp14> use ASCII armor to protect raw bina ry data. An OpenPGP implementation <bcp14>MAY</bcp14> use ASCII armor to protect raw bina ry data.
OpenPGP informs the user what kind of data is encoded in the ASCII armor through the use of the headers.</t> 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>Concatenating the following data creates ASCII Armor:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>An Armor Header Line, appropriate for the type of data</t>
<t>An Armor Header Line, appropriate for the type of data</t> </li>
<t>Armor Headers</t> <li>
<t>A blank (zero-length, or containing only whitespace) line</t> <t>Armor Headers</t>
<t>The ASCII-Armored data</t> </li>
<t>An optional Armor Checksum (discouraged, see <xref target="optional-crc24"/ <li>
>)</t> <t>A blank (zero length or containing only whitespace) line</t>
<t>The Armor Tail, which depends on the Armor Header Line</t> </li>
</list></t> <li>
<t>The ASCII-Armored data</t>
<section anchor="armor-header-line"><name>Armor Header Line</name> </li>
<li>
<t>An Armor Header Line consists of the appropriate header line text surrounded <t>An optional Armor Checksum (discouraged; see <xref target="option
by five (5) dashes (<spanx style="verb">-</spanx>, 0x2D) on either side of the h al-crc24"/>)</t>
eader line text. </li>
The header line text is chosen based upon the type of data that is being encoded <li>
in Armor, and how it is being encoded. <t>The Armor Tail, which depends on the Armor Header Line</t>
</li>
</ul>
<section anchor="armor-header-line">
<name>Armor Header Line</name>
<t>An Armor Header Line consists of the appropriate header line text s
urrounded by five (5) dashes (<tt>-</tt>, 0x2D) on either side of the header lin
e text. The header line text is chosen based on the type of data being encoded i
n Armor and how it is being encoded.
Header line texts include the following strings:</t> Header line texts include the following strings:</t>
<texttable title="OpenPGP Armor Header Line registry" anchor="armor-header-line- <table anchor="armor-header-line-registry">
registry"> <name>OpenPGP Armor Header Lines Registry</name>
<ttcol align='left'>Armor Header</ttcol> <thead>
<ttcol align='left'>Use</ttcol> <tr>
<c><spanx style="verb">BEGIN PGP MESSAGE</spanx></c> <th align="left">Armor Header</th>
<c>Used for signed, encrypted, or compressed files.</c> <th align="left">Use</th>
<c><spanx style="verb">BEGIN PGP PUBLIC KEY BLOCK</spanx></c> </tr>
<c>Used for armoring public keys.</c> </thead>
<c><spanx style="verb">BEGIN PGP PRIVATE KEY BLOCK</spanx></c> <tbody>
<c>Used for armoring private keys.</c> <tr>
<c><spanx style="verb">BEGIN PGP SIGNATURE</spanx></c> <td align="left">
<c>Used for detached signatures, OpenPGP/MIME signatures, and cleartext si <tt>BEGIN PGP MESSAGE</tt></td>
gnatures.</c> <td align="left">Used for signed, encrypted, or compressed files
</texttable> .</td>
</tr>
<t>Note that all these Armor Header Lines are to consist of a complete line. <tr>
The header lines, therefore, <bcp14>MUST</bcp14> start at the beginning of a lin <td align="left">
e, and <bcp14>MUST NOT</bcp14> have text other than whitespace following them on <tt>BEGIN PGP PUBLIC KEY BLOCK</tt></td>
the same line.</t> <td align="left">Used for armoring public keys.</td>
</tr>
</section> <tr>
<section anchor="armor-headers"><name>Armor Headers</name> <td align="left">
<tt>BEGIN PGP PRIVATE KEY BLOCK</tt></td>
<t>The Armor Headers are pairs of strings that can give the user or the receivin <td align="left">Used for armoring private keys.</td>
g OpenPGP implementation some information about how to decode or use the message </tr>
. <tr>
The Armor Headers are a part of the armor, not a part of the message, and hence <td align="left">
are not protected by any signatures applied to the message.</t> <tt>BEGIN PGP SIGNATURE</tt></td>
<td align="left">Used for detached signatures, OpenPGP/MIME sign
<t>The format of an Armor Header is that of a key-value pair. atures, and cleartext signatures.</td>
A colon (<spanx style="verb">:</spanx> 0x3A) and a single space (0x20) separate </tr>
the key and value. </tbody>
An OpenPGP implementation may consider improperly formatted Armor Headers to be </table>
corruption of the ASCII Armor, but <bcp14>SHOULD</bcp14> make an effort to recov <t>Note that all of these Armor Header Lines are to consist of a compl
er. ete line.
Unknown keys should be silently ignored, and an OpenPGP implementation <bcp14>SH Therefore, the header lines <bcp14>MUST</bcp14> start at the beginning of a line
OULD</bcp14> continue to process the message.</t> and <bcp14>MUST NOT</bcp14> have text other than whitespace following them on t
he same line.</t>
<t>Note that some transport methods are sensitive to line length. </section>
<section anchor="armor-headers">
<name>Armor Headers</name>
<t>The Armor Headers are pairs of strings that can give the user or th
e receiving OpenPGP implementation some information about how to decode or use t
he message. The Armor Headers are a part of the armor, not the message, and henc
e 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
(<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="RF C5322"/>).</t> 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="RF C5322"/>).</t>
<t>While there is a limit of 76 characters for the base64 data (<xref
<t>While there is a limit of 76 characters for the base64 data (<xref target="ba target="base64"/>), there is no limit for the length of Armor Headers.
se64"/>), there is no limit to the length of Armor Headers. Care should be taken to ensure that the Armor Headers are short enough to surviv
Care should be taken that the Armor Headers are short enough to survive transpor e transport.
t.
One way to do this is to repeat an Armor Header Key multiple times with differen t values for each so that no one line is overly long.</t> One way to do this is to repeat an Armor Header Key multiple times with differen t values for each so that no one line is overly long.</t>
<t>Currently defined Armor Header Keys are as follows:</t>
<t>Currently defined Armor Header Keys are as follows:</t> <table anchor="armor-header-key-registry">
<name>OpenPGP Armor Header Keys Registry</name>
<texttable title="OpenPGP Armor Header Key registry" anchor="armor-header-key-re <thead>
gistry"> <tr>
<ttcol align='left'>Key</ttcol> <th align="left">Key</th>
<ttcol align='left'>Summary</ttcol> <th align="left">Summary</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Reference</th>
<c><spanx style="verb">Version</spanx></c> </tr>
<c>Implementation information</c> </thead>
<c><xref target="armor-header-key-version"/></c> <tbody>
<c><spanx style="verb">Comment</spanx></c> <tr>
<c>Arbitrary text</c> <td align="left">
<c><xref target="armor-header-key-comment"/></c> <tt>Version</tt></td>
<c><spanx style="verb">Hash</spanx></c> <td align="left">Implementation information</td>
<c>Hash algorithms used in some v4 cleartext signed messages</c> <td align="left">
<c><xref target="armor-header-key-hash"/></c> <xref target="armor-header-key-version"/></td>
<c><spanx style="verb">Charset</spanx></c> </tr>
<c>Character set</c> <tr>
<c><xref target="armor-header-key-charset"/></c> <td align="left">
</texttable> <tt>Comment</tt></td>
<td align="left">Arbitrary text</td>
<section anchor="armor-header-key-version"><name>"Version" Armor Header</name> <td align="left">
<xref target="armor-header-key-comment"/></td>
<t>The armor header key <spanx style="verb">Version</spanx> describes the OpenPG </tr>
P implementation and version used to encode the message. <tr>
<td align="left">
<tt>Hash</tt></td>
<td align="left">Hash algorithms used in some v4 cleartext signe
d 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" Armor Header</name>
<t>The armor header key <tt>Version</tt> describes the OpenPGP imple
mentation and version used to encode the message.
To minimize metadata, implementations <bcp14>SHOULD NOT</bcp14> emit this key an d its corresponding value except for debugging purposes with explicit user conse nt.</t> To minimize metadata, implementations <bcp14>SHOULD NOT</bcp14> emit this key an d its corresponding value except for debugging purposes with explicit user conse nt.</t>
</section>
</section> <section anchor="armor-header-key-comment">
<section anchor="armor-header-key-comment"><name>"Comment" Armor Header</name> <name>"Comment" Armor Header</name>
<t>The armor header key <tt>Comment</tt> supplies a user-defined com
<t>The armor header key <spanx style="verb">Comment</spanx> supplies a user-defi ment.
ned comment. OpenPGP defines all text to be in UTF-8. A comment may be any UTF-8 s
OpenPGP defines all text to be in UTF-8. tring. However, the whole point of armoring is to provide seven-bit clean data.
A comment may be any UTF-8 string. Consequently, if a comment has characters that are outside the ASCII range of UT
However, the whole point of armoring is to provide seven-bit-clean data. F, they may very well not survive transport.</t>
Consequently, if a comment has characters that are outside the US-ASCII range of </section>
UTF, they may very well not survive transport.</t> <section anchor="armor-header-key-hash">
<name>"Hash" Armor Header</name>
</section> <t>The armor header key <tt>Hash</tt> is deprecated, but some older
<section anchor="armor-header-key-hash"><name>"Hash" Armor Header</name> implementations expect it in messages using the Cleartext Signature Framework (<
xref target="cleartext-signature"/>). When present, this armor header key contai
<t>This header is deprecated, but some older implementations expect it in messag ns a comma-separated list of hash algorithms used in the signatures on message,
es using the Cleartext Signature Framework (<xref target="cleartext-signature"/> with digest names as specified in the "Text Name" column in <xref target="hash-a
). lgorithms-registry"/>.
When present, The armor header key <spanx style="verb">Hash</spanx> contains a c
omma-separated list of hash algorithms used in the signatures on message, with d
igest names as specified in "Text Name" column in <xref target="hash-algorithms-
registry"/>.
These headers <bcp14>SHOULD NOT</bcp14> be emitted unless:</t> These headers <bcp14>SHOULD NOT</bcp14> be emitted unless:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The cleartext signed message contains a v4 signature made using a SHA2-base <t>the cleartext signed message contains a v4 signature made usi
d digest (<spanx style="verb">SHA224</spanx>, <spanx style="verb">SHA256</spanx> ng a SHA2-based digest (SHA224, SHA256, SHA384, or SHA512), and</t>
, <spanx style="verb">SHA384</spanx>, or <spanx style="verb">SHA512</spanx>), an </li>
d</t> <li>
<t>The cleartext signed message might be verified by a legacy OpenPGP implemen <t>the cleartext signed message might be verified by a legacy Op
tation that requires this header.</t> enPGP implementation that requires this header.</t>
</list></t> </li>
</ul>
<t>A verifying application <bcp14>MUST</bcp14> decline to validate any signature <t>A verifying application <bcp14>MUST</bcp14> decline to validate a
in a message with a non-conformant <spanx style="verb">Hash</spanx> header (tha ny signature in a message with a non-conformant <tt>Hash</tt> header (that is, a
t is, a <spanx style="verb">Hash</spanx> header that contains anything other tha <tt>Hash</tt> header that contains anything other than a comma-separated list o
n a comma-separated list of hash algorithms). f hash algorithms).
When a conformant <spanx style="verb">Hash</spanx> header is present, a verifyin When a conformant <tt>Hash</tt> header is present, a verifying application <bcp1
g application <bcp14>MUST</bcp14> ignore its contents, deferring to the hash alg 4>MUST</bcp14> ignore its contents, deferring to the hash algorithm indicated in
orithm indicated in the embedded signature.</t> the embedded signature.</t>
</section>
</section> <section anchor="armor-header-key-charset">
<section anchor="armor-header-key-charset"><name>"Charset" Armor Header</name> <name>"Charset" Armor Header</name>
<t>The armor header key <tt>Charset</tt> contains a description of t
<t>The armor header key <spanx style="verb">Charset</spanx> contains a descripti he character set that the plaintext is in (see <xref target="RFC2978"/>).
on of the character set that the plaintext is in (see <xref target="RFC2978"/>).
Please note that OpenPGP defines text to be in UTF-8. Please note that OpenPGP defines text to be in UTF-8.
An implementation will get best results by translating into and out of 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. 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. 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 defau lt by using this header key. In such instances, an implementation <bcp14>MAY</bcp14> override the UTF-8 defau lt 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> 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>
</section> <section anchor="armor-tail-line">
<section anchor="armor-tail-line"><name>Armor Tail Line</name> <name>Armor Tail Line</name>
<t>The Armor Tail Line is composed in the same manner as the Armor Hea
<t>The Armor Tail Line is composed in the same manner as the Armor Header Line, der Line, except the string "BEGIN" is replaced by the string "END".</t>
except the string "BEGIN" is replaced by the string "END".</t> </section>
</section>
</section> </section>
</section> <section anchor="cleartext-signature">
</section> <name>Cleartext Signature Framework</name>
<section 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
<t>It is desirable to be able to sign a textual octet stream without ASCII armor capable of rendering text.
ing the stream itself, so the signed text is still readable with any tool capabl In order to bind a signature to such a cleartext, the Cleartext Signature Framew
e of rendering text. ork is used, which follows the same basic format and restrictions as the ASCII a
In order to bind a signature to such a cleartext, this framework is used, which rmoring described in <xref target="forming-ascii-armor"/>.
follows the same basic format and restrictions as the ASCII armoring described i
n <xref target="forming-ascii-armor"/>.
(Note that this framework is not intended to be reversible. (Note that this framework is not intended to be reversible.
<xref target="RFC3156"/> defines another way to sign cleartext messages for envi ronments that support MIME.)</t> <xref target="RFC3156"/> defines another way to sign cleartext messages for envi ronments that support MIME.)</t>
<section anchor="cleartext-structure">
<section anchor="cleartext-structure"><name>Cleartext Signed Message Structure</ <name>Cleartext Signed Message Structure</name>
name> <t>An OpenPGP cleartext signed message consists of:</t>
<ul spacing="normal">
<t>An OpenPGP cleartext signed message consists of:</t> <li>
<t>The cleartext header <tt>-----BEGIN PGP SIGNED MESSAGE-----</tt>
<t><list style="symbols"> on a single line.</t>
<t>The cleartext header <spanx style="verb">-----BEGIN PGP SIGNED MESSAGE----- </li>
</spanx> on a single line,</t> <li>
<t>Some implementations <bcp14>MAY</bcp14> include one or more legacy <spanx s <t>One or more legacy <tt>Hash</tt> Armor Headers that <bcp14>MAY</b
tyle="verb">Hash</spanx> Armor Headers, which <bcp14>MUST</bcp14> be ignored whe cp14> be included by some implementations and <bcp14>MUST</bcp14> be ignored whe
n well-formed (see <xref target="armor-header-key-hash"/>),</t> n well formed (see <xref target="armor-header-key-hash"/>).</t>
<t>An empty line (not included into the message digest),</t> </li>
<t>The dash-escaped cleartext,</t> <li>
<t>A line ending separating the cleartext and following armored signature (not <t>An empty line (not included in the message digest).</t>
included into the message digest),</t> </li>
<t>The ASCII armored signature(s) including the <spanx style="verb">-----BEGIN <li>
PGP SIGNATURE-----</spanx> Armor Header and Armor Tail Lines.</t> <t>The dash-escaped cleartext.</t>
</list></t> </li>
<li>
<t>As with any other text signature (<xref target="sigtype-text"/>), a cleartext <t>A line ending separating the cleartext and following armored sign
signature is calculated on the text using canonical &lt;CR&gt;&lt;LF&gt; line e ature (not included in the message digest).</t>
ndings. </li>
As described above, the line ending before the <spanx style="verb">-----BEGIN PG <li>
P SIGNATURE-----</spanx> Armor Header Line of the armored signature is not consi <t>The ASCII-armored signature(s), including the <tt>-----BEGIN PGP
dered part of the signed text.</t> SIGNATURE-----</tt> Armor Header and Armor Tail Lines.</t>
</li>
<t>Also, any trailing whitespace --- spaces (0x20) and tabs (0x09) --- at the en </ul>
d of any line is removed before signing or verifying a cleartext signed message. <t>As with any other text signature (<xref target="sigtype-text"/>), a c
</t> leartext signature is calculated on the text using canonical &lt;CR&gt;&lt;LF&gt
; line endings.
<t>Between the <spanx style="verb">-----BEGIN PGP SIGNED MESSAGE-----</spanx> li As described above, the line ending before the <tt>-----BEGIN PGP SIGNATURE-----
ne and the first empty line, the only Armor Header permitted is a well-formed <s </tt> Armor Header Line of the armored signature is not considered part of the s
panx style="verb">Hash</spanx> Armor Header (see <xref target="armor-header-key- igned text.</t>
hash"/>). <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 me
ssage.</t>
<t>Between the <tt>-----BEGIN PGP SIGNED MESSAGE-----</tt> line and the
first empty line, the only Armor Header permitted is a well-formed <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 implemen tation <bcp14>MUST</bcp14> decline to validate any signature in a cleartext mess age if that message has any other Armor Header present in this location.</t> To reduce the risk of confusion about what has been signed, a verifying implemen tation <bcp14>MUST</bcp14> decline to validate any signature in a cleartext mess age if that message has any other Armor Header present in this location.</t>
</section>
</section> <section anchor="dash-escaping">
<section anchor="dash-escaping"><name>Dash-Escaped Text</name> <name>Dash-Escaped Text</name>
<t>The cleartext content of the message must also be dash-escaped.</t>
<t>The cleartext content of the message must also be dash-escaped.</t> <t>Dash-escaped cleartext is the ordinary cleartext where every line sta
rting with a <u>-</u> is prefixed by the sequence <u>-</u> and <u> </u>.
<t>Dash-escaped cleartext is the ordinary cleartext where every line starting wi
th 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. This prevents the parser from recognizing armor headers of the cleartext itself.
An implementation <bcp14>MAY</bcp14> dash-escape any line, <bcp14>SHOULD</bcp14> An implementation <bcp14>MAY</bcp14> dash-escape any line, <bcp14>SHOULD</bcp14>
dash-escape lines commencing "From" followed by a space, and <bcp14>MUST</bcp14 dash-escape lines commencing in "From" followed by a space, and <bcp14>MUST</bc
> dash-escape any line commencing in a dash. p14> dash-escape any line commencing in a dash. The message digest is computed u
The message digest is computed using the cleartext itself, not the dash-escaped sing the cleartext itself, not the dash-escaped form.</t>
form.</t> <t>When reversing dash-escaping, an implementation <bcp14>MUST</bcp14> s
trip the string <tt>-</tt> if it occurs at the beginning of a line, and it <bcp1
4>SHOULD</bcp14> 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 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 whitespac
e.</t>
<t>For example, the Unified Diff format <xref target="UNIFIED-DIFF"/> co
ntains 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 whit
espace added or removed will represent such a change with semantically meaningfu
l whitespace.</t>
<t>Furthermore, a Cleartext Signature Framework message that is very lar
ge is unlikely to work well.
In particular, it will be difficult for any human reading the message to know wh
ich part is covered by the signature because they can't understand the whole mes
sage at once, especially in the case where an Armor Header line is placed somewh
ere 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 Si
gnature Framework.
Safe alternatives for a semantically meaningful OpenPGP signature over such a fi
le format are:</t>
<ul spacing="normal">
<li>
<t>A signed message, as described in <xref target="openpgp-messages"
/>.</t>
</li>
<li>
<t>A detached signature, as described in <xref target="detached-sign
atures"/>.</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, an attacker can include additional text in the <tt>Hash</tt> he
ader, which may mislead the user into thinking it is part of the signed text.
The signature validation constraints described in Sections <xref target="armor-h
eader-key-hash" format="counter"/> and <xref target="cleartext-structure" format
="counter"/> help to mitigate the risk of arbitrary or misleading text in the Ar
mor Headers.</t>
</section>
</section>
<t>When reversing dash-escaping, an implementation <bcp14>MUST</bcp14> strip the <section anchor="regular-expressions">
string <spanx style="verb">- </spanx> if it occurs at the beginning of a line, <name>Regular Expressions</name>
and <bcp14>SHOULD</bcp14> warn on <spanx style="verb">-</spanx> and any characte <t>This section describes regular expressions.</t>
r other than a space at the beginning of a line.</t>
</section> <dl>
<section anchor="csf-issues"><name>Issues with the Cleartext Signature Framework <dt>Regular expression:</dt><dd>Zero or more branches, separated by <tt>|<
</name> /tt>.
It matches anything that matches one of the branches.</dd>
<dt>Branch:</dt><dd>Zero or more pieces, concatenated. It matches a match
for the first, followed by a match for the second, etc.</dd>
<dt>Piece:</dt><dd>An atom possibly followed by <tt>*</tt>, <tt>+</tt>, or
<tt>?</tt>.
An atom followed by <tt>*</tt> matches a sequence of 0 or more matches of the at
om.
An atom followed by <tt>+</tt> matches a sequence of 1 or more matches of the at
om.
An atom followed by <tt>?</tt> matches a match of the atom or the null string.</
dd>
<dt>Atom:</dt><dd>A regular expression in parentheses (matching a match fo
r the regular expression), a range (see below), a <tt>.</tt> (matching any singl
e Unicode character), a <tt>^</tt> (matching the null string at the beginning of
the input string), a <tt>$</tt> (matching the null string at the end of the inp
ut string), a <tt>\</tt> followed by a single Unicode character (matching that c
haracter), or a single Unicode character with no other significance (matching th
at character).</dd>
<dt>Range:</dt><dd>A sequence of characters enclosed in <tt>[]</tt>.
It normally matches any single character from the sequence.
If the sequence begins with <tt>^</tt>, it matches any single Unicode character
not from the rest of the sequence. If two characters in the sequence are separat
ed by <tt>-</tt>, this is shorthand for the full list of Unicode characters betw
een them in codepoint order (for example, <tt>[0-9]</tt> matches any decimal dig
it). To include a literal <tt>]</tt> in the sequence, make it the first characte
r (following a possible <tt>^</tt>). To include a literal <tt>-</tt>, make it th
e first or last character.</dd>
</dl>
</section>
<section 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 <bcp
14>MAY</bcp14> implement an algorithm that is not on these lists, as long as the
algorithm IDs are chosen from the Private or Experimental Use algorithm range.<
/t>
<t>See <xref target="notes-on-algorithms"/> for more discussion of the alg
orithms.</t>
<section anchor="pubkey-algos">
<name>Public-Key Algorithms</name>
<table anchor="pubkey-algo-registry">
<name>OpenPGP Public Key Algorithms 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"/></t
d>
<td align="left">MPI(n), MPI(e) [<xref target="key-rsa"/>]</td>
<td align="left">MPI(d), MPI(p), MPI(q), MPI(u)</td>
<td align="left">MPI(m<sup>d</sup> mod n) [<xref target="sig-rsa"/
>]</td>
<td align="left">MPI(m<sup>e</sup> mod n) [<xref target="pkesk-rsa
"/>]</td>
</tr>
<tr>
<td align="right">2</td>
<td align="left">RSA Encrypt-Only <xref target="FIPS186"/></td>
<td align="left">MPI(n), MPI(e) [<xref target="key-rsa"/>]</td>
<td align="left">MPI(d), MPI(p), MPI(q), MPI(u)</td>
<td align="left">N/A</td>
<td align="left">MPI(m<sup>e</sup> mod n) [<xref target="pkesk-rsa
"/>]</td>
</tr>
<tr>
<td align="right">3</td>
<td align="left">RSA Sign-Only <xref target="FIPS186"/></td>
<td align="left">MPI(n), MPI(e) [<xref target="key-rsa"/>]</td>
<td align="left">MPI(d), MPI(p), MPI(q), MPI(u)</td>
<td align="left">MPI(m<sup>d</sup> mod n) [<xref 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"/></
td>
<td align="left">MPI(p), MPI(g), MPI(y) [<xref target="key-elgamal
"/>]</td>
<td align="left">MPI(x)</td>
<td align="left">N/A</td>
<td align="left">MPI(g<sup>k</sup> mod p), MPI(m * y<sup>k</sup> m
od p) [<xref target="pkesk-elgamal"/>]</td>
</tr>
<tr>
<td align="right">17</td>
<td align="left">DSA (Digital Signature Algorithm) <xref target="F
IPS186"/></td>
<td align="left">MPI(p), MPI(q), MPI(g), MPI(y) [<xref target="key
-dsa"/>]</td>
<td align="left">MPI(x)</td>
<td align="left">MPI(r), MPI(s) [<xref target="sig-dsa"/>]</td>
<td align="left">N/A</td>
</tr>
<tr>
<td align="right">18</td>
<td align="left">ECDH public key algorithm</td>
<td align="left">OID, MPI(point in curve-specific point format), K
DFParams [Sections <xref target="curve-specific-formats" format="counter"/> and
<xref target="key-ecdh" format="counter"/>]</td>
<td align="left">MPI(value in curve-specific format) [<xref target
="curve-specific-formats"/>]</td>
<td align="left">N/A</td>
<td align="left">MPI(point in curve-specific point format), size o
ctet, encoded key [Sections <xref target="curve-specific-formats" format="counte
r"/>, <xref target="pkesk-ecdh" format="counter"/>, and <xref target="ecdh" form
at="counter"/>]</td>
</tr>
<tr>
<td align="right">19</td>
<td align="left">ECDSA public key algorithm <xref target="FIPS186"
/></td>
<td align="left">OID, MPI(point in SEC1 format) [<xref target="key
-ecdsa"/>]</td>
<td align="left">MPI(value)</td>
<td align="left">MPI(r), MPI(s) [<xref 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)</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 fo
r 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) [Sectio
ns <xref target="ec-point-prefixed-native" format="counter"/> and <xref target="
key-eddsa-legacy" format="counter"/>]</td>
<td align="left">MPI(value in curve-specific format) [<xref target
="curve-specific-formats"/>]</td>
<td align="left">MPI, MPI [Sections <xref target="curve-specific-f
ormats" format="counter"/> and <xref 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 [<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 [<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 or Experimental Use</td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
</tbody>
</table>
<t>Since creating a cleartext signed message involves trimming trailing whitespa <t>Implementations <bcp14>MUST</bcp14> implement Ed25519 (27) for signat
ce on every line, the Cleartext Signature Framework will fail to safely round-tr ures and X25519 (25) for encryption.
ip any textual stream that may include semantically meaningful whitespace.</t> Implementations <bcp14>SHOULD</bcp14> implement Ed448 (28) and X448 (26).</t>
<t>RSA (1) keys are deprecated and <bcp14>SHOULD NOT</bcp14> be generate
d but may be interpreted.
RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and <bcp14>MUST NOT</b
cp14> be generated (see <xref target="rsa-notes"/>). Elgamal (16) keys are depre
cated 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"/>). For notes on Elgamal Encrypt or Sign (20) and X9.42
(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 thi
s specification <xref target="RFC4880"/> has only DSA (17) and Elgamal (16) as t
he algorithms that <bcp14>MUST</bcp14> be implemented.</t>
<t>A compatible specification of ECDSA is given in <xref target="RFC6090
"/> (as "KT-I Signatures") and in <xref target="SEC1"/>; ECDH is defined in <xre
f target="ecdh"/> of this document.</t>
</section>
<section anchor="ec-curves">
<name>ECC Curves for OpenPGP</name>
<t>The parameter curve OID is an array of octets that defines a named cu
rve.</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 algorithm
s the curve can be used with, as well as the size of expected elements in octets
. Note that there is a break in "EdDSALegacy" for display purposes only.</t>
<t>For example, the Unified Diff format <xref target="UNIFIED-DIFF"/> contains s <table anchor="ecc-oid-usage-registry">
emantically meaningful whitespace: an empty line of context will consist of a li <name>OpenPGP ECC Curve OIDs and Usage Registry</name>
ne with a single <u> </u> character, and any line that has trailing whitespace a <thead>
dded or removed will represent such a change with semantically meaningful whites <tr>
pace.</t> <th align="left">ASN.1 Object Identifier</th>
<th align="left">OID Len</th>
<th align="left">Curve OID Octets</th>
<th align="left">Curve Name</th>
<th align="left">Usage</th>
<th align="left">Field Size (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</td>
<td align="left">NIST P-256</td>
<td align="left">ECDSA, ECDH</td>
<td align="left">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</td>
<td align="left">NIST P-384</td>
<td align="left">ECDSA, ECDH</td>
<td align="left">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</td>
<td align="left">NIST P-521</td>
<td align="left">ECDSA, ECDH</td>
<td align="left">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</td>
<td align="left">brainpoolP256r1</td>
<td align="left">ECDSA, ECDH</td>
<td align="left">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</td>
<td align="left">brainpoolP384r1</td>
<td align="left">ECDSA, ECDH</td>
<td align="left">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</td>
<td align="left">brainpoolP512r1</td>
<td align="left">ECDSA, ECDH</td>
<td align="left">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</td>
<td align="left">Ed25519Legacy</td>
<td align="left">EdDSA<br/>Legacy</td>
<td align="left">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</td>
<td align="left">Curve25519Legacy</td>
<td align="left">ECDH</td>
<td align="left">32</td>
</tr>
</tbody>
</table>
<t>Furthermore, a Cleartext Signature Framework message that is very large is un <!-- Combined Usage and Field Size columns:
likely to work well.
In particular, it will be difficult for any human reading the message to know wh
ich part of the message is covered by the signature because they can't understan
d the whole message at once, in case 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 <table anchor="ecc-oid-usage-registry">
the above characteristics <bcp14>SHOULD NOT</bcp14> use the Cleartext Signature <name>OpenPGP ECC Curve OIDs and Usage Registry</name>
Framework. <thead>
Safe alternatives for a semantically meaningful OpenPGP signature over such a fi <tr>
le format are:</t> <th align="left">ASN.1 Object Identifier</th>
<th align="left">OID Len</th>
<th align="left">Curve OID 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</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</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</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</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</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</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</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</td>
<td align="left">Curve25519Legacy</td>
<td align="left">ECDH (32)</td>
</tr>
</tbody>
</table>
-->
<t><list style="symbols"> <t>The "Field Size (fsize)" column represents the field size of the grou
<t>A Signed Message, as described in <xref target="openpgp-messages"/>.</t> p in number of octets, rounded up, such that x or y coordinates for a point on t
<t>A Detached Signature as described in <xref target="detached-signatures"/>.< he curve or native point representations for the curve can be represented in tha
/t> t many octets. The curves specified here, and scalars such as the base point ord
</list></t> er and the private key, can be represented in fsize octets. However, note that c
urves exist outside this specification where the representation of scalars requi
res 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 subse
quent truncation. The truncation removes the two fields of encoded Object Identi
fier. The first omitted field is one octet representing the Object Identifier ta
g, 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 c
onstructed 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 o
nly in version 4 keys and signatures.
Implementations <bcp14>MAY</bcp14> implement these variants for compatibility wi
th 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 Wire Formats</name>
<t>Some elliptic curve public key algorithms use different conventions
for specific fields depending on the curve in use. Each field is always formatt
ed as an MPI, but with a curve-specific framing. This table summarizes those dis
tinctions.</t>
<table anchor="ecc-wire-formats-registry">
<name>OpenPGP ECC Curve-Specific Wire Formats Registry</name>
<thead>
<tr>
<th align="left">Curve</th>
<th align="left">ECDH Point Format</th>
<th align="left">ECDH Secret Key MPI</th>
<th align="left">EdDSA Secret Key MPI</th>
<th align="left">EdDSA Signature first MPI</th>
<th align="left">EdDSA Signature second 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 <xre
f 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 Algorithms</name>
<table anchor="symkey-algorithms-registry">
<name>OpenPGP Symmetric Key Algorithms Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Algorithm</th>
<t>Either of these alternatives may be ASCII-armored (see <xref target="forming- </tr>
ascii-armor"/>) if they need to be transmitted across a text-only (or 7-bit clea </thead>
n) channel.</t> <tbody>
<tr>
<td align="right">0</td>
<td align="left">Plaintext or unencrypted data</td>
<t>Finally, when a Cleartext Signature Framework message is presented to the use </tr>
r as-is, an attacker can include additional text in the <spanx style="verb">Hash <tr>
</spanx> header, which may mislead the user into thinking it is part of the sign <td align="right">1</td>
ed text. <td align="left">IDEA <xref target="IDEA"/></td>
The signature validation constraints described in <xref target="armor-header-key
-hash"/> and <xref target="cleartext-structure"/> help to mitigate the risk of a
rbitrary or misleading text in the Armor Headers.</t>
</section> </tr>
</section> <tr>
<section anchor="regular-expressions"><name>Regular Expressions</name> <td align="right">2</td>
<td align="left">TripleDES (or DES-EDE) <xref target="SP800-67"/>
with 168-bit key derived from 192</td>
<t>A regular expression is zero or more branches, separated by <spanx style="ver </tr>
b">|</spanx>. <tr>
It matches anything that matches one of the branches.</t> <td align="right">3</td>
<td align="left">CAST5 with 128-bit key <xref target="RFC2144"/></
td>
<t>A branch is zero or more pieces, concatenated. </tr>
It matches a match for the first, followed by a match for the second, etc.</t> <tr>
<td align="right">4</td>
<td align="left">Blowfish with 128-bit key, 16 rounds <xref target
="BLOWFISH"/></td>
<t>A piece is an atom possibly followed by <spanx style="verb">*</spanx>, <spanx </tr>
style="verb">+</spanx>, or <spanx style="verb">?</spanx>. <tr>
An atom followed by <spanx style="verb">*</spanx> matches a sequence of 0 or mor <td align="right">5</td>
e matches of the atom. <td align="left">Reserved</td>
An atom followed by <spanx style="verb">+</spanx> matches a sequence of 1 or mor
e matches of the atom.
An atom followed by <spanx style="verb">?</spanx> matches a match of the atom, o
r the null string.</t>
<t>An atom is a regular expression in parentheses (matching a match for the regu </tr>
lar expression), a range (see below), <spanx style="verb">.</spanx> (matching an <tr>
y single Unicode character), <spanx style="verb">^</spanx> (matching the null st <td align="right">6</td>
ring at the beginning of the input string), <spanx style="verb">$</spanx> (match <td align="left">Reserved</td>
ing the null string at the end of the input string), a <spanx style="verb">\</sp
anx> followed by a single Unicode character (matching that character), or a sing
le Unicode character with no other significance (matching that character).</t>
<t>A range is a sequence of characters enclosed in <spanx style="verb">[]</spanx </tr>
>. <tr>
It normally matches any single character from the sequence. <td align="right">7</td>
If the sequence begins with <spanx style="verb">^</spanx>, it matches any single <td align="left">AES with 128-bit key <xref target="AES"/></td>
Unicode character not from the rest of the sequence.
If two characters in the sequence are separated by <spanx style="verb">-</spanx>
, this is shorthand for the full list of Unicode characters between them in code
point order (for example, <spanx style="verb">[0-9]</spanx> matches any decimal
digit).
To include a literal <spanx style="verb">]</spanx> in the sequence, make it the
first character (following a possible <spanx style="verb">^</spanx>).
To include a literal <spanx style="verb">-</spanx>, make it the first or last ch
aracter.</t>
</section> </tr>
<section anchor="constants"><name>Constants</name> <tr>
<td align="right">8</td>
<td align="left">AES with 192-bit key</td>
<t>This section describes the constants used in OpenPGP.</t> </tr>
<tr>
<td align="right">9</td>
<td align="left">AES with 256-bit key</td>
<t>Note that these tables are not exhaustive lists; an implementation <bcp14>MAY </tr>
</bcp14> implement an algorithm not on these lists, so long as the algorithm IDs <tr>
are chosen from the private or experimental algorithm range.</t> <td align="right">10</td>
<td align="left">Twofish with 256-bit key <xref target="TWOFISH"/>
</td>
<t>See <xref target="notes-on-algorithms"/> for more discussion of the algorithm </tr>
s.</t> <tr>
<td align="right">11</td>
<td align="left">Camellia with 128-bit key <xref target="RFC3713"/
></td>
<section anchor="pubkey-algos"><name>Public-Key Algorithms</name> </tr>
<tr>
<td align="right">12</td>
<td align="left">Camellia with 192-bit key</td>
<texttable title="OpenPGP Public Key Algorithms registry" anchor="pubkey-algo-re </tr>
gistry"> <tr>
<ttcol align='right'>ID</ttcol> <td align="right">13</td>
<ttcol align='left'>Algorithm</ttcol> <td align="left">Camellia with 256-bit key</td>
<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>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>1</c>
<c>RSA (Encrypt or Sign) <xref target="FIPS186"/></c>
<c>MPI(n), MPI(e) [<xref target="key-rsa"/>]</c>
<c>MPI(d), MPI(p), MPI(q), MPI(u)</c>
<c>MPI(m**d mod n) [<xref target="sig-rsa"/>]</c>
<c>MPI(m**e mod n) [<xref target="pkesk-rsa"/>]</c>
<c>2</c>
<c>RSA Encrypt-Only <xref target="FIPS186"/></c>
<c>MPI(n), MPI(e) [<xref target="key-rsa"/>]</c>
<c>MPI(d), MPI(p), MPI(q), MPI(u)</c>
<c>N/A</c>
<c>MPI(m**e mod n) [<xref target="pkesk-rsa"/>]</c>
<c>3</c>
<c>RSA Sign-Only <xref target="FIPS186"/></c>
<c>MPI(n), MPI(e) [<xref target="key-rsa"/>]</c>
<c>MPI(d), MPI(p), MPI(q), MPI(u)</c>
<c>MPI(m**d mod n) [<xref target="sig-rsa"/>]</c>
<c>N/A</c>
<c>16</c>
<c>Elgamal (Encrypt-Only) <xref target="ELGAMAL"/></c>
<c>MPI(p), MPI(g), MPI(y) [<xref target="key-elgamal"/>]</c>
<c>MPI(x)</c>
<c>N/A</c>
<c>MPI(g**k mod p), MPI (m * y**k mod p) [<xref target="pkesk-elgamal"/>]<
/c>
<c>17</c>
<c>DSA (Digital Signature Algorithm) <xref target="FIPS186"/></c>
<c>MPI(p), MPI(q), MPI(g), MPI(y) [<xref target="key-dsa"/>]</c>
<c>MPI(x)</c>
<c>MPI(r), MPI(s) [<xref target="sig-dsa"/>]</c>
<c>N/A</c>
<c>18</c>
<c>ECDH public key algorithm</c>
<c>OID, MPI(point in curve-specific point format), KDFParams [see <xref ta
rget="curve-specific-formats"/>, <xref target="key-ecdh"/>]</c>
<c>MPI(value in curve-specific format) [<xref target="curve-specific-forma
ts"/>]</c>
<c>N/A</c>
<c>MPI(point in curve-specific point format), size octet, encoded key [<xr
ef target="curve-specific-formats"/>, <xref target="pkesk-ecdh"/>, <xref target=
"ecdh"/>]</c>
<c>19</c>
<c>ECDSA public key algorithm <xref target="FIPS186"/></c>
<c>OID, MPI(point in SEC1 format) [<xref target="key-ecdsa"/>]</c>
<c>MPI(value)</c>
<c>MPI(r), MPI(s) [<xref target="sig-dsa"/>]</c>
<c>N/A</c>
<c>20</c>
<c>Reserved (formerly Elgamal Encrypt or Sign)</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>21</c>
<c>Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME)</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>22</c>
<c>EdDSALegacy (deprecated)</c>
<c>OID, MPI(point in prefixed native format) [see <xref target="ec-point-p
refixed-native"/>, <xref target="key-eddsa-legacy"/>]</c>
<c>MPI(value in curve-specific format) [see <xref target="curve-specific-f
ormats"/>]</c>
<c>MPI, MPI [see <xref target="curve-specific-formats"/>, <xref target="si
g-eddsa-legacy"/>]</c>
<c>N/A</c>
<c>23</c>
<c>Reserved (AEDH)</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>24</c>
<c>Reserved (AEDSA)</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</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 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 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>&#160;</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>&#160;</c>
<c>100 to 110</c>
<c>Private/Experimental algorithm</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
</texttable>
<t>Implementations <bcp14>MUST</bcp14> implement Ed25519 (27) for signatures, an </tr>
d X25519 (25) for encryption. <tr>
Implementations <bcp14>SHOULD</bcp14> implement Ed448 (28) and X448 (26).</t> <td align="right">100-110</td>
<td align="left">Private or Experimental Use</td>
<t>RSA (1) keys are deprecated and <bcp14>SHOULD NOT</bcp14> be generated, but m </tr>
ay be interpreted. <tr>
RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and <bcp14>MUST NOT</b <td align="right">253-255</td>
cp14> be generated. <td align="left">Reserved to avoid collision with Secret Key Encry
See <xref target="rsa-notes"/>. ption (See <xref target="secret-key-protection-registry"/> and <xref target="sec
Elgamal (16) keys are deprecated and <bcp14>MUST NOT</bcp14> be generated (see < ret-key-packet-formats"/>)</td>
xref target="elgamal-notes"/>).
DSA (17) keys are deprecated and <bcp14>MUST NOT</bcp14> be generated (see <xref </tr>
target="dsa-notes"/>). </tbody>
See <xref target="reserved-notes"/> for notes on Elgamal Encrypt or Sign (20), a </table>
nd X9.42 (21). <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 CA
ST5.
Implementations <bcp14>MAY</bcp14> decrypt data that uses IDEA, TripleDES, or CA
ST5 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>SHOU
LD</bcp14> generate a deprecation warning about the symmetric algorithm, indicat
ing that message confidentiality is suspect.
Implementations <bcp14>MAY</bcp14> implement any other algorithm.</t> Implementations <bcp14>MAY</bcp14> implement any other algorithm.</t>
</section>
<section anchor="compression-algos">
<name>Compression Algorithms</name>
<table anchor="compression-algorithms-registry">
<name>OpenPGP Compression Algorithms Registry</name>
<thead>
<tr>
<th align="right">ID</th>
<th align="left">Algorithm</th>
<t>Note that an implementation conforming to the previous version of this standa </tr>
rd (<xref target="RFC4880"/>) has only DSA (17) and Elgamal (16) as its <bcp14>M </thead>
UST</bcp14>-implement algorithms.</t> <tbody>
<tr>
<td align="right">0</td>
<td align="left">Uncompressed</td>
<t>A compatible specification of ECDSA is given in <xref target="RFC6090"/> as " </tr>
KT-I Signatures" and in <xref target="SEC1"/>; ECDH is defined in <xref target=" <tr>
ecdh"/> of this document.</t> <td align="right">1</td>
<td align="left">ZIP <xref target="RFC1951"/></td>
</section> </tr>
<section anchor="ec-curves"><name>ECC Curves for OpenPGP</name> <tr>
<td align="right">2</td>
<td align="left">ZLIB <xref target="RFC1950"/></td>
<t>The parameter curve OID is an array of octets that defines a named curve.</t> </tr>
<tr>
<td align="right">3</td>
<td align="left">BZip2 <xref target="BZ2"/></td>
<t>The table below specifies the exact sequence of octets for each named curve r </tr>
eferenced in this document. <tr>
It also specifies which public key algorithms the curve can be used with, as wel <td align="right">100-110</td>
l as the size of expected elements in octets:</t> <td align="left">Private or Experimental Use</td>
<texttable title="OpenPGP ECC Curve OID and Usage registry" anchor="ecc-oid-usag </tr>
e-registry"> </tbody>
<ttcol align='left'>ASN.1 Object Identifier</ttcol> </table>
<ttcol align='left'>OID len</ttcol> <t>Implementations <bcp14>MUST</bcp14> implement uncompressed data.
<ttcol align='left'>Curve OID octets in hex</ttcol> Implementations <bcp14>SHOULD</bcp14> implement ZLIB.
<ttcol align='left'>Curve name</ttcol> For interoperability reasons, implementations <bcp14>SHOULD</bcp14> be able to d
<ttcol align='left'>Usage</ttcol> ecompress using ZIP.
<ttcol align='left'>Field Size (fsize)</ttcol> Implementations <bcp14>MAY</bcp14> implement any other algorithm.</t>
<c>1.2.840.10045.3.1.7</c> </section>
<c>8</c> <section anchor="hash-algos">
<c>2A 86 48 CE 3D 03 01 07</c> <name>Hash Algorithms</name>
<c>NIST P-256</c> <table anchor="hash-algorithms-registry">
<c>ECDSA, ECDH</c> <name>OpenPGP Hash Algorithms Registry</name>
<c>32</c> <thead>
<c>1.3.132.0.34</c> <tr>
<c>5</c> <th align="right">ID</th>
<c>2B 81 04 00 22</c> <th align="left">Algorithm</th>
<c>NIST P-384</c> <th align="left">Text Name</th>
<c>ECDSA, ECDH</c> <th align="left">V6 Signature Salt Size</th>
<c>48</c>
<c>1.3.132.0.35</c>
<c>5</c>
<c>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 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 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 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 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 06 01 04 01 97 55 01 05 01</c>
<c>Curve25519Legacy</c>
<c>ECDH</c>
<c>32</c>
</texttable>
<t>The "Field Size (fsize)" column represents the field size of the group in num </tr>
ber of octets, rounded up, such that x or y coordinates for a point on the curve </thead>
or native point representations for the curve can be represented in that many o <tbody>
ctets. <tr>
For the curves specified here, also scalars such as the base point order and the <td align="right">0</td>
private key can be represented in fsize octets. <td align="left">Reserved</td>
Note that, however, there exist curves outside this specification where the repr <td align="left"></td>
esentation of scalars requires an additional octet.</t> <td align="left"></td>
<t>The sequence of octets in the third column is the result of applying the Dist </tr>
inguished Encoding Rules (DER) to the ASN.1 Object Identifier with subsequent tr <tr>
uncation. <td align="right">1</td>
The truncation removes the two fields of encoded Object Identifier. <td align="left">MD5 <xref target="RFC1321"/></td>
The first omitted field is one octet representing the Object Identifier tag, and <td align="left">"MD5"</td>
the second omitted field is the length of the Object Identifier body. <td align="left">N/A</td>
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 c
onstructed 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 v </tr>
ersion 4 keys and signatures. <tr>
Implementations <bcp14>MAY</bcp14> implement these variants for compatibility wi <td align="right">2</td>
th existing v4 key material and signatures. <td align="left">SHA-1 <xref target="FIPS180"/>
Implementations <bcp14>MUST NOT</bcp14> accept or generate v6 key material using <!--<xref target="sha1cd"/> --></td>
the deprecated OIDs.</t> <td align="left">"SHA1"</td>
<td align="left">N/A</td>
<section anchor="curve-specific-formats"><name>Curve-Specific Wire Formats</name </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>
<t>Some Elliptic Curve Public Key Algorithms use different conventions for speci </tr>
fic fields depending on the curve in use. <tr>
Each field is always formatted as an MPI, but with a curve-specific framing. <td align="right">4</td>
This table summarizes those distinctions.</t> <td align="left">Reserved</td>
<td align="left"> </td>
<td align="left"> </td>
<texttable title="OpenPGP ECC Curve-specific Wire Formats registry" anchor="ecc- </tr>
wire-formats-registry"> <tr>
<ttcol align='left'>Curve</ttcol> <td align="right">5</td>
<ttcol align='left'>ECDH Point Format</ttcol> <td align="left">Reserved</td>
<ttcol align='left'>ECDH Secret Key MPI</ttcol> <td align="left"> </td>
<ttcol align='left'>EdDSA Secret Key MPI</ttcol> <td align="left"> </td>
<ttcol align='left'>EdDSA Signature first MPI</ttcol>
<ttcol 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>
<t>For the native octet-string forms of Ed25519Legacy values, see <xref target=" </tr>
RFC8032"/>. <tr>
For the native octet-string forms of Curve25519Legacy secret scalars and points, <td align="right">6</td>
see <xref target="RFC7748"/>.</t> <td align="left">Reserved</td>
<td align="left"> </td>
<td align="left"> </td>
</section> </tr>
</section> <tr>
<section anchor="symmetric-algos"><name>Symmetric-Key Algorithms</name> <td align="right">7</td>
<td align="left">Reserved</td>
<td align="left"> </td>
<td align="left"> </td>
<texttable title="OpenPGP Symmetric Key Algorithms registry" anchor="symkey-algo </tr>
rithms-registry"> <tr>
<ttcol align='right'>ID</ttcol> <td align="right">8</td>
<ttcol align='left'>Algorithm</ttcol> <td align="left">SHA2-256 <xref target="FIPS180"/></td>
<c>0</c> <td align="left">"SHA256"</td>
<c>Plaintext or unencrypted data</c> <td align="left">16</td>
<c>1</c>
<c>IDEA <xref target="IDEA"/></c>
<c>2</c>
<c>TripleDES (DES-EDE, <xref target="SP800-67"/> - 168 bit key derived fro
m 192)</c>
<c>3</c>
<c>CAST5 (128 bit key, as per <xref target="RFC2144"/>)</c>
<c>4</c>
<c>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 with 128-bit key <xref target="AES"/></c>
<c>8</c>
<c>AES with 192-bit key</c>
<c>9</c>
<c>AES with 256-bit key</c>
<c>10</c>
<c>Twofish with 256-bit key <xref target="TWOFISH"/></c>
<c>11</c>
<c>Camellia with 128-bit key <xref target="RFC3713"/></c>
<c>12</c>
<c>Camellia with 192-bit key</c>
<c>13</c>
<c>Camellia with 256-bit key</c>
<c>100 to 110</c>
<c>Private/Experimental algorithm</c>
<c>253, 254 and 255</c>
<c>Reserved to avoid collision with Secret Key Encryption (see <xref targe
t="secret-key-protection-registry"/> and <xref target="secret-key-packet-formats
"/>)</c>
</texttable>
<t>Implementations <bcp14>MUST</bcp14> implement AES-128. </tr>
Implementations <bcp14>SHOULD</bcp14> implement AES-256. <tr>
Implementations <bcp14>MUST NOT</bcp14> encrypt data with IDEA, TripleDES, or CA <td align="right">9</td>
ST5. <td align="left">SHA2-384 <xref target="FIPS180"/></td>
Implementations <bcp14>MAY</bcp14> decrypt data that uses IDEA, TripleDES, or CA <td align="left">"SHA384"</td>
ST5 for the sake of reading older messages or new messages from implementations <td align="left">24</td>
predating support for <xref target="RFC2440"/>.
An Implementation that decrypts data using IDEA, TripleDES, or CAST5 <bcp14>SHOU
LD</bcp14> generate a deprecation warning about the symmetric algorithm, indicat
ing that message confidentiality is suspect.
Implementations <bcp14>MAY</bcp14> implement any other algorithm.</t>
</section> </tr>
<section anchor="compression-algos"><name>Compression Algorithms</name> <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>
<texttable title="OpenPGP Compression Algorithms registry" anchor="compression-a </tr>
lgorithms-registry"> <tr>
<ttcol align='right'>ID</ttcol> <td align="right">11</td>
<ttcol align='left'>Algorithm</ttcol> <td align="left">SHA2-224 <xref target="FIPS180"/></td>
<c>0</c> <td align="left">"SHA224"</td>
<c>Uncompressed</c> <td align="left">16</td>
<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>
<t>Implementations <bcp14>MUST</bcp14> implement uncompressed data. </tr>
Implementations <bcp14>SHOULD</bcp14> implement ZLIB. <tr>
For interoperability reasons implementations <bcp14>SHOULD</bcp14> be able to de <td align="right">12</td>
compress using ZIP. <td align="left">SHA3-256 <xref target="FIPS202"/></td>
Implementations <bcp14>MAY</bcp14> implement any other algorithm.</t> <td align="left">"SHA3-256"</td>
<td align="left">16</td>
</section> </tr>
<section anchor="hash-algos"><name>Hash Algorithms</name> <tr>
<td align="right">13</td>
<td align="left">Reserved</td>
<td align="left"> </td>
<td align="left"> </td>
<texttable title="OpenPGP Hash Algorithms registry" anchor="hash-algorithms-regi </tr>
stry"> <tr>
<ttcol align='right'>ID</ttcol> <td align="right">14</td>
<ttcol align='left'>Algorithm</ttcol> <td align="left">SHA3-512 <xref target="FIPS202"/></td>
<ttcol align='left'>Text Name</ttcol> <td align="left">"SHA3-512"</td>
<ttcol align='left'>V6 signature salt size</ttcol> <td align="left">32</td>
<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>&#160;</c>
<c>&#160;</c>
<c>5</c>
<c>Reserved</c>
<c>&#160;</c>
<c>&#160;</c>
<c>6</c>
<c>Reserved</c>
<c>&#160;</c>
<c>&#160;</c>
<c>7</c>
<c>Reserved</c>
<c>&#160;</c>
<c>&#160;</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>&#160;</c>
<c>&#160;</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>&#160;</c>
<c>&#160;</c>
</texttable>
<texttable title="OpenPGP Hash Algorithm Identifiers for RSA Signatures use of E </tr>
MSA-PKCS1-v1_5 Padding registry" anchor="emsa-hash-oids-registry"> <tr>
<ttcol align='left'>Hash Algorithm</ttcol> <td align="right">100-110</td>
<ttcol align='left'>OID</ttcol> <td align="left">Private or Experimental Use</td>
<ttcol align='left'>Full hash prefix</ttcol> <td align="left"> </td>
<c>MD5</c> <td align="left"> </td>
<c>1.2.840.113549.2.5</c>
<c>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, 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, 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, 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, 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, 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, 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, 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, 0x51, 0x30, 0x0D, 0x06, 0x09, 0x60, 0x86, 0x48, 0x01, 0x65, 0x03,
0x04, 0x02, 0x0a, 0x05, 0x00, 0x04, 0x40</c>
</texttable>
<t>Implementations <bcp14>MUST</bcp14> implement SHA2-256. </tr>
</tbody>
</table>
<table anchor="emsa-hash-oids-registry">
<name>OpenPGP Hash Algorithm Identifiers for RSA Signatures' Use of EM
SA&nbhy;PKCS1&nbhy;v1_5 Padding 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, 0
x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, 0x05, 0x00, 0x04, 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, 0
x03, 0x02, 0x1A, 0x05, 0x00, 0x04, 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, 0
x03, 0x02, 0x01, 0x05, 0x00, 0x04, 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, 0
x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, 0x05, 0x00, 0x04, 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, 0
x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x02, 0x05, 0x00, 0x04, 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, 0
x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x03, 0x05, 0x00, 0x04, 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, 0
x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x04, 0x05, 0x00, 0x04, 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, 0
x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x08, 0x05, 0x00, 0x04, 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, 0
x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x0a, 0x05, 0x00, 0x04, 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>SHOULD</bcp14> implement SHA2-384 and SHA2-512.
Implementations <bcp14>MAY</bcp14> implement other algorithms. Implementations <bcp14>MAY</bcp14> implement other algorithms.
Implementations <bcp14>SHOULD NOT</bcp14> create messages which require the use of SHA-1 with the exception of computing version 4 key fingerprints and for purp oses of the Modification Detection Code (MDC) in version 1 Symmetrically Encrypt ed Integrity Protected Data packets. Implementations <bcp14>SHOULD NOT</bcp14> create messages that require the use o f SHA-1, with the exception of computing version 4 key fingerprints for purposes of the MDC in version 1 Symmetrically Encrypted Integrity Protected Data packet s.
Implementations <bcp14>MUST NOT</bcp14> generate signatures with MD5, SHA-1, or RIPEMD-160. 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> 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 RI PEMD-160 as a hash function in an S2K KDF. Implementations <bcp14>MUST NOT</bcp14> generate packets using MD5, SHA-1, or RI PEMD-160 as a hash function in an S2K KDF.
Implementations <bcp14>MUST NOT</bcp14> decrypt a secret using MD5, SHA-1, or RI PEMD-160 as a hash function in an S2K KDF in a version 6 (or later) packet. Implementations <bcp14>MUST NOT</bcp14> decrypt a secret using MD5, SHA-1, or RI PEMD-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 depen ds on MD5, SHA-1, or RIPEMD-160. Implementations <bcp14>MUST NOT</bcp14> validate any recent signature that depen ds on MD5, SHA-1, or RIPEMD-160.
Implementations <bcp14>SHOULD NOT</bcp14> validate any old signature that depend s on MD5, SHA-1, or RIPEMD-160 unless the signature's creation date predates kno wn 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> Implementations <bcp14>SHOULD NOT</bcp14> validate any old signature that depend s on MD5, SHA-1, or RIPEMD-160 unless the signature's creation date predates kno wn 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 Algorithms</name>
<table anchor="aead-algorithms-registry">
<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>
</section> </tr>
<section anchor="aead-algorithms"><name>AEAD Algorithms</name> </thead>
<tbody>
<tr>
<td align="right">0</td>
<td align="left">Reserved</td>
<td align="left"></td>
<td align="left"></td>
<texttable title="OpenPGP AEAD Algorithms registry" anchor="aead-algorithms-regi </tr>
stry"> <tr>
<ttcol align='right'>ID</ttcol> <td align="right">1</td>
<ttcol align='left'>Name</ttcol> <td align="left">EAX <xref target="EAX"/></td>
<ttcol align='left'>Reference</ttcol> <td align="left">16</td>
<ttcol align='left'>Nonce length (octets)</ttcol> <td align="left">16</td>
<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>&#160;</c>
<c>&#160;</c>
<c>&#160;</c>
</texttable>
<t>Implementations <bcp14>MUST</bcp14> implement OCB. </tr>
Implementations <bcp14>MAY</bcp14> implement EAX, GCM and other algorithms.</t> <tr>
<td align="right">2</td>
<td align="left">OCB <xref target="RFC7253"/></td>
<td align="left">15</td>
<td align="left">16</td>
</section> </tr>
</section> <tr>
<section anchor="packet-sequence-composition"><name>Packet Sequence Composition< <td align="right">3</td>
/name> <td align="left">GCM <xref target="SP800-38D"/></td>
<td align="left">12</td>
<td align="left">16</td>
<t>OpenPGP packets are assembled into sequences in order to create messages and </tr>
to transfer keys. <tr>
<td align="right">100-110</td>
<td align="left">Private or Experimental Use</td>
<td align="left"> </td>
<td align="left"> </td>
</tr>
</tbody>
</table>
<t>Implementations <bcp14>MUST</bcp14> implement OCB. Implementations <b
cp14>MAY</bcp14> implement EAX, GCM, and other algorithms.</t>
</section>
</section>
<section anchor="packet-sequence-composition">
<name>Packet Sequence Composition</name>
<t>OpenPGP packets are assembled into sequences in order to create message
s and to transfer keys.
Not all possible packet sequences are meaningful and correct. Not all possible packet sequences are meaningful and correct.
This section describes the rules for how packets should be placed into sequences .</t> This section describes the rules for how packets should be placed into sequences .</t>
<t>There are three distinct sequences of packets:</t>
<t>There are three distinct sequences of packets:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>Transferable Public Keys (<xref target="transferable-public-keys"/>
<t>Transferable Public Keys (<xref target="transferable-public-keys"/>) and th ) and their close counterpart, Transferable Secret Keys (<xref target="transfera
eir close counterpart, Transferable Secret Keys (<xref target="transferable-secr ble-secret-keys"/>)</t>
et-keys"/>)</t> </li>
<t>OpenPGP Messages (<xref target="openpgp-messages"/>)</t> <li>
<t>Detached Signatures (<xref target="detached-signatures"/>)</t> <t>OpenPGP Messages (<xref target="openpgp-messages"/>)</t>
</list></t> </li>
<li>
<t>Each sequence has an explicit grammar of what packet types (<xref target="pac <t>Detached Signatures (<xref target="detached-signatures"/>)</t>
ket-types-registry"/>) can appear in what place. </li>
The presence of an unknown critical packet, or a known but unexpected packet is </ul>
a critical error, invalidating the entire sequence (see <xref target="packet-cri <t>Each sequence has an explicit grammar of what packet types (<xref targe
ticality"/>). t="packet-types-registry"/>) can appear in what place. The presence of an unknow
On the other hand, unknown non-critical packets can appear anywhere within any s n critical packet, or a known but unexpected packet, is a critical error, invali
equence. dating the entire sequence (see <xref target="packet-criticality"/>).
This provides a structured way to introduce new packets into the protocol, while On the other hand, unknown non-critical packets can appear anywhere within any s
making sure that certain packets will be handled strictly.</t> equence. This provides a structured way to introduce new packets into OpenPGP, w
hile making sure that certain packets will be handled strictly.</t>
<t>An implementation may "recognize" a packet, but not implement it. <t>An implementation may "recognize" a 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> 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 that previous versions of this document did not have a concept of
<t>Note that previous versions of this document did not have a concept of Packet Packet Criticality and did not give clear guidance on what to do when unknown pa
Criticality, and did not give clear guidance on what to do when unknown packets ckets are encountered. Therefore, implementations of the previous versions may r
are encountered. eject unknown non-critical packets or accept unknown critical packets.</t>
Therefore, implementations of older versions of this document may reject unknown <t>When generating a sequence of OpenPGP packets according to one of the t
non-critical packets, or accept unknown critical packets.</t> hree grammars, an implementation <bcp14>MUST NOT</bcp14> inject a critical packe
t of a type that does not adhere to the grammar.</t>
<t>When generating a sequence of OpenPGP packets according to one of the three g <t>When consuming a sequence of OpenPGP packets, if an implementation enco
rammars, an implementation <bcp14>MUST NOT</bcp14> inject a critical packet of a unters a critical packet of an inappropriate type according to the relevant gram
type that does not adhere to the grammar.</t> mar, the implementation <bcp14>MUST</bcp14> reject the sequence with an error.</
t>
<t>When consuming a sequence of OpenPGP packets according to one of the three gr <section anchor="transferable-public-keys">
ammars, an implementation <bcp14>MUST</bcp14> reject the sequence with an error <name>Transferable Public Keys</name>
if it encounters a critical packet of inappropriate type according to the gramma <t>OpenPGP users may transfer public keys.
r.</t>
<section 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 interop erability. This section describes the structure of public keys in transit to ensure interop erability.
An OpenPGP Transferable Public Key is also known as an OpenPGP certificate, in o An OpenPGP Transferable Public Key is also known as an OpenPGP certificate, in o
rder to distinguish it from both its constituent Public-Key packets (<xref targe rder to distinguish it from both its constituent Public-Key packets (Sections <x
t="pubkey"/> and <xref target="pubsubkey"/>) and the underlying cryptographic ke ref target="pubkey" format="counter"/> and <xref target="pubsubkey" format="coun
y material.</t> ter"/>) and the underlying cryptographic key material.</t>
<section anchor="v6-certificate-structures">
<section anchor="v6-certificate-structures"><name>OpenPGP v6 Certificate Structu <name>OpenPGP v6 Certificate Structure</name>
re</name> <t>The format of an OpenPGP v6 certificate is as follows.
<t>The format of an OpenPGP v6 certificate is as follows.
Entries in square brackets are optional and ellipses indicate repetition.</t> Entries in square brackets are optional and ellipses indicate repetition.</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
Primary Key Primary Key
[Revocation Signature...] [Revocation Signature...]
Direct Key Signature... Direct Key Signature...
[User ID or User Attribute [User ID or User Attribute
[Certification Revocation Signature...] [Certification Revocation Signature...]
[Certification Signature...]]... [Certification Signature...]]...
[Subkey [Subkey Revocation Signature...] [Subkey [Subkey Revocation Signature...]
Subkey Binding Signature...]... Subkey Binding Signature...]...
[Padding] [Padding]
]]></artwork></figure> ]]></artwork>
<t>In addition to these rules, a marker packet (<xref target="marker-p
<t>In addition to these rules, a marker packet (<xref target="marker-packet"/>) acket"/>) can appear anywhere in the sequence.</t>
can appear anywhere in the sequence.</t> <t>Note that a v6 key uses a self-signed direct key signature to store
algorithm preferences.</t>
<t>Note, that a v6 key uses a self-signed direct key signature to store algorith <t>Every subkey for a v6 primary key <bcp14>MUST</bcp14> be a v6 subke
m preferences.</t> y.
<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 <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). 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</bc p14> be a v6 signature.</t> Like all other signatures, every self-signature made by a v6 key <bcp14>MUST</bc p14> be a v6 signature.</t>
</section>
</section> <section anchor="v6-revocation-certificate">
<section anchor="v6-revocation-certificate"><name>OpenPGP v6 Revocation Certific <name>OpenPGP v6 Revocation Certificate</name>
ate</name> <t>When a primary v6 Public Key is revoked, it is sometimes distribute
d with only the revocation signature:</t>
<t>When a primary v6 Public Key is revoked, it is sometimes distributed with onl <artwork><![CDATA[
y the revocation signature:</t>
<figure><artwork><![CDATA[
Primary Key Primary Key
Revocation Signature Revocation Signature
]]></artwork></figure> ]]></artwork>
<t>In this case, the direct key signature is no longer necessary, sinc
<t>In this case, the direct key signature is no longer necessary, since the prim e the primary key itself has been marked as unusable.</t>
ary key itself has been marked as unusable.</t> </section>
<section anchor="openpgp-v4-certificate-structure">
</section> <name>OpenPGP v4 Certificate Structure</name>
<section anchor="openpgp-v4-certificate-structure"><name>OpenPGP v4 Certificate <t>The format of an OpenPGP v4 key is as follows.</t>
Structure</name> <artwork><![CDATA[
<t>The format of an OpenPGP v4 key is as follows.</t>
<figure><artwork><![CDATA[
Primary Key Primary Key
[Revocation Signature] [Revocation Signature]
[Direct Key Signature...] [Direct Key Signature...]
[User ID or User Attribute [Signature...]]... [User ID or User Attribute [Signature...]]...
[Subkey [Subkey Revocation Signature...] [Subkey [Subkey Revocation Signature...]
Subkey Binding Signature...]... Subkey Binding Signature...]...
]]></artwork></figure> ]]></artwork>
<t>In addition to these rules, a marker packet (<xref target="marker-p
<t>In addition to these rules, a marker packet (<xref target="marker-packet"/>) acket"/>) can appear anywhere in the sequence.</t>
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
<t>A subkey always has at least one subkey binding signature after it that is is signatures may be in either v3 or v4 format, but they <bcp14>SHOULD</bcp14> be
sued using the primary key to tie the two keys together. in v4 format.
These binding signatures may be in either v3 or v4 format, but <bcp14>SHOULD</bc
p14> be in v4 format.
Subkeys that can issue signatures <bcp14>MUST</bcp14> have a v4 binding signatur e due to the <bcp14>REQUIRED</bcp14> embedded primary key binding signature.</t> Subkeys that can issue signatures <bcp14>MUST</bcp14> have a v4 binding signatur e 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 subke
<t>Every subkey for a v4 primary key <bcp14>MUST</bcp14> be a v4 subkey.</t> y.</t>
<t>When a primary v4 Public Key is revoked, the revocation signature i
<t>When a primary v4 Public Key is revoked, the revocation signature is sometime s sometimes distributed by itself, without the primary key packet it applies to.
s distributed by itself, without the primary key packet it applies to. This is r This is referred to as a "revocation certificate".
eferred 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> Instead, a v6 revocation certificate <bcp14>MUST</bcp14> include the primary key packet, as described in <xref target="v6-revocation-certificate"/>.</t>
</section>
</section> <section anchor="openpgp-v3-key-structure">
<section anchor="openpgp-v3-key-structure"><name>OpenPGP v3 Key Structure</name> <name>OpenPGP v3 Key Structure</name>
<t>The format of an OpenPGP v3 key is as follows.</t>
<t>The format of an OpenPGP v3 key is as follows.</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
RSA Public Key RSA Public Key
[Revocation Signature] [Revocation Signature]
User ID [Signature...] User ID [Signature...]
[User ID [Signature...]]... [User ID [Signature...]]...
]]></artwork></figure> ]]></artwork>
<t>In addition to these rules, a marker packet (<xref target="marker-p
<t>In addition to these rules, a marker packet (<xref target="marker-packet"/>) acket"/>) can appear anywhere in the sequence.</t>
can appear anywhere in the sequence.</t> <t>Each signature certifies the RSA public key and the preceding User
ID.
<t>Each signature certifies the RSA public key and the preceding User ID. The RSA public key can have many User IDs, and each User ID can have many signat
The RSA public key can have many User IDs and each User ID can have many signatu ures.
res. V3 keys are deprecated. Implementations <bcp14>MUST NOT</bcp14> generate new v3
V3 keys are deprecated. keys but <bcp14>MAY</bcp14> continue to use existing ones.</t>
Implementations <bcp14>MUST NOT</bcp14> generate new v3 keys, but <bcp14>MAY</bc <t>V3 keys <bcp14>MUST NOT</bcp14> have subkeys.</t>
p14> continue to use existing ones.</t> </section>
<section anchor="common-requirements">
<t>V3 keys <bcp14>MUST NOT</bcp14> have subkeys.</t> <name>Common Requirements</name>
<t>The Public-Key packet occurs first.</t>
</section> <t>The primary key <bcp14>MUST</bcp14> be an algorithm capable of maki
<section anchor="common-requirements"><name>Common requirements</name> ng signatures (that is, not an encryption-only algorithm). This is because the p
rimary key needs to be able to create self-signatures (see <xref target="self-si
<t>The Public-Key packet occurs first.</t> gs"/>).
The subkeys may be keys of any type. For example, there may be a single-key RSA
<t>The primary key <bcp14>MUST</bcp14> be an algorithm capable of making signatu key, an Ed25519 primary key with an RSA encryption subkey, an Ed25519 primary ke
res (that is, not an encryption-only algorithm). y with an X25519 subkey, etc.</t>
This is because the primary key needs to be able to create self-signatures (see <t>Each of the following User ID packets provides the identity of the
<xref target="self-sigs"/>). owner of this public key.
The subkeys may be keys of any type. If there are multiple User ID packets, this corresponds to multiple means of ide
For example, there may be a single-key RSA key, an Ed25519 primary key with an R ntifying the same unique individual user; for example, a user may have more than
SA encryption subkey, or an Ed25519 primary key with an X25519 subkey, etc.</t> one email address and construct a User ID for each one.
<t>Each of the following User ID packets provides the identity of the owner of t
his public key.
If there are multiple User ID packets, this corresponds to multiple means of ide
ntifying the same unique individual user; for example, a user may have more than
one email address, and construct a User ID for each one.
A transferable public key <bcp14>SHOULD</bcp14> include at least one User ID pac ket unless storage requirements prohibit this.</t> A transferable public key <bcp14>SHOULD</bcp14> include at least one User ID pac ket unless storage requirements prohibit this.</t>
<t>Immediately following each User ID packet, there are zero or more S
<t>Immediately following each User ID packet, there are zero or more Signature p ignature packets.
ackets. Each Signature packet is calculated on the immediately preceding User ID packet
Each Signature packet is calculated on the immediately preceding User ID packet and the initial Public-Key packet. The signature serves to certify the correspon
and the initial Public-Key packet. ding public key and User ID. In effect, the signer is testifying to the belief t
The signature serves to certify the corresponding public key and User ID. hat this public key belongs to the user identified by this User ID.</t>
In effect, the signer is testifying to his or her belief that this public key be <t>Within the same section as the User ID packets, there are zero or m
longs to the user identified by this User ID.</t> ore User Attribute packets. Like the User ID packets, a User Attribute packet is
followed by zero or more Signature packets calculated on the immediately preced
<t>Within the same section as the User ID packets, there are zero or more User A ing User Attribute packet and the initial Public-Key packet.</t>
ttribute packets. <t>User Attribute packets and User ID packets may be freely intermixed
Like the User ID packets, a User Attribute packet is followed by zero or more Si in this section, as long as the signatures that follow them are maintained on t
gnature packets calculated on the immediately preceding User Attribute packet an he proper User Attribute or User ID packet.</t>
d the initial Public-Key packet.</t> <t>After the sequence of User ID packets and Attribute packets and the
ir associated signatures, zero or more Subkey packets follow, each with their ow
<t>User Attribute packets and User ID packets may be freely intermixed in this s n signatures. In general, subkeys are provided in cases where the top-level publ
ection, so long as the signatures that follow them are maintained on the proper ic key is a certification-only key.
User Attribute or User ID packet.</t>
<t>After the sequence of User ID packets and Attribute packets and their associa
ted signatures, zero or more Subkey packets follow, each with their own signatur
es.
In general, subkeys are provided in cases where the top-level public key is a ce
rtification-only key.
However, any v4 or v6 key may have subkeys, and the subkeys may be encryption ke ys, signing keys, authentication keys, etc. However, any v4 or v6 key may have subkeys, and the subkeys may be encryption ke ys, signing keys, authentication keys, etc.
It is good practice to use separate subkeys for every operation (i.e. signature- It is good practice to use separate subkeys for every operation (i.e., signature
only, encryption-only, authentication-only keys, etc.).</t> -only, encryption-only, authentication-only keys, etc.).</t>
<t>Each Subkey packet <bcp14>MUST</bcp14> be followed by one Signature
<t>Each Subkey packet <bcp14>MUST</bcp14> be followed by one Signature packet, w packet, which should be a subkey binding signature issued by the top-level key.
hich 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 signa ture (0x19) issued by the subkey on the top-level key.</t> For subkeys that can issue signatures, the subkey binding signature <bcp14>MUST< /bcp14> contain an Embedded Signature subpacket with a primary key binding signa ture (0x19) issued by the subkey on the top-level key.</t>
<t>Subkey and Key packets may each be followed by a revocation Signatu
<t>Subkey and Key packets may each be followed by a revocation Signature packet re packet to indicate that the key is revoked.
to indicate that the key is revoked. Revocation signatures are only accepted if they are issued by the key itself or
Revocation signatures are only accepted if they are issued by the key itself, or by a key that is authorized to issue revocations via a Revocation Key subpacket
by a key that is authorized to issue revocations via a Revocation Key subpacket in a self-signature by the top-level key.</t>
in a self-signature by the top-level key.</t> <t>The optional trailing Padding packet is a mechanism to defend again
st traffic analysis (see <xref target="traffic-analysis"/>).
<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 in dicated that they are capable of ignoring it successfully. 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 in dicated 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> 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 all
<t>Transferable public-key packet sequences may be concatenated to allow transfe ow transferring multiple public keys in one operation (see <xref target="keyring
rring multiple public keys in one operation (see <xref target="keyrings"/>).</t> s"/>).</t>
</section>
</section> </section>
</section> <section anchor="transferable-secret-keys">
<section anchor="transferable-secret-keys"><name>Transferable Secret Keys</name> <name>Transferable Secret Keys</name>
<t>OpenPGP users may transfer secret keys.
<t>OpenPGP users may transfer secret keys. The format of a transferable secret key is the same as a transferable pub
The format of a transferable secret key is the same as a transferable public key lic key except that Secret-Key and Secret-Subkey packets can be used in addition
except that Secret-Key and Secret-Subkey packets can be used in addition to the to the Public-Key and Public-Subkey packets. If a single Secret-Key or Secret-S
Public-Key and Public-Subkey packets. ubkey packet is included in a packet sequence, it is a transferable secret key a
If a single Secret-Key or Secret-Subkey packet is included in a packet sequence, nd should be handled and marked as such (see <xref target="armor-header-line"/>)
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
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 extrac
and subkeys, as this allows for a complete public key to be automatically extrac ted from the transferable secret key. An implementation <bcp14>MAY</bcp14> choos
ted from the transferable secret key. e to omit the self-signatures, especially if a transferable public key accompani
An implementation <bcp14>MAY</bcp14> choose to omit the self-signatures, especia es the transferable secret key.</t>
lly if a transferable public key accompanies the transferable secret key.</t> </section>
<section anchor="openpgp-messages">
</section> <name>OpenPGP Messages</name>
<section anchor="openpgp-messages"><name>OpenPGP Messages</name> <t>An OpenPGP message is a packet or sequence of packets that adheres to
the following grammatical rules (a comma (,) represents sequential composition,
<t>An OpenPGP message is a packet or sequence of packets that corresponds to the and a vertical bar (|) separates alternatives):</t>
following grammatical rules (comma (,) represents sequential composition, and v <dl>
ertical bar (|) separates alternatives):</t> <dt>OpenPGP Message:</dt>
<dd>
<dl> <t>Encrypted Message | Signed Message | Compressed Message | Literal
<dt>OpenPGP Message :-</dt> Message.</t>
<dd> </dd>
<t>Encrypted Message | Signed Message | Compressed Message | Literal Message <dt>Compressed Message:</dt>
.</t> <dd>
</dd> <t>Compressed Data Packet.</t>
<dt>Compressed Message :-</dt> </dd>
<dd> <dt>Literal Message:</dt>
<t>Compressed Data Packet.</t> <dd>
</dd> <t>Literal Data Packet.</t>
<dt>Literal Message :-</dt> </dd>
<dd> <dt>ESK:</dt>
<t>Literal Data Packet.</t> <dd>
</dd> <t>Public-Key Encrypted Session Key Packet | Symmetric-Key Encrypted
<dt>ESK :-</dt> Session Key Packet.</t>
<dd> </dd>
<t>Public-Key Encrypted Session Key Packet | Symmetric-Key Encrypted Session <dt>ESK Sequence:</dt>
Key Packet.</t> <dd>
</dd> <t>ESK | ESK Sequence, ESK.</t>
<dt>ESK Sequence :-</dt> </dd>
<dd> <dt>Encrypted Data:</dt>
<t>ESK | ESK Sequence, ESK.</t> <dd>
</dd> <t>Symmetrically Encrypted Data Packet | Symmetrically Encrypted Int
<dt>Encrypted Data :-</dt> egrity Protected Data Packet.</t>
<dd> </dd>
<t>Symmetrically Encrypted Data Packet | Symmetrically Encrypted Integrity P <dt>Encrypted Message:</dt>
rotected Data Packet</t> <dd>
</dd> <t>Encrypted Data | ESK Sequence, Encrypted Data.</t>
<dt>Encrypted Message :-</dt> </dd>
<dd> <dt>One-Pass Signed Message:</dt>
<t>Encrypted Data | ESK Sequence, Encrypted Data.</t> <dd>
</dd> <t>One-Pass Signature Packet, OpenPGP Message, Corresponding Signatu
<dt>One-Pass Signed Message :-</dt> re Packet.</t>
<dd> </dd>
<t>One-Pass Signature Packet, OpenPGP Message, Corresponding Signature Packe <dt>Signed Message:</dt>
t.</t> <dd>
</dd> <t>Signature Packet, OpenPGP Message | One-Pass Signed Message.</t>
<dt>Signed Message :-</dt> </dd>
<dd> <dt>Optionally Padded Message:</dt>
<t>Signature Packet, OpenPGP Message | One-Pass Signed Message.</t> <dd>
</dd> <t>OpenPGP Message | OpenPGP Message, Padding Packet.</t>
<dt>Optionally Padded Message :-</dt> </dd>
<dd> </dl>
<t>OpenPGP Message | OpenPGP Message, Padding Packet.</t> <t>In addition to these rules, a marker packet (<xref target="marker-pac
</dd> ket"/>) can appear anywhere in the sequence.</t>
</dl> <section anchor="unwrapping">
<name>Unwrapping Encrypted and Compressed Messages</name>
<t>In addition to these rules, a marker packet (<xref target="marker-packet"/>) <t>In addition to the above grammar, certain messages can be "unwrappe
can appear anywhere in the sequence.</t> d" to yield new messages.
<section anchor="unwrapping"><name>Unwrapping Encrypted and Compressed Messages<
/name>
<t>In addition to the above grammar, certain messages can be "unwrapped" to yiel
d new messages.
In particular:</t> In particular:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>Decrypting a version 2 Symmetrically Encrypted and Integrity Protected Data <t>Decrypting a version 2 Symmetrically Encrypted and Integrity Pr
packet <bcp14>MUST</bcp14> yield a valid Optionally Padded Message.</t> otected Data packet <bcp14>MUST</bcp14> yield a valid Optionally Padded Message.
<t>Decrypting a version 1 Symmetrically Encrypted and Integrity Protected Data </t>
packet or --- for historic data --- a Symmetrically Encrypted Data packet <bcp1 </li>
4>MUST</bcp14> yield a valid OpenPGP Message.</t> <li>
<t>Decompressing a Compressed Data packet <bcp14>MUST</bcp14> also yield a val <t>Decrypting a version 1 Symmetrically Encrypted and Integrity Pr
id OpenPGP Message.</t> otected Data packet or -- for historic data -- a Symmetrically Encrypted Data pa
</list></t> cket <bcp14>MUST</bcp14> yield a valid OpenPGP Message.</t>
</li>
<t>When any unwrapping is performed, the resulting stream of octets is parsed in <li>
to a series of OpenPGP packets like any other stream of octets. <t>Decompressing a Compressed Data packet <bcp14>MUST</bcp14> also
yield a valid OpenPGP Message.</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 t he length of the unwrapped octet stream. The packet boundaries found in the series of octets are expected to align with t he 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. 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 w ould extend beyond the boundaries of the unwrapped octet stream, the implementat ion <bcp14>MUST</bcp14> reject that packet as malformed and unusable.</t> If an implementation encounters a packet whose header length indicates that it w ould extend beyond the boundaries of the unwrapped octet stream, the implementat ion <bcp14>MUST</bcp14> reject that packet as malformed and unusable.</t>
</section>
</section> <section anchor="additional-constraints-on-packet-sequences">
<section anchor="additional-constraints-on-packet-sequences"><name>Additional Co <name>Additional Constraints on Packet Sequences</name>
nstraints on Packet Sequences</name> <t>Note that some subtle combinations that are formally acceptable by
this grammar are nonetheless unacceptable.</t>
<t>Note that some subtle combinations that are formally acceptable by this gramm <section anchor="encrypted-message-versions">
ar are nonetheless unacceptable.</t> <name>Packet Versions in Encrypted Messages</name>
<t>As noted above, an Encrypted Message is a sequence of zero or mor
<section anchor="encrypted-message-versions"><name>Packet Versions in Encrypted e PKESK packets (<xref target="pkesk"/>) and SKESK packets (<xref target="skesk"
Messages</name> />), followed by an SEIPD (<xref target="seipd"/>) payload. In some historic dat
a, the payload may be a deprecated SED packet (<xref target="sed"/>) instead of
<t>As noted above, an Encrypted Message is a sequence of zero or more PKESKs (<x SEIPD, though implementations <bcp14>MUST NOT</bcp14> generate SED packets (see
ref target="pkesk"/>) and SKESKs (<xref target="skesk"/>), followed by an SEIPD <xref target="ciphertext-malleability"/>).
(<xref target="seipd"/>) payload.
In some historic data, the payload may be a deprecated SED (<xref target="sed"/>
) packet instead of SEIPD, though implementations <bcp14>MUST NOT</bcp14> genera
te SED packets (see <xref target="ciphertext-malleability"/>).
The versions of the preceding ESK packets within an Encrypted Message <bcp14>MUS T</bcp14> align with the version of the payload SEIPD packet, as described in th is section.</t> The versions of the preceding ESK packets within an Encrypted Message <bcp14>MUS T</bcp14> align with the version of the payload SEIPD packet, as described in th is section.</t>
<t>v3 PKESK and v4 SKESK packets both contain the symmetric cipher a
<t>v3 PKESK and v4 SKESK packets both contain in their cleartext the symmetric c lgorithm ID and the session key for the subsequent SEIPD packet in their clearte
ipher algorithm ID in addition to the session key for the subsequent SEIPD packe xt.
t.
Since a v1 SEIPD does not contain a symmetric algorithm ID, all ESK packets prec eding a v1 SEIPD payload <bcp14>MUST</bcp14> be either v3 PKESK or v4 SKESK.</t> Since a v1 SEIPD does not contain a symmetric algorithm ID, all ESK packets prec eding 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 PK
<t>On the other hand, the cleartext of the v6 ESK packets (either PKESK or SKESK ESK or SKESK) do not contain a symmetric cipher algorithm ID, so they cannot be
) do not contain a symmetric cipher algorithm ID, so they cannot be used in comb used in combination with a v1 SEIPD payload.
ination with a v1 SEIPD payload.
The payload following any v6 PKESK or v6 SKESK packet <bcp14>MUST</bcp14> be a v 2 SEIPD.</t> The payload following any v6 PKESK or v6 SKESK packet <bcp14>MUST</bcp14> be a v 2 SEIPD.</t>
<t>Additionally, to avoid potentially conflicting cipher algorithm I
<t>Additionally, to avoid potentially conflicting cipher algorithm IDs, and for Ds, and for simplicity, implementations <bcp14>MUST NOT</bcp14> precede a v2 SEI
simplicity, implementations <bcp14>MUST NOT</bcp14> precede a v2 SEIPD payload w PD payload with either v3 PKESK or v4 SKESK packets.</t>
ith either v3 PKESK or v4 SKESK packets.</t> <t>The versions of packets found in an Encrypted Message are summari
zed in the following table.
<t>The versions of packets found in an Encrypted Message are summarized in the f
ollowing table.
An implementation <bcp14>MUST</bcp14> only generate an Encrypted Message using p acket versions that match a row with "Yes" in the "Generate?" column. An implementation <bcp14>MUST</bcp14> only generate an Encrypted Message using p acket versions that match a row with "Yes" in the "Generate?" column.
Other rows are provided for the purpose of historic interoperability. Other rows are provided for the purpose of historic interoperability.
A conforming implementation <bcp14>MUST</bcp14> only generate an Encrypted Messa ge using packets whose versions correspond to a single row.</t> A conforming implementation <bcp14>MUST</bcp14> only generate an Encrypted Messa ge using packets whose versions correspond to a single row.</t>
<table anchor="encrypted-packet-versions-registry">
<texttable title="OpenPGP Encrypted Message Packet Versions registry" anchor="en <name>OpenPGP Encrypted Message Packet Versions Registry</name>
crypted-packet-versions-registry"> <thead>
<ttcol align='left'>Version of Encrypted Data payload</ttcol> <tr>
<ttcol align='left'>Version of preceding Symmetric-Key ESK (if any)</ttcol <th align="left">Version of Encrypted Data Payload</th>
> <th align="left">Version of Preceding Symmetric-Key ESK (If An
<ttcol align='left'>Version of preceding Public-Key ESK (if any)</ttcol> y)</th>
<ttcol align='left'>Generate?</ttcol> <th align="left">Version of Preceding Public-Key ESK (If Any)<
<c>SED (<xref target="sed"/>)</c> /th>
<c>-</c> <th align="left">Generate?</th>
<c>v2 PKESK (<xref target="RFC2440"/>)</c> </tr>
<c>No</c> </thead>
<c>SED (<xref target="sed"/>)</c> <tbody>
<c>v4 SKESK (<xref target="v4-skesk"/>)</c> <tr>
<c>v3 PKESK (<xref target="v3-pkesk"/>)</c> <td align="left">SED (<xref target="sed"/>)</td>
<c>No</c> <td align="left">-</td>
<c>v1 SEIPD (<xref target="version-one-seipd"/>)</c> <td align="left">v2 PKESK <xref target="RFC2440"/></td>
<c>v4 SKESK (<xref target="v4-skesk"/>)</c> <td align="left">No</td>
<c>v3 PKESK (<xref target="v3-pkesk"/>)</c> </tr>
<c>Yes</c> <tr>
<c>v2 SEIPD (<xref target="version-two-seipd"/>)</c> <td align="left">SED (<xref target="sed"/>)</td>
<c>v6 SKESK (<xref target="v6-skesk"/>)</c> <td align="left">v4 SKESK (<xref target="v4-skesk"/>)</td>
<c>v6 PKESK (<xref target="v6-pkesk"/>)</c> <td align="left">v3 PKESK (<xref target="v3-pkesk"/>)</td>
<c>Yes</c> <td align="left">No</td>
</texttable> </tr>
<tr>
<t>An implementation processing an Encrypted Message <bcp14>MUST</bcp14> discard <td align="left">v1 SEIPD (<xref target="version-one-seipd"/>)
any preceding ESK packet with a version that does not align with the version of </td>
the payload.</t> <td align="left">v4 SKESK (<xref target="v4-skesk"/>)</td>
<td align="left">v3 PKESK (<xref target="v3-pkesk"/>)</td>
</section> <td align="left">Yes</td>
<section anchor="signed-message-versions"><name>Packet Versions in Signatures</n </tr>
ame> <tr>
<td align="left">v2 SEIPD (<xref target="version-two-seipd"/>)
<t>OpenPGP key packets and signature packets are also versioned. </td>
<td align="left">v6 SKESK (<xref target="v6-skesk"/>)</td>
<td align="left">v6 PKESK (<xref target="v6-pkesk"/>)</td>
<td align="left">Yes</td>
</tr>
</tbody>
</table>
<t>An implementation processing an Encrypted Message <bcp14>MUST</bc
p14> discard any preceding ESK packet with a version that does not align with th
e version of the payload.</t>
</section>
<section 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. 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 vers ion 6 signature packet, regardless of the signature packet type. When a v6 key produces a signature packet, it <bcp14>MUST</bcp14> produce a vers ion 6 signature packet, regardless of the signature packet type.
When a message is signed or verified using the one-pass construction, the versio n of the One-Pass Signature packet (<xref target="one-pass-sig"/>) should also b e aligned to the other versions.</t> When a message is signed or verified using the one-pass construction, the versio n of the One-Pass Signature packet (<xref target="one-pass-sig"/>) should also b e aligned to the other versions.</t>
<t>Some legacy implementations have produced unaligned signature ver
<t>Some legacy implementations have produced unaligned signature versions for ol sions for older key material, which are also described in the table below for th
der key material, which are also described in the table below for purpose of his e purpose of historic interoperability.
toric interoperability.
A conforming implementation <bcp14>MUST</bcp14> only generate signature packets with version numbers matching rows with "Yes" in the "Generate?" column.</t> A conforming implementation <bcp14>MUST</bcp14> only generate signature packets with version numbers matching rows with "Yes" in the "Generate?" column.</t>
<table anchor="signed-packet-versions-registry">
<texttable title="OpenPGP Key and Signature Versions registry" anchor="signed-pa <name>OpenPGP Key and Signature Versions Registry</name>
cket-versions-registry"> <thead>
<ttcol align='left'>Signing key version</ttcol> <tr>
<ttcol align='left'>Signature packet version</ttcol> <th align="left">Signing Key Version</th>
<ttcol align='left'>OPS packet version</ttcol> <th align="left">Signature Packet Version</th>
<ttcol align='left'>Generate?</ttcol> <th align="left">OPS Packet Version</th>
<c>3 (<xref target="v3-pubkeys"/>)</c> <th align="left">Generate?</th>
<c>3 (<xref target="version-three-sig"/>)</c> </tr>
<c>3 <xref target="one-pass-sig"/></c> </thead>
<c>No</c> <tbody>
<c>4 (<xref target="v4-pubkeys"/>)</c> <tr>
<c>3 (<xref target="version-three-sig"/>)</c> <td align="left">3 (<xref target="v3-pubkeys"/>)</td>
<c>3 <xref target="one-pass-sig"/></c> <td align="left">3 (<xref target="version-three-sig"/>)</td>
<c>No</c> <td align="left">3 (<xref target="one-pass-sig"/>)</td>
<c>4 (<xref target="v4-pubkeys"/>)</c> <td align="left">No</td>
<c>4 (<xref target="version-four-and-six-sig"/>)</c> </tr>
<c>3 <xref target="one-pass-sig"/></c> <tr>
<c>Yes</c> <td align="left">4 (<xref target="v4-pubkeys"/>)</td>
<c>6 (<xref target="v6-pubkeys"/>)</c> <td align="left">3 (<xref target="version-three-sig"/>)</td>
<c>6 (<xref target="version-four-and-six-sig"/>)</c> <td align="left">3 (<xref target="one-pass-sig"/>)</td>
<c>6 <xref target="one-pass-sig"/></c> <td align="left">No</td>
<c>Yes</c> </tr>
</texttable> <tr>
<td align="left">4 (<xref target="v4-pubkeys"/>)</td>
<t>Note, however, that a version mismatch between these packets does not invalid <td align="left">4 (<xref target="version-four-and-six-sig"/>)
ate the packet sequence as a whole, it merely invalidates the signature, as a si </td>
gnature with an unknown version <bcp14>SHOULD</bcp14> be discarded (see <xref ta <td align="left">3 (<xref target="one-pass-sig"/>)</td>
rget="malformed-signatures"/>).</t> <td align="left">Yes</td>
</tr>
</section> <tr>
</section> <td align="left">6 (<xref target="v6-pubkeys"/>)</td>
</section> <td align="left">6 (<xref target="version-four-and-six-sig"/>)
<section anchor="detached-signatures"><name>Detached Signatures</name> </td>
<td align="left">6 (<xref target="one-pass-sig"/>)</td>
<t>Some OpenPGP applications use so-called "detached signatures". <td align="left">Yes</td>
For example, a program bundle may contain a file, and with it a second file that </tr>
is a detached signature of the first file. </tbody>
These detached signatures are simply one or more Signature packets stored separa </table>
tely from the data for which they are a signature.</t> <t>Note, however, that a version mismatch between these packets does
not invalidate the packet sequence as a whole; it merely invalidates the signat
<t>In addition, a marker packet (<xref target="marker-packet"/>) and a padding p ure, as a signature with an unknown version <bcp14>SHOULD</bcp14> be discarded (
acket (<xref target="padding-packet"/>) can appear anywhere in the sequence.</t> see <xref target="malformed-signatures"/>).</t>
</section>
</section> </section>
</section> </section>
<section anchor="elliptic-curve-cryptography"><name>Elliptic Curve Cryptography< <section anchor="detached-signatures">
/name> <name>Detached Signatures</name>
<t>Some OpenPGP applications use so-called "detached signatures".
<t>This section describes algorithms and parameters used with Elliptic Curve Cry For example, a program bundle may contain a file, and with it a second file that
ptography (ECC) keys. is a detached signature of the first file. These detached signatures are simply
A thorough introduction to ECC can be found in <xref target="KOBLITZ"/>.</t> one or more Signature packets stored separately from the data for which they ar
e a signature.</t>
<t>None of the ECC methods described in this document are allowed with deprecate <t>In addition, a marker packet (<xref target="marker-packet"/>) and a p
d v3 keys. adding packet (<xref target="padding-packet"/>) can appear anywhere in the seque
Refer to <xref target="FIPS186"/>, B.4.1, for the method to generate a uniformly nce.</t>
distributed ECC private key.</t> </section>
</section>
<section anchor="ecc-curves"><name>ECC Curves</name> <section anchor="elliptic-curve-cryptography">
<name>Elliptic Curve Cryptography</name>
<t>This document references three named prime field curves defined in <xref targ <t>This section describes algorithms and parameters used with Elliptic Cur
et="FIPS186"/> as "Curve P-256", "Curve P-384", and "Curve P-521"; and three nam ve Cryptography (ECC) keys. A thorough introduction to ECC can be found in <xref
ed prime field curves defined in <xref target="RFC5639"/> as "brainpoolP256r1", target="KOBLITZ"/>. Refer to <xref target="FIPS186"/>, Appendix B.4, for the me
"brainpoolP384r1", and "brainpoolP512r1". thods to generate a uniformly distributed ECC private key.</t>
The three <xref target="FIPS186"/> curves and the three <xref target="RFC5639"/> <t>None of the ECC methods described in this document are allowed with dep
curves can be used with ECDSA and ECDH public key algorithms. recated v3 keys. </t>
They are referenced using a sequence of octets, referred to as the curve OID. <section anchor="ecc-curves">
<xref target="ec-curves"/> describes in detail how this sequence of octets is fo <name>ECC Curves</name>
rmed.</t> <t>This document references three named prime field curves defined in <x
ref target="FIPS186"/> as "Curve P-256", "Curve P-384", and "Curve P-521" and th
<t>Separate algorithms are also defined for the use of X25519 and X448, defined ree named prime field curves defined in <xref target="RFC5639"/> as "brainpoolP2
in <xref target="RFC7748"/>; and Ed25519 and Ed448, defined in <xref target="RFC 56r1", "brainpoolP384r1", and "brainpoolP512r1". All six curves can be used with
8032"/>. ECDSA and ECDH public key algorithms. They are referenced using a sequence of o
ctets, referred to as the curve OID. <xref target="ec-curves"/> describes in det
ail how this sequence of octets is formed.</t>
<t>Separate algorithms are also defined for the use of X25519 and X448 <
xref target="RFC7748"/> and Ed25519 and Ed448 <xref target="RFC8032"/>.
Additionally, legacy OIDs are defined for "Curve25519Legacy" (for encryption usi ng the ECDH algorithm) and "Ed25519Legacy" (for signing using the EdDSALegacy al gorithm).</t> Additionally, legacy OIDs are defined for "Curve25519Legacy" (for encryption usi ng the ECDH algorithm) and "Ed25519Legacy" (for signing using the EdDSALegacy al gorithm).</t>
</section>
</section> <section anchor="ec-point-wire-formats">
<section anchor="ec-point-wire-formats"><name>EC Point Wire Formats</name> <name>EC Point Wire Formats</name>
<t>A point on an elliptic curve will always be represented on the wire a
<t>A point on an elliptic curve will always be represented on the wire as an MPI s an MPI.
.
Each curve uses a specific point format for the data within the MPI itself. 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> 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>
<table anchor="ec-point-wire-formats-registry">
<texttable title="OpenPGP Elliptic Curve Point Wire Formats registry" anchor="ec <name>OpenPGP Elliptic Curve Point Wire Formats Registry</name>
-point-wire-formats-registry"> <thead>
<ttcol align='right'>Name</ttcol> <tr>
<ttcol align='left'>Wire Format</ttcol> <th align="right">Name</th>
<ttcol align='left'>Reference</ttcol> <th align="left">Wire Format</th>
<c>SEC1</c> <th align="left">Reference</th>
<c>0x04 || x || y</c> </tr>
<c><xref target="ec-point-sec1"/></c> </thead>
<c>Prefixed native</c> <tbody>
<c>0x40 || native</c> <tr>
<c><xref target="ec-point-prefixed-native"/></c> <td align="right">SEC1</td>
</texttable> <td align="left">0x04 || x || y</td>
<td align="left">
<section anchor="ec-point-sec1"><name>SEC1 EC Point Wire Format</name> <xref target="ec-point-sec1"/></td>
</tr>
<t>For a SEC1-encoded (uncompressed) point the content of the MPI is:</t> <tr>
<td align="right">Prefixed native</td>
<figure><artwork><![CDATA[ <td align="left">0x40 || native</td>
<td align="left">
<xref target="ec-point-prefixed-native"/></td>
</tr>
</tbody>
</table>
<section anchor="ec-point-sec1">
<name>SEC1 EC Point Wire Format</name>
<t>For a SEC1-encoded (uncompressed) point, the content of the MPI is:
</t>
<artwork><![CDATA[
B = 04 || x || y B = 04 || x || y
]]></artwork></figure> ]]></artwork>
<t>where x and y are coordinates of the point P = (x, y), and each is
<t>where x and y are coordinates of the point P = (x, y), and each is encoded in encoded in the big-endian format and zero-padded to the adjusted underlying fiel
the big-endian format and zero-padded to the adjusted underlying field size. d size.
The adjusted underlying field size is the underlying field size rounded up to th e nearest 8-bit boundary, as noted in the "fsize" column in <xref target="ec-cur ves"/>. The adjusted underlying field size is the underlying field size rounded up to th e nearest 8-bit boundary, as noted in the "fsize" column in <xref target="ec-cur ves"/>.
This encoding is compatible with the definition given in <xref target="SEC1"/>.< /t> This encoding is compatible with the definition given in <xref target="SEC1"/>.< /t>
</section>
</section> <section anchor="ec-point-prefixed-native">
<section anchor="ec-point-prefixed-native"><name>Prefixed Native EC Point Wire F <name>Prefixed Native EC Point Wire Format</name>
ormat</name> <t>For a custom compressed point, the content of the MPI is:</t>
<artwork><![CDATA[
<t>For a custom compressed point the content of the MPI is:</t>
<figure><artwork><![CDATA[
B = 40 || p B = 40 || p
]]></artwork></figure> ]]></artwork>
<t>where p is the public key of the point encoded using the rules defi
<t>where p is the public key of the point encoded using the rules defined for th ned for the specified curve.
e specified curve. This format is used for ECDH keys based on curves expressed in Montgomery form a
This format is used for ECDH keys based on curves expressed in Montgomery form, nd for points when using EdDSA.</t>
and for points when using EdDSA.</t> </section>
<section anchor="notes-on-ec-point-wire-formats">
</section> <name>Notes on EC Point Wire Formats</name>
<section anchor="notes-on-ec-point-wire-formats"><name>Notes on EC Point Wire Fo <t>Given the above definitions, the exact size of the MPI payload for
rmats</name> an encoded point is 515 bits for both NIST P-256 and brainpoolP256r1, 771 for bo
th NIST P-384 and brainpoolP384r1, 1059 for NIST P-521, 1027 for brainpoolP512r1
<t>Given the above definitions, the exact size of the MPI payload for an encoded , and 263 for both Curve25519Legacy and Ed25519Legacy. For example, the length o
point is 515 bits for both NIST P-256 and brainpoolP256r1, 771 for both NIST P- f an EdDSALegacy public key for the curve Ed25519Legacy is 263 bits: 7 bits to r
384 and brainpoolP384r1, 1059 for NIST P-521, 1027 for brainpoolP512r1, and 263 epresent the 0x40 prefix octet and 32 octets for the native value of the public
for both Curve25519Legacy and Ed25519Legacy. key.</t>
For example, the length of a EdDSALegacy public key for the curve Ed25519Legacy <t>Even though the zero point (also called the "point at infinity") ma
is 263 bits: 7 bits to represent the 0x40 prefix octet and 32 octets for the nat y occur as a result of arithmetic operations on points of an elliptic curve, it
ive value of the public key.</t> <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 f
<t>Even though the zero point, also called the point at infinity, may occur as a ound in its public key or ECDH data structure.
result of arithmetic operations on points of an elliptic curve, it <bcp14>SHALL An implementation <bcp14>MUST NOT</bcp14> use a different wire format for a poin
NOT</bcp14> appear in data structures defined in this document.</t> t other than the wire format associated with the curve.</t>
</section>
<t>Each particular curve uses a designated wire format for the point found in it </section>
s public key or ECDH data structure. <section anchor="ec-scalar-wire-formats">
An implementation <bcp14>MUST NOT</bcp14> use a different wire format for a poin <name>EC Scalar Wire Formats</name>
t than the wire format associated with the curve.</t> <t>Some non-curve values in elliptic curve cryptography (for example, se
cret keys and signature components) are not points on a curve, but they are also
</section> encoded on the wire in OpenPGP as an MPI.</t>
</section> <t>Because of different patterns of deployment, some curves treat these
<section anchor="ec-scalar-wire-formats"><name>EC Scalar Wire Formats</name> 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.
<t>Some non-curve values in elliptic curve cryptography (for example, secret key The choice of encoding is specific to the public key algorithm in use.</t
s and signature components) are not points on a curve, but are also encoded on t >
he wire in OpenPGP as an MPI.</t> <table anchor="ec-scalar-wire-formats-registry">
<name>OpenPGP Elliptic Curve Scalar Encodings Registry</name>
<t>Because of different patterns of deployment, some curves treat these values a <thead>
s opaque bit strings with the high bit set, while others are treated as actual i <tr>
ntegers, encoded in the standard OpenPGP big-endian form. <th align="left">Type</th>
The choice of encoding is specific to the public key algorithm in use.</t> <th align="left">Description</th>
<th align="left">Reference</th>
<texttable title="OpenPGP Elliptic Curve Scalar Encodings registry" anchor="ec-s </tr>
calar-wire-formats-registry"> </thead>
<ttcol align='left'>Type</ttcol> <tbody>
<ttcol align='left'>Description</ttcol> <tr>
<ttcol align='left'>Reference</ttcol> <td align="left">integer</td>
<c>integer</c> <td align="left">An integer encoded in big-endian format as a stan
<c>An integer, big-endian encoded as a standard OpenPGP MPI</c> dard OpenPGP MPI</td>
<c><xref target="mpi"/></c> <td align="left">
<c>octet string</c> <xref target="mpi"/></td>
<c>An octet string of fixed length, that may be shorter on the wire due to </tr>
leading zeros being stripped by the MPI encoding, and may need to be zero-padde <tr>
d before use</c> <td align="left">octet string</td>
<c><xref target="ec-octet-string"/></c> <td align="left">An octet string of fixed length that may be short
<c>prefixed N octets</c> er on the wire due to leading zeros being stripped by the MPI encoding and may n
<c>An octet string of fixed length N, prefixed with octet 0x40 to ensure n eed to be zero-padded before use</td>
o leading zero octet</c> <td align="left">
<c><xref target="ec-prefix"/></c> <xref target="ec-octet-string"/></td>
</texttable> </tr>
<tr>
<section anchor="ec-octet-string"><name>EC Octet String Wire Format</name> <td align="left">prefixed N octets</td>
<td align="left">An octet string of fixed length N, prefixed with
<t>Some opaque strings of octets are represented on the wire as an MPI by simply octet 0x40 to ensure no leading zero octet</td>
stripping the leading zeros and counting the remaining bits. <td align="left">
<xref target="ec-prefix"/></td>
</tr>
</tbody>
</table>
<section 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. These strings are of known, fixed length.
They are represented in this document as <spanx style="verb">MPI(N octets of X)< They are represented in this document as <tt>MPI(N octets of X)</tt>, where <tt>
/spanx> where <spanx style="verb">N</spanx> is the expected length in octets of N</tt> is the expected length in octets of the octet string.</t>
the octet string.</t> <t>For example, a five-octet opaque string (<tt>MPI(5 octets of X)</tt
>) where <tt>X</tt> has the value <tt>00 02 EE 19 00</tt> would be represented o
<t>For example, a five-octet opaque string (<spanx style="verb">MPI(5 octets of n the wire as an MPI like so: <tt>00 1A 02 EE 19 00</tt>.</t>
X)</spanx>) where <spanx style="verb">X</spanx> has the value <spanx style="verb <t>To encode <tt>X</tt> to the wire format, set the MPI's two-octet bi
">00 02 EE 19 00</spanx> would be represented on the wire as an MPI like so: <sp t counter to the value of the highest set bit (bit 26, or 0x001A), and do not tr
anx style="verb">00 1A 02 EE 19 00</spanx>.</t> ansfer the leading all-zero octet to the wire.</t>
<t>To reverse the process, an implementation can take the following st
<t>To encode <spanx style="verb">X</spanx> to the wire format, we set the MPI's eps, if it knows that X has an expected lenth of, for example, 5 octets:</t>
two-octet bit counter to the value of the highest set bit (bit 26, or 0x001A), a <ul spacing="normal">
nd do not transfer the leading all-zero octet to the wire.</t> <li>
<t>Ensure that the MPI's two-octet bit count is less than or equal
<t>To reverse the process, an implementation that knows this value has an expect to 40 (5 octets of 8 bits)</t>
ed length of 5 octets can take the following steps:</t> </li>
<li>
<t><list style="symbols"> <t>Allocate 5 octets, setting all to zero initially</t>
<t>Ensure that the MPI's two-octet bitcount is less than or equal to 40 (5 oct </li>
ets of 8 bits)</t> <li>
<t>Allocate 5 octets, setting all to zero initially</t> <t>Copy the MPI data octets (without the two count octets) into th
<t>Copy the MPI data octets (without the two count octets) into the lower octe e lower octets of the allocated space</t>
ts of the allocated space</t> </li>
</list></t> </ul>
</section>
</section> <section anchor="ec-prefix">
<section anchor="ec-prefix"><name>Elliptic Curve Prefixed Octet String Wire Form <name>EC Prefixed Octet String Wire Format</name>
at</name> <t>Another way to ensure that a fixed-length bytes string is encoded s
imply to the wire while remaining in MPI format is to prefix the byte string wit
<t>Another way to ensure that a fixed-length bytestring is encoded simply to the h a dedicated non-zero octet.
wire while remaining in MPI format is to prefix the bytestring with a dedicated
non-zero octet.
This specification uses 0x40 as the prefix octet. This specification uses 0x40 as the prefix octet.
This is represented in this standard as <spanx style="verb">MPI(prefixed N octet This is represented in this specification as <tt>MPI(prefixed N octets of X)</tt
s of X)</spanx>, where <spanx style="verb">N</spanx> is the known bytestring len >, where <tt>N</tt> is the known byte string length.</t>
gth.</t> <t>For example, a five-octet opaque string using <tt>MPI(prefixed 5 oc
tets of X)</tt> where <tt>X</tt> has the value <tt>00 02 EE 19 00</tt> would be
<t>For example, a five-octet opaque string using <spanx style="verb">MPI(prefixe written to the wire form as: <tt>00 2F 40 00 02 EE 19 00</tt>.</t>
d 5 octets of X)</spanx> where <spanx style="verb">X</spanx> has the value <span <t>To encode the string, prefix it with the octet 0x40 (whose 7th bit
x style="verb">00 02 EE 19 00</spanx> would be written to the wire form as: <spa is set), and then set the MPI's two-octet bit counter to 47 (0x002F -- 7 bits fo
nx style="verb">00 2F 40 00 02 EE 19 00</spanx>.</t> r the prefix octet and 40 bits for the string).</t>
<t>To decode the string from the wire, an implementation that knows th
<t>To encode the string, we prefix it with the octet 0x40 (whose 7th bit is set) at the variable is formed in this way can:</t>
, then set the MPI's two-octet bit counter to 47 (0x002F, 7 bits for the prefix <ul spacing="normal">
octet and 40 bits for the string).</t> <li>
<t>ensure that the first three octets of the MPI (the two-bit coun
<t>To decode the string from the wire, an implementation that knows that the var t octets plus the prefix octet) are <tt>00 2F 40</tt>, and</t>
iable is formed in this way can:</t> </li>
<li>
<t><list style="symbols"> <t>use the remainder of the MPI directly off the wire.</t>
<t>Ensure that the first three octets of the MPI (the two bit-count octets plu </li>
s the prefix octet) are <spanx style="verb">00 2F 40</spanx>, and</t> </ul>
<t>Use the remainder of the MPI directly off the wire.</t> <t>Note that this is a similar approach to that used in the EC point e
</list></t> ncodings found in <xref target="ec-point-prefixed-native"/>.</t>
</section>
<t>Note that this is a similar approach to that used in the EC point encodings f </section>
ound in <xref target="ec-point-prefixed-native"/>.</t> <section anchor="key-derivation-function">
<name>Key Derivation Function</name>
</section> <t>A key derivation function (KDF) is necessary to implement EC encrypti
</section> on.
<section 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> 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 w
<t>For convenience, the synopsis of the encoding method is given below with sign ith significant simplifications attributable to the restricted choice of hash fu
ificant simplifications attributable to the restricted choice of hash functions nctions in this document.
in this document.
However, <xref target="SP800-56A"/> is the normative source of the definition.</ t> However, <xref target="SP800-56A"/> is the normative source of the definition.</ t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
// Implements KDF( X, oBits, Param ); // Implements KDF( X, oBits, Param );
// Input: point X = (x,y) // Input: point X = (x,y)
// oBits - the desired size of output // oBits - the desired size of output
// hBits - the size of output of hash function Hash // hBits - the size of output of hash function Hash
// Param - octets representing the parameters // Param - octets representing the parameters
// Assumes that oBits <= hBits // Assumes that oBits <= hBits
// Convert the point X to the octet string: // Convert the point X to the octet string:
// ZB' = 04 || x || y // ZB' = 04 || x || y
// and extract the x portion from ZB' // and extract the x portion from ZB'
ZB = x; ZB = x;
MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param ); MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param );
return oBits leftmost bits of MB. return oBits leftmost bits of MB.
]]></artwork></figure> ]]></artwork>
<t>Note that ZB in the KDF description above is the compact representati
<t>Note that ZB in the KDF description above is the compact representation of X on of X as defined in <xref section="4.2" sectionFormat="of" target="RFC6090"/>.
as defined in <xref section="4.2" sectionFormat="of" target="RFC6090"/>.</t> </t>
</section>
</section> <section anchor="ecdh">
<section anchor="ecdh"><name>EC DH Algorithm (ECDH)</name> <name>ECDH Algorithm</name>
<t>This section describes the One-Pass Diffie-Hellman method, which is a
<t>The method is a combination of an ECC Diffie-Hellman method to establish a sh combination of the ECC Diffie-Hellman method that establishes a
ared secret, a key derivation method to process the shared secret into a derived shared secret and the key derivation method that processes the
key, and a key wrapping method that uses the derived key to protect a session k shared secret into a derived key. Additionally, this section
ey used to encrypt a message.</t> describes 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"/ <t>The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) <xref target="SP8
> <bcp14>MUST</bcp14> be implemented with the following restrictions: the ECC CD 00-56A"/> <bcp14>MUST</bcp14> be implemented with the following restrictions: th
H primitive employed by this method is modified to always assume the cofactor is e ECC Cofactor Diffie-Hellman (CDH) primitive employed by this method is modifie
1, the KDF specified in <xref target="key-derivation-function"/> is used, and t d to always assume the cofactor is 1, the KDF specified in <xref target="key-der
he KDF parameters specified below are used.</t> ivation-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 <t>The KDF parameters are encoded as a concatenation of the following 5
-length and fixed-length fields, which are compatible with the definition of the variable-length and fixed-length fields, which are compatible with the definitio
OtherInfo bitstring <xref target="SP800-56A"/>:</t> n of the OtherInfo bit string <xref target="SP800-56A"/>:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>A variable-length field containing a curve OID, which is formatted as follo <t>A variable-length field containing a curve OID, which is formatte
ws: <list style="symbols"> d as follows: </t>
<t>A one-octet size of the following field,</t> <ul spacing="normal">
<t>The octets representing a curve OID defined in <xref target="ec-curves" <li>
/>;</t> <t>A one-octet size of the following field.</t>
</list></t> </li>
<t>A one-octet public key algorithm ID defined in <xref target="pubkey-algos"/ <li>
>;</t> <t>The octets representing a curve OID, as defined in <xref targ
<t>A variable-length field containing KDF parameters, which are identical to t et="ec-curves"/>.</t>
he corresponding field in the ECDH public key, and are formatted as follows: <l </li>
ist style="symbols"> </ul>
<t>A one-octet size of the following fields; values 0 and 0xFF are reserve </li>
d for future extensions,</t> <li>
<t>A one-octet value 0x01, reserved for future extensions,</t> <t>A one-octet public key algorithm ID, as defined in <xref target="
<t>A one-octet hash function ID used with the KDF,</t> pubkey-algos"/>.</t>
<t>A one-octet algorithm ID for the symmetric algorithm used to wrap the s </li>
ymmetric key for message encryption; see <xref target="ecdh"/> for details;</t> <li>
</list></t> <t>A variable-length field containing KDF parameters, which are iden
<t>20 octets representing the UTF-8 encoding of the string <spanx style="verb" tical to the corresponding field in the ECDH public key and formatted as follows
>Anonymous Sender    </spanx>, which is the octet sequence 41 6E 6F 6E 79 6D 6F : </t>
75 73 20 53 65 6E 64 65 72 20 20 20 20;</t> <ul spacing="normal">
<t>A variable-length field containing the fingerprint of the recipient encrypt <li>
ion subkey identifying the key material that is needed for decryption. <t>A one-octet size of the following fields; values 0 and 0xFF a
re reserved for future extensions.</t>
</li>
<li>
<t>A one-octet value 0x01, reserved for future extensions.</t>
</li>
<li>
<t>A one-octet hash function ID used with the 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>
</li>
</ul>
</li>
<li>
<t>20 octets representing the UTF-8 encoding of the string "Anonymou
s Sender ", which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 6
4 65 72 20 20 20 20.</t>
</li>
<li>
<t>A variable-length field containing the fingerprint of the recipie
nt encryption subkey identifying the key material that is needed for decryption.
For version 4 keys, this field is 20 octets. For version 4 keys, this field is 20 octets.
For version 6 keys, this field is 32 octets.</t> For version 6 keys, this field is 32 octets.</t>
</list></t> </li>
</ul>
<t>The size in octets of the KDF parameters sequence, defined above, for encrypt <t>The size in octets of the KDF parameters sequence, as defined above,
ing to a v4 key is either 54 for curve NIST P-256, 51 for curves NIST P-384 and for encrypting to a v4 key is 54 for curve NIST P-256; 51 for curves NIST P-384
NIST P-521, 55 for curves brainpoolP256r1, brainpoolP384r1 and brainpoolP512r1, and NIST P-521; 55 for curves brainpoolP256r1, brainpoolP384r1, and brainpoolP51
or 56 for Curve25519Legacy. 2r1; or 56 for Curve25519Legacy. For encrypting to a v6 key, the size of the seq
For encrypting to a v6 key, the size of the sequence is either 66 for curve NIST uence is 66 for curve NIST P-256; 63 for curves NIST P-384 and NIST P-521; or 67
P-256, 63 for curves NIST P-384 and NIST P-521, or 67 for curves brainpoolP256r for curves brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1.</t>
1, 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 KEK as specified in <xref tar
<t>The key wrapping method is described in <xref target="RFC3394"/>. get="RFC3394"/>. Refer to <xref target="ecdh-parameters"/> for the details regar
The KDF produces a symmetric key that is used as a key-encryption key (KEK) as s ding the choice of the KEK algorithm, which <bcp14>SHOULD</bcp14> be one of the
pecified in <xref target="RFC3394"/>. three AES algorithms.
Refer to <xref target="ecdh-parameters"/> for the details regarding the choice o
f the KEK algorithm, which <bcp14>SHOULD</bcp14> be one of the three AES algorit
hms.
Key wrapping and unwrapping is performed with the default initial value of <xref target="RFC3394"/>.</t> 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 th
<t>To produce the input to the key wrapping method, first concatenate the follow e following values:</t>
ing values:</t> <ul spacing="normal">
<li>
<t><list style="symbols"> <t>The one-octet algorithm identifier, if it was passed (in the case
<t>The one-octet algorithm identifier, if it was passed (in the case of a v3 P of a v3 PKESK packet).</t>
KESK packet).</t> </li>
<t>The session key.</t> <li>
<t>A two-octet checksum of the session key, equal to the sum of the session ke <t>The session key.</t>
y octets, modulo 65536.</t> </li>
</list></t> <li>
<t>A two-octet checksum of the session key, equal to the sum of the
<t>Then, the above values are padded using the method described in <xref target= session key octets, modulo 65536.</t>
"RFC2898"/> to an 8-octet granularity.</t> </li>
</ul>
<t>For example, in a v3 Public-Key Encrypted Session Key packet, an AES-256 sess <t>Then, the above values are padded to an 8-octet granularity using the
ion key is encoded as follows, forming a 40 octet sequence:</t> method described in <xref target="RFC2898"/>.</t>
<t>For example, in a v3 Public-Key Encrypted Session Key packet, an AES-
<figure><artwork><![CDATA[ 256 session key is encoded as follows, forming a 40-octet sequence:</t>
<artwork><![CDATA[
09 k0 k1 ... k31 s0 s1 05 05 05 05 05 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
<t>The octets k0 to k31 above denote the session key, and the octets s0 and s1 d and s1 denote the checksum of the session key octets.
enote the checksum of the session key octets.
This encoding allows the sender to obfuscate the size of the symmetric encryptio n key used to encrypt the data. This encoding allows the sender to obfuscate the size of the symmetric encryptio n key used to encrypt the data.
For example, assuming that an AES algorithm is used for the session key, the sen der <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 a n input to the key wrapping method.</t> For example, assuming that an AES algorithm is used for the session key, the sen der <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 a n input to the key wrapping method.</t>
<t>In a v6 Public-Key Encrypted Session Key packet, the symmetric algori
<t>In a v6 Public-Key Encrypted Session Key packet, the symmetric algorithm is n thm is not included, as described in <xref target="pkesk"/>.
ot included, as described in <xref target="pkesk"/>.
For example, an AES-256 session key would be composed as follows:</t> For example, an AES-256 session key would be composed as follows:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
k0 k1 ... k31 s0 s1 06 06 06 06 06 06 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 octe
<t>The octets k0 to k31 above again denote the session key, and the octets s0 an ts s0 and s1 denote the checksum.
d s1 denote the checksum.
In this case, assuming that an AES algorithm is used for the session key, the se nder <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> In this case, assuming that an AES algorithm is used for the session key, the se nder <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.
<t>The output of the method consists of two fields.
The first field is the MPI containing the ephemeral key used to establish the sh ared secret. The first field is the MPI containing the ephemeral key used to establish the sh ared secret.
The second field is composed of the following two subfields:</t> The second field is composed of the following two subfields:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>One octet encoding the size in octets of the result of the key wrapping met <t>One octet encoding the size in octets of the result of the key wr
hod; the value 255 is reserved for future extensions;</t> apping method; the value 255 is reserved for future extensions.</t>
<t>Up to 254 octets representing the result of the key wrapping method, applie </li>
d to the 8-octet padded session key, as described above.</t> <li>
</list></t> <t>Up to 254 octets representing the result of the key wrapping meth
od, applied to the 8-octet padded session key, as described above.</t>
<t>Note that for session key sizes 128, 192, and 256 bits, the size of the resul </li>
t of the key wrapping method is, respectively, 32, 40, and 48 octets, unless siz </ul>
e obfuscation is used.</t> <t>Note that for session key sizes 128, 192, and 256 bits, the size of t
he result of the key wrapping method is, respectively, 32, 40, and 48 octets, un
<t>For convenience, the synopsis of the encoding method is given below; however, less size obfuscation is used.</t>
this section, <xref target="SP800-56A"/>, and <xref target="RFC3394"/> are the <t>For convenience, the synopsis of the encoding method is given below;
normative sources of the definition.</t> however, this section, <xref target="SP800-56A"/>, and <xref target="RFC3394"/>
are the normative sources of the definition.</t>
<t><list style="symbols"> <ul spacing="normal">
<t>Obtain the authenticated recipient public key R</t> <li>
<t>Generate an ephemeral, single-use key pair {v, V=vG}</t> <t>Obtain the authenticated recipient public key R</t>
<t>Compute the shared point S = vR;</t> </li>
<t>m = symm_alg_ID || session key || checksum || pkcs5_padding;</t> <li>
<t>curve_OID_len = (octet)len(curve_OID);</t> <t>Generate an ephemeral, single-use key pair {v, V=vG}</t>
<t>Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 || 01 || KDF_ </li>
hash_ID || KEK_alg_ID for AESKeyWrap || <spanx style="verb">Anonymous Sender     <li>
</spanx> || recipient_fingerprint;</t> <t>Compute the shared point S = vR</t>
<t>Z_len = the key size for the KEK_alg_ID used with AESKeyWrap</t> </li>
<t>Compute Z = KDF( S, Z_len, Param );</t> <li>
<t>Compute C = AESKeyWrap( Z, m ); (as per <xref target="RFC3394"/>)</t> <t>m = symm_alg_ID || session key || checksum || pkcs5_padding</t>
<t>Wipe the memory that contained S, v, and Z to avoid leaking ephemeral secre </li>
ts</t> <li>
<t>VB = convert point V to the octet string</t> <t>curve_OID_len = (octet)len(curve_OID)</t>
<t>Output (MPI(VB) || len(C) || C).</t> </li>
</list></t> <li>
<t>Param = curve_OID_len || curve_OID || public_key_alg_ID || 03 ||
<t>The decryption is the inverse of the method given. 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous Sender " || recipie
nt_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 ) (per <xref target="RFC3394"/>)</t>
</li>
<li>
<t>Wipe the memory that contained S, v, and Z to avoid leaking ephem
eral secrets</t>
</li>
<li>
<t>VB = convert point V to the octet string</t>
</li>
<li>
<t>Output (MPI(VB) || len(C) || C)</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 calcula ting:</t> Note that the recipient with key pair (r,R) obtains the shared secret by calcula ting:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
S = rV = rvG S = rV = rvG
]]></artwork></figure> ]]></artwork>
<section anchor="ecdh-parameters">
<section anchor="ecdh-parameters"><name>ECDH Parameters</name> <name>ECDH Parameters</name>
<t>ECDH keys have a hash algorithm parameter for key derivation and a
<t>ECDH keys have a hash algorithm parameter for key derivation and a symmetric symmetric algorithm for key encapsulation.</t>
algorithm for key encapsulation.</t> <t>For v6 keys, the following algorithms <bcp14>MUST</bcp14> be used d
epending on the curve.
<t>For v6 keys, the following algorithms <bcp14>MUST</bcp14> be used depending o
n 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> 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 o ver a listed curve that announces a different KDF or KEK parameter.</t> An implementation <bcp14>MUST NOT</bcp14> encrypt any message to a v6 ECDH key o ver a listed curve that announces a different KDF or KEK parameter.</t>
<t>For v4 keys, the following algorithms <bcp14>SHOULD</bcp14> be used
<t>For v4 keys, the following algorithms <bcp14>SHOULD</bcp14> be used depending depending on the curve.
on the curve.
An implementation <bcp14>SHOULD</bcp14> only use an AES algorithm as a KEK algor ithm.</t> An implementation <bcp14>SHOULD</bcp14> only use an AES algorithm as a KEK algor ithm.</t>
<table anchor="ecdh-kdf-kek-parameters-registry">
<name>OpenPGP ECDH KDF and KEK Parameters 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 on Algorithms</name>
<section anchor="pkcs-encoding">
<name>PKCS#1 Encoding in OpenPGP</name>
<t>This specification makes use of the PKCS#1 functions EME-PKCS1-v1_5 a
nd EMSA-PKCS1-v1_5. However, the calling conventions of these functions have cha
nged 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 ulti
mate authority on PKCS#1 for OpenPGP. Nonetheless, we believe that there is valu
e in having a self-contained document that avoids problems in the future with ne
eded changes in the conventions.</t>
<section anchor="eme-pkcs1-v1-5-encode">
<texttable title="OpenPGP ECDH KDF and KEK Parameters registry" anchor="ecdh-kdf <name>EME-PKCS1-v1_5-ENCODE</name>
-kek-parameters-registry"> <t>Input:</t>
<ttcol align='left'>Curve</ttcol> <dl>
<ttcol align='left'>Hash algorithm</ttcol> <dt>k =</dt>
<ttcol align='left'>Symmetric algorithm</ttcol> <dd>key modulus length in octets.
<c>NIST P-256</c> </dd>
<c>SHA2-256</c> <dt>M =</dt>
<c>AES-128</c> <dd>message to be encoded; an octet string of length mLen, where mLe
<c>NIST P-384</c> n &lt;= k - 11.
<c>SHA2-384</c> </dd>
<c>AES-192</c> </dl>
<c>NIST P-521</c> <t>Output:</t>
<c>SHA2-512</c> <dl>
<c>AES-256</c> <dt>EM =</dt>
<c>brainpoolP256r1</c> <dd>encoded message; an octet string of length k.
<c>SHA2-256</c> </dd>
<c>AES-128</c> </dl>
<c>brainpoolP384r1</c> <t>Error: "message too long".</t>
<c>SHA2-384</c> <ol spacing="normal" type="1"><li>
<c>AES-192</c> <t>Length checking: If mLen &gt; k - 11, output "message too long"
<c>brainpoolP512r1</c> and stop.</t>
<c>SHA2-512</c> </li>
<c>AES-256</c> <li>
<c>Curve25519Legacy</c> <t>Generate an octet string PS of length k - mLen - 3 consisting o
<c>SHA2-256</c> f pseudorandomly generated non-zero octets. The length of PS will be at least ei
<c>AES-128</c> ght octets.</t>
</texttable> </li>
<li>
</section> <t>Concatenate PS, the message M, and other padding to form an enc
</section> oded message EM of length k octets as </t>
</section> <artwork><![CDATA[
<section anchor="notes-on-algorithms"><name>Notes on Algorithms</name>
<section anchor="pkcs-encoding"><name>PKCS#1 Encoding in OpenPGP</name>
<t>This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and EMSA-PKCS1
-v1_5.
However, the calling conventions of these functions has changed in the past.
To avoid potential confusion and interoperability problems, we are including loc
al copies in this document, adapted from those in PKCS#1 v2.1 <xref target="RFC8
017"/>.
<xref target="RFC8017"/> should be treated as the ultimate authority on PKCS#1 f
or 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>
<t>Input:</t>
<dl>
<dt>k =</dt>
<dd>
<t>the length in octets of the key modulus.</t>
</dd>
<dt>M =</dt>
<dd>
<t>message to be encoded, an octet string of length mLen, where mLen &lt;= k
- 11.</t>
</dd>
</dl>
<t>Output:</t>
<dl>
<dt>EM =</dt>
<dd>
<t>encoded message, an octet string of length k.</t>
</dd>
</dl>
<t>Error: "message too long".</t>
<t><list style="numbers">
<t>Length checking: If mLen &gt; k - 11, output "message too long" and stop.</
t>
<t>Generate an octet string PS of length k - mLen - 3 consisting of pseudo-ran
domly generated nonzero octets.
The length of PS will be at least eight octets.</t>
<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[
EM = 0x00 || 0x02 || PS || 0x00 || M. EM = 0x00 || 0x02 || PS || 0x00 || M.
]]></artwork></figure> ]]></artwork>
</t> </li>
<t>Output EM.</t> <li>
</list></t> <t>Output EM.</t>
</li>
</section> </ol>
<section anchor="eme-pkcs1-v1-5-decode"><name>EME-PKCS1-v1_5-DECODE</name> </section>
<section anchor="eme-pkcs1-v1-5-decode">
<name>EME-PKCS1-v1_5-DECODE</name>
<t>Input:</t> <!-- #37 [rfced] Sections 12.1.2 and 12.1.3
<dl> b) Section 12.1.3. In the encoding method, "Hash" is followed
<dt>EM =</dt> by a dash whereas the other terms are followed by an equals sign.
<dd> Is this intentional, or can we update the dash to be an equals sign
<t>encoded message, an octet string</t> for consistency?
</dd>
</dl>
<t>Output:</t> Original:
Hash - a hash function in which hLen denotes the length in octets of
the hash function output.
<dl> Input:
<dt>M =</dt>
<dd>
<t>message, an octet string.</t>
</dd>
</dl>
<t>Error: "decryption error".</t> M = message to be encoded.
<t>To decode an EME-PKCS1_v1_5 message, separate the encoded message EM into an Perhaps:
octet string PS consisting of nonzero octets and a message M as follows</t> Hash = hash function in which hLen denotes the length of
the hash function output in octets.
<figure><artwork><![CDATA[ Input:
EM = 0x00 || 0x02 || PS || 0x00 || M.
]]></artwork></figure>
<t>If the first octet of EM does not have hexadecimal value 0x00, if the second M = message to be encoded.
octet of EM does not have hexadecimal value 0x02, if there is no octet with hexa
decimal 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 betwee
n a decryption error and a padding error.</t>
</section> [PH] I think it is "decoded message", but I am confused by the syntax as well, s
<section anchor="emsa-pkcs1-v1-5"><name>EMSA-PKCS1-v1_5</name> o I will
also like to hear from my co-authors here.
<t>This encoding method is deterministic and only has an encoding operation.</t> I think the entire line, including the preceding "Option:" line should be remove
d. The hLen variable
is not used anyway, and I think Hash() is obvious without this sentence. But let
my co-authors confirm this.
<t>Option:</t> [JW]
I think Paul is right here. Perhaps:
<dl> M = decoded message; an octet string.
<dt>Hash -</dt>
<dd>
<t>a hash function in which hLen denotes the length in octets of the hash fu
nction output.</t>
</dd>
</dl>
<t>Input:</t> I think this is a slightly shortened copy of the description in RFC3447,
which also contains the remark about hLen, which is likewise unused.
<dl> https://datatracker.ietf.org/doc/html/rfc3447#section-9.2
<dt>M =</dt>
<dd>
<t>message to be encoded.</t>
</dd>
<dt>emLen =</dt>
<dd>
<t>intended length in octets of the encoded message, at least tLen + 11, whe
re tLen is the octet length of the DER encoding T of a certain value computed du
ring the encoding operation.</t>
</dd>
</dl>
<t>Output:</t> I agree with Paul that removing the line (and the then empty "Option"
section) is fine.
<dl> ** NEEDS AD APPROVAL**
<dt>EM =</dt> -->
<dd>
<t>encoded message, an octet string of length emLen.</t>
</dd>
</dl>
<t>Errors: "message too long"; "intended encoded message length too short".</t> <t>Input:</t>
<dl>
<dt>EM =</dt>
<dd>
<t>encoded message; an octet string.</t>
</dd>
</dl>
<t>Output:</t>
<dl>
<dt>M =</dt>
<dd>
<t>decoded 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 E
M into an octet string PS consisting of non-zero octets and a message M as follo
ws</t>
<artwork><![CDATA[
EM = 0x00 || 0x02 || PS || 0x00 || M.
]]></artwork>
<t>If the first octet of EM does not have hexadecimal value 0x00, the
second octet of EM does not have hexadecimal value 0x02, there is no octet with
hexadecimal value 0x00 to separate PS from M, or 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>
<t>This encoding method is deterministic and only has an encoding oper
ation.</t>
<!-- AD approval needed - text removed per authors:
<t>Steps:</t> <t>Option:</t>
<dl>
<dt>Hash -</dt>
<dd>
<t>hash function in which hLen denotes the length in octets of the
hash function output.</t>
</dd>
</dl>-->
<t><list style="numbers"> <t>Input:</t>
<t>Apply the hash function to the message M to produce a hash value H: <vspac <dl>
e blankLines='1'/> <dt>M =</dt>
H = Hash(M). <vspace blankLines='1'/> <dd>
<t>message to be encoded.</t>
</dd>
<dt>emLen =</dt>
<dd>
<t>intended length of the encoded message in octets, at least tLen
+ 11, where tLen is the octet length of the DER encoding T of a certain value c
omputed during the encoding operation.</t>
</dd>
</dl>
<t>Output:</t>
<dl>
<dt>EM =</dt>
<dd>
<t>encoded message; an octet string of length emLen.</t>
</dd>
</dl>
<t>Errors: "message too long"; "intended encoded message length too sh
ort".</t>
<t>Steps:</t>
<ol spacing="normal" type="1"><li>
<t>Apply the hash function to the message M to produce hash value
H: </t>
<t>
H = Hash(M). </t>
<t>
If the hash function outputs "message too long," output "message too long" and s top.</t> If the hash function outputs "message too long," output "message too long" and s top.</t>
<t>Using the list in <xref target="hash-algos"/>, produce an ASN.1 DER value f </li>
or the hash function used. <li>
Let T be the full hash prefix from the list, and let tLen be the length in octet <t>Using the list in <xref target="hash-algos"/>, produce an ASN.1
s of T.</t> DER value for the hash function used.
<t>If emLen &lt; tLen + 11, output "intended encoded message length too short" Let T be the full hash prefix from the list, concatenated with the hash digest H
and stop.</t> , and let tLen be the length in octets of T.</t>
<t>Generate an octet string PS consisting of emLen - tLen - 3 octets with hexa </li>
decimal value 0xFF. <li>
<t>If emLen &lt; tLen + 11, output "intended encoded message lengt
h too short" and stop.</t>
</li>
<li>
<t>Generate an octet string PS consisting of emLen - tLen - 3 octe
ts with hexadecimal value 0xFF.
The length of PS will be at least 8 octets.</t> The length of PS will be at least 8 octets.</t>
<t>Concatenate PS, the hash prefix T, and other padding to form the encoded me </li>
ssage EM as <vspace blankLines='1'/> <li>
<figure><artwork><![CDATA[ <t>Concatenate PS, the hash prefix T, and other padding to form th
e encoded message EM as </t>
<artwork><![CDATA[
EM = 0x00 || 0x01 || PS || 0x00 || T. EM = 0x00 || 0x01 || PS || 0x00 || T.
]]></artwork></figure> ]]></artwork>
</t> </li>
<t>Output EM.</t> <li>
</list></t> <t>Output EM.</t>
</li>
</section> </ol>
</section> </section>
<section anchor="symmetric-algorithm-preferences"><name>Symmetric Algorithm Pref </section>
erences</name> <section anchor="symmetric-algorithm-preferences">
<name>Symmetric Algorithm Preferences</name>
<t>The symmetric algorithm preference is an ordered list of algorithms that the <t>The symmetric algorithm preference is an ordered list of algorithms t
keyholder accepts. hat the keyholder accepts.
Since it is found on a self-signature, it is possible that a keyholder may have Since it is found on a self-signature, it is possible that a keyholder may have
multiple, different preferences. multiple, different preferences. For example, Alice may have AES-128 only specif
For example, Alice may have AES-128 only specified for "alice@work.com" but Came ied for "alice@work.com" but Camellia-256, Twofish, and AES-128 specified for "a
llia-256, Twofish, and AES-128 specified for "alice@home.org". lice@home.org". Note that it is also possible for preferences to be in a subkey'
Note that it is also possible for preferences to be in a subkey's binding signat s binding signature.</t>
ure.</t> <t>Since AES-128 is the algorithm that <bcp14>MUST</bcp14> be implemente
d, if it is not explicitly in the list, it is tacitly at the end. However, it is
<t>Since AES-128 is the <bcp14>MUST</bcp14>-implement algorithm, if it is not ex good form to place it there explicitly.
plicitly in the list, it is tacitly at the end. Note also that if an implementation does not implement the preference, then it i
However, it is good form to place it there explicitly. s implicitly an AES-128-only implementation. Furthermore, note that implementati
Note also that if an implementation does not implement the preference, then it i ons conforming to the previous version of this specification <xref target="RFC48
s implicitly an AES-128-only implementation. 80"/> have TripleDES as the only algorithm that <bcp14>MUST</bcp14> be implement
Note further that implementations conforming to previous versions of this standa ed.</t>
rd <xref target="RFC4880"/> have TripleDES as its only <bcp14>MUST</bcp14>-imple <t>An implementation <bcp14>MUST NOT</bcp14> use a symmetric algorithm t
ment algorithm.</t> hat is not in the recipient's preference list. When encrypting to more than one
recipient, the implementation finds a suitable algorithm by taking the intersect
<t>An implementation <bcp14>MUST NOT</bcp14> use a symmetric algorithm that is n ion of the preferences of the recipients. Note that since the AES-128 algorithm
ot in the recipient's preference list. <bcp14>MUST</bcp14> be implemented, the intersection is guaranteed to be non-emp
When encrypting to more than one recipient, the implementation finds a suitable ty.</t>
algorithm by taking the intersection of the preferences of the recipients. <t>If an implementation can decrypt a message that a keyholder doesn't h
Note that the <bcp14>MUST</bcp14>-implement algorithm, AES-128, ensures that the ave in their preferences, the implementation <bcp14>SHOULD</bcp14> decrypt the m
intersection is non-empty. essage anyway, but it <bcp14>MUST</bcp14> warn the keyholder. For example, suppo
The implementation may use any mechanism to pick an algorithm in the intersectio se that Alice (above) has an implementation that implements all algorithms in th
n.</t> is specification. Nonetheless, she prefers subsets for work or home. If she is s
ent a message encrypted with IDEA, which is not in her preferences, the implemen
<t>If an implementation can decrypt a message that a keyholder doesn't have in t tation warns her that someone sent an IDEA-encrypted message, but it would ideal
heir preferences, the implementation <bcp14>SHOULD</bcp14> decrypt the message a ly decrypt it anyway.</t>
nyway, but <bcp14>MUST</bcp14> warn the keyholder that the protocol has been vio <section anchor="plaintext">
lated. <name>Plaintext</name>
For example, suppose that Alice, above, has an implementation that implements al <t>Algorithm 0, "plaintext", may only be used to denote secret keys th
l algorithms in this specification. at are stored in the clear.
Nonetheless, she prefers subsets for work or home. An implementation <bcp14>MUST NOT</bcp14> use algorithm 0 as the indicated symme
If she is sent a message encrypted with IDEA, which is not in her preferences, t tric cipher for an encrypted data packet (Sections <xref target="sed" format="co
he implementation warns her that someone sent her an IDEA-encrypted message, but unter"/> or <xref target="seipd" format="counter"/>); it can use a Literal Data
it would ideally decrypt it anyway.</t> packet (<xref target="lit"/>) to encode unencrypted literal data.</t>
</section>
<section anchor="plaintext"><name>Plaintext</name> </section>
<section anchor="other-algorithm-preferences">
<t>Algorithm 0, "plaintext", may only be used to denote secret keys that are sto <name>Other Algorithm Preferences</name>
red in the clear. <t>Other algorithm preferences work similarly to the symmetric algorithm
An implementation <bcp14>MUST NOT</bcp14> use algorithm 0 as the indicated symme preference in that they specify which algorithms the keyholder accepts. There a
tric cipher for an encrypted data packet (<xref target="sed"/> or <xref target=" re two interesting cases in which further comments are needed: the compression p
seipd"/>); it can use a Literal Data packet (<xref target="lit"/>) to encode une references and the hash preferences.</t>
ncrypted literal data.</t> <section anchor="compression-preferences">
<name>Compression Preferences</name>
</section> <t>Like the algorithm preferences, an implementation <bcp14>MUST NOT</
</section> bcp14> use an algorithm that is not in the preference vector.
<section anchor="other-algorithm-preferences"><name>Other Algorithm Preferences<
/name>
<t>Other algorithm preferences work similarly to the symmetric algorithm prefere
nce, in that they specify which algorithms the keyholder accepts.
There are two interesting cases that other comments need to be made about, thoug
h, the compression preferences and the hash preferences.</t>
<section 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. If Uncompressed (0) is not explicitly in the list, it is tacitly at the end.
That is, uncompressed messages may always be sent.</t> That is, uncompressed messages may always be sent.</t>
<t>Note that earlier implementations may assume that the absence of co
<t>Note that earlier implementations may assume that the absence of compression mpression preferences means that [ZIP(1), Uncompressed(0)] are preferred, and de
preferences means that [ZIP(1), Uncompressed(0)] are preferred, and default to Z fault to ZIP compression.
IP compression.
Therefore, an implementation that prefers uncompressed data <bcp14>SHOULD</bcp14 > explicitly state this in the preferred compression algorithms.</t> Therefore, an implementation that prefers uncompressed data <bcp14>SHOULD</bcp14 > explicitly state this in the preferred compression algorithms.</t>
<section anchor="uncompressed">
<section anchor="uncompressed"><name>Uncompressed</name> <name>Uncompressed</name>
<t>Algorithm 0, "uncompressed", may only be used to denote a prefere
<t>Algorithm 0, "uncompressed", may only be used to denote a preference for unco nce for uncompressed data.
mpressed data.
An implementation <bcp14>MUST NOT</bcp14> use algorithm 0 as the indicated compr ession 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> An implementation <bcp14>MUST NOT</bcp14> use algorithm 0 as the indicated compr ession 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>
</section> <section anchor="hash-algorithm-preferences">
<section anchor="hash-algorithm-preferences"><name>Hash Algorithm Preferences</n <name>Hash Algorithm Preferences</name>
ame> <t>Typically, the signer chooses which hash algorithm to use, rather t
han the verifier, because a signer rarely knows who is going to be verifying the
<t>Typically, the choice of a hash algorithm is something the signer does, rathe signature. This preference allows a protocol based upon digital signatures ease
r than the verifier, because a signer rarely knows who is going to be verifying in negotiation.</t>
the signature. <t>Thus, if Alice is authenticating herself to Bob with a signature, i
This preference, though, allows a protocol based upon digital signatures ease in t makes sense for her to use a hash algorithm that Bob's implementation uses. Th
negotiation.</t> is preference allows Bob to state which algorithms Alice may use in his key.</t>
<t>Since SHA2-256 is the hash algorithm that <bcp14>MUST</bcp14> be im
<t>Thus, if Alice is authenticating herself to Bob with a signature, it makes se plemented, if it is not explicitly in the list, it is tacitly at the end.
nse 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>
<t>Since SHA2-256 is the <bcp14>MUST</bcp14>-implement hash algorithm, 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> However, it is good form to place it there explicitly.</t>
</section>
</section> </section>
</section> <section anchor="rsa-notes">
<section anchor="rsa-notes"><name>RSA</name> <name>RSA</name>
<t>The PKCS1-v1_5 padding scheme, used by the RSA algorithms defined in
<t>The PKCS1-v1_5 padding scheme, used by the RSA algorithms defined in this doc this document, is no longer recommended, and its use is deprecated by <xref targ
ument, is no longer recommended, and its use is deprecated by <xref target="SP80 et="SP800-131A"/>.
0-131A"/>.
Therefore, an implementation <bcp14>SHOULD NOT</bcp14> generate RSA keys.</t> Therefore, an implementation <bcp14>SHOULD NOT</bcp14> generate RSA keys.</t>
<t>There are algorithm types for RSA Sign-Only and RSA Encrypt-Only keys
<t>There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only keys. . These types are deprecated in favor of the "key flags" signature subpacket. An
These types are deprecated. implementation <bcp14>MUST NOT</bcp14> create such a key, but it <bcp14>MAY</bc
The "key flags" subpacket in a signature is a much better way to express the sam p14> interpret it.</t>
e idea, and generalizes it to all algorithms. <t>An implementation <bcp14>MUST NOT</bcp14> generate RSA keys of a size
An implementation <bcp14>MUST NOT</bcp14> create such a key, but <bcp14>MAY</bcp less than 3072 bits.
14> interpret it.</t> An implementation <bcp14>SHOULD NOT</bcp14> encrypt, sign, or verify using RSA k
eys of a size less than 3072 bits. An implementation <bcp14>MUST NOT</bcp14> enc
<t>An implementation <bcp14>MUST NOT</bcp14> generate RSA keys of size less than rypt, sign, or verify using RSA keys of a size less than 2048 bits. An implement
3072 bits. ation that decrypts a message using an RSA secret key of a size less than 3072 b
An implementation <bcp14>SHOULD NOT</bcp14> encrypt, sign or verify using RSA ke its <bcp14>SHOULD</bcp14> generate a deprecation warning that the key is too wea
ys of size less than 3072 bits. k for modern use.</t>
An implementation <bcp14>MUST NOT</bcp14> encrypt, sign or verify using RSA keys </section>
of size less than 2048 bits. <section anchor="dsa-notes">
An implementation that decrypts a message using an RSA secret key of size less t <name>DSA</name>
han 3072 bits <bcp14>SHOULD</bcp14> generate a deprecation warning that the key <t>DSA is no longer recommended.
is too weak for modern use.</t>
</section>
<section anchor="dsa-notes"><name>DSA</name>
<t>DSA is no longer recommended.
It has also been deprecated in <xref target="FIPS186"/>. It has also been deprecated in <xref target="FIPS186"/>.
Therefore, an implementation <bcp14>MUST NOT</bcp14> generate DSA keys.</t> Therefore, an implementation <bcp14>MUST NOT</bcp14> generate DSA keys.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> sign or verify using DSA ke
<t>An implementation <bcp14>MUST NOT</bcp14> sign or verify using DSA keys.</t> ys.</t>
</section>
</section> <section anchor="elgamal-notes">
<section anchor="elgamal-notes"><name>Elgamal</name> <name>Elgamal</name>
<t>The PKCS1-v1_5 padding scheme, used by the Elgamal algorithm defined
<t>The PKCS1-v1_5 padding scheme, used by the Elgamal algorithm defined in this in this document, is no longer recommended, and its use is deprecated by <xref t
document, is no longer recommended, and its use is deprecated by <xref target="S arget="SP800-131A"/>.
P800-131A"/>.
Therefore, an implementation <bcp14>MUST NOT</bcp14> generate Elgamal keys.</t> Therefore, an implementation <bcp14>MUST NOT</bcp14> generate Elgamal keys.</t>
<t>An implementation <bcp14>MUST NOT</bcp14> encrypt using Elgamal keys.
<t>An implementation <bcp14>MUST NOT</bcp14> encrypt using Elgamal keys.
An implementation that decrypts a message using an Elgamal secret key <bcp14>SHO ULD</bcp14> generate a deprecation warning that the key is too weak for modern u se.</t> An implementation that decrypts a message using an Elgamal secret key <bcp14>SHO ULD</bcp14> generate a deprecation warning that the key is too weak for modern u se.</t>
</section>
</section> <section anchor="eddsa-notes">
<section anchor="eddsa-notes"><name>EdDSA</name> <name>EdDSA</name>
<t>Although the EdDSA algorithm allows arbitrary data as input, its use
<t>Although the EdDSA algorithm allows arbitrary data as input, its use with Ope with OpenPGP requires that a digest of the message be used as input (pre-hashed)
nPGP requires that a digest of the message is used as input (pre-hashed). . See <xref target="computing-signatures"/> for details.
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> 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 varia
<t>For clarity: while <xref target="RFC8032"/> describes different variants of E nts of EdDSA, OpenPGP uses the "pure" variant (PureEdDSA).
dDSA, OpenPGP uses the "pure" variant (PureEdDSA).
The hashing that happens with OpenPGP is done as part of the standard OpenPGP si gnature process, and that hash itself is fed as the input message to the PureEdD SA algorithm.</t> The hashing that happens with OpenPGP is done as part of the standard OpenPGP si gnature process, and that hash itself is fed as the input message to the PureEdD SA algorithm.</t>
<t>As specified in <xref target="RFC8032"/>, Ed448 also expects a "conte
<t>As specified in <xref target="RFC8032"/>, Ed448 also expects a "context strin xt string".
g".
In OpenPGP, Ed448 is used with the empty string as a context string.</t> In OpenPGP, Ed448 is used with the empty string as a context string.</t>
</section>
<section anchor="reserved-notes">
<name>Reserved Algorithm IDs</name>
<t>A number of algorithm IDs have been reserved for algorithms that woul
d be useful to use in an OpenPGP implementation, yet there are issues that preve
nt an implementer from actually implementing the algorithm. These are marked as
reserved in <xref target="pubkey-algos"/>.</t>
</section> <t>The reserved public-key algorithm X9.42 (21) does not have the necess
<section anchor="reserved-notes"><name>Reserved Algorithm IDs</name> ary parameters, parameter order, or semantics defined. The same is currently tru
e for reserved public-key algorithms AEDH (23) and AEDSA (24).</t>
<t>A number of algorithm IDs have been reserved for algorithms that would be use <t>Previous versions of the OpenPGP specification permitted Elgamal <xre
ful to use in an OpenPGP implementation, yet there are issues that prevent an im f target="ELGAMAL"/> signatures with a public-key algorithm ID of 20. These are
plementer from actually implementing the algorithm. no longer permitted. An implementation <bcp14>MUST NOT</bcp14> generate such key
These are marked as reserved in <xref target="pubkey-algos"/>.</t> s. An implementation <bcp14>MUST NOT</bcp14> generate Elgamal signatures;
see <xref target="BLEICHENBACHER"/>.</t>
<t>The reserved public-key algorithm X9.42 (21) does not have the necessary para </section>
meters, parameter order, or semantics defined. <section anchor="cfb-mode">
The same is currently true for reserved public-key algorithms AEDH (23) and AEDS <name>CFB Mode</name>
A (24).</t> <t>The Cipher Feedback (CFB) mode used in this document is defined in Se
ction 6.3 of <xref target="SP800-38A"/>.</t>
<t>Previous versions of OpenPGP permitted Elgamal <xref target="ELGAMAL"/> signa <t>The CFB segment size <tt>s</tt> is equal to the block size of the cip
tures with a public-key algorithm ID of 20. her (i.e., n-bit CFB mode, where n is the block size used).</t>
These are no longer permitted. </section>
An implementation <bcp14>MUST NOT</bcp14> generate such keys. <section anchor="private-or-experimental-parameters">
An implementation <bcp14>MUST NOT</bcp14> generate Elgamal signatures. <name>Private or Experimental Parameters</name>
See <xref target="BLEICHENBACHER"/>.</t> <t>S2K specifiers, Signature subpacket type IDs, User Attribute subpacke
t type IDs, image format IDs, and the various algorithm IDs described in <xref t
</section> arget="constants"/> all reserve the range 100 to 110 for Private and Experimenta
<section anchor="cfb-mode"><name>CFB Mode</name> l Use.
Packet type IDs reserve the range 60 to 63 for Private and Experimental Use.
<t>The Cipher Feedback (CFB) mode used in this document is defined in Section 6. These are intentionally managed by the Private Use and Experimental Use policies
3 of <xref target="SP800-38A"/>.</t> , as described in <xref target="RFC8126"/>.</t>
<t>However, implementations need to be careful with these and promote th
<t>The CFB segment size <spanx style="verb">s</spanx> is equal to the block size em to full IANA-managed parameters when they grow beyond the original, limited s
of the cipher (i.e., n-bit CFB mode where n is the block size is used).</t> ystem.</t>
</section>
</section> <section anchor="meta-considerations-for-expansion">
<section anchor="private-or-experimental-parameters"><name>Private or Experiment <name>Meta Considerations for Expansion</name>
al Parameters</name> <t>If OpenPGP is extended in a way that is not backward compatible, mean
ing that old implementations will not gracefully handle their absence of a new f
<t>S2K specifiers, Signature subpacket type IDs, User Attribute subpacket type I eature, the extension proposal can be declared in the keyholder's self-signature
Ds, image format IDs, and the various algorithm IDs described in <xref target="c as part of the Features signature subpacket.</t>
onstants"/> all reserve the range 100 to 110 for private and experimental use. <t>We cannot state definitively what extensions will not be forward comp
Packet type IDs reserve the range 60 to 63 for private and experimental use. atible, but typically new algorithms are forward compatible, whereas new packets
These are intentionally managed with the PRIVATE USE method, as described in <xr are not.</t>
ef target="RFC8126"/>.</t> <t>If an extension proposal does not update the Features system, it <bcp
14>SHOULD</bcp14> include an explanation of why this is unnecessary.
<t>However, implementations need to be careful with these and promote them to fu
ll IANA-managed parameters when they grow beyond the original, limited system.</
t>
</section>
<section anchor="meta-considerations-for-expansion"><name>Meta-Considerations fo
r Expansion</name>
<t>If OpenPGP is extended in a way that is not backwards-compatible, meaning tha
t 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 par
t of the Features signature subpacket.</t>
<t>We cannot state definitively what extensions will not be upwards-compatible,
but typically new algorithms are upwards-compatible, whereas new packets are not
.</t>
<t>If an extension proposal does not update the Features system, it <bcp14>SHOUL
D</bcp14> include an explanation of why this is unnecessary.
If the proposal contains neither an extension to the Features system nor an expl anation of why such an extension is unnecessary, the proposal <bcp14>SHOULD</bcp 14> be rejected.</t> If the proposal contains neither an extension to the Features system nor an expl anation of why such an extension is unnecessary, the proposal <bcp14>SHOULD</bcp 14> be rejected.</t>
</section>
</section> </section>
</section> <section anchor="security-considerations">
<section anchor="security-considerations"><name>Security Considerations</name> <name>Security Considerations</name>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>As with any technology involving cryptography, implementers should check th <t>As with any technology involving cryptography, implementers should
e current literature to determine if any algorithms used here have been found to check the current literature to determine if any algorithms used here have been
be vulnerable to an attack. found to be vulnerable to an attack.
If so, implementers should consider disallowing such algorithms for new data and If so, implementers should consider disallowing such algorithms for new data and
warn or prevent the enduser when they are trying to consume data protected by s warning the end user, or preventing use, when they are trying to consume data p
uch now vulnerable algorithms.</t> rotected by such algorithms that are now vulnerable.</t>
<t>This specification uses Public-Key Cryptography technologies. </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 contr olled and secured by the proper party or parties.</t> It is assumed that the private key portion of a public-private key pair is contr olled and secured by the proper party or parties.</t>
<t>The MD5 and SHA-1 hash algorithms have been found to have weaknesses, with </li>
collisions found in a number of cases. <li>
MD5 and SHA-1 are deprecated for use in OpenPGP (See <xref target="hash-algos"/> <t>The MD5 and SHA-1 hash algorithms have been found to have weaknesse
).</t> s, with collisions found in a number of cases.
<t>Many security protocol designers think that it is a bad idea to use a singl MD5 and SHA-1 are deprecated for use in OpenPGP (see <xref target="hash-algos"/>
e key for both privacy (encryption) and integrity (signatures). ).</t>
In fact, this was one of the motivating forces behind the v4 key format with sep </li>
arate signature and encryption keys. <li>
Using a single key for encrypting and signing is discouraged.</t> <t>Many security protocol designers think that it is a bad idea to use
<t>The DSA algorithm will work with any hash, but is sensitive to the quality a single key for both privacy (encryption) and integrity (signatures).
of the hash algorithm. In fact, this was one of the motivating forces behind the v4 key format with sep
Verifiers should be aware that even if the signer used a strong hash, an attacke arate signature and encryption keys. Using a single key for encrypting and signi
r could have modified the signature to use a weak one. ng is discouraged.</t>
Only signatures using acceptably strong hash algorithms should be accepted as va </li>
lid.</t> <li>
<t>As OpenPGP combines many different asymmetric, symmetric, and hash algorith <t>The DSA algorithm will work with any hash, but it is sensitive to t
ms, each with different measures of strength, care should be taken that the weak he quality of the hash algorithm.
est element of an OpenPGP message is still sufficiently strong for the purpose a Verifiers should be aware that even if the signer used a strong hash, an attacke
t hand. r could have modified the signature to use a weak one. Only signatures using acc
While consensus about the strength of a given algorithm may evolve, NIST Special eptably strong hash algorithms should be accepted as valid.</t>
Publication 800-57 <xref target="SP800-57"/> contains recommendations current a </li>
t the time of this publication about equivalent security levels of different alg <li>
orithms.</t> <t>As OpenPGP combines many different asymmetric, symmetric, and hash
<t>There is a somewhat-related potential security problem in signatures. algorithms, each with different measures of strength, care should be taken to en
If an attacker can find a message that hashes to the same hash with a different sure that the weakest element of an OpenPGP message is still sufficiently strong
algorithm, a bogus signature structure can be constructed that evaluates correct for the purpose at hand. While consensus about the strength of a given algorith
ly. <vspace blankLines='1'/> m may evolve, NIST Special Publication 800-57 <xref target="SP800-57"/> contains
For example, suppose Alice DSA signs message M using hash algorithm H. recommendations (current at the time of this publication) about equivalent secu
rity levels of different algorithms.</t>
</li>
<li>
<t>There is a somewhat-related potential security problem in signature
s.
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 correct
ly. </t>
<t>
For example, suppose Alice 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' . 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 o f M' with H'. Mallet can then construct a signature block that verifies as Alice's signature o f M' with H'.
However, this would also constitute a weakness in either H or H' or both. However, this would also constitute a weakness in either H or H', or both.
Should this ever occur, a revision will have to be made to this document to revi se the allowed hash algorithms.</t> Should this ever occur, a revision will have to be made to this document to revi se the allowed hash algorithms.</t>
<t>If you are building an authentication system, the recipient may specify a p </li>
referred signing algorithm. <li>
<t>If you are building an authentication system, the recipient may spe
cify a preferred signing algorithm.
However, the signer would be foolish to use a weak algorithm simply because the recipient requests it.</t> However, the signer would be foolish to use a weak algorithm simply because the recipient requests it.</t>
<t>Some of the encryption algorithms mentioned in this document have been anal </li>
yzed less than others. <li>
<t>Some of the encryption algorithms mentioned in this document have b
een analyzed less than others.
For example, although TWOFISH is presently considered reasonably strong, it has been analyzed much less than AES. 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> Other algorithms may have other concerns surrounding them.</t>
<t>In late summer 2002, Jallad, Katz, and Schneier published an interesting at </li>
tack on older versions of the OpenPGP protocol and some of its implementations < <li>
xref target="JKS02"/>. <t>In late summer 2002, Jallad, Katz, and Schneier published an intere
sting attack on previous versions of the OpenPGP specification and some of its i
mplementations <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. 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, and can often decryp t the message. The attacker is thus using the user as a decryption oracle and can often decrypt the message.
This attack is a particular form of ciphertext malleability. This attack is a particular form of ciphertext malleability.
See <xref target="ciphertext-malleability"/> for information on how to defend ag ainst such an attack using more recent versions of OpenPGP.</t> See <xref target="ciphertext-malleability"/> for information on how to defend ag ainst such an attack using more recent versions of OpenPGP.</t>
</list></t> </li>
</ul>
<section anchor="sha1cd"><name>SHA-1 Collision Detection</name> <section anchor="sha1cd">
<name>SHA-1 Collision Detection</name>
<t>As described in <xref target="SHAMBLES"/>, the SHA-1 digest algorithm is not <t>As described in <xref target="SHAMBLES"/>, the SHA-1 digest algorithm
collision-resistant. is not collision resistant.
However, an OpenPGP implementation cannot completely discard the SHA-1 algorithm , because it is required for implementing v4 public keys. 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. 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> 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
<t>To avoid the risk of uncertain breakage from a maliciously introduced SHA-1 c SHA-1 collision, an OpenPGP implementation <bcp14>MAY</bcp14> attempt to detect
ollision, an OpenPGP implementation <bcp14>MAY</bcp14> attempt to detect when a when a hash input is likely from a known collision attack and then either rejec
hash input is likely from a known collision attack, and then either deliberately t the hash input deliberately or modify the hash output.
reject the hash input or modify the hash output.
This should convert an uncertain breakage (where it is unclear what the effect o f a collision will be) to an explicit breakage, which is more desirable for a ro bust implementation.</t> This should convert an uncertain breakage (where it is unclear what the effect o f a collision will be) to an explicit breakage, which is more desirable for a ro bust implementation.</t>
<t><xref target="STEVENS2013"/> describes a method for detecting indicat
<t><xref target="STEVENS2013"/> describes a method for detecting indicators of w ors of well-known SHA-1 collision attacks.
ell-known SHA-1 collision attacks.
Some example C code implementing this technique can be found at <xref target="SH A1CD"/>.</t> Some example C code implementing this technique can be found at <xref target="SH A1CD"/>.</t>
</section>
</section> <section anchor="signature-salt-rationale">
<section anchor="signature-salt-rationale"><name>Advantages of Salted Signatures <name>Advantages of Salted Signatures</name>
</name> <t>V6 signatures include a salt that is hashed first, and it's size depe
nds on the hashing algorithm. This makes v6 OpenPGP signatures non-deterministic
<t>V6 signatures include a salt that is hashed first, which size depends on the and protects against a broad class of attacks that depend on creating a signatu
hashing algorithm. re over a predictable message. By selecting a new random salt for each signature
This makes v6 OpenPGP signatures non-deterministic and protects against a broad made, the signed hashes and the signatures are not predictable.</t>
class of attacks that depend on creating a signature over a predictable message. <t>While the material to be signed could be attacker controlled, hashing
By selecting a new random salt for each signature made, the signed hashes and th the salt first means that there is no attacker-controlled hashed prefix.
e signatures are not predictable.</t> An example of this kind of attack is described in the paper "SHA-1 is a Shambles
" <xref target="SHAMBLES"/>, which leverages a chosen prefix collision attack ag
<t>While the material to be signed could be attacker-controlled, hashing the sal ainst SHA-1.
t first means that there is no attacker controlled hashed prefix. This means that an adversary carrying out a chosen-message attack will not be ab
An example of this kind of attack is described in the paper "SHA-1 Is A Shambles le to control the hash that is being signed and will need to break second-preima
" <xref target="SHAMBLES"/>, which leverages a chosen prefix collision attack ag ge resistance instead of the simpler collision resistance to create two messages
ainst SHA-1. having the same signature.
This means that an adversary carrying out a chosen-message attack will not be ab The size of the salt is bound to the hash function to match the expected collisi
le to control the hash that is being signed, and will need to break second-preim on-resistance level and is at least 16 octets.</t>
age resistance instead of the simpler collision resistance to create two message <t>In some cases, an attacker may be able to induce a signature to be ma
s having the same signature. de, even if they do not control the content of the message. In some scenarios, a
The size of the salt is bound to the hash function to match the expected collisi repeated signature over the exact same message may risk leakage of part or all
on resistance level, and at least 16 octets.</t> of the signing key; for example, see discussion of hardware faults over EdDSA an
d deterministic ECDSA in <xref target="PSSLR17"/>.
<t>In some cases, an attacker may be able to induce a signature to be made, even Choosing a new random salt for each signature ensures that no repeated signature
if they do not control the content of the message. s are produced, which mitigates this risk.</t>
In some scenarios, a repeated signature over the exact same message may risk lea </section>
kage of part or all of the signing key, for example see discussion of hardware f <section anchor="ecc-side-channels">
aults over EdDSA and deterministic ECDSA in <xref target="PSSLR17"/>. <name>Elliptic Curve Side Channels</name>
Choosing a new random salt for each signature ensures that no repeated signature <t>Side-channel attacks are a concern when a compliant application's use
s are produced, and mitigates this risk.</t> of the OpenPGP format can be modeled by a decryption or signing oracle, for exa
mple, when an application is a network service performing decryption to unauthen
</section> ticated remote users.
<section anchor="ecc-side-channels"><name>Elliptic Curve Side Channels</name> ECC scalar multiplication operations used in ECDSA and ECDH are vulnerable to si
de-channel attacks. Countermeasures can often be taken at the higher protocol le
<t>Side channel attacks are a concern when a compliant application's use of the vel, such as limiting the number of allowed failures or time-blinding the operat
OpenPGP format can be modeled by a decryption or signing oracle, for example, wh ions associated with each network interface. Mitigations at the scalar multiplic
en an application is a network service performing decryption to unauthenticated ation level seek to eliminate any measurable distinction between the ECC point a
remote users. ddition and doubling operations.</t>
ECC scalar multiplication operations used in ECDSA and ECDH are vulnerable to si </section>
de channel attacks. <section anchor="quick-check-oracle">
Countermeasures can often be taken at the higher protocol level, such as limitin <name>Risks of a Quick Check Oracle</name>
g the number of allowed failures or time-blinding of the operations associated w <t>In winter 2005, Serge Mister and Robert Zuccherato from Entrust relea
ith each network interface. sed a paper describing a way that the "quick check" in v1 SEIPD and SED packets
Mitigations at the scalar multiplication level seek to eliminate any measurable can be used as an oracle to decrypt two octets of every cipher block <xref targe
distinction between the ECC point addition and doubling operations.</t> t="MZ05"/>.
</section>
<section 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 pa
per describing a way that the "quick check" in v1 SEIPD and SED packets can be u
sed 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, pa rticularly to detect a wrong passphrase, since v4 SKESK packets do not include a n integrity check.</t> This check was intended for early detection of session key decryption errors, pa rticularly to detect a wrong passphrase, since v4 SKESK packets do not include a n integrity check.</t>
<t>There is a danger when using the quick check if timing or error infor
<t>There is a danger to using the quick check if timing or error information abo mation about the check can be exposed to an attacker, particularly via an automa
ut the check can be exposed to an attacker, particularly via an automated servic ted service that allows rapidly repeated queries.</t>
e 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 pas
<t>Disabling the quick check prevents the attack.</t> sphrase using a version 4 SKESK, the quick check may be convenient to the user b
y informing them early that they typed the wrong passphrase.
<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, by infor
ming them early that they typed the wrong passphrase.
But the implementation should use the quick check with care. 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. 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> 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 exp
<t>The quick check oracle attack is a particular type of attack that exploits ci loits ciphertext malleability.
phertext malleability.
For information about other similar attacks, see <xref target="ciphertext-mallea bility"/>.</t> For information about other similar attacks, see <xref target="ciphertext-mallea bility"/>.</t>
</section>
</section> <section anchor="pkcs1-errors">
<section anchor="pkcs1-errors"><name>Avoiding Leaks From PKCS#1 Errors</name> <name>Avoiding Leaks from PKCS#1 Errors</name>
<t>The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted PKESK
<t>The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted PKESK) has be ) has been found to be vulnerable to attacks in which a system that allows disti
en found to be vulnerable to attacks in which a system that allows distinguishin nguishing padding errors from other decryption errors can act as a decryption an
g padding errors from other decryption errors can act as a decryption and/or sig d/or signing oracle that can leak the session key or allow signing arbitrary dat
ning oracle that can leak the session key or allow signing arbitrary data, respe a, respectively <xref target="BLEICHENBACHER-PKCS1"/>.
ctively <xref target="BLEICHENBACHER-PKCS1"/>.
The number of queries required to carry out an attack can range from thousands t o millions, depending on how strict and careful an implementation is in processi ng the padding.</t> The number of queries required to carry out an attack can range from thousands t o millions, depending on how strict and careful an implementation is in processi ng the padding.</t>
<t>To make the attack more difficult, an implementation <bcp14>SHOULD</b
<t>To make the attack more difficult, an implementation <bcp14>SHOULD</bcp14> im cp14> implement strict, robust, and constant time padding checks.</t>
plement strict, robust, constant time padding checks.</t> <t>To prevent the attack, in settings where the attacker does not have a
ccess to timing information concerning message decryption, the simplest solution
<t>To prevent the attack, in settings where the attacker does not have access to is to report a single error code for all variants of PKESK processing errors as
timing information concerning message decryption, the simplest solution is to r well as SEIPD integrity errors (this also includes session key parsing errors,
eport a single error code for all variants of PKESK processing errors as well as such as on an invalid cipher algorithm for v3 PKESK, or a session key size misma
SEIPD integrity errors (this includes also session key parsing errors, such as tch for v6 PKESK). If the attacker may have access to timing information, then a
on invalid cipher algorithm for v3 PKESK, or session key size mismatch for v6 PK constant time solution is also needed. This requires careful design, especially
ESK). for v3 PKESK, where session key size and cipher information is typically not kn
If the attacker may have access to timing information, then a constant time solu own in advance, as it is part of the PKESK encrypted payload.</t>
tion is also needed. </section>
This requires careful design, especially for v3 PKESK, where session key size an <section anchor="fingerprint-usability">
d cipher information is typically not known in advance, as it is part of the PKE <name>Fingerprint Usability</name>
SK encrypted payload.</t> <t>This specification uses fingerprints in several places on the wire (e
.g., Sections <xref target="revocation-key" format="counter"/>, <xref target="is
</section> suer-fingerprint-subpacket" format="counter"/>, and <xref target="intended-recip
<section anchor="fingerprint-usability"><name>Fingerprint Usability</name> ient-fingerprint" format="counter"/>) and in processing (e.g., in ECDH KDF <xref
target="ecdh"/>). An implementation may also use the fingerprint internally, fo
<t>This specification uses fingerprints in several places on the wire (e.g., <xr r example, as an index to a keystore.</t>
ef target="revocation-key"/>, <xref target="issuer-fingerprint-subpacket"/>, and <t>Additionally, some OpenPGP users have historically used manual finger
<xref target="intended-recipient-fingerprint"/>), and in processing (e.g., in E print comparison to verify the public key of a peer.
CDH KDF <xref target="ecdh"/>).
An implementation may also use the fingerprint internally, for example as an ind
ex to a keystore.</t>
<t>Additionally, some OpenPGP users have historically used manual fingerprint co
mparison to verify the public key of a peer.
For a version 4 fingerprint, this has typically been done with the fingerprint r epresented as 40 hexadecimal digits, often broken into groups of four digits wit h whitespace between each group.</t> For a version 4 fingerprint, this has typically been done with the fingerprint r epresented as 40 hexadecimal digits, often broken into groups of four digits wit h 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 for
m like a hexadecimal <xref target="USENIX-STUDY"/>.</t>
<t>The version 6 fingerprint makes the challenge for a human verifier ev
en worse.
At 256 bits (compared to v4's 160-bit fingerprint), a v6 fingerprint is even har
der for a human to successfully compare.</t>
<t>An OpenPGP implementation should prioritize mechanical fingerprint tr
ansfer and comparison where possible and <bcp14>SHOULD NOT</bcp14> promote manua
l transfer or comparison of full fingerprints by a human unless there is no othe
r way to achieve the desired result.</t>
<t>While this subsection acknowledges existing practice for human-repres
entable v4 fingerprints, this document does not attempt to standardize any speci
fic human-readable form of v6 fingerprint for this discouraged use case.</t>
<t>NOTE: the topic of interoperable human-in-the-loop key verification n
eeds more work, which will be done in a separate document.</t>
</section>
<section anchor="ciphertext-malleability">
<name>Avoiding Ciphertext Malleability</name>
<t>If ciphertext can be modified by an attacker but still subsequently d
ecrypted to some new plaintext, it is considered "malleable". A number of attack
s 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 wer
e available. Because OpenPGP implementations deal with historic stored data, the
y may encounter malleable ciphertexts.</t>
<t>When a human is actively involved, the result of such a verification is dubio <t>When an OpenPGP implementation discovers that it is decrypting data t
us. hat appears to be malleable, it <bcp14>MUST</bcp14> generate a clear error messa
There is little evidence that most humans are good at precise comparison of high ge that indicates the integrity of the message is suspect, it <bcp14>SHOULD NOT<
-entropy data, particularly when that data is represented in compact textual for /bcp14> attempt to parse nor release decrypted data to the user, and it <bcp14>S
m like a hexadecimal (<xref target="USENIX-STUDY"/>).</t> HOULD</bcp14> halt with an error.
Parsing or releasing decrypted data before having confirmed its integrity can le
<t>The version 6 fingerprint makes the challenge for a human verifier even worse ak the decrypted data <xref target="EFAIL"/> <xref target="MRLG15"/>.</t>
. <t>In the case of AEAD encrypted data, if the authentication tag fails t
At 256 bits (compared to v4's 160 bit fingerprint), a v6 fingerprint is even har o verify, the implementation <bcp14>MUST NOT</bcp14> attempt to parse nor releas
der for a human to successfully compare.</t> e decrypted data to the user, and it <bcp14>MUST</bcp14> halt with an error.</t>
<t>An implementation that encounters malleable ciphertext <bcp14>MAY</bc
<t>An OpenPGP implementation should prioritize mechanical fingerprint transfer a p14> choose to release cleartext to the user if it is not encrypted using AEAD,
nd comparison where possible, and <bcp14>SHOULD NOT</bcp14> promote manual trans it is known to be dealing with historic archived legacy data, and the user is aw
fer or comparison of full fingerprints by a human unless there is no other way t are of the risks.</t>
o achieve the desired result.</t> <t>In the case of AEAD encrypted messages, if the message is truncated,
i.e., the final zero-octet chunk and possibly (part of) some chunks before it ar
<t>While this subsection acknowledges existing practice for human-representable e missing, the implementation <bcp14>MAY</bcp14> choose to release cleartext fro
v4 fingerprints, this document does not attempt to standardize any specific huma m the fully authenticated chunks before it to the user if it is operating in a s
n-readable form of v6 fingerprint for this discouraged use case.</t> treaming fashion, but it <bcp14>MUST</bcp14> indicate a clear error message as s
oon as the truncation is detected.</t>
<t>NOTE: the topic of interoperable human-in-the-loop key verification needs mor <t>Any of the following OpenPGP data elements indicate that malleable ci
e work, to be done in a separate document.</t> phertext is present:</t>
<ul spacing="normal">
</section> <li>
<section anchor="ciphertext-malleability"><name>Avoiding Ciphertext Malleability <t>All Symmetrically Encrypted Data packets (<xref target="sed"/>).<
</name> /t>
</li>
<t>If ciphertext can be modified by an attacker but still subsequently decrypted <li>
to some new plaintext, it is considered "malleable". <t>Within any encrypted container, any Compressed Data packet (<xref
A number of attacks can arise in any cryptosystem that uses malleable encryption target="compressed-data"/>) where there is a decompression failure.</t>
, so <xref target="RFC4880"/> and later versions of OpenPGP offer mechanisms to </li>
defend against it. <li>
However, OpenPGP data may have been created before these defense mechanisms were <t>Any version 1 Symmetrically Encrypted Integrity Protected Data pa
available. cket (<xref target="version-one-seipd"/>) where the internal Modification Detect
Because OpenPGP implementations deal with historic stored data, they may encount ion Code does not validate.</t>
er malleable ciphertexts.</t> </li>
<li>
<t>When an OpenPGP implementation discovers that it is decrypting data that appe <t>Any version 2 Symmetrically Encrypted Integrity Protected Data pa
ars to be malleable, it <bcp14>MUST</bcp14> indicate a clear error message that cket (<xref target="version-two-seipd"/>) where the authentication tag of any ch
the integrity of the message is suspect, <bcp14>SHOULD NOT</bcp14> attempt to pa unk fails or where there is no final zero-octet chunk.</t>
rse nor release decrypted data to the user, and <bcp14>SHOULD</bcp14> halt with </li>
an error. <li>
Parsing or releasing decrypted data before having confirmed its integrity can le <t>Any Secret-Key packet with encrypted secret key material (<xref t
ak the decrypted data <xref target="EFAIL"/>, <xref target="MRLG15"/>.</t> arget="secret-key-encryption"/>) where there is an integrity failure, based on t
he value of the secret key protection octet: </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 decryp
ted data to the user, and <bcp14>MUST</bcp14> halt with an error.</t>
<t>An implementation that encounters malleable ciphertext <bcp14>MAY</bcp14> cho
ose to release cleartext to the user if it is not encrypted using AEAD, and it i
s 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. 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 fully a
uthenticated chunks before it to the user if it is operating in a streaming fash
ion, but it <bcp14>MUST</bcp14> indicate a clear error message as soon as the tr
uncation is detected.</t>
<t>Any of the following OpenPGP data elements indicate that malleable ciphertext
is present:</t>
<t><list style="symbols">
<t>All Symmetrically Encrypted Data packets (<xref target="sed"/>).</t>
<t>Within any encrypted container, any Compressed Data packet (<xref target="c
ompressed-data"/>) where there is a decompression failure.</t>
<t>Any version 1 Symmetrically Encrypted Integrity Protected Data packet (<xre
f target="version-one-seipd"/>) where the internal Modification Detection Code d
oes not validate.</t>
<t>Any version 2 Symmetrically Encrypted Integrity Protected Data packet (<xre
f target="version-two-seipd"/>) where the authentication tag of any chunk fails,
or where there is no final zero-octet chunk.</t>
<t>Any Secret-Key packet with encrypted secret key material (<xref target="sec
ret-key-encryption"/>) where there is an integrity failure, based on the value o
f the secret key protection octet: <list style="symbols">
<t>Value 255 (MalleableCFB) or raw cipher algorithm: where the trailing 2-
octet checksum does not match.</t>
<t>Value 254 (CFB): where the SHA1 checksum is mismatched.</t>
<t>Value 253 (AEAD): where the AEAD authentication tag is invalid.</t>
</list></t>
</list></t>
<t>To avoid these circumstances, an implementation that generates OpenPGP encryp <ul spacing="normal">
ted data <bcp14>SHOULD</bcp14> select the encrypted container format with the mo <li>
st robust protections that can be handled by the intended recipients. <t>Value 253 (AEAD): where the AEAD authentication tag is invali
d.</t>
</li>
<li>
<t>Value 254 (CFB): where the SHA1 checksum is mismatched.</t>
</li>
<li>
<t>Value 255 (MalleableCFB) or raw cipher algorithm: where the t
railing 2-octet checksum does not match.</t>
</li>
</ul>
</li>
</ul>
<t>To avoid these circumstances, an implementation that generates OpenPG
P encrypted data <bcp14>SHOULD</bcp14> select the encrypted container format wit
h the most robust protections that can be handled by the intended recipients.
In particular:</t> In particular:</t>
<ul spacing="normal">
<t><list style="symbols"> <li>
<t>The SED packet is deprecated, and <bcp14>MUST NOT</bcp14> be generated.</t> <t>The SED packet is deprecated and <bcp14>MUST NOT</bcp14> be gener
<t>When encrypting to one or more public keys: <list style="symbols"> ated.</t>
<t>If all recipient keys indicate support for version 2 of the Symmetrical </li>
ly Encrypted Integrity Protected Data packet in their Features subpacket (<xref <li>
target="features-subpacket"/>), or are v6 keys without a Features subpacket, or <t>When encrypting to one or more public keys: </t>
the implementation can otherwise infer that all recipients support v2 SEIPD pack <ul spacing="normal">
ets, the implementation <bcp14>SHOULD</bcp14> encrypt using a v2 SEIPD packet.</ <li>
t> <t>If all recipient keys indicate support for version 2 of the S
<t>If one of the recipients does not support v2 SEIPD packets, then the me ymmetrically Encrypted Integrity Protected Data packet in their Features subpack
ssage generator <bcp14>MAY</bcp14> use a v1 SEIPD packet instead.</t> et (<xref target="features-subpacket"/>), if all recipient keys are v6 keys with
</list></t> out a Features subpacket, or the implementation can otherwise infer that all rec
<t>Passphrase-protected secret key material in a v6 Secret Key or v6 Secret Su ipients support v2 SEIPD packets, the implementation <bcp14>SHOULD</bcp14> encry
bkey packet <bcp14>SHOULD</bcp14> be protected with AEAD encryption (S2K usage o pt using a v2 SEIPD packet.</t>
ctet 253) unless it will be transferred to an implementation that is known to no </li>
t support AEAD. <li>
An implementation should be aware that, in scenarios where an attacker has write <t>If one of the recipients does not support v2 SEIPD packets, t
access to encrypted private keys, CFB-encrypted keys (S2K usage octet 254 or 25 hen the message generator <bcp14>MAY</bcp14> use a v1 SEIPD packet instead.</t>
5) are vulnerable to corruption attacks that can cause leakage of secret data wh </li>
en the secret key is used <xref target="KOPENPGP"/>, <xref target="KR02"/>.</t> </ul>
</list></t> </li>
<li>
<t>Implementers should implement AEAD (v2 SEIPD and S2K usage octet 253) promptl <t>Passphrase-protected secret key material in a v6 Secret Key or v6
y and encourage its spread.</t> Secret Subkey packet <bcp14>SHOULD</bcp14> be protected with AEAD encryption (S
2K usage octet 253) unless it will be transferred to an implementation that is k
<t>Users are <bcp14>RECOMMENDED</bcp14> to migrate to AEAD.</t> nown to not support AEAD.
An implementation should be aware that, in scenarios where an attacker has write
</section> access to encrypted private keys, CFB-encrypted keys (S2K usage octet 254 or 25
<section anchor="secure-sessionkey-reuse"><name>Secure Use of the v2 SEIPD Sessi 5) are vulnerable to corruption attacks that can cause leakage of secret data wh
on-Key-Reuse Feature</name> en the secret key is used <xref target="KOPENPGP"/> <xref target="KR02"/>.</t>
</li>
<t>The salted key derivation of v2 SEIPD packets (<xref target="version-two-seip </ul>
d"/>) allows the recipient of an encrypted message to reply to the sender and al <t>Implementers should implement AEAD (v2 SEIPD and S2K usage octet 253)
l other recipients without needing their public keys but by using the same v6 PK promptly and encourage its spread.</t>
ESK packets he received and a different random salt value. <t>Users are <bcp14>RECOMMENDED</bcp14> to migrate to AEAD.</t>
This ensures a secure mechanism on the cryptographic level that enables the use </section>
of message encryption in cases where a sender does not have a copy of an encrypt <section anchor="secure-sessionkey-reuse">
ion-capable certificate for one or more participants in the conversation and thu <name>Secure Use of the v2 SEIPD Session-Key-Reuse Feature</name>
s can enhance the overall security of an application. <t>The salted key derivation of v2 SEIPD packets (<xref target="version-
However, care must be taken when using this mechanism not to create security vul two-seipd"/>) allows the recipient of an encrypted message to reply to the sende
nerabilities, such as the following.</t> r and all other recipients without needing their public keys but by using the sa
me v6 PKESK packets it received and a different random salt value.
<t><list style="symbols"> This ensures a secure mechanism on the cryptographic level that enables the use
<t>Replying to only a subset of the original recipients and the original sende of message encryption in cases where a sender does not have a copy of an encrypt
r by use of the session-key-reuse feature would mean that the remaining recipien ion-capable certificate for one or more participants in the conversation and thu
ts (including the sender) of the original message could read the encrypted reply s can enhance the overall security of an application. However, care must be take
message, too.</t> n when using this mechanism not to create security vulnerabilities, such as the
<t>Adding a further recipient to the reply that is encrypted using the session following:</t>
-key-reuse feature gives that further recipient also cryptographic access to the <ul spacing="normal">
original message that is being replied to (and potentially to a longer history <li>
of previous messages).</t> <t>Replying to only a subset of the original recipients and the orig
<t>A modification of the list of recipients addressed in the above points need inal sender by use of the session-key-reuse feature would mean that the remainin
s also to be safeguarded when a message is initially composed as a reply with se g recipients (including the sender) of the original message could read the encry
ssion-key reuse but then first stored (e.g. as a draft) and later reopened for f pted reply message, too.</t>
urther editing and finally sent.</t> </li>
<t>There is the potential threat that an attacker with network or mailbox acce <li>
ss, who is at the same time a recipient of the original message, silently remove <t>Adding a further recipient to the reply that is encrypted using t
s themselves from the message before the victim's client receives it. he session-key-reuse feature gives that further recipient also cryptographic acc
ess to the original message that is being replied to (and potentially to a longe
r history of previous messages).</t>
</li>
<li>
<t>A modification of the list of recipients addressed in the above p
oints also needs to be safeguarded when a message is initially composed as a rep
ly with session-key reuse but then is stored (e.g., as a draft) and later reopen
ed for further editing and to be finally sent.</t>
</li>
<li>
<t>There is the potential threat that an attacker with network or ma
ilbox access, who is at the same time a recipient of the original message, silen
tly 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 r euse would unknowingly compose an encrypted message that could be read by the at tacker. The victim's client that then uses the mechanism for replying with session-key r euse would unknowingly compose an encrypted message that could be read by the at tacker.
Implementations are encouraged to use the Intended Recipient Fingerprint (<xref Implementations are encouraged to use the Intended Recipient Fingerprint subpack
target="intended-recipient-fingerprint"/>) subpacket when composing messages and et (<xref target="intended-recipient-fingerprint"/>) when composing messages and
to use it to check the consistency of the set of recipients of a message before checking the consistency of the set of recipients of a message before replying
replying to it with session-key reuse.</t> to it with session-key reuse.</t>
<t>When using the session-key-reuse feature in any higher-layer protocol, care </li>
should be taken that there is no other potentially interfering practice of sess <li>
ion-key reuse established in that protocol. <t>When using the session-key-reuse feature in any higher-layer proto
Such interfering session-key reuse could for instance be given if an initial mes col, care should be taken to ensure that there is no other potentially interferi
sage is already composed by reusing the session key of an existing encrypted fil ng practice of session-key reuse established in that protocol. Such interfering
e the access to which may be shared among a group of users already. session-key reuse could, for instance, be given -- if an initial message is alre
Using the session-key-reuse feature to compose an encrypted reply to such a mess ady composed -- by reusing the session key of an existing encrypted file that ma
age would unknowingly give this whole group of users cryptographic access to the y have been shared among a group of users already. Using the session-key-reuse f
encrypted message.</t> eature to compose an encrypted reply to such a message would unknowingly give th
<t>Generally, the use of the session-key-reuse feature should be under the con is whole group of users cryptographic access to the encrypted message.</t>
trol of the user. </li>
Specifically, care should be taken that this feature is not silently used when t <li>
he user assumes that proper public-key encryption is used. <t>Generally, the use of the session-key-reuse feature should be und
This can be the case for instance when the public key of one of the recipients o er the control of the user. Specifically, care should be taken so that this feat
f the reply is known but has expired. ure is not silently used when the user assumes that proper public-key encryption
Special care should be taken to ensure that users do not get caught in continued is used. This can be the case, for instance, when the public key of one of the
use of the session-key reuse unknowingly but instead receive the chance to swit recipients of the reply is known but has expired. Special care should be taken t
ch to proper fresh public-key encryption as soon as possible.</t> o ensure that users do not get caught in continued use of the session-key reuse
<t>Whenever possible, a client should prefer a fresh public key encryption ove unknowingly but instead receive the chance to switch to proper fresh public-key
r the session-key reuse.</t> encryption as soon as possible.</t>
</list></t> </li>
<li>
<t>Even though this not necessarily being a security aspect, note that initially <t>Whenever possible, a client should prefer a fresh public key encr
composing an encrypted reply using the session-key-reuse feature on one client yption over the session-key reuse.</t>
and storing it (e.g. as a draft) and later reopening the stored unfinished reply </li>
with another client that does not support the session-key-reuse feature may lea </ul>
d to interoperability problems.</t> <t>Even though this is not necessarily a security aspect, note that init
ially composing an encrypted reply using the session-key-reuse feature on one cl
<t>Avoiding the pitfalls described above requires context-specific expertise. ient and then storing it (e.g., as a draft) and later reopening the stored unfin
ished reply with another client that does not support the session-key-reuse feat
ure may lead to interoperability problems.</t>
<t>Avoiding the pitfalls described above requires context-specific exper
tise.
An implementation should only make use of the session-key-reuse feature in any p articular application layer when it can follow reasonable documentation about ho w to deploy the feature safely in the specific application. An implementation should only make use of the session-key-reuse feature in any p articular application layer when it can follow reasonable documentation about ho w 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 m ake use of this feature should publish their own proposed guidance for others to review.</t> 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 m ake use of this feature should publish their own proposed guidance for others to review.</t>
</section>
</section> <section anchor="escrowed-revocations">
<section anchor="escrowed-revocations"><name>Escrowed Revocation Signatures</nam <name>Escrowed Revocation Signatures</name>
e> <t>A keyholder, Alice, may wish to designate a third party to be able to
revoke her own key.</t>
<t>A keyholder, Alice, may wish to designate a third party to be able to revoke <t>The preferred way for Alice to do this is to produce a specific Revoc
Alice's own key.</t> ation Signature (signature type IDs 0x20, 0x28, or 0x30) and distribute it secur
ely to a preferred revoker who can hold it in escrow. The preferred revoker can
<t>The preferred way for her to do this is to produce a specific Revocation Sign then publish the escrowed Revocation Signature at whatever time is deemed approp
ature (signature type IDs 0x20, 0x28, or 0x30) and distribute it securely to her riate rather than generating the revocation signature themselves.</t>
preferred revoker who can hold it in escrow. <t>There are multiple advantages of using an escrowed Revocation Signatu
The preferred revoker can then publish the escrowed Revocation Signature at what re over the deprecated Revocation Key subpacket (<xref target="revocation-key"/>
ever time is deemed appropriate, rather than generating a revocation signature t ):</t>
hemselves.</t> <ul spacing="normal">
<li>
<t>There are multiple advantages of using an escrowed Revocation Signature over <t>The keyholder can constrain what types of revocation the preferre
the deprecated Revocation Key subpacket (<xref target="revocation-key"/>):</t> d revoker can issue, by only escrowing those specific signatures.</t>
</li>
<t><list style="symbols"> <li>
<t>The keyholder can constrain what types of revocation the preferred revoker <t>There is no public/visible linkage between the keyholder and the
can issue, by only escrowing those specific signatures.</t> preferred revoker.</t>
<t>There is no public/visible linkage between the keyholder and the preferred </li>
revoker.</t> <li>
<t>Third parties can verify the revocation without needing to find the key of <t>Third parties can verify the revocation without needing to find t
the preferred revoker.</t> he key of the preferred revoker.</t>
<t>The preferred revoker doesn't even need to have a public OpenPGP key if som </li>
e other secure transport is possible between them and the keyholder.</t> <li>
<t>Implementation support for enforcing a revocation from an authorized Revoca <t>The preferred revoker doesn't even need to have a public OpenPGP
tion Key subpacket is uneven and unreliable.</t> key if some other secure transport is possible between them and the keyholder.</
<t>If the fingerprint mechanism suffers a cryptanalytic flaw, the escrowed Rev t>
ocation Signature is not affected.</t> </li>
</list></t> <li>
<t>Implementation support for enforcing a revocation from an authori
<t>A Revocation Signature may also be split up into shares and distributed among zed Revocation Key subpacket is uneven and unreliable.</t>
multiple parties, requiring some subset of those parties to collaborate before </li>
the escrowed Revocation Signature is recreated.</t> <li>
<t>If the fingerprint mechanism suffers a cryptanalytic flaw, the es
</section> crowed Revocation Signature is not affected.</t>
<section anchor="CSPRNG"><name>Random Number Generation and Seeding</name> </li>
</ul>
<t>OpenPGP requires a cryptographically secure pseudorandom number generator (CS <t>A Revocation Signature may also be split up into shares and distribut
PRNG). ed among multiple parties, requiring some subset of those parties to collaborate
In most cases, the operating system provides an appropriate facility such as a < before the escrowed Revocation Signature is recreated.</t>
spanx style="verb">getrandom()</spanx> syscall on Linux or BSD, which should be </section>
used absent other (for example, performance) concerns. <section anchor="CSPRNG">
It is <bcp14>RECOMMENDED</bcp14> to use an existing CSPRNG implementation in pre <name>Random Number Generation and Seeding</name>
ference to crafting a new one. <t>OpenPGP requires a cryptographically secure pseudorandom number gener
Many adequate cryptographic libraries are already available under favorable lice ator (CSPRNG). In most cases, the operating system provides an appropriate facil
nse terms. ity such as a <tt>getrandom()</tt> syscall on Linux or BSD, which should be used
Should those prove unsatisfactory, <xref target="RFC4086"/> provides guidance on absent other (for example, performance) concerns.
the generation of random values.</t> It is <bcp14>RECOMMENDED</bcp14> to use an existing CSPRNG implementation as opp
osed to crafting a new one.
<t>OpenPGP uses random data with three different levels of visibility:</t> Many adequate cryptographic libraries are already available under favorable lice
nse terms. Should those prove unsatisfactory, <xref target="RFC4086"/> provides
<t><list style="symbols"> guidance on the generation of random values.</t>
<t>In publicly-visible fields such as nonces, IVs, public padding material, or <t>OpenPGP uses random data with three different levels of visibility:</
salts,</t> t>
<t>In shared-secret values, such as session keys for encrypted data or padding <ul spacing="normal">
material within an encrypted packet, and</t> <li>
<t>In entirely private data, such as asymmetric key generation.</t> <t>In publicly visible fields such as nonces, IVs, public padding ma
</list></t> terial, or salts.</t>
</li>
<t>With a properly functioning CSPRNG, this range of visibility does not present <li>
a security problem, as it is not feasible to determine the CSPRNG state from it <t>In shared-secret values, such as session keys for encrypted data
s output. or padding material within an encrypted packet.</t>
</li>
<li>
<t>In entirely private data, such as asymmetric key generation.</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> 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 att
<t>An implementation can provide extra security against this form of attack by u ack by using separate CSPRNGs to generate random data with different levels of v
sing separate CSPRNGs to generate random data with different levels of visibilit isibility.</t>
y.</t> </section>
<section anchor="traffic-analysis">
</section> <name>Traffic Analysis</name>
<section anchor="traffic-analysis"><name>Traffic Analysis</name> <t>When sending OpenPGP data through the network, the size of the data m
ay leak information to an attacker. There are circumstances where such a leak co
<t>When sending OpenPGP data through the network, the size of the data may leak uld be unacceptable from a security perspective.</t>
information to an attacker. <t>For example, if possible cleartext messages for a given protocol are
There are circumstances where such a leak could be unacceptable from a security known to be either <tt>yes</tt> (three octets) or <tt>no</tt> (two octets) and t
perspective.</t> he messages are sent within a Symmetrically Encrypted Integrity Protected Data p
acket, the length of the encrypted message will reveal the contents of the clear
<t>For example, if possible cleartext messages for a given protocol are known to text.</t>
be either <spanx style="verb">yes</spanx> (three octets) and <spanx style="verb <t>In another example, sending an OpenPGP Transferable Public Key over a
">no</spanx> (two octets) and the messages are sent within a Symmetrically-Encry n encrypted network connection might reveal the length of the certificate. Since
pted Integrity Protected Data packet, the length of the encrypted message will r the length of an OpenPGP certificate varies based on the content, an external o
eveal the contents of the cleartext.</t> bserver interested in metadata (e.g., which individual is trying to contact anot
her individual) may be able to guess the identity of the certificate sent, if it
<t>In another example, sending an OpenPGP Transferable Public Key over an encryp s length is unique.</t>
ted network connection might reveal the length of the certificate. <t>In both cases, an implementation can adjust the size of the compound
Since the length of an OpenPGP certificate varies based on the content, an exter structure by including a Padding packet (see <xref target="padding-packet"/>).</
nal observer interested in metadata (who is trying to contact whom) may be able t>
to guess the identity of the certificate sent, if its length is unique.</t> </section>
<section anchor="surreptitious-forwarding">
<t>In both cases, an implementation can adjust the size of the compound structur <name>Surreptitious Forwarding</name>
e by including a Padding packet (see <xref target="padding-packet"/>).</t> <t>When an attacker obtains a signature for some text, e.g., by receivin
g a signed message, they may be able to use that signature maliciously by sendin
</section> g a message purporting to come from the original sender, with the same body and
<section anchor="surreptitious-forwarding"><name>Surreptitious Forwarding</name> signature, to a different recipient.
<t>When an attacker obtains a signature for some text, e.g. by receiving a signe
d message, they may be able to use that signature maliciously by sending a messa
ge 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-fing erprint"/>).</t> To prevent this, an implementation <bcp14>SHOULD</bcp14> implement the Intended Recipient Fingerprint signature subpacket (<xref target="intended-recipient-fing erprint"/>).</t>
</section>
</section> <section anchor="subpacket-section-guidance">
<section anchor="subpacket-section-guidance"><name>Hashed vs. Unhashed Subpacket <name>Hashed vs. Unhashed Subpackets</name>
s</name> <t>Each OpenPGP signature can have subpackets in two different sections.
<t>Each OpenPGP signature can have subpackets in two different sections.
The first set of subpackets (the "hashed section") is covered by the signature i tself. The first set of subpackets (the "hashed section") is covered by the signature i tself.
The second set has no cryptographic protections, and is used for advisory materi The second set has no cryptographic protections and is used for advisory materia
al only, including locally-stored annotations about the signature.</t> l only, including locally stored annotations about the signature.</t>
<t>For example, consider an implementation working with a specific signa
<t>For example, consider an implementation working with a specific signature tha ture that happens to know that the signature was made by a certain key, even tho
t happens to know that the signature was made by a certain key, even though the ugh the signature contains no Issuer Fingerprint subpacket (<xref target="issuer
signature contains no Issuer Fingerprint subpacket (<xref target="issuer-fingerp -fingerprint-subpacket"/>) in the hashed section.
rint-subpacket"/>) in the hashed section. That implementation <bcp14>MAY</bcp14> synthesize an Issuer Fingerprint subpacke
That implementation <bcp14>MAY</bcp14> synthesize an Issuer Fingerprint subpacke t and store it in the unhashed section so that it will be able to recall which k
t and store it in the unhashed section so that in the future it will be able to ey issued the signature in the future.</t>
recall which key issued the signature.</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
<t>Some subpackets are only useful when they are in the hashed section, and an i unknown provenance in the unhashed section.
mplementation <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 keyho lder when encrypting SEIPD v2 data to the key. For example, a Preferred AEAD Ciphersuites subpacket (<xref target="preferred-v2 -seipd"/>) in a direct key self-signature indicates the preferences of the keyho lder when encrypting SEIPD v2 data to the key.
An implementation that observes such a subpacket found in the unhashed section w ould 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> An implementation that observes such a subpacket found in the unhashed section w ould 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> <section anchor="compress-bomb">
<section anchor="compress-bomb"><name>Malicious Compressed Data</name> <name>Malicious Compressed Data</name>
<t>It is possible to form a compression quine that produces itself upon
<t>It is possible to form a compression quine that produces itself upon decompre decompression, leading to infinite regress in any implementation willing to pars
ssion, leading to infinite regress in any implementation willing to parse arbitr e arbitrary numbers of layers of compression. This could cause resource exhausti
ary numbers of layers of compression. on, which itself could lead to termination by the operating system. If the opera
This could cause resource exhaustion which itself could lead to it being termina ting creates a "crash report", that report could contain confidential informatio
ted by the operating system. n.</t>
If the operating system would create a "crash report", that report could contain <t>An OpenPGP implementation <bcp14>SHOULD</bcp14> limit the number of l
confidential information.</t> ayers of compression it is willing to decompress in a single message.</t>
</section>
<t>An OpenPGP implementation <bcp14>SHOULD</bcp14> limit the number of layers of </section>
compression it is willing to decompress in a single message.</t> <section anchor="implementation-considerations">
<name>Implementation Considerations</name>
</section> <t>This section is a collection of comments to help an implementer who has
</section> a particular interest in backward compatibility. Often the differences are smal
<section anchor="implementation-considerations"><name>Implementation Considerati l, but small differences are frequently more vexing than large differences. Thus
ons</name> , this is a non-comprehensive list of potential problems and gotchas for a devel
oper who is trying to achieve backward compatibility.</t>
<t>This section is a collection of comments to help an implementer, particularly <ul spacing="normal">
with an eye to backward compatibility. <li>
Often the differences are small, but small differences are frequently more vexin <t>There are many possible ways for two keys to have the same key mate
g than large differences. rial but different fingerprints (and thus different Key IDs). For example, since
Thus, this is a non-comprehensive list of potential problems and gotchas for a d a v4 fingerprint is constructed by hashing the key creation time along with oth
eveloper who is trying to be backward-compatible.</t> er things, two v4 keys created at different times yet with the same key material
will have different fingerprints.</t>
<t><list style="symbols"> </li>
<t>There are many ways possible for two keys to have the same key material, bu <li>
t different fingerprints (and thus Key IDs). <t>OpenPGP does not put limits on the size of public keys.
For example, since a v4 fingerprint is constructed by hashing the key creation t
ime along with other things, two v4 keys created at different times, yet with th
e same key material will have different fingerprints.</t>
<t>OpenPGP does not put limits on the size of public keys.
However, larger keys are not necessarily better keys. However, larger keys are not necessarily better keys.
Larger keys take more computation time to use, and this can quickly become impra ctical. Larger keys take more computation time to use, and this can quickly become impra ctical.
Different OpenPGP implementations may also use different upper bounds for public Different OpenPGP implementations may also use different upper bounds for public
key sizes, and so care should be taken when choosing sizes to maintain interope key sizes, so care should be taken when choosing sizes to maintain interoperabi
rability.</t> lity.</t>
<t>ASCII armor is an optional feature of OpenPGP. </li>
The OpenPGP working group strives for a minimal set of mandatory-to-implement fe <li>
atures, and since there could be useful implementations that only use binary obj <t>ASCII armor is an optional feature of OpenPGP.
ect formats, this is not a "<bcp14>MUST</bcp14>" feature for an implementation. The OpenPGP Working Group strives for a minimal set of mandatory-to-implement fe
atures, and since there could be useful implementations that only use binary obj
ect 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 sig natures may find ASCII armor unnecessary. For example, an implementation that is using OpenPGP as a mechanism for file sig natures 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. 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 indiscrim inately, an implementation that does not implement ASCII armor may find itself w ith compatibility issues with general-purpose implementations. Since most implementations allow binary and armored objects to be used indiscrim inately, an implementation that does not implement ASCII armor may find itself w ith compatibility issues with general-purpose implementations.
Moreover, implementations of OpenPGP-MIME <xref target="RFC3156"/> already have Moreover, implementations of OpenPGP-MIME <xref target="RFC3156"/> already have
a requirement for ASCII armor so those implementations will necessarily have sup a requirement for ASCII armor, so those implementations will necessarily have su
port.</t> pport.</t>
<t>What this document calls Legacy packet format <xref target="legacy-packet-f </li>
ormat"/> is what older documents called the "old packet format". <li>
<t>What this document calls the "Legacy packet 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" />. It is the packet format used by implementations predating <xref target="RFC2440" />.
Older RFCs called the current OpenPGP packet format <xref target="openpgp-packet The current "OpenPGP packet format" (<xref target="openpgp-packet-format"/>) was
-format"/> the "new packet format". called the "new packet format" by older RFCs. This is the format introduced in
This is the format introduced in <xref target="RFC2440"/> and maintained through <xref target="RFC2440"/> and maintained through <xref target="RFC4880"/> to this
<xref target="RFC4880"/> to this document.</t> document.</t>
</list></t> </li>
</ul>
<section anchor="constrained-legacy-fingerprint-storage-for-v6-keys"><name>Const <section anchor="constrained-legacy-fingerprint-storage-for-v6-keys">
rained Legacy Fingerprint Storage for v6 Keys</name> <name>Constrained Legacy Fingerprint Storage for v6 Keys</name>
<t>Some OpenPGP implementations have fixed length constraints for key fi
<t>Some OpenPGP implementations have fixed length constraints for key fingerprin ngerprint storage that will not fit all 32 octets of a v6 fingerprint.
t storage that will not fit all 32 octets of a v6 fingerprint.
For example, <xref target="OPENPGPCARD"/> reserves 20 octets for each stored fin gerprint.</t> For example, <xref target="OPENPGPCARD"/> reserves 20 octets for each stored fin gerprint.</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 specifi
cation for the constrained environment has explicit guidance for storing a v6 fi
ngerprint that distinguishes it from a v4 fingerprint. An implementation interac
ting with such a constrained field <bcp14>SHOULD</bcp14> directly calculate the
v6 fingerprint from public key material and associated metadata instead of relyi
ng on the constrained field.</t>
</section>
</section>
<section anchor="iana-considerations">
<t>An OpenPGP implementation <bcp14>MUST NOT</bcp14> attempt to map any part of <name>IANA Considerations</name>
a v6 fingerprint to such a constrained field unless the relevant spec for the co
nstrained environment has explicit guidance for storing a v6 fingerprint that di
stinguishes 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> <!-- #44 [rfced] IANA-related updates:
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>
<t>This document obsoletes <xref target="RFC4880"/>. 9) [rfced] Should "a packet" be "a packet tag" as shown in the IANA registry <ht
IANA is requested to update all registration information that references <xref t tps://www.iana.org/assignments/openpgp>?
arget="RFC4880"/> to instead reference this RFC.</t>
<section anchor="rename-pretty-good-privacy-pgp-protocol-group-to-openpgp"><name Original:
>Rename "Pretty Good Privacy (PGP)" Protocol Group to "OpenPGP"</name> | 0 | yes | Reserved - a packet | | |
| | | MUST NOT have this | | |
| | | packet type ID | | |
<t>IANA bundles a set of registries associated with a particular protocol into a IANA description:
"protocol group". Reserved - a packet tag MUST NOT have this packet type ID
This document requests IANA to update 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>) to "OpenPGP".
If renaming the protocol group results in new URLs for the registries in this pr
otocol group, please arrange for a permanent redirection (e.g., HTTP 301) from t
he existing URLs to the new URLs.
All further updates specified below are for registries within this same "OpenPGP
" protocol group.</t>
</section> [PH] Maybe just change it to: "this packet type ID MUST NOT be used"
<section anchor="registries-to-be-renamed-and-updated"><name>Registries to be Re (Table 3 - OpenPGP Packet Types registry)
named and Updated</name>
<t>IANA is requested to rename the "PGP String-to-Key (S2K)" registry to "OpenPG P String-to-Key (S2K) Types" and update its content to <xref target="s2k-types-r egistry"/>.</t> -Table 21 (Section 9.3)-
<t>IANA is requested to rename the "PGP Packet Types/Tags" registry to "OpenPGP 44 b) Under ID 2, does "TripleDES (DES-EDE, [SP800-67]" mean
Packet Types" and update its content to <xref target="packet-types-registry"/>.< "TripleDES (or DES-EDE) [SP800-67]"? If not,
/t> please clarify.
<t>IANA is requested to rename the "PGP User Attribute Types" registry to "OpenP GP User Attribute Subpacket Types" and update its content to <xref target="user- attr-subpacket-types-registry"/>.</t> -Yes.
<t>IANA is requested to rename the "Image Format Subpacket Types" registry to "O c) Under IDs 2, 3, and 4, are the parentheses present in the
penPGP Image Attribute Encoding Format" and update its content to <xref target=" "Algorithm" column to denote that they are different from the
image-attr-encoding-format-registry"/>.</t> descriptions for IDs 7-13? If not, can the parentheses be
removed for consistency as shown below?
<t>IANA is requested to rename the "Key Server Preference Extensions" registry t Original:
o "OpenPGP Key Server Preference Flags" and update its contents to <xref target= 2 TripleDES (DES-EDE), [SP800-67] - 168 bit key derived from 192)
"key-server-preference-flags-registry"/>.</t> 3 CAST5 (128 bit key, as per [RFC2144])
4 Blowfish (128 bit key, 16 rounds)
<t>IANA is requested to rename the "Reason for Revocation Extensions" registry t Perhaps:
o "OpenPGP Reason for Revocation Code" and update its contents to <xref target=" 2 TripleDES (or DES-EDE) [SP800-67] with 168-bit key derived from 192
reason-for-revocation-code-registry"/>.</t> 3 CAST5 with 128-bit key [RFC2144]
4 Blowfish with 128-bit key, 16 rounds [BLOWFISH]
<t>IANA is requested to rename the "Key Flags Extensions" registry to "OpenPGP K ey Flags" and update its contents to <xref target="key-flags-registry"/>.</t> -Looks good.
<t>IANA is requested to rename the "Implementation Features" registry to "OpenPG P Features Flags" and update its contents to <xref target="features-flags-regist ry"/>.</t> f) Please consider whether the following registry titles should be plural.
<t>IANA is requested to rename the "Public Key Algorithms" registry to "OpenPGP Registry titles:
Public Key Algorithms" and update its contents to <xref target="pubkey-algo-regi OpenPGP Secret Key Encryption (S2K Usage Octet)
stry"/>.</t> 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
<t>IANA is requested to rename the "Symmetric Key Algorithms" registry to "OpenP Perhaps:
GP Symmetric Key Algorithms" and update its contents to <xref target="symkey-alg OpenPGP Secret Key Encryption (S2K Usage Octets) - no
orithms-registry"/>.</t> OpenPGP Reason for Revocation Codes - no
OpenPGP Key IDs and Fingerprints - yes (Table 12)
OpenPGP Image Attribute Versions - yes (Table 14)
OpenPGP Armor Header Lines - yes (Table 16)
OpenPGP Armor Header Keys - yes (Table 17)
OpenPGP ECC Curve OIDs and Usage - yes (Table 19)
<t>IANA is requested to rename the "Compression Algorithms" registry to "OpenPGP Compression Algorithms" and update its contents to <xref target="compression-al gorithms-registry"/>.</t> g) Please consider whether "Packet" should be plural in the following IANA descr iptions within the "OpenPGP Packet Types" registry, as they seemingly refer to m ore than one ID.
<t>IANA is requested to rename the "Hash Algorithms" registry to "OpenPGP Hash A Unassigned Critical Packet - yes (Table 3)
lgorithms" and update its contents to <xref target="hash-algorithms-registry"/>. Unassigned Non-Critical Packet - yes
</t>
<t>IANA is requested to rename the "Signature Subpacket Types" registry to "Open PGP Signature Subpacket Types" and update its contents to <xref target="signatur e-subpacket-types-registry"/>.</t> i) Please consider whether these table entries should be made consistent - perha ps "Private or Experimental Use"?
</section> Private/Experimental S2K
<section anchor="removed-registries"><name>Registries to be Removed</name> Private or Experimental Values
Private or Experimental
Private/Experimental Use
Private or Experimental Use
Private/Experimental algorithm
<t>IANA is requested to remove the empty "New Packet Versions" registry.</t> [PH] "Private or Experimental Use"
<t>A tombstone note should be added to the OpenPGP protocol group with the follo wing content: Those wishing to use the removed "New Packet Versions" registry sh ould instead register new versions of the relevant packets in the "OpenPGP Key a nd Signature Versions", "OpenPGP Key ID and Fingerprint" and "OpenPGP Encrypted Message Packet Versions" registries.</t> j) For tables in which the reference appears in the Description column, would yo u like a Reference column to be added? For examples, see tables 22, 23, and 24.
</section> - Tables 21, 22, and 23 were udpated.
<section anchor="added-registries"><name>Registries to be Added</name> -->
<t>IANA is requested to add the following registries in the OpenPGP protocol gro <t>This document obsoletes <xref target="RFC4880"/>. IANA has updated all
up:</t> registration information that references <xref target="RFC4880"/> to reference t
his RFC instead.</t>
<section anchor="rename-pretty-good-privacy-pgp-protocol-group-to-openpgp"
>
<name>Renamed Protocol Group</name>
<t>IANA bundles a set of registries associated with a particular protoco
l into a "protocol group". IANA has updated the name of the "Pretty Good Privacy
(PGP)" protocol group (i.e., the group of registries described at <eref target=
"https://www.iana.org/assignments/pgp-parameters" brackets="angle"/>) to "OpenPG
P". IANA has arranged a permanent redirect from the existing URL to the new URL
for the registries in this protocol group. All further updates specified below a
re for registries within this same OpenPGP protocol group.</t>
</section>
<section anchor="registries-to-be-renamed-and-updated">
<name>Renamed and Updated Registries</name>
<!-- tab 1 ok -->
<t>IANA has renamed the "PGP String-to-Key (S2K)" registry to "OpenPGP S
tring-to-Key (S2K) Types" and updated its contents as shown in <xref target="s2
k-types-registry"/>.</t>
<t><list style="symbols"> <!-- tab 3 ok -->
<t>OpenPGP Secret Key Encryption (S2K Usage Octet) containing <xref target="se <t>IANA has renamed the "PGP Packet Types/Tags" registry to "OpenPGP Packet Type
cret-key-protection-registry"/>.</t> s" and updated its contents as shown in <xref target="packet-types-registry"/>.<
<t>OpenPGP Signature Types containing <xref target="signature-types-registry"/ /t>
>.</t>
<t>OpenPGP Signature Notation Data Subpacket Notation Flags containing <xref t
arget="sig-note-data-note-flags-registry"/>.</t>
<t>OpenPGP Signature Notation Data Subpacket Types containing <xref target="si
g-note-data-subpacket-types"/>.</t>
<t>OpenPGP Key ID and Fingerprint containing <xref target="key-id-fingerprint-
registry"/>.</t>
<t>OpenPGP Image Attribute Version containing <xref target="image-attribute-ve
rsion-registry"/>.</t>
<t>OpenPGP Armor Header Line containing <xref target="armor-header-line-regist
ry"/>.</t>
<t>OpenPGP Armor Header Key containing <xref target="armor-header-key-registry
"/>.</t>
<t>OpenPGP ECC Curve OID and Usage containing <xref target="ecc-oid-usage-regi
stry"/>.</t>
<t>OpenPGP ECC Curve-specific Wire Formats containing <xref target="ecc-wire-f
ormats-registry"/>.</t>
<t>OpenPGP Hash Algorithm Identifiers for RSA Signatures use of EMSA-PKCS1-v1_
5 Padding containing <xref target="emsa-hash-oids-registry"/>.</t>
<t>OpenPGP AEAD Algorithms containing <xref target="aead-algorithms-registry"/
>.</t>
<t>OpenPGP Encrypted Message Packet Versions containing <xref target="encrypte
d-packet-versions-registry"/>.</t>
<t>OpenPGP Key and Signature Versions containing <xref target="signed-packet-v
ersions-registry"/>.</t>
<t>OpenPGP Elliptic Curve Point Wire Formats containing <xref target="ec-point
-wire-formats-registry"/>.</t>
<t>OpenPGP Elliptic Curve Scalar Encodings containing <xref target="ec-scalar-
wire-formats-registry"/>.</t>
<t>OpenPGP ECDH KDF and KEK Parameters containing <xref target="ecdh-kdf-kek-p
arameters-registry"/>.</t>
</list></t>
</section> <!-- tab 5 ok -->
<section anchor="registration-policies"><name>Registration Policies</name> <t>IANA has renamed the "Signature Subpacket Types" registry to "OpenPGP
Signature Subpacket Types" and updated its contents as shown in <xref target="s
ignature-subpacket-types-registry"/>.</t>
<t>IANA is requested to set all registries within the OpenPGP protocol group to <!-- tab 8 ok -->
use the SPECIFICATION <bcp14>REQUIRED</bcp14> registration policy, see <xref sec <t>IANA has renamed the "Key Server Preference Extensions" registry to "OpenPGP
tion="4.6" sectionFormat="of" target="RFC8126"/> with the exception of the regis Key Server Preference Flags" and updated its contents as shown in <xref target="
tries listed in <xref target="rfc-required-registries"/>, below. key-server-preference-flags-registry"/>.</t>
This policy means that review and approval by a designated expert is required, a
nd that the IDs and their meanings must be documented in a permanent and readily
available public specification, in sufficient detail so that interoperability b
etween independent implementations is possible.</t>
<section anchor="rfc-required-registries"><name>Registries that are RFC REQUIRED <!-- tab 9 ok -->
</name> <t>IANA has renamed the "Key Flags Extensions" registry to "OpenPGP Key
Flags" and updated its contents as shown in <xref target="key-flags-registry"/>.
</t>
<t>The following registries use the RFC <bcp14>REQUIRED</bcp14> registration pol <!-- tab 10 ok -->
icy, as described in <xref section="4.7" sectionFormat="of" target="RFC8126"/>:< <t>IANA has renamed the "Reason for Revocation Extensions" registry to "OpenPGP
/t> Reason for Revocation (Revocation Octet)" and updated its contents as shown in <
xref target="reason-for-revocation-code-registry"/>.</t>
<t><list style="symbols"> <!-- tab 11 ok -->
<t>OpenPGP Packet Types registry (<xref target="packet-types-registry"/>)</t> <t>IANA has renamed the "Implementation Features" registry to "OpenPGP F
<t>OpenPGP Key and Signature Versions registry (<xref target="signed-packet-ve eatures Flags" and updated its contents as shown in <xref target="features-flags
rsions-registry"/>)</t> -registry"/>.</t>
<t>OpenPGP Key ID and Fingerprint registry (<xref target="key-id-fingerprint-r
egistry"/>)</t>
<t>OpenPGP Encrypted Message Packet Versions registry (<xref target="encrypted
-packet-versions-registry"/>)</t>
</list></t>
</section> <!-- tab 13 ok -->
</section> <t>IANA has renamed the "PGP User Attribute Types" registry to "OpenPGP
<section anchor="designated-experts"><name>Designated Experts</name> User Attribute Subpacket Types" and updated its contents as shown in <xref targe
t="user-attr-subpacket-types-registry"/>.</t>
<t>The designated experts will determine whether the new registrations retain th <!-- tab 15 ok -->
e security properties that are expected by the base implementation and that thes <t>IANA has renamed the "Image Format Subpacket Types" registry to "Open
e new registrations do not cause interoperability issues with existing implement PGP Image Attribute Encoding Format" and updated its contents as shown in <xref
ations other than not producing or consuming the IDs associated with these new r target="image-attr-encoding-format-registry"/>.</t>
egistrations.
Registration proposals that fail to meet these criteria could instead be propose
d as new work items for the OpenPGP working group or its successor.</t>
<t>The subsections below describe specific guidance for classes of registry upda <!-- tab 18 ok -->
tes that a designated expert will consider.</t> <t>IANA has renamed the "Public Key Algorithms" registry to "OpenPGP Pub
lic Key Algorithms" and updated its contents as shown in <xref target="pubkey-al
go-registry"/>.</t>
<t>The designated experts should also consider <xref target="meta-considerations <!-- tab 21 ok -->
-for-expansion"/> when reviewing proposed additions to the OpenPGP registries.</ <t>IANA has renamed the "Symmetric Key Algorithms" registry to "OpenPGP
t> Symmetric Key Algorithms" and updated its contents as shown in <xref target="sym
key-algorithms-registry"/>.</t>
<section anchor="key-and-signature-versions"><name>Key and Signature Versions</n <!-- tab 22 ok -->
ame> <t>IANA has renamed the "Compression Algorithms" registry to "OpenPGP Co
mpression Algorithms" and updated its contents as shown in <xref target="compres
sion-algorithms-registry"/>.</t>
<t>When defining a new version of OpenPGP keys or signatures, <xref target="sign <!-- tab 23 ok -->
ed-packet-versions-registry"/> should be updated, <t>IANA has renamed the "Hash Algorithms" registry to "OpenPGP Hash Algo
When a new version of OpenPGP key is defined, <xref target="key-id-fingerprint-r rithms" and updated its contents as shown in <xref target="hash-algorithms-regis
egistry"/> should also be updated.</t> try"/>.</t>
</section> </section>
<section anchor="encryption-versions"><name>Encryption Versions</name> <section anchor="removed-registries">
<name>Removed Registry</name>
<t>IANA has marked the empty "New Packet Versions" registry as OBSOLETE.
</t>
<t>A tombstone note has been added to the OpenPGP protocol group with th
e following content:</t>
<t>When defining a new version of the Symmetrically Encrypted Integrity Protecte <blockquote>Those wishing to use the removed "New Packet Versions" registry shou
d Data Packet (<xref target="seipd"/>), Public Key Encrypted Session Key Packet ld instead register new versions of the relevant packets in the "OpenPGP Key and
(<xref target="pkesk"/>), and/or Symmetric Key Encrypted Session Key Packet (<xr Signature Versions", "OpenPGP Key IDs and Fingerprints", and "OpenPGP Encrypted
ef target="skesk"/>), the registry from <xref target="encrypted-packet-versions- Message Packet Versions" registries.</blockquote>
registry"/> needs to be updated. </section>
When the SEIPD is updated, consider also adding a corresponding flag to <xref ta <section anchor="added-registries">
rget="features-flags-registry"/>.</t> <name>Added Registries</name>
<t>IANA has added the following registries in the OpenPGP protocol 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)" (<xref target="
secret-key-protection-registry"/>).</t>
</li>
</section> <!-- tab 4 ok -->
<section anchor="algorithms"><name>Algorithms</name> <li>
<t>"OpenPGP Signature Types" (<xref target="signature-types-registry
"/>).</t>
</li>
<t><xref target="constants"/> lists the cryptographic and compression algorithms <!-- tab 6 ok -->
that OpenPGP uses. <li>
Adding new algorithms is usually simple, in some cases as little as allocating a <t>"OpenPGP Signature Notation Data Subpacket Notation Flags" (<xref
n ID and pointing to a reference. target="sig-note-data-note-flags-registry"/>).</t>
But some algorithm registries require some subtle additional details when a new </li>
algorithm is introduced.</t>
<section anchor="elliptic-curve-algorithms"><name>Elliptic Curve Algorithms</nam <!-- tab 7 ok -->
e> <li>
<t>"OpenPGP Signature Notation Data Subpacket Types" (<xref target="
sig-note-data-subpacket-types"/>).</t>
</li>
<t>To register a new elliptic curve for use with OpenPGP, its OID needs to be re <!-- tab 12 ok - made this plural -->
gistered in <xref target="ecc-oid-usage-registry"/>, its wire format needs to be <li>
documented in <xref target="ecc-wire-formats-registry"/>, and if used for ECDH, <t>"OpenPGP Key IDs and Fingerprints" (<xref target="key-id-fingerpr
its KDF and KEK parameters must be populated in <xref target="ecdh-kdf-kek-para int-registry"/>).</t>
meters-registry"/>. </li>
If the wire format(s) used are not already defined in <xref target="ec-point-wir
e-formats-registry"/> or <xref target="ec-scalar-wire-formats-registry"/>, they
should be defined there as well.</t>
</section> <!-- tab 14 ok - made this plural -->
<section anchor="symmetric-key-algorithms"><name>Symmetric-Key Algorithms</name> <li>
<t>"OpenPGP Image Attribute Versions" (<xref target="image-attribute
-version-registry"/>).</t>
</li>
<t>When registering a new symmetric cipher with a block size of 64 or 128 bits a <!-- tab 16 ok - made this plural -->
nd a key size that is a multiple of 64 bits, no new considerations are needed.</ <li>
t> <t>"OpenPGP Armor Header Lines" (<xref target="armor-header-line-reg
istry"/>).</t>
</li>
<t>If the new cipher has a different block size, there needs to be additional do <!-- tab 17 ok - made this plural -->
cumentation describing how to use the cipher in CFB mode.</t> <li>
<t>"OpenPGP Armor Header Keys" (<xref target="armor-header-key-regis
try"/>).</t>
</li>
<t>If the new cipher has an unusual key size, then padding needs to be considere <!-- tab 19 ok - made this plural -->
d for X25519 and X448 keywrap, which currently needs no padding.</t> <li>
<t>"OpenPGP ECC Curve OIDs and Usage" (<xref target="ecc-oid-usage-r
egistry"/>).</t>
</li>
</section> <!-- tab 20 ok -->
<section anchor="hash-algorithms"><name>Hash Algorithms</name> <li>
<t>"OpenPGP ECC Curve-Specific Wire Formats" (<xref target="ecc-wire
-formats-registry"/>).</t>
</li>
<t>When registering a new hash algorithm (in <xref target="hash-algorithms-regis <!-- tab 24 ok - added apostrophe and capped "use" -->
try"/>), if the algorithm is also to be used with RSA signing schemes, it must a <li>
lso have an entry in <xref target="emsa-hash-oids-registry"/>.</t> <t>"OpenPGP Hash Algorithm Identifiers for RSA Signatures' Use of EM
SA-PKCS1-v1_5 Padding" (<xref target="emsa-hash-oids-registry"/>).</t>
</li>
</section> <!-- tab 25 ok -->
</section> <li>
</section> <t>"OpenPGP AEAD Algorithms" (<xref target="aead-algorithms-registry
</section> "/>).</t>
</li>
</middle> <!-- tab 26 ok -->
<li>
<t>"OpenPGP Encrypted Message Packet Versions" (<xref target="encryp
ted-packet-versions-registry"/>).</t>
</li>
<back> <!-- tab 27 ok -->
<li>
<t>"OpenPGP Key and Signature Versions" (<xref target="signed-packet
-versions-registry"/>).</t>
</li>
<references title='Normative References'> <!-- tab 28 ok -->
<li>
<t>"OpenPGP Elliptic Curve Point Wire Formats" (<xref target="ec-poi
nt-wire-formats-registry"/>).</t>
</li>
<reference anchor="BLOWFISH" target="http://www.counterpane.com/bfsverlag.html"> <!-- tab 29 ok -->
<front> <li>
<title>Description of a New Variable-Length Key, 64-Bit Block Cipher (Blowfi <t>"OpenPGP Elliptic Curve Scalar Encodings" (<xref target="ec-scala
sh)</title> r-wire-formats-registry"/>).</t>
<author initials="B." surname="Schneier"> </li>
<organization></organization>
</author>
<date year="1993" month="December"/>
</front>
<seriesInfo name="Fast Software Encryption, Cambridge Security Workshop Procee
dings" value="Springer-Verlag, 1994, pp191-204"/>
</reference>
<reference anchor="BZ2" target="http://www.bzip.org/">
<front>
<title>The Bzip2 and libbzip2 home page</title>
<author initials="J." surname="Seward" fullname="Julian Seward, jseward@acm.
org">
<organization></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>
</author>
<author initials="P." surname="Rogaway">
<organization></organization>
</author>
<author initials="D." surname="Wagner">
<organization></organization>
</author>
<date year="2003" month="April"/>
</front>
</reference>
<reference anchor="ELGAMAL" >
<front>
<title>A Public-Key Cryptosystem and a Signature Scheme Based on Discrete Lo
garithms</title>
<author initials="T." surname="Elgamal">
<organization></organization>
</author>
<date year="1985"/>
</front>
<seriesInfo name="IEEE Transactions on Information Theory" value="v. IT-31, n.
4, 1985, pp. 469-472"/>
</reference>
<reference anchor="IDEA" >
<front>
<title>On the design and security of block ciphers</title>
<author initials="X." surname="Lai">
<organization></organization>
</author>
<date year="1992"/>
</front>
<seriesInfo name="ETH Series in Information Processing, J.L. Massey (editor)"
value="Vol. 1, Hartung-Gorre Verlag Konstanz, Technische Hochschule (Zurich)"/>
</reference>
<reference anchor="ISO10646" target="https://www.iso.org/standard/76835.html">
<front>
<title>Information Technology - Universal Multiple-octet coded Character Set
(UCS) - Part 1: Architecture and Basic Multilingual Plane</title>
<author >
<organization>International Organization for Standardization</organization
>
</author>
<date year="2020"/>
</front>
<seriesInfo name="ISO" value="Standard 10646-1"/>
</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>
<date year="2011" month="May" day="14"/>
</front>
<seriesInfo name="ISO" value="ISO/IEC 10918-5"/>
</reference>
<reference anchor='RFC1321'> <!-- tab 30 ok -->
<front> <li>
<title>The MD5 Message-Digest Algorithm</title> <t>"OpenPGP ECDH KDF and KEK Parameters" (<xref target="ecdh-kdf-kek
<author fullname='R. Rivest' initials='R.' surname='Rivest'/> -parameters-registry"/>).</t>
<date month='April' year='1992'/> </li>
<abstract> </ul>
<t>This document describes the MD5 message-digest algorithm. The algorithm </section>
takes as input a message of arbitrary length and produces as output a 128-bit " <section anchor="registration-policies">
fingerprint" or "message digest" of the input. This memo provides information fo <name>Registration Policies</name>
r the Internet community. It does not specify an Internet standard.</t> <t>All registries within the OpenPGP protocol group, with the exception
</abstract> of the registries listed in <xref target="rfc-required-registries"/>, use the Sp
</front> ecification Required registration policy; see <xref section="4.6" sectionFormat=
<seriesInfo name='RFC' value='1321'/> "of" target="RFC8126"/>.
<seriesInfo name='DOI' value='10.17487/RFC1321'/> This policy means that review and approval by a designated expert is required an
</reference> d that the IDs and their meanings must be documented in a permanent and readily
available public specification, in sufficient detail, so that interoperability b
etween independent implementations is possible.</t>
<section anchor="rfc-required-registries">
<name>Registries That Use RFC Required</name>
<t>The following registries use the RFC Required registration policy,
as described in <xref section="4.7" sectionFormat="of" target="RFC8126"/>:</t>
<ul spacing="normal">
<!-- tab 3 ok -->
<li>
<t>"OpenPGP Packet Types" (<xref target="packet-types-registry"/>)
.</t>
</li>
<!-- tab 12 ok -->
<li>
<t>"OpenPGP Key IDs and Fingerprints" (<xref target="key-id-finger
print-registry"/>).</t>
</li>
<reference anchor='RFC1950'> <!-- tab 26 ok -->
<front> <li>
<title>ZLIB Compressed Data Format Specification version 3.3</title> <t>"OpenPGP Encrypted Message Packet Versions" (<xref target="encr
<author fullname='P. Deutsch' initials='P.' surname='Deutsch'/> ypted-packet-versions-registry"/>).</t>
<author fullname='J-L. Gailly' surname='J-L. Gailly'/> </li>
<date month='May' year='1996'/> <!-- tab 27 ok -->
<abstract> <li>
<t>This specification defines a lossless compressed data format. This memo <t>"OpenPGP Key and Signature Versions" (<xref target="signed-pack
provides information for the Internet community. This memo does not specify an et-versions-registry"/>).</t>
Internet standard of any kind.</t> </li>
</abstract> </ul>
</front> </section>
<seriesInfo name='RFC' value='1950'/> </section>
<seriesInfo name='DOI' value='10.17487/RFC1950'/> <section anchor="designated-experts">
</reference> <name>Designated Experts</name>
<t>The designated experts will determine whether the new registrations r
etain the security properties that are expected by the base implementation and w
hether these new registrations do not cause interoperability issues with existin
g 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 propose
d as new work items for the OpenPGP Working Group or its successor.</t>
<t>The subsections below describe specific guidance for classes of regis
try updates that a designated expert will consider.</t>
<t>The designated experts should also consider <xref target="meta-consid
erations-for-expansion"/> when reviewing proposed additions to the OpenPGP proto
col group.</t>
<section anchor="key-and-signature-versions">
<name>Key and Signature Versions</name>
<t>When defining a new version of OpenPGP keys or signatures, the "Ope
nPGP Key and Signature Versions" registry (<xref target="signed-packet-versions-
registry"/>) should be updated. When a new version of OpenPGP key is defined, th
e "OpenPGP Key IDs and Fingerprints" registry (<xref target="key-id-fingerprint-
registry"/>) should also be updated.</t>
</section>
<section anchor="encryption-versions">
<name>Encryption Versions</name>
<t>When defining a new version of the Symmetrically Encrypted Integrit
y Protected Data Packet (<xref target="seipd"/>), Public Key Encrypted Session K
ey Packet (<xref target="pkesk"/>), and/or Symmetric Key Encrypted Session Key P
acket (<xref target="skesk"/>), the "OpenPGP Encrypted Message Packet Versions"
registry (<xref target="encrypted-packet-versions-registry"/>) should be updated
. When the SEIPD is updated, consider also adding a corresponding flag to the "O
penPGP Features Flags" registry (<xref target="features-flags-registry"/>).</t>
</section>
<section anchor="algorithms">
<name>Algorithms</name>
<t><xref target="constants"/> lists the cryptographic and compression
algorithms that OpenPGP uses.
Adding new algorithms is usually simple; in some cases, allocating an ID and poi
nting to a 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 Curve Algorithms</name>
<t>To register a new elliptic curve for use with OpenPGP, its OID ne
eds to be registered in the "OpenPGP ECC Curve OIDs and Usage" registry (<xref t
arget="ecc-oid-usage-registry"/>), its wire format needs to be documented in the
"OpenPGP ECC Curve-Specific Wire Formats" registry (<xref target="ecc-wire-form
ats-registry"/>), and if used for ECDH, its KDF and KEK parameters must be popul
ated in the "OpenPGP ECDH KDF and KEK Parameters" registry (<xref target="ecdh-k
df-kek-parameters-registry"/>). If the wire format(s) used is not already define
d in the "OpenPGP Elliptic Curve Point Wire Formats" (<xref target="ec-point-wir
e-formats-registry"/>) or "OpenPGP Elliptic Curve Scalar Encodings" (<xref targe
t="ec-scalar-wire-formats-registry"/>) registries, they should be defined there
as well.</t>
</section>
<section anchor="symmetric-key-algorithms">
<name>Symmetric-Key Algorithms</name>
<t>When registering a new symmetric cipher with a block size of 64 o
r 128 bits and a key size that is a multiple of 64 bits, no new considerations a
re needed.</t>
<t>If the new cipher has a different block size, there needs to be a
dditional 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 key wrapping, which currently needs no padding
.</t>
</section>
<section anchor="hash-algorithms">
<name>Hash Algorithms</name>
<t>When registering a new hash algorithm in the "OpenPGP Hash Algori
thms" 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 the "Ope
nPGP Hash Algorithm Identifiers for RSA Signatures' Use of EMSA-PKCS1-v1_5 Paddi
ng" registry (<xref target="emsa-hash-oids-registry"/>).</t>
</section>
</section>
</section>
</section>
</middle>
<back>
<reference anchor='RFC1951'> <references>
<front> <name>References</name>
<title>DEFLATE Compressed Data Format Specification version 1.3</title> <references>
<author fullname='P. Deutsch' initials='P.' surname='Deutsch'/> <name>Normative References</name>
<date month='May' year='1996'/>
<abstract>
<t>This specification defines a lossless compressed data format that compr
esses data using a combination of the LZ77 algorithm and Huffman coding, with ef
ficiency comparable to the best currently available general-purpose compression
methods. This memo provides information for the Internet community. This memo do
es not specify an Internet standard of any kind.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='1951'/>
<seriesInfo name='DOI' value='10.17487/RFC1951'/>
</reference>
<reference anchor='RFC2144'> <reference anchor="BLOWFISH" target="https://www.schneier.com/academic/a
<front> rchives/1994/09/description_of_a_new.html">
<title>The CAST-128 Encryption Algorithm</title> <front>
<author fullname='C. Adams' initials='C.' surname='Adams'/> <title>Description of a New Variable-Length Key, 64-Bit Block Cipher
<date month='May' year='1997'/> (Blowfish)</title>
<abstract> <author initials="B." surname="Schneier">
<t>There is a need in the Internet community for an unencumbered encryptio <organization/>
n algorithm with a range of key sizes that can provide security for a variety of </author>
cryptographic applications and protocols. This document describes an existing a <date year="1993" month="December"/>
lgorithm that can be used to satisfy this requirement. This memo provides inform </front>
ation for the Internet community. This memo does not specify an Internet standar <refcontent>Fast Software Encryption, Cambridge Security Workshop Proce
d of any kind.</t> edings, pp. 191-204</refcontent>
</abstract> </reference>
</front> <reference anchor="BZ2" target="https://sourceware.org/bzip2/">
<seriesInfo name='RFC' value='2144'/> <front>
<seriesInfo name='DOI' value='10.17487/RFC2144'/> <title>bzip2 and libbzip2</title>
</reference> <author>
<organization>bzip2</organization>
</author>
<date year="2010"/>
</front>
</reference>
<reference anchor='RFC2822'> <reference anchor="EAX" target="https://seclab.cs.ucdavis.edu/papers/eax
<front> .pdf">
<title>Internet Message Format</title> <front>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'/ <title>A Conventional Authenticated-Encryption Mode</title>
> <author initials="M." surname="Bellare">
<date month='April' year='2001'/> <organization/>
<abstract> </author>
<t>This document specifies a syntax for text messages that are sent betwee <author initials="P." surname="Rogaway">
n computer users, within the framework of "electronic mail" messages. [STANDARDS <organization/>
-TRACK]</t> </author>
</abstract> <author initials="D." surname="Wagner">
</front> <organization/>
<seriesInfo name='RFC' value='2822'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC2822'/> <date year="2003" month="April"/>
</reference> </front>
</reference>
<reference anchor='RFC2898'> <reference anchor="ELGAMAL">
<front> <front>
<title>PKCS #5: Password-Based Cryptography Specification Version 2.0</title <title>A Public Key Cryptosystem and a Signature Scheme Based on Dis
> crete Logarithms</title>
<author fullname='B. Kaliski' initials='B.' surname='Kaliski'/> <author initials="T." surname="Elgamal">
<date month='September' year='2000'/> <organization/>
<abstract> </author>
<t>This document provides recommendations for the implementation of passwo <date month="July" year="1985"/>
rd-based cryptography, covering key derivation functions, encryption schemes, me </front>
ssage-authentication schemes, and ASN.1 syntax identifying the techniques. This <seriesInfo name="DOI" value="10.1109/TIT.1985.1057074"/>
memo provides information for the Internet community.</t> <refcontent>IEEE Transactions on Information Theory, Vol. 31, Issue 4,
</abstract> pp. 469-472</refcontent>
</front> </reference>
<seriesInfo name='RFC' value='2898'/>
<seriesInfo name='DOI' value='10.17487/RFC2898'/>
</reference>
<reference anchor='RFC3156'> <reference anchor="IDEA">
<front> <front>
<title>MIME Security with OpenPGP</title> <title>On the Design and Security of Block Ciphers</title>
<author fullname='M. Elkins' initials='M.' surname='Elkins'/> <author initials="X." surname="Lai">
<author fullname='D. Del Torto' initials='D.' surname='Del Torto'/> <organization/>
<author fullname='R. Levien' initials='R.' surname='Levien'/> </author>
<author fullname='T. Roessler' initials='T.' surname='Roessler'/> <date month="January" year="1992"/>
<date month='August' year='2001'/> </front>
<abstract> <refcontent>ETH Series in Information Processing, Vol. 1, Hartung-Gorr
<t>This document describes how the OpenPGP Message Format can be used to p e Verlag Konstanz, Technische Hochschule (Zurich), Dissertation</refcontent>
rovide privacy and authentication using the Multipurpose Internet Mail Extension </reference>
s (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>
<reference anchor='RFC3394'> <reference anchor="ISO10646" target="https://www.iso.org/standard/76835.
<front> html">
<title>Advanced Encryption Standard (AES) Key Wrap Algorithm</title> <front>
<author fullname='J. Schaad' initials='J.' surname='Schaad'/> <title>Information technology - Universal coded character set (UCS)<
<author fullname='R. Housley' initials='R.' surname='Housley'/> /title>
<date month='September' year='2002'/> <author>
</front> <organization>ISO</organization>
<seriesInfo name='RFC' value='3394'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC3394'/> <date month="December" year="2020"/>
</reference> </front>
<seriesInfo name="ISO/IEC" value="10646:2020"/>
</reference>
<reference anchor='RFC3629'> <reference anchor="JFIF" target="https://www.itu.int/rec/T-REC-T.871-201
<front> 105-I">
<title>UTF-8, a transformation format of ISO 10646</title> <front>
<author fullname='F. Yergeau' initials='F.' surname='Yergeau'/> <title>Information technology - Digital compression and coding of co
<date month='November' year='2003'/> ntinuous-tone still images: JPEG File Interchange Format (JFIF)</title>
<abstract> <author>
<t>ISO/IEC 10646-1 defines a large character set called the Universal Char <organization>ITU-T</organization>
acter Set (UCS) which encompasses most of the world's writing systems. The origi </author>
nally proposed encodings of the UCS, however, were not compatible with many curr <date year="2011" month="May"/>
ent applications and protocols, and this has led to the development of UTF-8, th </front>
e object of this memo. UTF-8 has the characteristic of preserving the full US-AS <seriesInfo name="Recommendation" value="ITU-T T.871"/>
CII range, providing compatibility with file systems, parsers and other software </reference>
that rely on US-ASCII values but are transparent to other values. This memo obs
oletes 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'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<front> 321.xml"/>
<title>A Description of the Camellia Encryption Algorithm</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<author fullname='M. Matsui' initials='M.' surname='Matsui'/> 950.xml"/>
<author fullname='J. Nakajima' initials='J.' surname='Nakajima'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
<author fullname='S. Moriai' initials='S.' surname='Moriai'/> 951.xml"/>
<date month='April' year='2004'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<abstract> 144.xml"/>
<t>This document describes the Camellia encryption algorithm. Camellia is <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
a block cipher with 128-bit block size and 128-, 192-, and 256-bit keys. The alg 822.xml"/>
orithm description is presented together with key scheduling part and data rando <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
mizing part. This memo provides information for the Internet community.</t> 898.xml"/>
</abstract> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
</front> 156.xml"/>
<seriesInfo name='RFC' value='3713'/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
<seriesInfo name='DOI' value='10.17487/RFC3713'/> 394.xml"/>
</reference> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
629.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
713.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
086.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
322.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
253.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
748.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
017.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
032.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
106.xml"/>
<reference anchor='RFC4086'> <reference anchor="RIPEMD-160">
<front> <front>
<title>Randomness Requirements for Security</title> <title>Information technology - Security techniques - Hash-functions
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'/> - Part 3: Dedicated hash-functions</title>
<author fullname='J. Schiller' initials='J.' surname='Schiller'/> <author>
<author fullname='S. Crocker' initials='S.' surname='Crocker'/> <organization>ISO</organization>
<date month='June' year='2005'/> </author>
<abstract> <date month="May" year="1998"/>
<t>Security systems are built on strong cryptographic algorithms that foil </front>
pattern analysis attempts. However, the security of these systems is dependent <seriesInfo name="ISO/IEC" value="10118-3:1998"/>
on generating secret quantities for passwords, cryptographic keys, and similar q </reference>
uantities. The use of pseudo-random processes to generate secret quantities can
result in pseudo-security. A sophisticated attacker may find it easier to reprod
uce the environment that produced the secret quantities and to search the result
ing 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 adversar
y is surprisingly difficult. This document points out many pitfalls in using poo
r entropy sources or traditional pseudo-random number generation techniques for
generating such quantities. It recommends the use of truly random hardware techn
iques 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 solut
ion 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 Prac
tices for the Internet Community, and requests discussion and suggestions for im
provements.</t>
</abstract>
</front>
<seriesInfo name='BCP' value='106'/>
<seriesInfo name='RFC' value='4086'/>
<seriesInfo name='DOI' value='10.17487/RFC4086'/>
</reference>
<reference anchor='RFC4648'> <reference anchor="SP800-38A" target="https://nvlpubs.nist.gov/nistpubs/
<front> legacy/sp/nistspecialpublication800-38a.pdf">
<title>The Base16, Base32, and Base64 Data Encodings</title> <front>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'/> <title>Recommendation for Block Cipher Modes of Operation: Methods a
<date month='October' year='2006'/> nd Techniques</title>
<abstract> <author>
<t>This document describes the commonly used base 64, base 32, and base 16 <organization>NIST</organization>
encoding schemes. It also discusses the use of line-feeds in encoded data, use </author>
of padding in encoded data, use of non-alphabet characters in encoded data, use <date year="2001" month="December"/>
of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK]</t> </front>
</abstract> <seriesInfo name="NIST Special Publication" value="800-38A"/>
</front> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38A"/>
<seriesInfo name='RFC' value='4648'/> </reference>
<seriesInfo name='DOI' value='10.17487/RFC4648'/>
</reference>
<reference anchor='RFC5322'> <reference anchor="SP800-38D" target="https://nvlpubs.nist.gov/nistpubs
<front> /legacy/sp/nistspecialpublication800-38d.pdf">
<title>Internet Message Format</title> <front>
<author fullname='P. Resnick' initials='P.' role='editor' surname='Resnick'/ <title>Recommendation for Block Cipher Modes of Operation: Galois/Co
> unter Mode (GCM) and GMAC</title>
<date month='October' year='2008'/> <author>
<abstract> <organization>NIST</organization>
<t>This document specifies the Internet Message Format (IMF), a syntax for </author>
text messages that are sent between computer users, within the framework of "el <date year="2007" month="November"/>
ectronic mail" messages. This specification is a revision of Request For Comment </front>
s (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard <seriesInfo name="NIST Special Publication" value="800-38D"/>
for the Format of ARPA Internet Text Messages", updating it to reflect current p <seriesInfo name="DOI" value="10.6028/NIST.SP.800-38D"/>
ractice and incorporating incremental changes that were specified in other RFCs. </reference>
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5322'/>
<seriesInfo name='DOI' value='10.17487/RFC5322'/>
</reference>
<reference anchor='RFC6234'> <reference anchor="SP800-56A" target="https://nvlpubs.nist.gov/nistpubs/
<front> SpecialPublications/
<title>US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)</title> nist.sp.800-56Ar3.pdf">
<author fullname='D. Eastlake 3rd' initials='D.' surname='Eastlake 3rd'/> <front>
<author fullname='T. Hansen' initials='T.' surname='Hansen'/> <title>Recommendation for Pair-Wise Key Establishment Schemes Using
<date month='May' year='2011'/> Discrete Logarithm Cryptography</title>
<abstract> <author>
<t>Federal Information Processing Standard, FIPS</t> <organization>NIST</organization>
</abstract> </author>
</front> <date year="2018" month="April"/>
<seriesInfo name='RFC' value='6234'/> </front>
<seriesInfo name='DOI' value='10.17487/RFC6234'/> <seriesInfo name="NIST Special Publication" value="800-56A Revision 3"
</reference> />
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-56Ar"/>
</reference>
<reference anchor='RFC7253'> <reference anchor="SP800-67" target="https://nvlpubs.nist.gov/nistpubs/S
<front> pecialPublications/NIST.SP.800-67r2.pdf">
<title>The OCB Authenticated-Encryption Algorithm</title> <front>
<author fullname='T. Krovetz' initials='T.' surname='Krovetz'/> <title>Recommendation for the Triple Data Encryption Algorithm (TDEA
<author fullname='P. Rogaway' initials='P.' surname='Rogaway'/> ) Block Cipher</title>
<date month='May' year='2014'/> <author>
<abstract> <organization>NIST</organization>
<t>This document specifies OCB, a shared-key blockcipher-based encryption </author>
scheme that provides confidentiality and authenticity for plaintexts and authent <date year="2017" month="November"/>
icity for associated data. This document is a product of the Crypto Forum Resear </front>
ch Group (CFRG).</t> <seriesInfo name="NIST Special Publication" value="800-67 Revision 2"/
</abstract> >
</front> <seriesInfo name="DOI" value="10.6028/NIST.SP.800-67r2"/>
<seriesInfo name='RFC' value='7253'/> </reference>
<seriesInfo name='DOI' value='10.17487/RFC7253'/>
</reference>
<reference anchor='RFC7748'> <reference anchor="TWOFISH" target="https://www.schneier.com/wp-content/
<front> uploads/2016/02/paper-twofish-paper.pdf">
<title>Elliptic Curves for Security</title> <front>
<author fullname='A. Langley' initials='A.' surname='Langley'/> <title>Twofish: A 128-Bit Block Cipher</title>
<author fullname='M. Hamburg' initials='M.' surname='Hamburg'/> <author initials="B." surname="Schneier">
<author fullname='S. Turner' initials='S.' surname='Turner'/> <organization/>
<date month='January' year='2016'/> </author>
<abstract> <author initials="J." surname="Kelsey">
<t>This memo specifies two elliptic curves over prime fields that offer a <organization/>
high level of practical security in cryptographic applications, including Transp </author>
ort Layer Security (TLS). These curves are intended to operate at the ~128-bit a <author initials="D." surname="Whiting">
nd ~224-bit security level, respectively, and are generated deterministically ba <organization/>
sed on a list of required properties.</t> </author>
</abstract> <author initials="D." surname="Wagner">
</front> <organization/>
<seriesInfo name='RFC' value='7748'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC7748'/> <author initials="C." surname="Hall">
</reference> <organization/>
</author>
<author initials="N." surname="Ferguson">
<organization/>
</author>
<date month="June" year="1998"/>
</front>
</reference>
<reference anchor='RFC8017'> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
<front> 119.xml"/>
<title>PKCS #1: RSA Cryptography Specifications Version 2.2</title> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
<author fullname='K. Moriarty' initials='K.' role='editor' surname='Moriarty 174.xml"/>
'/>
<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 repre
senting keys and for identifying the schemes.</t>
<t>This document represents a republication of PKCS #1 v2.2 from RSA Labor
atories' 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'> <reference anchor="FIPS186" target="https://nvlpubs.nist.gov/nistpubs/FI
<front> PS/NIST.FIPS.186-5.pdf">
<title>Edwards-Curve Digital Signature Algorithm (EdDSA)</title> <front>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'/> <title>Digital Signature Standard (DSS)</title>
<author fullname='I. Liusvaara' initials='I.' surname='Liusvaara'/> <author>
<date month='January' year='2017'/> <organization>NIST</organization>
<abstract> </author>
<t>This document describes elliptic curve signature scheme Edwards-curve D <date month="February" year="2023"/>
igital Signature Algorithm (EdDSA). The algorithm is instantiated with recommend </front>
ed parameters for the edwards25519 and edwards448 curves. An example implementat <seriesInfo name="FIPS PUB" value="186-5"/>
ion and test vectors are provided.</t> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.186-5"/>
</abstract> </reference>
</front>
<seriesInfo name='RFC' value='8032'/>
<seriesInfo name='DOI' value='10.17487/RFC8032'/>
</reference>
<reference anchor='RFC8126'> <reference anchor="AES" target="https://nvlpubs.nist.gov/nistpubs/FIPS/N
<front> IST.FIPS.197-upd1.pdf">
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title> <front>
<author fullname='M. Cotton' initials='M.' surname='Cotton'/> <title>Advanced Encryption Standard (AES)</title>
<author fullname='B. Leiba' initials='B.' surname='Leiba'/> <author>
<author fullname='T. Narten' initials='T.' surname='Narten'/> <organization>NIST</organization>
<date month='June' year='2017'/> </author>
<abstract> <date month="November" year="2001"/>
<t>Many protocols make use of points of extensibility that use constants t </front>
o identify various protocol parameters. To ensure that the values in these field <seriesInfo name="FIPS PUB" value="197"/>
s do not have conflicting uses and to promote interoperability, their allocation <seriesInfo name="DOI" value="10.6028/NIST.FIPS.197-upd1"/>
s are often coordinated by a central record keeper. For IETF protocols, that rol <refcontent>Updated May 2023</refcontent>
e is filled by the Internet Assigned Numbers Authority (IANA).</t> </reference>
<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 ho
w 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 cl
ear and addresses the various issues that are likely in the operation of a regis
try.</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'> <reference anchor="FIPS180" target="https://nvlpubs.nist.gov/nistpubs/fi
<front> ps/nist.fips.180-4.pdf">
<title>Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Ap <front>
plications</title> <title>Secure Hash Standard (SHS)</title>
<author fullname='A. Biryukov' initials='A.' surname='Biryukov'/> <author>
<author fullname='D. Dinu' initials='D.' surname='Dinu'/> <organization>NIST</organization>
<author fullname='D. Khovratovich' initials='D.' surname='Khovratovich'/> </author>
<author fullname='S. Josefsson' initials='S.' surname='Josefsson'/> <date month="August" year="2015"/>
<date month='September' year='2021'/> </front>
<abstract> <seriesInfo name="FIPS PUB" value="180-4"/>
<t>This document describes the Argon2 memory-hard function for password ha <seriesInfo name="DOI" value="10.6028/NIST.FIPS.180-4"/>
shing and proof-of-work applications. We provide an implementer-oriented descrip </reference>
tion with test vectors. The purpose is to simplify adoption of Argon2 for Intern
et protocols. This document is a product of the Crypto Forum Research Group (CFR
G) in the IRTF.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='9106'/>
<seriesInfo name='DOI' value='10.17487/RFC9106'/>
</reference>
<reference anchor="RIPEMD-160" > <reference anchor="FIPS202" target="https://nvlpubs.nist.gov/nistpubs/fi
<front> ps/nist.fips.202.pdf">
<title>Information technology - Security techniques - Hash-functions - Part <front>
3: Dedicated hash-functions,</title> <title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output
<author > Functions</title>
<organization>International Organization for Standardization, Geneva, Swit <author>
zerland</organization> <organization>NIST</organization>
</author> </author>
<date year="1998"/> <date month="August" year="2015"/>
</front> </front>
<seriesInfo name="ISO" value="ISO/IEC 10118-3"/> <seriesInfo name="FIPS PUB" value="202"/>
</reference> <seriesInfo name="DOI" value="10.6028/NIST.FIPS.202"/>
<reference anchor="SP800-38A" > </reference>
<front>
<title>Recommendation for Block Cipher Modes of Operation: Methods and Techn
iques</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 Mo
de (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>
<author initials="B." surname="Schneier">
<organization></organization>
</author>
<author initials="J." surname="Kelsey">
<organization></organization>
</author>
<author initials="D." surname="Whiting">
<organization></organization>
</author>
<author initials="D." surname="Wagner">
<organization></organization>
</author>
<author initials="C." surname="Hall">
<organization></organization>
</author>
<author initials="N." surname="Ferguson">
<organization></organization>
</author>
<date year="1999"/>
</front>
</reference>
<reference anchor='RFC2119'> </references>
<front> <references>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <name>Informative References</name>
<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 docu
ment defines these words as they should be interpreted in IETF documents. This d
ocument 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'> <reference anchor="BLEICHENBACHER">
<front> <front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title> <title>Generating ElGamal Signatures Without Knowing the Secret Key<
<author fullname='B. Leiba' initials='B.' surname='Leiba'/> /title>
<date month='May' year='2017'/> <author initials="D." surname="Bleichenbacher">
<abstract> <organization/>
<t>RFC 2119 specifies common key words that may be used in protocol specif </author>
ications. This document aims to reduce the ambiguity by clarifying that only UPP <date month="May" year="1996"/>
ERCASE usage of the key words have the defined special meanings.</t> </front>
</abstract> <refcontent>EUROCRYPT'96: International Conference on the Theory and A
</front> pplications of Cryptographic Techniques Proceedings, Vol. 1070, pp. 10-18</refco
<seriesInfo name='BCP' value='14'/> ntent>
<seriesInfo name='RFC' value='8174'/> </reference>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor='FIPS186'> <reference anchor="BLEICHENBACHER-PKCS1" target="http://archiv.infsec.et
<front> hz.ch/education/fs08/secsem/Bleichenbacher98.pdf">
<title>Digital Signature Standard (DSS)</title> <front>
<author fullname='Lily Chen' initials='L.' surname='Chen'> <title>Chosen Ciphertext Attacks Against Protocols Based on the RSA
<organization/> Encryption Standard PKCS #1</title>
</author> <author initials="D." surname="Bleichenbacher">
<author fullname='Dustin Moody' initials='D.' surname='Moody'> <organization/>
<organization/> </author>
</author> <date month="August" year="1998"/>
<author fullname='Andrew Regenscheid' initials='A.' surname='Regenscheid'> </front>
<organization/> <refcontent>CRYPTO '98: International Cryptology Conference Proceedings
</author> , Vol. 1462, pp. 1-12</refcontent>
<author fullname='Angela Robinson' initials='A.' surname='Robinson'> </reference>
<organization/>
</author>
<date month='February' year='2023'/>
</front>
<seriesInfo name='National Institute of Standards and Technology (U.S.)' value
='report'/>
<seriesInfo name='DOI' value='10.6028/nist.fips.186-5'/>
</reference>
<reference anchor='AES'> <reference anchor="C99" target="https://www.iso.org/standard/74528.html"
<front> >
<title>Advanced encryption standard (AES)</title> <front>
<author> <title>Information technology - Programming languages: C</title>
<organization/> <author>
</author> <organization>ISO</organization>
<date month='November' year='2001'/> </author>
</front> <date year="2018" month="June"/>
<seriesInfo name='National Institute of Standards and Technology' value='repor </front>
t'/> <seriesInfo name="ISO/IEC" value="9899:2018"/>
<seriesInfo name='DOI' value='10.6028/nist.fips.197'/> </reference>
</reference>
<reference anchor='FIPS180'> <reference anchor="EFAIL" target="https://www.usenix.org/system/files/co
<front> nference/usenixsecurity18/sec18-poddebniak.pdf">
<title>Secure Hash Standard</title> <front>
<author fullname='Quynh H. Dang' initials='Q.' surname='Dang'> <title>Efail: Breaking S/MIME and OpenPGP Email Encryption using Exf
<organization/> iltration Channels</title>
</author> <author initials="D." surname="Poddebniak" fullname="Damian Poddebni
<date month='July' year='2015'/> ak">
</front> <organization/>
<seriesInfo name='National Institute of Standards and Technology' value='repor </author>
t'/> <author initials="C." surname="Dresen" fullname="Christian Dresen">
<seriesInfo name='DOI' value='10.6028/nist.fips.180-4'/> <organization/>
</reference> </author>
<author initials="J." surname="Müller" fullname="Jens Müller">
<organization/>
</author>
<author initials="F." surname="Ising" fullname="Fabian Ising">
<organization/>
</author>
<author initials="S." surname="Schinzel" fullname="Sebastian Schinze
l">
<organization/>
</author>
<author initials="S." surname="Friedberger" fullname="Simon Friedber
ger">
<organization/>
</author>
<author initials="J." surname="Somorovsky" fullname="Juraj Somorovsk
y">
<organization/>
</author>
<author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
<organization/>
</author>
<date month="August" year="2018"/>
</front>
<refcontent>Proceedings of the 27th USENIX Security Symposium</refcont
ent>
</reference>
<reference anchor='FIPS202'> <reference anchor="Errata-2199" quote-title="false" target="https://www.rfc-edi tor.org/errata/eid2199">
<front> <front>
<title>SHA-3 Standard: Permutation-Based Hash and Extendable-Output Function <title>Erratum ID 2199</title>
s</title> <author>
<author fullname='Morris J. Dworkin' initials='M.' surname='Dworkin'> <organization>RFC Errata</organization>
<organization/>
</author> </author>
<date month='July' year='2015'/> <date />
</front> </front>
<seriesInfo name='National Institute of Standards and Technology' value='repor <refcontent>RFC 4880</refcontent>
t'/>
<seriesInfo name='DOI' value='10.6028/nist.fips.202'/>
</reference> </reference>
</references> <reference anchor="Errata-2200" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2200">
<references title='Informative References'>
<reference anchor="BLEICHENBACHER" >
<front>
<title>Generating ElGamal Signatures Without Knowing the Secret Key</title>
<author initials="D." surname="Bleichenbacher">
<organization></organization>
</author>
<date year="1996"/>
</front>
<seriesInfo name="Lecture Notes in Computer Science" value="Volume 1070, pp. 1
0-18"/>
</reference>
<reference anchor="BLEICHENBACHER-PKCS1" target="http://archiv.infsec.ethz.ch/ed
ucation/fs08/secsem/Bleichenbacher98.pdf">
<front>
<title>Chosen Ciphertext Attacks Against Protocols Based on the RSA Encrypti
on Standard PKCS \#1</title>
<author initials="D." surname="Bleichenbacher">
<organization></organization>
</author>
<date year="1998"/>
</front>
</reference>
<reference anchor="C99" target="https://www.iso.org/standard/50510.html">
<front>
<title>Programming languages - C: C99, correction 3:2007, ISO/IEC 9899:1999
/Cor 3:2007</title>
<author initials="I. O. for" surname="Standardization" fullname="Internation
al Organization for Standardization">
<organization></organization>
</author>
<date year="2007" month="November"/>
</front>
</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 Exfiltratio
n Channels</title>
<author initials="D." surname="Poddebniak" fullname="Damian Poddebniak">
<organization></organization>
</author>
<author initials="C." surname="Dresen" fullname="Christian Dresen">
<organization></organization>
</author>
<author initials="J." surname="Müller" fullname="Jens Müller">
<organization></organization>
</author>
<author initials="F." surname="Ising" fullname="Fabian Ising">
<organization></organization>
</author>
<author initials="S." surname="Schinzel" fullname="Sebastian Schinzel">
<organization></organization>
</author>
<author initials="S." surname="Friedberger" fullname="Simon Friedberger">
<organization></organization>
</author>
<author initials="J." surname="Somorovsky" fullname="Juraj Somorovsky">
<organization></organization>
</author>
<author initials="J." surname="Schwenk" fullname="Jörg Schwenk">
<organization></organization>
</author>
<date year="2018"/>
</front>
<seriesInfo name="Proceedings of the 27th USENIX Conference on Security Sympos
ium, August 2018, Pages 549–566" value=""/>
</reference>
<reference anchor="Errata-2199" target="https://www.rfc-editor.org/errata/eid219
9">
<front> <front>
<title>Errata Report 2199 - S2K hash/cipher octet correction</title> <title>Erratum ID 2200</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2200" target="https://www.rfc-editor.org/errata/eid220
0"> <reference anchor="Errata-2206" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2206">
<front> <front>
<title>Errata Report 2200 - No implicit use of IDEA correction</title> <title>Erratum ID 2206</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2206" target="https://www.rfc-editor.org/errata/eid220
6"> <reference anchor="Errata-2208" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2208">
<front> <front>
<title>Errata Report 2206 - PKESK acronym expansion</title> <title>Erratum ID 2208</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2208" target="https://www.rfc-editor.org/errata/eid220
8"> <reference anchor="Errata-2214" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2214">
<front> <front>
<title>Errata Report 2208 - Signature key owner clarification</title> <title>Erratum ID 2214</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2214" target="https://www.rfc-editor.org/errata/eid221
4"> <reference anchor="Errata-2216" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2216">
<front> <front>
<title>Errata Report 2214 - Signature hashing clarification</title> <title>Erratum ID 2216</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2216" target="https://www.rfc-editor.org/errata/eid221
6"> <reference anchor="Errata-2219" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2219">
<front> <front>
<title>Errata Report 2216 - Self signature applies to user ID correction</ti <title>Erratum ID 2219</title>
tle> <author>
<author > <organization>RFC Errata</organization>
<organization></organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2219" target="https://www.rfc-editor.org/errata/eid221
9"> <reference anchor="Errata-2222" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2222">
<front> <front>
<title>Errata Report 2219 - Session key encryption storage clarification</ti tle> <title>Erratum ID 2222</title>
<author > <author >
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2222" target="https://www.rfc-editor.org/errata/eid222
2"> <reference anchor="Errata-2226" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2226">
<front> <front>
<title>Errata Report 2222 - Simple hash MUST/MAY clarification</title> <title>Erratum ID 2226</title>
<author > <author >
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2226" target="https://www.rfc-editor.org/errata/eid222
6"> <reference anchor="Errata-2234" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2234">
<front> <front>
<title>Errata Report 2226 - Native line endings SHOULD clarification</title> <title>Erratum ID 2234</title>
<author > <author >
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2234" target="https://www.rfc-editor.org/errata/eid223
4"> <reference anchor="Errata-2235" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2235">
<front> <front>
<title>Errata Report 2234 - Radix-64 / base64 clarification</title> <title>Erratum ID 2235</title>
<author > <author >
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2235" target="https://www.rfc-editor.org/errata/eid223
5"> <reference anchor="Errata-2236" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2236">
<front> <front>
<title>Errata Report 2235 - ASCII / UTF-8 collation sequence clarification</ <title>Erratum ID 2236</title>
title> <author>
<author > <organization>RFC Errata</organization>
<organization></organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2236" target="https://www.rfc-editor.org/errata/eid223
6"> <reference anchor="Errata-2238" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2238">
<front> <front>
<title>Errata Report 2236 - Packet Composition is a sequence clarification</ <title>Erratum ID 2238</title>
title> <author>
<author > <organization>RFC Errata</organization>
<organization></organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2238" target="https://www.rfc-editor.org/errata/eid223
8"> <reference anchor="Errata-2240" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2240">
<front> <front>
<title>Errata Report 2238 - Subkey packets come after all User ID packets cl <title>Erratum ID 2240</title>
arification</title> <author>
<author > <organization>RFC Errata</organization>
<organization></organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2240" target="https://www.rfc-editor.org/errata/eid224
0"> <reference anchor="Errata-2242" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2242">
<front> <front>
<title>Errata Report 2240 - Subkey removal clarification</title> <title>Erratum ID 2242</title>
<author > <author >
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2242" target="https://www.rfc-editor.org/errata/eid224
2"> <reference anchor="Errata-2243" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2243">
<front> <front>
<title>Errata Report 2242 - mL / emLen variable correction</title> <title>Erratum ID 2243</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2243" target="https://www.rfc-editor.org/errata/eid224
3"> <reference anchor="Errata-2270" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2270">
<front> <front>
<title>Errata Report 2243 - CFB mode initialization vector (IV) clarificatio <title>Erratum ID 2270</title>
n</title> <author>
<author > <organization>RFC Errata</organization>
<organization></organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2270" target="https://www.rfc-editor.org/errata/eid227
0"> <reference anchor="Errata-2271" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid2271">
<front> <front>
<title>Errata Report 2270 - SHA-224 octet sequence correction</title> <title>Erratum ID 2271</title>
<author > <author >
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-2271" target="https://www.rfc-editor.org/errata/eid227
1"> <reference anchor="Errata-3298" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid3298">
<front> <front>
<title>Errata Report 2271 - Radix-64 correction</title> <title>Erratum ID 3298</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-3298" target="https://www.rfc-editor.org/errata/eid329
8"> <reference anchor="Errata-5491" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid5491">
<front> <front>
<title>Errata Report 3298 - Key revocation signatures correction</title> <title>Erratum ID 5491</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-5491" target="https://www.rfc-editor.org/errata/eid549
1"> <reference anchor="Errata-7545" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid7545">
<front> <front>
<title>Errata Report 5491 - C code fix for CRC24_POLY define</title> <title>Erratum ID 7545</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <refcontent>RFC 4880</refcontent>
</reference> </reference>
<reference anchor="Errata-7545" target="https://www.rfc-editor.org/errata/eid754
5"> <reference anchor="Errata-7889" quote-title="false" target="https://www.rfc-edit
or.org/errata/eid7889">
<front> <front>
<title>Errata Report 7545 - Armor Header colon hex fix</title> <title>Erratum ID 7889</title>
<author > <author>
<organization></organization> <organization>RFC Errata</organization>
</author> </author>
<date /> <date />
</front> </front>
<seriesInfo name="RFC" value="4880"/> <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>
</author>
<date year="1988"/>
</front>
<seriesInfo name="DOI" value="10.1137/0217019"/>
</reference>
<reference anchor="JKS02" target="http://www.counterpane.com/pgp-attack.html">
<front>
<title>Implementation of Chosen-Ciphertext Attacks against PGP and GnuPG</ti
tle>
<author initials="K." surname="Jallad" fullname="Kahil Jallad">
<organization></organization>
</author>
<author initials="J." surname="Katz" fullname="Jonathan Katz">
<organization></organization>
</author>
<author initials="B." surname="Schneier" fullname="Bruce Schneier">
<organization></organization>
</author>
<date year="2002"/>
</front>
</reference>
<reference anchor="KOBLITZ" >
<front>
<title>A course in number theory and cryptography, Chapter VI. Elliptic Curv
es</title>
<author initials="N." surname="Koblitz">
<organization></organization>
</author>
<date year="1997"/>
</front>
<seriesInfo name="ISBN" value="0-387-96576-9"/>
</reference>
<reference anchor="KOPENPGP" target="https://www.kopenpgp.com/">
<front>
<title>Victory by KO: Attacking OpenPGP Using Key Overwriting</title>
<author initials="L." surname="Bruseghini" fullname="Lara Bruseghini">
<organization></organization>
</author>
<author initials="K. G." surname="Paterson" fullname="Kenneth G. Paterson">
<organization></organization>
</author>
<author initials="D." surname="Huigens" fullname="Daniel Huigens">
<organization></organization>
</author>
<date year="2022"/>
</front>
<seriesInfo name="Proceedings of the 29th ACM Conference on Computer and Commu
nications Security, November 2022 (to appear)" value=""/>
</reference>
<reference anchor="KR02" target="https://eprint.iacr.org/2002/076">
<front>
<title>Attack on Private Signature Keys of the OpenPGP Format, PGP(TM) Progr
ams and Other Applications Compatible with OpenPGP</title>
<author initials="V." surname="Klíma" fullname="Vlastimil Klíma">
<organization></organization>
</author>
<author initials="T." surname="Rosa" fullname="Tomáš Rosa">
<organization></organization>
</author>
<date year="2002"/>
</front>
<seriesInfo name="Cryptology ePrint Archive, Report 2002/076" value=""/>
</reference>
<reference anchor="MRLG15" >
<front>
<title>Format Oracles on OpenPGP</title>
<author initials="F." surname="Maury" fullname="Florian Maury">
<organization></organization>
</author>
<author initials="J.-R." surname="Reinhard" fullname="Jean-René Reinhard">
<organization></organization>
</author>
<author initials="O." surname="Levillain" fullname="Olivier Levillain">
<organization></organization>
</author>
<author initials="H." surname="Gilbert" fullname="Henri Gilbert">
<organization></organization>
</author>
<date year="2015"/>
</front>
<seriesInfo name="CT-RSA 2015" value="Topics in Cryptology –- CT-RSA 2015 pp 2
20–236"/>
<seriesInfo name="DOI" value="10.1007/978-3-319-16715-2_12"/>
</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>
</author>
<author initials="R." surname="Zuccherato" fullname="Robert Zuccherato">
<organization></organization>
</author>
<date year="2005" month="February" day="08"/>
</front>
<seriesInfo name="IACR ePrint Archive" value="Report 2005/033"/>
</reference>
<reference anchor="OPENPGPCARD" target="https://gnupg.org/ftp/specs/OpenPGP-smar
t-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>
<author initials="A." surname="Pietig" fullname="Achim Pietig">
<organization></organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="PAX" target="https://pubs.opengroup.org/onlinepubs/9699919799
/utilities/pax.html">
<front>
<title>IEEE Standard for Information Technology--Portable Operating System I
nterface (POSIX(R)) Base Specifications, Issue 7: pax - portable archive interch
ange</title>
<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>
<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>
</author>
<author initials="J." surname="Somorovsky">
<organization></organization>
</author>
<author initials="S." surname="Schinzel">
<organization></organization>
</author>
<author initials="M." surname="Lochter">
<organization></organization>
</author>
<author initials="P." surname="Rösler">
<organization></organization>
</author>
<date year="2017" month="October"/>
</front>
</reference>
<reference anchor="REGEX" >
<front>
<title>Mastering Regular Expressions</title>
<author initials="J." surname="Friedl" fullname="Jeffrey Friedl">
<organization>O'Reilly</organization>
</author>
<date year="2002" month="August"/>
</front>
<seriesInfo name="ISBN" value="0-596-00289-0"/>
</reference> </reference>
<reference anchor='RFC1991'> <reference anchor="HASTAD">
<front> <front>
<title>PGP Message Exchange Formats</title> <title>Solving Simultaneous Modular Equations of Low Degree</title>
<author fullname='D. Atkins' initials='D.' surname='Atkins'/> <author initials="J." surname="Hastad" fullname="Johan Hastad">
<author fullname='W. Stallings' initials='W.' surname='Stallings'/> <organization/>
<author fullname='P. Zimmermann' initials='P.' surname='Zimmermann'/> </author>
<date month='August' year='1996'/> <date month="April" year="1988"/>
<abstract> </front>
<t>This document describes the format of "PGP files", i.e., messages that <seriesInfo name="DOI" value="10.1137/0217019"/>
have been encrypted and/or signed with PGP. This memo provides information for t </reference>
he Internet community. This memo does not specify an Internet standard of any ki
nd.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='1991'/>
<seriesInfo name='DOI' value='10.17487/RFC1991'/>
</reference>
<reference anchor='RFC2440'> <reference anchor="JKS02" target="https://www.schneier.com/academic/arch
<front> ives/2002/01/implementation_of_ch.html">
<title>OpenPGP Message Format</title> <front>
<author fullname='J. Callas' initials='J.' surname='Callas'/> <title>Implementation of Chosen-Ciphertext Attacks against PGP and G
<author fullname='L. Donnerhacke' initials='L.' surname='Donnerhacke'/> nuPG</title>
<author fullname='H. Finney' initials='H.' surname='Finney'/> <author initials="K." surname="Jallad" fullname="Kahil Jallad">
<author fullname='R. Thayer' initials='R.' surname='Thayer'/> <organization/>
<date month='November' year='1998'/> </author>
<abstract> <author initials="J." surname="Katz" fullname="Jonathan Katz">
<t>This document is maintained in order to publish all necessary informati <organization/>
on needed to develop interoperable applications based on the OpenPGP format. [ST </author>
ANDARDS-TRACK]</t> <author initials="B." surname="Schneier" fullname="Bruce Schneier">
</abstract> <organization/>
</front> </author>
<seriesInfo name='RFC' value='2440'/> <date month="September" year="2002"/>
<seriesInfo name='DOI' value='10.17487/RFC2440'/> </front>
</reference> <seriesInfo name="DOI" value="0.1007/3-540-45811-5_7"/>
</reference>
<reference anchor='RFC4880'> <reference anchor="KOBLITZ">
<front> <front>
<title>OpenPGP Message Format</title> <title>A course in number theory and cryptography</title>
<author fullname='J. Callas' initials='J.' surname='Callas'/> <author initials="N." surname="Koblitz">
<author fullname='L. Donnerhacke' initials='L.' surname='Donnerhacke'/> <organization/>
<author fullname='H. Finney' initials='H.' surname='Finney'/> </author>
<author fullname='D. Shaw' initials='D.' surname='Shaw'/> <date year="1997"/>
<author fullname='R. Thayer' initials='R.' surname='Thayer'/> </front>
<date month='November' year='2007'/> <seriesInfo name="DOI" value="10.2307/3618498"/>
<abstract> <refcontent>Chaper VI: Elliptic Curves</refcontent>
<t>This document is maintained in order to publish all necessary informati </reference>
on 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 packet
s crossing any network. It does not deal with storage and implementation questio
ns. 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 the message formats used in Op
enPGP. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name='RFC' value='4880'/>
<seriesInfo name='DOI' value='10.17487/RFC4880'/>
</reference>
<reference anchor='RFC5581'> <reference anchor="KOPENPGP" target="https://dl.acm.org/doi/10.1145/3548
<front> 606.3559363">
<title>The Camellia Cipher in OpenPGP</title> <front>
<author fullname='D. Shaw' initials='D.' surname='Shaw'/> <title>Victory by KO: Attacking OpenPGP Using Key Overwriting</title
<date month='June' year='2009'/> >
<abstract> <author initials="L." surname="Bruseghini" fullname="Lara Bruseghini
<t>This document presents the necessary information to use the Camellia sy ">
mmetric block cipher in the OpenPGP protocol. This memo provides information for <organization/>
the Internet community.</t> </author>
</abstract> <author initials="K. G." surname="Paterson" fullname="Kenneth G. Pat
</front> erson">
<seriesInfo name='RFC' value='5581'/> <organization/>
<seriesInfo name='DOI' value='10.17487/RFC5581'/> </author>
</reference> <author initials="D." surname="Huigens" fullname="Daniel Huigens">
<organization/>
</author>
<date month="November" year="2022"/>
</front>
<seriesInfo name="DOI" value="10.1145/3548606.3559363"/>
<refcontent>Proceedings of the ACM SIGSAC Conference on Computer and C
ommunications Security, pp. 411-423</refcontent>
</reference>
<reference anchor='RFC5639'> <reference anchor="KR02" target="https://eprint.iacr.org/2002/076">
<front> <front>
<title>Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve <title>Attack on Private Signature Keys of the OpenPGP Format, PGP(T
Generation</title> M) Programs and Other Applications Compatible with OpenPGP</title>
<author fullname='M. Lochter' initials='M.' surname='Lochter'/> <author initials="V." surname="Klíma" fullname="Vlastimil Klíma">
<author fullname='J. Merkle' initials='J.' surname='Merkle'/> <organization/>
<date month='March' year='2010'/> </author>
<abstract> <author initials="T." surname="Rosa" fullname="Tomáš Rosa">
<t>This memo proposes several elliptic curve domain parameters over finite <organization/>
prime fields for use in cryptographic applications. The domain parameters are c </author>
onsistent with the relevant international standards, and can be used in X.509 ce <date month="March" year="2001"/>
rtificates and certificate revocation lists (CRLs), for Internet Key Exchange (I </front>
KE), Transport Layer Security (TLS), XML signatures, and all applications or pro <refcontent>Cryptology ePrint Archive, Paper 2002/076</refcontent>
tocols based on the cryptographic message syntax (CMS). This document is not an </reference>
Internet Standards Track specification; it is published for informational purpos
es.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='5639'/>
<seriesInfo name='DOI' value='10.17487/RFC5639'/>
</reference>
<reference anchor='RFC5869'> <reference anchor="MRLG15">
<front> <front>
<title>HMAC-based Extract-and-Expand Key Derivation Function (HKDF)</title> <title>Format Oracles on OpenPGP</title>
<author fullname='H. Krawczyk' initials='H.' surname='Krawczyk'/> <author initials="F." surname="Maury" fullname="Florian Maury">
<author fullname='P. Eronen' initials='P.' surname='Eronen'/> <organization/>
<date month='May' year='2010'/> </author>
<abstract> <author initials="JR." surname="Reinhard" fullname="Jean-René Reinha
<t>This document specifies a simple Hashed Message Authentication Code (HM rd">
AC)-based key derivation function (HKDF), which can be used as a building block <organization/>
in various protocols and applications. The key derivation function (KDF) is inte </author>
nded to support a wide range of applications and requirements, and is conservati <author initials="O." surname="Levillain" fullname="Olivier Levillai
ve in its use of cryptographic hash functions. This document is not an Internet n">
Standards Track specification; it is published for informational purposes.</t> <organization/>
</abstract> </author>
</front> <author initials="H." surname="Gilbert" fullname="Henri Gilbert">
<seriesInfo name='RFC' value='5869'/> <organization/>
<seriesInfo name='DOI' value='10.17487/RFC5869'/> </author>
</reference> <date month="January" year="2015"/>
</front>
<seriesInfo name="DOI" value="10.1007/978-3-319-16715-2_12"/>
<refcontent>Topics in Cryptology -- CT-RSA 2015, Vol. 9048, pp. 220-236
</refcontent>
</reference>
<reference anchor='RFC6090'> <reference anchor="MZ05" target="http://eprint.iacr.org/2005/033">
<front> <front>
<title>Fundamental Elliptic Curve Cryptography Algorithms</title> <title>An Attack on CFB Mode Encryption As Used By OpenPGP</title>
<author fullname='D. McGrew' initials='D.' surname='McGrew'/> <author initials="S." surname="Mister" fullname="Serge Mister">
<author fullname='K. Igoe' initials='K.' surname='Igoe'/> <organization/>
<author fullname='M. Salter' initials='M.' surname='Salter'/> </author>
<date month='February' year='2011'/> <author initials="R." surname="Zuccherato" fullname="Robert Zucchera
<abstract> to">
<t>This note describes the fundamental algorithms of Elliptic Curve Crypto <organization/>
graphy (ECC) as they were defined in some seminal references from 1994 and earli </author>
er. These descriptions may be useful for implementing the fundamental algorithms <date year="2005" month="February"/>
without using any of the specialized methods that were developed in following y </front>
ears. Only elliptic curves defined over fields of characteristic greater than th <refcontent>Cryptology ePrint Archive, Paper 2005/033</refcontent>
ree are in scope; these curves are those used in Suite B. This document is not a </reference>
n Internet Standards Track specification; it is published for informational purp
oses.</t>
</abstract>
</front>
<seriesInfo name='RFC' value='6090'/>
<seriesInfo name='DOI' value='10.17487/RFC6090'/>
</reference>
<reference anchor='RFC6637'> <reference anchor="OPENPGPCARD" target="https://gnupg.org/ftp/specs/Open
<front> PGP-smart-card-application-3.4.1.pdf">
<title>Elliptic Curve Cryptography (ECC) in OpenPGP</title> <front>
<author fullname='A. Jivsov' initials='A.' surname='Jivsov'/> <title>Functional Specification of the OpenPGP application on ISO Sm
<date month='June' year='2012'/> art Card Operating Systems</title>
<abstract> <author initials="A." surname="Pietig" fullname="Achim Pietig">
<t>This document defines an Elliptic Curve Cryptography extension to the O <organization/>
penPGP public key format and specifies three Elliptic Curves that enjoy broad su </author>
pport by other standards, including standards published by the US National Insti <date month="March" year="2020"/>
tute of Standards and Technology. The document specifies the conventions for int </front>
eroperability between compliant OpenPGP implementations that make use of this ex <refcontent>Version 3.4.1</refcontent>
tension and these Elliptic Curves. [STANDARDS-TRACK]</t> </reference>
</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"> <reference anchor="PAX" target="https://pubs.opengroup.org/onlinepubs/
<front> 9699919799/utilities/pax.html">
<title>Standards for Efficient Cryptography 1 (SEC 1)</title> <front>
<author > <title>The Open Group Base Specifications</title>
<organization>Standards for Efficient Cryptography Group</organization> <author>
</author> <organization>The Open Group</organization>
<date year="2009" month="May"/> </author>
</front> <date year="2018"/>
</reference> </front>
<reference anchor="SHA1CD" target="https://github.com/cr-marcstevens/sha1collisi <seriesInfo name="IEEE Std" value="1003.1-2017"/>
ondetection"> <refcontent>'pax - portable archive interchange', Issue 7, 2018 Editio
<front> n </refcontent>
<title>sha1collisiondetection</title> </reference>
<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>
<reference anchor="SHAMBLES" target="https://sha-mbles.github.io/">
<front>
<title>Sha-1 is a shambles: First chosen-prefix collision on sha-1 and appli
cation to the PGP web of trust</title>
<author initials="G." surname="Leurent" fullname="Gaëtan Leurent">
<organization></organization>
</author>
<author initials="T." surname="Peyrin" fullname="Thomas Peyrin">
<organization></organization>
</author>
<date year="2020"/>
</front>
</reference>
<reference anchor="SP800-57" target="https://nvlpubs.nist.gov/nistpubs/SpecialPu
blications/NIST.SP.800-57pt1r5.pdf">
<front>
<title>Recommendation on Key Management: Part 1 - General</title>
<author >
<organization>NIST</organization>
</author>
<date year="2020" month="May"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-57 Part 1 Rev. 5"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
</reference>
<reference anchor="SP800-131A" target="https://nvlpubs.nist.gov/nistpubs/Special
Publications/NIST.SP.800-131Ar2.pdf">
<front>
<title>Transitioning the Use of Cryptographic Algorithms and Key Lengths</ti
tle>
<author initials="E." surname="Barker">
<organization></organization>
</author>
<author initials="A." surname="Roginsky">
<organization></organization>
</author>
<date year="2019" month="March"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-131A Revision 2"/>
</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>
</author>
<date year="2013" month="June"/>
</front>
</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 >
<organization>Free Software Foundation</organization>
</author>
<date year="2021" month="January" day="02"/>
</front>
</reference>
<reference anchor="USENIX-STUDY" target="https://www.usenix.org/system/files/con
ference/usenixsecurity16/sec16_paper_dechand.pdf">
<front>
<title>An Empirical Study of Textual Key-Fingerprint Representations</title>
<author >
<organization>Usenix</organization>
</author>
<date year="2016" month="August" day="10"/>
</front>
<seriesInfo name="ISBN" value="978-1-931971-32-4"/>
</reference>
<reference anchor='RFC2978'> <reference anchor="PSSLR17" target="https://eprint.iacr.org/2017/1014">
<front> <front>
<title>IANA Charset Registration Procedures</title> <title>Attacking Deterministic Signature Schemes using Fault Attacks
<author fullname='N. Freed' initials='N.' surname='Freed'/> </title>
<author fullname='J. Postel' initials='J.' surname='Postel'/> <author initials="D." surname="Poddebniak">
<date month='October' year='2000'/> <organization/>
<abstract> </author>
<t>Multipurpose Internet Mail Extensions (MIME) and various other Internet <author initials="J." surname="Somorovsky">
protocols are capable of using many different charsets. This in turn means that <organization/>
the ability to label different charsets is essential. This document specifies a </author>
n Internet Best Current Practices for the Internet Community, and requests discu <author initials="S." surname="Schinzel">
ssion and suggestions for improvements.</t> <organization/>
</abstract> </author>
</front> <author initials="M." surname="Lochter">
<seriesInfo name='BCP' value='19'/> <organization/>
<seriesInfo name='RFC' value='2978'/> </author>
<seriesInfo name='DOI' value='10.17487/RFC2978'/> <author initials="P." surname="Rösler">
</reference> <organization/>
</author>
<date year="2017" month="October"/>
</front>
<refcontent>Cryptology ePrint Archive, Paper 2017/1014 </refcontent>
</reference>
<reference anchor='CHECKOWAY'> <reference anchor="REGEX" target="https://garyhouston.github.io/regex/">
<front> <front>
<title>A Systematic Analysis of the Juniper Dual EC Incident</title> <title>Henry Spencer's regular expression libraries</title>
<author fullname='Stephen Checkoway' initials='S.' surname='Checkoway'> <author>
<organization>University of Illinois at Chicago, Chicago, IL, USA</organiz <organization>regex</organization>
ation> </author>
</author> <date/>
<author fullname='Jacob Maskiewicz' initials='J.' surname='Maskiewicz'> </front>
<organization>UC San Diego, La Jolla, CA, USA</organization> </reference>
</author>
<author fullname='Christina Garman' initials='C.' surname='Garman'>
<organization>Johns Hopkins University, Baltimore, MD, USA</organization>
</author>
<author fullname='Joshua Fried' initials='J.' surname='Fried'>
<organization>University of Pennsylvania, Philadelphia, PA, USA</organizat
ion>
</author>
<author fullname='Shaanan Cohney' initials='S.' surname='Cohney'>
<organization>University of Pennsylvania, Philadelphia, PA, USA</organizat
ion>
</author>
<author fullname='Matthew Green' initials='M.' surname='Green'>
<organization>Johns Hopkins University, Baltimore, MD, USA</organization>
</author>
<author fullname='Nadia Heninger' initials='N.' surname='Heninger'>
<organization>University of Pennsylvania, Philadelphia, PA, USA</organizat
ion>
</author>
<author fullname='Ralf-Philipp Weinmann' initials='R.' surname='Weinmann'>
<organization>Comsecuris, Duisburg, Germany</organization>
</author>
<author 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'>
<organization>UC San Diego, La Jolla, CA, USA</organization>
</author>
<date month='October' year='2016'/>
</front>
<seriesInfo name='Proceedings of the 2016 ACM SIGSAC Conference on Computer an
d Communications' value='Security'/>
<seriesInfo name='DOI' value='10.1145/2976749.2978395'/>
</reference>
</references> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1
991.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
440.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4
880.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
581.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
639.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
869.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
090.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
637.xml"/>
<section anchor="test-vectors"><name>Test vectors</name> <reference anchor="SEC1" target="https://www.secg.org/sec1-v2.pdf">
<front>
<title>SEC 1: Elliptic Curve Cryptography</title>
<author>
<organization>Standards for Efficient Cryptography Group</organiza
tion>
</author>
<date year="2009" month="May"/>
</front>
<refcontent></refcontent>
</reference>
<t>To help implementing this specification a set of non-normative examples follo <reference anchor="SHA1CD" target="https://github.com/cr-marcstevens/sha
w here.</t> 1collisiondetection">
<front>
<title>sha1collisiondetection</title>
<author>
<organization/>
</author>
<date month="December" year="2020"/>
</front>
<refcontent>commit b4a7b0b</refcontent>
</reference>
<section anchor="sample-v4-ed25519legacy-key"><name>Sample v4 Ed25519Legacy key< <reference anchor="SHAMBLES" target="https://dl.acm.org/doi/abs/10.5555/
/name> 3489212.3489316/">
<front>
<title>Sha-1 is a shambles: first chosen-prefix collision on sha-1 a
nd application to the PGP web of trust</title>
<author initials="G." surname="Leurent" fullname="Gaëtan Leurent">
<organization/>
</author>
<author initials="T." surname="Peyrin" fullname="Thomas Peyrin">
<organization/>
</author>
<date month="August" year="2020"/>
</front>
</reference>
<t>The secret key used for this example is:</t> <reference anchor="SP800-57" target="https://nvlpubs.nist.gov/nistpubs/S
pecialPublications/NIST.SP.800-57pt1r5.pdf">
<front>
<title>Recommendation for Key Management: Part 1 - General</title>
<author>
<organization>NIST</organization>
</author>
<date year="2020" month="May"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-57 Part 1, Revi
sion 5"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-57pt1r5"/>
</reference>
<t>D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2</t> <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 Len
gths</title>
<author>
<organization>NIST</organization>
</author>
<date year="2019" month="March"/>
</front>
<seriesInfo name="NIST Special Publication" value="800-131A, Revision
2"/>
<seriesInfo name="DOI" value="10.6028/NIST.SP.800-131Ar2"/>
</reference>
<t>Note that this is the raw secret key used as input to the EdDSA signing opera <reference anchor="STEVENS2013" target="https://eprint.iacr.org/2013/358
tion. ">
The key was created on 2014-08-19 14:28:27 and thus the fingerprint of the OpenP <front>
GP key is:</t> <title>Counter-cryptanalysis</title>
<author initials="M." surname="Stevens" fullname="Marc Stevens">
<organization/>
</author>
<date year="2013" month="June"/>
</front>
<refcontent>Cryptology ePrint Archive, Paper 2013/358</refcontent>
</reference>
<figure><artwork><![CDATA[ <reference anchor="UNIFIED-DIFF" target="https://www.gnu.org/software/di
C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A ffutils/manual/html_node/Detailed-Unified.html">
]]></artwork></figure> <front>
<title>Comparing and Merging Files</title>
<author>
<organization>Free Software Foundation</organization>
</author>
<date year="2021" month="January"/>
</front>
<refcontent>'Detailed Description of Unified Format', Section 2.2.2.2</
refcontent>
</reference>
<t>The algorithm-specific input parameters without the MPI length headers are:</ <reference anchor="USENIX-STUDY" target="https://www.usenix.org/system/f
t> iles/conference/usenixsecurity16/sec16_paper_dechand.pdf">
<front>
<title>An Empirical Study of Textual Key-Fingerprint Representations
</title>
<author fullname="Sergej Dechand" initials="S." surname="Dechand">
<organization/>
</author>
<author fullname="Dominik Schürmann" initials="D." surname="Schürman
n">
<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"/>
</front>
<seriesInfo name="ISBN" value="978-1-931971-32-4"/>
</reference>
<figure><artwork><![CDATA[ <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
oid: 2b06010401da470f01 978.xml"/>
q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406 <reference anchor="CHECKOWAY">
]]></artwork></figure> <front>
<title>A Systematic Analysis of the Juniper Dual EC Incident</title>
<author fullname="Stephen Checkoway" initials="S." surname="Checkowa
y">
<organization>University of Illinois at Chicago, Chicago, IL, USA<
/organization>
</author>
<author fullname="Jacob Maskiewicz" initials="J." surname="Maskiewic
z">
<organization>UC San Diego, La Jolla, CA, USA</organization>
</author>
<author fullname="Christina Garman" initials="C." surname="Garman">
<organization>Johns Hopkins University, Baltimore, MD, USA</organi
zation>
</author>
<author fullname="Joshua Fried" initials="J." surname="Fried">
<organization>University of Pennsylvania, Philadelphia, PA, USA</o
rganization>
</author>
<author fullname="Shaanan Cohney" initials="S." surname="Cohney">
<organization>University of Pennsylvania, Philadelphia, PA, USA</o
rganization>
</author>
<author fullname="Matthew Green" initials="M." surname="Green">
<organization>Johns Hopkins University, Baltimore, MD, USA</organi
zation>
</author>
<author fullname="Nadia Heninger" initials="N." surname="Heninger">
<organization>University of Pennsylvania, Philadelphia, PA, USA</o
rganization>
</author>
<author fullname="Ralf-Philipp Weinmann" initials="RP." surname="Wei
nmann">
<organization>Comsecuris, Duisburg, Germany</organization>
</author>
<author 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">
<organization>UC San Diego, La Jolla, CA, USA</organization>
</author>
<date month="October" year="2016"/>
</front>
<refcontent>Proceedings of the 2016 ACM SIGSAC Conference on Computer
and Communications Security</refcontent>
<seriesInfo name="DOI" value="10.1145/2976749.2978395"/>
</reference>
<t>The entire public key packet is thus:</t> </references>
</references>
<section anchor="test-vectors">
<name>Test Vectors</name>
<t>To help with the implementation of this specification, a set of non-nor
mative examples follow.</t>
<section anchor="sample-v4-ed25519legacy-key">
<name>Sample v4 Ed25519Legacy Key</name>
<t>The secret key used for this example is:</t>
<artwork><![CDATA[
D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2
]]></artwork>
<t>Note that this is the raw secret key used as input to the EdDSA signi
ng operation.
The key was created on 2014-08-19 14:28:27 and thus the fingerprint of the OpenP
GP key is:</t>
<artwork><![CDATA[
C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A
]]></artwork>
<t>The algorithm-specific input parameters without the MPI length header
s are:</t>
<artwork><![CDATA[
oid: 2b06010401da470f01
<figure><artwork><![CDATA[ q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406
]]></artwork>
<t>The entire public key packet is thus:</t>
<artwork><![CDATA[
98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47 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 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 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e
43 ee 3b 24 06 43 ee 3b 24 06
]]></artwork></figure> ]]></artwork>
<t>The same packet represented in ASCII-armored form is:</t>
<t>The same packet, represented in ASCII-armored form is:</t> <sourcecode type="application/pgp-keys" name="v4-ed25519-pubkey-packet.k
ey"><![CDATA[
<figure><sourcecode type="application/pgp-keys" name="v4-ed25519-pubkey-packet.k
ey"><![CDATA[
-----BEGIN PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK-----
xjMEU/NfCxYJKwYBBAHaRw8BAQdAPwmJlL3ZFu1AUxl5NOSofIBzOhKA1i+AEJku xjMEU/NfCxYJKwYBBAHaRw8BAQdAPwmJlL3ZFu1AUxl5NOSofIBzOhKA1i+AEJku
Q+47JAY= Q+47JAY=
-----END PGP PUBLIC KEY BLOCK----- -----END PGP PUBLIC KEY BLOCK-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> <section anchor="sample-v4-ed25519legacy-signature">
<section anchor="sample-v4-ed25519legacy-signature"><name>Sample v4 Ed25519Legac <name>Sample v4 Ed25519Legacy Signature</name>
y signature</name> <t>The signature is created using the sample key over the input data "Op
enPGP" on 2015-09-16 12:24:53 UTC and thus the input to the hash function is:</t
<t>The signature is created using the sample key over the input data "OpenPGP" o >
n 2015-09-16 12:24:53 UTC and thus the input to the hash function is:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
m: 4f70656e504750040016080006050255f95f9504ff0000000c m: 4f70656e504750040016080006050255f95f9504ff0000000c
]]></artwork></figure> ]]></artwork>
<t>Using the SHA2-256 hash algorithm yields the digest:</t>
<t>Using the SHA2-256 hash algorithm yields the digest:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280 d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
]]></artwork></figure> ]]></artwork>
<t>which is fed into the EdDSA signature function and yields the followi
<t>Which is fed into the EdDSA signature function and yields this signature:</t> ng signature:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366 r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366
s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404 s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404
]]></artwork></figure> ]]></artwork>
<t>The entire signature packet is thus:</t>
<t>The entire signature packet is thus:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a 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 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 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 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 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 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>
<t>The same packet represented in ASCII-armored form is:</t> <sourcecode type="application/pgp-signature" name="v4-ed25519-signature-
over-OpenPGP.sig"><![CDATA[
<figure><sourcecode type="application/pgp-signature" name="v4-ed25519-signature-
over-OpenPGP.sig"><![CDATA[
-----BEGIN PGP SIGNATURE----- -----BEGIN PGP SIGNATURE-----
iF4EABYIAAYFAlX5X5UACgkQjP3hIZeWWpr2IgD/VvkMypjiECY3vZg/2xbBMd/S iF4EABYIAAYFAlX5X5UACgkQjP3hIZeWWpr2IgD/VvkMypjiECY3vZg/2xbBMd/S
ftgr9N3lYG4NdWrtM2YBANCcT6EVJ/A44PV/IgHYLy6iyQMyZfps60iehUuuYbQE ftgr9N3lYG4NdWrtM2YBANCcT6EVJ/A44PV/IgHYLy6iyQMyZfps60iehUuuYbQE
-----END PGP SIGNATURE----- -----END PGP SIGNATURE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> <section anchor="v6-cert">
<section anchor="v6-cert"><name>Sample v6 Certificate (Transferable Public Key)< <name>Sample v6 Certificate (Transferable Public Key)</name>
/name> <t>Here is a Transferable Public Key consisting of:</t>
<ul spacing="normal">
<t>Here is a Transferable Public Key consisting of:</t> <li>
<t>A v6 Ed25519 Public-Key packet</t>
<t><list style="symbols"> </li>
<t>A v6 Ed25519 Public-Key packet</t> <li>
<t>A v6 direct key self-signature</t> <t>A v6 direct key self-signature</t>
<t>A v6 X25519 Public-Subkey packet</t> </li>
<t>A v6 subkey binding signature</t> <li>
</list></t> <t>A v6 X25519 Public-Subkey packet</t>
</li>
<t>The primary key has the fingerprint <spanx style="verb">CB186C4F0609A697E4D52 <li>
DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9</spanx>.</t> <t>A v6 subkey binding signature</t>
</li>
<t>The subkey has the fingerprint <spanx style="verb">12C83F1E706F6308FE151A4177 </ul>
43A1F033790E93E9978488D1DB378DA9930885</spanx>.</t> <t>The primary key has the following fingerprint:</t> <t><tt>CB186C4F060
9A697E4D52DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9</tt></t>
<figure><sourcecode type="application/pgp-keys" name="v6-minimal-cert.key"><![CD <t>The subkey has the following fingerprint:</t> <t><tt>12C83F1E706F6308
ATA[ FE151A417743A1F033790E93E9978488D1DB378DA9930885</tt></t>
<sourcecode type="application/pgp-keys" name="v6-minimal-cert.key"><![CD
ATA[
-----BEGIN PGP PUBLIC KEY BLOCK----- -----BEGIN PGP PUBLIC KEY BLOCK-----
xioGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laPCsQYf xioGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laPCsQYf
GwoAAABCBYJjh3/jAwsJBwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxy GwoAAABCBYJjh3/jAwsJBwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxy
KwwfHifBilZwj2Ul7Ce62azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lw KwwfHifBilZwj2Ul7Ce62azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lw
gyU2kCcUmKfvBXbAf6rhRYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaE gyU2kCcUmKfvBXbAf6rhRYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaE
QsiPlR4zxP/TP7mhfVEe7XWPxtnMUMtf15OyA51YBM4qBmOHf+MZAAAAIIaTJINn QsiPlR4zxP/TP7mhfVEe7XWPxtnMUMtf15OyA51YBM4qBmOHf+MZAAAAIIaTJINn
+eUBXbki+PSAld2nhJh/LVmFsS+60WyvXkQ1wpsGGBsKAAAALAWCY4d/4wKbDCIh +eUBXbki+PSAld2nhJh/LVmFsS+60WyvXkQ1wpsGGBsKAAAALAWCY4d/4wKbDCIh
BssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce62azJAAAAAAQBIKbpGG2dWTX8 BssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce62azJAAAAAAQBIKbpGG2dWTX8
j+VjFM21J0hqWlEg+bdiojWnKfA5AQpWUWtnNwDEM0g12vYxoWM8Y81W+bHBw805 j+VjFM21J0hqWlEg+bdiojWnKfA5AQpWUWtnNwDEM0g12vYxoWM8Y81W+bHBw805
I8kWVkXU6vFOi+HWvv/ira7ofJu16NnoUkhclkUrk0mXubZvyl4GBg== I8kWVkXU6vFOi+HWvv/ira7ofJu16NnoUkhclkUrk0mXubZvyl4GBg==
-----END PGP PUBLIC KEY BLOCK----- -----END PGP PUBLIC KEY BLOCK-----
]]></sourcecode></figure> ]]></sourcecode>
<t>The corresponding Transferable Secret Key can be found in <xref targe
<t>The corresponding Transferable Secret Key can be found in <xref target="v6-ke t="v6-key"/>.</t>
y"/>.</t> <section anchor="sig-hashed-data-example">
<name>Hashed Data Stream for Signature Verification</name>
<section anchor="sig-hashed-data-example"><name>Hashed Data Stream for Signature <t>The direct key self-signature in the certificate in <xref target="v
Verification</name> 6-cert"/> is made over the following sequence of data:</t>
<artwork><![CDATA[
<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[
0x0000 10 3e 2d 7d 22 7e c0 e6 0x0000 10 3e 2d 7d 22 7e c0 e6
0x0008 d7 ce 44 71 db 36 bf c9 0x0008 d7 ce 44 71 db 36 bf c9
0x0010 70 83 25 36 90 27 14 98 0x0010 70 83 25 36 90 27 14 98
0x0018 a7 ef 05 76 c0 7f aa e1 0x0018 a7 ef 05 76 c0 7f aa e1
0x0020 9b 00 00 00 2a 06 63 87 0x0020 9b 00 00 00 2a 06 63 87
0x0028 7f e3 1b 00 00 00 20 f9 0x0028 7f e3 1b 00 00 00 20 f9
0x0030 4d a7 bb 48 d6 0a 61 e5 0x0030 4d a7 bb 48 d6 0a 61 e5
0x0038 67 70 6a 65 87 d0 33 19 0x0038 67 70 6a 65 87 d0 33 19
0x0040 99 bb 9d 89 1a 08 24 2e 0x0040 99 bb 9d 89 1a 08 24 2e
0x0048 ad 84 54 3d f8 95 a3 06 0x0048 ad 84 54 3d f8 95 a3 06
0x0050 1f 1b 0a 00 00 00 42 05 0x0050 1f 1b 0a 00 00 00 42 05
0x0058 82 63 87 7f e3 03 0b 09 0x0058 82 63 87 7f e3 03 0b 09
0x0060 07 05 15 0a 0e 08 0c 02 0x0060 07 05 15 0a 0e 08 0c 02
0x0068 16 00 02 9b 03 02 1e 09 0x0068 16 00 02 9b 03 02 1e 09
0x0070 22 21 06 cb 18 6c 4f 06 0x0070 22 21 06 cb 18 6c 4f 06
0x0078 09 a6 97 e4 d5 2d fa 6c 0x0078 09 a6 97 e4 d5 2d fa 6c
0x0080 72 2b 0c 1f 1e 27 c1 8a 0x0080 72 2b 0c 1f 1e 27 c1 8a
0x0088 56 70 8f 65 25 ec 27 ba 0x0088 56 70 8f 65 25 ec 27 ba
0x0090 d9 ac c9 05 27 09 02 07 0x0090 d9 ac c9 05 27 09 02 07
0x0098 02 06 ff 00 00 00 4a 0x0098 02 06 ff 00 00 00 4a
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics, is:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 10 3e 2d 7d 22 7e c0 e6 salt 0x0000 10 3e 2d 7d 22 7e c0 e6 salt
0x0008 d7 ce 44 71 db 36 bf c9 0x0008 d7 ce 44 71 db 36 bf c9
0x0010 70 83 25 36 90 27 14 98 0x0010 70 83 25 36 90 27 14 98
0x0018 a7 ef 05 76 c0 7f aa e1 0x0018 a7 ef 05 76 c0 7f aa e1
[ pubkey begins ] [ pubkey begins ]
0x0020 9b v6 pubkey 0x0020 9b v6 pubkey
0x0021 00 00 00 2a pubkey length 0x0021 00 00 00 2a pubkey length
0x0025 06 pubkey version 0x0025 06 pubkey version
0x0026 63 87 creation time 0x0026 63 87 creation time
0x0028 7f e3 (2022-11-30T16:08:03Z) 0x0028 7f e3 (2022-11-30T16:08:03Z)
0x002a 1b key algo: Ed25519 0x002a 1b key algo: Ed25519
0x002b 00 00 00 20 key length 0x002b 00 00 00 20 key length
0x002f f9 Ed25519 public key 0x002f f9 Ed25519 public key
0x0030 4d a7 bb 48 d6 0a 61 e5 0x0030 4d a7 bb 48 d6 0a 61 e5
0x0038 67 70 6a 65 87 d0 33 19 0x0038 67 70 6a 65 87 d0 33 19
0x0040 99 bb 9d 89 1a 08 24 2e 0x0040 99 bb 9d 89 1a 08 24 2e
0x0048 ad 84 54 3d f8 95 a3 0x0048 ad 84 54 3d f8 95 a3
[ trailer begins ] [ trailer begins ]
0x004f 06 sig version 0x004f 06 sig version
0x0050 1f sig type: direct key signature 0x0050 1f sig type: Direct Key Signature
0x0051 1b sig algo: Ed25519 0x0051 1b sig algo: Ed25519
0x0052 0a hash ago: SHA2-512 0x0052 0a hash ago: SHA2-512
0x0053 00 00 00 42 hashed subpackets length 0x0053 00 00 00 42 hashed subpackets length
0x0057 05 subpkt length 0x0057 05 subpkt length
0x0058 82 critical subpkt: Sig Creation Time 0x0058 82 critical subpkt: Sig Creation Time
0x0059 63 87 7f e3 Signature Creation Time 0x0059 63 87 7f e3 Signature Creation Time
0x005d 03 subpkt length 0x005d 03 subpkt length
0x005e 0b subpkt type: Pref. v1 SEIPD Ciphers 0x005e 0b subpkt type: Pref. v1 SEIPD Ciphers
0x005f 09 Ciphers: [AES256 AES128] 0x005f 09 Ciphers: [AES256 AES128]
0x0060 07 0x0060 07
skipping to change at line 6829 skipping to change at line 7039
0x0069 00 Compression: [none] 0x0069 00 Compression: [none]
0x006a 02 subpkt length 0x006a 02 subpkt length
0x006b 9b critical subpkt: Key Flags 0x006b 9b critical subpkt: Key Flags
0x006c 03 Key Flags: {certify, sign} 0x006c 03 Key Flags: {certify, sign}
0x006d 02 subpkt length 0x006d 02 subpkt length
0x006e 1e subpkt type: Features 0x006e 1e subpkt type: Features
0x006f 09 Features: {SEIPDv1, SEIPDv2} 0x006f 09 Features: {SEIPDv1, SEIPDv2}
0x0070 22 subpkt length 0x0070 22 subpkt length
0x0071 21 subpkt type: Issuer Fingerprint 0x0071 21 subpkt type: Issuer Fingerprint
0x0072 06 Fingerprint version 6 0x0072 06 Fingerprint version 6
0x0073 cb 18 6c 4f 06 Issuer Fingerprint 0x0073 cb 18 6c 4f 06 Fingerprint
0x0078 09 a6 97 e4 d5 2d fa 6c 0x0078 09 a6 97 e4 d5 2d fa 6c
0x0080 72 2b 0c 1f 1e 27 c1 8a 0x0080 72 2b 0c 1f 1e 27 c1 8a
0x0088 56 70 8f 65 25 ec 27 ba 0x0088 56 70 8f 65 25 ec 27 ba
0x0090 d9 ac c9 0x0090 d9 ac c9
0x0093 05 subpkt length 0x0093 05 subpkt length
0x0094 27 subpkt type: Pref. AEAD Ciphersuites 0x0094 27 subpkt type: Pref. AEAD Ciphersuites
0x0095 09 02 07 Ciphersuites: 0x0095 09 02 07 Ciphersuites:
0x0098 02 [ AES256-OCB, AES128-OCB ] 0x0098 02 [ AES256-OCB, AES128-OCB ]
0x0099 06 sig version 0x0099 06 sig version
0x009a ff sentinel octet 0x009a ff sentinel octet
0x009b 00 00 00 4a trailer length 0x009b 00 00 00 4a trailer length
]]></artwork></figure> ]]></artwork>
<t>The subkey binding signature in <xref target="v6-cert"/> is made ov
<t>The subkey binding signature in <xref target="v6-cert"/> is made over the fol er the following sequence of data:</t>
lowing sequence of data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 a6 e9 18 6d 9d 59 35 fc 0x0000 a6 e9 18 6d 9d 59 35 fc
0x0008 8f e5 63 14 cd b5 27 48 0x0008 8f e5 63 14 cd b5 27 48
0x0010 6a 5a 51 20 f9 b7 62 a2 0x0010 6a 5a 51 20 f9 b7 62 a2
0x0018 35 a7 29 f0 39 01 0a 56 0x0018 35 a7 29 f0 39 01 0a 56
0x0020 9b 00 00 00 2a 06 63 87 0x0020 9b 00 00 00 2a 06 63 87
0x0028 7f e3 1b 00 00 00 20 f9 0x0028 7f e3 1b 00 00 00 20 f9
0x0030 4d a7 bb 48 d6 0a 61 e5 0x0030 4d a7 bb 48 d6 0a 61 e5
0x0038 67 70 6a 65 87 d0 33 19 0x0038 67 70 6a 65 87 d0 33 19
0x0040 99 bb 9d 89 1a 08 24 2e 0x0040 99 bb 9d 89 1a 08 24 2e
0x0048 ad 84 54 3d f8 95 a3 9b 0x0048 ad 84 54 3d f8 95 a3 9b
skipping to change at line 6869 skipping to change at line 7077
0x0068 22 f8 f4 80 95 dd a7 84 0x0068 22 f8 f4 80 95 dd a7 84
0x0070 98 7f 2d 59 85 b1 2f ba 0x0070 98 7f 2d 59 85 b1 2f ba
0x0078 d1 6c af 5e 44 35 06 18 0x0078 d1 6c af 5e 44 35 06 18
0x0080 1b 0a 00 00 00 2c 05 82 0x0080 1b 0a 00 00 00 2c 05 82
0x0088 63 87 7f e3 02 9b 0c 22 0x0088 63 87 7f e3 02 9b 0c 22
0x0090 21 06 cb 18 6c 4f 06 09 0x0090 21 06 cb 18 6c 4f 06 09
0x0098 a6 97 e4 d5 2d fa 6c 72 0x0098 a6 97 e4 d5 2d fa 6c 72
0x00a0 2b 0c 1f 1e 27 c1 8a 56 0x00a0 2b 0c 1f 1e 27 c1 8a 56
0x00a8 70 8f 65 25 ec 27 ba d9 0x00a8 70 8f 65 25 ec 27 ba d9
0x00b0 ac c9 06 ff 00 00 00 34 0x00b0 ac c9 06 ff 00 00 00 34
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics, is:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 a6 e9 18 6d 9d 59 35 fc salt 0x0000 a6 e9 18 6d 9d 59 35 fc salt
0x0008 8f e5 63 14 cd b5 27 48 0x0008 8f e5 63 14 cd b5 27 48
0x0010 6a 5a 51 20 f9 b7 62 a2 0x0010 6a 5a 51 20 f9 b7 62 a2
0x0018 35 a7 29 f0 39 01 0a 56 0x0018 35 a7 29 f0 39 01 0a 56
[ primary pubkey begins ] [ primary pubkey begins ]
0x0020 9b v6 pubkey 0x0020 9b v6 pubkey
0x0021 00 00 00 2a pubkey length 0x0021 00 00 00 2a pubkey length
0x0025 06 pubkey version 0x0025 06 pubkey version
0x0026 63 87 creation time 0x0026 63 87 creation time
0x0028 7f e3 (2022-11-30T16:08:03Z) 0x0028 7f e3 (2022-11-30T16:08:03Z)
skipping to change at line 6906 skipping to change at line 7112
0x0058 e3 0x0058 e3
0x0059 19 key algo: X25519 0x0059 19 key algo: X25519
0x005a 00 00 00 20 key length 0x005a 00 00 00 20 key length
0x005e 86 93 X25519 public key 0x005e 86 93 X25519 public key
0x0060 24 83 67 f9 e5 01 5d b9 0x0060 24 83 67 f9 e5 01 5d b9
0x0068 22 f8 f4 80 95 dd a7 84 0x0068 22 f8 f4 80 95 dd a7 84
0x0070 98 7f 2d 59 85 b1 2f ba 0x0070 98 7f 2d 59 85 b1 2f ba
0x0078 d1 6c af 5e 44 35 0x0078 d1 6c af 5e 44 35
[ trailer begins ] [ trailer begins ]
0x007e 06 sig version 0x007e 06 sig version
0x007f 18 sig type: Subkey Binding sig 0x007f 18 sig type: Subkey Binding Sig
0x0080 1b sig algo Ed25519 0x0080 1b sig algo Ed25519
0x0081 0a hash algo: SHA2-512 0x0081 0a hash algo: SHA2-512
0x0082 00 00 00 2c hashed subpackets length 0x0082 00 00 00 2c hashed subpackets length
0x0086 05 subpkt length 0x0086 05 subpkt length
0x0087 82 critical subpkt: Sig Creation Time 0x0087 82 critical subpkt: Sig Creation Time
0x0088 63 87 7f e3 Signature Creation Time 0x0088 63 87 7f e3 Signature Creation Time
0x008c 02 subpkt length 0x008c 02 subpkt length
0x008d 9b critical subpkt: Key Flags 0x008d 9b critical subpkt: Key Flags
0x008e 0c Key Flags: {EncComms, EncStorage} 0x008e 0c Key Flags: {EncComms, EncStorage}
0x008f 22 subpkt length 0x008f 22 subpkt length
0x0090 21 subpkt type: Issuer Fingerprint 0x0090 21 subpkt type: Issuer Fingerprint
0x0091 06 Fingerprint version 6 0x0091 06 Fingerprint version 6
0x0092 cb 18 6c 4f 06 09 Fingerprint 0x0092 cb 18 6c 4f 06 09 Fingerprint
0x0098 a6 97 e4 d5 2d fa 6c 72 0x0098 a6 97 e4 d5 2d fa 6c 72
0x00a0 2b 0c 1f 1e 27 c1 8a 56 0x00a0 2b 0c 1f 1e 27 c1 8a 56
0x00a8 70 8f 65 25 ec 27 ba d9 0x00a8 70 8f 65 25 ec 27 ba d9
0x00b0 ac c9 0x00b0 ac c9
0x00b2 06 sig version 0x00b2 06 sig version
0x00b3 ff sentinel octet 0x00b3 ff sentinel octet
0x00b4 00 00 00 34 trailer length 0x00b4 00 00 00 34 trailer length
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="v6-key">
<section anchor="v6-key"><name>Sample v6 Secret Key (Transferable Secret Key)</n <name>Sample v6 Secret Key (Transferable Secret Key)</name>
ame> <t>Here is a Transferable Secret Key consisting of:</t>
<ul spacing="normal">
<t>Here is a Transferable Secret Key consisting of:</t> <li>
<t>A v6 Ed25519 Secret-Key packet</t>
<t><list style="symbols"> </li>
<t>A v6 Ed25519 Secret-Key packet</t> <li>
<t>A v6 direct key self-signature</t> <t>A v6 direct key self-signature</t>
<t>A v6 X25519 Secret-Subkey packet</t> </li>
<t>A v6 subkey binding signature</t> <li>
</list></t> <t>A v6 X25519 Secret-Subkey packet</t>
</li>
<figure><sourcecode type="application/pgp-keys" name="v6-minimal-secret.key"><![ <li>
CDATA[ <t>A v6 subkey binding signature</t>
</li>
</ul>
<sourcecode type="application/pgp-keys" name="v6-minimal-secret.key"><![
CDATA[
-----BEGIN PGP PRIVATE KEY BLOCK----- -----BEGIN PGP PRIVATE KEY BLOCK-----
xUsGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laMAGXKB xUsGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laMAGXKB
exK+cH6NX1hs5hNhIB00TrJmosgv3mg1ditlsLfCsQYfGwoAAABCBYJjh3/jAwsJ exK+cH6NX1hs5hNhIB00TrJmosgv3mg1ditlsLfCsQYfGwoAAABCBYJjh3/jAwsJ
BwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6 BwUVCg4IDAIWAAKbAwIeCSIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lwgyU2kCcUmKfvBXbAf6rh 2azJBScJAgcCAAAAAK0oIBA+LX0ifsDm185Ecds2v8lwgyU2kCcUmKfvBXbAf6rh
RYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaEQsiPlR4zxP/TP7mhfVEe RYWzuQOwEn7E/aLwIwRaLsdry0+VcallHhSu4RN6HWaEQsiPlR4zxP/TP7mhfVEe
7XWPxtnMUMtf15OyA51YBMdLBmOHf+MZAAAAIIaTJINn+eUBXbki+PSAld2nhJh/ 7XWPxtnMUMtf15OyA51YBMdLBmOHf+MZAAAAIIaTJINn+eUBXbki+PSAld2nhJh/
LVmFsS+60WyvXkQ1AE1gCk95TUR3XFeibg/u/tVY6a//1q0NWC1X+yui3O24wpsG LVmFsS+60WyvXkQ1AE1gCk95TUR3XFeibg/u/tVY6a//1q0NWC1X+yui3O24wpsG
GBsKAAAALAWCY4d/4wKbDCIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6 GBsKAAAALAWCY4d/4wKbDCIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJAAAAAAQBIKbpGG2dWTX8j+VjFM21J0hqWlEg+bdiojWnKfA5AQpWUWtnNwDE 2azJAAAAAAQBIKbpGG2dWTX8j+VjFM21J0hqWlEg+bdiojWnKfA5AQpWUWtnNwDE
M0g12vYxoWM8Y81W+bHBw805I8kWVkXU6vFOi+HWvv/ira7ofJu16NnoUkhclkUr M0g12vYxoWM8Y81W+bHBw805I8kWVkXU6vFOi+HWvv/ira7ofJu16NnoUkhclkUr
k0mXubZvyl4GBg== k0mXubZvyl4GBg==
-----END PGP PRIVATE KEY BLOCK----- -----END PGP PRIVATE KEY BLOCK-----
]]></sourcecode></figure> ]]></sourcecode>
<t>The corresponding Transferable Public Key can be found in <xref targe
<t>The corresponding Transferable Public Key can be found in <xref target="v6-ce t="v6-cert"/>.</t>
rt"/>.</t> </section>
<section anchor="v6-locked-key">
</section> <name>Sample Locked v6 Secret Key (Transferable Secret Key)</name>
<section anchor="v6-locked-key"><name>Sample locked v6 Secret Key (Transferable <t>Here is the same secret key as in <xref target="v6-key"/>, but the se
Secret Key)</name> cret key material is locked with a passphrase using AEAD and Argon2.</t>
<t>The passphrase is the ASCII string:</t>
<t>Here is the same secret key as in <xref target="v6-key"/>, but the secret key <artwork><![CDATA[
material is locked with a passphrase using AEAD and Argon2.</t>
<t>The passphrase is the ASCII string:</t>
<figure><artwork><![CDATA[
correct horse battery staple correct horse battery staple
]]></artwork></figure> ]]></artwork>
<sourcecode type="application/pgp-keys" name="v6-minimal-secret-locked.k
<figure><sourcecode type="application/pgp-keys" name="v6-minimal-secret-locked.k ey"><![CDATA[
ey"><![CDATA[
-----BEGIN PGP PRIVATE KEY BLOCK----- -----BEGIN PGP PRIVATE KEY BLOCK-----
xYIGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laP9JgkC xYIGY4d/4xsAAAAg+U2nu0jWCmHlZ3BqZYfQMxmZu52JGggkLq2EVD34laP9JgkC
FARdb9ccngltHraRe25uHuyuAQQVtKipJ0+r5jL4dacGWSAheCWPpITYiyfyIOPS FARdb9ccngltHraRe25uHuyuAQQVtKipJ0+r5jL4dacGWSAheCWPpITYiyfyIOPS
3gIDyg8f7strd1OB4+LZsUhcIjOMpVHgmiY/IutJkulneoBYwrEGHxsKAAAAQgWC 3gIDyg8f7strd1OB4+LZsUhcIjOMpVHgmiY/IutJkulneoBYwrEGHxsKAAAAQgWC
Y4d/4wMLCQcFFQoOCAwCFgACmwMCHgkiIQbLGGxPBgmml+TVLfpscisMHx4nwYpW Y4d/4wMLCQcFFQoOCAwCFgACmwMCHgkiIQbLGGxPBgmml+TVLfpscisMHx4nwYpW
cI9lJewnutmsyQUnCQIHAgAAAACtKCAQPi19In7A5tfORHHbNr/JcIMlNpAnFJin cI9lJewnutmsyQUnCQIHAgAAAACtKCAQPi19In7A5tfORHHbNr/JcIMlNpAnFJin
7wV2wH+q4UWFs7kDsBJ+xP2i8CMEWi7Ha8tPlXGpZR4UruETeh1mhELIj5UeM8T/ 7wV2wH+q4UWFs7kDsBJ+xP2i8CMEWi7Ha8tPlXGpZR4UruETeh1mhELIj5UeM8T/
0z+5oX1RHu11j8bZzFDLX9eTsgOdWATHggZjh3/jGQAAACCGkySDZ/nlAV25Ivj0 0z+5oX1RHu11j8bZzFDLX9eTsgOdWATHggZjh3/jGQAAACCGkySDZ/nlAV25Ivj0
gJXdp4SYfy1ZhbEvutFsr15ENf0mCQIUBA5hhGgp2oaavg6mFUXcFMwBBBUuE8qf gJXdp4SYfy1ZhbEvutFsr15ENf0mCQIUBA5hhGgp2oaavg6mFUXcFMwBBBUuE8qf
9Ock+xwusd+GAglBr5LVyr/lup3xxQvHXFSjjA2haXfoN6xUGRdDEHI6+uevKjVR 9Ock+xwusd+GAglBr5LVyr/lup3xxQvHXFSjjA2haXfoN6xUGRdDEHI6+uevKjVR
v5oAxgu7eJpaXNjCmwYYGwoAAAAsBYJjh3/jApsMIiEGyxhsTwYJppfk1S36bHIr v5oAxgu7eJpaXNjCmwYYGwoAAAAsBYJjh3/jApsMIiEGyxhsTwYJppfk1S36bHIr
DB8eJ8GKVnCPZSXsJ7rZrMkAAAAABAEgpukYbZ1ZNfyP5WMUzbUnSGpaUSD5t2Ki DB8eJ8GKVnCPZSXsJ7rZrMkAAAAABAEgpukYbZ1ZNfyP5WMUzbUnSGpaUSD5t2Ki
Nacp8DkBClZRa2c3AMQzSDXa9jGhYzxjzVb5scHDzTkjyRZWRdTq8U6L4da+/+Kt Nacp8DkBClZRa2c3AMQzSDXa9jGhYzxjzVb5scHDzTkjyRZWRdTq8U6L4da+/+Kt
ruh8m7Xo2ehSSFyWRSuTSZe5tm/KXgYG ruh8m7Xo2ehSSFyWRSuTSZe5tm/KXgYG
-----END PGP PRIVATE KEY BLOCK----- -----END PGP PRIVATE KEY BLOCK-----
]]></sourcecode></figure> ]]></sourcecode>
<section anchor="intermediate-data-for-locked-primary-key">
<section anchor="intermediate-data-for-locked-primary-key"><name>Intermediate Da <name>Intermediate Data for Locked Primary Key</name>
ta for Locked Primary Key</name> <t>The S2K-derived material for the primary key is:</t>
<artwork><![CDATA[
<t>The S2K-derived material for the primary key is:</t>
<figure><artwork><![CDATA[
832bd2662a5c2b251ee3fc82aec349a766ca539015880133002e5a21960b3bcf 832bd2662a5c2b251ee3fc82aec349a766ca539015880133002e5a21960b3bcf
]]></artwork></figure> ]]></artwork>
<t>After HKDF, the symmetric key used for AEAD encryption of the prima
<t>After HKDF, the symmetric key used for AEAD encryption of the primary key is: ry key is:</t>
</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
9e37cb26787f37e18db172795c4c297550d39ac82511d9af4c8706db6a77fd51 9e37cb26787f37e18db172795c4c297550d39ac82511d9af4c8706db6a77fd51
]]></artwork></figure> ]]></artwork>
<t>The additional data for AEAD for the primary key is:</t>
<t>The additional data for AEAD for the primary key is:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
c50663877fe31b00000020f94da7bb48d60a61e567706a6587d0331999bb9d89 c50663877fe31b00000020f94da7bb48d60a61e567706a6587d0331999bb9d89
1a08242ead84543df895a3 1a08242ead84543df895a3
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="intermediate-data-for-locked-subkey">
<section anchor="intermediate-data-for-locked-subkey"><name>Intermediate Data fo <name>Intermediate Data for Locked Subkey</name>
r Locked Subkey</name> <t>The S2K-derived key material for the subkey is:</t>
<artwork><![CDATA[
<t>The S2K-derived key material for the subkey is:</t>
<figure><artwork><![CDATA[
f74a6ce873a089ef13a3da9ac059777bb22340d15eaa6c9dc0f8ef09035c67cd f74a6ce873a089ef13a3da9ac059777bb22340d15eaa6c9dc0f8ef09035c67cd
]]></artwork></figure> ]]></artwork>
<t>After HKDF, the symmetric key used for AEAD encryption of the subke
<t>After HKDF, the symmetric key used for AEAD encryption of the subkey is:</t> y is:</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
3c60cb63285f62f4c3de49835786f011cf6f4c069f61232cd7013ff5fd31e603 3c60cb63285f62f4c3de49835786f011cf6f4c069f61232cd7013ff5fd31e603
]]></artwork></figure> ]]></artwork>
<t>The additional data for AEAD for the subkey is:</t>
<t>The additional data for AEAD for the subkey is:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
c70663877fe319000000208693248367f9e5015db922f8f48095dda784987f2d c70663877fe319000000208693248367f9e5015db922f8f48095dda784987f2d
5985b12fbad16caf5e4435 5985b12fbad16caf5e4435
]]></artwork></figure> ]]></artwork>
</section>
</section> </section>
</section> <section anchor="sample-csf-message">
<section anchor="sample-csf-message"><name>Sample Cleartext Signed Message</name <name>Sample Cleartext Signed Message</name>
> <t>Here is a signed message that uses the Cleartext Signature Framework
(<xref target="cleartext-signature"/>). It can be verified with the certificate
<t>Here is a signed message that uses the cleartext signature framework (<xref t from <xref target="v6-cert"/>.</t>
arget="cleartext-signature"/>). <t>Note that this message makes use of dash-escaping (<xref target="dash
It can be verified with the certificate from (<xref target="v6-cert"/>).</t> -escaping"/>) due to its contents.</t>
<sourcecode type="text/plain" name="cleartext-signed-message.txt"><![CDA
<t>Note that this message makes use of dash-escaping (<xref target="dash-escapin TA[
g"/>) due to its contents.</t>
<figure><sourcecode type="text/plain" name="cleartext-signed-message.txt"><![CDA
TA[
-----BEGIN PGP SIGNED MESSAGE----- -----BEGIN PGP SIGNED MESSAGE-----
What we need from the grocery store: What we need from the grocery store:
- - tofu - - tofu
- - vegetables - - vegetables
- - noodles - - noodles
-----BEGIN PGP SIGNATURE----- -----BEGIN PGP SIGNATURE-----
wpgGARsKAAAAKQWCY5ijYyIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6 wpgGARsKAAAAKQWCY5ijYyIhBssYbE8GCaaX5NUt+mxyKwwfHifBilZwj2Ul7Ce6
2azJAAAAAGk2IHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usJ9BvuAqo 2azJAAAAAGk2IHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usJ9BvuAqo
/FvLFuGWMbKAdA+epq7V4HOtAPlBWmU8QOd6aud+aSunHQaaEJ+iTFjP2OMW0KBr /FvLFuGWMbKAdA+epq7V4HOtAPlBWmU8QOd6aud+aSunHQaaEJ+iTFjP2OMW0KBr
NK2ay45cX1IVAQ== NK2ay45cX1IVAQ==
-----END PGP SIGNATURE----- -----END PGP SIGNATURE-----
]]></sourcecode></figure> ]]></sourcecode>
<t>The signature packet here is:</t>
<t>The signature packet here is:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 c2 packet type: Signature 0x0000 c2 packet type: Signature
0x0001 98 packet length 0x0001 98 packet length
0x0002 06 signature version 6 0x0002 06 sig version 6
0x0003 01 signature type: canonical text 0x0003 01 sig type: Canonical Text
0x0004 1b pubkey algorithm: Ed25519 0x0004 1b pubkey algorithm: Ed25519
0x0005 0a hash algorithm used: SHA2-512 0x0005 0a hash algorithm used: SHA2-512
0x0006 00 00 hashed subpackets length: 41 0x0006 00 00 hashed subpackets length: 41
0x0008 00 29 0x0008 00 29
0x000a 05 subpkt length 0x000a 05 subpkt length
0x000b 82 critical subpkt: Sig Creation Time 0x000b 82 critical subpkt: Sig Creation Time
0x000c 63 98 a3 63 (2022-12-13T16:08:03Z) 0x000c 63 98 a3 63 (2022-12-13T16:08:03Z)
0x0010 22 subpkt length 0x0010 22 subpkt length
0x0011 21 subpkt type: issuer fingerprint 0x0011 21 subpkt type: Issuer Fingerprint
0x0012 06 key version 0x0012 06 Key version
0x0013 cb 18 6c 4f 06 v6 fingerprint 0x0013 cb 18 6c 4f 06 Fingerprint version 6
0x001a 09 a6 97 e4 d5 2d fa 6c 0x001a 09 a6 97 e4 d5 2d fa 6c
0x0020 72 2b 0c 1f 1e 27 c1 8a 0x0020 72 2b 0c 1f 1e 27 c1 8a
0x0028 56 70 8f 65 25 ec 27 ba 0x0028 56 70 8f 65 25 ec 27 ba
0x0030 d9 ac c9 0x0030 d9 ac c9
0x0033 00 00 00 00 unhashed subpackets length: 0 0x0033 00 00 00 00 unhashed subpackets length: 0
0x0037 69 left 16 bits of signed hash 0x0037 69 left 16 bits of signed hash
0x0038 36 0x0038 36
0x0039 20 salt length 0x0039 20 salt length
0x003a 76 49 5f 50 21 88 salt 0x003a 76 49 5f 50 21 88 salt
0x0040 90 f7 f5 e2 ee 3c 18 22 0x0040 90 f7 f5 e2 ee 3c 18 22
skipping to change at line 7101 skipping to change at line 7289
0x0058 fb ac 0x0058 fb ac
0x005a 27 d0 6f b8 0a a8 Ed25519 signature 0x005a 27 d0 6f b8 0a a8 Ed25519 signature
0x0060 fc 5b cb 16 e1 96 31 b2 0x0060 fc 5b cb 16 e1 96 31 b2
0x0068 80 74 0f 9e a6 ae d5 e0 0x0068 80 74 0f 9e a6 ae d5 e0
0x0070 73 ad 00 f9 41 5a 65 3c 0x0070 73 ad 00 f9 41 5a 65 3c
0x0078 40 e7 7a 6a e7 7e 69 2b 0x0078 40 e7 7a 6a e7 7e 69 2b
0x0080 a7 1d 06 9a 10 9f a2 4c 0x0080 a7 1d 06 9a 10 9f a2 4c
0x0088 58 cf d8 e3 16 d0 a0 6b 0x0088 58 cf d8 e3 16 d0 a0 6b
0x0090 34 ad 9a cb 8e 5c 5f 52 0x0090 34 ad 9a cb 8e 5c 5f 52
0x0098 15 01 0x0098 15 01
]]></artwork></figure> ]]></artwork>
<t>The signature is made over the following data:</t>
<t>The signature is made over the following data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 76 49 5f 50 21 88 90 f7 0x0000 76 49 5f 50 21 88 90 f7
0x0008 f5 e2 ee 3c 18 22 51 4f 0x0008 f5 e2 ee 3c 18 22 51 4f
0x0010 70 50 0f 55 1d 86 e5 c9 0x0010 70 50 0f 55 1d 86 e5 c9
0x0018 21 e4 04 e3 4a 53 fb ac 0x0018 21 e4 04 e3 4a 53 fb ac
0x0020 57 68 61 74 20 77 65 20 0x0020 57 68 61 74 20 77 65 20
0x0028 6e 65 65 64 20 66 72 6f 0x0028 6e 65 65 64 20 66 72 6f
0x0030 6d 20 74 68 65 20 67 72 0x0030 6d 20 74 68 65 20 67 72
0x0038 6f 63 65 72 79 20 73 74 0x0038 6f 63 65 72 79 20 73 74
0x0040 6f 72 65 3a 0d 0a 0d 0a 0x0040 6f 72 65 3a 0d 0a 0d 0a
0x0048 2d 20 74 6f 66 75 0d 0a 0x0048 2d 20 74 6f 66 75 0d 0a
0x0050 2d 20 76 65 67 65 74 61 0x0050 2d 20 76 65 67 65 74 61
0x0058 62 6c 65 73 0d 0a 2d 20 0x0058 62 6c 65 73 0d 0a 2d 20
0x0060 6e 6f 6f 64 6c 65 73 0d 0x0060 6e 6f 6f 64 6c 65 73 0d
0x0068 0a 06 01 1b 0a 00 00 00 0x0068 0a 06 01 1b 0a 00 00 00
0x0070 29 05 82 63 98 a3 63 22 0x0070 29 05 82 63 98 a3 63 22
0x0078 21 06 cb 18 6c 4f 06 09 0x0078 21 06 cb 18 6c 4f 06 09
0x0080 a6 97 e4 d5 2d fa 6c 72 0x0080 a6 97 e4 d5 2d fa 6c 72
0x0088 2b 0c 1f 1e 27 c1 8a 56 0x0088 2b 0c 1f 1e 27 c1 8a 56
0x0090 70 8f 65 25 ec 27 ba d9 0x0090 70 8f 65 25 ec 27 ba d9
0x0098 ac c9 06 ff 00 00 00 31 0x0098 ac c9 06 ff 00 00 00 31
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics, is:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 76 49 5f 50 21 88 90 f7 salt 0x0000 76 49 5f 50 21 88 90 f7 salt
0x0008 f5 e2 ee 3c 18 22 51 4f 0x0008 f5 e2 ee 3c 18 22 51 4f
0x0010 70 50 0f 55 1d 86 e5 c9 0x0010 70 50 0f 55 1d 86 e5 c9
0x0018 21 e4 04 e3 4a 53 fb ac 0x0018 21 e4 04 e3 4a 53 fb ac
[ message begins ] [ message begins ]
0x0020 57 68 61 74 20 77 65 20 canonicalized message 0x0020 57 68 61 74 20 77 65 20 canonicalized message
0x0028 6e 65 65 64 20 66 72 6f 0x0028 6e 65 65 64 20 66 72 6f
0x0030 6d 20 74 68 65 20 67 72 0x0030 6d 20 74 68 65 20 67 72
0x0038 6f 63 65 72 79 20 73 74 0x0038 6f 63 65 72 79 20 73 74
0x0040 6f 72 65 3a 0d 0a 0d 0a 0x0040 6f 72 65 3a 0d 0a 0d 0a
0x0048 2d 20 74 6f 66 75 0d 0a 0x0048 2d 20 74 6f 66 75 0d 0a
0x0050 2d 20 76 65 67 65 74 61 0x0050 2d 20 76 65 67 65 74 61
0x0058 62 6c 65 73 0d 0a 2d 20 0x0058 62 6c 65 73 0d 0a 2d 20
0x0060 6e 6f 6f 64 6c 65 73 0d 0x0060 6e 6f 6f 64 6c 65 73 0d
0x0068 0a 0x0068 0a
[ trailer begins ] [ trailer begins ]
0x0069 06 sig version 0x0069 06 sig version
0x006a 01 sigtype: canonical text 0x006a 01 sig type: Canonical Text
0x006b 1b pubkey algorithm: Ed25519 0x006b 1b pubkey algorithm: Ed25519
0x006c 0a hash algorithm: SHA2-512 0x006c 0a hash algorithm: SHA2-512
0x006d 00 00 00 hashed subpackets length 0x006d 00 00 00 hashed subpackets length
0x0070 29 0x0070 29
0x0071 05 subpacket length 0x0071 05 subpacket length
0x0072 82 critical subpkt: Sig Creation Time 0x0072 82 critical subpkt: Sig Creation Time
0x0073 63 98 a3 63 (2022-12-13T16:08:03Z) 0x0073 63 98 a3 63 (2022-12-13T16:08:03Z)
0x0077 22 subpkt length 0x0077 22 subpkt length
0x0078 21 subpkt type: issuer fingerprint 0x0078 21 subpkt type: Issuer Fingerprint
0x0079 06 key version 0x0079 06 Key version
0x007a cb 18 6c 4f 06 09 v6 fingerprint 0x007a cb 18 6c 4f 06 09 Fingerprint version 6
0x0080 a6 97 e4 d5 2d fa 6c 72 0x0080 a6 97 e4 d5 2d fa 6c 72
0x0088 2b 0c 1f 1e 27 c1 8a 56 0x0088 2b 0c 1f 1e 27 c1 8a 56
0x0090 70 8f 65 25 ec 27 ba d9 0x0090 70 8f 65 25 ec 27 ba d9
0x0098 ac c9 0x0098 ac c9
0x009a 06 sig version 0x009a 06 sig version
0x009b ff sentinel octet 0x009b ff sentinel octet
0x009c 00 00 00 31 trailer length 0x009c 00 00 00 31 trailer length
]]></artwork></figure> ]]></artwork>
<t>The calculated SHA2-512 hash digest over this data is:</t>
<t>The calculated SHA2-512 hash digest over this data is:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
69365bf44a97af1f0844f1f6ab83fdf6b36f26692efaa621a8aac91c4e29ea07 69365bf44a97af1f0844f1f6ab83fdf6b36f26692efaa621a8aac91c4e29ea07
e894cabc6e2f20eedfce6c03b89141a2cc7cbe245e6e7a5654addbec5000b89b e894cabc6e2f20eedfce6c03b89141a2cc7cbe245e6e7a5654addbec5000b89b
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="sample-inline-signed-message">
<section anchor="sample-inline-signed-message"><name>Sample inline-signed messag <name>Sample Inline-Signed Message</name>
e</name> <t>This is the same message and signature as in <xref target="sample-csf
-message"/> but as an inline-signed message. The hashed data is exactly the same
<t>This is the same message and signature as in <xref target="sample-csf-message , and all intermediate values and annotated hex dumps are also applicable.</t>
"/>, but as inline-signed message. <sourcecode type="text/plain" name="inline-signed-message.pgp"><![CDATA[
The hashed data is exactly the same, and all intermediate values and annotated h
ex dumps are also applicable.</t>
<figure><sourcecode type="text/plain" name="inline-signed-message.pgp"><![CDATA[
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
xEYGAQobIHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usyxhsTwYJppfk xEYGAQobIHZJX1AhiJD39eLuPBgiUU9wUA9VHYblySHkBONKU/usyxhsTwYJppfk
1S36bHIrDB8eJ8GKVnCPZSXsJ7rZrMkBy0p1AAAAAABXaGF0IHdlIG5lZWQgZnJv 1S36bHIrDB8eJ8GKVnCPZSXsJ7rZrMkBy0p1AAAAAABXaGF0IHdlIG5lZWQgZnJv
bSB0aGUgZ3JvY2VyeSBzdG9yZToKCi0gdG9mdQotIHZlZ2V0YWJsZXMKLSBub29k bSB0aGUgZ3JvY2VyeSBzdG9yZToKCi0gdG9mdQotIHZlZ2V0YWJsZXMKLSBub29k
bGVzCsKYBgEbCgAAACkFgmOYo2MiIQbLGGxPBgmml+TVLfpscisMHx4nwYpWcI9l bGVzCsKYBgEbCgAAACkFgmOYo2MiIQbLGGxPBgmml+TVLfpscisMHx4nwYpWcI9l
JewnutmsyQAAAABpNiB2SV9QIYiQ9/Xi7jwYIlFPcFAPVR2G5ckh5ATjSlP7rCfQ JewnutmsyQAAAABpNiB2SV9QIYiQ9/Xi7jwYIlFPcFAPVR2G5ckh5ATjSlP7rCfQ
b7gKqPxbyxbhljGygHQPnqau1eBzrQD5QVplPEDnemrnfmkrpx0GmhCfokxYz9jj b7gKqPxbyxbhljGygHQPnqau1eBzrQD5QVplPEDnemrnfmkrpx0GmhCfokxYz9jj
FtCgazStmsuOXF9SFQE= FtCgazStmsuOXF9SFQE=
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> <section anchor="sample-x25519-aead-ocb-encryption-and-decryption">
<section anchor="sample-x25519-aead-ocb-encryption-and-decryption"><name>Sample <name>Sample X25519-AEAD-OCB Encryption and Decryption</name>
X25519-AEAD-OCB encryption and decryption</name> <t>This example encrypts the cleartext string <tt>Hello, world!</tt> for
the sample cert (see <xref target="v6-cert"/>), using AES-128 with AEAD-OCB enc
<t>This example encrypts the cleartext string <spanx style="verb">Hello, world!< ryption.</t>
/spanx> for the sample cert (see <xref target="v6-cert"/>), using AES-128 with A <section anchor="sample-public-key-encrypted-session-key-packet-v6">
EAD-OCB encryption.</t> <name>Sample Public-Key Encrypted Session Key Packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<section anchor="sample-public-key-encrypted-session-key-packet-v6"><name>Sample <artwork name="v6pkesk-x25519.hexdump"><![CDATA[
public-key encrypted session key packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork name="v6pkesk-x25519.hexdump"><![CDATA[
0x0000 c1 5d 06 21 06 12 c8 3f 0x0000 c1 5d 06 21 06 12 c8 3f
0x0008 1e 70 6f 63 08 fe 15 1a 0x0008 1e 70 6f 63 08 fe 15 1a
0x0010 41 77 43 a1 f0 33 79 0e 0x0010 41 77 43 a1 f0 33 79 0e
0x0018 93 e9 97 84 88 d1 db 37 0x0018 93 e9 97 84 88 d1 db 37
0x0020 8d a9 93 08 85 19 87 cf 0x0020 8d a9 93 08 85 19 87 cf
0x0028 18 d5 f1 b5 3f 81 7c ce 0x0028 18 d5 f1 b5 3f 81 7c ce
0x0030 5a 00 4c f3 93 cc 89 58 0x0030 5a 00 4c f3 93 cc 89 58
0x0038 bd dc 06 5f 25 f8 4a f5 0x0038 bd dc 06 5f 25 f8 4a f5
0x0040 09 b1 7d d3 67 64 18 de 0x0040 09 b1 7d d3 67 64 18 de
0x0048 a3 55 43 79 56 61 79 01 0x0048 a3 55 43 79 56 61 79 01
0x0050 e0 69 57 fb ca 8a 6a 47 0x0050 e0 69 57 fb ca 8a 6a 47
0x0058 a5 b5 15 3e 8d 3a b7 0x0058 a5 b5 15 3e 8d 3a b7
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 c1 packet type: PKESK 0x0000 c1 packet type: PKESK
0x0001 5d packet length 0x0001 5d packet length
0x0002 06 PKESK version 6 0x0002 06 PKESK version 6
0x0003 21 length of fingerprint 0x0003 21 length of fingerprint
0x0004 06 Key version 6 0x0004 06 Key version 6
0x0005 12 c8 3f Key fingerprint 0x0005 12 c8 3f Key fingerprint
0x0008 1e 70 6f 63 08 fe 15 1a 0x0008 1e 70 6f 63 08 fe 15 1a
0x0010 41 77 43 a1 f0 33 79 0e 0x0010 41 77 43 a1 f0 33 79 0e
0x0018 93 e9 97 84 88 d1 db 37 0x0018 93 e9 97 84 88 d1 db 37
0x0020 8d a9 93 08 85 0x0020 8d a9 93 08 85
skipping to change at line 7243 skipping to change at line 7417
0x0026 87 cf Ephemeral key 0x0026 87 cf Ephemeral key
0x0028 18 d5 f1 b5 3f 81 7c ce 0x0028 18 d5 f1 b5 3f 81 7c ce
0x0030 5a 00 4c f3 93 cc 89 58 0x0030 5a 00 4c f3 93 cc 89 58
0x0038 bd dc 06 5f 25 f8 4a f5 0x0038 bd dc 06 5f 25 f8 4a f5
0x0040 09 b1 7d d3 67 64 0x0040 09 b1 7d d3 67 64
0x0046 18 ESK length 0x0046 18 ESK length
0x0047 de ESK 0x0047 de ESK
0x0048 a3 55 43 79 56 61 79 01 0x0048 a3 55 43 79 56 61 79 01
0x0050 e0 69 57 fb ca 8a 6a 47 0x0050 e0 69 57 fb ca 8a 6a 47
0x0058 a5 b5 15 3e 8d 3a b7 0x0058 a5 b5 15 3e 8d 3a b7
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="x25519-encryptiondecryption-of-the-session-key">
<section anchor="x25519-encryptiondecryption-of-the-session-key"><name>X25519 en <name>X25519 Encryption/Decryption of the Session Key</name>
cryption/decryption of the session key</name> <t>Ephemeral key:</t>
<artwork><![CDATA[
<t>Ephemeral key:</t>
<figure><artwork><![CDATA[
87 cf 18 d5 f1 b5 3f 81 7c ce 5a 00 4c f3 93 cc 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 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 k
<t>This ephemeral key is derived from the following ephemeral secret key materia ey material, which is never placed on the wire:</t>
l, which is never placed on the wire:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
af 1e 43 c0 d1 23 ef e8 93 a7 d4 d3 90 f3 a7 61 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 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>Public key from target certificate (see <xref target="v6-cert"/>):</t> >):</t>
<artwork><![CDATA[
<figure><artwork><![CDATA[
86 93 24 83 67 f9 e5 01 5d b9 22 f8 f4 80 95 dd 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 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
<t>The corresponding long-lived X25519 private key material (see <xref target="v target="v6-key"/>):</t>
6-key"/>):</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
4d 60 0a 4f 79 4d 44 77 5c 57 a2 6e 0f ee fe d5 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 58 e9 af ff d6 ad 0d 58 2d 57 fb 2b a2 dc ed b8
]]></artwork></figure> ]]></artwork>
<t>Shared point:</t>
<t>Shared point:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
67 e3 0e 69 cd c7 ba b2 a2 68 0d 78 ac a4 6a 2f 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 8b 6e 2a e4 4d 39 8b dc 6f 92 c5 ad 4a 49 25 14
]]></artwork></figure> ]]></artwork>
<t>HKDF output:</t>
<t>HKDF output:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
f6 6d ad cf f6 45 92 23 9b 25 45 39 b6 4f f6 07 f6 6d ad cf f6 45 92 23 9b 25 45 39 b6 4f f6 07
]]></artwork></figure> ]]></artwork>
<t>Decrypted session key:</t>
<t>Decrypted session key:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
dd 70 8f 6f a1 ed 65 11 4d 68 d2 34 3e 7c 2f 1d dd 70 8f 6f a1 ed 65 11 4d 68 d2 34 3e 7c 2f 1d
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="sample-v2-seipd-packet">
<section anchor="sample-v2-seipd-packet"><name>Sample v2 SEIPD packet</name> <name>Sample v2 SEIPD Packet</name>
<t>This packet contains the following series of octets:</t>
<t>This packet contains the following series of octets:</t> <artwork name="x25519-v2seipd-aes128-ocb.hexdump"><![CDATA[
<figure><artwork name="x25519-v2seipd-aes128-ocb.hexdump"><![CDATA[
0x0000 d2 69 02 07 02 06 61 64 0x0000 d2 69 02 07 02 06 61 64
0x0008 16 53 5b e0 b0 71 6d 60 0x0008 16 53 5b e0 b0 71 6d 60
0x0010 e0 52 a5 6c 4c 40 7f 9e 0x0010 e0 52 a5 6c 4c 40 7f 9e
0x0018 b3 6b 0e fa fe 9a d0 a0 0x0018 b3 6b 0e fa fe 9a d0 a0
0x0020 df 9b 03 3c 69 a2 1b a9 0x0020 df 9b 03 3c 69 a2 1b a9
0x0028 eb d2 c0 ec 95 bf 56 9d 0x0028 eb d2 c0 ec 95 bf 56 9d
0x0030 25 c9 99 ee 4a 3d e1 70 0x0030 25 c9 99 ee 4a 3d e1 70
0x0038 58 f4 0d fa 8b 4c 68 2b 0x0038 58 f4 0d fa 8b 4c 68 2b
0x0040 e3 fb bb d7 b2 7e b0 f5 0x0040 e3 fb bb d7 b2 7e b0 f5
0x0048 9b b5 00 5f 80 c7 c6 f4 0x0048 9b b5 00 5f 80 c7 c6 f4
0x0050 03 88 c3 0a d4 06 ab 05 0x0050 03 88 c3 0a d4 06 ab 05
0x0058 13 dc d6 f9 fd 73 76 56 0x0058 13 dc d6 f9 fd 73 76 56
0x0060 28 6e 11 77 d0 0f 88 8a 0x0060 28 6e 11 77 d0 0f 88 8a
0x0068 db 31 c4 0x0068 db 31 c4
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 d2 packet type: SEIPD 0x0000 d2 packet type: SEIPD
0x0001 69 packet length 0x0001 69 packet length
0x0002 02 SEIPD version 2 0x0002 02 SEIPD version 2
0x0003 07 cipher: AES128 0x0003 07 cipher: AES128
0x0004 02 AEAD mode: OCB 0x0004 02 AEAD mode: OCB
0x0005 06 chunk size (2**12 octets) 0x0005 06 chunk size (2^12 octets)
0x0006 61 64 salt 0x0006 61 64 salt
0x0008 16 53 5b e0 b0 71 6d 60 0x0008 16 53 5b e0 b0 71 6d 60
0x0010 e0 52 a5 6c 4c 40 7f 9e 0x0010 e0 52 a5 6c 4c 40 7f 9e
0x0018 b3 6b 0e fa fe 9a d0 a0 0x0018 b3 6b 0e fa fe 9a d0 a0
0x0020 df 9b 03 3c 69 a2 0x0020 df 9b 03 3c 69 a2
0x0026 1b a9 chunk #0 encrypted data 0x0026 1b a9 chunk #0 encrypted data
0x0028 eb d2 c0 ec 95 bf 56 9d 0x0028 eb d2 c0 ec 95 bf 56 9d
0x0030 25 c9 99 ee 4a 3d e1 70 0x0030 25 c9 99 ee 4a 3d e1 70
0x0038 58 f4 0d fa 8b 4c 68 2b 0x0038 58 f4 0d fa 8b 4c 68 2b
0x0040 e3 fb bb d7 b2 7e b0 f5 0x0040 e3 fb bb d7 b2 7e b0 f5
0x0048 9b b5 00 0x0048 9b b5 00
0x004b 5f 80 c7 c6 f4 chunk #0 AEAD tag 0x004b 5f 80 c7 c6 f4 chunk #0 AEAD tag
0x0050 03 88 c3 0a d4 06 ab 05 0x0050 03 88 c3 0a d4 06 ab 05
0x0058 13 dc d6 0x0058 13 dc d6
0x005b f9 fd 73 76 56 final AEAD tag (#1) 0x005b f9 fd 73 76 56 final AEAD tag (#1)
0x0060 28 6e 11 77 d0 0f 88 8a S0x0060 28 6e 11 77 d0 0f 88 8a
0x0068 db 31 c4 0x0068 db 31 c4
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="decryption-of-data">
<section anchor="decryption-of-data"><name>Decryption of data</name> <name>Decryption of Data</name>
<t>Starting AEAD-OCB decryption of data, using the session key.</t>
<t>Starting AEAD-OCB decryption of data, using the session key.</t> <t>HKDF info:</t>
<artwork><![CDATA[
<t>HKDF info:</t>
<figure><artwork><![CDATA[
d2 02 07 02 06 d2 02 07 02 06
]]></artwork></figure> ]]></artwork>
<t>HKDF output:</t>
<t>HKDF output:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
45 12 f7 14 9d 86 33 41 52 7c 65 67 d5 bf fc 42 45 12 f7 14 9d 86 33 41 52 7c 65 67 d5 bf fc 42
5f af 32 50 21 2f f9 5f af 32 50 21 2f f9
]]></artwork></figure> ]]></artwork>
<t>Message key:</t>
<t>Message key:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
45 12 f7 14 9d 86 33 41 52 7c 65 67 d5 bf fc 42 45 12 f7 14 9d 86 33 41 52 7c 65 67 d5 bf fc 42
]]></artwork></figure> ]]></artwork>
<t>Initialization vector:</t>
<t>Initialization vector:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
5f af 32 50 21 2f f9 5f af 32 50 21 2f f9
]]></artwork></figure> ]]></artwork>
<t>Chunk #0:</t>
<t>Chunk #0:</t> <t>Nonce:</t>
<artwork><![CDATA[
<t>Nonce:</t>
<figure><artwork><![CDATA[
5f af 32 50 21 2f f9 00 00 00 00 00 00 00 00 5f af 32 50 21 2f f9 00 00 00 00 00 00 00 00
]]></artwork></figure> ]]></artwork>
<t>Additional authenticated data:</t>
<t>Additional authenticated data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d2 02 07 02 06 d2 02 07 02 06
]]></artwork></figure> ]]></artwork>
<t>Encrypted data chunk:</t>
<t>Encrypted data chunk:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
1b a9 eb d2 c0 ec 95 bf 56 9d 25 c9 99 ee 4a 3d 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 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 b0 f5 9b b5 00 5f 80 c7 c6 f4 03 88 c3 0a d4 06
ab 05 13 dc d6 ab 05 13 dc d6
]]></artwork></figure> ]]></artwork>
<t>Decrypted chunk #0.</t>
<t>Decrypted chunk #0.</t> <t>Literal data packet with the string contents <tt>Hello, world!</tt>
:</t>
<t>Literal data packet with the string contents <spanx style="verb">Hello, world <artwork><![CDATA[
!</spanx>:</t>
<figure><artwork><![CDATA[
cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77 cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
6f 72 6c 64 21 6f 72 6c 64 21
]]></artwork></figure> ]]></artwork>
<t>Padding packet:</t>
<t>Padding packet:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d5 0e c5 a2 93 07 29 91 62 81 47 d7 2c 8f 86 b7 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>Authenticating final tag:</t> <t>Final nonce:</t>
<artwork><![CDATA[
<t>Final nonce:</t>
<figure><artwork><![CDATA[
5f af 32 50 21 2f f9 00 00 00 00 00 00 00 01 5f af 32 50 21 2f f9 00 00 00 00 00 00 00 01
]]></artwork></figure> ]]></artwork>
<t>Final additional authenticated data:</t>
<t>Final additional authenticated data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d2 02 07 02 06 00 00 00 00 00 00 00 25 d2 02 07 02 06 00 00 00 00 00 00 00 25
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="complete-x25519-aead-ocb-encrypted-packet-sequence">
<section anchor="complete-x25519-aead-ocb-encrypted-packet-sequence"><name>Compl <name>Complete X25519-AEAD-OCB Encrypted Packet Sequence</name>
ete X25519-AEAD-OCB encrypted packet sequence</name> <sourcecode type="application/pgp-encrypted" name="v6pkesk-aes128-ocb.
pgp"><![CDATA[
<figure><sourcecode type="application/pgp-encrypted" name="v6pkesk-aes128-ocb.pg
p"><![CDATA[
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
wV0GIQYSyD8ecG9jCP4VGkF3Q6HwM3kOk+mXhIjR2zeNqZMIhRmHzxjV8bU/gXzO wV0GIQYSyD8ecG9jCP4VGkF3Q6HwM3kOk+mXhIjR2zeNqZMIhRmHzxjV8bU/gXzO
WgBM85PMiVi93AZfJfhK9QmxfdNnZBjeo1VDeVZheQHgaVf7yopqR6W1FT6NOrfS WgBM85PMiVi93AZfJfhK9QmxfdNnZBjeo1VDeVZheQHgaVf7yopqR6W1FT6NOrfS
aQIHAgZhZBZTW+CwcW1g4FKlbExAf56zaw76/prQoN+bAzxpohup69LA7JW/Vp0l aQIHAgZhZBZTW+CwcW1g4FKlbExAf56zaw76/prQoN+bAzxpohup69LA7JW/Vp0l
yZnuSj3hcFj0DfqLTGgr4/u717J+sPWbtQBfgMfG9AOIwwrUBqsFE9zW+f1zdlYo yZnuSj3hcFj0DfqLTGgr4/u717J+sPWbtQBfgMfG9AOIwwrUBqsFE9zW+f1zdlYo
bhF30A+IitsxxA== bhF30A+IitsxxA==
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="sample-aead-eax-encryption-and-decryption">
<section anchor="sample-aead-eax-encryption-and-decryption"><name>Sample AEAD-EA <name>Sample AEAD-EAX Encryption and Decryption</name>
X encryption and decryption</name> <t>This example encrypts the cleartext string <tt>Hello, world!</tt> wit
h the passphrase <tt>password</tt>, using AES-128 with AEAD-EAX encryption.</t>
<t>This example encrypts the cleartext string <spanx style="verb">Hello, world!< <section anchor="sample-symmetric-key-encrypted-session-key-packet-v6">
/spanx> with the passphrase <spanx style="verb">password</spanx>, using AES-128 <name>Sample Symmetric-Key Encrypted Session Key Packet (v6)</name>
with AEAD-EAX encryption.</t> <t>This packet contains the following series of octets:</t>
<artwork name="v6skesk-aes128-eax.hexdump"><![CDATA[
<section anchor="sample-symmetric-key-encrypted-session-key-packet-v6"><name>Sam
ple symmetric-key encrypted session key packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork name="v6skesk-aes128-eax.hexdump"><![CDATA[
0x0000 c3 40 06 1e 07 01 0b 03 0x0000 c3 40 06 1e 07 01 0b 03
0x0008 08 a5 ae 57 9d 1f c5 d8 0x0008 08 a5 ae 57 9d 1f c5 d8
0x0010 2b ff 69 22 4f 91 99 93 0x0010 2b ff 69 22 4f 91 99 93
0x0018 b3 50 6f a3 b5 9a 6a 73 0x0018 b3 50 6f a3 b5 9a 6a 73
0x0020 cf f8 c5 ef c5 f4 1c 57 0x0020 cf f8 c5 ef c5 f4 1c 57
0x0028 fb 54 e1 c2 26 81 5d 78 0x0028 fb 54 e1 c2 26 81 5d 78
0x0030 28 f5 f9 2c 45 4e b6 5e 0x0030 28 f5 f9 2c 45 4e b6 5e
0x0038 be 00 ab 59 86 c6 8e 6e 0x0038 be 00 ab 59 86 c6 8e 6e
0x0040 7c 55 0x0040 7c 55
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 c3 packet type: SKESK 0x0000 c3 packet type: SKESK
0x0001 40 packet length 0x0001 40 packet length
0x0002 06 SKESK version 6 0x0002 06 SKESK version 6
0x0003 1e length through end of AEAD nonce 0x0003 1e length through end of AEAD nonce
0x0004 07 cipher: AES128 0x0004 07 cipher: AES128
0x0005 01 AEAD mode: EAX 0x0005 01 AEAD mode: EAX
0x0006 0b length of S2K 0x0006 0b length of S2K
0x0007 03 S2K type: iterated+salted 0x0007 03 S2K type: iterated+salted
0x0008 08 S2K hash: SHA2-256 0x0008 08 S2K hash: SHA2-256
0x0009 a5 ae 57 9d 1f c5 d8 S2K salt 0x0009 a5 ae 57 9d 1f c5 d8 S2K salt
skipping to change at line 7487 skipping to change at line 7611
0x0011 ff S2K iterations (65011712 octets) 0x0011 ff S2K iterations (65011712 octets)
0x0012 69 22 4f 91 99 93 AEAD nonce 0x0012 69 22 4f 91 99 93 AEAD nonce
0x0018 b3 50 6f a3 b5 9a 6a 73 0x0018 b3 50 6f a3 b5 9a 6a 73
0x0020 cf f8 0x0020 cf f8
0x0022 c5 ef c5 f4 1c 57 encrypted session key 0x0022 c5 ef c5 f4 1c 57 encrypted session key
0x0028 fb 54 e1 c2 26 81 5d 78 0x0028 fb 54 e1 c2 26 81 5d 78
0x0030 28 f5 0x0030 28 f5
0x0032 f9 2c 45 4e b6 5e AEAD tag 0x0032 f9 2c 45 4e b6 5e AEAD tag
0x0038 be 00 ab 59 86 c6 8e 6e 0x0038 be 00 ab 59 86 c6 8e 6e
0x0040 7c 55 0x0040 7c 55
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="starting-aead-eax-decryption-of-the-session-key">
<section anchor="starting-aead-eax-decryption-of-the-session-key"><name>Starting <name>Starting AEAD-EAX Decryption of the Session Key</name>
AEAD-EAX decryption of the session key</name> <t>The derived key is:</t>
<artwork><![CDATA[
<t>The derived key is:</t>
<figure><artwork><![CDATA[
15 49 67 e5 90 aa 1f 92 3e 1c 0a c6 4c 88 f2 3d 15 49 67 e5 90 aa 1f 92 3e 1c 0a c6 4c 88 f2 3d
]]></artwork></figure> ]]></artwork>
<t>HKDF info:</t>
<t>HKDF info:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
c3 06 07 01 c3 06 07 01
]]></artwork></figure> ]]></artwork>
<t>HKDF output:</t>
<t>HKDF output:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
2f ce 33 1f 39 dd 95 5c c4 1e 95 d8 70 c7 21 39 2f ce 33 1f 39 dd 95 5c c4 1e 95 d8 70 c7 21 39
]]></artwork></figure> ]]></artwork>
<t>Authenticated Data:</t>
<t>Authenticated Data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
c3 06 07 01 c3 06 07 01
]]></artwork></figure> ]]></artwork>
<t>Nonce:</t>
<t>Nonce:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
69 22 4f 91 99 93 b3 50 6f a3 b5 9a 6a 73 cf f8 69 22 4f 91 99 93 b3 50 6f a3 b5 9a 6a 73 cf f8
]]></artwork></figure> ]]></artwork>
<t>Decrypted session key:</t>
<t>Decrypted session key:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
38 81 ba fe 98 54 12 45 9b 86 c3 6f 98 cb 9a 5e 38 81 ba fe 98 54 12 45 9b 86 c3 6f 98 cb 9a 5e
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="sample-v2-seipd-packet-1">
<section anchor="sample-v2-seipd-packet-1"><name>Sample v2 SEIPD packet</name> <name>Sample v2 SEIPD Packet</name>
<t>This packet contains the following series of octets:</t>
<t>This packet contains the following series of octets:</t> <artwork name="v2seipd-aes128-eax.hexdump"><![CDATA[
<figure><artwork name="v2seipd-aes128-eax.hexdump"><![CDATA[
0x0000 d2 69 02 07 01 06 9f f9 0x0000 d2 69 02 07 01 06 9f f9
0x0008 0e 3b 32 19 64 f3 a4 29 0x0008 0e 3b 32 19 64 f3 a4 29
0x0010 13 c8 dc c6 61 93 25 01 0x0010 13 c8 dc c6 61 93 25 01
0x0018 52 27 ef b7 ea ea a4 9f 0x0018 52 27 ef b7 ea ea a4 9f
0x0020 04 c2 e6 74 17 5d 4a 3d 0x0020 04 c2 e6 74 17 5d 4a 3d
0x0028 22 6e d6 af cb 9c a9 ac 0x0028 22 6e d6 af cb 9c a9 ac
0x0030 12 2c 14 70 e1 1c 63 d4 0x0030 12 2c 14 70 e1 1c 63 d4
0x0038 c0 ab 24 1c 6a 93 8a d4 0x0038 c0 ab 24 1c 6a 93 8a d4
0x0040 8b f9 9a 5a 99 b9 0b ba 0x0040 8b f9 9a 5a 99 b9 0b ba
0x0048 83 25 de 61 04 75 40 25 0x0048 83 25 de 61 04 75 40 25
0x0050 8a b7 95 9a 95 ad 05 1d 0x0050 8a b7 95 9a 95 ad 05 1d
0x0058 da 96 eb 15 43 1d fe f5 0x0058 da 96 eb 15 43 1d fe f5
0x0060 f5 e2 25 5c a7 82 61 54 0x0060 f5 e2 25 5c a7 82 61 54
0x0068 6e 33 9a 0x0068 6e 33 9a
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 d2 packet type: SEIPD 0x0000 d2 packet type: SEIPD
0x0001 69 packet length 0x0001 69 packet length
0x0002 02 SEIPD version 2 0x0002 02 SEIPD version 2
0x0003 07 cipher: AES128 0x0003 07 cipher: AES128
0x0004 01 AEAD mode: EAX 0x0004 01 AEAD mode: EAX
0x0005 06 chunk size (2**12 octets) 0x0005 06 chunk size (2^12 octets)
0x0005 9f f9 salt 0x0005 9f f9 salt
0x0008 0e 3b 32 19 64 f3 a4 29 0x0008 0e 3b 32 19 64 f3 a4 29
0x0010 13 c8 dc c6 61 93 25 01 0x0010 13 c8 dc c6 61 93 25 01
0x0018 52 27 ef b7 ea ea a4 9f 0x0018 52 27 ef b7 ea ea a4 9f
0x0020 04 c2 e6 74 17 5d 0x0020 04 c2 e6 74 17 5d
0x0026 4a 3d chunk #0 encrypted data 0x0026 4a 3d chunk #0 encrypted data
0x0028 22 6e d6 af cb 9c a9 ac 0x0028 22 6e d6 af cb 9c a9 ac
0x0030 12 2c 14 70 e1 1c 63 d4 0x0030 12 2c 14 70 e1 1c 63 d4
0x0038 c0 ab 24 1c 6a 93 8a d4 0x0038 c0 ab 24 1c 6a 93 8a d4
0x0040 8b f9 9a 5a 99 b9 0b ba 0x0040 8b f9 9a 5a 99 b9 0b ba
0x0048 83 25 de 0x0048 83 25 de
0x004b 61 04 75 40 25 chunk #0 AEAD tag 0x004b 61 04 75 40 25 chunk #0 AEAD tag
0x0050 8a b7 95 9a 95 ad 05 1d 0x0050 8a b7 95 9a 95 ad 05 1d
0x0058 da 96 eb 0x0058 da 96 eb
0x005b 15 43 1d fe f5 final AEAD tag (#1) 0x005b 15 43 1d fe f5 final AEAD tag (#1)
0x0060 f5 e2 25 5c a7 82 61 54 0x0060 f5 e2 25 5c a7 82 61 54
0x0068 6e 33 9a 0x0068 6e 33 9a
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="decryption-of-data-1">
<section anchor="decryption-of-data-1"><name>Decryption of data</name> <name>Decryption of Data</name>
<t>Starting AEAD-EAX decryption of data, using the session key.</t>
<t>Starting AEAD-EAX decryption of data, using the session key.</t> <t>HKDF info:</t>
<artwork><![CDATA[
<t>HKDF info:</t>
<figure><artwork><![CDATA[
d2 02 07 01 06 d2 02 07 01 06
]]></artwork></figure> ]]></artwork>
<t>HKDF output:</t>
<t>HKDF output:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f
78 b8 33 f2 e9 4a 60 c0 78 b8 33 f2 e9 4a 60 c0
]]></artwork></figure> ]]></artwork>
<t>Message key:</t>
<t>Message key:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f b5 04 22 ac 1c 26 be 9d dd 83 1d 5b bb 36 b6 4f
]]></artwork></figure> ]]></artwork>
<t>Initialization vector:</t>
<t>Initialization vector:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
78 b8 33 f2 e9 4a 60 c0 78 b8 33 f2 e9 4a 60 c0
]]></artwork></figure> ]]></artwork>
<t>Chunk #0:</t>
<t>Chunk #0:</t> <t>Nonce:</t>
<artwork><![CDATA[
<t>Nonce:</t>
<figure><artwork><![CDATA[
78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 00 78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 00
]]></artwork></figure> ]]></artwork>
<t>Additional authenticated data:</t>
<t>Additional authenticated data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d2 02 07 01 06 d2 02 07 01 06
]]></artwork></figure> ]]></artwork>
<t>Decrypted chunk #0.</t>
<t>Decrypted chunk #0.</t> <t>Literal data packet with the string contents <tt>Hello, world!</tt>
:</t>
<t>Literal data packet with the string contents <spanx style="verb">Hello, world <artwork><![CDATA[
!</spanx>:</t>
<figure><artwork><![CDATA[
cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77 cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
6f 72 6c 64 21 6f 72 6c 64 21
]]></artwork></figure> ]]></artwork>
<t>Padding packet:</t>
<t>Padding packet:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d5 0e ae 5b f0 cd 67 05 50 03 55 81 6c b0 c8 ff 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>Authenticating final tag:</t> <t>Final nonce:</t>
<artwork><![CDATA[
<t>Final nonce:</t>
<figure><artwork><![CDATA[
78 b8 33 f2 e9 4a 60 c0 00 00 00 00 00 00 00 01 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>
<t>Final additional authenticated data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d2 02 07 01 06 00 00 00 00 00 00 00 25 d2 02 07 01 06 00 00 00 00 00 00 00 25
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="complete-aead-eax-encrypted-packet-sequence">
<section anchor="complete-aead-eax-encrypted-packet-sequence"><name>Complete AEA <name>Complete AEAD-EAX Encrypted Packet Sequence</name>
D-EAX encrypted packet sequence</name> <sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-eax.
pgp"><![CDATA[
<figure><sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-eax.pg
p"><![CDATA[
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
w0AGHgcBCwMIpa5XnR/F2Cv/aSJPkZmTs1Bvo7WaanPP+MXvxfQcV/tU4cImgV14 w0AGHgcBCwMIpa5XnR/F2Cv/aSJPkZmTs1Bvo7WaanPP+MXvxfQcV/tU4cImgV14
KPX5LEVOtl6+AKtZhsaObnxV0mkCBwEGn/kOOzIZZPOkKRPI3MZhkyUBUifvt+rq KPX5LEVOtl6+AKtZhsaObnxV0mkCBwEGn/kOOzIZZPOkKRPI3MZhkyUBUifvt+rq
pJ8EwuZ0F11KPSJu1q/LnKmsEiwUcOEcY9TAqyQcapOK1Iv5mlqZuQu6gyXeYQR1 pJ8EwuZ0F11KPSJu1q/LnKmsEiwUcOEcY9TAqyQcapOK1Iv5mlqZuQu6gyXeYQR1
QCWKt5Wala0FHdqW6xVDHf719eIlXKeCYVRuM5o= QCWKt5Wala0FHdqW6xVDHf719eIlXKeCYVRuM5o=
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="sample-aead-ocb-encryption-and-decryption">
<section anchor="sample-aead-ocb-encryption-and-decryption"><name>Sample AEAD-OC <name>Sample AEAD-OCB Encryption and Decryption</name>
B encryption and decryption</name> <t>This example encrypts the cleartext string <tt>Hello, world!</tt> wit
h the passphrase <tt>password</tt>, using AES-128 with AEAD-OCB encryption.</t>
<t>This example encrypts the cleartext string <spanx style="verb">Hello, world!< <section anchor="sample-symmetric-key-encrypted-session-key-packet-v6-1"
/spanx> with the passphrase <spanx style="verb">password</spanx>, using AES-128 >
with AEAD-OCB encryption.</t> <name>Sample Symmetric-Key Encrypted Session Key Packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<section anchor="sample-symmetric-key-encrypted-session-key-packet-v6-1"><name>S <artwork name="v6skesk-aes128-ocb.hexdump"><![CDATA[
ample symmetric-key encrypted session key packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork name="v6skesk-aes128-ocb.hexdump"><![CDATA[
0x0000 c3 3f 06 1d 07 02 0b 03 0x0000 c3 3f 06 1d 07 02 0b 03
0x0008 08 56 a2 98 d2 f5 e3 64 0x0008 08 56 a2 98 d2 f5 e3 64
0x0010 53 ff cf cc 5c 11 66 4e 0x0010 53 ff cf cc 5c 11 66 4e
0x0018 db 9d b4 25 90 d7 dc 46 0x0018 db 9d b4 25 90 d7 dc 46
0x0020 b0 72 41 b6 12 c3 81 2c 0x0020 b0 72 41 b6 12 c3 81 2c
0x0028 ff fb ea 00 f2 34 7b 25 0x0028 ff fb ea 00 f2 34 7b 25
0x0030 64 11 23 f8 87 ae 60 d4 0x0030 64 11 23 f8 87 ae 60 d4
0x0038 fd 61 4e 08 37 d8 19 d3 0x0038 fd 61 4e 08 37 d8 19 d3
0x0040 6c 0x0040 6c
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 c3 packet type: SKESK 0x0000 c3 packet type: SKESK
0x0001 3f packet length 0x0001 3f packet length
0x0002 06 SKESK version 6 0x0002 06 SKESK version 6
0x0003 1d length through end of AEAD nonce 0x0003 1d length through end of AEAD nonce
0x0004 07 cipher: AES128 0x0004 07 cipher: AES128
0x0005 02 AEAD mode: OCB 0x0005 02 AEAD mode: OCB
0x0006 0b length of S2K 0x0006 0b length of S2K
0x0007 03 S2K type: iterated+salted 0x0007 03 S2K type: iterated+salted
0x0008 08 S2K hash: SHA2-256 0x0008 08 S2K hash: SHA2-256
0x0009 56 a2 98 d2 f5 e3 64 S2K salt 0x0009 56 a2 98 d2 f5 e3 64 S2K salt
skipping to change at line 7710 skipping to change at line 7788
0x0011 ff S2K iterations (65011712 octets) 0x0011 ff S2K iterations (65011712 octets)
0x0012 cf cc 5c 11 66 4e AEAD nonce 0x0012 cf cc 5c 11 66 4e AEAD nonce
0x0018 db 9d b4 25 90 d7 dc 46 0x0018 db 9d b4 25 90 d7 dc 46
0x0020 b0 0x0020 b0
0x0021 72 41 b6 12 c3 81 2c encrypted session key 0x0021 72 41 b6 12 c3 81 2c encrypted session key
0x0028 ff fb ea 00 f2 34 7b 25 0x0028 ff fb ea 00 f2 34 7b 25
0x0030 64 0x0030 64
0x0031 11 23 f8 87 ae 60 d4 AEAD tag 0x0031 11 23 f8 87 ae 60 d4 AEAD tag
0x0038 fd 61 4e 08 37 d8 19 d3 0x0038 fd 61 4e 08 37 d8 19 d3
0x0040 6c 0x0040 6c
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="starting-aead-ocb-decryption-of-the-session-key">
<section anchor="starting-aead-ocb-decryption-of-the-session-key"><name>Starting <name>Starting AEAD-OCB Decryption of the Session Key</name>
AEAD-OCB decryption of the session key</name> <t>The derived key is:</t>
<artwork><![CDATA[
<t>The derived key is:</t>
<figure><artwork><![CDATA[
e8 0d e2 43 a3 62 d9 3b 9d c6 07 ed e9 6a 73 56 e8 0d e2 43 a3 62 d9 3b 9d c6 07 ed e9 6a 73 56
]]></artwork></figure> ]]></artwork>
<t>HKDF info:</t>
<t>HKDF info:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
c3 06 07 02 c3 06 07 02
]]></artwork></figure> ]]></artwork>
<t>HKDF output:</t>
<t>HKDF output:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
38 a9 b3 45 b5 68 0b b6 1b b6 5d 73 ee c7 ec d9 38 a9 b3 45 b5 68 0b b6 1b b6 5d 73 ee c7 ec d9
]]></artwork></figure> ]]></artwork>
<t>Authenticated Data:</t>
<t>Authenticated Data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
c3 06 07 02 c3 06 07 02
]]></artwork></figure> ]]></artwork>
<t>Nonce:</t>
<t>Nonce:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
cf cc 5c 11 66 4e db 9d b4 25 90 d7 dc 46 b0 cf cc 5c 11 66 4e db 9d b4 25 90 d7 dc 46 b0
]]></artwork></figure> ]]></artwork>
<t>Decrypted session key:</t>
<t>Decrypted session key:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
28 e7 9a b8 23 97 d3 c6 3d e2 4a c2 17 d7 b7 91 28 e7 9a b8 23 97 d3 c6 3d e2 4a c2 17 d7 b7 91
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="sample-v2-seipd-packet-2">
<section anchor="sample-v2-seipd-packet-2"><name>Sample v2 SEIPD packet</name> <name>Sample v2 SEIPD Packet</name>
<t>This packet contains the following series of octets:</t>
<t>This packet contains the following series of octets:</t> <artwork name="v2seipd-aes128-ocb.hexdump"><![CDATA[
<figure><artwork name="v2seipd-aes128-ocb.hexdump"><![CDATA[
0x0000 d2 69 02 07 02 06 20 a6 0x0000 d2 69 02 07 02 06 20 a6
0x0008 61 f7 31 fc 9a 30 32 b5 0x0008 61 f7 31 fc 9a 30 32 b5
0x0010 62 33 26 02 7e 3a 5d 8d 0x0010 62 33 26 02 7e 3a 5d 8d
0x0018 b5 74 8e be ff 0b 0c 59 0x0018 b5 74 8e be ff 0b 0c 59
0x0020 10 d0 9e cd d6 41 ff 9f 0x0020 10 d0 9e cd d6 41 ff 9f
0x0028 d3 85 62 75 80 35 bc 49 0x0028 d3 85 62 75 80 35 bc 49
0x0030 75 4c e1 bf 3f ff a7 da 0x0030 75 4c e1 bf 3f ff a7 da
0x0038 d0 a3 b8 10 4f 51 33 cf 0x0038 d0 a3 b8 10 4f 51 33 cf
0x0040 42 a4 10 0a 83 ee f4 ca 0x0040 42 a4 10 0a 83 ee f4 ca
0x0048 1b 48 01 a8 84 6b f4 2b 0x0048 1b 48 01 a8 84 6b f4 2b
0x0050 cd a7 c8 ce 9d 65 e2 12 0x0050 cd a7 c8 ce 9d 65 e2 12
0x0058 f3 01 cb cd 98 fd ca de 0x0058 f3 01 cb cd 98 fd ca de
0x0060 69 4a 87 7a d4 24 73 23 0x0060 69 4a 87 7a d4 24 73 23
0x0068 f6 e8 57 0x0068 f6 e8 57
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 d2 packet type: SEIPD 0x0000 d2 packet type: SEIPD
0x0001 69 packet length 0x0001 69 packet length
0x0002 02 SEIPD version 2 0x0002 02 SEIPD version 2
0x0003 07 cipher: AES128 0x0003 07 cipher: AES128
0x0004 02 AEAD mode: OCB 0x0004 02 AEAD mode: OCB
0x0005 06 chunk size (2**21 octets) 0x0005 06 chunk size (2^12 octets)
0x0006 20 a6 salt 0x0006 20 a6 salt
0x0008 61 f7 31 fc 9a 30 32 b5 0x0008 61 f7 31 fc 9a 30 32 b5
0x0010 62 33 26 02 7e 3a 5d 8d 0x0010 62 33 26 02 7e 3a 5d 8d
0x0018 b5 74 8e be ff 0b 0c 59 0x0018 b5 74 8e be ff 0b 0c 59
0x0020 10 d0 9e cd d6 41 0x0020 10 d0 9e cd d6 41
0x0026 ff 9f chunk #0 encrypted data 0x0026 ff 9f chunk #0 encrypted data
0x0028 d3 85 62 75 80 35 bc 49 0x0028 d3 85 62 75 80 35 bc 49
0x0030 75 4c e1 bf 3f ff a7 da 0x0030 75 4c e1 bf 3f ff a7 da
0x0038 d0 a3 b8 10 4f 51 33 cf 0x0038 d0 a3 b8 10 4f 51 33 cf
0x0040 42 a4 10 0a 83 ee f4 ca 0x0040 42 a4 10 0a 83 ee f4 ca
0x0048 1b 48 01 0x0048 1b 48 01
0x004b a8 84 6b f4 2b chunk #0 authentication tag 0x004b a8 84 6b f4 2b chunk #0 authentication tag
0x0050 cd a7 c8 ce 9d 65 e2 12 0x0050 cd a7 c8 ce 9d 65 e2 12
0x0058 f3 01 cb 0x0058 f3 01 cb
0x005b cd 98 fd ca de final AEAD tag (#1) 0x005b cd 98 fd ca de final AEAD tag (#1)
0x0060 69 4a 87 7a d4 24 73 23 0x0060 69 4a 87 7a d4 24 73 23
0x0068 f6 e8 57 0x0068 f6 e8 57
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="decryption-of-data-2">
<section anchor="decryption-of-data-2"><name>Decryption of data</name> <name>Decryption of Data</name>
<t>Starting AEAD-OCB decryption of data, using the session key.</t>
<t>Starting AEAD-OCB decryption of data, using the session key.</t> <t>HKDF info:</t>
<artwork><![CDATA[
<t>HKDF info:</t>
<figure><artwork><![CDATA[
d2 02 07 02 06 d2 02 07 02 06
]]></artwork></figure> ]]></artwork>
<t>HKDF output:</t>
<t>HKDF output:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99 71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99
eb de 12 bb 57 0d cf eb de 12 bb 57 0d cf
]]></artwork></figure> ]]></artwork>
<t>Message key:</t>
<t>Message key:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99 71 66 2a 11 ee 5b 4e 08 14 4e 6d e8 83 a0 09 99
]]></artwork></figure> ]]></artwork>
<t>Initialization vector:</t>
<t>Initialization vector:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
eb de 12 bb 57 0d cf eb de 12 bb 57 0d cf
]]></artwork></figure> ]]></artwork>
<t>Chunk #0:</t>
<t>Chunk #0:</t> <t>Nonce:</t>
<artwork><![CDATA[
<t>Nonce:</t>
<figure><artwork><![CDATA[
eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 00 eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 00
]]></artwork></figure> ]]></artwork>
<t>Additional authenticated data:</t>
<t>Additional authenticated data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d2 02 07 02 06 d2 02 07 02 06
]]></artwork></figure> ]]></artwork>
<t>Decrypted chunk #0.</t>
<t>Decrypted chunk #0.</t> <t>Literal data packet with the string contents <tt>Hello, world!</tt>
:</t>
<t>Literal data packet with the string contents <spanx style="verb">Hello, world <artwork><![CDATA[
!</spanx>:</t>
<figure><artwork><![CDATA[
cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77 cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
6f 72 6c 64 21 6f 72 6c 64 21
]]></artwork></figure> ]]></artwork>
<t>Padding packet:</t>
<t>Padding packet:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d5 0e ae 6a a1 64 9b 56 aa 83 5b 26 13 90 2b d2 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>Authenticating final tag:</t> <t>Final nonce:</t>
<artwork><![CDATA[
<t>Final nonce:</t>
<figure><artwork><![CDATA[
eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 01 eb de 12 bb 57 0d cf 00 00 00 00 00 00 00 01
]]></artwork></figure> ]]></artwork>
<t>Final additional authenticated data:</t>
<t>Final additional authenticated data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d2 02 07 02 06 00 00 00 00 00 00 00 25 d2 02 07 02 06 00 00 00 00 00 00 00 25
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="complete-aead-ocb-encrypted-packet-sequence">
<section anchor="complete-aead-ocb-encrypted-packet-sequence"><name>Complete AEA <name>Complete AEAD-OCB Encrypted Packet Sequence</name>
D-OCB encrypted packet sequence</name> <sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-ocb.
pgp"><![CDATA[
<figure><sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-ocb.pg
p"><![CDATA[
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
wz8GHQcCCwMIVqKY0vXjZFP/z8xcEWZO2520JZDX3EawckG2EsOBLP/76gDyNHsl wz8GHQcCCwMIVqKY0vXjZFP/z8xcEWZO2520JZDX3EawckG2EsOBLP/76gDyNHsl
ZBEj+IeuYNT9YU4IN9gZ02zSaQIHAgYgpmH3MfyaMDK1YjMmAn46XY21dI6+/wsM ZBEj+IeuYNT9YU4IN9gZ02zSaQIHAgYgpmH3MfyaMDK1YjMmAn46XY21dI6+/wsM
WRDQns3WQf+f04VidYA1vEl1TOG/P/+n2tCjuBBPUTPPQqQQCoPu9MobSAGohGv0 WRDQns3WQf+f04VidYA1vEl1TOG/P/+n2tCjuBBPUTPPQqQQCoPu9MobSAGohGv0
K82nyM6dZeIS8wHLzZj9yt5pSod61CRzI/boVw== K82nyM6dZeIS8wHLzZj9yt5pSod61CRzI/boVw==
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="sample-aead-gcm-encryption-and-decryption">
<section anchor="sample-aead-gcm-encryption-and-decryption"><name>Sample AEAD-GC <name>Sample AEAD-GCM Encryption and Decryption</name>
M encryption and decryption</name> <t>This example encrypts the cleartext string <tt>Hello, world!</tt> wit
h the passphrase <tt>password</tt>, using AES-128 with AEAD-GCM encryption.</t>
<t>This example encrypts the cleartext string <spanx style="verb">Hello, world!< <section anchor="sample-symmetric-key-encrypted-session-key-packet-v6-2"
/spanx> with the passphrase <spanx style="verb">password</spanx>, using AES-128 >
with AEAD-GCM encryption.</t> <name>Sample Symmetric-Key Encrypted Session Key Packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<section anchor="sample-symmetric-key-encrypted-session-key-packet-v6-2"><name>S <artwork name="v6skesk-aes128-gcm.hexdump"><![CDATA[
ample symmetric-key encrypted session key packet (v6)</name>
<t>This packet contains the following series of octets:</t>
<figure><artwork name="v6skesk-aes128-gcm.hexdump"><![CDATA[
0x0000 c3 3c 06 1a 07 03 0b 03 0x0000 c3 3c 06 1a 07 03 0b 03
0x0008 08 e9 d3 97 85 b2 07 00 0x0008 08 e9 d3 97 85 b2 07 00
0x0010 08 ff b4 2e 7c 48 3e f4 0x0010 08 ff b4 2e 7c 48 3e f4
0x0018 88 44 57 cb 37 26 b9 b3 0x0018 88 44 57 cb 37 26 b9 b3
0x0020 db 9f f7 76 e5 f4 d9 a4 0x0020 db 9f f7 76 e5 f4 d9 a4
0x0028 09 52 e2 44 72 98 85 1a 0x0028 09 52 e2 44 72 98 85 1a
0x0030 bf ff 75 26 df 2d d5 54 0x0030 bf ff 75 26 df 2d d5 54
0x0038 41 75 79 a7 79 9f 0x0038 41 75 79 a7 79 9f
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 c3 packet type: SKESK 0x0000 c3 packet type: SKESK
0x0001 3c packet length 0x0001 3c packet length
0x0002 06 SKESK version 6 0x0002 06 SKESK version 6
0x0003 1a length through end of AEAD nonce 0x0003 1a length through end of AEAD nonce
0x0004 07 cipher: AES128 0x0004 07 cipher: AES128
0x0005 03 AEAD mode: GCM 0x0005 03 AEAD mode: GCM
0x0006 0b length of S2K 0x0006 0b length of S2K
0x0007 03 S2K type: iterated+salted 0x0007 03 S2K type: iterated+salted
0x0008 08 S2K hash: SHA2-256 0x0008 08 S2K hash: SHA2-256
0x0009 e9 d3 97 85 b2 07 00 S2K salt 0x0009 e9 d3 97 85 b2 07 00 S2K salt
0x0010 08 0x0010 08
0x0011 ff S2K iterations (65011712 octets) 0x0011 ff S2K iterations (65011712 octets)
0x0012 b4 2e 7c 48 3e f4 AEAD nonce 0x0012 b4 2e 7c 48 3e f4 AEAD nonce
0x0018 88 44 57 cb 37 26 0x0018 88 44 57 cb 37 26
0x001e b9 b3 encrypted session key 0x001e b9 b3 encrypted session key
0x0020 db 9f f7 76 e5 f4 d9 a4 0x0020 db 9f f7 76 e5 f4 d9 a4
0x0028 09 52 e2 44 72 98 0x0028 09 52 e2 44 72 98
0x002e 85 1a AEAD tag 0x002e 85 1a AEAD tag
0x0030 bf ff 75 26 df 2d d5 54 0x0030 bf ff 75 26 df 2d d5 54
0x0038 41 75 79 a7 79 9f 0x0038 41 75 79 a7 79 9f
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="starting-aead-gcm-decryption-of-the-session-key">
<section anchor="starting-aead-gcm-decryption-of-the-session-key"><name>Starting <name>Starting AEAD-GCM Decryption of the Session Key</name>
AEAD-GCM decryption of the session key</name> <t>The derived key is:</t>
<artwork><![CDATA[
<t>The derived key is:</t>
<figure><artwork><![CDATA[
25 02 81 71 5b ba 78 28 ef 71 ef 64 c4 78 47 53 25 02 81 71 5b ba 78 28 ef 71 ef 64 c4 78 47 53
]]></artwork></figure> ]]></artwork>
<t>HKDF info:</t>
<t>HKDF info:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
c3 06 07 03 c3 06 07 03
]]></artwork></figure> ]]></artwork>
<t>HKDF output:</t>
<t>HKDF output:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
7a 6f 9a b7 f9 9f 7e f8 db ef 84 1c 65 08 00 f5 7a 6f 9a b7 f9 9f 7e f8 db ef 84 1c 65 08 00 f5
]]></artwork></figure> ]]></artwork>
<t>Authenticated Data:</t>
<t>Authenticated Data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
c3 06 07 03 c3 06 07 03
]]></artwork></figure> ]]></artwork>
<t>Nonce:</t>
<t>Nonce:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
b4 2e 7c 48 3e f4 88 44 57 cb 37 26 b4 2e 7c 48 3e f4 88 44 57 cb 37 26
]]></artwork></figure> ]]></artwork>
<t>Decrypted session key:</t>
<t>Decrypted session key:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
19 36 fc 85 68 98 02 74 bb 90 0d 83 19 36 0c 77 19 36 fc 85 68 98 02 74 bb 90 0d 83 19 36 0c 77
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="sample-v2-seipd-packet-3">
<section anchor="sample-v2-seipd-packet-3"><name>Sample v2 SEIPD packet</name> <name>Sample v2 SEIPD Packet</name>
<t>This packet contains the following series of octets, is:</t>
<t>This packet contains the following series of octets:</t> <artwork name="v2seipd-aes128-ocb.hexdump"><![CDATA[
<figure><artwork name="v2seipd-aes128-ocb.hexdump"><![CDATA[
0x0000 d2 69 02 07 03 06 fc b9 0x0000 d2 69 02 07 03 06 fc b9
0x0008 44 90 bc b9 8b bd c9 d1 0x0008 44 90 bc b9 8b bd c9 d1
0x0010 06 c6 09 02 66 94 0f 72 0x0010 06 c6 09 02 66 94 0f 72
0x0018 e8 9e dc 21 b5 59 6b 15 0x0018 e8 9e dc 21 b5 59 6b 15
0x0020 76 b1 01 ed 0f 9f fc 6f 0x0020 76 b1 01 ed 0f 9f fc 6f
0x0028 c6 d6 5b bf d2 4d cd 07 0x0028 c6 d6 5b bf d2 4d cd 07
0x0030 90 96 6e 6d 1e 85 a3 00 0x0030 90 96 6e 6d 1e 85 a3 00
0x0038 53 78 4c b1 d8 b6 a0 69 0x0038 53 78 4c b1 d8 b6 a0 69
0x0040 9e f1 21 55 a7 b2 ad 62 0x0040 9e f1 21 55 a7 b2 ad 62
0x0048 58 53 1b 57 65 1f d7 77 0x0048 58 53 1b 57 65 1f d7 77
0x0050 79 12 fa 95 e3 5d 9b 40 0x0050 79 12 fa 95 e3 5d 9b 40
0x0058 21 6f 69 a4 c2 48 db 28 0x0058 21 6f 69 a4 c2 48 db 28
0x0060 ff 43 31 f1 63 29 07 39 0x0060 ff 43 31 f1 63 29 07 39
0x0068 9e 6f f9 0x0068 9e 6f f9
]]></artwork></figure> ]]></artwork>
<t>The same data, broken out by octet and semantics, is:</t>
<t>The same data, broken out by octet and semantics:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
0x0000 d2 packet type: SEIPD 0x0000 d2 packet type: SEIPD
0x0001 69 packet length 0x0001 69 packet length
0x0002 02 SEIPD version 2 0x0002 02 SEIPD version 2
0x0003 07 cipher: AES128 0x0003 07 cipher: AES128
0x0004 03 AEAD mode: GCM 0x0004 03 AEAD mode: GCM
0x0005 06 chunk size (2**21 octets) 0x0005 06 chunk size (2^12 octets)
0x0006 fc b9 salt 0x0006 fc b9 salt
0x0008 44 90 bc b9 8b bd c9 d1 0x0008 44 90 bc b9 8b bd c9 d1
0x0010 06 c6 09 02 66 94 0f 72 0x0010 06 c6 09 02 66 94 0f 72
0x0018 e8 9e dc 21 b5 59 6b 15 0x0018 e8 9e dc 21 b5 59 6b 15
0x0020 76 b1 01 ed 0f 9f 0x0020 76 b1 01 ed 0f 9f
0x0026 fc 6f chunk #0 encrypted data 0x0026 fc 6f chunk #0 encrypted data
0x0028 c6 d6 5b bf d2 4d cd 07 0x0028 c6 d6 5b bf d2 4d cd 07
0x0030 90 96 6e 6d 1e 85 a3 00 0x0030 90 96 6e 6d 1e 85 a3 00
0x0038 53 78 4c b1 d8 b6 a0 69 0x0038 53 78 4c b1 d8 b6 a0 69
0x0040 9e f1 21 55 a7 b2 ad 62 0x0040 9e f1 21 55 a7 b2 ad 62
0x0048 58 53 1b 0x0048 58 53 1b
0x004b 57 65 1f d7 77 chunk #0 authentication tag 0x004b 57 65 1f d7 77 chunk #0 authentication tag
0x0050 79 12 fa 95 e3 5d 9b 40 0x0050 79 12 fa 95 e3 5d 9b 40
0x0058 21 6f 69 0x0058 21 6f 69
0x005b a4 c2 48 db 28 final AEAD tag (#1) 0x005b a4 c2 48 db 28 final AEAD tag (#1)
0x0060 ff 43 31 f1 63 29 07 39 0x0060 ff 43 31 f1 63 29 07 39
0x0068 9e 6f f9 0x0068 9e 6f f9
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="decryption-of-data-3">
<section anchor="decryption-of-data-3"><name>Decryption of data</name> <name>Decryption of Data</name>
<t>Starting AEAD-GCM decryption of data, using the session key.</t>
<t>Starting AEAD-GCM decryption of data, using the session key.</t> <t>HKDF info:</t>
<artwork><![CDATA[
<t>HKDF info:</t>
<figure><artwork><![CDATA[
d2 02 07 03 06 d2 02 07 03 06
]]></artwork></figure> ]]></artwork>
<t>HKDF output:</t>
<t>HKDF output:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d
4d 2b dc 2b 4d 2b dc 2b
]]></artwork></figure> ]]></artwork>
<t>Message key:</t>
<t>Message key:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d ea 14 38 80 3c b8 a4 77 40 ce 9b 54 c3 38 77 8d
]]></artwork></figure> ]]></artwork>
<t>Initialization vector:</t>
<t>Initialization vector:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
4d 2b dc 2b 4d 2b dc 2b
]]></artwork></figure> ]]></artwork>
<t>Chunk #0:</t>
<t>Chunk #0:</t> <t>Nonce:</t>
<artwork><![CDATA[
<t>Nonce:</t>
<figure><artwork><![CDATA[
4d 2b dc 2b 00 00 00 00 00 00 00 00 4d 2b dc 2b 00 00 00 00 00 00 00 00
]]></artwork></figure> ]]></artwork>
<t>Additional authenticated data:</t>
<t>Additional authenticated data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d2 02 07 03 06 d2 02 07 03 06
]]></artwork></figure> ]]></artwork>
<t>Decrypted chunk #0.</t>
<t>Decrypted chunk #0.</t> <t>Literal data packet with the string contents <tt>Hello, world!</tt>
:</t>
<t>Literal data packet with the string contents <spanx style="verb">Hello, world <artwork><![CDATA[
!</spanx>:</t>
<figure><artwork><![CDATA[
cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77 cb 13 62 00 00 00 00 00 48 65 6c 6c 6f 2c 20 77
6f 72 6c 64 21 6f 72 6c 64 21
]]></artwork></figure> ]]></artwork>
<t>Padding packet:</t>
<t>Padding packet:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d5 0e 1c e2 26 9a 9e dd ef 81 03 21 72 b7 ed 7c 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>Authenticating final tag:</t> <t>Final nonce:</t>
<artwork><![CDATA[
<t>Final nonce:</t>
<figure><artwork><![CDATA[
4d 2b dc 2b 00 00 00 00 00 00 00 01 4d 2b dc 2b 00 00 00 00 00 00 00 01
]]></artwork></figure> ]]></artwork>
<t>Final additional authenticated data:</t>
<t>Final additional authenticated data:</t> <artwork><![CDATA[
<figure><artwork><![CDATA[
d2 02 07 03 06 00 00 00 00 00 00 00 25 d2 02 07 03 06 00 00 00 00 00 00 00 25
]]></artwork></figure> ]]></artwork>
</section>
</section> <section anchor="complete-aead-gcm-encrypted-packet-sequence">
<section anchor="complete-aead-gcm-encrypted-packet-sequence"><name>Complete AEA <name>Complete AEAD-GCM Encrypted Packet Sequence</name>
D-GCM encrypted packet sequence</name> <sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-gcm.
pgp"><![CDATA[
<figure><sourcecode type="application/pgp-encrypted" name="v6skesk-aes128-gcm.pg
p"><![CDATA[
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
wzwGGgcDCwMI6dOXhbIHAAj/tC58SD70iERXyzcmubPbn/d25fTZpAlS4kRymIUa wzwGGgcDCwMI6dOXhbIHAAj/tC58SD70iERXyzcmubPbn/d25fTZpAlS4kRymIUa
v/91Jt8t1VRBdXmneZ/SaQIHAwb8uUSQvLmLvcnRBsYJAmaUD3LontwhtVlrFXax v/91Jt8t1VRBdXmneZ/SaQIHAwb8uUSQvLmLvcnRBsYJAmaUD3LontwhtVlrFXax
Ae0Pn/xvxtZbv9JNzQeQlm5tHoWjAFN4TLHYtqBpnvEhVaeyrWJYUxtXZR/Xd3kS Ae0Pn/xvxtZbv9JNzQeQlm5tHoWjAFN4TLHYtqBpnvEhVaeyrWJYUxtXZR/Xd3kS
+pXjXZtAIW9ppMJI2yj/QzHxYykHOZ5v+Q== +pXjXZtAIW9ppMJI2yj/QzHxYykHOZ5v+Q==
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> </section>
</section> <section anchor="sample-messages-encrypted-using-argon2">
<section anchor="sample-messages-encrypted-using-argon2"><name>Sample messages e <name>Sample Messages Encrypted Using Argon2</name>
ncrypted using Argon2</name> <t>These messages are the literal data <tt>Hello, world!</tt> encrypted
using v1 SEIPD, with Argon2 and the passphrase "password", using different sessi
<t>These messages are the literal data "Hello, world!" encrypted using v1 SEIPD, on key sizes.
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 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> 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">
<section anchor="version-4-skesk-using-argon2-with-aes-128"><name>Version 4 SKES <name>Version 4 SKESK Using Argon2 with AES-128</name>
K using Argon2 with AES-128</name> <sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes1
28.pgp"><![CDATA[
<figure><sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes128
.pgp"><![CDATA[
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 128-bit key Comment: Encrypted using AES with 128-bit key
Comment: Session key: 01FE16BBACFD1E7B78EF3B865187374F Comment: Session key: 01FE16BBACFD1E7B78EF3B865187374F
wycEBwScUvg8J/leUNU1RA7N/zE2AQQVnlL8rSLPP5VlQsunlO+ECxHSPgGYGKY+ wycEBwScUvg8J/leUNU1RA7N/zE2AQQVnlL8rSLPP5VlQsunlO+ECxHSPgGYGKY+
YJz4u6F+DDlDBOr5NRQXt/KJIf4m4mOlKyC/uqLbpnLJZMnTq3o79GxBTdIdOzhH YJz4u6F+DDlDBOr5NRQXt/KJIf4m4mOlKyC/uqLbpnLJZMnTq3o79GxBTdIdOzhH
XfA3pqV4mTzF XfA3pqV4mTzF
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> <section anchor="version-4-skesk-using-argon2-with-aes-192">
<section anchor="version-4-skesk-using-argon2-with-aes-192"><name>Version 4 SKES <name>Version 4 SKESK Using Argon2 with AES-192</name>
K using Argon2 with AES-192</name> <sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes1
92.pgp"><![CDATA[
<figure><sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes192
.pgp"><![CDATA[
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 192-bit key Comment: Encrypted using AES with 192-bit key
Comment: Session key: 27006DAE68E509022CE45A14E569E91001C2955... Comment: Session key: 27006DAE68E509022CE45A14E569E91001C2955...
Comment: Session key: ...AF8DFE194 Comment: Session key: ...AF8DFE194
wy8ECAThTKxHFTRZGKli3KNH4UP4AQQVhzLJ2va3FG8/pmpIPd/H/mdoVS5VBLLw wy8ECAThTKxHFTRZGKli3KNH4UP4AQQVhzLJ2va3FG8/pmpIPd/H/mdoVS5VBLLw
F9I+AdJ1Sw56PRYiKZjCvHg+2bnq02s33AJJoyBexBI4QKATFRkyez2gldJldRys F9I+AdJ1Sw56PRYiKZjCvHg+2bnq02s33AJJoyBexBI4QKATFRkyez2gldJldRys
LVg77Mwwfgl2n/d572WciAM= LVg77Mwwfgl2n/d572WciAM=
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section> <section anchor="version-4-skesk-using-argon2-with-aes-256">
<section anchor="version-4-skesk-using-argon2-with-aes-256"><name>Version 4 SKES <name>Version 4 SKESK Using Argon2 with AES-256</name>
K using Argon2 with AES-256</name> <sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes2
56.pgp"><![CDATA[
<figure><sourcecode type="application/pgp-encrypted" name="v4skesk-argon2-aes256
.pgp"><![CDATA[
-----BEGIN PGP MESSAGE----- -----BEGIN PGP MESSAGE-----
Comment: Encrypted using AES with 256-bit key Comment: Encrypted using AES with 256-bit key
Comment: Session key: BBEDA55B9AAE63DAC45D4F49D89DACF4AF37FEF... Comment: Session key: BBEDA55B9AAE63DAC45D4F49D89DACF4AF37FEF...
Comment: Session key: ...C13BAB2F1F8E18FB74580D8B0 Comment: Session key: ...C13BAB2F1F8E18FB74580D8B0
wzcECQS4eJUgIG/3mcaILEJFpmJ8AQQVnZ9l7KtagdClm9UaQ/Z6M/5roklSGpGu wzcECQS4eJUgIG/3mcaILEJFpmJ8AQQVnZ9l7KtagdClm9UaQ/Z6M/5roklSGpGu
623YmaXezGj80j4B+Ku1sgTdJo87X1Wrup7l0wJypZls21Uwd67m9koF60eefH/K 623YmaXezGj80j4B+Ku1sgTdJo87X1Wrup7l0wJypZls21Uwd67m9koF60eefH/K
95D1usliXOEm8ayQJQmZrjf6K6v9PWwqMQ== 95D1usliXOEm8ayQJQmZrjf6K6v9PWwqMQ==
-----END PGP MESSAGE----- -----END PGP MESSAGE-----
]]></sourcecode></figure> ]]></sourcecode>
</section>
</section>
</section>
<section anchor="upgrade-guidance">
<name>Upgrade Guidance (Adapting Implementations from RFCs 4880 and 6637)<
/name>
<t>This subsection offers a concise, non-normative summary of the substant
ial additions to and departures from <xref target="RFC4880"/> and <xref target="
RFC6637"/>.
It is intended to help implementers who are augmenting an existing implementatio
n from those specifications to comply with this specification. Cryptographic alg
orithms marked with "MTI" are mandatory to implement.</t>
<ul spacing="normal">
<li>
<t>Public Key Signing Algorithms:
</t>
<ul spacing="normal">
<li>
<t>Ed25519 (Sections <xref target="key-ed25519" format="counter"/>
and <xref target="sig-ed25519" format="counter"/>) -- MTI</t>
</li>
<li>
<t>Ed448 (Sections <xref target="key-ed448" format="counter"/> and
<xref target="sig-ed448" format="counter"/>)</t>
</li>
<li>
<t>EdDSALegacy with Ed25519Legacy (Sections <xref target="key-edds
a-legacy" format="counter"/> and <xref target="sig-eddsa-legacy" format="counter
"/>)</t>
</li>
<li>
<t>ECDSA with Brainpool curves (<xref target="ec-curves"/>)</t>
</li>
</ul>
</li>
<li>
<t>Public Key Encryption Algorithms:
</t>
<ul spacing="normal">
<li>
<t>X25519 (Sections <xref target="key-x25519" format="counter"/> a
nd <xref target="pkesk-x25519" format="counter"/>) -- MTI</t>
</li>
<li>
<t>X448 (Sections <xref target="key-x448" format="counter"/> and <
xref 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>
</li>
</ul>
</li>
<li>
<t>AEAD Encryption:
</t>
<ul spacing="normal">
<li>
<t>Version 2 SEIPD (<xref target="version-two-seipd"/>)</t>
</li>
<li>
<t>AEAD modes:
</t>
<ul spacing="normal">
<li>
<t>OCB mode (<xref 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>
</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="feature
s-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" (Sections <xref t
arget="s2k-usage-octet" format="counter"/> and <xref target="secret-key-packet-f
ormats" format="counter"/>)</t>
</li>
</ul>
</li>
<li>
<t>Version 6 Keys and Signatures:
</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-finge
rprint"/>)</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>
</li>
</ul>
</li>
<li>
<t>Certificate (Transferable Public Key) Structure:
</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-revocat
ion-certificate"/>)</t>
</li>
<li>
<t>User ID is explicitly optional (<xref target="v6-certificate-st
ructures"/>)</t>
</li>
</ul>
</li>
<li>
<t>S2K: Argon2 (<xref target="s2k-argon2"/>)</t>
</li>
<li>
<t>Subpacket: Intended Recipient Fingerprint (<xref target="intended-r
ecipient-fingerprint"/>)</t>
</li>
<li>
<t>Digest 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: Packet Criticality (<xref target="packet-critica
lity"/>)</t>
</li>
<li>
<t>Deprecations:
</t>
<ul spacing="normal">
<li>
<t>Public Key Algorithms:
</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 (Sections <xref target="elgamal-notes" format
="counter"/> and <xref target="pkesk-elgamal" format="counter"/>)</t>
</li>
<li>
<t>For Version 6 Keys: Avoid EdDSA25519Legacy and Curve25519Le
gacy (<xref target="ec-curves"/>)</t>
</li>
</ul>
</li>
<li>
<t>Digest Algorithms:
</t>
<ul spacing="normal">
<li>
<t>Avoid MD5, SHA1, and RIPEMD160 (<xref target="hash-algos"/>
)</t>
</li>
</ul>
</li>
<li>
<t>Symmetric Key Algorithms:
</t>
<ul spacing="normal">
<li>
<t>Avoid IDEA, TripleDES, and CAST5 (<xref target="symmetric-a
lgos"/>)</t>
</li>
</ul>
</li>
<li>
<t>S2K Specifier:
</t>
<ul spacing="normal">
<li>
<t>Avoid Simple S2K (<xref target="s2k-simple"/>)</t>
</li>
</ul>
</li>
<li>
<t>Secret Key Protections (a.k.a.&nbsp;S2K Usage):
</t>
<ul spacing="normal">
<li>
<t>Avoid MalleableCFB (<xref target="secret-key-encryption"/>)
</t>
</li>
</ul>
</li>
<li>
<t>Packet Types:
</t>
<ul spacing="normal">
<li>
<t>Avoid Symmetrically Encrypted Data (Sections <xref target="
sed" format="counter"/> and <xref target="ciphertext-malleability" format="count
er"/>)</t>
</li>
</ul>
</li>
<li>
<t>Literal Data Packet Metadata:
</t>
<ul spacing="normal">
<li>
<t>Avoid Filename and Date fields (<xref target="lit"/>)</t>
</li>
<li>
<t>Avoid Special <tt>_CONSOLE</tt> "filename" (<xref target="f
or-eyes-only"/>)</t>
</li>
</ul>
</li>
<li>
<t>Packet Versions:
</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>
</li>
</ul>
</li>
<li>
<t>Signature Types:
</t>
<ul spacing="normal">
<li>
<t>Avoid Reserved Signature type ID 0xFF (Sections <xref targe
t="sigtype-reserved" format="counter"/> and <xref target="sig-computation-notes"
format="counter"/>)</t>
</li>
</ul>
</li>
<li>
<t>Signature Subpackets:
</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>
</li>
</ul>
</li>
<li>
<t>ASCII Armor:
</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-hea
der-key-version"/>)</t>
</li>
</ul>
</li>
<li>
<t>Cleartext Signature Framework:
</t>
<ul spacing="normal">
<li>
<t>Ignore; avoid emitting unnecessary Hash: headers (<xref tar
get="armor-header-key-hash"/>)</t>
</li>
<li>
<t>Reject Cleartext Signature Framework signatures with invali
d Hash: headers (<xref target="armor-header-key-hash"/>) or any other Armor Head
er (<xref target="cleartext-structure"/>)</t>
</li>
</ul>
</li>
</ul>
</li>
</ul>
<section anchor="terminology-changes">
<name>Terminology Changes</name>
<t>Note that some of the words used in previous versions of the OpenPGP
specification have been improved in this document.</t>
<t>In previous versions, the following terms were used:</t>
<ul spacing="normal">
<li>
<t>"Radix-64" was used to refer to OpenPGP's ASCII Armor base64 enco
ding (<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 forma
t (<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 means "Transferable Public Key" exclusively.</t>
</li>
<li>
<t>"Preferred Symmetric Algorithms" was the old name for the "Prefer
red Symmetric Ciphers for v1 SEIPD" subpacket (<xref target="preferred-v1-seipd"
/>).</t>
</li>
<li>
<t>"Modification Detection Code" or "MDC" was originally described a
s a distinct packet (packet type ID 19), and its corresponding flag in the Featu
res subpacket (<xref target="features-subpacket"/>) was known as "Modification D
etection".
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 targe
t="packet-types"/>) or sometimes to the encoded Packet Type ID (<xref target="pa
cket-headers"/>).</t>
</li>
</ul>
</section>
</section>
<section anchor="errata-listing">
<name>Errata Addressed by This Document</name>
<t>The following verified errata have been incorporated or are otherwise r
esolved by this document:</t>
<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 applies to user ID co
rrection</t>
</li>
<li>
<t><xref target="Errata-2219"/> - Session key encryption storage clari
fication</t>
</li>
<li>
<t><xref target="Errata-2222"/> - Simple hash <bcp14>MUST</bcp14>/<bcp
14>MAY</bcp14> clarification</t>
</li>
<li>
<t><xref target="Errata-2226"/> - Native line endings <bcp14>SHOULD</b
cp14> clarification</t>
</li>
<li>
<t><xref target="Errata-2234"/> - Radix-64/base64 clarification</t>
</li>
<li>
<t><xref target="Errata-2235"/> - ASCII/UTF-8 collation sequence clari
fication</t>
</li>
<li>
<t><xref target="Errata-2236"/> - Packet Composition is a sequence cla
rification</t>
</li>
<li>
<t><xref target="Errata-2238"/> - Subkey packets come after all User I
D packets clarification</t>
</li>
<li>
<t><xref target="Errata-2240"/> - Subkey removal clarification</t>
</li>
<li>
<t><xref target="Errata-2242"/> - 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>
</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 prep
aring 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>
</section> <t>Thanks to <contact fullname="Werner Koch"/> for the early work on rfc48
</section> 80bis and <contact fullname="Andrey Jivsov"/> for the work on <xref target="RFC6
</section> 637"/>.</t>
<section anchor="upgrade-guidance"><name>Upgrade Guidance (Adapting Implementati <t>This document also draws on much previous work from a number of other a
ons from RFC 4880 and RFC 6637)</name> uthors including <contact fullname="Derek Atkins"/>, <contact fullname="Charles
Breed"/>, <contact fullname="Dave Del Torto"/>, <contact fullname="Marc Dyksterh
ouse"/>, <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 Sta
llings"/>, <contact fullname="Mark Weaver"/>, and <contact fullname="Philip R. Z
immermann"/>.</t>
</section>
<t>This subsection offers a concise, non-normative summary of the substantial ad </back>
ditions to and departures from <xref target="RFC4880"/> and <xref target="RFC663
7"/>.
It is intended to help implementers who are augmenting an existing implementatio
n from those standards to this standard.
Cryptographic algorithms marked with "MTI" are mandatory to implement.</t>
<t><list style="symbols"> <!-- #61 [rfced] Written Numbers vs. Numerals
<t>Public Key signing algorithms:
<list style="symbols">
<t>Ed25519 (<xref target="key-ed25519"/> and <xref target="sig-ed25519"/>)
, MTI</t>
<t>Ed448 (<xref target="key-ed448"/> and <xref target="sig-ed448"/>)</t>
<t>EdDSALegacy with Ed25519Legacy (<xref target="key-eddsa-legacy"/> and <
xref target="sig-eddsa-legacy"/>)</t>
<t>ECDSA with Brainpool curves (<xref target="ec-curves"/>)</t>
</list></t>
<t>Public Key encryption algorithms:
<list style="symbols">
<t>X25519 (<xref target="key-x25519"/> and <xref target="pkesk-x25519"/>),
MTI</t>
<t>X448 (<xref target="key-x448"/> and <xref target="pkesk-x448"/>)</t>
<t>ECDH with Curve25519Legacy (<xref target="ec-curves"/>)</t>
<t>ECDH with Brainpool curves (<xref target="ec-curves"/>)</t>
</list></t>
<t>AEAD Encryption:
<list style="symbols">
<t>Version 2 SEIPD (<xref target="version-two-seipd"/>)</t>
<t>AEAD modes:
<list style="symbols">
<t>OCB mode (<xref target="aead-mode-ocb"/>), MTI</t>
<t>EAX mode (<xref target="aead-mode-eax"/>)</t>
<t>GCM mode (<xref target="aead-mode-gcm"/>)</t>
</list></t>
<t>Version 6 PKESK (<xref target="v6-pkesk"/>)</t>
<t>Version 6 SKESK (<xref target="v6-skesk"/>)</t>
<t>Features subpacket: add flag for SEIPDv2 (<xref target="features-subpac
ket"/>)</t>
<t>Subpacket: Preferred AEAD Ciphersuites (<xref target="preferred-v2-seip
d"/>)</t>
<t>Secret key encryption: AEAD "S2K usage octet" (<xref target="s2k-usage-
octet"/> and <xref target="secret-key-packet-formats"/>)</t>
</list></t>
<t>Version 6 Keys and Signatures:
<list style="symbols">
<t>Version 6 Public keys (<xref target="v6-pubkeys"/>)</t>
<t>Version 6 Fingerprint and Key ID (<xref target="v6-key-id-fingerprint"/
>)</t>
<t>Version 6 Secret keys (<xref target="secret-key-packet-formats"/>)</t>
<t>Version 6 Signatures (<xref target="version-four-and-six-sig"/>)</t>
<t>Version 6 One-Pass Signatures (<xref target="one-pass-sig"/>)</t>
</list></t>
<t>Certificate (Transferable Public Key) Structure:
<list style="symbols">
<t>Preferences subpackets in Direct Key Signatures (<xref target="self-sig
s"/>)</t>
<t>Self-verifying revocation certificate (<xref target="v6-revocation-cert
ificate"/>)</t>
<t>User ID is explicitly optional (<xref target="v6-certificate-structures
"/>)</t>
</list></t>
<t>S2K: Argon2 (<xref target="s2k-argon2"/>)</t>
<t>Subpacket: Intended Recipient Fingerprint (<xref target="intended-recipient
-fingerprint"/>)</t>
<t>Digest algorithms: SHA3-256 and SHA3-512 (<xref target="hash-algos"/>)</t>
<t>Packet: Padding (<xref target="padding-packet"/>)</t>
<t>Message structure: Packet Criticality (<xref target="packet-criticality"/>)
</t>
<t>Deprecations:
<list style="symbols">
<t>Public Key Algorithms:
<list style="symbols">
<t>Avoid RSA weak keys (<xref target="rsa-notes"/>)</t>
<t>Avoid DSA (<xref target="dsa-notes"/>)</t>
<t>Avoid ElGamal (<xref target="elgamal-notes"/>, <xref target="pkesk-
elgamal"/>)</t>
<t>For Version 6 Keys: Avoid EdDSA25519Legacy, Curve25519Legacy (<xref
target="ec-curves"/>)</t>
</list></t>
<t>Digest Algorithms:
<list style="symbols">
<t>Avoid MD5, SHA1, RIPEMD160 (<xref target="hash-algos"/>)</t>
</list></t>
<t>Symmetric Key Algorithms:
<list style="symbols">
<t>Avoid IDEA, TripleDES, CAST5 (<xref target="symmetric-algos"/>)</t>
</list></t>
<t>S2K Specifier:
<list style="symbols">
<t>Avoid Simple S2K (<xref target="s2k-simple"/>)</t>
</list></t>
<t>Secret Key protections (a.k.a. S2K Usage):
<list style="symbols">
<t>Avoid MalleableCFB (<xref target="secret-key-encryption"/>)</t>
</list></t>
<t>Packet Types:
<list style="symbols">
<t>Avoid Symmetrically-Encrypted Data (<xref target="sed"/>, <xref tar
get="ciphertext-malleability"/>)</t>
</list></t>
<t>Literal Data packet metadata:
<list style="symbols">
<t>Avoid Filename and Date fields (<xref target="lit"/>)</t>
<t>Avoid Special <spanx style="verb">_CONSOLE</spanx> "filename" (<xre
f target="for-eyes-only"/>)</t>
</list></t>
<t>Packet Versions:
<list style="symbols">
<t>Avoid Version 3 Public Keys (<xref target="v3-pubkeys"/>)</t>
<t>Avoid Version 3 Signatures (<xref target="signature-packet"/>)</t>
</list></t>
<t>Signature Types:
<list style="symbols">
<t>Avoid Reserved Signature Type ID 0xFF (<xref target="sigtype-reserv
ed"/>, <xref target="sig-computation-notes"/>)</t>
</list></t>
<t>Signature Subpackets:
<list style="symbols">
<t>For Version 6 Signatures: Avoid Issuer Key ID (<xref target="issuer
-keyid-subpacket"/>)</t>
<t>Avoid Revocation Key (<xref target="revocation-key"/>)</t>
</list></t>
<t>ASCII Armor:
<list style="symbols">
<t>Ignore, do not emit CRC (<xref target="optional-crc24"/>)</t>
<t>Do not emit "Version" armor header (<xref target="armor-header-key-
version"/>)</t>
</list></t>
<t>Cleartext Signature Framework:
<list style="symbols">
<t>Ignore, avoid emitting unnecessary Hash: headers (<xref target="arm
or-header-key-hash"/>)</t>
<t>Reject CSF signatures with invalid Hash: headers (<xref target="arm
or-header-key-hash"/>) or any other Armor Header (<xref target="cleartext-struct
ure"/>)</t>
</list></t>
</list></t>
</list></t>
<section anchor="terminology-changes"><name>Terminology Changes</name> 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.
<t>Note that some of the words used in previous revisions of the OpenPGP standar d have been improved in this document.</t> A few examples (see the document for more)
<t>In previous revisions, the following terms were used:</t> 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
<t><list style="symbols"> [PH] - I guess use numeral for all of them
<t>"Radix-64" was used to refer to OpenPGP's ASCII Armor base64 encoding (<xre -->
f target="base64"/>).</t>
<t>"Old packet format" was used to refer to the Legacy packet format (<xref ta
rget="legacy-packet-format"/>) predating <xref target="RFC2440"/>.</t>
<t>"New packet format" was used to refer to the OpenPGP packet format (<xref t
arget="openpgp-packet-format"/>) introduced in <xref target="RFC2440"/>.</t>
<t>"Certificate" was used ambiguously to mean multiple things.
In this document, it is used to mean "Transferable Public Key" exclusively.</t>
<t>"Preferred Symmetric Algorithms" was the old name for the "Preferred Symmet
ric Ciphers for v1 SEIPD" subpacket (<xref target="preferred-v1-seipd"/>)</t>
<t>"Modification Detection Code" or "MDC" was originally described as a distin
ct packet (packet type ID 19), and its corresponding flag in the Features subpac
ket (<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>
<t>"Packet Tag" was used to refer to the Packet Type ID (<xref target="packet-
types"/>), or sometimes to the encoded Packet Type ID (<xref target="packet-head
ers"/>).</t>
</list></t>
</section> <!-- #62 [rfced] Terminology Questions
</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>
<t>Thanks to the openpgp design team for working on this document to prepare it Note: if changes are made to the IANA terms, we will ask IANA to
for working group consumption: Stephen Farrell, Daniel Kahn Gillmor, Daniel Huig update the registries <https://www.iana.org/assignments/openpgp>
ens, Jeffrey Lau, Yutaka Niibe, Justus Winter and Paul Wouters.</t> accordingly.
<t>Thanks to Werner Koch for the early work on rfc4880bis and Andrey Jivsov for -Packet Type Names-
<xref target="RFC6637"/>.</t> 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.)
<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, Gai l Haspert, Gene Hoffman, Paul Hoffman, Ben Laurie, Raph Levien, Colin Plumb, Wil l Price, David Shaw, William Stallings, Mark Weaver, and Philip R. Zimmermann.</ t> Compressed Data Packet vs. Compressed Data packet
</section> Literal Data Packet vs. Literal Data packet vs. literal data packet vs. Litera
<section anchor="errata-listing"><name>Errata addressed by this document</name> l packet
(Note: should the 4 instances of "Literal packet" include "data",
or are these terms different?)
<t>The following verified errata have been incorporated or are otherwise resolve d by this document:</t> Marker Packet vs. marker packet
<t><list style="symbols"> One-Pass Signature Packet vs. One-Pass Signature packet vs.
<t><xref target="Errata-2199"/> - S2K hash/cipher octet correction</t> one-pass signature packet vs. one-pass packet
<t><xref target="Errata-2200"/> - No implicit use of IDEA correction</t> (Note: there are 2 instances of "one-pass packet"; is this term
<t><xref target="Errata-2206"/> - PKESK acronym expansion</t> different, or should "signature" be added to it?)
<t><xref target="Errata-2208"/> - Signature key owner clarification</t>
<t><xref target="Errata-2214"/> - Signature hashing clarification</t>
<t><xref target="Errata-2216"/> - Self signature applies to user ID correction
</t>
<t><xref target="Errata-2219"/> - Session key encryption storage clarification
</t>
<t><xref target="Errata-2222"/> - Simple hash <bcp14>MUST</bcp14>/<bcp14>MAY</
bcp14> clarification</t>
<t><xref target="Errata-2226"/> - Native line endings <bcp14>SHOULD</bcp14> cl
arification</t>
<t><xref target="Errata-2234"/> - Radix-64 / base64 clarification</t>
<t><xref target="Errata-2235"/> - ASCII / UTF-8 collation sequence clarificati
on</t>
<t><xref target="Errata-2236"/> - Packet Composition is a sequence clarificati
on</t>
<t><xref target="Errata-2238"/> - Subkey packets come after all User ID packet
s clarification</t>
<t><xref target="Errata-2240"/> - Subkey removal clarification</t>
<t><xref target="Errata-2242"/> - mL / emLen variable correction</t>
<t><xref target="Errata-2243"/> - CFB mode initialization vector (IV) clarific
ation</t>
<t><xref target="Errata-2270"/> - SHA-224 octet sequence correction</t>
<t><xref target="Errata-2271"/> - Radix-64 correction</t>
<t><xref target="Errata-3298"/> - Key revocation signatures correction</t>
<t><xref target="Errata-5491"/> - C code fix for CRC24_POLY define</t>
<t><xref target="Errata-7545"/> - Armor Header colon hex fix</t>
</list></t>
</section> Padding Packet vs. Padding packet
</back> 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
<!-- ##markdown-source: Public-Key Packet vs. Public-Key packet vs. Public Key packet vs.
H4sIAAAAAAAAA+y9SXMbaZYgeOev8GaYdYBZAEgAXBWZOUlxkRgSJY5ARS6V public-key packet vs. public key packet
ZZlOwEF6yuGOdHeQYoZUVjbnOYxZ1WGO08e2trn2aU6TNn+kfsm89Vt8ASmG
sqy7rKIqIkHA/Vve9763L71eb62MyyR6FrxdROnFi4u1aTZJwzl8Mc3DWdmL Public-Subkey Packet vs. Public-Subkey packet vs. public-subkey packet
o3LWy+C3xfWiN8nvF2XWy6NZHhU3vcFobRKW0XWW3z8LinK6ll0VWRKVUfEs
2N7f3+oGOzv7g26wuzvaW4sX+bNgkUc7o739y3xZlMOtrYOt4dokS4soLZbw Secret-Key Packet vs. Secret-Key packet vs. secret key packet
zn1UrIV5FMJg0WTtLss/XOfZcvEseBOV+Ffwa/hPnF4HL/DrtQ/RPXw7fRac Secret-Subkey Packet vs. Secret-Subkey packet vs. Secret Subkey packet
pWWUp1HZO8YlrxVlmE7/ECZZGvGYxfJqHhdFnKWX9wv47uzk8nRtET9bC4Iy Signature Packet vs. Signature packet vs. signature packet
m/Az9HEaLcobWDv8VWR5Cfss9Nfifm7/vI3SZYSvy/rWBXjrOAxNse4tFb+f
h3EC3wsof4Vw7Wf5Nf4U5hOYdf2mLBfFs81NfBK/im+jvj62iV9sXuXZXRFt Symmetric Key Encrypted Session Key Packet vs.
yhib+G4eLTLn3Ws4zPCqP8nm+lTv7nozn03wPK7iAl9J4MyK0nnJPtmX9+PM Symmetric-Key Encrypted Session Key Packet vs.
eQfmCZflTZbjjnvwbxDEKUDiog8HsgTQF/QdY81FuEy8ryPe+AK+79/x978K Symmetric-Key Encrypted Session Key packet vs.
YWspTEIPwO6eBYf4Df2ZZ4iN0TQus9yf77gfvFzG14AsznzHYRpHifeDzDjt Symmetric-key Encrypted Session Key packet
3/CXv1rkWZml+C0Cxk56Qd8Hhy/8eb6HfcWIUs403wPCLgv3e5nlT/TDr4ro
z8ssDnsARjwuO8dYfsCr5c3y237wJo6vImeS3y7L8EPofC1zXKf4za9mRfwn Symmetrically Encrypted Data Packet vs.
f/DT8dn3a3E6y/J5WAIE8YCevz45O3p58ub5Ifz33TN6WK74iyiNcngQ0PIk Symmetrically Encrypted Data packet
eRHOwyQYx9dpWC7hOsPe4IyXZfAqze7wkfImgtVP8gi+iu5pHIsG+E9P/tce
z/Mkiic3UXoVwn8ZTFNAtmfB4OBgl/4sojyOClyyjvI6muD8wZsMsBJGCo6y Symmetrically Encrypted Integrity Protected Data Packet vs.
+QLRJBhP4iidwNs/ZMlyHgWDrT0gKYtFHz71Bvu1vfYuXh2NB96Oj24yIC7B Symmetrically Encrypted Integrity Protected Data packet vs.
UbyA9ZTRxzI4LMtw8qEIDq9DWHXJODDJkiJ4HhbRNAB8wI2/Gx8GJynROyAb Symmetrically Encrypted and Integrity Protected Data Packet
wRhJSphPA5wi+P03g58Mjn1eZphfR3AV8SbCReRb3wfwAAHsR+XNX/pw66Pp
EsgsLGNzVmztb8JPRTTf9Ac/2O8vpjMY8+jgwIPAOmzwOg/nczzSJEyvl+E1 Trust Packet vs. Trust packet
wLkXHD3DZ7vBJMtzOALc5egZ0OS9bhCcjd9unp0cBQf7MBos9mDzKMvl5/Xa User Attribute Packet vs. User Attribute packet
wpGE3N3d9eMiI1JVCLA2d7Z2Blv9m3KeOHt/k91G8ys4XhxsJRj5UqwzdScA User ID Packet vs. User ID packet
AMK+za/hxv+F/gwA8c3RyHe4vJPTw7PXPhROZnSTngN3IbI83jw/Oz8J4FVl
fMEJXjb30JcF3ZSPszgpc57w6CZM0ygp2oGwBHyLPzIc7osSDgpej4pNYHOz -Hyphenation in Packet Type Names and General Terms-
KEd83uRH4BiXeVzeD+hEB/u9RTadRldpHH6Qo1SIDbcG+48A1HE4j8M0uDDD b) There are inconsistencies with hyphen use throughout the
tDx3dJPHRYmPHsO1F6pbf+x7oJzB+V//nyQR1K0/chpe4TBnCKeWR8bRVciT document. Please consider removing the hyphen from all instances of
jQG1079ESduD8RzgewrUYQrIcd065/fLPPxTMM7mWZ7dFh/u2x7763/Pr3HO "Public-Key", "Public-Subkey", "Secret-Key", "Secret-Subkey", and
uyj90EJ54GZMImA06XURZDO69sO98iZ4Pz55c/YboEN6YkgUxnJcwfh+vsiK "Symmetric-Key" both in the "OpenPGP Packet Types" registry and
eDnvBofLa6D+dD5dYHx4r3a2D/71n/55Zxep3UkOWBP2hgNzJQVf1l2EAT7b the running text (see some examples of general term inconsistencies
Y25HSBPRS5tRPMX31l0k5vGCd8Dxc5gVfoZrPB6+Cm7C4mZzQjQuyCYlEGx7 below). In the majority of RFCs, similar terms are not hyphenated,
qVv2/u70iGU0B89mYVJEzrrhgj5p3fDeqnXDz7DuN1kQzxdJPIlLuGgRHsDZ even when in attributive position (i.e., when followed by a noun),
8cnh11r57hNXvrt65buw8otXJ+NXQTjJs/R+HkQfF2Fa/NTl7j9xufurl7uP which is consistent with the PKIX documents and RFC 4253 (see guidance
CKIcPgB5OcjuQAQIJiBfxrOYucpPWfhg+2kLH2yvXPhg21s44jeS4q+37Cei for "public key" at <https://www.rfc-editor.org/materials/terms-online.txt>).
x2A1egwQPcZRMgsKs/ZwAUgOhKHMEM1zQPKvhOKDpxEVeG/1HoioRKQtEcZE Please review and let us know your preference.
liEWMB5Qua93DsPh0/YwHK7cw3BI6APkhXEnOH8/vtw8P/ztV1z5EzFouBqD
hohBb0iWD5I4jQD6zJ/GL9++f3389dY/euLFHa2+uCO8uO/Cafyxt7sdbAbA Some general examples:
/CP48PWWvfPEZe+sXvYOLPtwfHR2Bmt+f3na24dLmiQs86FqR1LA19vFE5Fn public-key algorithm vs. public key algorithm
tBp5RsSdQLsBAQCVKJBSaANxEYR/i108kWmNVjOtETGt5RXSngVtpoDDAPUv public-key encryption vs. public key encryption
nKFSGCZJ8F4Iqfn5a21p+4kCz/ZqgWd7y24pj+bZLegxX2/NT6Sh26tp6DbS secret-key material vs. secret key material
0PlruA/R/DWo0Lew3PAKCOrX4V7boyeuerR61SPUbE+fB/NsGoEeDhcgTFRb symmetric-key encryption
vIVlg8LYOfth4+uBf++JKLO3GmX2CGVeHiKoRKa3N/irnMDe4IkLH6xe+MDl symmetric-key algorithm
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==
-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 si
gnature 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 se
ssion key (general use)
Encrypted Message vs. encrypted message
Fingerprint vs. fingerprint (when not "Intended Recipient Fingerprint" or "Iss
uer 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. OpenPG
P 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)
-->
<!-- #64 [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
[PH] - Considered, but please keep them unchanged.
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.
[PH] - Both can be changed to "typically". - UPDATED -
--> -->
</rfc> </rfc>
 End of changes. 767 change blocks. 
10880 lines changed or deleted 9342 lines changed or added

This html diff was produced by rfcdiff 1.48.