From openpgp-2015-rfc4880bis-02 to librepgp-00
Werner Koch
wk at gnupg.org
Tue Jan 30 10:05:17 CET 2024
Hi!
Last November I published an updated draft of openpgp-2015-rfc2015-02
which is named librepgp-00. See
https://datatracker.ietf.org/doc/draft-koch-librepgp/
for the actual text and its history. Here comes a description of
the changes:
- Replaced the term "OpenPGP" by "LibrePGP" and briefliy explained the
new name.
- Minor copy edits
- Added algorithm specific parts for ML-KEM (Kyber) along with a note
that this part is still subject to change.
- Added brief description of Kyber. This needs to be extended.
- Added a note on when a message will be post-quantume secure.
- Mentioned version 6 signatures because of its 4 octet subpacket area
length headers. Added description of the salt parameter.
- Changed the encryption mode number number from a "SHOULD be 2" to a
"MUST be 2." That is to make OCB mandatory for the new AEAD packet.
- Added reference to FIPS-203.
- Moved the former authors into the acknowledgments section. Made Ron
and me the current authors.
- Credited the authors from the Wussler draft for PQC.
All in all these are minor changes except for v6 signature and PQC.
My idea with implementing and thus describing the v6 signatures was to
only allow a salt of length 0 and thus giving us the opportunity to
eventually increase the size of the subpacket areas. Only when
implementing this I realized that the hashing of the metadata from the
Literal Data Packet had been removed from the v5 signatures. So it
turned out that it is not possible to use the v6 specification to
increase the size of the subpacket area. I would thus suggest to remove
the v6 signature specification and come up with a new signature format
only iff we need to increase the subpacket area size.
The PQC things are just a start and I will write another mail to discuss
it.
Shalom-Salam,
Werner
--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
-------------- next part --------------
--- previous.txt 2024-01-30 09:08:18.123955859 +0100
+++ current.txt 2024-01-30 09:11:14.155950353 +0100
@@ -3,25 +3,21 @@
Network Working Group W. Koch
-Internet-Draft GnuPG e.V.
-Obsoletes: 4880, 5581, 6637 (if approved) B. Carlson
-Intended status: Standards Track
-Expires: 1 December 2023 R.H. Tse
- Ribose
- D.A. Atkins
-
- D.K. Gillmor
- 30 May 2023
+Internet-Draft g10 Code GmbH
+Obsoletes: 4880, 5581, 6637 (if approved) R. H. Tse
+Intended status: Standards Track Ribose
+Expires: 1 June 2024 29 November 2023
OpenPGP Message Format
- draft-koch-openpgp-2015-rfc4880bis-02
+ draft-koch-librepgp-00
Abstract
- This document specifies the message formats used in OpenPGP. OpenPGP
- provides encryption with public-key or symmetric cryptographic
- algorithms, digital signatures, compression and key management.
+ This document specifies the message formats used in OpenPGP.
+ OpenPGP is an extension of the OpenPGP format which provides
+ encryption with public-key or symmetric cryptographic algorithms,
+ digital signatures, compression and key management.
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on the
@@ -32,8 +28,8 @@
It does, however, discuss implementation issues necessary to avoid
security flaws.
- This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia in
- OpenPGP) and RFC 6637 (Elliptic Curves in OpenPGP).
+ This document is based on: RFC 4880 (OpenPGP), RFC 5581 (Camellia in
+ OpenPGP), and RFC 6637 (Elliptic Curves in OpenPGP).
Status of This Memo
@@ -49,8 +45,8 @@
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
- This Internet-Draft will expire on 1 December 2023.
+ This Internet-Draft will expire on 1 June 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
@@ -75,13 +71,19 @@
replaces RFC 1991, "PGP Message Exchange Formats" [RFC1991] [RFC2440]
[RFC4880].
- This document obsoletes: RFC 4880 (OpenPGP), RFC 5581 (Camellia
- cipher) and RFC 6637 (ECC for OpenPGP).
+ OpenPGP is fully compatible to the OpenPGP specification it is based
+ on: RFC 4880 (OpenPGP), RFC 5581 (Camellia cipher), and RFC 6637 (ECC
+ for OpenPGP).
1.1. Terms
+ * OpenPGP - This is a term for security software that is based on
+ OpenPGP with updates for newer algorithms and an advertency to
+ long-term stability and critical deployments. It is formalized in
+ this document.
+
* OpenPGP - This is a term for security software that uses PGP 5 as
- a basis, formalized in this document.
+ a basis.
* PGP - Pretty Good Privacy. PGP is a family of software systems
developed by Philip R. Zimmermann from which OpenPGP is based.
@@ -95,16 +96,18 @@
community. It has new formats and corrects a number of problems
in the PGP 2 design. It is referred to here as PGP 5 because that
software was the first release of the "PGP 3" code base.
+
* GnuPG - GNU Privacy Guard, also called GPG, is the leading Open
- Source implementation of OpenPGP and has been developed along with
- the OpenPGP standard since 1997.
+ Source implementation of OpenPGP and OpenPGP and has been
+ developed along with the OpenPGP standard since 1997.
- * RNP - Ribose Network PGP is a newer OpenPGP implemention and
- prominently used by the mail client Thunderbird.
+ * RNP - Ribose Network PGP is a newer OpenPGP and OpenPGP
+ implemention and prominently used by the mail client Thunderbird.
"PGP" is a trademark of CA, INC. The use of this, or any other,
- marks is solely for identification purposes. The term "OpenPGP"
- refers to the protocol described in this and related documents.
+ marks is solely for identification purposes. The terms "OpenPGP" and
+ "OpenPGP" refer to the protocol described in this and related
+ documents.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@@ -157,8 +160,8 @@
5. The receiving OpenPGP decrypts the session key using the
recipient's private key.
- 6. The receiving OpenPGP decrypts the message using the session key.
- If the message was compressed, it will be decompressed.
+ 6. The receiving OpenPGP decrypts the message using the session
+ key. If the message was compressed, it will be decompressed.
With symmetric-key encryption, an object may be encrypted with a
symmetric key derived from a passphrase (or other shared secret), or
@@ -198,8 +201,8 @@
the signature but before encryption.
If an implementation does not implement compression, its authors
- should be aware that most OpenPGP messages in the world are
- compressed. Thus, it may even be wise for a space-constrained
+ should be aware that most OpenPGP and OpenPGP messages in the world
+ are compressed. Thus, it may even be wise for a space-constrained
implementation to implement decompression, but not compression.
Furthermore, compression has the added side effect that some types of
@@ -345,7 +348,7 @@
key.
If the hash size is less than the key size, multiple instances of the
- hash context are created -- enough to produce the required key data.
+ hash context are created --- enough to produce the required key data.
These instances are preloaded with 0, 1, 2, ... octets of zeros (that
is to say, the first instance has no preloading, the second gets
preloaded with 1 octet of zero, the third is preloaded with two
@@ -357,11 +360,10 @@
hashed, the output data from the multiple hashes is concatenated,
first hash leftmost, to produce the key data, with any excess octets
on the right discarded.
-
3.7.1.2. Salted S2K
- This includes a "salt" value in the S2K specifier -- some arbitrary
- data -- that gets hashed along with the passphrase string, to help
+ This includes a "salt" value in the S2K specifier --- some arbitrary
+ data --- that gets hashed along with the passphrase string, to help
prevent dictionary attacks.
Octet 0: 0x01
@@ -442,14 +445,14 @@
These are followed by an Initial Vector of the same length as the
block size of the cipher for the decryption of the secret values, if
they are encrypted, and then the secret-key values themselves.
-
3.7.2.2. Symmetric-Key Message Encryption
- OpenPGP can create a Symmetric-key Encrypted Session Key (ESK) packet
- at the front of a message. This is used to allow S2K specifiers to
- be used for the passphrase conversion or to create messages with a
- mix of symmetric-key ESKs and public-key ESKs. This allows a message
- to be decrypted either with a passphrase or a public-key pair.
+ OpenPGP can create a Symmetric-key Encrypted Session Key (ESK)
+ packet at the front of a message. This is used to allow S2K
+ specifiers to be used for the passphrase conversion or to create
+ messages with a mix of symmetric-key ESKs and public-key ESKs. This
+ allows a message to be decrypted either with a passphrase or a
+ public-key pair.
PGP 2 always used IDEA with Simple string-to-key conversion when
encrypting a message with a symmetric algorithm. This is deprecated,
@@ -465,7 +469,8 @@
tag specifying its meaning. An OpenPGP message, keyring,
certificate, and so forth consists of a number of packets. Some of
those packets may contain other OpenPGP packets (for example, a
- compressed data packet, when uncompressed, contains OpenPGP packets).
+ compressed data packet, when uncompressed, contains OpenPGP
+ packets).
Each packet consists of a packet header, followed by the packet body.
The packet header is of variable length.
@@ -723,10 +727,27 @@
Algorithm-Specific Fields for ECDH encryption:
- MPI of an EC point representing an ephemeral public key.
-
- a one-octet size, followed by a symmetric key encoded using the
method described in Section 13.5.
+ Algorithm-Specific Fields for ML-KEM (Kyber) encryption: {Note:
+ This part is not finalized and subject to change}
+
+ - A fixed-length octet string representing an ECC ephemeral
+ public key in the format associated with the curve. For ML-
+ KEM-768+X25519 these are 32 octets, for ML-KEM-1024+X448 these
+ are 56 octets.
+
+ - A fixed-length octet string of the ML-KEM ciphertext, whose
+ length depends on the algorithm. For ML-KEM-768+X25519 these
+ are 1088 octets, for ML-KEM-1024+X448 these are 1568 octets.
+
+ - A one-octet algorithm identifier which must indicate one of the
+ AES algorithms (7, 8, or 9).
+
+ - a one-octet size, followed by a symmetric key wrapped using the
+ method described in Section 14.1.
+
The value "m" in the above formulas is derived from the session key
as follows. First, the session key is prefixed with a one-octet
algorithm identifier that specifies the symmetric encryption
@@ -735,17 +756,21 @@
sum of the preceding session key octets, not including the algorithm
identifier, modulo 65536. This value is then encoded as described in
PKCS#1 block encoding EME-PKCS1-v1_5 in Section 7.2.1 of [RFC3447] to
- form the "m" value used in the formulas above. See Section 14.1 of
+ form the "m" value used in the formulas above. See Section 15.1 of
this document for notes on OpenPGP's use of PKCS#1.
+
Note that when an implementation forms several PKESKs with one
session key, forming a message that can be decrypted by several keys,
- the implementation MUST make a new PKCS#1 encoding for each key.
+ the implementation MUST make a new PKCS#1 encoding or for each key.
An implementation MAY accept or use a Key ID of zero as a "wild card"
or "speculative" Key ID. In this case, the receiving implementation
would try all available private keys, checking for a valid decrypted
session key. This format helps reduce traffic analysis of messages.
+ Note that the confidentiality of a message is only post-quantum
+ secure when encrypting to multiple recipients iff only ML-KEM
+ algorithms are used for all recipients.
5.2. Signature Packet (Tag 2)
A Signature packet describes a binding between some public key and
@@ -753,14 +778,15 @@
block of text, and a signature that is a certification of a User ID.
Three versions of Signature packets are defined. Version 3 provides
- basic signature information, while versions 4 and 5 provide an
+ basic signature information, while versions 4, 5, and 6 provide an
expandable format with subpackets that can specify more information
about the signature. PGP 2.6.x only accepts version 3 signatures.
Implementations MUST generate version 5 signatures when using a
- version 5 key. Implementations SHOULD generate V4 signatures with
- version 4 keys. Implementations MUST NOT create version 3
- signatures; they MAY accept version 3 signatures.
+ version 5 key. Version 6 signature MAY be generated if larger
+ subpacket data needs to be used. Implementations SHOULD generate V4
+ signatures with version 4 keys. Implementations MUST NOT create
+ version 3 signatures; they MAY accept version 3 signatures.
5.2.1. Signature Types
@@ -804,22 +829,25 @@
0x13 Positive certification of a User ID and Public-Key packet. The
issuer of this certification has done substantial verification of
- the claim of identity. Most OpenPGP implementations make their
- "key signatures" as 0x10 certifications. Some implementations can
- issue 0x11-0x13 certifications, but few differentiate between the
- types.
+ the claim of identity.
+
+ Most OpenPGP implementations make their "key signatures" as 0x10
+ certifications. Some implementations can issue 0x11-0x13
+ certifications, but few differentiate between the types.
0x16 Attested Key Signature. This signature is issued by the
primary key over itself and its User ID (or User Attribute). It
MUST contain an "Attested Certifications" subpacket and a
"Signature Creation Time" subpacket. This type of key signature
does not replace or override any standard certification
- (0x10-0x13). Only the most recent Attestation Key Signature is
- valid for any given <key,userid> pair. If more than one
- Certification Attestation Key Signature is present with the same
- Signature Creation Time, the set of attestations should be treated
- as the union of all "Attested Certifications" subpackets from all
- such signatures with the same timestamp.
+ (0x10-0x13).
+
+ Only the most recent Attestation Key Signature is valid for any
+ given <key,userid> pair. If more than one Certification
+ Attestation Key Signature is present with the same Signature
+ Creation Time, the set of attestations should be treated as the
+ union of all "Attested Certifications" subpackets from all such
+ signatures with the same timestamp.
0x18 Subkey Binding Signature. This signature is a statement by the
top-level signing key that indicates that it owns the subkey.
@@ -992,10 +1020,10 @@
5.2.3. Version 4 and 5 Signature Packet Formats
- The body of a V4 or V5 Signature packet contains:
+ The body of a V4, V5, and V6 Signature packet contains:
- * One-octet version number. This is 4 for V4 signatures and 5 for
- V5 signatures.
+ * One-octet version number. This is 4 for V4 signatures, 5 for V5
+ signatures, and 6 vor V6 signature.
* One-octet signature type.
@@ -1003,21 +1031,30 @@
* One-octet hash algorithm.
* Two-octet scalar octet count for following hashed subpacket data.
- Note that this is the length in octets of all of the hashed
- subpackets; a pointer incremented by this number will skip over
- the hashed subpackets.
+ For V6 signatures this is a four-octet field. Note that this is
+ the length in octets of all of the hashed subpackets; a pointer
+ incremented by this number will skip over the hashed subpackets.
* Hashed subpacket data set (zero or more subpackets).
* Two-octet scalar octet count for the following unhashed subpacket
- data. Note that this is the length in octets of all of the
- unhashed subpackets; a pointer incremented by this number will
- skip over the unhashed subpackets.
+ data. For V6 signatures this is a four-octet field. Note that
+ this is the length in octets of all of the unhashed subpackets; a
+ pointer incremented by this number will skip over the unhashed
+ subpackets.
* Unhashed subpacket data set (zero or more subpackets).
* Two-octet field holding the left 16 bits of the signed hash value.
+ * Only for V6 signatures, a variable-length field containing:
+
+ - A one-octet salt size. If salted signatures are used the value
+ SHOULD match the digest length of the hash algorithm. The
+ common use case is not to use salted signatures.
+
+ - The salt; a random value of the specified size.
+
* One or more multiprecision integers comprising the signature.
This portion is algorithm specific:
@@ -1436,15 +1472,16 @@
(1 octet of class, 1 octet of public-key algorithm ID, 20 or 32
octets of fingerprint)
- V4 keys use the full 20 octet fingerprint; V5 keys use the full 32
- octet fingerprint
-
+ V4 keys use the full 20 octet fingerprint; V4 keys with the Class
+ octet bit 0x20 set use the extended 32 octet v4 fingerprint; V5 keys
+ use the full 32 octet fingerprint.
Authorizes the specified key to issue revocation signatures for this
key. Class octet must have bit 0x80 set. If the bit 0x40 is set,
- then this means that the revocation information is sensitive. Other
- bits are for future expansion to other kinds of authorizations. This
- is only found on a direct-key self-signature (type 0x1f). The use on
- other types of self-signatures is unspecified.
+ then this means that the revocation information is sensitive. Bit
+ 0x20 is used as described above. Other bits are for future expansion
+ to other kinds of authorizations. This is only found on a direct-key
+ self-signature (type 0x1f). The use on other types of self-
+ signatures is unspecified.
If the "sensitive" flag is set, the keyholder feels this subpacket
contains private trust information that describes a real-world
@@ -1634,8 +1671,9 @@
subpacket applies only to User ID packets. When appearing on a self-
signature on a User Attribute packet, this subpacket applies only to
User Attribute packets. That is to say, there are two different and
- independent "primaries" -- one for User IDs, and one for User
+ independent "primaries" --- one for User IDs, and one for User
Attributes.
+
5.2.3.22. Policy URI
(String)
@@ -1681,15 +1718,16 @@
The flags in this packet may appear in self-signatures or in
certification signatures. They mean different things depending on
- who is making the statement -- for example, a certification signature
- that has the "sign data" flag is stating that the certification is
- for that use. On the other hand, the "communications encryption"
- flag in a self-signature is stating a preference that a given key be
- used for communications. Note however, that it is a thorny issue to
- determine what is "communications" and what is "storage". This
- decision is left wholly up to the implementation; the authors of this
- document do not claim any special wisdom on the issue and realize
- that accepted opinion may change.
+ who is making the statement --- for example, a certification
+ signature that has the "sign data" flag is stating that the
+ certification is for that use. On the other hand, the
+ "communications encryption" flag in a self-signature is stating a
+ preference that a given key be used for communications. Note
+ however, that it is a thorny issue to determine what is
+ "communications" and what is "storage". This decision is left wholly
+ up to the implementation; the authors of this document do not claim
+ any special wisdom on the issue and realize that accepted opinion may
+ change.
The "split key" (1st,0x10) and "group key" (1st,0x80) flags are
placed on a self-signature only; they are meaningless on a
@@ -1928,9 +1967,8 @@
of class 0x00, 0x01, or 0x02. It MUST contain the key used to create
the signature; either as the primary key or as a subkey. The key
SHOULD contain a primary or subkey capable of encryption and the
- entire key must be a valid OpenPGP key including at least one User ID
- packet and the corresponding self-signatures.
-
+ entire key must be a valid OpenPGP key including at least one User
+ ID packet and the corresponding self-signatures.
Implementations MUST ignore this subpacket if the first octet does
not have a value of zero or if the key data does not represent a
valid transferable public key.
@@ -1960,6 +1999,8 @@
All signatures are formed by producing a hash over the signature
data, and then using the resulting hash in the signature algorithm.
+ When a V6 signature with a salt is made, the salt is hashed first.
+
For binary document signatures (type 0x00), the document data is
hashed directly. For text document signatures (type 0x01), the
document is canonicalized by converting line endings to <CR><LF>, and
@@ -1967,16 +2008,15 @@
When a V4 signature is made over a key, the hash data starts with the
octet 0x99, followed by a two-octet length of the key, and then body
- of the key packet; when a V5 signature is made over a key, the hash
- data starts with the octet 0x9a, followed by a four-octet length of
- the key, and then body of the key packet. A subkey binding signature
- (type 0x18) or primary key binding signature (type 0x19) then hashes
- the subkey using the same format as the main key (also using 0x99 or
- 0x9a as the first octet). Primary key revocation signatures (type
- 0x20) hash only the key being revoked. Subkey revocation signature
- (type 0x28) hash first the primary key and then the subkey being
- revoked.
-
+ of the key packet; when a V5 or V6 signature is made over a key, the
+ hash data starts with the octet 0x9a for V5 and 0x9b for V6, followed
+ by a four-octet length of the key, and then body of the key packet.
+ A subkey binding signature (type 0x18) or primary key binding
+ signature (type 0x19) then hashes the subkey using the same format as
+ the main key (also using 0x99 or 0x9a as the first octet). Primary
+ key revocation signatures (type 0x20) hash only the key being
+ revoked. Subkey revocation signature (type 0x28) hash first the
+ primary key and then the subkey being revoked.
A certification signature (type 0x10 through 0x13) hashes the User ID
being bound to the key into the hash context after the above data. A
V3 certification hashes the contents of the User ID or attribute
@@ -2022,10 +2063,9 @@
- the hashed subpacket body,
- the two octets 0x04 and 0xFF,
-
- a four-octet big-endian number that is the length of the hashed
data from the Signature packet stopping right before the 0x04,
- 0xff octets.
+ 0XFF octets.
The four-octet big-endian number is considered to be an
unsigned integer modulo 2^32.
@@ -2047,23 +2088,20 @@
- Only for document signatures (type 0x00 or 0x01) the following
three data items are hashed here:
-
- o the one-octet content format,
-
- o the file name as a string (one octet length, followed by the
- file name),
-
- o a four-octet number that indicates a date,
-
+ - the one-octet content format,
+ - the file name as a string (one octet length, followed by
+ the file name),
+ - a four-octet number that indicates a date,
- the two octets 0x05 and 0xFF,
- - a eight-octet big-endian number that is the length of the
- hashed data from the Signature packet stopping right before the
- 0x05, 0xff octets.
-
- The three data items hashed for document signatures need to
- mirror the values of the Literal Data packet. For detached and
- cleartext signatures 6 zero bytes are hashed instead.
+ - a eight-octet big-endian number that is the length
+ of the hashed data from the Signature packet
+ stopping right before the 0x05, 0XFF octets.
+
+ The three data items hashed for document signatures need to mirror
+ the values of the Literal Data packet. Note that for a detached
+ signatures this means to hash 6 0x00 octets and for a cleartext
+ signature this means to hash a 't' followed by 5 0x00 octets.
After all this has been hashed in a single hash context, the
resulting hash field is used in the signature algorithm and placed at
@@ -2082,7 +2119,7 @@
generous in what they accept, while putting pressure on a creator to
be stingy in what they generate.
- Some apparent conflicts may actually make sense -- for example,
+ Some apparent conflicts may actually make sense --- for example,
suppose a keyholder has a V3 key and a V4 key that share the same RSA
key material. Either of these keys can verify a signature created by
the other, and it may be reasonable for a signature to contain an
@@ -2142,7 +2179,7 @@
* A one-octet cipher algorithm.
- * A one-octet encryption mode number which SHOULD be 2 to indicate
+ * A one-octet encryption mode number which MUST be 2 to indicate
OCB.
* A string-to-key (S2K) specifier, length as defined above.
@@ -2175,7 +2211,8 @@
The body of this packet consists of:
- * A one-octet version number. The current version is 3.
+ * A one-octet version number. The currently specified versions are
+ 3 and 6.
* A one-octet signature type. Signature types are described in
Section 5.2.1.
@@ -2179,11 +2216,26 @@
* A one-octet signature type. Signature types are described in
Section 5.2.1.
+
* A one-octet number describing the hash algorithm used.
* A one-octet number describing the public-key algorithm used.
- * An eight-octet number holding the Key ID of the signing key.
+ * Only for V6 signatures, a variable-length field containing:
+
+ - A one-octet salt size. If salted signatures are used the value
+ SHOULD match the digest length of the hash algorithm. The
+ common use case is not to use salted signatures.
+
+ - The salt; a random value of the specified size. The value MUST
+ match the salt field of the corresponding Signature packet.
+
+ * Only for V3 signatures: an eight-octet number holding the Key ID
+ of the signing key.
+
+ * Only for V6 sigmatures: a one octet key version number and N
+ octets of the fingerprint of the signing key. Note that the
+ length N of the fingerprint for a version 6 key is 32.
* A one-octet number holding a flag showing whether the signature is
nested. A zero value indicates that the next packet is another
@@ -2537,6 +2588,35 @@
* MPI of an integer representing the secret key, which is a scalar
of the public EC point.
+
+5.6.7. Algorithm-Specific Part for ML-KEM Keys
+
+ {Note: This part is not finalized and subject to change}
+
+ The public key is this series of values:
+
+ * A fixed-length octet string representing an ECC public key in the
+ format associated with the curve. For ML-KEM-768+X25519 these are
+ 32 octets, for ML-KEM-1024+X448 these are 56 octets.
+
+ * A fixed-length octet string containing the ML-KEM public key,
+ whose length depends on the algorithm. For ML-KEM-768+X25519
+ these are 1184 octets, for ML-KEM-1024+X448 these are 1568 octets.
+
+ The secret key is this series of values:
+
+ * A fixed-length octet string of the encoded secret scalar, whose
+ encoding and length depend on the algorithm. For ML-KEM-
+ 768+X25519 these are 32 octets, for ML-KEM-1024+X448 these are 56
+ octets.
+
+ * A fixed-length octet string containing the ML-KEM secret key,
+ whose length depends on the algorithm. For ML-KEM-768+X25519
+ these are 2400 octets, for ML-KEM-1024+X448 these are 3168 octets.
+
+ Observe that the format of the ECC keys differ from the format used
+ with ECDH. This has been chosen to avoid prefix octets.
+
5.7. Compressed Data Packet (Tag 8)
The Compressed Data packet contains compressed data. Typically, this
@@ -2769,10 +2849,9 @@
examination of the image data if it is unable to handle a particular
version of the image header or if a specified encoding format value
is not recognized.
-
5.13.2. User ID Attribute Subpacket
- A User ID Attribute subpacket has type [IANA -- assignment TBD1].
+ A User ID Attribute subpacket has type [IANA --- assignment TBD1].
A User ID Attribute subpacket, just like a User ID packet, consists
of UTF-8 text that is intended to represent the name and email
@@ -2790,8 +2869,8 @@
The Symmetrically Encrypted Integrity Protected Data packet is a
variant of the Symmetrically Encrypted Data packet. It is a new
- feature created for OpenPGP that addresses the problem of detecting a
- modification to encrypted data. It is used in combination with a
+ feature created for OpenPGP that addresses the problem of detecting
+ a modification to encrypted data. It is used in combination with a
Modification Detection Code packet.
There is a corresponding feature in the features Signature subpacket
@@ -3138,10 +3215,10 @@
6.2. Forming ASCII Armor
When OpenPGP encodes data into ASCII Armor, it puts specific headers
- around the Radix-64 encoded data, so OpenPGP can reconstruct the data
- later. An OpenPGP implementation MAY use ASCII armor to protect raw
- binary data. OpenPGP informs the user what kind of data is encoded
- in the ASCII armor through the use of the headers.
+ around the Radix-64 encoded data, so OpenPGP can reconstruct the
+ data later. An OpenPGP implementation MAY use ASCII armor to
+ protect raw binary data. OpenPGP informs the user what kind of data
+ is encoded in the ASCII armor through the use of the headers.
Concatenating the following data creates ASCII Armor:
* An Armor Header Line, appropriate for the type of data
@@ -3183,17 +3260,17 @@
line. That is to say, there is always a line ending preceding the
starting five dashes, and following the ending five dashes. The
header lines, therefore, MUST start at the beginning of a line, and
- MUST NOT have text other than whitespace -- space (0x20), tab (0x09)
- or carriage return (0x0d) -- following them on the same line. These
+ MUST NOT have text other than whitespace --- space (0x20), tab (0x09)
+ or carriage return (0x0d) --- following them on the same line. These
line endings are considered a part of the Armor Header Line for the
purposes of determining the content they delimit. This is
particularly important when computing a cleartext signature (see
below).
The Armor Headers are pairs of strings that can give the user or the
- receiving OpenPGP implementation some information about how to decode
- or use the message. The Armor Headers are a part of the armor, not a
- part of the message, and hence are not protected by any signatures
- applied to the message.
+ receiving OpenPGP implementation some information about how to
+ decode or use the message. The Armor Headers are a part of the
+ armor, not a part of the message, and hence are not protected by any
+ signatures applied to the message.
The format of an Armor Header is that of a key-value pair. A colon
(: 0x38) and a single space (0x20) separate the key and value.
@@ -3214,9 +3291,9 @@
* "Version", which states the OpenPGP implementation and version
used to encode the message.
- * "Comment", a user-defined comment. OpenPGP defines all text to be
- in UTF-8. A comment may be any UTF-8 string. However, the whole
- point of armoring is to provide seven-bit-clean data.
+ * "Comment", a user-defined comment. OpenPGP defines all text to
+ be in UTF-8. A comment may be any UTF-8 string. However, the
+ whole point of armoring is to provide seven-bit-clean data.
Consequently, if a comment has characters that are outside the US-
ASCII range of UTF, they may very well not survive transport.
@@ -3431,9 +3508,9 @@
"- " if it occurs at the beginning of a line, and SHOULD warn on "-"
and any character other than a space at the beginning of a line.
- Also, any trailing whitespace -- spaces (0x20), tabs (0x09) or
- carriage returns (0x0d) -- at the end of any line is removed when the
- cleartext signature is generated and verified.
+ Also, any trailing whitespace --- spaces (0x20), tabs (0x09) or
+ carriage returns (0x0d) --- at the end of any line is removed when
+ the cleartext signature is generated and verified.
8. Regular Expressions
@@ -3479,36 +3556,37 @@
9.1. Public-Key Algorithms
- +=========+===================================================+
+ +=======+===================================================+
| ID | Algorithm |
- +=========+===================================================+
+ +=======+===================================================+
| 1 | RSA (Encrypt or Sign) [HAC] |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 2 | RSA Encrypt-Only [HAC] |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 3 | RSA Sign-Only [HAC] |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 16 | Elgamal (Encrypt-Only) [ELGAMAL] [HAC] |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 17 | DSA (Digital Signature Algorithm) [FIPS186] [HAC] |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 18 | ECDH public key algorithm |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 19 | ECDSA public key algorithm [FIPS186] |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 20 | Reserved (formerly Elgamal Encrypt or Sign) |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 21 | Reserved for Diffie-Hellman (X9.42, as defined |
| | for IETF-S/MIME) |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 22 | EdDSA [RFC8032] |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 23 | Reserved for AEDH |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
| 24 | Reserved for AEDSA |
- +---------+---------------------------------------------------+
- | 100-110 | Private/Experimental algorithm |
- +---------+---------------------------------------------------+
+ +-------+---------------------------------------------------+
+ | 100-- | Private/Experimental algorithm |
+ | 110 | |
+ +-------+---------------------------------------------------+
Table 6
@@ -3517,8 +3595,8 @@
implement EdDSA (22) keys.
RSA Encrypt-Only (2) and RSA Sign-Only (3) are deprecated and SHOULD
- NOT be generated, but may be interpreted. See Section 14.5. See
- Section 14.9 for notes on Elgamal Encrypt or Sign (20), and X9.42
+ NOT be generated, but may be interpreted. See Section 15.5. See
+ Section 15.9 for notes on Elgamal Encrypt or Sign (20), and X9.42
(21). Implementations MAY implement any other algorithm.
Note that implementations conforming to previous versions of this
@@ -3587,44 +3665,46 @@
9.3. Symmetric-Key Algorithms
- +=========+======================================+
+ +=======+======================================+
| ID | Algorithm |
- +=========+======================================+
+ +=======+======================================+
| 0 | Plaintext or unencrypted data |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 1 | IDEA [IDEA] |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 2 | TripleDES (DES-EDE, [SCHNEIER] [HAC] |
| | - 168 bit key derived from 192) |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 3 | CAST5 (128 bit key, as per |
| | [RFC2144]) |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 4 | Blowfish (128 bit key, 16 rounds) |
| | [BLOWFISH] |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 5 | Reserved |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 6 | Reserved |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 7 | AES with 128-bit key [AES] |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 8 | AES with 192-bit key |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 9 | AES with 256-bit key |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 10 | Twofish with 256-bit key [TWOFISH] |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 11 | Camellia with 128-bit key [RFC3713] |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 12 | Camellia with 192-bit key |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
| 13 | Camellia with 256-bit key |
- +---------+--------------------------------------+
- | 100-110 | Private/Experimental algorithm |
- +---------+--------------------------------------+
+ +-------+--------------------------------------+
+ | 100-- | Private/Experimental algorithm |
+ | 110 | |
+ +-------+--------------------------------------+
Table 8
+
Implementations MUST implement AES-128. Implementations SHOULD
implement AES-256. Implementations that interoperate with RFC-4880
implementations need to support TripleDES and CAST5. Implementations
@@ -3634,19 +3714,19 @@
9.4. Compression Algorithms
- +=========+================================+
+ +==========+================================+
| ID | Algorithm |
- +=========+================================+
+ +==========+================================+
| 0 | Uncompressed |
- +---------+--------------------------------+
+ +----------+--------------------------------+
| 1 | ZIP [RFC1951] |
- +---------+--------------------------------+
+ +----------+--------------------------------+
| 2 | ZLIB [RFC1950] |
- +---------+--------------------------------+
+ +----------+--------------------------------+
| 3 | BZip2 [BZ2] |
- +---------+--------------------------------+
- | 100-110 | Private/Experimental algorithm |
- +---------+--------------------------------+
+ +----------+--------------------------------+
+ | 100--110 | Private/Experimental algorithm |
+ +----------+--------------------------------+
Table 9
@@ -3657,39 +3737,39 @@
9.5. Hash Algorithms
- +=========+================================+=============+
+ +==========+================================+=============+
| ID | Algorithm | Text Name |
- +=========+================================+=============+
+ +==========+================================+=============+
| 1 | MD5 [HAC] | "MD5" |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 2 | SHA-1 [FIPS180] | "SHA1" |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 3 | RIPE-MD/160 [HAC] | "RIPEMD160" |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 4 | Reserved | |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 5 | Reserved | |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 6 | Reserved | |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 7 | Reserved | |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 8 | SHA2-256 [FIPS180] | "SHA256" |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 9 | SHA2-384 [FIPS180] | "SHA384" |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 10 | SHA2-512 [FIPS180] | "SHA512" |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 11 | SHA2-224 [FIPS180] | "SHA224" |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 12 | SHA3-256 [FIPS202] | "SHA3-256" |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 13 | Reserved | |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
| 14 | SHA3-512 [FIPS202] | "SHA3-512" |
- +---------+--------------------------------+-------------+
- | 100-110 | Private/Experimental algorithm | |
- +---------+--------------------------------+-------------+
+ +----------+--------------------------------+-------------+
+ | 100--110 | Private/Experimental algorithm | |
+ +----------+--------------------------------+-------------+
Table 10
@@ -3721,16 +3802,15 @@
of considerations for allocating parameters for extensions. This
section describes how IANA should look at extensions to the protocol
as described in this document.
-
{ FIXME: Also add forward references, like "The list of S2K specifier
types is maintained by IANA as described in Section 10." }
10.1. New String-to-Key Specifier Types
- OpenPGP S2K specifiers contain a mechanism for new algorithms to turn
- a string into a key. This specification creates a registry of S2K
- specifier types. The registry includes the S2K type, the name of the
- S2K, and a reference to the defining specification. The initial
+ OpenPGP S2K specifiers contain a mechanism for new algorithms to
+ turn a string into a key. This specification creates a registry of
+ S2K specifier types. The registry includes the S2K type, the name of
+ the S2K, and a reference to the defining specification. The initial
values for this registry can be found in Section 3.7.1. Adding a new
S2K specifier MUST be done through the SPECIFICATION REQUIRED method,
as described in [RFC8126].
@@ -3896,13 +3976,13 @@
Adding a new feature-implementation flag MUST be done through the
SPECIFICATION REQUIRED method, as described in [RFC8126].
- Also see Section 14.12 for more information about when feature flags
+ Also see Section 15.12 for more information about when feature flags
are needed.
10.2.4. New Packet Versions
- The core OpenPGP packets all have version numbers, and can be revised
- by introducing a new version of an existing packet. This
+ The core OpenPGP packets all have version numbers, and can be
+ revised by introducing a new version of an existing packet. This
specification creates a registry of packet types. The registry
includes the packet type, the number of the version, and a reference
to the defining specification. The initial values for this registry
@@ -3937,7 +4017,7 @@
+====+============================+========================+
| ID | Algorithm | Reference |
+====+============================+========================+
- | 22 | EdDSA public key algorithm | This doc, Section 14.8 |
+ | 22 | EdDSA public key algorithm | This doc, Section 15.8 |
+----+----------------------------+------------------------+
| 23 | Reserved for AEDH | This doc |
+----+----------------------------+------------------------+
@@ -4084,15 +4164,15 @@
11.2. Transferable Secret Keys
- OpenPGP users may transfer secret keys. The format of a transferable
- secret key is the same as a transferable public key except that
- secret-key and secret-subkey packets are used instead of the public
- key and public-subkey packets. Implementations SHOULD include self-
- signatures on any User IDs and subkeys, as this allows for a complete
- public key to be automatically extracted from the transferable secret
- key. Implementations MAY choose to omit the self-signatures,
- especially if a transferable public key accompanies the transferable
- secret key.
+ OpenPGP users may transfer secret keys. The format of a
+ transferable secret key is the same as a transferable public key
+ except that secret-key and secret-subkey packets are used instead of
+ the public key and public-subkey packets. Implementations SHOULD
+ include self- signatures on any User IDs and subkeys, as this allows
+ for a complete public key to be automatically extracted from the
+ transferable secret key. Implementations MAY choose to omit the
+ self-signatures, especially if a transferable public key accompanies
+ the transferable secret key.
11.3. OpenPGP Messages
@@ -4262,8 +4342,8 @@
f.4) MPI of DSA public-key value y (= g**x mod p where x
is secret).
- Note that it is possible for there to be collisions of Key IDs -- two
- different keys with the same Key ID. Note that there is a much
+ Note that it is possible for there to be collisions of Key IDs ---
+ two different keys with the same Key ID. Note that there is a much
smaller, but still non-zero, probability that two different keys have
the same fingerprint.
@@ -4352,7 +4432,7 @@
A key derivation function (KDF) is necessary to implement the EC
encryption. The Concatenation Key Derivation Function (Approved
Alternative 1) [SP800-56A] with the KDF hash function that is
- SHA2-256 [FIPS180] or stronger is REQUIRED. See Section 16 for the
+ SHA2-256 [FIPS180] or stronger is REQUIRED. See Section 17 for the
details regarding the choice of the hash function.
For convenience, the synopsis of the encoding method is given below
@@ -4430,7 +4510,7 @@
The key wrapping method is described in [RFC3394]. KDF produces a
symmetric key that is used as a key-encryption key (KEK) as specified
- in [RFC3394]. Refer to Section 15 for the details regarding the
+ in [RFC3394]. Refer to Section 16 for the details regarding the
choice of the KEK algorithm, which SHOULD be one of three AES
algorithms. Key wrapping and unwrapping is performed with the
default initial value of [RFC3394].
@@ -4531,9 +4611,26 @@
Table 16
-14. Notes on Algorithms
+14. Post-Quantum Cryptography
-14.1. PKCS#1 Encoding in OpenPGP
+ {Note: This part is not finalized and subject to change}
+
+ This section descripes algorithms and parameters used with post-
+ quantum cryptography. Specifically, it defines composite public-key
+ encryption based on ML-KEM.
+
+14.1. Kyber Algorithm
+
+ ML-KEM [FIPS203], which is also known as CRYSTALS-Kyber, is based on
+ the hardness of solving the learning-with-errors problem in module
+ lattices (MLWE). The scheme is believed to provide security against
+ cryptanalytic attacks by classical as well as quantum computers.
+ This specification defines ML-KEM only in composite combination with
+ ECC-based encryption schemes in order to provide a pre-quantum
+ security fallback.
+
+15. Notes on Algorithms
+15.1. PKCS#1 Encoding in OpenPGP
This standard makes use of the PKCS#1 functions EME-PKCS1-v1_5 and
EMSA-PKCS1-v1_5. However, the calling conventions of these functions
@@ -4545,7 +4642,8 @@
contained document that avoids problems in the future with needed
changes in the conventions.
-14.1.1. EME-PKCS1-v1_5-ENCODE
+15.1.1. EME-PKCS1-v1_5-ENCODE
+
Input:
k = the length in octets of the key modulus.
@@ -4573,8 +4671,7 @@
4. Output EM.
-14.1.2. EME-PKCS1-v1_5-DECODE
-
+15.1.2. EME-PKCS1-v1_5-DECODE
Input:
EM = encoded message, an octet string
@@ -4595,10 +4692,10 @@
second octet of EM does not have hexadecimal value 0x02, if there is
no octet with hexadecimal value 0x00 to separate PS from M, or if the
length of PS is less than 8 octets, output "decryption error" and
- stop. See also the security note in Section 15 regarding differences
+ stop. See also the security note in Section 16 regarding differences
in reporting between a decryption error and a padding error.
-14.1.3. EMSA-PKCS1-v1_5
+15.1.3. EMSA-PKCS1-v1_5
This encoding method is deterministic and only has an encoding
operation.
@@ -4652,7 +4749,7 @@
6. Output EM.
-14.2. Symmetric Algorithm Preferences
+15.2. Symmetric Algorithm Preferences
The symmetric algorithm preference is an ordered list of algorithms
that the keyholder accepts. Since it is found on a self-signature,
@@ -4687,7 +4784,7 @@
warns her that someone sent her an IDEA-encrypted message, but it
would ideally decrypt it anyway.
-14.3. Other Algorithm Preferences
+15.3. Other Algorithm Preferences
Other algorithm preferences work similarly to the symmetric algorithm
preference, in that they specify which algorithms the keyholder
@@ -4695,7 +4792,7 @@
be made about, though, the compression preferences and the hash
preferences.
-14.3.1. Compression Preferences
+15.3.1. Compression Preferences
Compression has been an integral part of PGP since its first days.
OpenPGP and all previous versions of PGP have offered compression.
@@ -4719,7 +4816,7 @@
compressed message, since all implementations can handle messages
that have not been compressed.
-14.3.2. Hash Algorithm Preferences
+15.3.2. Hash Algorithm Preferences
Typically, the choice of a hash algorithm is something the signer
does, rather than the verifier, because a signer rarely knows who is
@@ -4735,14 +4832,14 @@
explicitly in the list, it is tacitly at the end. However, it is
good form to place it there explicitly.
-14.4. Plaintext
+15.4. Plaintext
Algorithm 0, "plaintext", may only be used to denote secret keys that
are stored in the clear. Implementations MUST NOT use plaintext in
Symmetrically Encrypted Data packets; they must use Literal Data
packets to encode unencrypted or literal data.
-14.5. RSA
+15.5. RSA
There are algorithm types for RSA Sign-Only, and RSA Encrypt-Only
keys. These types are deprecated. The "key flags" subpacket in a
@@ -4752,7 +4849,7 @@
An implementation SHOULD NOT implement RSA keys of size less than
1024 bits.
-14.6. DSA
+15.6. DSA
An implementation SHOULD NOT implement DSA keys of size less than
1024 bits. It MUST NOT implement a DSA key with a q size of less
@@ -4783,12 +4880,12 @@
able to handle signatures with a different q size or a truncated
hash.
-14.7. Elgamal
+15.7. Elgamal
An implementation SHOULD NOT implement Elgamal keys of size less than
1024 bits.
-14.8. EdDSA
+15.8. EdDSA
Although the EdDSA algorithm allows arbitrary data as input, its use
with OpenPGP requires that a digest of the message is used as input
@@ -4796,7 +4893,7 @@
details. Truncation of the resulting digest is never applied; the
resulting digest value is used verbatim as input to the EdDSA
algorithm.
-14.9. Reserved Algorithm Numbers
+15.9. Reserved Algorithm Numbers
A number of algorithm IDs have been reserved for algorithms that
would be useful to use in an OpenPGP implementation, yet there are
@@ -4814,7 +4911,7 @@
An implementation MUST NOT generate such keys. An implementation
MUST NOT generate Elgamal signatures. See [BLEICHENBACHER].
-14.10. OpenPGP CFB Mode
+15.10. OpenPGP CFB Mode
OpenPGP does symmetric encryption using a variant of Cipher Feedback
mode (CFB mode). This section describes the procedure it uses in
@@ -4829,8 +4926,8 @@
index of 1 (unlike the C language, which assumes arrays start with a
zero index).
- OpenPGP CFB mode uses an initialization vector (IV) of all zeros, and
- prefixes the plaintext with BS+2 octets of random data, such that
+ OpenPGP CFB mode uses an initialization vector (IV) of all zeros,
+ and prefixes the plaintext with BS+2 octets of random data, such that
octets BS+1 and BS+2 match octets BS-1 and BS. It does a CFB
resynchronization after encrypting those BS+2 octets.
@@ -4879,7 +4976,7 @@
the next BS octets of ciphertext. These are loaded into FR, and
the process is repeated until the plaintext is used up.
-14.11. Private or Experimental Parameters
+15.11. Private or Experimental Parameters
S2K specifiers, Signature subpacket types, User Attribute types,
image format types, and algorithms described in Section 9 all reserve
@@ -4891,7 +4988,7 @@
However, implementations need to be careful with these and promote
them to full IANA-managed parameters when they grow beyond the
original, limited system.
-14.12. Meta-Considerations for Expansion
+15.12. Meta-Considerations for Expansion
If OpenPGP is extended in a way that is not backwards-compatible,
meaning that old implementations will not gracefully handle their
@@ -4909,7 +5006,7 @@
explanation of why such an extension is unnecessary, the proposal
SHOULD be rejected.
-15. Security Considerations
+16. Security Considerations
* As with any technology involving cryptography, you should check
the current literature to determine if any algorithms used here
@@ -4967,8 +5064,8 @@
small vulnerabilities. For example, if an implementation does not
compress a message before encryption (perhaps because it knows it
was already compressed), then that message is vulnerable. Because
- of this happenstance -- that modification attacks can be thwarted
- by decompression errors -- an implementation SHOULD treat a
+ of this happenstance --- that modification attacks can be thwarted
+ by decompression errors --- an implementation SHOULD treat a
decompression error as a security problem, not merely a data
problem.
@@ -5152,9 +5249,9 @@
makes sense to combine the ID and image into a single signed packet
with a single signature.
-16. Compatibility Profiles
+17. Compatibility Profiles
-16.1. OpenPGP ECC Profile
+17.1. OpenPGP ECC Profile
A compliant application MUST implement NIST curve P-256, SHOULD
implement NIST curve P-521, SHOULD implement brainpoolP256r1 and
@@ -5166,7 +5263,7 @@
SHA2-384 and SHA2-512. A compliant application MUST implement
AES-128 and SHOULD implement AES-256.
- A compliant application SHOULD follow Section 15 regarding the choice
+ A compliant application SHOULD follow Section 16 regarding the choice
of the following algorithms for each curve:
* the KDF hash algorithm,
@@ -5180,7 +5277,7 @@
It is recommended that the chosen symmetric algorithm for message
encryption be no less secure than the KEK algorithm.
-17. Implementation Nits
+18. Implementation Nits
This section is a collection of comments to help an implementer,
particularly with an eye to backward compatibility. Previous
@@ -5246,9 +5343,9 @@
requirement for ASCII armor so those implementations will
necessarily have support.
-18. References
+19. References
-18.1. Normative References
+19.1. Normative References
[AES] NIST, "FIPS PUB 197, Advanced Encryption Standard (AES)",
November 2001,
@@ -5286,7 +5383,12 @@
Hash and Extendable-Output Functions, FIPS 202", August
2015, <http://dx.doi.org/10.6028/NIST.FIPS.202>.
- [HAC] Menezes, A.J., Oorschot, P.v., and S. Vanstone, "Handbook
+ [FIPS203] National Institute of Standards and Technology, U.S.
+ Department of Commerce, "Module-Lattice-Based Key-
+ Encapsulation Mechanism Standard", August 2023,
+ <https://doi.org/10.6028/NIST.FIPS.203.ipd>.
+
+ [HAC] Menezes, A. J., v Oorschot, P., and S. Vanstone, "Handbook
of Applied Cryptography", 1996.
[IDEA] Lai, X., "On the design and security of block ciphers",
@@ -5304,87 +5406,87 @@
[PKCS5] RSA Laboratories, "PKCS #5 v2.0: Password-Based
Cryptography Standard", 25 March 1999.
-
[RFC1950] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996,
- <https://www.rfc-editor.org/info/rfc1950>.
+ <https://www.rfc-editor.org/rfc/rfc1950>.
+
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
- <https://www.rfc-editor.org/info/rfc1951>.
+ <https://www.rfc-editor.org/rfc/rfc1951>.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
- <https://www.rfc-editor.org/info/rfc2045>.
+ <https://www.rfc-editor.org/rfc/rfc2045>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
- <https://www.rfc-editor.org/info/rfc2119>.
+ <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC2144] Adams, C., "The CAST-128 Encryption Algorithm", RFC 2144,
DOI 10.17487/RFC2144, May 1997,
- <https://www.rfc-editor.org/info/rfc2144>.
+ <https://www.rfc-editor.org/rfc/rfc2144>.
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
DOI 10.17487/RFC2822, April 2001,
- <https://www.rfc-editor.org/info/rfc2822>.
+ <https://www.rfc-editor.org/rfc/rfc2822>.
[RFC3156] Elkins, M., Del Torto, D., Levien, R., and T. Roessler,
"MIME Security with OpenPGP", RFC 3156,
DOI 10.17487/RFC3156, August 2001,
- <https://www.rfc-editor.org/info/rfc3156>.
+ <https://www.rfc-editor.org/rfc/rfc3156>.
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard
(AES) Key Wrap Algorithm", RFC 3394, DOI 10.17487/RFC3394,
- September 2002, <https://www.rfc-editor.org/info/rfc3394>.
+ September 2002, <https://www.rfc-editor.org/rfc/rfc3394>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
- 2003, <https://www.rfc-editor.org/info/rfc3447>.
+ 2003, <https://www.rfc-editor.org/rfc/rfc3447>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
- 2003, <https://www.rfc-editor.org/info/rfc3629>.
-
+ 2003, <https://www.rfc-editor.org/rfc/rfc3629>.
[RFC3713] Matsui, M., Nakajima, J., and S. Moriai, "A Description of
the Camellia Encryption Algorithm", RFC 3713,
DOI 10.17487/RFC3713, April 2004,
- <https://www.rfc-editor.org/info/rfc3713>.
+ <https://www.rfc-editor.org/rfc/rfc3713>.
+
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
- <https://www.rfc-editor.org/info/rfc4086>.
+ <https://www.rfc-editor.org/rfc/rfc4086>.
[RFC5639] Lochter, M. and J. Merkle, "Elliptic Curve Cryptography
(ECC) Brainpool Standard Curves and Curve Generation",
RFC 5639, DOI 10.17487/RFC5639, March 2010,
- <https://www.rfc-editor.org/info/rfc5639>.
+ <https://www.rfc-editor.org/rfc/rfc5639>.
[RFC5870] Mayrhofer, A. and C. Spanring, "A Uniform Resource
Identifier for Geographic Locations ('geo' URI)",
RFC 5870, DOI 10.17487/RFC5870, June 2010,
- <https://www.rfc-editor.org/info/rfc5870>.
+ <https://www.rfc-editor.org/rfc/rfc5870>.
[RFC7253] Krovetz, T. and P. Rogaway, "The OCB Authenticated-
Encryption Algorithm", RFC 7253, DOI 10.17487/RFC7253, May
- 2014, <https://www.rfc-editor.org/info/rfc7253>.
+ 2014, <https://www.rfc-editor.org/rfc/rfc7253>.
[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves
for Security", RFC 7748, DOI 10.17487/RFC7748, January
- 2016, <https://www.rfc-editor.org/info/rfc7748>.
+ 2016, <https://www.rfc-editor.org/rfc/rfc7748>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
- <https://www.rfc-editor.org/info/rfc8032>.
+ <https://www.rfc-editor.org/rfc/rfc8032>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
- <https://www.rfc-editor.org/info/rfc8126>.
+ <https://www.rfc-editor.org/rfc/rfc8126>.
[SCHNEIER] Schneier, B., "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996.
@@ -5394,12 +5496,12 @@
Pair-Wise Key Establishment Schemes Using Discrete
Logarithm Cryptography", NIST Special Publication 800-56A
Revision 1, March 2007.
-
[TWOFISH] Schneier, B., Kelsey, J., Whiting, D., Wagner, D., Hall,
C., and N. Ferguson, "The Twofish Encryption Algorithm",
1999.
-18.2. Informative References
+19.2. Informative References
+
[BLEICHENBACHER]
Bleichenbacher, D., "Generating ElGamal Signatures Without
Knowing the Secret Key", Lecture Notes in Computer
@@ -5422,21 +5524,21 @@
[RFC1991] Atkins, D., Stallings, W., and P. Zimmermann, "PGP Message
Exchange Formats", RFC 1991, DOI 10.17487/RFC1991, August
- 1996, <https://www.rfc-editor.org/info/rfc1991>.
+ 1996, <https://www.rfc-editor.org/rfc/rfc1991>.
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
"OpenPGP Message Format", RFC 2440, DOI 10.17487/RFC2440,
- November 1998, <https://www.rfc-editor.org/info/rfc2440>.
+ November 1998, <https://www.rfc-editor.org/rfc/rfc2440>.
[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
Thayer, "OpenPGP Message Format", RFC 4880,
DOI 10.17487/RFC4880, November 2007,
- <https://www.rfc-editor.org/info/rfc4880>.
+ <https://www.rfc-editor.org/rfc/rfc4880>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
- <https://www.rfc-editor.org/info/rfc6090>.
+ <https://www.rfc-editor.org/rfc/rfc6090>.
[SEC1] Standards for Efficient Cryptography Group, "SEC 1:
Elliptic Curve Cryptography", September 2000.
@@ -5719,7 +5821,17 @@
* Added alternative OIDs for Ed25519 and Curve25519.
-Appendix D. The principal authors of RFC-4880
+ Changes since draft-koch-openpgp-2015-rfc4880bis-02:
+
+ * Add ML-KEM parts from draft-wussler-openpgp-pqc-03.txt
+
+ * Changed name of the specification to OpenPGP.
+Appendix D. Acknowledgments
+
+ There have been a number of authors involved with the development of
+ the OpenPGP specification as described by RFC-4880, RFC-5581, and
+ RFC-6637:
+
Jon Callas
EMail: jon at callas.org
@@ -5734,30 +5846,15 @@
Rodney Thayer
EMail: rodney at canola-jones.com
-Authors' Addresses
-
- Werner Koch
- GnuPG e.V.
- Rochusstr. 44
- 40479 Duesseldorf
- Germany
- Email: wk at gnupg.org
- URI: https://gnupg.org/verein
+ Andrey Jivsov
+ EMail: Andrey_Jivsov at symantec.com
+ The work to update RFC-4880 was mainly conducted by the authors of
+ this document and the following authors:
brian m. carlson
Email: sandals at crustytoothpaste.net
-
- Ronald Henry Tse
- Ribose
- Suite 1111, 1 Pedder Street
- Central, Hong Kong
- Hong Kong
- Email: ronald.tse at ribose.com
- URI: https://www.ribose.com
-
-
Derek Atkins
Email: derek at ihtfp.com
@@ -5761,6 +5858,28 @@
Derek Atkins
Email: derek at ihtfp.com
-
Daniel Kahn Gillmor
Email: dkg at fifthhorseman.net
+
+ The PQC algorithm extension was conducted by the following authors:
+
+ Stavros Kousidis
+ Email: stavros.kousidis at bsi.bund.de
+
+ Falko Strenzke
+ Email: falko.strenzke at mtg.de
+
+ Aron Wussler
+ Email: aron at wussler.it
+
+Authors' Addresses
+ Werner Koch
+ g10 Code GmbH
+ Germany
+ Email: wk at gnupg.org
+
+
+ Ronald Henry Tse
+ Ribose
+ Hong Kong
+ Email: ronald.tse at ribose.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: openpgp-digital-signature.asc
Type: application/pgp-signature
Size: 247 bytes
Desc: not available
URL: <https://librepgp.org/pipermail/librepgp-discuss/attachments/20240130/63ff1acb/attachment.sig>
More information about the LibrePGP-discuss
mailing list