Re: [stir] Second WG Last Call for RFC4474bis

Russ Housley <housley@vigilsec.com> Tue, 13 September 2016 18:58 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 513E612B4DB for <stir@ietfa.amsl.com>; Tue, 13 Sep 2016 11:58:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] 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 RuYTx4cE60Hd for <stir@ietfa.amsl.com>; Tue, 13 Sep 2016 11:58:38 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E78412B02E for <stir@ietf.org>; Tue, 13 Sep 2016 11:58:38 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2372A300A05 for <stir@ietf.org>; Tue, 13 Sep 2016 14:44:18 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xwADPCwzQjwm for <stir@ietf.org>; Tue, 13 Sep 2016 14:44:17 -0400 (EDT)
Received: from 132-177-252-228.ip.sipit.net (unknown [132.177.252.228]) by mail.smeinc.net (Postfix) with ESMTPSA id C6C09300086; Tue, 13 Sep 2016 14:44:16 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <45382e81-68f9-f1c7-ae3f-42a6069a11a9@alum.mit.edu>
Date: Tue, 13 Sep 2016 14:58:35 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <10F20385-407D-41C5-94FF-013354FE44C0@vigilsec.com>
References: <C1E751BC-55E9-4D8C-A6A5-B5674835870E@vigilsec.com> <10F4895C-4103-497A-B1E0-7B6CB617F13C@vigilsec.com> <859C0A33-E957-4971-BA43-7CC2537FBE83@vigilsec.com> <b7615c44-4881-0cff-44ad-7f350f3261e2@alum.mit.edu> <45382e81-68f9-f1c7-ae3f-42a6069a11a9@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/GWm3AN8HvLd4HMKELnp8Wy0XNic>
Cc: IETF STIR Mail List <stir@ietf.org>
Subject: Re: [stir] Second WG Last Call for RFC4474bis
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Sep 2016 18:58:40 -0000

On Sep 13, 2016, at 2:26 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> Replying to myself :-(
> 
> I discovered more problems with this:
> 
> I presume that there should be some consistency between this document and passport and JWS regarding how base64 encoding is done.
> 
> * JWS [RFC7515] defines a modified encoding that is like "base64url" from RFC4648 except that it omits the trailing "=" for padding. It uses BASE64URL(octets) to denote this.
> 
> * passport references JWS, and also uses BASE64URL in examples.
> 
> * as I noted below, the examples in rfc4474bis clearly use "base64" encoding as defined in RFC4648, including the trailing "=" pad characters.
> 
> ISTM the proper fix for this is for both rfc4474bis and passport to explicitly reference RFC7515 for the definition of BASE64URL. Then the examples in 4474bis need to be changed accordingly. Once this is done there is no need for allowing "=" in the syntax.
> 
> More below.
> 
> On 9/13/16 1:29 PM, Paul Kyzivat wrote:
>> On 9/13/16 10:21 AM, Russ Housley wrote:
>>> I was talking to a developer a few minutes ago, and he found a small
>>> bug.  It is very simple to fix.  Maybe he will find other bugs as
>>> development continues …
>>> 
>>> In section 4, the ABNF includes:
>>> 
>>>      base64-char = ALPHA / DIGIT / "/" / "+"
>>> 
>>> 
>>> This line should say:
>>> 
>>>      base64-char = ALPHA / DIGIT / "/" / “+” / “="
> 
> Actually, now it should be:
> 
>         base64-char = ALPHA / DIGIT / "-" / “_”
> 
>> That is an improvement.  However, the document lacks any definition of
>> how base64 encoding/decoding works. I suggest a reference to RFC4648.
>> That RFC has two distinct base64 encodings: "base64" and "base64url".
>> The examples in this draft clearly use "base64" because some of them
>> contain "/".
> 
> 
>> Also, it would be possible to write the syntax to more tightly define
>> the syntax for base64:
>> 
>>      canonical-str = "canon" EQUAL LDQUOT base64-encoding RDQUOT
>>      base64-encoding =
>>         *(3base64-char) [ (2base64-char "=") / (base64-char 2"=") ]
> 
> The above isn't right. I was going to correct it, but now there is no need to do so.
> 

You are right, the equal sign is not needed.  JWT uses Base64url encoding, which is defined in RFC 7515.  Base64url encoding produces the URL-safe and filename-safe result.  It uses “-“ instead of “+“, it uses “_” instead of “/“, and it strips any trailing “=“ characters.

RFC 7515, Appendix C shows how to convert a Base64 string to a Base64url string.

So, the ABNF above should be:

      signed-identity-digest = LDQUOT *base64url-char RDQUOT

      canonical-str = "canon" EQUAL LDQUOT *base64url-char RDQUOT

     base64url-char = ALPHA / DIGIT / “_" / “-“

Russ