Re: [Cbor] Reviews and shepherd for draft-ietf-cbor-cddl-more-control

["lgl island-resort.com" <[e-mail]>]

Hi Carsten,

Appreciate the fix and rapid turnaround. 

I’d like to ask that the draft explicitly say that .b4u and .b4c accept only their respective alphabets.

- RFC 4648 only really says how to encode, not what decoders should do
- B64 decoders out there widely accept both; What .b64u and .b64c do here is far from the norm (but I like it)
- This draft is a specification that we expect other cddl tool implementors to follow so it should be clear

It would also be helpful for CDDL-using document authors like me to not have to go read and interpret RFC 4648.

Thx

LL



> On Apr 14, 2024, at 11:32 PM, Carsten Bormann <[e-mail]> wrote:
> 
> Hi Laurence,
> 
>> On 14. Apr 2024, at 21:30, lgl island-resort.com <[e-mail]> wrote:
>> 
>> I’ve made a lot of progress using .join as described below, but this comment is about “.b64u” and RFC 4648 section 5.
>> 
>> It’s clear to me that a base64url encoder should output “-“ and “_” instead of “+” and “/“, but it’s not clear what an RFC 4648 section 5 decoder should accept. Most tools and websites I’ve played with accept both, and that’s OK. However, I was expecting .b64u to reject  “+” and “/“ because it is opinionated, but the cddl tool 0.11.4 doesn’t.
> 
> Thank you for the bug report — fixed in 0.11.5.
> 
>> Here’s my CDDL:
>>   foo = text .b64u bstr
>> 
>> Validating “jkd8” correctly succeeds
>> 
>> Validating "&kd8” correctly fails.
>> 
>> Validating "+kd8” unexpectedly succeeds. The “+” is b64, but not b64url.
> 
> Fixed in 0.11.5.
> 
>> Validating "YQ==" correctly fails due to opinions about padding (that I agree with).
>> 
>> Interestingly, .b64c does seem to reject inputs with “_” and “-“ which aligns with my reading of RFC 4648 section 4.
> 
> Yes. My .b64c implementation uses a platform API marked as strict.
> I mistakenly believed that the similar platform function that I used for .b64u also was strict in its character set; it turns out it wasn’t.
> So I added + and / to the check that already was handling =.
> 
>> I think I prefer strict enforcement because this is a validation tool.
> 
> I agree.
> 
>> If you are picking b64url, you are probably avoiding classic for a reason.
>> 
>> Whatever behavior is decided upon, it would be helpful to be clear in the draft because RFC 4648 isn’t that clear
> 
> I’d say 4648 is quite clear here.
> 4648 uses “recommended” once in an overview sentence where it introduces what actually is a mandate, but particularly Table 2 leaves no room for interpretation: + and / are not in the set of 4648 section 5 characters.
> 
>> and most of the tools I played with are not very organized.
> 
> Right — the above observation is another data point that indicates the existing platform mechanisms aren’t always very strict…
> 
> Grüße, Carsten
>