On Jul 15, 2025, at 21:08, Desmond, Ryan <ryan.desm...@maxar.com> wrote: > > the crux of my errata request is that the example decoder in Appendix C is > does accept padded Base64url Encoding.
Right. It seems to have been written to allay fears that base64url is hard to implement if you only have a base64classic implementation. It (as far as I can tell) successful encodes and decodes all base64url instances. It does not promise to be what we’d call a “checking decoder”. I would expect a security-related implementation to require a checking decoder. The decoder as given breaks in most cases if the input contains blank space; it also can falsely succeed if the input contains “=“, “+”, or “/“. > Though I haven't fallen victim as a JWS implementer, I do have a service > which produces JWS of this invalid format. They could justify non-action for > their non-compliant parameters because of it. I’d reply that the appendix is there to demonstrate decoding, not checking the input. But, yes, it does provide a potential rationalization for an insufficiently checking decoder implementation. (It in no way provides a rationalization of a defective encoder, but people are really happy with rationalizing their mistakes.) > Perhaps a better errata would be against that only and suggest a comment such > as "Note: The decoder outlined here will accept padded Base64url Encoded > values, which are not compliant with this specifation." or an update to the > code to error if such input is encountered. Well, if they are not compliant, they are not “Base64url Encoded values”! I don’t know whether errata are a great way to attach notes to potentially misunderstandable passages, but a note that the decoder produces a result for certain inputs other than Base64url encoded values would indeed be helpful to readers. For a future document update, I would point out that there also is no mention of Section 3.5 of RFC 4648 [3.5], so there also might be claims that “sloppy” (Section 2.1 of RFC 9741 [2.1]) encodings are allowed. In a security protocol, they clearly should not be. (This really is more of a flaw of RFC 4648, which tries to be too friendly to the utterly unnecessary use of sloppy encoding, requiring any citing standard to explicitly mention its Section 3.5.) Grüße, Carsten [3.5]: https://www.rfc-editor.org/rfc/rfc4648#section-3.5 [2.1]: https://www.rfc-editor.org/rfc/rfc9741#section-2.1-8 _______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
