Re: [stir] Second WG Last Call for RFC4474bis

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 13 September 2016 18:26 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 9FB31120727 for <stir@ietfa.amsl.com>; Tue, 13 Sep 2016 11:26:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.709
X-Spam-Level:
X-Spam-Status: No, score=-5.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.508, 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 zXdsWtNfR6Wl for <stir@ietfa.amsl.com>; Tue, 13 Sep 2016 11:26:12 -0700 (PDT)
Received: from alum-mailsec-scanner-6.mit.edu (alum-mailsec-scanner-6.mit.edu [18.7.68.18]) by ietfa.amsl.com (Postfix) with ESMTP id A88BE126B6D for <stir@ietf.org>; Tue, 13 Sep 2016 11:26:12 -0700 (PDT)
X-AuditID: 12074412-1afff70000000931-c8-57d844c3c9ab
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 14.5A.02353.3C448D75; Tue, 13 Sep 2016 14:26:11 -0400 (EDT)
Received: from 132-177-252-148.ip.sipit.net ([132.177.252.148]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u8DIQAoH012761 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <stir@ietf.org>; Tue, 13 Sep 2016 14:26:11 -0400
To: stir@ietf.org
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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <45382e81-68f9-f1c7-ae3f-42a6069a11a9@alum.mit.edu>
Date: Tue, 13 Sep 2016 14:26:10 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <b7615c44-4881-0cff-44ad-7f350f3261e2@alum.mit.edu>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNIsWRmVeSWpSXmKPExsUixO6iqHvY5Ua4wY8uE4vla7cxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY+n3A+wF2wUq+r6+ZmpgvMTTxcjJISFgIrH/xXVmEFtIYCuj xLuWsi5GLiD7CpPEvVdXwRLCAmYSzUe2sYLYIgKCEvdmnGaCKHrIKDHpwAs2kASbgJbEnEP/ WUBsXgF7iQmzOsAaWARUJead6QCLiwqkSUw/3M8IUSMocXLmE7A4p4CDRP/lNUwgNrOArcSd ubuZIWx5ieats5knMPLNQtIyC0nZLCRlCxiZVzHKJeaU5urmJmbmFKcm6xYnJ+blpRbpmunl ZpbopaaUbmKEhJnQDsb1J+UOMQpwMCrx8Ab8uB4uxJpYVlyZe4hRkoNJSZSX1eJGuBBfUn5K ZUZicUZ8UWlOavEhRgkOZiURXgVgcAvxpiRWVqUW5cOkpDlYlMR5fy5W9xMSSE8sSc1OTS1I LYLJynBwKEnw/nMGahQsSk1PrUjLzClBSDNxcIIM5wEargo2vLggMbc4Mx0if4pRUUqctxqk WQAkkVGaB9cLSwOvGMWBXhHmvQRSxQNMIXDdr4AGMwEN3rLmOsjgkkSElFQD49oskynPZWYd nf1pX4Aoo0+J2+3PcerXbQQc9Q8xzFRNd4rgrHjz9tSZX69XtOi+jF+w6+KvoyWnly/XVnL7 +c3w6+wLrPY3rh74bXP5DkOfx+Jj95QWmxunO1ddXc91SL/lc+zKNsm78p/z8wu6rQ+YT9cL /vSXzz/ZezejdFjHyh2FuTtm/VViKc5INNRiLipOBAANn9jE3gIAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/fU3nSDp_VGLxIrBmASaEtio6GNQ>
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:26:15 -0000

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.

	Thanks,
	Paul