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

[Henk Birkholz <[e-mail]>]

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".

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.

In summary, as a last resort I'd agree with you that we need to "hit 
people over the head with this", extensively.

Viele Grüße,

Henk

On 11.11.19 01:21, Michael Richardson wrote:
> 
> When it comes to JWT encapsulation and YANG serialized JSON there are
> some potential conflicts that I want to bring up.  This is worth a 5
> minute discussion at a future meeting (perhaps premature for IETF106).
> 
> I've posted about this to other lists in the past two weeks, but I don't
> have the references, and I don't have enough Internet to look them up
> from here.
> 
> The specific conflict is that JWT, coming from the web space, uses
> base64URL encoding for binary objects (signatures..., etc.) while YANG,
> uses base64 encoding for binary objects.  This is a documentation
> annoyance, but it will catch at least one implementer.
> 
> Tolerant decoders might accept both (but neither Python or Ruby base64
> decoders are tolerant), but I don't think we can in general, demand that
> either is acceptable, so we have to say which to use each time.
> 
> We will just have to be clear going forward, and hit people over the
> head with this.  I can easily see YANG described data (signatures on
> Evidence) from a TPM device being base64 encoded, and then placed into a
> JWT container which is base64URL signed (for a Claim).
> 
> 
> 
> 
> _______________________________________________
> RATS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rats
>