RFC Errata
Found 5 records.
Status: Verified (4)
RFC 9580, "OpenPGP", July 2024
Source of RFC: openpgp (sec)
Errata ID: 8454
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Tim Geiser
Date Reported: 2025-06-07
Verifier Name: Paul Wouters
Date Verified: 2025-06-13
Section 5.2.3 says:
One or more MPIs comprising the signature. This portion is algorithm specific.
It should say:
One or more MPIs comprising the signature, or plain octets with no MPI header. This portion is algorithm specific.
Notes:
The final bullet point of 5.2.3 is not, strictly speaking, correct. Ed25519 and Ed448 have signatures that are not MPIs but rather "native" octet strings. These algorithms do not have "one or more MPIs" - they have zero MPIs and only the octet string (of length 64 or 114). Prior to the introduction of these algorithms that statement was correct - every other signature algorithm uses MPI(s).
Errata ID: 8465
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Heiko Schaefer
Date Reported: 2025-06-18
Verifier Name: Paul Wouters
Date Verified: 2025-06-18
Section 5.5.3 says:
A point on an elliptic curve will always be represented on the wire as an MPI.
It should say:
TBD
Notes:
This and the following paragraphs don't mention the case of "native" secret key representations. The text should acknowledge the existence of MPIs as well as natively encoded points.
Errata ID: 8466
Status: Verified
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Heiko Schaefer
Date Reported: 2025-06-18
Verifier Name: Paul Wouters
Date Verified: 2025-08-28
Section 11.2 says:
A point on an elliptic curve will always be represented on the wire as an MPI.
It should say:
TBD
Notes:
This langauge doesn't acknowledge the native encoding of the new Ed/X 25519/448 variants.
Various language in the following sections of chapter 11 also seem to imply that all EC data is encoded in MPI format.
In particular, in 11.3, all three entries in the table "OpenPGP Elliptic Curve Scalar Encodings Registry" seem to imply variants of MPI encoding. The case of "native" fixed length encoding seems to be missing.
Paul Wouters (AD): This report is correct: the text is a holdover from RFC 6637 and should have been updated with the new streamlined ECC formats added in RFC 9580.
dkg proposed corrected text to be prefixed like "For ECDH (18), ECDSA (19) and EdDSALegacy (22) public key algorithms, …"
Errata ID: 8432
Status: Verified
Type: Editorial
Publication Format(s) : PDF, HTML
Reported By: Neal Walfield
Date Reported: 2025-05-27
Verifier Name: RFC Editor
Date Verified: 2025-06-10
Section 16.1 says:
[SP800-56A]
NIST, "Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography", NIST
Special Publication 800-56A Revision 3,
DOI 10.6028/NIST.SP.800-56Ar, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
nist.sp.800-56Ar3.pdf>.
It should say:
[SP800-56A]
NIST, "Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography", NIST
Special Publication 800-56A Revision 3,
DOI 10.6028/NIST.SP.800-56Ar, April 2018,
<https://nvlpubs.nist.gov/nistpubs/SpecialPublications/nist.sp.800-56Ar3.pdf>.
Notes:
I noticed that Section 16.1 of RFC 9580 contains a broken link.
https://www.rfc-editor.org/rfc/rfc9580.html#section-16.1
Specifically, this entry is broken:
[SP800-56A] NIST, "Recommendation for Pair-Wise Key Establishment
Schemes Using Discrete Logarithm Cryptography", NIST Special
Publication 800-56A Revision 3, DOI 10.6028/NIST.SP.800-56Ar, April
2018, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/
nist.sp.800-56Ar3.pdf>.
The URL should be:
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/nist.sp.800-56Ar3.pdf
That is, the link contains an extra space.
I've checked, and this error exists in both the HTML and the PDF
versions of the document.
Status: Held for Document Update (1)
RFC 9580, "OpenPGP", July 2024
Source of RFC: openpgp (sec)
Errata ID: 8449
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT, PDF, HTML
Reported By: Jasper Spaans
Date Reported: 2025-06-05
Held for Document Update by: Paul Wouters
Date Held: 2025-06-09
Section 5.11 says:
A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the keyholder. By convention, it includes a mail name-addr as described in [RFC2822], but there are no restrictions on its content. The packet length in the header specifies the length of the User ID.
It should say:
A User ID packet consists of UTF-8 text that is intended to represent the name and email address of the keyholder. By convention, it includes a mailbox as described in [RFC2822], but there are no restrictions on its content. The packet length in the header specifies the length of the User ID.
Notes:
A name-addr requires angled brackets around the mail address, which in practice are left off when there is no display name.
`mailbox` in rfc2822 (and 5322) is defined as `name-addr / addr-spec` so it can be either the original name-addr, or a bare address which does occur in the wild.
Paul Wouters (SEC AD): Note that the corrected text also does not fully address the problem. See further https://mailarchive.ietf.org/arch/msg/openpgp/PNluQWUlkABlJ5Er4hA9P6zCADk/