On Tue, 2025-07-15 at 18:34 +0200, Carsten Bormann wrote: > On 2025-07-11, at 20:00, RFC Errata System <[email protected]> wrote: > > > > 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. > > Common misconception: > A protocol definition needs RFC 2119 keywords to say anything at all; > anything not bolstered with an RFC 2119 keyword is not actually meant > seriously. > > Here, the report is about a *definition of a term*. > > 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 entirely incorrect — there is no circumstance in which a > “=“ is permitted in RFC 7515 “Base64url Encoding”. > The proposed change would be a massive, unmotivated deviation from the WG > intent. > > By the way, that definition is referenced from other RFCs, which would need > to be examined for damage if this definition is retroactively changed. > > Reject. > > Grüße, Carsten
100% agree with Carsten, not only this errata would be erroneous, it would also make all the software that (correctly) unconditionally only accept proper BaseURL Encoding become non-compliant overnight as a SHOULD would imply that decoding software now would need to parse data that was previously deemed invalid. -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
