Re: [netmod] Strictness of Base64classic in RFC 7950/7951
On 2023-03-05, at 18:37, Robert Varga wrote:
>
>>
>> Now what do other implementations do?
>
> OpenDaylight uses plain Java, which in turn boils down to:
>
>> | Welcome to JShell -- Version 17.0.6
>> | For an introduction type: /help intro
>> jshell> java.util.Base64.getDecoder().decode("ue==")
>> $1 ==> byte[1] { -71 }
Thank you!
It seems we should be planning for accepting invalid codes when that is desired.
Grüße, Carsten
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
On 27/02/2023 15.24, Carsten Bormann wrote:
On 2023-02-27, at 15:04, Ladislav Lhotka 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?
OpenDaylight uses plain Java, which in turn boils down to:
| Welcome to JShell -- Version 17.0.6
| For an introduction type: /help intro
jshell> java.util.Base64.getDecoder().decode("ue==")
$1 ==> byte[1] { -71 }
Regards,
Robert
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
> On Feb 28, 2023, at 2:25 AM, Ladislav Lhotka wrote: > > Was it this thread? > > https://mailarchive.ietf.org/arch/msg/netconf/ra_KfLp2HPUZajLIYQ_MBLf-sfw/ > No, it didn't regard the sztp-csr draft's IESG LC. K. > Lada > ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
Kent Watsen writes: >>> This was discussed in late 2021. I switched from: >>> >>> base64encodedvalue== >>> >>> to: >>> >>> BASE64VALUE= >>> >>> in all my drafts then. Which document are you looking at? >> >> RFC 8366 (from 2018). > > That document was published before the issue was discovered. File an Errata > for it? > > >> Do you have a pointer to the discussion? > > Not at hand. Was it this thread? https://mailarchive.ietf.org/arch/msg/netconf/ra_KfLp2HPUZajLIYQ_MBLf-sfw/ Lada > > >> Was there, at the same time, any conclusion with respect to my question >> (strict or soup)? > > No, only that it was wrong and should be fixed. ;) > > > K. > >> Grüße, Carsten > > -- Ladislav Lhotka, CZ.NIC PGP Key ID: 0xB8F92B08A9F76C67 ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
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? > > RFC 8366 (from 2018). That document was published before the issue was discovered. File an Errata for it? > Do you have a pointer to the discussion? Not at hand. > Was there, at the same time, any conclusion with respect to my question > (strict or soup)? No, only that it was wrong and should be fixed. ;) K. > Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
On 2023-02-27, at 20:59, Kent Watsen wrote: > > This was discussed in late 2021. I switched from: > > base64encodedvalue== > > to: > > BASE64VALUE= > > in all my drafts then. Which document are you looking at? RFC 8366 (from 2018). Do you have a pointer to the discussion? Was there, at the same time, any conclusion with respect to my question (strict or soup)? Grüße, Carsten ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
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 wrote:
>
> On 2023-02-27, at 15:04, Ladislav Lhotka 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
On 2023-02-27, at 15:04, Ladislav Lhotka 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
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
Dne 27. 02. 23 v 14:31 Carsten Bormann napsal(a):
On 2023-02-27, at 12:57, Ladislav Lhotka wrote:
I this YANG-JSON valid for a `binary`?
"base64encodedvalue==“
Strictly speaking it isn't because it's out of range of the base64 encoding
function.
Right.
I think though it is OK to be liberal in what we accept here because
"base64encodedvaluQ==" is clearly the canonical value in this case, so there is
no ambiguity e.g. regarding string equality.
Well, this is the essence of my question (not sure about the part about string
equality, though).
draft-iab-protocol-maintenance [0] takes the position that the Postel
principle, while historically a good way to implement protocols and get
interoperability going, is not to be misunderstood as a mandate for the
evolution of protocol ecosystems — protocols are free to be strict, lest they
turn into soup (“Protocol Decay” [1]: “...a chain reaction that can create
interoperability problems over time”).
Section 9.1 in RFC 7950: "values in the data tree are conceptually
stored in the canonical representation", and also "XPath expression
evaluations are done using the canonical form". If implementations obey
these rules, and since the canonical form for the binary type is
unambiguous, I don't see much potential for interoperability problems.
In essence, it's like representing number 17 as +17.
I’d like to know whether, on issues like this, YANG is more on the strict side
or on the soup side — what do YANG implementations actually do, and what do we
want YANG implementations to do? Is there an implicit “MAY send invalid last
character”, which is no different from a “MUST accept invalid last character”?
Unlike non-alphabet characters, RFC 4648 doesn't say that such a
character in encoded data is invalid.
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.
Lada
Background: I’m proposing to add a few control operators to CDDL, including for
handling base64classic [2], and in my PoC implementation was of course
implementing a strict interpretation, only to be struck by the first example in
an RFC I was pointed to.
Grüße, Carsten
[0]:
https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas
[1]:
https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-12.html#name-harmful-consequences-of-tol
--
Ladislav Lhotka, CZ.NIC
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
On 2023-02-27, at 12:57, Ladislav Lhotka wrote: > >> I this YANG-JSON valid for a `binary`? >> >> "base64encodedvalue==“ > > Strictly speaking it isn't because it's out of range of the base64 encoding > function. Right. > I think though it is OK to be liberal in what we accept here because > "base64encodedvaluQ==" is clearly the canonical value in this case, so there > is no ambiguity e.g. regarding string equality. Well, this is the essence of my question (not sure about the part about string equality, though). draft-iab-protocol-maintenance [0] takes the position that the Postel principle, while historically a good way to implement protocols and get interoperability going, is not to be misunderstood as a mandate for the evolution of protocol ecosystems — protocols are free to be strict, lest they turn into soup (“Protocol Decay” [1]: “...a chain reaction that can create interoperability problems over time”). I’d like to know whether, on issues like this, YANG is more on the strict side or on the soup side — what do YANG implementations actually do, and what do we want YANG implementations to do? Is there an implicit “MAY send invalid last character”, which is no different from a “MUST accept invalid last character”? Background: I’m proposing to add a few control operators to CDDL, including for handling base64classic [2], and in my PoC implementation was of course implementing a strict interpretation, only to be struck by the first example in an RFC I was pointed to. Grüße, Carsten [0]: https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-more-control-00.html#name-byte-strings-base16-hex-bas [1]: https://www.ietf.org/archive/id/draft-iab-protocol-maintenance-12.html#name-harmful-consequences-of-tol ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Strictness of Base64classic in RFC 7950/7951
Carsten Bormann writes:
> Quick question (can’t find in the archives whether that was discussed):
>
> I this YANG-JSON valid for a `binary`?
>
> "base64encodedvalue==“
Strictly speaking it isn't because it's out of range of the base64 encoding
function. I think though it is OK to be liberal in what we accept here because
"base64encodedvaluQ==" is clearly the canonical value in this case, so there is
no ambiguity e.g. regarding string equality.
Lada
>
> Section 6.6 of RFC 7951 points to Section 9.8 of RFC 7950, which points to
> Section 4 of RFC 4648. That says:
>
>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.
>
> I read that as saying the `binary` should be encoded as:
>
> "base64encodedvaluQ==“
>
> (Q = 01, e = 00, only the first two bits are used after “u” has
> supplied six of eight for the last byte, so the rest must be zero.)
>
> Grüße, Carsten
>
> ...
>
> For those who don’t breathe base64, here’s the problem:
>
> a = Base64.decode64("base64encodedvalue==").hexs
> => "6d ab 1e eb 87 a7 72 87 5e 76 f6 a5 b9”
>
> But some bits were *not* zero in the discarded part, so we get:
>
> Base64.encode64(a.xeh) => "base64encodedvaluQ==\n”
>
> Of course, a strict base64classic decoder is not going to accept
> "base64encodedvalue==“ in the first place, because the sentence cited above
> is violated.
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC
PGP Key ID: 0xB8F92B08A9F76C67
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
[netmod] Strictness of Base64classic in RFC 7950/7951
Quick question (can’t find in the archives whether that was discussed):
I this YANG-JSON valid for a `binary`?
"base64encodedvalue==“
Section 6.6 of RFC 7951 points to Section 9.8 of RFC 7950, which points to
Section 4 of RFC 4648. That says:
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.
I read that as saying the `binary` should be encoded as:
"base64encodedvaluQ==“
(Q = 01, e = 00, only the first two bits are used after “u” has
supplied six of eight for the last byte, so the rest must be zero.)
Grüße, Carsten
...
For those who don’t breathe base64, here’s the problem:
a = Base64.decode64("base64encodedvalue==").hexs
=> "6d ab 1e eb 87 a7 72 87 5e 76 f6 a5 b9”
But some bits were *not* zero in the discarded part, so we get:
Base64.encode64(a.xeh) => "base64encodedvaluQ==\n”
Of course, a strict base64classic decoder is not going to accept
"base64encodedvalue==“ in the first place, because the sentence cited above is
violated.
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
