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

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Mon, 11 November 2019 12:19 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: rats@ietfa.amsl.com
Delivered-To: rats@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F3F8120820 for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 04:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQubaSavGbYL for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 04:19:04 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D3E51200F3 for <rats@ietf.org>; Mon, 11 Nov 2019 04:19:02 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id xABCJ0dL025012 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 11 Nov 2019 13:19:01 +0100
Received: from [134.102.155.87] (134.102.155.87) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Mon, 11 Nov 2019 13:18:55 +0100
To: Michael Richardson <mcr@sandelman.ca>, <rats@ietf.org>
References: <8B173958-FC2A-4D1D-A81C-F324AB632CD7@cisco.com> <147F9159-6055-4E55-ABDC-43DFE3498BF1@island-resort.com> <ce5f8206-74dc-36bb-0093-a93045d5c67f@sit.fraunhofer.de> <0A7E3A4F-8534-4E98-BCB7-1454E07699F4@island-resort.com> <C3AE2645-49C8-4313-BCED-02FEB576B614@cisco.com> <78de3311-e3d1-675a-f373-dec567d31dc6@sandelman.ca> <d490a8ec-fb4e-bdca-b9c9-8730ae71a488@sit.fraunhofer.de> <086f1aeb-1401-2c95-1abf-bb104d0c13e5@sandelman.ca>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <6c9f7880-e494-c2ac-7325-bdfa05eee712@sit.fraunhofer.de>
Date: Mon, 11 Nov 2019 13:18:54 +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: <086f1aeb-1401-2c95-1abf-bb104d0c13e5@sandelman.ca>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [134.102.155.87]
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/vv_vga3DgI94xaLXJ6pzYynDDSs>
Subject: Re: [Rats] clarity on JWT vs YANG-serialization: base64 vs base64url
X-BeenThere: rats@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Remote Attestation Procedures <rats.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rats>, <mailto:rats-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rats/>
List-Post: <mailto:rats@ietf.org>
List-Help: <mailto:rats-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rats>, <mailto:rats-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Nov 2019 12:19:06 -0000

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
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>