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

Michael Richardson <mcr@sandelman.ca> Mon, 11 November 2019 11:48 UTC

Return-Path: <mcr@sandelman.ca>
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 4983E120820 for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 03:48:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.865
X-Spam-Level:
X-Spam-Status: No, score=-0.865 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 oD-k_UoRG33w for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 03:48:52 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D3421200DB for <rats@ietf.org>; Mon, 11 Nov 2019 03:48:52 -0800 (PST)
Received: from [192.168.42.250] (unknown [209.52.88.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPSA id 633733897C; Mon, 11 Nov 2019 06:45:47 -0500 (EST)
To: 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>
From: Michael Richardson <mcr@sandelman.ca>
Openpgp: preference=signencrypt
Autocrypt: addr=mcr@sandelman.ca; keydata= mQGNBF3EaO8BDADNdcAioLgGWFMLcmR6SuX1ioVH0v1fcprk0Wl1Qc7LCdwqj+QSdv84oNe1 h6lTf+CsmzO+TZtL+2iUzR3WHyXViEJcSHldx2YIfgxGZkzqgqozDj2IoHCU6ezhQz2TwJO7 l6H7fIPBbemIu8qVezwP1azLVq3D+cXZkkOvsFhTiw1bF/WF8lIIAYEbQ4YyYyjk5DS30x59 kxFNSv6om8rqSAKs2epneEWpzybB0J82dBnB4VDDsMmTJWPkszvQoCjCbrvgDAuoRtL5su2V IQWw61O6N5p1mwJ7VQoPDWYyeFH4NrVlL71FwRLueVPle76Oi3ybE2IMUvHZ/e42jVBizlQj 1N/2x7mGk35Zrvz0WHjZLcFJYJkDOnLsMU1smhdRtxNfYf576DTlzQKVcLmNCfOKAWnz4DdQ gRI4pNs24NoxLXl5v5mhDHRX5Me+CuckkFNGSlCXZ5kMXzPPFAV6CwMlm65P1tVJq9td8Uh0 5I5okPcENk5iY+FniqMXamsAEQEAAbQlTWljaGFlbCBSaWNoYXJkc29uIDxtY3JAc2FuZGVs bWFuLmNhPokB1AQTAQgAPhYhBKMP9ag1YAG1i9s8WHACrsLM2IBDBQJdxGjwAhsDBQkB4TOA BQsJCAcCBhUKCQgLAgQWAgMBAh4BAheAAAoJEHACrsLM2IBDeJ4MAMvUmQjFqXgsg4KhIWQb QBcgNPxrtp9jW/i2m//0zVA2iGxbeTOZD6cmcNDRj153TbSGTEH03oJIeYbdwlOCe5blA6h4 FTEBwt/qX+mjRYKXuA3uvFdEJQJPFcaWFF68rgQMxgLPPUAnTYQ00SqaBEg+Vh4gSh8yOHuU 8VTgenm4JpBdJQx7/7syvIaQilhN2fF25CcA7hArmebkaG691x+cFD60s8ITI9PSf82SVUnp mspJTGptxFxH/GM/kW40iB4tUjZrUSQfTfWIXA/5j005XbVbo1DIYirWWNK0WPVsh51ullzt u37BDVj/SmgbGhvTUXwsBi4b+T2cJHLt+8QT/KM8OA+UA8AlkNPleKtOzxsg5z22m0fzollE Zcw9VIojPKIhTUYU79InmibEUoGfb05MFJM9aXX5BMoJNpKcB92PKI/gMsrxMwH1exs0cY/E K/xYdpFo3rTPw5KSsDkr7ZbqGPgz+QP2H+TLwgLKMFTBlVKpj+oqBnqeEVVrC7kBjQRdxGjv AQwA0T5oxtsQkr3I3FxBi5TkNSh0HZ7ND5xJJkyM6wLAsljLk5KhdcxjTlo6htNjRUuUy1Ld 0bARmezZf5GqKRh6fR7WX9EdYjGm0RbcK3tQ3L61h4p3EOplKgMSoGpGamLSDzRs3SAJu4GF iHfzQ20R0PxBN/CbzWh6ROPcxQ8wwt8G4ZOwU4zXfSmZqZwNp/6xosLCl3TKvFWX6421Vb/L WAOOAz/xSyS0GCUs/grBUfzu95+TTskRk7kkeYSQ//1Oq9srPlIU9lx3Y4jDgPkXIwd9eXOq e7/5y4bQkILGGMIux878DhAED865hPMBuHlkDNzIuo6HhjRkShLBM16yQhK+NJ0WI77+m1FD 7r5QL6iU57zI/B5U03JKZhW0Pm3Bm+RWZPWGVawkPUnvxoMFbw+x1+MnKZgXwRmRmbFsCHhD VmrDKLWXRm9QvTB+k0ZnTdme9ZwSNCn0CXME2rNtOR39Yh6dsWH2nMPvg/G5iUmZyO9Oa01W xhWcXnKA+v+VABEBAAGJAbwEGAEIACYWIQSjD/WoNWABtYvbPFhwAq7CzNiAQwUCXcRo7wIb DAUJAeEzgAAKCRBwAq7CzNiAQwaOC/4olaVHP/npCn2CrtAOstbyytePFmS9NAwdT8A6mA4s +WshPo1DhKEnKnYzW/S0jLf0iqlzT8LUqu2G8f6elGzghRR8WJVn0zH7LVCKMWo/tHE2rWyi Q1zuX9o7ChTodQ8cXx0lM1xdY8v4Amc5fFxyyhJprKZAtiDJ897vv1jP09fWLEBhaDsHqLhg ckQpIoee0Id4FXGt7wxDsPwa64SUUCTYdt98EiLoUY6eAWQnyelgbFU+D/bxkeytmmvWOVr7 UXVMQlEKG7E31G1XQMk6sFATF1dwiH/laLQPLuMYr7owUC+ef/YAWSHMTYeIfwdt/Yd8ngJ8 SFA6Uc+Bjr0i1jdnxS5H3EF4V1FNY2rh4zNPVNj2UrZaShK/XH4hnTJUYL5fo2ygt2ZM98ot 8lIsHGAJQHDl2/EffLsAL85pXDPl8E+nvOUOE1kwmfOgv/oV8z0469qu/hNiEpGp8xKBqGEL NWHd8fH5S9JxVix9Ed34vi9Cyf24iLjiWZBemXw=
Message-ID: <086f1aeb-1401-2c95-1abf-bb104d0c13e5@sandelman.ca>
Date: Mon, 11 Nov 2019 19:48:45 +0800
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: <d490a8ec-fb4e-bdca-b9c9-8730ae71a488@sit.fraunhofer.de>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="qLH13ywzaOVFOjsNhiQJVuISMVyiPYH8f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/-w0PRt6Wd0Zf3x7_3bwKoN8ZOG4>
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 11:48:54 -0000


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.

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