RFC Errata
Found 3 records.
Status: Reported (2)
RFC 7515, "JSON Web Signature (JWS)", May 2015
Source of RFC: jose (sec)
Errata ID: 7767
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Jeffrey Yasskin
Date Reported: 2024-01-17
Section 6 says:
These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision; however, if the only information used in the trust decision is a key, these parameters need not be integrity protected, since changing them in a way that causes a different key to be used will cause the validation to fail.
It should say:
These Header Parameters MUST be integrity protected if the information that they convey is to be utilized in a trust decision.
Notes:
See the discussion for https://www.rfc-editor.org/errata/eid7719 at https://mailarchive.ietf.org/arch/msg/jose/I3_IuEfFSyiHWap7Pyn1BFAb4QM/. The deleted text is incorrect for both signature schemes and encryption schemes.
You could consider adding text like "Note that some algorithms allow multiple keys to validate or decrypt the same signature or encrypted data." to prevent readers from making the same bad assumption as the original RFC authors, but it doesn't seem necessary if doing so is contentious. Similarly, it's probably ok to simply delete the whole "Original Text" if that seems better to the reviewers.
Errata ID: 8430
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Panos Kampanakis
Date Reported: 2025-05-26
Section A.1.1 says:
Encoding this JWS Signature as BASE64URL(JWS Signature) gives this value: dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk
It should say:
[ I don't know what the signature is. dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk is not base64url. ]
Notes:
Maybe it was the signature in ascii and needed to be converted to base4url?
Status: Rejected (1)
RFC 7515, "JSON Web Signature (JWS)", May 2015
Source of RFC: jose (sec)
Errata ID: 6118
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jason Heiss
Date Reported: 2020-04-22
Rejected by: Benjamin Kaduk
Date Rejected: 2020-04-25
Section 2 says:
(as permitted by Section 3.2)
Notes:
This appears to be a reference to section 3.2 of RFC 4648, but because it is somewhat ambiguous the HTML and PDF versions of the RFC link to section 3.2 of this RFC instead.
--VERIFIER NOTES--
Errata reports are for the authoritative versions hosted on rfc-editor.org, which for this document is the plain text version. As such, issues introduced by the "htmlization" process do not qualify.