The following errata report has been rejected for RFC7515, "JSON Web Signature (JWS)".
-------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid8508 -------------------------------------- Status: Rejected Type: Technical Reported by: Ryan Desmond <[email protected]> Date Reported: 2025-07-11 Rejected by: Deb Cooley (IESG) Section: Sec 2, Appendix C Original Text ------------- 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. Corrected Text -------------- 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. -------------------------------------- RFC7515 (draft-ietf-jose-json-web-signature-41) -------------------------------------- Title : JSON Web Signature (JWS) Publication Date : May 2015 Author(s) : M. Jones, J. Bradley, N. Sakimura Category : PROPOSED STANDARD Source : Javascript Object Signing and Encryption Stream : IETF Verifying Party : IESG _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
