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

Anders Rundgren <anders.rundgren.net@gmail.com> Mon, 11 November 2019 14:02 UTC

Return-Path: <anders.rundgren.net@gmail.com>
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 AADE412088D for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 06:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 Yufdpb7BL5J1 for <rats@ietfa.amsl.com>; Mon, 11 Nov 2019 06:02:07 -0800 (PST)
Received: from mail-wm1-x332.google.com (mail-wm1-x332.google.com [IPv6:2a00:1450:4864:20::332]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F0DE120289 for <rats@ietf.org>; Mon, 11 Nov 2019 06:02:07 -0800 (PST)
Received: by mail-wm1-x332.google.com with SMTP id u18so5811819wmc.3 for <rats@ietf.org>; Mon, 11 Nov 2019 06:02:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=qRAWg96Kf/w478ZPyPU1JaILuT0JafbDXcCj7K5lP1A=; b=S4LVYzlN9EcU18u87TUyVk3i5nFdi6QwNXeUoi5/wkHR3+32aiyJhwAecYTtKp/Xzo zdo6nV4HYoTvTAhZn7yG3LtLHFhogukSMAcgtJFhz7vf8qXKLgxzRbLGsGkG/kqYS0cn KsvNntciUgUOA+Zy5326wbSaYsFPELc3FbZ4UpOqLNQl3xSzfwr403CAQxFApdn1Flgu 0bBYFEmgGWTq7TJAMs0Wf8KVFYRcE6lSh/AhLbt7CMHYREm5nxdYRl4yrusAVsz9KjXo jKEHudL0soX5W7rG0J3xyVCBd2QYiW7CRzskvK/YYmfE/fsjWOxgTOjJRNp9aoPKvRwi Ar7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qRAWg96Kf/w478ZPyPU1JaILuT0JafbDXcCj7K5lP1A=; b=MAK+eAGd+LfHmHtlxZFC2bqXYGwfBgfXivtcmhbnMr9X7CpOlKXe25Zf1Kr/wlqz7G cNk2OAbNhUkNJMnGp4jP2khlQa3inPkhNfsMX9U40I9eKdIw0rVE0N56Sj1mtLINQuuD 4iW/oa//lJeev0EmvqsgcN+5Lkw0593T2dJ5h7vyiaTN70rEU7vq2hfO8TgHqRBSioC2 Ys0HxvfBums/CAKtkvGuWUUrdr81vh5rT1r0/OfxSs5o2eI1joCDPlGXb9ZnaJDNrw8r Uy/wjN829F9D7Ar+yvXHSu3iSjK/q3QjQ7IG3xX6cF5Gr8aSQntI0wtwvVHqOnt+h3ct pg/w==
X-Gm-Message-State: APjAAAWL7HdtyiY7Cn+Yi6t8mQB2P+hHRpSiMoYwX6bCwzu8eUuOes+M vH5/Dex6SNJyNPk41OlPsWY8c1NA
X-Google-Smtp-Source: APXvYqz9kaNi68vQAG9VVrZy9rfNQH/rshqdZfp3czALOpxvUPJRQFuFXBPs2wbbnN+W2iWG6gSzZg==
X-Received: by 2002:a1c:7d16:: with SMTP id y22mr19851182wmc.106.1573480925200; Mon, 11 Nov 2019 06:02:05 -0800 (PST)
Received: from [192.168.1.79] (25.131.146.77.rev.sfr.net. [77.146.131.25]) by smtp.googlemail.com with ESMTPSA id j66sm13329090wma.19.2019.11.11.06.02.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Nov 2019 06:02:03 -0800 (PST)
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, 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> <6c9f7880-e494-c2ac-7325-bdfa05eee712@sit.fraunhofer.de>
From: Anders Rundgren <anders.rundgren.net@gmail.com>
Message-ID: <8ac03e95-480a-53d8-14d3-3bae4937db23@gmail.com>
Date: Mon, 11 Nov 2019 15:02:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1
MIME-Version: 1.0
In-Reply-To: <6c9f7880-e494-c2ac-7325-bdfa05eee712@sit.fraunhofer.de>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/rats/5aQNZ5lIHvpKCGKtkBV9Gj_ITtc>
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 14:02:10 -0000

Having multiple ways to do one thing was never a good idea.  COSE would suffice.
Regarding the Base64-encoding of X5C objects, the rational was to be PEM compatible which also was a pretty bad idea since X5C simply isn't PEM compatible by a long shot.

Both are excellent examples of "design by committee".

Anders

On 2019-11-11 13:18, Henk Birkholz wrote:
> 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
>>
> 
> _______________________________________________
> RATS mailing list
> RATS@ietf.org
> https://www.ietf.org/mailman/listinfo/rats
>