Re: [Rats] clarity on JWT vs YANG-serialization: base64 vs base64url

[Henk Birkholz <[e-mail]>]

A single reply in-line.

On 11.11.19 12:48, Michael Richardson wrote:
> 
> 
> On 2019-11-11 6:11 p.m., Henk Birkholz wrote:
>> Hi Michael,
>>
>> you are bringing up an issue that might look tiny, but I think you are
>> right when you say: "it will catch at least one implementer".
> 
> I started a private discussion with Mike Jones and Tim Bray a few weeks
> ago about a clarifying BCP about always using base64URL in JSON going
> forward.  (I thought I had posted this to a list.)
> Or... would an errata be enough?
> That would put the current serialization of YANG (RFC7951) on the wrong
> side of the tracks, which is unfortunate.

This is what I meant by "not easy". Both are used already. The technical 
differences (see below) are not that big, I agree.

> 
>> And there is no easy fix for his, it seems? JWT is set, and YANG
>> modeled data, such as RFC 7951, is also set. I am not sure that there
>> is a thing such as "tolerant decoders" in practice, I am afraid.
> 
> It's not hard, there are only two characters:
>    62 is either +(original) or -
>    63 is either / (original) or _
> 
> I was rather surprised that common implementations didn't just accept
> both already.
> I stubbed my toe on this when processing Jim Schaad's excellent JOSE
> reference vectors, and couldn't figure out why one of the public keys
> was too short, until I learnt that the decoder I was using just stopped
> when it got an invalid character, and I was using base64 rather than
> base64url.
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>