Re: [netconf] base64encodedvalue== is an invalid base64 value

[Carsten Bormann <[e-mail]>]

On 30. Jan 2021, at 00:26, Kent Watsen <[e-mail]> wrote:
> 
> 
>>> Who cares whether this value roundtrips in an examples??
>> 
>> I’d expect at least some decent implementations will check for RFC 4648’s mandate "These pad bits MUST be set to
>>  zero by conforming encoders”, just like some check for the right number of equals signs.
>> Examples that fail in decent implementations are suboptimal.
>> (They might even be used in arguments to claim that this decency needs to be removed.)
> 
> 
> 
> `base64` doesn’t produce a warning:
> 
>    $ echo "base64encodedvalue==" | base64 -d | base64
>    base64encodedvaluQ==
> 
> 
> 
> `openssl` doesn’t produce a warning:
> 
>    $ echo "base64encodedvalue==" | openssl enc -d -base64 -A | openssl enc -base64 -A
>    base64encodedvaluQ==
> 
> 
> 
> Python doesn’t produce a warning:
> 
>    $ printf "import binascii\nprint(binascii.b2a_base64(binascii.a2b_base64('base64encodedvalue=='), newline=False).decode('ascii'))" |  python -
>    base64encodedvaluQ==


Thanks for the data points; adding 1½ more:

$ ruby -rbase64 -e 'puts Base64.encode64(Base64.decode64("base64encodedvalue=="))' 
base64encodedvaluQ==
$ ruby -rbase64 -e 'puts Base64.strict_encode64(Base64.strict_decode64("base64encodedvalue=="))'
<internal:pack>:281:in `unpack1': invalid base64 (ArgumentError)
	from /opt/homebrew/Cellar/ruby/3.0.0_1/lib/ruby/3.0.0/base64.rb:74:in `strict_decode64'
	from -e:1:in `<main>'

Checking conformance is a MAY(*) for a decoder, so I’m not surprised that many don’t do that.
(Or check only on specific request, as in Ruby.)

I would strongly expect any decoder that is used in a security context to actually check, so I *am* surprised by the openssl example above.
(Well, not that much surprised; it is, well, openssl.)

I wouldn’t have reacted to this thread if I hadn’t years ago, when writing a random test case generator, been surprised by a base64 implementation that did check.
I don’t recollect the details of that, though…

Grüße, Carsten

(*) https://tools.ietf.org/html/rfc4648#section-3.5 <https://tools.ietf.org/html/rfc4648#section-3.5>
For those not familiar with RFC 2119 interoperability keywords:
MAY means that an implementation is free to do so.
Which raises the interoperability requirement that any peer implementation MUST be able to interoperate with an implementation that does.
This would be unnecessary to state in this case because that MUST is in the paragraph before.
So the intent here apparently was stressing the optionality of checking in a decoder.