rfc9580v6.txt | rfc9580.txt | |||
---|---|---|---|---|
skipping to change at line 234 ¶ | skipping to change at line 234 ¶ | |||
5.7. Symmetrically Encrypted Data Packet (Type ID 9) | 5.7. Symmetrically Encrypted Data Packet (Type ID 9) | |||
5.8. Marker Packet (Type ID 10) | 5.8. Marker Packet (Type ID 10) | |||
5.9. Literal Data Packet (Type ID 11) | 5.9. Literal Data Packet (Type ID 11) | |||
5.9.1. Special Filename _CONSOLE (Deprecated) | 5.9.1. Special Filename _CONSOLE (Deprecated) | |||
5.10. Trust Packet (Type ID 12) | 5.10. Trust Packet (Type ID 12) | |||
5.11. User ID Packet (Type ID 13) | 5.11. User ID Packet (Type ID 13) | |||
5.12. User Attribute Packet (Type ID 17) | 5.12. User Attribute Packet (Type ID 17) | |||
5.12.1. Image Attribute Subpacket | 5.12.1. Image Attribute Subpacket | |||
5.13. Symmetrically Encrypted and Integrity Protected Data Packet | 5.13. Symmetrically Encrypted and Integrity Protected Data Packet | |||
(Type ID 18) | (Type ID 18) | |||
5.13.1. Symmetrically Encrypted and Integrity Protected Data | 5.13.1. Version 1 Symmetrically Encrypted and Integrity | |||
Packet Version 1 Format | Protected Data Packet Format | |||
5.13.2. Symmetrically Encrypted and Integrity Protected Data | 5.13.2. Version 2 Symmetrically Encrypted and Integrity | |||
Packet Version 2 Format | Protected Data Packet Format | |||
5.13.3. EAX Mode | 5.13.3. EAX Mode | |||
5.13.4. OCB Mode | 5.13.4. OCB Mode | |||
5.13.5. GCM Mode | 5.13.5. GCM Mode | |||
5.14. Padding Packet (Type ID 21) | 5.14. Padding Packet (Type ID 21) | |||
6. Base64 Conversions | 6. Base64 Conversions | |||
6.1. Optional Checksum | 6.1. Optional Checksum | |||
6.1.1. An Implementation of the CRC24 in "C" | 6.1.1. An Implementation of the CRC24 in "C" | |||
6.2. Forming ASCII Armor | 6.2. Forming ASCII Armor | |||
6.2.1. Armor Header Line | 6.2.1. Armor Header Line | |||
6.2.2. Armor Headers | 6.2.2. Armor Headers | |||
skipping to change at line 327 ¶ | skipping to change at line 327 ¶ | |||
13.6. Fingerprint Usability | 13.6. Fingerprint Usability | |||
13.7. Avoiding Ciphertext Malleability | 13.7. Avoiding Ciphertext Malleability | |||
13.8. Secure Use of the v2 SEIPD Session-Key-Reuse Feature | 13.8. Secure Use of the v2 SEIPD Session-Key-Reuse Feature | |||
13.9. Escrowed Revocation Signatures | 13.9. Escrowed Revocation Signatures | |||
13.10. Random Number Generation and Seeding | 13.10. Random Number Generation and Seeding | |||
13.11. Traffic Analysis | 13.11. Traffic Analysis | |||
13.12. Surreptitious Forwarding | 13.12. Surreptitious Forwarding | |||
13.13. Hashed vs. Unhashed Subpackets | 13.13. Hashed vs. Unhashed Subpackets | |||
13.14. Malicious Compressed Data | 13.14. Malicious Compressed Data | |||
14. Implementation Considerations | 14. Implementation Considerations | |||
14.1. Constrained Legacy Fingerprint Storage for v6 Keys | 14.1. Constrained Legacy Fingerprint Storage for Version 6 Keys | |||
15. IANA Considerations | 15. IANA Considerations | |||
15.1. Renamed Protocol Group | 15.1. Renamed Protocol Group | |||
15.2. Renamed and Updated Registries | 15.2. Renamed and Updated Registries | |||
15.3. Removed Registry | 15.3. Removed Registry | |||
15.4. Added Registries | 15.4. Added Registries | |||
15.5. Registration Policies | 15.5. Registration Policies | |||
15.5.1. Registries That Use RFC Required | 15.5.1. Registries That Use RFC Required | |||
15.6. Designated Experts | 15.6. Designated Experts | |||
15.6.1. Key and Signature Versions | 15.6.1. Key and Signature Versions | |||
15.6.2. Encryption Versions | 15.6.2. Encryption Versions | |||
skipping to change at line 381 ¶ | skipping to change at line 381 ¶ | |||
A.10.3. Sample v2 SEIPD Packet | A.10.3. Sample v2 SEIPD Packet | |||
A.10.4. Decryption of Data | A.10.4. Decryption of Data | |||
A.10.5. Complete AEAD-OCB Encrypted Packet Sequence | A.10.5. Complete AEAD-OCB Encrypted Packet Sequence | |||
A.11. Sample AEAD-GCM Encryption and Decryption | A.11. Sample AEAD-GCM Encryption and Decryption | |||
A.11.1. Sample Symmetric Key Encrypted Session Key Packet (v6) | A.11.1. Sample Symmetric Key Encrypted Session Key Packet (v6) | |||
A.11.2. Starting AEAD-GCM Decryption of the Session Key | A.11.2. Starting AEAD-GCM Decryption of the Session Key | |||
A.11.3. Sample v2 SEIPD Packet | A.11.3. Sample v2 SEIPD Packet | |||
A.11.4. Decryption of Data | A.11.4. Decryption of Data | |||
A.11.5. Complete AEAD-GCM Encrypted Packet Sequence | A.11.5. Complete AEAD-GCM Encrypted Packet Sequence | |||
A.12. Sample Messages Encrypted Using Argon2 | A.12. Sample Messages Encrypted Using Argon2 | |||
A.12.1. Version 4 SKESK Using Argon2 with AES-128 | A.12.1. v4 SKESK Using Argon2 with AES-128 | |||
A.12.2. Version 4 SKESK Using Argon2 with AES-192 | A.12.2. v4 SKESK Using Argon2 with AES-192 | |||
A.12.3. Version 4 SKESK Using Argon2 with AES-256 | A.12.3. v4 SKESK Using Argon2 with AES-256 | |||
Appendix B. Upgrade Guidance (Adapting Implementations from RFCs | Appendix B. Upgrade Guidance (Adapting Implementations from RFCs | |||
4880 and 6637) | 4880 and 6637) | |||
B.1. Terminology Changes | B.1. Terminology Changes | |||
Appendix C. Errata Addressed by This Document | Appendix C. Errata Addressed by This Document | |||
Acknowledgements | Acknowledgements | |||
Authors' Addresses | Authors' Addresses | |||
1. Introduction | 1. Introduction | |||
This document provides information on the message-exchange packet | This document provides information on the message-exchange packet | |||
skipping to change at line 479 ¶ | skipping to change at line 479 ¶ | |||
Both digital signature and confidentiality services may be applied to | Both digital signature and confidentiality services may be applied to | |||
the same message. First, a signature is generated for the message | the same message. First, a signature is generated for the message | |||
and attached to the message. Then, the message plus signature is | and attached to the message. Then, the message plus signature is | |||
encrypted using a symmetric message key derived from the session key. | encrypted using a symmetric message key derived from the session key. | |||
Finally, the session key is encrypted using public key encryption and | Finally, the session key is encrypted using public key encryption and | |||
prefixed to the encrypted block. | prefixed to the encrypted block. | |||
2.2. Authentication via Digital Signature | 2.2. Authentication via Digital Signature | |||
The digital signature uses a cryptographic hash function and a public | The digital signature uses a cryptographic hash function and a public | |||
key signature algorithm. The sequence is as follows: | key algorithm capable of signing. The sequence is as follows: | |||
1. The sender creates a message. | 1. The sender creates a message. | |||
2. The sending implementation generates a hash digest of the | 2. The sending implementation generates a hash digest of the | |||
message. | message. | |||
3. The sending implementation generates a signature from the hash | 3. The sending implementation generates a signature from the hash | |||
digest using the sender's private key. | digest using the sender's private key. | |||
4. The signature is attached to or transmitted alongside the | 4. The signature is attached to or transmitted alongside the | |||
skipping to change at line 572 ¶ | skipping to change at line 572 ¶ | |||
The string [00 09 01 FF] forms an MPI with the value 511. | The string [00 09 01 FF] forms an MPI with the value 511. | |||
Additional rules: | Additional rules: | |||
* The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. | * The size of an MPI is ((MPI.length + 7) / 8) + 2 octets. | |||
* The length field of an MPI describes the length starting from its | * The length field of an MPI describes the length starting from its | |||
most significant non-zero bit. Thus, the MPI [00 02 01] is not | most significant non-zero bit. Thus, the MPI [00 02 01] is not | |||
formed correctly. It should be [00 01 01]. When parsing an MPI | formed correctly. It should be [00 01 01]. When parsing an MPI | |||
in a v6 Key, Signature, or Public Key Encrypted Session Key | in a version 6 Key, Signature, or Public Key Encrypted Session Key | |||
(PKESK) packet, the implementation MUST check that the encoded | (PKESK) packet, the implementation MUST check that the encoded | |||
length matches the length starting from the most significant non- | length matches the length starting from the most significant non- | |||
zero bit; if it doesn't match, reject the packet as malformed. | zero bit; if it doesn't match, reject the packet as malformed. | |||
* Unused bits of an MPI MUST be zero. | * Unused bits of an MPI MUST be zero. | |||
3.2.1. Using MPIs to Encode Other Data | 3.2.1. Using MPIs to Encode Other Data | |||
Note that in some places, MPIs are used to encode non-integer data, | Note that in some places, MPIs are used to encode non-integer data, | |||
such as an elliptic curve (EC) point (see Section 11.2) or an octet | such as an elliptic curve (EC) point (see Section 11.2) or an octet | |||
string of known, fixed length (see Section 11.3). The wire | string of known, fixed length (see Section 11.3). The wire | |||
representation is the same: 2 octets of length in bits counted from | representation is the same: 2 octets of length in bits counted from | |||
the first non-zero bit, followed by the smallest series of octets | the first non-zero bit, followed by the smallest series of octets | |||
that can represent the value while stripping off any leading zero | that can represent the value while stripping off any leading zero | |||
octets. | octets. | |||
3.3. Key IDs and Fingerprints | 3.3. Key IDs and Fingerprints | |||
A Key ID is an 8-octet scalar that identifies a key. Implementations | A Key ID is an 8-octet scalar that identifies a key. Implementations | |||
SHOULD NOT assume that Key IDs are unique. A fingerprint is more | SHOULD NOT assume that Key IDs are unique. A fingerprint is more | |||
likely to be unique than a key ID. The fingerprint and key ID of a | 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. | key are calculated differently according to the version of the key. | |||
Section 5.5.4 describes how Key IDs and Fingerprints are formed. | Section 5.5.4 describes how Key IDs and Fingerprints are formed. | |||
3.4. Text | 3.4. Text | |||
Unless otherwise specified, the character set for text is the UTF-8 | Unless otherwise specified, the character set for text is the UTF-8 | |||
[RFC3629] encoding of Unicode [ISO10646]. | [RFC3629] encoding of Unicode [ISO10646]. | |||
3.5. Time Fields | 3.5. Time Fields | |||
skipping to change at line 617 ¶ | skipping to change at line 617 ¶ | |||
3.6. Keyrings | 3.6. Keyrings | |||
A keyring is a collection of one or more keys in a file or database. | A keyring is a collection of one or more keys in a file or database. | |||
Typically, a keyring is simply a sequential list of keys, but it may | Typically, a keyring is simply a sequential list of keys, but it may | |||
be any suitable database. It is beyond the scope of this | be any suitable database. It is beyond the scope of this | |||
specification to discuss the details of keyrings or other databases. | specification to discuss the details of keyrings or other databases. | |||
3.7. String-to-Key (S2K) Specifier | 3.7. String-to-Key (S2K) Specifier | |||
A string-to-key (S2K) specifier type is used to convert a passphrase | A string-to-key (S2K) Specifier Type is used to convert a passphrase | |||
string into a symmetric key encryption/decryption key. Passphrases | string into a symmetric key encryption/decryption key. Passphrases | |||
requiring use of S2K conversion are currently used in two places: to | requiring use of S2K conversion are currently used in two places: to | |||
encrypt the secret part of private keys and for symmetrically | encrypt the secret part of private keys and for symmetrically | |||
encrypted messages. | encrypted messages. | |||
3.7.1. S2K Specifier Types | 3.7.1. S2K Specifier Types | |||
There are four types of S2K Specifier Types currently specified and | There are four types of S2K Specifier Types currently specified and | |||
some reserved values: | some reserved values: | |||
skipping to change at line 692 ¶ | skipping to change at line 692 ¶ | |||
As the data is hashed, it is given independently to each hash | As the data is hashed, it is given independently to each hash | |||
context. Since the contexts have been initialized differently, they | context. Since the contexts have been initialized differently, they | |||
will each produce a different hash output. Once the passphrase is | will each produce a different hash output. Once the passphrase is | |||
hashed, the output data from the multiple hashes is concatenated, | hashed, the output data from the multiple hashes is concatenated, | |||
first hash leftmost, to produce the key data, and any excess octets | first hash leftmost, to produce the key data, and any excess octets | |||
on the right are discarded. | on the right are discarded. | |||
3.7.1.2. Salted S2K | 3.7.1.2. Salted S2K | |||
Salted S2K includes a "salt" value in the S2K Specifier Type -- some | Salted S2K includes a "salt" value in the S2K Specifier -- some | |||
arbitrary data -- that gets hashed along with the passphrase string | arbitrary data -- that gets hashed along with the passphrase string | |||
to help prevent dictionary attacks. | to help prevent dictionary attacks. | |||
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 | |||
Salted S2K is exactly like Simple S2K, except that the input to the | Salted S2K is exactly like Simple S2K, except that the input to the | |||
hash function(s) consists of the 8 octets of salt from the S2K | hash function(s) consists of the 8 octets of salt from the S2K | |||
Specifier Type, followed by the passphrase. | Specifier, followed by the passphrase. | |||
3.7.1.3. Iterated and Salted S2K | 3.7.1.3. Iterated and Salted S2K | |||
Iterated and Salted S2K includes both a salt and an octet count. The | Iterated and Salted S2K includes both a salt and an octet count. The | |||
salt is combined with the passphrase, and the resulting value is | salt is combined with the passphrase, and the resulting value is | |||
repeated and then hashed. This further increases the amount of work | repeated and then hashed. This further increases the amount of work | |||
an attacker must do to try dictionary attacks. | an attacker must do to try dictionary attacks. | |||
Octet 0: 0x03 | Octet 0: 0x03 | |||
Octet 1: hash algorithm | Octet 1: hash algorithm | |||
skipping to change at line 726 ¶ | skipping to change at line 726 ¶ | |||
The count is coded into a 1-octet number using the following formula: | The count is coded into a 1-octet number using the following formula: | |||
#define EXPBIAS 6 | #define EXPBIAS 6 | |||
count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); | count = ((Int32)16 + (c & 15)) << ((c >> 4) + EXPBIAS); | |||
The above formula is described in [C99], where "Int32" is a type for | The above formula is described in [C99], where "Int32" is a type for | |||
a 32-bit integer, and the variable "c" is the coded count, octet 10. | a 32-bit integer, and the variable "c" is the coded count, octet 10. | |||
Iterated and Salted S2K hashes the passphrase and salt data multiple | Iterated and Salted S2K hashes the passphrase and salt data multiple | |||
times. The total number of octets to be hashed is specified in the | times. The total number of octets to be hashed is specified in the | |||
encoded count in the S2K Specifier Type. Note that the resulting | encoded count in the S2K Specifier. Note that the resulting count | |||
count value is an octet count of how many octets will be hashed, not | value is an octet count of how many octets will be hashed, not an | |||
an iteration count. | iteration count. | |||
Initially, one or more hash contexts are set up the same as the other | Initially, one or more hash contexts are set up the same as the other | |||
S2K algorithms, depending on how many octets of key data are needed. | S2K algorithms, depending on how many octets of key data are needed. | |||
Then the salt, followed by the passphrase data, is repeatedly | Then the salt, followed by the passphrase data, is repeatedly | |||
processed as input to each hash context until the number of octets | processed as input to each hash context until the number of octets | |||
specified by the octet count has been hashed. The input is truncated | 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 | 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 copy | initial size of the salt plus passphrase. That is, at least one copy | |||
of the full salt plus passphrase will be provided as input to each | of the full salt plus passphrase will be provided as input to each | |||
hash context regardless of the octet count. After the hashing is | hash context regardless of the octet count. After the hashing is | |||
skipping to change at line 776 ¶ | skipping to change at line 776 ¶ | |||
of t, p, and m as described above, the required key size as the tag | 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. | length T, 0x13 as the version v, and Argon2id as the type. | |||
For the recommended values of t, p, and m, see Section 4 of | For the recommended values of t, p, and m, see Section 4 of | |||
[RFC9106]. If the recommended value of m for a given application is | [RFC9106]. If the recommended value of m for a given application is | |||
not a power of 2, it is RECOMMENDED to round up to the next power of | not a power of 2, it is RECOMMENDED to round up to the next power of | |||
2 if the resulting performance would be acceptable; otherwise, round | 2 if the resulting performance would be acceptable; otherwise, round | |||
down (keeping in mind that m must be at least 8*p). | down (keeping in mind that m must be at least 8*p). | |||
As an example, with the first recommended option (t=1, p=4, m=2^21), | As an example, with the first recommended option (t=1, p=4, m=2^21), | |||
the full S2K Specifier Type would be: | the full S2K Specifier would be: | |||
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 | |||
where XX represents a random octet of salt. | where XX represents a random octet of salt. | |||
3.7.2. S2K Usage | 3.7.2. S2K Usage | |||
Simple S2K and Salted S2K Specifier Types can be brute-forced when | Simple S2K and Salted S2K Specifiers can be brute-forced when used | |||
used with a low-entropy string, such as those typically provided by | with a low-entropy string, such as those typically provided by users. | |||
users. In addition, the usage of Simple S2K can lead to key and | In addition, the usage of Simple S2K can lead to key and | |||
initialization vector (IV) reuse (see Section 5.3). Therefore, when | initialization vector (IV) reuse (see Section 5.3). Therefore, when | |||
generating an S2K Specifier Type, an implementation MUST NOT use | generating an S2K Specifier, an implementation MUST NOT use Simple | |||
Simple S2K. Furthermore, an implementation SHOULD NOT generate a | S2K. Furthermore, an implementation SHOULD NOT generate a Salted S2K | |||
Salted S2K unless the implementation knows that the input string is | unless the implementation knows that the input string is high entropy | |||
high entropy (for example, it generated the string itself using a | (for example, it generated the string itself using a known good | |||
known good source of randomness). | source of randomness). | |||
It is RECOMMENDED that implementations use Argon2. If Argon2 is not | It is RECOMMENDED that implementations use Argon2. If Argon2 is not | |||
available, Iterated and Salted S2K MAY be used if care is taken to | available, Iterated and Salted S2K MAY be used if care is taken to | |||
use a high octet count and a strong passphrase. However, this method | use a high octet count and a strong passphrase. However, this method | |||
does not provide memory hardness, unlike Argon2. | does not provide memory hardness, unlike Argon2. | |||
3.7.2.1. Secret Key Encryption | 3.7.2.1. Secret Key Encryption | |||
The first octet following the public key material in a Secret Key | The first octet following the public key material in a Secret Key | |||
packet (Section 5.5.3) indicates whether and how the secret key | packet (Section 5.5.3) indicates whether and how the secret key | |||
skipping to change at line 886 ¶ | skipping to change at line 886 ¶ | |||
| | |S2K- |secrets || check(secrets))| | | | | |S2K- |secrets || check(secrets))| | | |||
| | |specifier, | | | | | | |specifier, | | | | |||
| | |IV | | | | | | |IV | | | | |||
+---------+------------+------------+--------------------------+----+ | +---------+------------+------------+--------------------------+----+ | |||
Table 2: OpenPGP Secret Key Encryption (S2K Usage Octet) Registry | Table 2: OpenPGP Secret Key Encryption (S2K Usage Octet) Registry | |||
When emitting a secret key (with or without passphrase protection), | When emitting a secret key (with or without passphrase protection), | |||
an implementation MUST only produce data from a row with "Generate?" | an implementation MUST only produce data from a row with "Generate?" | |||
marked as "Yes". Each row with "Generate?" marked as "No" is | marked as "Yes". Each row with "Generate?" marked as "No" is | |||
described for backward compatibility (for reading v4 and earlier keys | described for backward compatibility (for reading version 4 and | |||
only) and MUST NOT be used to generate new output. Version 6 secret | earlier keys only) and MUST NOT be used to generate new output. | |||
keys using these formats MUST be rejected. | Version 6 secret keys using these formats MUST be rejected. | |||
Note that compared to a version 4 secret key, the parameters of a | Note that compared to a version 4 secret key, the parameters of a | |||
passphrase-protected version 6 secret key are stored with an | passphrase-protected version 6 secret key are stored with an | |||
additional pair of length counts, each of which is 1 octet wide. | additional pair of length counts, each of which is 1 octet wide. | |||
Argon2 is only used with Authenticated Encryption with Associated | Argon2 is only used with Authenticated Encryption with Associated | |||
Data (AEAD) (S2K usage octet 253). An implementation MUST NOT create | Data (AEAD) (S2K usage octet 253). An implementation MUST NOT create | |||
and MUST reject as malformed any Secret Key packet where the S2K | and MUST reject as malformed any Secret Key packet where the S2K | |||
usage octet is not AEAD (253) and the S2K Specifier Type is Argon2. | usage octet is not AEAD (253) and the S2K Specifier Type is Argon2. | |||
3.7.2.2. Symmetric Key Message Encryption | 3.7.2.2. Symmetric Key Message Encryption | |||
OpenPGP can create a Symmetric Key Encrypted Session Key (SKESK) | OpenPGP can create a Symmetric Key Encrypted Session Key (SKESK) | |||
packet at the front of a message. This is used to allow S2K | packet at the front of a message. This is used to allow S2K | |||
Specifier Types to be used for the passphrase conversion or to create | Specifiers to be used for the passphrase conversion or to create | |||
messages with a mix of SKESK packets and PKESK packets. This allows | messages with a mix of SKESK packets and PKESK packets. This allows | |||
a message to be decrypted with either a passphrase or a public key | a message to be decrypted with either a passphrase or a public key | |||
pair. | pair. | |||
Implementations predating [RFC2440] always used the International | Implementations predating [RFC2440] always used the International | |||
Data Encryption Algorithm (IDEA) with Simple S2K conversion when | Data Encryption Algorithm (IDEA) with Simple S2K conversion when | |||
encrypting a message with a symmetric algorithm; see Section 5.7. | encrypting a message with a symmetric algorithm; see Section 5.7. | |||
IDEA MUST NOT be generated but MAY be consumed for backward | IDEA MUST NOT be generated but MAY be consumed for backward | |||
compatibility. | compatibility. | |||
skipping to change at line 1479 ¶ | skipping to change at line 1479 ¶ | |||
An implementation MUST generate a version 6 signature when signing | An implementation MUST generate a version 6 signature when signing | |||
with a version 6 key. An implementation MUST generate a version 4 | with a version 6 key. An implementation MUST generate a version 4 | |||
signature when signing with a version 4 key. Implementations MUST | signature when signing with a version 4 key. Implementations MUST | |||
NOT create version 3 signatures; they MAY accept version 3 | NOT create version 3 signatures; they MAY accept version 3 | |||
signatures. See Section 10.3.2.2 for more details about packet | signatures. See Section 10.3.2.2 for more details about packet | |||
version correspondence between keys and signatures. | version correspondence between keys and signatures. | |||
5.2.1. Signature Types | 5.2.1. Signature Types | |||
There are a number of possible meanings for a signature, which are | There are a number of possible meanings for a signature, which are | |||
indicated by the signature Type ID in any given signature. Please | indicated by the Signature Type ID in any given signature. Please | |||
note that the vagueness of these meanings is not a flaw but rather a | note that the vagueness of these meanings is not a flaw but rather a | |||
feature of the system. Because OpenPGP places final authority for | feature of the system. Because OpenPGP places final authority for | |||
validity upon the receiver of a signature, it may be that one | validity upon the receiver of a signature, it may be that one | |||
signer's casual act might be more rigorous than some other | signer's casual act might be more rigorous than some other | |||
authority's positive act. See Section 5.2.4 for detailed information | authority's positive act. See Section 5.2.4 for detailed information | |||
on how to compute and verify signatures of each type. | on how to compute and verify signatures of each type. | |||
+======+====================================+==================+ | +======+====================================+==================+ | |||
| ID | Name | Reference | | | ID | Name | Reference | | |||
+======+====================================+==================+ | +======+====================================+==================+ | |||
skipping to change at line 1632 ¶ | skipping to change at line 1632 ¶ | |||
or by a (deprecated) Revocation Key. The signature is computed over | or by a (deprecated) Revocation Key. The signature is computed over | |||
the same data as the certification that it revokes, and it should | the same data as the certification that it revokes, and it should | |||
have a later creation date than that certification. | have a later creation date than that certification. | |||
5.2.1.14. Timestamp Signature (Type ID 0x40) | 5.2.1.14. Timestamp Signature (Type ID 0x40) | |||
This signature is only meaningful for the timestamp contained in it. | This signature is only meaningful for the timestamp contained in it. | |||
5.2.1.15. Third-Party Confirmation Signature (Type ID 0x50) | 5.2.1.15. Third-Party Confirmation Signature (Type ID 0x50) | |||
This signature is a signature over some other OpenPGP Signature | This signature is a signature over another OpenPGP Signature packet. | |||
packet(s). It is analogous to a notary seal on the signed data. A | It is analogous to a notary seal on the signed data. A Third-Party | |||
Third-Party Confirmation signature SHOULD include one or more | Confirmation signature SHOULD include a Signature Target subpacket | |||
Signature Target subpackets to give easy identification. Note that | that identifies the confirmed signature. | |||
we really do mean SHOULD. There are plausible uses for this (such as | ||||
a blind party that only sees the signature, not the key or source | ||||
document) that cannot include a target subpacket. | ||||
5.2.1.16. Reserved (Type ID 0xFF) | 5.2.1.16. Reserved (Type ID 0xFF) | |||
An implementation MUST NOT create any signature with this type and | An implementation MUST NOT create any signature with this type and | |||
MUST NOT validate any signature made with this type. See | MUST NOT validate any signature made with this type. See | |||
Section 5.2.4.1 for more details. | Section 5.2.4.1 for more details. | |||
5.2.2. Version 3 Signature Packet Format | 5.2.2. Version 3 Signature Packet Format | |||
The body of a version 3 Signature packet contains: | The body of a version 3 Signature packet contains: | |||
* A 1-octet version number with value 3. | * A 1-octet version number with value 3. | |||
* A 1-octet length of the following hashed material; it MUST be 5: | * A 1-octet length of the following hashed material; it MUST be 5: | |||
- A 1-octet signature Type ID. | - A 1-octet Signature Type ID. | |||
- A 4-octet creation time. | - A 4-octet creation time. | |||
* An 8-octet Key ID of the signer. | * An 8-octet Key ID of the signer. | |||
* A 1-octet public key algorithm. | * A 1-octet public key algorithm. | |||
* A 1-octet hash algorithm. | * A 1-octet hash algorithm. | |||
* A 2-octet field holding left 16 bits of the signed hash value. | * A 2-octet field holding left 16 bits of the signed hash value. | |||
skipping to change at line 1693 ¶ | skipping to change at line 1690 ¶ | |||
* MPI of DSA value s. | * MPI of DSA value s. | |||
The signature calculation is based on a hash of the signed data, as | The signature calculation is based on a hash of the signed data, as | |||
described above. The details of the calculation are different for | described above. The details of the calculation are different for | |||
DSA signatures than for RSA signatures; see Sections 5.2.3.1 and | DSA signatures than for RSA signatures; see Sections 5.2.3.1 and | |||
5.2.3.2. | 5.2.3.2. | |||
5.2.3. Versions 4 and 6 Signature Packet Formats | 5.2.3. Versions 4 and 6 Signature Packet Formats | |||
The body of a v4 or v6 Signature packet contains: | The body of a version 4 or version 6 Signature packet contains: | |||
* A 1-octet version number. This is 4 for v4 signatures and 6 for | * A 1-octet version number. This is 4 for version 4 signatures and | |||
v6 signatures. | 6 for version 6 signatures. | |||
* A 1-octet signature Type ID. | * A 1-octet Signature Type ID. | |||
* A 1-octet public key algorithm. | * A 1-octet public key algorithm. | |||
* A 1-octet hash algorithm. | * A 1-octet hash algorithm. | |||
* A scalar octet count for the hashed subpacket data that follows | * A scalar octet count for the hashed subpacket data that follows | |||
this field. For a v4 signature, this is a 2-octet field. For a | this field. For a version 4 signature, this is a 2-octet field. | |||
v6 signature, this is a 4-octet field. Note that this is the | For a version 6 signature, this is a 4-octet field. Note that | |||
length in octets of all of the hashed subpackets; an | this is the length in octets of all of the hashed subpackets; an | |||
implementation's pointer incremented by this number will skip over | implementation's pointer incremented by this number will skip over | |||
the hashed subpackets. | the hashed subpackets. | |||
* A hashed subpacket data set (zero or more subpackets). | * A hashed subpacket data set (zero or more subpackets). | |||
* A scalar octet count for the unhashed subpacket data that follows | * A scalar octet count for the unhashed subpacket data that follows | |||
this field. For a v4 signature, this is a 2-octet field. For a | this field. For a version 4 signature, this is a 2-octet field. | |||
v6 signature, this is a 4-octet field. Note that this is the | For a version 6 signature, this is a 4-octet field. Note that | |||
length in octets of all of the unhashed subpackets; an | this is the length in octets of all of the unhashed subpackets; an | |||
implementation's pointer incremented by this number will skip over | implementation's pointer incremented by this number will skip over | |||
the unhashed subpackets. | the unhashed subpackets. | |||
* An unhashed subpacket data set (zero or more subpackets). | * An unhashed subpacket data set (zero or more subpackets). | |||
* A 2-octet field holding the left 16 bits of the signed hash value. | * A 2-octet field holding the left 16 bits of the signed hash value. | |||
* Only for v6 signatures, a variable-length field containing: | * Only for version 6 signatures, a variable-length field containing: | |||
- A 1-octet salt size. The value MUST match the value defined | - A 1-octet salt size. The value MUST match the value defined | |||
for the hash algorithm as specified in Table 23. | for the hash algorithm as specified in Table 23. | |||
- The salt, which is a random value of the specified size. | - The salt, which is a random value of the specified size. | |||
* One or more MPIs comprising the signature. This portion is | * One or more MPIs comprising the signature. This portion is | |||
algorithm specific. | algorithm specific. | |||
5.2.3.1. Algorithm-Specific Fields for RSA Signatures | 5.2.3.1. Algorithm-Specific Fields for RSA Signatures | |||
skipping to change at line 1835 ¶ | skipping to change at line 1832 ¶ | |||
5.2.3.6. Notes on Signatures | 5.2.3.6. Notes on Signatures | |||
The concatenation of the data being signed, the signature data from | The concatenation of the data being signed, the signature data from | |||
the version number through the hashed subpacket data (inclusive), and | the version number through the hashed subpacket data (inclusive), and | |||
(for signature versions later than 3) a 6-octet trailer (see | (for signature versions later than 3) a 6-octet trailer (see | |||
Section 5.2.4) is hashed. The resulting hash value is what is | Section 5.2.4) is hashed. The resulting hash value is what is | |||
signed. The high 16 bits (first two octets) of the hash are included | signed. The high 16 bits (first two octets) of the hash are included | |||
in the Signature packet to provide a way to reject some invalid | in the Signature packet to provide a way to reject some invalid | |||
signatures without performing a signature verification. When | signatures without performing a signature verification. When | |||
verifying a v6 signature, an implementation MUST reject the signature | verifying a version 6 signature, an implementation MUST reject the | |||
if these octets do not match the first two octets of the computed | signature if these octets do not match the first two octets of the | |||
hash. | computed hash. | |||
There are two fields consisting of Signature subpackets. The first | There are two fields consisting of Signature subpackets. The first | |||
field is hashed with the rest of the signature data, while the second | field is hashed with the rest of the signature data, while the second | |||
is not hashed into the signature. The second set of subpackets (the | is not hashed into the signature. The second set of subpackets (the | |||
"unhashed section") is not cryptographically protected by the | "unhashed section") is not cryptographically protected by the | |||
signature and should include only advisory information. See | signature and should include only advisory information. See | |||
Section 13.13 for more information. | Section 13.13 for more information. | |||
The differences between a v4 and v6 signature are two-fold: first, a | The differences between a version 4 and version 6 signature are two- | |||
v6 signature increases the width of the fields that indicate the size | fold: first, a version 6 signature increases the width of the fields | |||
of the hashed and unhashed subpackets, making it possible to include | that indicate the size of the hashed and unhashed subpackets, making | |||
significantly more data in subpackets. Second, the hash is salted | it possible to include significantly more data in subpackets. | |||
with random data (see Section 13.2). | Second, the hash is salted with random data (see Section 13.2). | |||
The algorithms for converting the hash function result to a signature | The algorithms for converting the hash function result to a signature | |||
are described in Section 5.2.4. | are described in Section 5.2.4. | |||
5.2.3.7. Signature Subpacket Specification | 5.2.3.7. Signature Subpacket Specification | |||
A subpacket data set consists of zero or more Signature subpackets. | A subpacket data set consists of zero or more Signature subpackets. | |||
In Signature packets, the subpacket data set is preceded by a 2-octet | In Signature packets, the subpacket data set is preceded by a 2-octet | |||
(for v4 signatures) or 4-octet (for v6 signatures) scalar count of | (for version 4 signatures) or 4-octet (for version 6 signatures) | |||
the length in octets of all the subpackets. A pointer incremented by | scalar count of the length in octets of all the subpackets. A | |||
this number will skip over the subpacket data set. | pointer incremented by this number will skip over the subpacket data | |||
set. | ||||
Each subpacket consists of a subpacket header and a body. The header | Each subpacket consists of a subpacket header and a body. The header | |||
consists of: | consists of: | |||
* The encoded subpacket length (1, 2, or 5 octets). | * The encoded subpacket length (1, 2, or 5 octets). | |||
* The encoded subpacket Type ID (1 octet). | * The encoded Subpacket Type ID (1 octet). | |||
* The subpacket-specific data. | * The subpacket-specific data. | |||
The subpacket length field covers the encoded subpacket Type ID and | The subpacket length field covers the encoded Subpacket Type ID and | |||
the subpacket-specific data, and it does not include the subpacket | the subpacket-specific data, and it does not include the subpacket | |||
length field itself. It is encoded similarly to a 1-octet, 2-octet, | length field itself. It is encoded similarly to a 1-octet, 2-octet, | |||
or 5-octet OpenPGP format packet header. The encoded subpacket | or 5-octet OpenPGP format packet header. The encoded subpacket | |||
length can be decoded as follows: | length can be decoded as follows: | |||
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 = [4-octet scalar starting at 2nd_octet] | subpacket length = [4-octet scalar starting at 2nd_octet] | |||
Bit 7 of the encoded subpacket Type ID is the "critical" bit. If | 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 | set, it denotes that the subpacket is one that is critical for the | |||
evaluator of the signature to recognize. If a subpacket is | evaluator of the signature to recognize. If a subpacket is | |||
encountered that is marked critical but is unknown to the evaluating | encountered that is marked critical but is unknown to the evaluating | |||
implementation, the evaluator SHOULD consider the signature to be in | implementation, the evaluator SHOULD consider the signature to be in | |||
error. | error. | |||
An implementation SHOULD ignore any non-critical subpacket of a type | An implementation SHOULD ignore any non-critical subpacket of a type | |||
that it does not recognize. | that it does not recognize. | |||
An evaluator may "recognize" a subpacket but not implement it. The | An evaluator may "recognize" a subpacket but not implement it. The | |||
purpose of the critical bit is to allow the signer to tell an | purpose of the critical bit is to allow the signer to tell an | |||
evaluator that it would prefer a new, unknown feature to generate an | evaluator that it would prefer a new, unknown feature to generate an | |||
error rather than being ignored. | error rather than being ignored. | |||
The other bits of the encoded subpacket Type ID (i.e., bits 6-0) | The other bits of the encoded Subpacket Type ID (i.e., bits 6-0) | |||
contain the subpacket Type ID. | contain the Subpacket Type ID. | |||
The following signature subpackets are defined: | The following signature subpackets are defined: | |||
+=========+===========================+==================+ | +=========+===========================+==================+ | |||
| ID | Description | Reference | | | ID | Description | Reference | | |||
+=========+===========================+==================+ | +=========+===========================+==================+ | |||
| 0 | Reserved | | | | 0 | Reserved | | | |||
+---------+---------------------------+------------------+ | +---------+---------------------------+------------------+ | |||
| 1 | Reserved | | | | 1 | Reserved | | | |||
+---------+---------------------------+------------------+ | +---------+---------------------------+------------------+ | |||
skipping to change at line 2069 ¶ | skipping to change at line 2067 ¶ | |||
signature. Subpackets that appear in a certification self-signature | signature. Subpackets that appear in a certification self-signature | |||
apply to the User ID, and subpackets that appear in the subkey self- | apply to the User ID, and subpackets that appear in the subkey self- | |||
signature apply to the subkey. Lastly, subpackets on the Direct Key | signature apply to the subkey. Lastly, subpackets on the Direct Key | |||
signature apply to the entire key. | signature apply to the entire key. | |||
An implementation should interpret a self-signature's preference | An implementation should interpret a self-signature's preference | |||
subpackets as narrowly as possible. For example, suppose a key has | subpackets as narrowly as possible. For example, suppose a key has | |||
two user names, Alice and Bob. Suppose that Alice prefers the AEAD | two user names, Alice and Bob. Suppose that Alice prefers the AEAD | |||
ciphersuite AES-256 with OCB, and Bob prefers Camellia-256 with GCM. | ciphersuite AES-256 with OCB, and Bob prefers Camellia-256 with GCM. | |||
If the implementation locates this key via Alice's name, then the | If the implementation locates this key via Alice's name, then the | |||
Preferred AEAD Ciphersuite is AES-256 with OCB; if the implementation | preferred AEAD ciphersuite is AES-256 with OCB; if the implementation | |||
locates the key via Bob's name, then the preferred algorithm is | locates the key via Bob's name, then the preferred algorithm is | |||
Camellia-256 with GCM. If the key is located by Key ID, the | Camellia-256 with GCM. If the key is located by Key ID, the | |||
algorithm of the Primary User ID of the key provides the Preferred | algorithm of the Primary User ID of the key provides the preferred | |||
AEAD Ciphersuite. | AEAD ciphersuite. | |||
Revoking a self-signature or allowing it to expire has a semantic | Revoking a self-signature or allowing it to expire has a semantic | |||
meaning that varies with the signature type. Revoking the self- | meaning that varies with the signature type. Revoking the self- | |||
signature on a User ID effectively retires that user name. 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", | signature is a statement, "My name X is tied to my signing key K", | |||
and it is corroborated by other users' certifications. If another | and it is corroborated by other users' certifications. If another | |||
user revokes their certification, they are effectively saying that | user revokes their certification, they are effectively saying that | |||
they no longer believe that name and that key are tied together. | they no longer believe that name and that key are tied together. | |||
Similarly, if the users themselves revoke their self-signature, then | Similarly, if the users themselves revoke their self-signature, then | |||
the users no longer go by that name, no longer have that email | the users no longer go by that name, no longer have that email | |||
skipping to change at line 2107 ¶ | skipping to change at line 2105 ¶ | |||
offer to create new self-signatures that advertise the actual set of | offer to create new self-signatures that advertise the actual set of | |||
features and algorithms supported by the implementation. | features and algorithms supported by the implementation. | |||
An implementation that encounters multiple self-signatures on the | An implementation that encounters multiple self-signatures on the | |||
same object MUST select the most recent valid self-signature and | same object MUST select the most recent valid self-signature and | |||
ignore all other self-signatures. | ignore all other self-signatures. | |||
By convention, a version 4 key stores information about the primary | By convention, a version 4 key stores information about the primary | |||
Public Key (key flags, key expiration, etc.) and the Transferable | Public Key (key flags, key expiration, etc.) and the Transferable | |||
Public Key as a whole (features, algorithm preferences, etc.) in a | Public Key as a whole (features, algorithm preferences, etc.) in a | |||
User ID self-signature of type 0x10 or 0x13. To use a v4 key, some | User ID self-signature of type 0x10 or 0x13. To use a version 4 key, | |||
implementations require at least one User ID with a valid self- | some implementations require at least one User ID with a valid self- | |||
signature to be present. For this reason, it is RECOMMENDED to | signature to be present. For this reason, it is RECOMMENDED to | |||
include at least one User ID with a self-signature in v4 keys. | include at least one User ID with a self-signature in version 4 keys. | |||
For version 6 keys, it is RECOMMENDED to store information about the | For version 6 keys, it is RECOMMENDED to store information about the | |||
primary Public Key as well as the Transferable Public Key as a whole | primary Public Key as well as the Transferable Public Key as a whole | |||
(key flags, key expiration, features, algorithm preferences, etc.) in | (key flags, key expiration, features, algorithm preferences, etc.) in | |||
a Direct Key signature (Type ID 0x1F) over the Public Key, instead of | a Direct Key signature (Type ID 0x1F) over the Public Key, instead of | |||
placing that information in a User ID self-signature. An | placing that information in a User ID self-signature. An | |||
implementation MUST ensure that a valid Direct Key signature is | implementation MUST ensure that a valid Direct Key signature is | |||
present before using a v6 key. This prevents certain attacks where | present before using a version 6 key. This prevents certain attacks | |||
an adversary strips a self-signature specifying a Key Expiration Time | where an adversary strips a self-signature specifying a Key | |||
or certain preferences. | Expiration Time or certain preferences. | |||
An implementation SHOULD NOT require a User ID self-signature to be | An implementation SHOULD NOT require a User ID self-signature to be | |||
present in order to consume or use a key, unless the particular use | present in order to consume or use a key, unless the particular use | |||
is contingent on the keyholder identifying themselves with the | is contingent on the keyholder identifying themselves with the | |||
textual label in the User ID. For example, when refreshing a key to | textual label in the User ID. For example, when refreshing a key to | |||
learn about changes in expiration, advertised features, algorithm | learn about changes in expiration, advertised features, algorithm | |||
preferences, revocation, subkey rotation, and so forth, there is no | preferences, revocation, subkey rotation, and so forth, there is no | |||
need to require a User ID self-signature. On the other hand, when | need to require a User ID self-signature. On the other hand, when | |||
verifying a signature over an email message, an implementation MAY | verifying a signature over an email message, an implementation MAY | |||
choose to only accept a signature from a key that has a valid self- | choose to only accept a signature from a key that has a valid self- | |||
skipping to change at line 2175 ¶ | skipping to change at line 2173 ¶ | |||
zero, the key never expires. This is found only on a self-signature. | zero, the key never expires. This is found only on a self-signature. | |||
When an implementation generates this subpacket, it SHOULD be marked | When an implementation generates this subpacket, it SHOULD be marked | |||
as critical. | as critical. | |||
5.2.3.14. Preferred Symmetric Ciphers for v1 SEIPD | 5.2.3.14. Preferred Symmetric Ciphers for v1 SEIPD | |||
(array of 1-octet values) | (array of 1-octet values) | |||
A series of Symmetric Cipher Algorithm IDs indicating how the | A series of Symmetric Cipher Algorithm IDs indicating how the | |||
keyholder prefers to receive Symmetrically Encrypted and Integrity | keyholder prefers to receive the Version 1 Symmetrically Encrypted | |||
Protected Data packet version 1 (Section 5.13.1). The subpacket body | and Integrity Protected Data packet (Section 5.13.1). The subpacket | |||
is an ordered list of octets with the most preferred listed first. | body is an ordered list of octets with the most preferred listed | |||
It is assumed that only the algorithms listed are supported by the | first. It is assumed that only the algorithms listed are supported | |||
recipient's implementation. Algorithm IDs are defined in | by the recipient's implementation. Algorithm IDs are defined in | |||
Section 9.3. This is only found on a self-signature. | Section 9.3. This is only found on a self-signature. | |||
When generating a v2 SEIPD packet, this preference list is not | When generating a v2 SEIPD packet, this preference list is not | |||
relevant. See Section 5.2.3.15 instead. | relevant. See Section 5.2.3.15 instead. | |||
5.2.3.15. Preferred AEAD Ciphersuites | 5.2.3.15. Preferred AEAD Ciphersuites | |||
(array of pairs of octets indicating Symmetric Cipher and AEAD | (array of pairs of octets indicating Symmetric Cipher and AEAD | |||
algorithms) | algorithms) | |||
A series of paired algorithm IDs indicating how the keyholder prefers | A series of paired algorithm IDs indicating how the keyholder prefers | |||
to receive Symmetrically Encrypted and Integrity Protected Data | to receive the Version 2 Symmetrically Encrypted and Integrity | |||
packet version 2 (Section 5.13.2). Each pair of octets indicates a | Protected Data packet (Section 5.13.2). Each pair of octets | |||
combination of a symmetric cipher and an AEAD mode that the keyholder | indicates a combination of a symmetric cipher and an AEAD mode that | |||
prefers to use. The Symmetric Cipher Algorithm ID precedes the AEAD | the keyholder prefers to use. The Symmetric Cipher Algorithm ID | |||
algorithm ID in each pair. The subpacket body is an ordered list of | precedes the AEAD algorithm ID in each pair. The subpacket body is | |||
pairs of octets with the most preferred algorithm combination listed | an ordered list of pairs of octets with the most preferred algorithm | |||
first. | combination listed first. | |||
It is assumed that only the combinations of algorithms listed are | It is assumed that only the combinations of algorithms listed are | |||
supported by the recipient's implementation, with the exception of | supported by the recipient's implementation, with the exception of | |||
the mandatory-to-implement combination of AES-128 and OCB. If | the mandatory-to-implement combination of AES-128 and OCB. If | |||
AES-128 and OCB are not found in the subpacket, it is implicitly | AES-128 and OCB are not found in the subpacket, it is implicitly | |||
listed at the end. | listed at the end. | |||
AEAD algorithm IDs are listed in Section 9.6. Symmetric Cipher | AEAD algorithm IDs are listed in Section 9.6. Symmetric Cipher | |||
Algorithm IDs are listed in Section 9.3. | Algorithm IDs are listed in Section 9.3. | |||
For example, a subpacket containing the six octets | For example, a subpacket containing the six octets | |||
09 02 09 03 13 02 | 09 02 09 03 13 02 | |||
indicates that the keyholder prefers to receive v2 SEIPD using | indicates that the keyholder prefers to receive v2 SEIPD using | |||
AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB, | AES-256 with OCB, then AES-256 with GCM, then Camellia-256 with OCB, | |||
and finally the implicit AES-128 with OCB. | and finally the implicit AES-128 with OCB. | |||
Note that support for the Symmetrically Encrypted and Integrity | Note that support for the Version 2 Symmetrically Encrypted and | |||
Protected Data packet version 2 (Section 5.13.2) in general is | Integrity Protected Data packet (Section 5.13.2) in general is | |||
indicated by a Features Flag (Section 5.2.3.32). | indicated by a Features Flag (Section 5.2.3.32). | |||
This subpacket is only found on a self-signature. | This subpacket is only found on a self-signature. | |||
When generating a v1 SEIPD packet, this preference list is not | When generating a v1 SEIPD packet, this preference list is not | |||
relevant. See Section 5.2.3.14 instead. | relevant. See Section 5.2.3.14 instead. | |||
5.2.3.16. Preferred Hash Algorithms | 5.2.3.16. Preferred Hash Algorithms | |||
(array of 1-octet values) | (array of 1-octet values) | |||
skipping to change at line 2347 ¶ | skipping to change at line 2345 ¶ | |||
this octet; if it is not present, it MUST reject the subpacket (i.e., | this octet; if it is not present, it MUST reject the subpacket (i.e., | |||
ignore the subpacket if it's non-critical and reject the signature if | ignore the subpacket if it's non-critical and reject the signature if | |||
it's critical). When an implementation generates a Regular | it's critical). When an implementation generates a Regular | |||
Expression subpacket, it MUST include the null terminator. | Expression subpacket, it MUST include the null terminator. | |||
When generating this subpacket, it SHOULD be marked as critical. | When generating this subpacket, it SHOULD be marked as critical. | |||
5.2.3.23. Revocation Key (Deprecated) | 5.2.3.23. Revocation Key (Deprecated) | |||
(1 octet of class, 1 octet of public key algorithm ID, 20 octets of | (1 octet of class, 1 octet of public key algorithm ID, 20 octets of | |||
v4 fingerprint) | version 4 fingerprint) | |||
This mechanism is deprecated. Applications MUST NOT generate such a | This mechanism is deprecated. Applications MUST NOT generate such a | |||
subpacket. | subpacket. | |||
An application that wants the functionality of delegating revocation | An application that wants the functionality of delegating revocation | |||
can use an escrowed Revocation Signature. See Section 13.9 for more | can use an escrowed Revocation Signature. See Section 13.9 for more | |||
details. | details. | |||
The remainder of this section describes how some implementations | The remainder of this section describes how some implementations | |||
attempt to interpret this deprecated subpacket. | attempt to interpret this deprecated subpacket. | |||
skipping to change at line 2508 ¶ | skipping to change at line 2506 ¶ | |||
This subpacket contains a list of binary flags that hold information | This subpacket contains a list of binary flags that hold information | |||
about a key. It is a string of octets, and an implementation MUST | about a key. It is a string of octets, and an implementation MUST | |||
NOT assume a fixed size, so that it can grow over time. If a list is | NOT assume a fixed size, so that it can grow over time. If a list is | |||
shorter than an implementation expects, the unstated flags are | shorter than an implementation expects, the unstated flags are | |||
considered to be zero. The defined flags are as follows: | considered to be zero. The defined flags are as follows: | |||
+===========+======================================================+ | +===========+======================================================+ | |||
| Flag | Definition | | | Flag | Definition | | |||
+===========+======================================================+ | +===========+======================================================+ | |||
| 0x01... | This key may be used to make User ID certifications | | | 0x01... | This key may be used to make User ID certifications | | |||
| | (signature Type IDs 0x10-0x13) or Direct Key | | | | (Signature Type IDs 0x10-0x13) or Direct Key | | |||
| | signatures (signature Type ID 0x1F) over other keys. | | | | signatures (Signature Type ID 0x1F) over other keys. | | |||
+-----------+------------------------------------------------------+ | +-----------+------------------------------------------------------+ | |||
| 0x02... | This key may be used to sign data. | | | 0x02... | This key may be used to sign data. | | |||
+-----------+------------------------------------------------------+ | +-----------+------------------------------------------------------+ | |||
| 0x04... | This key may be used to encrypt communications. | | | 0x04... | This key may be used to encrypt communications. | | |||
+-----------+------------------------------------------------------+ | +-----------+------------------------------------------------------+ | |||
| 0x08... | This key may be used to encrypt storage. | | | 0x08... | This key may be used to encrypt storage. | | |||
+-----------+------------------------------------------------------+ | +-----------+------------------------------------------------------+ | |||
| 0x10... | The private component of this key may have been | | | 0x10... | The private component of this key may have been | | |||
| | split by a secret-sharing mechanism. | | | | split by a secret-sharing mechanism. | | |||
+-----------+------------------------------------------------------+ | +-----------+------------------------------------------------------+ | |||
skipping to change at line 2579 ¶ | skipping to change at line 2577 ¶ | |||
(1 octet of revocation code, N octets of reason string) | (1 octet of revocation code, N octets of reason string) | |||
This subpacket is used only in Key Revocation and Certification | This subpacket is used only in Key Revocation and Certification | |||
Revocation signatures. It describes the reason why the key or | Revocation signatures. It describes the reason why the key or | |||
certification was revoked. | certification was revoked. | |||
The first octet contains a machine-readable code that denotes the | The first octet contains a machine-readable code that denotes the | |||
reason for the revocation: | reason for the revocation: | |||
+=========+==================================+ | +=========+========================================+ | |||
| Code | Reason | | | Code | Reason | | |||
+=========+==================================+ | +=========+========================================+ | |||
| 0 | No reason specified (key | | | 0 | No reason specified (Key Revocation or | | |||
| | revocations or cert revocations) | | | | Certificate Revocation signatures) | | |||
+---------+----------------------------------+ | +---------+----------------------------------------+ | |||
| 1 | Key is superseded (key | | | 1 | Key is superseded (Key Revocation | | |||
| | revocations) | | | | signatures) | | |||
+---------+----------------------------------+ | +---------+----------------------------------------+ | |||
| 2 | Key material has been | | | 2 | Key material has been compromised (Key | | |||
| | compromised (key revocations) | | | | Revocation signatures) | | |||
+---------+----------------------------------+ | +---------+----------------------------------------+ | |||
| 3 | Key is retired and no longer | | | 3 | Key is retired and no longer used (Key | | |||
| | used (key revocations) | | | | Revocation signatures) | | |||
+---------+----------------------------------+ | +---------+----------------------------------------+ | |||
| 32 | User ID information is no longer | | | 32 | User ID information is no longer valid | | |||
| | valid (cert revocations) | | | | (Certification Revocation signatures) | | |||
+---------+----------------------------------+ | +---------+----------------------------------------+ | |||
| 100-110 | Private Use | | | 100-110 | Private Use | | |||
+---------+----------------------------------+ | +---------+----------------------------------------+ | |||
Table 10: OpenPGP Reason for Revocation | Table 10: OpenPGP Reason for Revocation | |||
(Revocation Octet) Registry | (Revocation Octet) Registry | |||
Following the revocation code is a string of octets that gives | Following the revocation code is a string of octets that gives | |||
information about the Reason for Revocation in human-readable form | information about the Reason for Revocation in human-readable form | |||
(UTF-8). The string may be null (of zero length). The length of the | (UTF-8). The string may be null (of zero length). The length of the | |||
subpacket is the length of the reason string plus one. An | subpacket is the length of the reason string plus one. An | |||
implementation SHOULD implement this subpacket, include it in all | implementation SHOULD implement this subpacket, include it in all | |||
Revocation Signatures, and interpret revocations appropriately. | Revocation Signatures, and interpret revocations appropriately. | |||
skipping to change at line 2648 ¶ | skipping to change at line 2646 ¶ | |||
An implementation SHOULD NOT use a feature listed when sending to a | An implementation SHOULD NOT use a feature listed when sending to a | |||
user who does not state that they can use it, unless the | user who does not state that they can use it, unless the | |||
implementation can infer support for the feature from another | implementation can infer support for the feature from another | |||
implementation-dependent mechanism. | implementation-dependent mechanism. | |||
Defined features are as follows: | Defined features are as follows: | |||
First octet: | First octet: | |||
+=========+=======================================+===========+ | +=========+=====================================+===========+ | |||
| Feature | Definition | Reference | | | Feature | Definition | Reference | | |||
+=========+=======================================+===========+ | +=========+=====================================+===========+ | |||
| 0x01... | Symmetrically Encrypted and Integrity | Section | | | 0x01... | Version 1 Symmetrically Encrypted | Section | | |||
| | Protected Data packet version 1 | 5.13.1 | | | | and Integrity Protected Data packet | 5.13.1 | | |||
+---------+---------------------------------------+-----------+ | +---------+-------------------------------------+-----------+ | |||
| 0x02... | Reserved | | | | 0x02... | Reserved | | | |||
+---------+---------------------------------------+-----------+ | +---------+-------------------------------------+-----------+ | |||
| 0x04... | Reserved | | | | 0x04... | Reserved | | | |||
+---------+---------------------------------------+-----------+ | +---------+-------------------------------------+-----------+ | |||
| 0x08... | Symmetrically Encrypted and Integrity | Section | | | 0x08... | Version 2 Symmetrically Encrypted | Section | | |||
| | Protected Data packet version 2 | 5.13.2 | | | | and Integrity Protected Data packet | 5.13.2 | | |||
+---------+---------------------------------------+-----------+ | +---------+-------------------------------------+-----------+ | |||
Table 11: OpenPGP Features Flags Registry | Table 11: OpenPGP Features Flags Registry | |||
If an implementation implements any of the defined features, it | If an implementation implements any of the defined features, it | |||
SHOULD implement the Features subpacket, too. | SHOULD implement the Features subpacket, too. | |||
See Section 13.7 for details about how to use the Features subpacket | See Section 13.7 for details about how to use the Features subpacket | |||
when generating encryption data. | when generating encryption data. | |||
5.2.3.33. Signature Target | 5.2.3.33. Signature Target | |||
skipping to change at line 2700 ¶ | skipping to change at line 2698 ¶ | |||
in Section 5.2. It is useful when one signature needs to refer to, | in Section 5.2. It is useful when one signature needs to refer to, | |||
or be incorporated in, another signature. | or be incorporated in, another signature. | |||
5.2.3.35. Issuer Fingerprint | 5.2.3.35. Issuer Fingerprint | |||
(1 octet key version number, N octets of fingerprint) | (1 octet key version number, N octets of fingerprint) | |||
The OpenPGP Key fingerprint of the key issuing the signature. This | The OpenPGP Key fingerprint of the key issuing the signature. This | |||
subpacket SHOULD be included in all signatures. If the version of | subpacket SHOULD be included in all signatures. If the version of | |||
the issuing key is 4 and an Issuer Key ID subpacket | the issuing key is 4 and an Issuer Key ID subpacket | |||
(Section 5.2.3.12) is also included in the signature, the key ID of | (Section 5.2.3.12) is also included in the signature, the Key ID of | |||
the Issuer Key ID subpacket MUST match the low 64 bits of the | the Issuer Key ID subpacket MUST match the low 64 bits of the | |||
fingerprint. | fingerprint. | |||
Note that the length N of the fingerprint for a version 4 key is 20 | Note that the length N of the fingerprint for a version 4 key is 20 | |||
octets; for a version 6 key, N is 32. Since the version of the | octets; for a version 6 key, N is 32. Since the version of the | |||
signature is bound to the version of the key, the version octet here | signature is bound to the version of the key, the version octet here | |||
MUST match the version of the signature. If the version octet does | MUST match the version of the signature. If the version octet does | |||
not match the signature version, the receiving implementation MUST | not match the signature version, the receiving implementation MUST | |||
treat it as a malformed signature (see Section 5.2.5). | treat it as a malformed signature (see Section 5.2.5). | |||
skipping to change at line 2728 ¶ | skipping to change at line 2726 ¶ | |||
key it was encrypted to is one of the indicated primary keys or one | 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 | of their subkeys. This can be used to prevent forwarding a signature | |||
outside of its intended, encrypted context (see Section 13.12). | outside of its intended, encrypted context (see Section 13.12). | |||
Note that the length N of the fingerprint for a version 4 key is 20 | Note that the length N of the fingerprint for a version 4 key is 20 | |||
octets; for a version 6 key, N is 32. | octets; for a version 6 key, N is 32. | |||
An implementation SHOULD generate this subpacket when creating a | An implementation SHOULD generate this subpacket when creating a | |||
signed and encrypted message. | signed and encrypted message. | |||
When generating this subpacket in a v6 signature, it SHOULD be marked | When generating this subpacket in a version 6 signature, it SHOULD be | |||
as critical. | marked as critical. | |||
5.2.4. Computing Signatures | 5.2.4. Computing Signatures | |||
All signatures are formed by producing a hash over the signature data | All signatures are formed by producing a hash over the signature data | |||
and then using the resulting hash in the signature algorithm. | and then using the resulting hash in the signature algorithm. | |||
When creating or verifying a version 6 signature, the salt is fed | When creating or verifying a version 6 signature, the salt is fed | |||
into the hash context before any other data. | into the hash context before any other data. | |||
For binary document signatures (Type ID 0x00), the document data is | For binary document signatures (Type ID 0x00), the document data is | |||
skipping to change at line 2831 ¶ | skipping to change at line 2829 ¶ | |||
5.2.4.1. Notes about Signature Computation | 5.2.4.1. Notes about Signature Computation | |||
The data actually hashed by OpenPGP varies depending on the signature | The data actually hashed by OpenPGP varies depending on the signature | |||
version, in order to ensure that a signature made using one version | version, in order to ensure that a signature made using one version | |||
cannot be repurposed as a signature with a different version over | cannot be repurposed as a signature with a different version over | |||
subtly different data. The hashed data streams differ based on their | subtly different data. The hashed data streams differ based on their | |||
trailer, most critically in the fifth and sixth octets from the end | trailer, most critically in the fifth and sixth octets from the end | |||
of the stream. In particular: | of the stream. In particular: | |||
* A version 3 signature uses the fifth octet from the end to store | * A version 3 signature uses the fifth octet from the end to store | |||
its signature Type ID. This MUST NOT be signature Type ID 0xFF. | its Signature Type ID. This MUST NOT be Signature Type ID 0xFF. | |||
* All signature versions later than version 3 always use a literal | * All signature versions later than version 3 always use a literal | |||
0xFF in the fifth octet from the end. For these later signature | 0xFF in the fifth octet from the end. For these later signature | |||
versions, the sixth octet from the end (the octet before the 0xFF) | versions, the sixth octet from the end (the octet before the 0xFF) | |||
stores the signature version number. | stores the signature version number. | |||
5.2.5. Malformed and Unknown Signatures | 5.2.5. Malformed and Unknown Signatures | |||
In some cases, a Signature packet (or its corresponding One-Pass | In some cases, a Signature packet (or its corresponding One-Pass | |||
Signature packet; see Section 5.4) may be malformed or unknown. For | Signature packet; see Section 5.4) may be malformed or unknown. For | |||
skipping to change at line 2867 ¶ | skipping to change at line 2865 ¶ | |||
Signature packet itself | Signature packet itself | |||
* A hash algorithm known to be weak (e.g., MD5) | * A hash algorithm known to be weak (e.g., MD5) | |||
* A mismatch between the expected salt length of the hash algorithm | * A mismatch between the expected salt length of the hash algorithm | |||
and the actual salt length | and the actual salt length | |||
* A mismatch between the One-Pass Signature version and the | * A mismatch between the One-Pass Signature version and the | |||
Signature version (see Section 10.3.2.2) | Signature version (see Section 10.3.2.2) | |||
* A signature with a version other than 6, made by a v6 key | * A signature with a version other than 6, made by a version 6 key | |||
When an implementation encounters such a malformed or unknown | When an implementation encounters such a malformed or unknown | |||
signature, it MUST ignore the signature for validation purposes. It | signature, it MUST ignore the signature for validation purposes. It | |||
MUST NOT indicate a successful signature validation for such a | MUST NOT indicate a successful signature validation for such a | |||
signature. At the same time, it MUST NOT halt processing on the | signature. At the same time, it MUST NOT halt processing on the | |||
packet stream or reject other signatures in the same packet stream | packet stream or reject other signatures in the same packet stream | |||
just because an unknown or invalid signature exists. | just because an unknown or invalid signature exists. | |||
This requirement is necessary for forward compatibility. Producing | This requirement is necessary for forward compatibility. Producing | |||
an output that indicates that no successful signatures were found is | an output that indicates that no successful signatures were found is | |||
skipping to change at line 2910 ¶ | skipping to change at line 2908 ¶ | |||
are 4 and 6. The remainder of the packet depends on the version. | are 4 and 6. The remainder of the packet depends on the version. | |||
The versions differ in how they encrypt the session key with the | The versions differ in how they encrypt the session key with the | |||
passphrase and in what they encode. The version of the SKESK packet | passphrase and in what they encode. The version of the SKESK packet | |||
must align with the version of the SEIPD packet (see | must align with the version of the SEIPD packet (see | |||
Section 10.3.2.1). Any new version of the SKESK packet should be | Section 10.3.2.1). Any new version of the SKESK packet should be | |||
registered in the registry established in Section 10.3.2.1. | registered in the registry established in Section 10.3.2.1. | |||
5.3.1. Version 4 Symmetric Key Encrypted Session Key Packet Format | 5.3.1. Version 4 Symmetric Key Encrypted Session Key Packet Format | |||
A version 4 SKESK packet precedes a v1 SEIPD (see Section 5.13.1). | A v4 SKESK packet precedes a v1 SEIPD (see Section 5.13.1). In | |||
In historic data, it is sometimes found preceding a deprecated SED | historic data, it is sometimes found preceding a deprecated SED | |||
packet (see Section 5.7). A v4 SKESK packet MUST NOT precede a v2 | packet (see Section 5.7). A v4 SKESK packet MUST NOT precede a v2 | |||
SEIPD packet (see Section 10.3.2.1). | SEIPD packet (see Section 10.3.2.1). | |||
A version 4 Symmetric Key Encrypted Session Key packet consists of: | A version 4 Symmetric Key Encrypted Session Key packet consists of: | |||
* A 1-octet version number with value 4. | * A 1-octet version number with value 4. | |||
* A 1-octet number describing the symmetric algorithm used. | * A 1-octet number describing the symmetric algorithm used. | |||
* An S2K Specifier Type. The length of the S2K Specifier Type | * An S2K Specifier. The length of the S2K Specifier depends on its | |||
depends on its type (see Section 3.7.1). | type (see Section 3.7.1). | |||
* Optionally, the encrypted session key itself, which is decrypted | * Optionally, the encrypted session key itself, which is decrypted | |||
with the S2K object. | with the S2K object. | |||
If the encrypted session key is not present (which can be detected on | If the encrypted session key is not present (which can be detected on | |||
the basis of packet length and S2K Specifier Type size), then the S2K | the basis of packet length and S2K Specifier size), then the S2K | |||
algorithm applied to the passphrase produces the session key for | algorithm applied to the passphrase produces the session key for | |||
decrypting the message, using the Symmetric Cipher Algorithm ID from | decrypting the message, using the Symmetric Cipher Algorithm ID from | |||
the Symmetric Key Encrypted Session Key packet. | the Symmetric Key Encrypted Session Key packet. | |||
If the encrypted session key is present, the result of applying the | If the encrypted session key is present, the result of applying the | |||
S2K algorithm to the passphrase is used to decrypt just that | S2K algorithm to the passphrase is used to decrypt just that | |||
encrypted session key field, using CFB mode with an IV of all zeros. | encrypted session key field, using CFB mode with an IV of all zeros. | |||
The decryption result consists of a 1-octet algorithm identifier that | The decryption result consists of a 1-octet algorithm identifier that | |||
specifies the symmetric key encryption algorithm used to encrypt the | specifies the symmetric key encryption algorithm used to encrypt the | |||
following encryption container, followed by the session key octets | following encryption container, followed by the session key octets | |||
themselves. | themselves. | |||
Note: because an all-zero IV is used for this decryption, the S2K | Note: because an all-zero IV is used for this decryption, the S2K | |||
Specifier Type MUST use a salt value, a Salted S2K, an Iterated and | Specifier MUST use a salt value, a Salted S2K, an Iterated and Salted | |||
Salted S2K, or Argon2. The salt value will ensure that the | S2K, or Argon2. The salt value will ensure that the decryption key | |||
decryption key is not repeated even if the passphrase is reused. | is not repeated even if the passphrase is reused. | |||
5.3.2. Version 6 Symmetric Key Encrypted Session Key Packet Format | 5.3.2. Version 6 Symmetric Key Encrypted Session Key Packet Format | |||
A version 6 SKESK packet precedes a v2 SEIPD packet (see | A v6 SKESK packet precedes a v2 SEIPD packet (see Section 5.13.2). A | |||
Section 5.13.2). A v6 SKESK packet MUST NOT precede a v1 SEIPD | v6 SKESK packet MUST NOT precede a v1 SEIPD packet or a deprecated | |||
packet or a deprecated Symmetrically Encrypted Data packet (see | Symmetrically Encrypted Data packet (see Section 10.3.2.1). | |||
Section 10.3.2.1). | ||||
A version 6 Symmetric Key Encrypted Session Key packet consists of: | A version 6 Symmetric Key Encrypted Session Key packet consists of: | |||
* A 1-octet version number with value 6. | * A 1-octet version number with value 6. | |||
* A 1-octet scalar octet count for the 5 fields following this | * A 1-octet scalar octet count for the 5 fields following this | |||
octet. | octet. | |||
* A 1-octet Symmetric Cipher Algorithm ID (from Table 21). | * A 1-octet Symmetric Cipher Algorithm ID (from Table 21). | |||
* A 1-octet AEAD algorithm identifier (from Table 25). | * A 1-octet AEAD algorithm identifier (from Table 25). | |||
* A 1-octet scalar octet count of the following field. | * A 1-octet scalar octet count of the following field. | |||
* An S2K Specifier Type. The length of the S2K Specifier Type | * An S2K Specifier. The length of the S2K Specifier depends on its | |||
depends on its type (see Section 3.7.1). | type (see Section 3.7.1). | |||
* A starting IV of the size specified by the AEAD algorithm. | * A starting IV of the size specified by the AEAD algorithm. | |||
* The encrypted session key itself. | * The encrypted session key itself. | |||
* An authentication tag for the AEAD mode. | * An authentication tag for the AEAD mode. | |||
A key-encryption key (KEK) is derived using HKDF [RFC5869] with | A key-encryption key (KEK) is derived using HKDF [RFC5869] with | |||
SHA256 [RFC6234] as the hash algorithm. The Initial Keying Material | SHA256 [RFC6234] as the hash algorithm. The Initial Keying Material | |||
(IKM) for HKDF is the key derived from S2K. No salt is used. The | (IKM) for HKDF is the key derived from S2K. No salt is used. The | |||
info parameter is comprised of the Packet Type ID in OpenPGP format | info parameter is comprised of the Packet Type ID in OpenPGP format | |||
encoding (bits 7 and 6 are set, and bits 5-0 carry the Packet Type | encoding (bits 7 and 6 are set, and bits 5-0 carry the Packet Type | |||
ID), the packet version, and the cipher-algo and AEAD-mode used to | ID), the packet version, and the cipher-algo and AEAD-mode used to | |||
encrypt the key material. | encrypt the key material. | |||
Then, the session key is encrypted using the resulting key, with the | Then, the session key is encrypted using the resulting key, with the | |||
AEAD algorithm specified for the Symmetrically Encrypted and | AEAD algorithm specified for the Version 2 Symmetrically Encrypted | |||
Integrity Protected Data packet version 2. Note that no chunks are | and Integrity Protected Data packet. Note that no chunks are used | |||
used and that there is only one authentication tag. The Packet Type | and that there is only one authentication tag. The Packet Type ID | |||
ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 | encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 carry | |||
carry the Packet Type ID), the packet version number, the cipher | the Packet Type ID), the packet version number, the cipher algorithm | |||
algorithm ID, and the AEAD algorithm ID are given as additional data. | ID, and the AEAD algorithm ID are given as additional data. For | |||
For example, the additional data used with AES-128 with OCB consists | example, the additional data used with AES-128 with OCB consists of | |||
of the octets 0xC3, 0x06, 0x07, and 0x02. | the octets 0xC3, 0x06, 0x07, and 0x02. | |||
5.4. One-Pass Signature Packet (Type ID 4) | 5.4. One-Pass Signature Packet (Type ID 4) | |||
The One-Pass Signature packet precedes the signed data and contains | The One-Pass Signature packet precedes the signed data and contains | |||
enough information to allow the receiver to begin calculating any | enough information to allow the receiver to begin calculating any | |||
hashes needed to verify the signature. It allows the Signature | hashes needed to verify the signature. It allows the Signature | |||
packet to be placed at the end of the message so that the signer can | packet to be placed at the end of the message so that the signer can | |||
compute the entire signed message in one pass. | compute the entire signed message in one pass. | |||
The body of this packet consists of: | The body of this packet consists of: | |||
* A 1-octet version number. The currently defined versions are 3 | * A 1-octet version number. The currently defined versions are 3 | |||
and 6. Any new One-Pass Signature packet version should be | and 6. Any new One-Pass Signature packet version should be | |||
registered in the registry established in Section 10.3.2.2. | registered in the registry established in Section 10.3.2.2. | |||
* A 1-octet signature Type ID. Signature types are described in | * A 1-octet Signature Type ID. Signature types are described in | |||
Section 5.2.1. | Section 5.2.1. | |||
* A 1-octet number describing the hash algorithm used. | * A 1-octet number describing the hash algorithm used. | |||
* A 1-octet number describing the public key algorithm used. | * A 1-octet number describing the public key algorithm used. | |||
* Only for v6 packets, a variable-length field containing: | * Only for version 6 packets, a variable-length field containing: | |||
- A 1-octet salt size. The value MUST match the value defined | - A 1-octet salt size. The value MUST match the value defined | |||
for the hash algorithm as specified in Table 23. | for the hash algorithm as specified in Table 23. | |||
- The salt; a random value of the specified size. The value MUST | - The salt; a random value of the specified size. The value MUST | |||
match the salt field of the corresponding Signature packet. | match the salt field of the corresponding Signature packet. | |||
* Only for v3 packets, an 8-octet number holding the Key ID of the | * Only for v3 packets, an 8-octet number holding the Key ID of the | |||
signing key. | signing key. | |||
* Only for v6 packets, 32 octets of the fingerprint of the signing | * Only for version 6 packets, 32 octets of the fingerprint of the | |||
key. Since a v6 signature can only be made by a v6 key, the | signing key. Since a version 6 signature can only be made by a | |||
length of the fingerprint is fixed. | version 6 key, the length of the fingerprint is fixed. | |||
* A 1-octet number holding a flag showing whether the signature is | * A 1-octet number holding a flag showing whether the signature is | |||
nested. A zero value indicates that the next packet is another | nested. A zero value indicates that the next packet is another | |||
One-Pass Signature packet that describes another signature to be | One-Pass Signature packet that describes another signature to be | |||
applied to the same message data. | applied to the same message data. | |||
When generating a one-pass signature, the OPS packet version MUST | When generating a one-pass signature, the OPS packet version MUST | |||
correspond to the version of the associated Signature packet, except | correspond to the version of the associated Signature packet, except | |||
for the historical accident that v4 keys use a v3 One-Pass Signature | for the historical accident that version 4 keys use a version 3 One- | |||
packet (there is no v4 OPS). See Section 10.3.2.2 for the full | Pass Signature packet (there is no version 4 OPS). See | |||
correspondence of versions between Keys, Signatures, and One-Pass | Section 10.3.2.2 for the full correspondence of versions between | |||
Signatures. | Keys, Signatures, and One-Pass Signatures. | |||
Note that if a message contains more than one one-pass signature, | Note that if a message contains more than one one-pass signature, | |||
then the Signature packets bracket the message; that is, the first | then the Signature packets bracket the message; that is, the first | |||
Signature packet after the message corresponds to the last One-Pass | Signature packet after the message corresponds to the last One-Pass | |||
Signature packet and the final Signature packet corresponds to the | Signature packet and the final Signature packet corresponds to the | |||
first One-Pass Signature packet. | first One-Pass Signature packet. | |||
5.5. Key Material Packets | 5.5. Key Material Packets | |||
A key material packet contains all the information about a public or | A key material packet contains all the information about a public or | |||
skipping to change at line 3186 ¶ | skipping to change at line 3183 ¶ | |||
specific secret key data appended, usually in encrypted form. | specific secret key data appended, usually in encrypted form. | |||
The packet contains: | The packet contains: | |||
* The fields of a Public Key or Public Subkey packet, as described | * The fields of a Public Key or Public Subkey packet, as described | |||
above. | above. | |||
* One octet (the "S2K usage octet") indicating whether and how the | * One octet (the "S2K usage octet") indicating whether and how the | |||
secret key material is protected by a passphrase. Zero indicates | secret key material is protected by a passphrase. Zero indicates | |||
that the secret key data is not encrypted. 253 (AEAD), 254 (CFB), | that the secret key data is not encrypted. 253 (AEAD), 254 (CFB), | |||
or 255 (MalleableCFB) indicates that an S2K Specifier Type and | or 255 (MalleableCFB) indicates that an S2K Specifier and other | |||
other parameters will follow. Any other value is a symmetric key | parameters will follow. Any other value is a symmetric key | |||
encryption algorithm identifier. A version 6 packet MUST NOT use | encryption algorithm identifier. A version 6 packet MUST NOT use | |||
the value 255 (MalleableCFB). | the value 255 (MalleableCFB). | |||
* Only for a version 6 packet where the secret key material is | * Only for a version 6 packet where the secret key material is | |||
encrypted (that is, where the previous octet is not zero), a | encrypted (that is, where the previous octet is not zero), a | |||
1-octet scalar octet count of the cumulative length of all the | 1-octet scalar octet count of the cumulative length of all the | |||
following conditionally included S2K parameter fields. | following conditionally included S2K parameter fields. | |||
* Conditionally included S2K parameter fields: | * Conditionally included S2K parameter fields: | |||
- If the S2K usage octet was 253, 254, or 255, a 1-octet | - If the S2K usage octet was 253, 254, or 255, a 1-octet | |||
symmetric key encryption algorithm. | symmetric key encryption algorithm. | |||
- If the S2K usage octet was 253 (AEAD), a 1-octet AEAD | - If the S2K usage octet was 253 (AEAD), a 1-octet AEAD | |||
algorithm. | algorithm. | |||
- Only for a version 6 packet, and if the S2K usage octet was 253 | - Only for a version 6 packet, and if the S2K usage octet was 253 | |||
or 254, a 1-octet count of the size of the one field following | or 254, a 1-octet count of the size of the one field following | |||
this octet. | this octet. | |||
- If the S2K usage octet was 253, 254, or 255, an S2K Specifier | - If the S2K usage octet was 253, 254, or 255, an S2K Specifier. | |||
Type. The length of the S2K Specifier Type depends on its type | The length of the S2K Specifier depends on its type (see | |||
(see Section 3.7.1). | Section 3.7.1). | |||
- If the S2K usage octet was 253 (AEAD), an IV of a size | - If the S2K usage octet was 253 (AEAD), an IV of a size | |||
specified by the AEAD algorithm (see Section 5.13.2), which is | specified by the AEAD algorithm (see Section 5.13.2), which is | |||
used as the nonce for the AEAD algorithm. | used as the nonce for the AEAD algorithm. | |||
- If the S2K usage octet was 254, 255, or a cipher algorithm ID | - If the S2K usage octet was 254, 255, or a cipher algorithm ID | |||
(that is, the secret data uses some form of CFB encryption), an | (that is, the secret data uses some form of CFB encryption), an | |||
IV of the same length as the cipher's block size. | IV of the same length as the cipher's block size. | |||
* Plain or encrypted multiprecision integers comprising the secret | * Plain or encrypted multiprecision integers comprising the secret | |||
skipping to change at line 3244 ¶ | skipping to change at line 3241 ¶ | |||
zero, a 2-octet checksum of the algorithm-specific portion (sum of | zero, a 2-octet checksum of the algorithm-specific portion (sum of | |||
all octets, mod 65536). | all octets, mod 65536). | |||
The details about storing algorithm-specific secrets above are | The details about storing algorithm-specific secrets above are | |||
summarized in Table 2. | summarized in Table 2. | |||
Note that the version 6 packet format adds two count values to help | Note that the version 6 packet format adds two count values to help | |||
parsing packets with unknown S2K or public key algorithms. | parsing packets with unknown S2K or public key algorithms. | |||
Secret MPI values can be encrypted using a passphrase. If an S2K | Secret MPI values can be encrypted using a passphrase. If an S2K | |||
Specifier Type is given, it describes the algorithm for converting | Specifier is given, it describes the algorithm for converting the | |||
the passphrase to a key; otherwise, a simple MD5 hash of the | passphrase to a key; otherwise, a simple MD5 hash of the passphrase | |||
passphrase is used. An implementation producing a passphrase- | is used. An implementation producing a passphrase-protected Secret | |||
protected Secret Key packet MUST use an S2K Specifier Type; the | Key packet MUST use an S2K Specifier; the simple hash is for read- | |||
simple hash is for read-only backward compatibility, though | only backward compatibility, though implementations MAY continue to | |||
implementations MAY continue to use existing private keys in the old | use existing private keys in the old format. The cipher for | |||
format. The cipher for encrypting the MPIs is specified in the | encrypting the MPIs is specified in the Secret Key packet. | |||
Secret Key packet. | ||||
Encryption/decryption of the secret data is done using the key | Encryption/decryption of the secret data is done using the key | |||
created from the passphrase and the IV from the packet. If the S2K | created 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 | usage octet is not 253, CFB mode is used. A different mode is used | |||
with v3 keys (which are only RSA) than with other key formats. With | with version 3 keys (which are only RSA) than with other key formats. | |||
v3 keys, the MPI bit count prefix (that is, the first two octets) is | With version 3 keys, the MPI bit count prefix (that is, the first two | |||
not encrypted. Only the MPI non-prefix data is encrypted. | octets) is not encrypted. Only the MPI non-prefix data is encrypted. | |||
Furthermore, the CFB state is resynchronized at the beginning of each | Furthermore, the CFB state is resynchronized at the beginning of each | |||
new MPI value so that the CFB block boundary is aligned with the | new MPI value so that the CFB block boundary is aligned with the | |||
start of the MPI data. | start of the MPI data. | |||
With v4 and v6 keys, a simpler method is used. All secret MPI values | With version 4 and version 6 keys, a simpler method is used. All | |||
are encrypted, including the MPI bit count prefix. | secret MPI values are encrypted, including the MPI bit count prefix. | |||
If the S2K usage octet is 253, the KEK is derived using HKDF | If the S2K usage octet is 253, the KEK is derived using HKDF | |||
[RFC5869] to provide key separation. SHA256 [RFC6234] is used as the | [RFC5869] to provide key separation. SHA256 [RFC6234] is used as the | |||
hash algorithm for HKDF. IKM for HKDF is the key derived from S2K. | hash algorithm for HKDF. IKM for HKDF is the key derived from S2K. | |||
No salt is used. The info parameter is comprised of the Packet Type | No salt is used. The info parameter is comprised of the Packet Type | |||
ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 | ID encoded in OpenPGP format (bits 7 and 6 are set, and bits 5-0 | |||
carry the Packet Type ID), the packet version, and the cipher-algo | carry the Packet Type ID), the packet version, and the cipher-algo | |||
and AEAD-mode used to encrypt the key material. | and AEAD-mode used to encrypt the key material. | |||
Then, the encrypted MPI values are encrypted as one combined | Then, the encrypted MPI values are encrypted as one combined | |||
plaintext using one of the AEAD algorithms specified for the | plaintext using one of the AEAD algorithms specified for the Version | |||
Symmetrically Encrypted and Integrity Protected Data packet version | 2 Symmetrically Encrypted and Integrity Protected Data packet. Note | |||
2. Note that no chunks are used and that there is only one | that no chunks are used and that there is only one authentication | |||
authentication tag. As additional data, the Packet Type ID in | tag. As additional data, the Packet Type ID in OpenPGP format | |||
OpenPGP format encoding (bits 7 and 6 are set, and bits 5-0 carry the | encoding (bits 7 and 6 are set, and bits 5-0 carry the Packet Type | |||
Packet Type ID), followed by the Public Key packet fields, starting | ID), followed by the Public Key packet fields, starting with the | |||
with the packet version number, are passed to the AEAD algorithm. | packet version number, are passed to the AEAD algorithm. For | |||
For example, the additional data used with a Secret Key packet of | example, the additional data used with a Secret Key packet of version | |||
version 4 consists of the octets 0xC5, 0x04, followed by four octets | 4 consists of the octets 0xC5, 0x04, followed by four octets of | |||
of creation time, one octet denoting the public key algorithm, and | creation time, one octet denoting the public key algorithm, and the | |||
the algorithm-specific public key parameters. For a Secret Subkey | algorithm-specific public key parameters. For a Secret Subkey | |||
packet, the first octet would be 0xC7. For a version 6 key packet, | packet, the first octet would be 0xC7. For a version 6 key packet, | |||
the second octet would be 0x06, and the 4-octet octet count of the | the second octet would be 0x06, and the 4-octet octet count of the | |||
public key material would be included as well (see Section 5.5.2). | public key material would be included as well (see Section 5.5.2). | |||
The 2-octet checksum that follows the algorithm-specific portion is | The 2-octet checksum that follows the algorithm-specific portion is | |||
the algebraic sum, mod 65536, of the plaintext of all the algorithm- | the algebraic sum, mod 65536, of the plaintext of all the algorithm- | |||
specific octets (including the MPI prefix and data). With v3 keys, | specific octets (including the MPI prefix and data). With version 3 | |||
the checksum is stored in the clear. With v4 keys, the checksum is | keys, the checksum is stored in the clear. With version 4 keys, the | |||
encrypted like the algorithm-specific data. This value is used to | checksum is encrypted like the algorithm-specific data. This value | |||
check that the passphrase was correct. However, this checksum is | is used to check that the passphrase was correct. However, this | |||
deprecated, and an implementation SHOULD NOT use it; instead, an | checksum is deprecated, and an implementation SHOULD NOT use it; | |||
implementation should use the SHA-1 hash denoted with a usage octet | instead, an implementation should use the SHA-1 hash denoted with a | |||
of 254. The reason for this is that there are some attacks that | usage octet of 254. The reason for this is that there are some | |||
involve modifying the secret key undetected. If the S2K usage octet | attacks that involve modifying the secret key undetected. If the S2K | |||
is 253, no checksum or SHA-1 hash is used, but the authentication tag | usage octet is 253, no checksum or SHA-1 hash is used, but the | |||
of the AEAD algorithm follows. | authentication tag of the AEAD algorithm follows. | |||
When decrypting the secret key material using any of these schemes | When decrypting the secret key material using any of these schemes | |||
(that is, where the usage octet is non-zero), the resulting cleartext | (that is, where the usage octet is non-zero), the resulting cleartext | |||
octet stream must be well formed. In particular, an implementation | octet stream must be well formed. In particular, an implementation | |||
MUST NOT interpret octets beyond the unwrapped cleartext octet stream | MUST NOT interpret octets beyond the unwrapped cleartext octet stream | |||
as part of any of the unwrapped MPI objects. Furthermore, an | as part of any of the unwrapped MPI objects. Furthermore, an | |||
implementation MUST reject any secret key material whose cleartext | implementation MUST reject any secret key material whose cleartext | |||
length does not align with the lengths of the unwrapped MPI objects | length does not align with the lengths of the unwrapped MPI objects | |||
as unusable. | as unusable. | |||
5.5.4. Key IDs and Fingerprints | 5.5.4. Key IDs and Fingerprints | |||
Every OpenPGP Key has a fingerprint and a key ID. The computation of | Every OpenPGP Key has a fingerprint and a Key ID. The computation of | |||
these values differs based on the key version. The fingerprint | these values differs based on the key version. The fingerprint | |||
length varies with the key version, but the key ID (which is only | length varies with the key version, but the Key ID (which is only | |||
used in v3 PKESK packets; see Section 5.1.1) is always 64 bits. The | used in v3 PKESK packets; see Section 5.1.1) is always 64 bits. The | |||
following registry represents the subsections below: | following registry represents the subsections below: | |||
+=======+===================+===============+=============+=========+ | +=======+===================+===============+=============+=========+ | |||
|Key | Fingerprint | Fingerprint | Key ID |Reference| | |Key | Fingerprint | Fingerprint | Key ID |Reference| | |||
|Version| | Length | | | | |Version| | Length | | | | |||
| | | (Bits) | | | | | | | (Bits) | | | | |||
+=======+===================+===============+=============+=========+ | +=======+===================+===============+=============+=========+ | |||
|3 | MD5(MPIs without | 128 | low 64 bits |Section | | |3 | MD5(MPIs without | 128 | low 64 bits |Section | | |||
| | length octets) | | of RSA |5.5.4.1 | | | | length octets) | | of RSA |5.5.4.1 | | |||
skipping to change at line 3342 ¶ | skipping to change at line 3338 ¶ | |||
+-------+-------------------+---------------+-------------+---------+ | +-------+-------------------+---------------+-------------+---------+ | |||
|6 | SHA256(normalized | 256 | first 64 |Section | | |6 | SHA256(normalized | 256 | first 64 |Section | | |||
| | pubkey packet) | | bits of |5.5.4.3 | | | | pubkey packet) | | bits of |5.5.4.3 | | |||
| | | | fingerprint | | | | | | | fingerprint | | | |||
+-------+-------------------+---------------+-------------+---------+ | +-------+-------------------+---------------+-------------+---------+ | |||
Table 12: OpenPGP Key IDs and Fingerprints Registry | Table 12: OpenPGP Key IDs and Fingerprints Registry | |||
5.5.4.1. Version 3 Key ID and Fingerprint | 5.5.4.1. Version 3 Key ID and Fingerprint | |||
For a v3 key, the 8-octet Key ID consists of the low 64 bits of the | For a version 3 key, the 8-octet Key ID consists of the low 64 bits | |||
public modulus of the RSA key. | of the public modulus of the RSA key. | |||
The fingerprint of a v3 key is formed by hashing the body (but not | The fingerprint of a version 3 key is formed by hashing the body (but | |||
the 2-octet length) of the MPIs that form the key material (public | not the 2-octet length) of the MPIs that form the key material | |||
modulus n, followed by exponent e) with MD5. Note that both v3 keys | (public modulus n, followed by exponent e) with MD5. Note that both | |||
and MD5 are deprecated. | version 3 keys and MD5 are deprecated. | |||
5.5.4.2. Version 4 Key ID and Fingerprint | 5.5.4.2. Version 4 Key ID and Fingerprint | |||
A v4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, | A version 4 fingerprint is the 160-bit SHA-1 hash of the octet 0x99, | |||
followed by the 2-octet packet length, followed by the entire Public | followed by the 2-octet packet length, followed by the entire Public | |||
Key packet starting with the version field. The Key ID is the low- | Key packet starting with the version field. The Key ID is the low- | |||
order 64 bits of the fingerprint. Here are the fields of the hash | order 64 bits of the fingerprint. Here are the fields of the hash | |||
material, including an example of an Ed25519 key: | material, including an example of an Ed25519 key: | |||
a.1) 0x99 (1 octet) | a.1) 0x99 (1 octet) | |||
a.2) 2-octet, big-endian scalar octet count of (b)-(e) | a.2) 2-octet, big-endian scalar octet count of (b)-(e) | |||
b) version number = 4 (1 octet) | b) version number = 4 (1 octet) | |||
skipping to change at line 3376 ¶ | skipping to change at line 3372 ¶ | |||
d) algorithm (1 octet): 27 = Ed25519 (example) | d) algorithm (1 octet): 27 = Ed25519 (example) | |||
e) algorithm-specific fields | e) algorithm-specific fields | |||
Algorithm-specific fields for Ed25519 keys (example): | Algorithm-specific fields for Ed25519 keys (example): | |||
e.1) 32 octets representing the public key | e.1) 32 octets representing the public key | |||
5.5.4.3. Version 6 Key ID and Fingerprint | 5.5.4.3. Version 6 Key ID and Fingerprint | |||
A v6 fingerprint is the 256-bit SHA2-256 hash of the octet 0x9B, | A version 6 fingerprint is the 256-bit SHA2-256 hash of the octet | |||
followed by the 4-octet packet length, followed by the entire Public | 0x9B, followed by the 4-octet packet length, followed by the entire | |||
Key packet starting with the version field. The Key ID is the high- | Public Key packet starting with the version field. The Key ID is the | |||
order 64 bits of the fingerprint. Here are the fields of the hash | high-order 64 bits of the fingerprint. Here are the fields of the | |||
material, including an example of an Ed25519 key: | hash material, including an example of an Ed25519 key: | |||
a.1) 0x9B (1 octet) | a.1) 0x9B (1 octet) | |||
a.2) 4-octet scalar octet count of (b)-(f) | a.2) 4-octet scalar octet count of (b)-(f) | |||
b) version number = 6 (1 octet) | b) version number = 6 (1 octet) | |||
c) timestamp of key creation (4 octets) | c) timestamp of key creation (4 octets) | |||
d) algorithm (1 octet): 27 = Ed25519 (example) | d) algorithm (1 octet): 27 = Ed25519 (example) | |||
skipping to change at line 3406 ¶ | skipping to change at line 3402 ¶ | |||
Algorithm-specific fields for Ed25519 keys (example): | Algorithm-specific fields for Ed25519 keys (example): | |||
f.1) 32 octets representing the public key | f.1) 32 octets representing the public key | |||
Note that it is possible for there to be collisions of Key IDs -- | Note that it is possible for there to be collisions of Key IDs -- | |||
that is, two different keys with the same Key ID. Note that there is | that is, two different keys with the same Key ID. Note that there is | |||
a much smaller, but still non-zero, probability that two different | a much smaller, but still non-zero, probability that two different | |||
keys have the same fingerprint. | keys have the same fingerprint. | |||
Also note that if v3, v4, and v6 format keys share the same RSA key | Also note that if version 3, version 4, and version 6 format keys | |||
material, they will have different Key IDs as well as different | share the same RSA key material, they will have different Key IDs as | |||
fingerprints. | well as different fingerprints. | |||
Finally, the Key ID and fingerprint of a subkey are calculated in the | 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 | same way as for a primary key, including the 0x99 (version 4 key) or | |||
(v6 key) as the first octet (even though this is not a valid Packet | 0x9B (version 6 key) as the first octet (even though this is not a | |||
Type ID for a public subkey). | valid Packet Type ID for a public subkey). | |||
5.5.5. Algorithm-Specific Parts of Keys | 5.5.5. Algorithm-Specific Parts of Keys | |||
The public and secret key formats specify algorithm-specific parts of | The public and secret key formats specify algorithm-specific parts of | |||
a key. The following sections describe them in detail. | a key. The following sections describe them in detail. | |||
5.5.5.1. Algorithm-Specific Part for RSA Keys | 5.5.5.1. Algorithm-Specific Part for RSA Keys | |||
For RSA keys, the public key consists of this series of | For RSA keys, the public key consists of this series of | |||
multiprecision integers: | multiprecision integers: | |||
skipping to change at line 3679 ¶ | skipping to change at line 3675 ¶ | |||
A ZLIB-compressed series of packets is compressed with raw ZLIB-style | A ZLIB-compressed series of packets is compressed with raw ZLIB-style | |||
blocks [RFC1950]. | blocks [RFC1950]. | |||
A BZip2-compressed series of packets is compressed using the BZip2 | A BZip2-compressed series of packets is compressed using the BZip2 | |||
[BZ2] algorithm. | [BZ2] algorithm. | |||
An implementation that generates a Compressed Data packet MUST use | An implementation that generates a Compressed Data packet MUST use | |||
the OpenPGP format for packet framing (see Section 4.2.1). It MUST | the OpenPGP format for packet framing (see Section 4.2.1). It MUST | |||
NOT generate a Compressed Data packet with Legacy format | NOT generate a Compressed Data packet with Legacy format | |||
(Section 4.2.2) | (Section 4.2.2). | |||
An implementation that deals with either historic data or data | An implementation that deals with either historic data or data | |||
generated by legacy implementations predating support for [RFC2440] | generated by legacy implementations predating support for [RFC2440] | |||
MAY interpret Compressed Data packets that use the Legacy format for | MAY interpret Compressed Data packets that use the Legacy format for | |||
packet framing. | packet framing. | |||
5.7. Symmetrically Encrypted Data Packet (Type ID 9) | 5.7. Symmetrically Encrypted Data Packet (Type ID 9) | |||
The Symmetrically Encrypted Data packet contains data encrypted with | The Symmetrically Encrypted Data packet contains data encrypted with | |||
a symmetric key algorithm. When it has been decrypted, it contains | a symmetric key algorithm. When it has been decrypted, it contains | |||
other packets (usually a Literal Data packet or compressed data | other packets (usually a Literal Data packet or compressed data | |||
packet, but in theory, it could be another sequence of packets that | packet, but in theory, it could be another sequence of packets that | |||
forms a valid OpenPGP Message. | forms a valid OpenPGP Message). | |||
This packet is obsolete. An implementation MUST NOT create this | This packet is obsolete. An implementation MUST NOT create this | |||
packet. An implementation SHOULD reject such a packet and stop | packet. An implementation SHOULD reject such a packet and stop | |||
processing the message. If an implementation chooses to process the | processing the message. If an implementation chooses to process the | |||
packet anyway, it MUST return a clear warning that a non-integrity- | packet anyway, it MUST return a clear warning that a non-integrity- | |||
protected packet has been processed. | protected packet has been processed. | |||
This packet format is impossible to handle safely in general because | This packet format is impossible to handle safely in general because | |||
the ciphertext it provides is malleable. See Section 13.7 about | the ciphertext it provides is malleable. See Section 13.7 about | |||
selecting a better OpenPGP encryption container that does not have | selecting a better OpenPGP encryption container that does not have | |||
skipping to change at line 3893 ¶ | skipping to change at line 3889 ¶ | |||
User Attribute packet. A simple way to do this is by treating the | User Attribute packet. A simple way to do this is by treating the | |||
User Attribute packet as a User ID packet with opaque contents, but | User Attribute packet as a User ID packet with opaque contents, but | |||
an implementation may use any method desired. | an implementation may use any method desired. | |||
The User Attribute packet is made up of one or more attribute | The User Attribute packet is made up of one or more attribute | |||
subpackets. Each subpacket consists of a subpacket header and a | subpackets. Each subpacket consists of a subpacket header and a | |||
body. The header consists of: | body. The header consists of: | |||
* the subpacket length (1, 2, or 5 octets) | * the subpacket length (1, 2, or 5 octets) | |||
* the subpacket Type ID (1 octet) | * the Subpacket Type ID (1 octet) | |||
and is followed by the subpacket specific data. | and is followed by the subpacket specific data. | |||
The following table lists the currently known subpackets: | The following table lists the currently known subpackets: | |||
+=========+=============================+================+ | +=========+=============================+================+ | |||
| ID | Attribute Subpacket | Reference | | | ID | Attribute Subpacket | Reference | | |||
+=========+=============================+================+ | +=========+=============================+================+ | |||
| 0 | Reserved | | | | 0 | Reserved | | | |||
+---------+-----------------------------+----------------+ | +---------+-----------------------------+----------------+ | |||
skipping to change at line 3991 ¶ | skipping to change at line 3987 ¶ | |||
and offers some protections against ciphertext malleability. | and offers some protections against ciphertext malleability. | |||
Version 2 of this packet contains data encrypted with an AEAD | Version 2 of this packet contains data encrypted with an AEAD | |||
construction. This offers a more cryptographically rigorous defense | construction. This offers a more cryptographically rigorous defense | |||
against ciphertext malleability. See Section 13.7 for more details | against ciphertext malleability. See Section 13.7 for more details | |||
on choosing between these formats. | on choosing between these formats. | |||
Any new version of the SEIPD packet should be registered in the | Any new version of the SEIPD packet should be registered in the | |||
registry established in Section 10.3.2.1. | registry established in Section 10.3.2.1. | |||
5.13.1. Symmetrically Encrypted and Integrity Protected Data Packet | 5.13.1. Version 1 Symmetrically Encrypted and Integrity Protected Data | |||
Version 1 Format | Packet Format | |||
A Symmetrically Encrypted and Integrity Protected Data packet version | A Version 1 Symmetrically Encrypted and Integrity Protected Data | |||
1 consists of: | packet consists of: | |||
* A 1-octet version number with value 1. | * A 1-octet version number with value 1. | |||
* Encrypted data -- the output of the selected symmetric key cipher | * Encrypted data -- the output of the selected symmetric key cipher | |||
operating in CFB mode. | operating in CFB mode. | |||
The symmetric cipher used MUST be specified in a Public Key or | The symmetric cipher used MUST be specified in a Public Key or | |||
Symmetric Key Encrypted Session Key packet that precedes the | Symmetric Key Encrypted Session Key packet that precedes the | |||
Symmetrically Encrypted and Integrity Protected Data packet. In | Symmetrically Encrypted and Integrity Protected Data packet. In | |||
either case, the cipher algorithm ID is prefixed to the session key | either case, the cipher algorithm ID is prefixed to the session key | |||
skipping to change at line 4048 ¶ | skipping to change at line 4044 ¶ | |||
including the prefix data as well as the trailing constant octets | including the prefix data as well as the trailing constant octets | |||
0xD3, 0x14, but excluding the last 20 octets containing the SHA-1 | 0xD3, 0x14, but excluding the last 20 octets containing the SHA-1 | |||
hash. The computed SHA-1 hash is then compared with the last 20 | hash. The computed SHA-1 hash is then compared with the last 20 | |||
octets of plaintext. A mismatch of the hash indicates that the | octets of plaintext. A mismatch of the hash indicates that the | |||
message has been modified and MUST be treated as a security problem. | message has been modified and MUST be treated as a security problem. | |||
Any failure SHOULD be reported to the user. | Any failure SHOULD be reported to the user. | |||
NON-NORMATIVE EXPLANATION | NON-NORMATIVE EXPLANATION | |||
The MDC system, as the integrity protection mechanism of the | The MDC system, as the integrity protection mechanism of the | |||
Symmetrically Encrypted and Integrity Protected Data packet | Version 1 Symmetrically Encrypted and Integrity Protected Data | |||
version 1 is called, was created to provide an integrity mechanism | packet is called, was created to provide an integrity mechanism | |||
that is less strong than a signature, yet stronger than bare CFB | that is less strong than a signature, yet stronger than bare CFB | |||
encryption. | encryption. | |||
CFB encryption has a limitation as damage to the ciphertext will | CFB encryption has a limitation as damage to the ciphertext will | |||
corrupt the affected cipher blocks and the block following. | 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.) | is undetectable.) | |||
skipping to change at line 4101 ¶ | skipping to change at line 4097 ¶ | |||
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 is an attack that would | simple, fast system. (A downgrade attack is an attack that would | |||
replace 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 RIPEMD-160, | would replace SHA-1 with another 160-bit hash, such as RIPEMD-160, | |||
for example.) | for example.) | |||
However, no update will be needed because the MDC has been | However, no update will be needed because the MDC has been | |||
replaced by the AEAD encryption described in this document. | replaced by the AEAD encryption described in this document. | |||
5.13.2. Symmetrically Encrypted and Integrity Protected Data Packet | 5.13.2. Version 2 Symmetrically Encrypted and Integrity Protected Data | |||
Version 2 Format | Packet Format | |||
A Symmetrically Encrypted and Integrity Protected Data packet version | A Version 2 Symmetrically Encrypted and Integrity Protected Data | |||
2 consists of: | packet consists of: | |||
* A 1-octet version number with value 2. | * A 1-octet version number with value 2. | |||
* A 1-octet cipher algorithm ID. | * A 1-octet cipher algorithm ID. | |||
* A 1-octet AEAD algorithm identifier. | * A 1-octet AEAD algorithm identifier. | |||
* A 1-octet chunk size. | * A 1-octet chunk size. | |||
* 32 octets of salt. The salt is used to derive the message key and | * 32 octets of salt. The salt is used to derive the message key and | |||
skipping to change at line 4219 ¶ | skipping to change at line 4215 ¶ | |||
(see Section 5.13.2) and Transferable Public Keys (see Section 10.1). | (see Section 5.13.2) and Transferable Public Keys (see Section 10.1). | |||
Such a packet MUST be ignored when received. | Such a packet MUST be ignored when received. | |||
Its contents SHOULD be random octets to make the length obfuscation | Its contents SHOULD be random octets to make the length obfuscation | |||
it provides more robust even when compressed. | it provides more robust even when compressed. | |||
An implementation adding padding to an OpenPGP stream SHOULD place | An implementation adding padding to an OpenPGP stream SHOULD place | |||
such a packet: | such a packet: | |||
* At the end of a v6 Transferable Public Key that is transferred | * At the end of a version 6 Transferable Public Key that is | |||
over an encrypted channel (see Section 10.1). | transferred over an encrypted channel (see Section 10.1). | |||
* As the last packet of an Optionally Padded Message within a | * As the last packet of an Optionally Padded Message within a | |||
Symmetrically Encrypted and Integrity Protected Data packet | Version 2 Symmetrically Encrypted and Integrity Protected Data | |||
version 2 (see Section 10.3.1). | packet (see Section 10.3.1). | |||
An implementation MUST be able to process Padding packets anywhere | An implementation MUST be able to process Padding packets anywhere | |||
else in an OpenPGP stream so that future revisions of this document | else in an OpenPGP stream so that future revisions of this document | |||
may specify further locations for padding. | may specify further locations for padding. | |||
Policy about how large to make such a packet to defend against | Policy about how large to make such a packet to defend against | |||
traffic analysis is beyond the scope of this document. | traffic analysis is beyond the scope of this document. | |||
6. Base64 Conversions | 6. Base64 Conversions | |||
skipping to change at line 4282 ¶ | skipping to change at line 4278 ¶ | |||
The CRC24 footer MUST NOT be generated if it can be determined by the | The CRC24 footer MUST NOT be generated if it can be determined by the | |||
context or by the OpenPGP object being encoded that the consuming | context or by the OpenPGP object being encoded that the consuming | |||
implementation accepts base64-encoded blocks without a CRC24 footer. | implementation accepts base64-encoded blocks without a CRC24 footer. | |||
Notably: | Notably: | |||
* An ASCII-armored Encrypted Message packet sequence that ends in a | * An ASCII-armored Encrypted Message packet sequence that ends in a | |||
v2 SEIPD packet MUST NOT contain a CRC24 footer. | v2 SEIPD packet MUST NOT contain a CRC24 footer. | |||
* An ASCII-armored sequence of Signature packets that only includes | * An ASCII-armored sequence of Signature packets that only includes | |||
v6 Signature packets MUST NOT contain a CRC24 footer. | version 6 Signature packets MUST NOT contain a CRC24 footer. | |||
* An ASCII-armored Transferable Public Key packet sequence of a v6 | * An ASCII-armored Transferable Public Key packet sequence of a | |||
key MUST NOT contain a CRC24 footer. | version 6 key MUST NOT contain a CRC24 footer. | |||
* An ASCII-armored keyring consisting of only v6 keys MUST NOT | * An ASCII-armored keyring consisting of only version 6 keys MUST | |||
contain a CRC24 footer. | NOT contain a CRC24 footer. | |||
Rationale: Previous draft versions of this document stated that the | Rationale: Previous draft versions of this document stated that the | |||
CRC24 footer is optional, but the text was ambiguous. In practice, | CRC24 footer is optional, but the text was ambiguous. In practice, | |||
very few implementations require the CRC24 footer to be present. | very few implementations require the CRC24 footer to be present. | |||
Computing the CRC24 incurs a significant cost, while providing no | Computing the CRC24 incurs a significant cost, while providing no | |||
meaningful integrity protection. Therefore, generating it is now | meaningful integrity protection. Therefore, generating it is now | |||
discouraged. | discouraged. | |||
6.1.1. An Implementation of the CRC24 in "C" | 6.1.1. An Implementation of the CRC24 in "C" | |||
skipping to change at line 4443 ¶ | skipping to change at line 4439 ¶ | |||
6.2.2.3. "Hash" Armor Header | 6.2.2.3. "Hash" Armor Header | |||
The Armor Header Key Hash is deprecated, but some older | The Armor Header Key Hash is deprecated, but some older | |||
implementations expect it in messages using the Cleartext Signature | implementations expect it in messages using the Cleartext Signature | |||
Framework (Section 7). When present, this Armor Header Key contains | Framework (Section 7). When present, this Armor Header Key contains | |||
a comma-separated list of hash algorithms used in the signatures on | a comma-separated list of hash algorithms used in the signatures on | |||
message, with digest names as specified in the "Text Name" column in | message, with digest names as specified in the "Text Name" column in | |||
Table 23. These headers SHOULD NOT be emitted unless: | Table 23. These headers SHOULD NOT be emitted unless: | |||
* the cleartext signed message contains a v4 signature made using a | * the cleartext signed message contains a version 4 signature made | |||
SHA2-based digest (SHA224, SHA256, SHA384, or SHA512), and | using a SHA2-based digest (SHA224, SHA256, SHA384, or SHA512), and | |||
* the cleartext signed message might be verified by a legacy OpenPGP | * the cleartext signed message might be verified by a legacy OpenPGP | |||
implementation that requires this header. | implementation that requires this header. | |||
A verifying application MUST decline to validate any signature in a | A verifying application MUST decline to validate any signature in a | |||
message with a non-conformant Hash header (that is, a Hash header | message with a non-conformant Hash header (that is, a Hash header | |||
that contains anything other than a comma-separated list of hash | that contains anything other than a comma-separated list of hash | |||
algorithms). When a conformant Hash header is present, a verifying | algorithms). When a conformant Hash header is present, a verifying | |||
application MUST ignore its contents, deferring to the hash algorithm | application MUST ignore its contents, deferring to the hash algorithm | |||
indicated in the Embedded Signature. | indicated in the Embedded Signature. | |||
skipping to change at line 4859 ¶ | skipping to change at line 4855 ¶ | |||
encoded Object Identifier. The first omitted field is 1 octet | encoded Object Identifier. The first omitted field is 1 octet | |||
representing the Object Identifier tag, and the second omitted field | representing the Object Identifier tag, and the second omitted field | |||
is the length of the Object Identifier body. For example, the | 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 | 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 | 86 48 CE 3D 03 01 07", from which the first entry in the table above | |||
is constructed by omitting the first two octets. Only the truncated | is constructed by omitting the first two octets. Only the truncated | |||
sequence of octets is the valid representation of a curve OID. | sequence of octets is the valid representation of a curve OID. | |||
The deprecated OIDs for Ed25519Legacy and Curve25519Legacy are used | The deprecated OIDs for Ed25519Legacy and Curve25519Legacy are used | |||
only in version 4 keys and signatures. Implementations MAY implement | only in version 4 keys and signatures. Implementations MAY implement | |||
these variants for compatibility with existing v4 key material and | these variants for compatibility with existing version 4 key material | |||
signatures. Implementations MUST NOT accept or generate v6 key | and signatures. Implementations MUST NOT accept or generate version | |||
material using the deprecated OIDs. | 6 key material using the deprecated OIDs. | |||
9.2.1. Curve-Specific Wire Formats | 9.2.1. Curve-Specific Wire Formats | |||
Some elliptic curve public key algorithms use different conventions | Some elliptic curve public key algorithms use different conventions | |||
for specific fields depending on the curve in use. Each field is | for specific fields depending on the curve in use. Each field is | |||
always formatted as an MPI, but with a curve-specific framing. This | always formatted as an MPI, but with a curve-specific framing. This | |||
table summarizes those distinctions. | table summarizes those distinctions. | |||
+================+========+============+=======+=========+==========+ | +================+========+============+=======+=========+==========+ | |||
|Curve |ECDH |ECDH Secret |EdDSA |EdDSA |EdDSA | | |Curve |ECDH |ECDH Secret |EdDSA |EdDSA |EdDSA | | |||
skipping to change at line 5094 ¶ | skipping to change at line 5090 ¶ | |||
| | | 0x00, 0x04, 0x40 | | | | | 0x00, 0x04, 0x40 | | |||
+------------+-------------------------+-------------------------+ | +------------+-------------------------+-------------------------+ | |||
Table 24: OpenPGP Hash Algorithm Identifiers for RSA | Table 24: OpenPGP Hash Algorithm Identifiers for RSA | |||
Signatures' Use of EMSA-PKCS1-v1_5 Padding Registry | Signatures' Use of EMSA-PKCS1-v1_5 Padding Registry | |||
Implementations MUST implement SHA2-256. Implementations SHOULD | Implementations MUST implement SHA2-256. Implementations SHOULD | |||
implement SHA2-384 and SHA2-512. Implementations MAY implement other | implement SHA2-384 and SHA2-512. Implementations MAY implement other | |||
algorithms. Implementations SHOULD NOT create messages that require | algorithms. Implementations SHOULD NOT create messages that require | |||
the use of SHA-1, with the exception of computing version 4 key | the use of SHA-1, with the exception of computing version 4 key | |||
fingerprints for purposes of the MDC in Symmetrically Encrypted and | fingerprints for purposes of the MDC in Version 1 Symmetrically | |||
Integrity Protected Data packets version 1. Implementations MUST NOT | Encrypted and Integrity Protected Data packets. Implementations MUST | |||
generate signatures with MD5, SHA-1, or RIPEMD-160. Implementations | NOT generate signatures with MD5, SHA-1, or RIPEMD-160. | |||
MUST NOT use MD5, SHA-1, or RIPEMD-160 as a hash function in an ECDH | Implementations MUST NOT use MD5, SHA-1, or RIPEMD-160 as a hash | |||
KDF. Implementations MUST NOT generate packets using MD5, SHA-1, or | function in an ECDH KDF. Implementations MUST NOT generate packets | |||
RIPEMD-160 as a hash function in an S2K KDF. Implementations MUST | using MD5, SHA-1, or RIPEMD-160 as a hash function in an S2K KDF. | |||
NOT decrypt a secret using MD5, SHA-1, or RIPEMD-160 as a hash | Implementations MUST NOT decrypt a secret using MD5, SHA-1, or | |||
function in an S2K KDF in a version 6 (or later) packet. | RIPEMD-160 as a hash function in an S2K KDF in a version 6 (or later) | |||
Implementations MUST NOT validate any recent signature that depends | packet. Implementations MUST NOT validate any recent signature that | |||
on MD5, SHA-1, or RIPEMD-160. Implementations SHOULD NOT validate | depends on MD5, SHA-1, or RIPEMD-160. Implementations SHOULD NOT | |||
any old signature that depends on MD5, SHA-1, or RIPEMD-160 unless | validate any old signature that depends on MD5, SHA-1, or RIPEMD-160 | |||
the signature's creation date predates known weakness of the | unless the signature's creation date predates known weakness of the | |||
algorithm used, and the implementation is confident that the message | algorithm used, and the implementation is confident that the message | |||
has been in the secure custody of the user the whole time. | has been in the secure custody of the user the whole time. | |||
9.6. AEAD Algorithms | 9.6. AEAD Algorithms | |||
+=========+==================+==============+====================+ | +=========+==================+==============+====================+ | |||
| ID | Name | Nonce Length | Authentication Tag | | | ID | Name | Nonce Length | Authentication Tag | | |||
| | | (Octets) | Length (Octets) | | | | | (Octets) | Length (Octets) | | |||
+=========+==================+==============+====================+ | +=========+==================+==============+====================+ | |||
| 0 | Reserved | | | | | 0 | Reserved | | | | |||
skipping to change at line 5188 ¶ | skipping to change at line 5184 ¶ | |||
OpenPGP users may transfer public keys. This section describes the | OpenPGP users may transfer public keys. This section describes the | |||
structure of public keys in transit to ensure interoperability. An | structure of public keys in transit to ensure interoperability. An | |||
OpenPGP Transferable Public Key is also known as an OpenPGP | OpenPGP Transferable Public Key is also known as an OpenPGP | |||
certificate, in order to distinguish it from both its constituent | certificate, in order to distinguish it from both its constituent | |||
Public Key packets (Sections 5.5.1.1 and 5.5.1.2) and the underlying | Public Key packets (Sections 5.5.1.1 and 5.5.1.2) and the underlying | |||
cryptographic key material. | cryptographic key material. | |||
10.1.1. OpenPGP Version 6 Certificate Structure | 10.1.1. OpenPGP Version 6 Certificate Structure | |||
The format of an OpenPGP v6 certificate is as follows. Entries in | The format of an OpenPGP version 6 certificate is as follows. | |||
square brackets are optional and ellipses indicate repetition. | Entries in square brackets are optional and ellipses indicate | |||
repetition. | ||||
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] | |||
skipping to change at line 5397 ¶ | skipping to change at line 5394 ¶ | |||
Padding Packet. | Padding Packet. | |||
In addition to these rules, a Marker packet (Section 5.8) can appear | In addition to these rules, a Marker packet (Section 5.8) can appear | |||
anywhere in the sequence. | anywhere in the sequence. | |||
10.3.1. Unwrapping Encrypted and Compressed Messages | 10.3.1. Unwrapping Encrypted and Compressed Messages | |||
In addition to the above grammar, certain messages can be "unwrapped" | In addition to the above grammar, certain messages can be "unwrapped" | |||
to yield new messages. In particular: | to yield new messages. In particular: | |||
* Decrypting a Symmetrically Encrypted and Integrity Protected Data | * Decrypting a Version 2 Symmetrically Encrypted and Integrity | |||
packet version 2 MUST yield a valid Optionally Padded Message. | Protected Data packet MUST yield a valid Optionally Padded | |||
Message. | ||||
* Decrypting a Symmetrically Encrypted and Integrity Protected Data | * Decrypting a Version 1 Symmetrically Encrypted and Integrity | |||
packet version 1 or -- for historic data -- a Symmetrically | Protected Data packet or -- for historic data -- a Symmetrically | |||
Encrypted Data packet MUST yield a valid OpenPGP Message. | Encrypted Data packet MUST yield a valid OpenPGP Message. | |||
* Decompressing a Compressed Data packet MUST also yield a valid | * Decompressing a Compressed Data packet MUST also yield a valid | |||
OpenPGP Message. | OpenPGP Message. | |||
When any unwrapping is performed, the resulting stream of octets is | When any unwrapping is performed, the resulting stream of octets is | |||
parsed into a series of OpenPGP packets like any other stream of | parsed into a series of OpenPGP packets like any other stream of | |||
octets. The packet boundaries found in the series of octets are | octets. The packet boundaries found in the series of octets are | |||
expected to align with the length of the unwrapped octet stream. An | expected to align with the length of the unwrapped octet stream. An | |||
implementation MUST NOT interpret octets beyond the boundaries of the | implementation MUST NOT interpret octets beyond the boundaries of the | |||
skipping to change at line 5488 ¶ | skipping to change at line 5486 ¶ | |||
Table 26: OpenPGP Encrypted Message Packet Versions Registry | Table 26: OpenPGP Encrypted Message Packet Versions Registry | |||
An implementation processing an Encrypted Message MUST discard any | An implementation processing an Encrypted Message MUST discard any | |||
preceding ESK packet with a version that does not align with the | preceding ESK packet with a version that does not align with the | |||
version of the payload. | version of the payload. | |||
10.3.2.2. Packet Versions in Signatures | 10.3.2.2. Packet Versions in Signatures | |||
OpenPGP Key packets and Signature packets are also versioned. The | OpenPGP Key packets and Signature packets are also versioned. The | |||
version of a Signature typically matches the version of the signing | version of a Signature typically matches the version of the signing | |||
key. When a v6 key produces a Signature packet, it MUST produce a | key. When a version 6 key produces a Signature packet, it MUST | |||
version 6 Signature packet, regardless of the Signature packet type. | produce a version 6 Signature packet, regardless of the Signature | |||
When a message is signed or verified using the one-pass construction, | packet type. When a message is signed or verified using the one-pass | |||
the version of the One-Pass Signature packet (Section 5.4) should | construction, the version of the One-Pass Signature packet | |||
also be aligned to the other versions. | (Section 5.4) should also be aligned to the other versions. | |||
Some legacy implementations have produced unaligned signature | Some legacy implementations have produced unaligned signature | |||
versions for older key material, which are also described in the | versions for older key material, which are also described in the | |||
table below for the purpose of historic interoperability. A | table below for the purpose of historic interoperability. A | |||
conforming implementation MUST only generate Signature packets with | conforming implementation MUST only generate Signature packets with | |||
version numbers matching rows with "Yes" in the "Generate?" column. | version numbers matching rows with "Yes" in the "Generate?" column. | |||
+=====================+================+============+===========+ | +=====================+================+============+===========+ | |||
| Signing Key Version | Signature | OPS Packet | Generate? | | | Signing Key Version | Signature | OPS Packet | Generate? | | |||
| | Packet Version | Version | | | | | Packet Version | Version | | | |||
skipping to change at line 5792 ¶ | skipping to change at line 5790 ¶ | |||
* 20 octets representing the UTF-8 encoding of the string "Anonymous | * 20 octets representing the UTF-8 encoding of the string "Anonymous | |||
Sender ", which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 | Sender ", which is the octet sequence 41 6E 6F 6E 79 6D 6F 75 73 | |||
20 53 65 6E 64 65 72 20 20 20 20. | 20 53 65 6E 64 65 72 20 20 20 20. | |||
* A variable-length field containing the fingerprint of the | * A variable-length field containing the fingerprint of the | |||
recipient encryption subkey identifying the key material that is | recipient encryption subkey identifying the key material that is | |||
needed for decryption. For version 4 keys, this field is 20 | needed for decryption. For version 4 keys, this field is 20 | |||
octets. For version 6 keys, this field is 32 octets. | octets. For version 6 keys, this field is 32 octets. | |||
The size in octets of the KDF parameters sequence, as defined above, | The size in octets of the KDF parameters sequence, as defined above, | |||
for encrypting to a v4 key is 54 for curve NIST P-256; 51 for curves | for encrypting to a version 4 key is 54 for curve NIST P-256; 51 for | |||
NIST P-384 and NIST P-521; 55 for curves brainpoolP256r1, | curves NIST P-384 and NIST P-521; 55 for curves brainpoolP256r1, | |||
brainpoolP384r1, and brainpoolP512r1; or 56 for Curve25519Legacy. | brainpoolP384r1, and brainpoolP512r1; or 56 for Curve25519Legacy. | |||
For encrypting to a v6 key, the size of the sequence is 66 for curve | For encrypting to a version 6 key, the size of the sequence is 66 for | |||
NIST P-256; 63 for curves NIST P-384 and NIST P-521; or 67 for curves | curve NIST P-256; 63 for curves NIST P-384 and NIST P-521; or 67 for | |||
brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1. | curves brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1. | |||
The key wrapping method is described in [RFC3394]. The KDF produces | The key wrapping method is described in [RFC3394]. The KDF produces | |||
a symmetric key that is used as a KEK as specified in [RFC3394]. | a symmetric key that is used as a KEK as specified in [RFC3394]. | |||
Refer to Section 11.5.1 for the details regarding the choice of the | Refer to Section 11.5.1 for the details regarding the choice of the | |||
KEK algorithm, which SHOULD be one of the three AES algorithms. Key | KEK algorithm, which SHOULD be one of the three AES algorithms. Key | |||
wrapping and unwrapping is performed with the default initial value | wrapping and unwrapping is performed with the default initial value | |||
of [RFC3394]. | of [RFC3394]. | |||
To produce the input to the key wrapping method, first concatenate | To produce the input to the key wrapping method, first concatenate | |||
the following values: | the following values: | |||
skipping to change at line 5820 ¶ | skipping to change at line 5818 ¶ | |||
a v3 PKESK packet). | a v3 PKESK packet). | |||
* The session key. | * The session key. | |||
* A 2-octet checksum of the session key, equal to the sum of the | * A 2-octet checksum of the session key, equal to the sum of the | |||
session key octets, modulo 65536. | session key octets, modulo 65536. | |||
Then, the above values are padded to an 8-octet granularity using the | Then, the above values are padded to an 8-octet granularity using the | |||
method described in [RFC2898]. | method described in [RFC2898]. | |||
For example, in a v3 Public Key Encrypted Session Key packet, an | For example, in a version 3 Public Key Encrypted Session Key packet, | |||
AES-256 session key is encoded as follows, forming a 40-octet | an AES-256 session key is encoded as follows, forming a 40-octet | |||
sequence: | sequence: | |||
09 k0 k1 ... k31 s0 s1 05 05 05 05 05 | 09 k0 k1 ... k31 s0 s1 05 05 05 05 05 | |||
The octets k0 to k31 above denote the session key, and the octets s0 | The octets k0 to k31 above denote the session key, and the octets s0 | |||
and s1 denote the checksum of the session key octets. This encoding | and s1 denote the checksum of the session key octets. This encoding | |||
allows the sender to obfuscate the size of the symmetric encryption | allows the sender to obfuscate the size of the symmetric encryption | |||
key used to encrypt the data. For example, assuming that an AES | key used to encrypt the data. For example, assuming that an AES | |||
algorithm is used for the session key, the sender MAY use 21, 13, and | algorithm is used for the session key, the sender MAY use 21, 13, and | |||
5 octets of padding for AES-128, AES-192, and AES-256, respectively, | 5 octets of padding for AES-128, AES-192, and AES-256, respectively, | |||
to provide the same number of octets, 40 total, as an input to the | to provide the same number of octets, 40 total, as an input to the | |||
key wrapping method. | key wrapping method. | |||
In a v6 Public Key Encrypted Session Key packet, the symmetric | In a version 6 Public Key Encrypted Session Key packet, the symmetric | |||
algorithm is not included, as described in Section 5.1. For example, | algorithm is not included, as described in Section 5.1. For example, | |||
an AES-256 session key would be composed as follows: | an AES-256 session key would be composed as follows: | |||
k0 k1 ... k31 s0 s1 06 06 06 06 06 06 | k0 k1 ... k31 s0 s1 06 06 06 06 06 06 | |||
The octets k0 to k31 above again denote the session key, and the | The octets k0 to k31 above again denote the session key, and the | |||
octets s0 and s1 denote the checksum. In this case, assuming that an | octets s0 and s1 denote the checksum. In this case, assuming that an | |||
AES algorithm is used for the session key, the sender MAY use 22, 14, | AES algorithm is used for the session key, the sender MAY use 22, 14, | |||
and 6 octets of padding for AES-128, AES-192, and AES-256, | 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 | respectively, to provide the same number of octets, 40 total, as an | |||
skipping to change at line 6011 ¶ | skipping to change at line 6009 ¶ | |||
stop. See also Section 13.5 regarding differences in reporting | stop. See also Section 13.5 regarding differences in reporting | |||
between a decryption error and a padding error. | between a decryption error and a padding error. | |||
12.1.3. EMSA-PKCS1-v1_5 | 12.1.3. EMSA-PKCS1-v1_5 | |||
This encoding method is deterministic and only has an encoding | This encoding method is deterministic and only has an encoding | |||
operation. | operation. | |||
Input: | Input: | |||
Hash = a hash function to be used. | ||||
M = message to be encoded. | M = message to be encoded. | |||
emLen = intended length of the encoded message in octets, at least | emLen = intended length of the encoded message in octets, at least | |||
tLen + 11, where tLen is the octet length of the DER encoding T of | tLen + 11, where tLen is the octet length of the DER encoding T of | |||
a certain value computed during the encoding operation. | a certain value computed during the encoding operation. | |||
Output: | Output: | |||
EM = encoded message; an octet string of length emLen. | EM = encoded message; an octet string of length emLen. | |||
skipping to change at line 6034 ¶ | skipping to change at line 6034 ¶ | |||
Steps: | Steps: | |||
1. Apply the hash function to the message M to produce hash value H: | 1. Apply the hash function to the message M to produce hash value H: | |||
H = Hash(M). | H = Hash(M). | |||
If the hash function outputs "message too long," output "message | If the hash function outputs "message too long," output "message | |||
too long" and stop. | too long" and stop. | |||
2. Using the list in Section 9.5, produce an ASN.1 DER value for the | 2. Using the list in Section 9.5, produce an ASN.1 DER value for the | |||
hash function used. Let T be the full hash prefix from the list, | hash function used. Let T be the Full Hash Prefix from Table 24 | |||
concatenated with the hash digest H, and let tLen be the length | for the given hash function, concatenated with the hash digest H, | |||
in octets of T. | and let tLen be the length in octets of T. | |||
3. If emLen < tLen + 11, output "intended encoded message length too | 3. If emLen < tLen + 11, output "intended encoded message length too | |||
short" and stop. | short" and stop. | |||
4. Generate an octet string PS consisting of emLen - tLen - 3 octets | 4. Generate an octet string PS consisting of emLen - tLen - 3 octets | |||
with hexadecimal value 0xFF. The length of PS will be at least 8 | with hexadecimal value 0xFF. The length of PS will be at least 8 | |||
octets. | octets. | |||
5. Concatenate PS, the hash prefix T, and other padding to form the | 5. Concatenate PS, the hash prefix T, and other padding to form the | |||
encoded message EM as | encoded message EM as | |||
skipping to change at line 6224 ¶ | skipping to change at line 6224 ¶ | |||
12.9. CFB Mode | 12.9. CFB Mode | |||
The Cipher Feedback (CFB) mode used in this document is defined in | The Cipher Feedback (CFB) mode used in this document is defined in | |||
Section 6.3 of [SP800-38A]. | Section 6.3 of [SP800-38A]. | |||
The CFB segment size s is equal to the block size of the cipher | The CFB segment size s is equal to the block size of the cipher | |||
(i.e., n-bit CFB mode, where n is the block size used). | (i.e., n-bit CFB mode, where n is the block size used). | |||
12.10. Private or Experimental Parameters | 12.10. Private or Experimental Parameters | |||
S2K Specifier Types, Signature subpacket Type IDs, User Attribute | S2K Specifiers, Signature Subpacket Type IDs, User Attribute | |||
subpacket Type IDs, image format IDs, and the various algorithm IDs | Subpacket Type IDs, image format IDs, and the various algorithm IDs | |||
described in Section 9 all reserve the range 100 to 110 for Private | described in Section 9 all reserve the range 100 to 110 for Private | |||
and Experimental Use. Packet Type IDs reserve the range 60 to 63 for | and Experimental Use. Packet Type IDs reserve the range 60 to 63 for | |||
Private and Experimental Use. These are intentionally managed by the | Private and Experimental Use. These are intentionally managed by the | |||
Private Use and Experimental Use policies, as described in [RFC8126]. | Private Use and Experimental Use policies, as described in [RFC8126]. | |||
However, implementations need to be careful with these and promote | However, implementations need to be careful with these and promote | |||
them to full IANA-managed parameters when they grow beyond the | them to full IANA-managed parameters when they grow beyond the | |||
original, limited system. | original, limited system. | |||
12.11. Meta Considerations for Expansion | 12.11. Meta Considerations for Expansion | |||
skipping to change at line 6274 ¶ | skipping to change at line 6274 ¶ | |||
is assumed that the private key portion of a public-private key | is assumed that the private key portion of a public-private key | |||
pair is controlled and secured by the proper party or parties. | pair is controlled and secured by the proper party or parties. | |||
* The MD5 and SHA-1 hash algorithms have been found to have | * The MD5 and SHA-1 hash algorithms have been found to have | |||
weaknesses, with collisions found in a number of cases. MD5 and | weaknesses, with collisions found in a number of cases. MD5 and | |||
SHA-1 are deprecated for use in OpenPGP (see Section 9.5). | SHA-1 are deprecated for use in OpenPGP (see Section 9.5). | |||
* Many security protocol designers think that it is a bad idea to | * Many security protocol designers think that it is a bad idea to | |||
use a single key for both privacy (encryption) and integrity | use a single key for both privacy (encryption) and integrity | |||
(signatures). In fact, this was one of the motivating forces | (signatures). In fact, this was one of the motivating forces | |||
behind the v4 key format with separate signature and encryption | behind the version 4 key format with separate signature and | |||
keys. Using a single key for encrypting and signing is | encryption keys. Using a single key for encrypting and signing is | |||
discouraged. | discouraged. | |||
* The DSA algorithm will work with any hash, but it is sensitive to | * The DSA algorithm will work with any hash, but it is sensitive to | |||
the quality of the hash algorithm. Verifiers should be aware that | the quality of the hash algorithm. Verifiers should be aware that | |||
even if the signer used a strong hash, an attacker could have | even if the signer used a strong hash, an attacker could have | |||
modified the signature to use a weak one. Only signatures using | modified the signature to use a weak one. Only signatures using | |||
acceptably strong hash algorithms should be accepted as valid. | acceptably strong hash algorithms should be accepted as valid. | |||
* As OpenPGP combines many different asymmetric, symmetric, and hash | * As OpenPGP combines many different asymmetric, symmetric, and hash | |||
algorithms, each with different measures of strength, care should | algorithms, each with different measures of strength, care should | |||
skipping to change at line 6352 ¶ | skipping to change at line 6352 ¶ | |||
should convert an uncertain breakage (where it is unclear what the | should convert an uncertain breakage (where it is unclear what the | |||
effect of a collision will be) to an explicit breakage, which is more | effect of a collision will be) to an explicit breakage, which is more | |||
desirable for a robust implementation. | desirable for a robust implementation. | |||
[STEVENS2013] describes a method for detecting indicators of well- | [STEVENS2013] describes a method for detecting indicators of well- | |||
known SHA-1 collision attacks. Some example C code implementing this | known SHA-1 collision attacks. Some example C code implementing this | |||
technique can be found at [SHA1CD]. | technique can be found at [SHA1CD]. | |||
13.2. Advantages of Salted Signatures | 13.2. Advantages of Salted Signatures | |||
V6 signatures include a salt that is hashed first, and it's size | Version 6 signatures include a salt that is hashed first, and it's | |||
depends on the hashing algorithm. This makes v6 OpenPGP signatures | size depends on the hashing algorithm. This makes version 6 OpenPGP | |||
non-deterministic and protects against a broad class of attacks that | signatures non-deterministic and protects against a broad class of | |||
depend on creating a signature over a predictable message. By | attacks that depend on creating a signature over a predictable | |||
selecting a new random salt for each signature made, the signed | message. By selecting a new random salt for each signature made, the | |||
hashes and the signatures are not predictable. | signed hashes and the signatures are not predictable. | |||
While the material to be signed could be attacker controlled, hashing | While the material to be signed could be attacker controlled, hashing | |||
the salt first means that there is no attacker-controlled hashed | the salt first means that there is no attacker-controlled hashed | |||
prefix. An example of this kind of attack is described in the paper | prefix. An example of this kind of attack is described in the paper | |||
"SHA-1 is a Shambles" [SHAMBLES], which leverages a chosen prefix | "SHA-1 is a Shambles" [SHAMBLES], which leverages a chosen prefix | |||
collision attack against SHA-1. This means that an adversary | collision attack against SHA-1. This means that an adversary | |||
carrying out a chosen-message attack will not be able to control the | carrying out a chosen-message attack will not be able to control the | |||
hash that is being signed and will need to break second-preimage | hash that is being signed and will need to break second-preimage | |||
resistance instead of the simpler collision resistance to create two | resistance instead of the simpler collision resistance to create two | |||
messages having the same signature. The size of the salt is bound to | messages having the same signature. The size of the salt is bound to | |||
skipping to change at line 6411 ¶ | skipping to change at line 6411 ¶ | |||
check. | check. | |||
There is a danger when using the quick check if timing or error | There is a danger when using the quick check if timing or error | |||
information about the check can be exposed to an attacker, | information about the check can be exposed to an attacker, | |||
particularly via an automated service that allows rapidly repeated | particularly via an automated service that allows rapidly repeated | |||
queries. | queries. | |||
Disabling the quick check prevents the attack. | Disabling the quick check prevents the attack. | |||
For very large encrypted data whose session key is protected by a | For very large encrypted data whose session key is protected by a | |||
passphrase using a version 4 SKESK, the quick check may be convenient | passphrase using a v4 SKESK, the quick check may be convenient to the | |||
to the user by informing them early that they typed the wrong | user by informing them early that they typed the wrong passphrase. | |||
passphrase. But the implementation should use the quick check with | But the implementation should use the quick check with care. The | |||
care. The recommended approach for secure and early detection of | recommended approach for secure and early detection of decryption | |||
decryption failure is to encrypt data using v2 SEIPD. If the session | failure is to encrypt data using v2 SEIPD. If the session key is | |||
key is public key encrypted, the quick check is not useful as the | public key encrypted, the quick check is not useful as the public key | |||
public key encryption of the session key should guarantee that it is | encryption of the session key should guarantee that it is the right | |||
the right session key. | session key. | |||
The quick check oracle attack is a particular type of attack that | The quick check oracle attack is a particular type of attack that | |||
exploits ciphertext malleability. For information about other | exploits ciphertext malleability. For information about other | |||
similar attacks, see Section 13.7. | similar attacks, see Section 13.7. | |||
13.5. Avoiding Leaks from PKCS#1 Errors | 13.5. Avoiding Leaks from PKCS#1 Errors | |||
The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted | The PKCS#1 padding (used in RSA-encrypted and ElGamal-encrypted | |||
PKESK) has been found to be vulnerable to attacks in which a system | PKESK) has been found to be vulnerable to attacks in which a system | |||
that allows distinguishing padding errors from other decryption | that allows distinguishing padding errors from other decryption | |||
skipping to change at line 6470 ¶ | skipping to change at line 6470 ¶ | |||
fingerprint represented as 40 hexadecimal digits, often broken into | fingerprint represented as 40 hexadecimal digits, often broken into | |||
groups of four digits with whitespace between each group. | groups of four digits with whitespace between each group. | |||
When a human is actively involved, the result of such a verification | When a human is actively involved, the result of such a verification | |||
is dubious. There is little evidence that most humans are good at | is dubious. There is little evidence that most humans are good at | |||
precise comparison of high-entropy data, particularly when that data | precise comparison of high-entropy data, particularly when that data | |||
is represented in compact textual form like a hexadecimal | is represented in compact textual form like a hexadecimal | |||
[USENIX-STUDY]. | [USENIX-STUDY]. | |||
The version 6 fingerprint makes the challenge for a human verifier | The version 6 fingerprint makes the challenge for a human verifier | |||
even worse. At 256 bits (compared to v4's 160-bit fingerprint), a v6 | even worse. At 256 bits (compared to version 4's 160-bit | |||
fingerprint is even harder for a human to successfully compare. | fingerprint), a version 6 fingerprint is even harder for a human to | |||
successfully compare. | ||||
An OpenPGP implementation should prioritize mechanical fingerprint | An OpenPGP implementation should prioritize mechanical fingerprint | |||
transfer and comparison where possible and SHOULD NOT promote manual | transfer and comparison where possible and SHOULD NOT promote manual | |||
transfer or comparison of full fingerprints by a human unless there | transfer or comparison of full fingerprints by a human unless there | |||
is no other way to achieve the desired result. | is no other way to achieve the desired result. | |||
While this subsection acknowledges existing practice for human- | While this subsection acknowledges existing practice for human- | |||
representable v4 fingerprints, this document does not attempt to | representable version 4 fingerprints, this document does not attempt | |||
standardize any specific human-readable form of v6 fingerprint for | to standardize any specific human-readable form of version 6 | |||
this discouraged use case. | fingerprint for this discouraged use case. | |||
NOTE: the topic of interoperable human-in-the-loop key verification | NOTE: the topic of interoperable human-in-the-loop key verification | |||
needs more work, which will be done in a separate document. | needs more work, which will be done in a separate document. | |||
13.7. Avoiding Ciphertext Malleability | 13.7. Avoiding Ciphertext Malleability | |||
If ciphertext can be modified by an attacker but still subsequently | If ciphertext can be modified by an attacker but still subsequently | |||
decrypted to some new plaintext, it is considered "malleable". A | decrypted to some new plaintext, it is considered "malleable". A | |||
number of attacks can arise in any cryptosystem that uses malleable | number of attacks can arise in any cryptosystem that uses malleable | |||
encryption, so [RFC4880] and later versions of OpenPGP offer | encryption, so [RFC4880] and later versions of OpenPGP offer | |||
skipping to change at line 6529 ¶ | skipping to change at line 6530 ¶ | |||
clear error message as soon as the truncation is detected. | clear error message as soon as the truncation is detected. | |||
Any of the following OpenPGP data elements indicate that malleable | Any of the following OpenPGP data elements indicate that malleable | |||
ciphertext is present: | ciphertext is present: | |||
* All Symmetrically Encrypted Data packets (Section 5.7). | * All Symmetrically Encrypted Data packets (Section 5.7). | |||
* Within any encrypted container, any Compressed Data packet | * Within any encrypted container, any Compressed Data packet | |||
(Section 5.6) where there is a decompression failure. | (Section 5.6) where there is a decompression failure. | |||
* Any Symmetrically Encrypted and Integrity Protected Data packet | * Any Version 1 Symmetrically Encrypted and Integrity Protected Data | |||
version 1 (Section 5.13.1) where the internal Modification | packet (Section 5.13.1) where the internal Modification Detection | |||
Detection Code does not validate. | Code does not validate. | |||
* Any Symmetrically Encrypted and Integrity Protected Data packet | * Any Version 2 Symmetrically Encrypted and Integrity Protected Data | |||
version 2 (Section 5.13.2) where the authentication tag of any | packet (Section 5.13.2) where the authentication tag of any chunk | |||
chunk fails or where there is no final zero-octet chunk. | fails or where there is no final zero-octet chunk. | |||
* Any Secret-Key packet with encrypted secret key material | * Any Secret-Key packet with encrypted secret key material | |||
(Section 3.7.2.1) where there is an integrity failure, based on | (Section 3.7.2.1) where there is an integrity failure, based on | |||
the value of the secret key protection octet: | the value of the secret key protection octet: | |||
- Value 253 (AEAD): where the AEAD authentication tag is invalid. | - Value 253 (AEAD): where the AEAD authentication tag is invalid. | |||
- Value 254 (CFB): where the SHA1 checksum is mismatched. | - Value 254 (CFB): where the SHA1 checksum is mismatched. | |||
- Value 255 (MalleableCFB) or raw cipher algorithm: where the | - Value 255 (MalleableCFB) or raw cipher algorithm: where the | |||
skipping to change at line 6557 ¶ | skipping to change at line 6558 ¶ | |||
To avoid these circumstances, an implementation that generates | To avoid these circumstances, an implementation that generates | |||
OpenPGP encrypted data SHOULD select the encrypted container format | OpenPGP encrypted data SHOULD select the encrypted container format | |||
with the most robust protections that can be handled by the intended | with the most robust protections that can be handled by the intended | |||
recipients. In particular: | recipients. In particular: | |||
* The SED packet is deprecated and MUST NOT be generated. | * The SED packet is deprecated and MUST NOT be generated. | |||
* When encrypting to one or more public keys: | * When encrypting to one or more public keys: | |||
- If all recipient keys indicate support for Symmetrically | - If all recipient keys indicate support for a Version 2 | |||
Encrypted and Integrity Protected Data packet version 2 in | Symmetrically Encrypted and Integrity Protected Data packet in | |||
their Features subpacket (Section 5.2.3.32), if all recipient | their Features signature subpacket (Section 5.2.3.32), if all | |||
keys are version 6 keys without a Features subpacket, or the | recipient keys are version 6 keys without a Features signature | |||
implementation can otherwise infer that all recipients support | subpacket, or the implementation can otherwise infer that all | |||
v2 SEIPD packets, the implementation SHOULD encrypt using a v2 | recipients support v2 SEIPD packets, the implementation SHOULD | |||
SEIPD packet. | encrypt using a v2 SEIPD packet. | |||
- If one of the recipients does not support v2 SEIPD packets, | - If one of the recipients does not support v2 SEIPD packets, | |||
then the message generator MAY use a v1 SEIPD packet instead. | then the message generator MAY use a v1 SEIPD packet instead. | |||
* Passphrase-protected secret key material in a version 6 Secret Key | * Passphrase-protected secret key material in a version 6 Secret Key | |||
or version 6 Secret Subkey packet SHOULD be protected with AEAD | or version 6 Secret Subkey packet SHOULD be protected with AEAD | |||
encryption (S2K usage octet 253) unless it will be transferred to | encryption (S2K usage octet 253) unless it will be transferred to | |||
an implementation that is known to not support AEAD. An | an implementation that is known to not support AEAD. An | |||
implementation should be aware that, in scenarios where an | implementation should be aware that, in scenarios where an | |||
attacker has write access to encrypted private keys, CFB-encrypted | attacker has write access to encrypted private keys, CFB-encrypted | |||
skipping to change at line 6671 ¶ | skipping to change at line 6672 ¶ | |||
keys for any specific context. An implementer that intends to make | keys for any specific context. An implementer that intends to make | |||
use of this feature should publish their own proposed guidance for | use of this feature should publish their own proposed guidance for | |||
others to review. | others to review. | |||
13.9. Escrowed Revocation Signatures | 13.9. Escrowed Revocation Signatures | |||
A keyholder, Alice, may wish to designate a third party to be able to | A keyholder, Alice, may wish to designate a third party to be able to | |||
revoke her own key. | revoke her own key. | |||
The preferred way for Alice to do this is to produce a specific | The preferred way for Alice to do this is to produce a specific | |||
Revocation Signature (signature Type IDs 0x20, 0x28, or 0x30) and | Revocation Signature (Signature Type ID 0x20, 0x28, or 0x30) and | |||
distribute it securely to a preferred revoker who can hold it in | distribute it securely to a preferred revoker who can hold it in | |||
escrow. The preferred revoker can then publish the escrowed | escrow. The preferred revoker can then publish the escrowed | |||
Revocation Signature at whatever time is deemed appropriate rather | Revocation Signature at whatever time is deemed appropriate rather | |||
than generating the Revocation Signature themselves. | than generating the Revocation Signature themselves. | |||
There are multiple advantages of using an escrowed Revocation | There are multiple advantages of using an escrowed Revocation | |||
Signature over the deprecated Revocation Key subpacket | Signature over the deprecated Revocation Key subpacket | |||
(Section 5.2.3.23): | (Section 5.2.3.23): | |||
* The keyholder can constrain what types of revocation the preferred | * The keyholder can constrain what types of revocation the preferred | |||
skipping to change at line 6819 ¶ | skipping to change at line 6820 ¶ | |||
This section is a collection of comments to help an implementer who | This section is a collection of comments to help an implementer who | |||
has a particular interest in backward compatibility. Often the | has a particular interest in backward compatibility. Often the | |||
differences are small, but small differences are frequently more | differences are small, but small differences are frequently more | |||
vexing than large differences. Thus, this is a non-comprehensive | vexing than large differences. Thus, this is a non-comprehensive | |||
list of potential problems and gotchas for a developer who is trying | list of potential problems and gotchas for a developer who is trying | |||
to achieve backward compatibility. | to achieve backward compatibility. | |||
* There are many possible ways for two keys to have the same key | * There are many possible ways for two keys to have the same key | |||
material but different fingerprints (and thus different Key IDs). | material but different fingerprints (and thus different Key IDs). | |||
For example, since a v4 fingerprint is constructed by hashing the | For example, since a version 4 fingerprint is constructed by | |||
key creation time along with other things, two v4 keys created at | hashing the key creation time along with other things, two version | |||
different times yet with the same key material will have different | 4 keys created at different times yet with the same key material | |||
fingerprints. | will have different fingerprints. | |||
* OpenPGP does not put limits on the size of public keys. However, | * OpenPGP does not put limits on the size of public keys. However, | |||
larger keys are not necessarily better keys. Larger keys take | larger keys are not necessarily better keys. Larger keys take | |||
more computation time to use, and this can quickly become | more computation time to use, and this can quickly become | |||
impractical. Different OpenPGP implementations may also use | impractical. Different OpenPGP implementations may also use | |||
different upper bounds for public key sizes, so care should be | different upper bounds for public key sizes, so care should be | |||
taken when choosing sizes to maintain interoperability. | taken when choosing sizes to maintain interoperability. | |||
* ASCII Armor is an optional feature of OpenPGP. The OpenPGP | * ASCII Armor is an optional feature of OpenPGP. The OpenPGP | |||
Working Group strives for a minimal set of mandatory-to-implement | Working Group strives for a minimal set of mandatory-to-implement | |||
skipping to change at line 6855 ¶ | skipping to change at line 6856 ¶ | |||
necessarily have support. | necessarily have support. | |||
* What this document calls the "Legacy packet format" | * What this document calls the "Legacy packet format" | |||
(Section 4.2.2) is what older documents called the "old packet | (Section 4.2.2) is what older documents called the "old packet | |||
format". It is the packet format used by implementations | format". It is the packet format used by implementations | |||
predating [RFC2440]. The current "OpenPGP packet format" | predating [RFC2440]. The current "OpenPGP packet format" | |||
(Section 4.2.1) was called the "new packet format" by older RFCs. | (Section 4.2.1) was called the "new packet format" by older RFCs. | |||
This is the format introduced in [RFC2440] and maintained through | This is the format introduced in [RFC2440] and maintained through | |||
[RFC4880] to this document. | [RFC4880] to this document. | |||
14.1. Constrained Legacy Fingerprint Storage for v6 Keys | 14.1. Constrained Legacy Fingerprint Storage for Version 6 Keys | |||
Some OpenPGP implementations have fixed length constraints for key | Some OpenPGP implementations have fixed length constraints for key | |||
fingerprint storage that will not fit all 32 octets of a version 6 | fingerprint storage that will not fit all 32 octets of a version 6 | |||
fingerprint. For example, [OPENPGPCARD] reserves 20 octets for each | fingerprint. For example, [OPENPGPCARD] reserves 20 octets for each | |||
stored fingerprint. | stored fingerprint. | |||
An OpenPGP implementation MUST NOT attempt to map any part of a | An OpenPGP implementation MUST NOT attempt to map any part of a | |||
version 6 fingerprint to such a constrained field unless the relevant | version 6 fingerprint to such a constrained field unless the relevant | |||
specification for the constrained environment has explicit guidance | specification for the constrained environment has explicit guidance | |||
for storing a version 6 fingerprint that distinguishes it from a | for storing a version 6 fingerprint that distinguishes it from a | |||
skipping to change at line 7639 ¶ | skipping to change at line 7640 ¶ | |||
-----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----- | |||
A.3. Sample v6 Certificate (Transferable Public Key) | A.3. Sample v6 Certificate (Transferable Public Key) | |||
Here is a Transferable Public Key consisting of: | Here is a Transferable Public Key consisting of: | |||
* A v6 Ed25519 Public Key packet | * A version 6 Ed25519 Public Key packet | |||
* A v6 Direct Key self-signature | * A version 6 Direct Key self-signature | |||
* A v6 X25519 Public Subkey packet | * A version 6 X25519 Public Subkey packet | |||
* A v6 Subkey Binding signature | * A version 6 Subkey Binding signature | |||
The primary key has the following fingerprint: | The primary key has the following fingerprint: | |||
CB186C4F0609A697E4D52DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9 | CB186C4F0609A697E4D52DFA6C722B0C1F1E27C18A56708F6525EC27BAD9ACC9 | |||
The subkey has the following fingerprint: | The subkey has the following fingerprint: | |||
12C83F1E706F6308FE151A417743A1F033790E93E9978488D1DB378DA9930885 | 12C83F1E706F6308FE151A417743A1F033790E93E9978488D1DB378DA9930885 | |||
-----BEGIN PGP PUBLIC KEY BLOCK----- | -----BEGIN PGP PUBLIC KEY BLOCK----- | |||
skipping to change at line 7741 ¶ | skipping to change at line 7742 ¶ | |||
0x0063 0a 0e Hashes: [SHA2-512 SHA3-512 | 0x0063 0a 0e Hashes: [SHA2-512 SHA3-512 | |||
0x0065 08 0c SHA2-256 SHA3-256] | 0x0065 08 0c SHA2-256 SHA3-256] | |||
0x0067 02 subpkt length | 0x0067 02 subpkt length | |||
0x0068 16 subpkt type: Pref. Compression | 0x0068 16 subpkt type: Pref. Compression | |||
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: {v1SEIPD, v2SEIPD} | |||
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 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 | |||
skipping to change at line 7845 ¶ | skipping to change at line 7846 ¶ | |||
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 | |||
A.4. Sample v6 Secret Key (Transferable Secret Key) | A.4. Sample v6 Secret Key (Transferable Secret Key) | |||
Here is a Transferable Secret Key consisting of: | Here is a Transferable Secret Key consisting of: | |||
* A v6 Ed25519 Secret Key packet | * A version 6 Ed25519 Secret Key packet | |||
* A v6 Direct Key self-signature | * A version 6 Direct Key self-signature | |||
* A v6 X25519 Secret Subkey packet | * A version 6 X25519 Secret Subkey packet | |||
* A v6 Subkey Binding signature | * A version 6 Subkey Binding signature | |||
-----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 | |||
skipping to change at line 8811 ¶ | skipping to change at line 8812 ¶ | |||
-----END PGP MESSAGE----- | -----END PGP MESSAGE----- | |||
A.12. Sample Messages Encrypted Using Argon2 | A.12. Sample Messages Encrypted Using Argon2 | |||
These messages are the literal data Hello, world! encrypted using v1 | These messages are the literal data Hello, world! encrypted using v1 | |||
SEIPD, with Argon2 and the passphrase "password", using different | SEIPD, with Argon2 and the passphrase "password", using different | |||
session key sizes. In each example, the choice of symmetric cipher | session key sizes. In each example, the choice of symmetric cipher | |||
is the same in both the v4 SKESK packet and v1 SEIPD packet. In all | 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. | cases, the Argon2 parameters are t = 1, p = 4, and m = 21. | |||
A.12.1. Version 4 SKESK Using Argon2 with AES-128 | A.12.1. v4 SKESK Using Argon2 with AES-128 | |||
-----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----- | |||
A.12.2. Version 4 SKESK Using Argon2 with AES-192 | A.12.2. v4 SKESK Using Argon2 with AES-192 | |||
-----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----- | |||
A.12.3. Version 4 SKESK Using Argon2 with AES-256 | A.12.3. v4 SKESK Using Argon2 with AES-256 | |||
-----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----- | |||
skipping to change at line 8892 ¶ | skipping to change at line 8893 ¶ | |||
o OCB mode (Section 5.13.4) -- MTI | o OCB mode (Section 5.13.4) -- MTI | |||
o EAX mode (Section 5.13.3) | o EAX mode (Section 5.13.3) | |||
o GCM mode (Section 5.13.5) | o GCM mode (Section 5.13.5) | |||
- Version 6 PKESK (Section 5.1.2) | - Version 6 PKESK (Section 5.1.2) | |||
- Version 6 SKESK (Section 5.3.2) | - Version 6 SKESK (Section 5.3.2) | |||
- Features subpacket: add flag for SEIPDv2 (Section 5.2.3.32) | - Features signature subpacket: add flag for v2 SEIPD | |||
(Section 5.2.3.32) | ||||
- Subpacket: Preferred AEAD Ciphersuites (Section 5.2.3.15) | - Signature Subpacket: Preferred AEAD Ciphersuites | |||
(Section 5.2.3.15) | ||||
- Secret key encryption: AEAD "S2K usage octet" (Sections 3.7.2 | - Secret key encryption: AEAD "S2K usage octet" (Sections 3.7.2 | |||
and 5.5.3) | and 5.5.3) | |||
* Version 6 Keys and Signatures: | * Version 6 Keys and Signatures: | |||
- Version 6 Public Keys (Section 5.5.2.3) | - Version 6 Public Keys (Section 5.5.2.3) | |||
- Version 6 Fingerprint and Key ID (Section 5.5.4.3) | - Version 6 Fingerprint and Key ID (Section 5.5.4.3) | |||
skipping to change at line 8951 ¶ | skipping to change at line 8954 ¶ | |||
Curve25519Legacy (Section 9.2) | Curve25519Legacy (Section 9.2) | |||
- Digest Algorithms: | - Digest Algorithms: | |||
o Avoid MD5, SHA1, and RIPEMD160 (Section 9.5) | o Avoid MD5, SHA1, and RIPEMD160 (Section 9.5) | |||
- Symmetric Key Algorithms: | - Symmetric Key Algorithms: | |||
o Avoid IDEA, TripleDES, and CAST5 (Section 9.3) | o Avoid IDEA, TripleDES, and CAST5 (Section 9.3) | |||
- S2K Specifier Type: | - S2K Specifier: | |||
o Avoid Simple S2K (Section 3.7.1.1) | o Avoid Simple S2K (Section 3.7.1.1) | |||
- Secret Key Protections (a.k.a. S2K Usage): | - Secret Key Protections (a.k.a. S2K Usage): | |||
o Avoid MalleableCFB (Section 3.7.2.1) | o Avoid MalleableCFB (Section 3.7.2.1) | |||
- Packet Types: | - Packet Types: | |||
o Avoid Symmetrically Encrypted Data (Sections 5.7 and 13.7) | o Avoid Symmetrically Encrypted Data (Sections 5.7 and 13.7) | |||
skipping to change at line 9027 ¶ | skipping to change at line 9030 ¶ | |||
* "Certificate" was used ambiguously to mean multiple things. In | * "Certificate" was used ambiguously to mean multiple things. In | |||
this document, it means "Transferable Public Key" exclusively. | this document, it means "Transferable Public Key" exclusively. | |||
* "Preferred Symmetric Algorithms" was the old name for the | * "Preferred Symmetric Algorithms" was the old name for the | |||
"Preferred Symmetric Ciphers for v1 SEIPD" subpacket | "Preferred Symmetric Ciphers for v1 SEIPD" subpacket | |||
(Section 5.2.3.14). | (Section 5.2.3.14). | |||
* "Modification Detection Code" or "MDC" was originally described as | * "Modification Detection Code" or "MDC" was originally described as | |||
a distinct packet (Packet Type ID 19), and its corresponding flag | a distinct packet (Packet Type ID 19), and its corresponding flag | |||
in the Features subpacket (Section 5.2.3.32) was known as | in the Features signature subpacket (Section 5.2.3.32) was known | |||
"Modification Detection". It is now described as an intrinsic | as "Modification Detection". It is now described as an intrinsic | |||
part of v1 SEIPD (Section 5.13.1), and the same corresponding flag | part of v1 SEIPD (Section 5.13.1), and the same corresponding flag | |||
is known as "Symmetrically Encrypted and Integrity Protected Data | is known as "Version 1 Symmetrically Encrypted and Integrity | |||
packet version 1". | Protected Data packet". | |||
* "Packet Tag" was used to refer to the Packet Type ID (Section 5) | * "Packet Tag" was used to refer to the Packet Type ID (Section 5) | |||
or sometimes to the encoded Packet Type ID (Section 4.2). | or sometimes to the encoded Packet Type ID (Section 4.2). | |||
Appendix C. Errata Addressed by This Document | Appendix C. Errata Addressed by This Document | |||
The following verified errata have been incorporated or are otherwise | The following verified errata have been incorporated or are otherwise | |||
resolved by this document: | resolved by this document: | |||
* [Errata-2199] - S2K hash/cipher octet correction | * [Errata-2199] - S2K hash/cipher octet correction | |||
End of changes. 128 change blocks. | ||||
342 lines changed or deleted | 345 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |