Errata

Errata-ID: 7767

Status:

Reported

Type:

Technical

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:

Rejected

Type:

Technical

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

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

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.