Re: [netmod] Strictness of Base64classic in RFC 7950/7951

This was discussed in late 2021.   I switched from:

	base64encodedvalue==

to:

	BASE64VALUE=

in all my drafts then.  Which document are you looking at?

Kent

> On Feb 27, 2023, at 9:24 AM, Carsten Bormann <cabo@tzi.org> wrote:
> 
> On 2023-02-27, at 15:04, Ladislav Lhotka <ladislav.lhotka@nic.cz> wrote:
>> 
>> Unlike non-alphabet characters, RFC 4648 doesn't say that such a character in encoded data is invalid.
> 
> Not explicitly, but it also gives you an algorithm for arriving at the encoded value that never can result in the characters that I consider invalid [1]:
> 
>   When fewer than 24 input
>   bits are available in an input group, bits with value zero are added
>   (on the right) to form an integral number of 6-bit groups.  
> 
> Note the explicit “with value zero”.
> 
>> FWIW, my implementation (Yangson) uses Python standard library base64 that accepts it without complaints even with validation turned on:
>> 
>>>>> import base64
>>>>> base64.b64decode("ue==", validate=True)
>> b'\xb9'
>> 
>> So I assume the authors consider this input valid, and I saw no reason to be concerned about it.
> 
> Thank you — that was the kind of input I was looking for.
> 
> Now what do other implementations do?
> 
> Grüße, Carsten
> 
> [1]: https://www.rfc-editor.org/rfc/rfc4648#page-6
> 
> And the missing [2] from my previous message:
> [2]: https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod