Found 4 records.
Status: Reported (1)
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.
Status: Rejected (3)
RFC 7515, "JSON Web Signature (JWS)", May 2015
Source of RFC: jose (sec)
Errata ID: 8430
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Panos Kampanakis
Date Reported: 2025-05-26
Rejected by: Deb Cooley
Date Rejected: 2025-06-27
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?
--VERIFIER NOTES--
This does not appear to be broken (or incorrect). Add == to the end for padding to allow proper decoding.
Errata ID: 8508
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Ryan Desmond
Date Reported: 2025-07-11
Rejected by: Deb Cooley
Date Rejected: 2025-10-28
Section Sec 2, Appendix C says:
2. Terminology
These terms are defined by this specification:
Base64url Encoding
Base64 encoding using the URL- and filename-safe character set
defined in Section 5 of RFC 4648 [RFC4648], with all trailing '='
characters omitted (as permitted by Section 3.2) and without the
inclusion of any line breaks, whitespace, or other additional
characters. Note that the base64url encoding of the empty octet
sequence is the empty string. (See Appendix C for notes on
implementing base64url encoding without padding.)
Appendix C. Notes on Implementing base64url Encoding without Padding
This appendix describes how to implement base64url encoding and
decoding functions without padding based upon standard base64
encoding and decoding functions that do use padding.
To be concrete, example C# code implementing these functions is shown
below. Similar code could be used in other languages.
...
static byte [] base64urldecode(string arg)
{
string s = arg;
s = s.Replace('-', '+'); // 62nd char of encoding
s = s.Replace('_', '/'); // 63rd char of encoding
switch (s.Length % 4) // Pad with trailing '='s
{
case 0: break; // No pad chars in this case
case 2: s += "=="; break; // Two pad chars
case 3: s += "="; break; // One pad char
default: throw new System.Exception(
"Illegal base64url string!");
}
return Convert.FromBase64String(s); // Standard base64 decoder
}
As per the example code above, the number of '=' padding characters
that needs to be added to the end of a base64url-encoded string
without padding to turn it into one with padding is a deterministic
function of the length of the encoded string. Specifically, if the
length mod 4 is 0, no padding is added; if the length mod 4 is 2, two
'=' padding characters are added; if the length mod 4 is 3, one '='
padding character is added; if the length mod 4 is 1, the input is
malformed.
It should say:
2. Terminology
These terms are defined by this specification:
Base64url Encoding
Base64 encoding using the URL- and filename-safe character set
defined in Section 5 of RFC 4648 [RFC4648], all trailing '='
characters SHOULD be omitted (as permitted by Section 3.2) and
any line breaks, whitespace, or other additional characters SHALL
be excluded. Note that the base64url encoding of the empty octet
sequence is the empty string. (See Appendix C for notes on
implementing base64url encoding without padding.)
Appendix C. Notes on Implementing base64url Encoding without Padding
...
NOTE: The decoding function allows padded input, which is not recommended.
Notes:
The definition for Base64url is more strict than RFC4648, but doesn't qualify that with keyword from RFC 2119. The corrected text uses RFC 2119 keywords to be more specific and consistent. I do propose allowing but discouraging extraneous padding, which is currently ambiguous. An alternate solution would be using SHALL be omitted in the definition and either adding a note in appendix C or a conditional to throw an exception for non-compliant input.
--VERIFIER NOTES--
The term definition clearly says what “Base64url Encoding” means in this specification.
Among other things, it meaning of that term includes the detail "with all trailing '=' characters omitted” — unconditionally so.
The proposed replacement text would replace this clear definition with a “SHOULD”, which is incorrect — there is no circumstance in which a “=“ is permitted in RFC 7515 “Base64url Encoding”.
The proposed change would be a deviation from the WG intent.
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.