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

Henk Birkholz <> Mon, 11 November 2019 10:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1C94B12082E for <>; Mon, 11 Nov 2019 02:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UyGsVsCe3wBC for <>; Mon, 11 Nov 2019 02:11:26 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A3F27120059 for <>; Mon, 11 Nov 2019 02:11:26 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2/Debian-10) with ESMTPS id xABABNOx016999 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 11 Nov 2019 11:11:24 +0100
Received: from [] ( by ( with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 11 Nov 2019 11:11:18 +0100
To: Michael Richardson <>, <>
References: <> <> <> <> <> <>
From: Henk Birkholz <>
Message-ID: <>
Date: Mon, 11 Nov 2019 11:11:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Rats] clarity on JWT vs YANG-serialization: base64 vs base64url
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Nov 2019 10:11:30 -0000

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,


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