Re: [stir] Second WG Last Call for RFC4474bis

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 13 September 2016 17:29 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 6094312B43F for <stir@ietfa.amsl.com>; Tue, 13 Sep 2016 10:29: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 zR3YX6MOoh-L for <stir@ietfa.amsl.com>; Tue, 13 Sep 2016 10:29:14 -0700 (PDT)
Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id CA81412B42A for <stir@ietf.org>; Tue, 13 Sep 2016 10:29:13 -0700 (PDT)
X-AuditID: 12074413-ab7ff70000000955-d7-57d83767756c
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 17.B1.02389.76738D75; Tue, 13 Sep 2016 13:29:13 -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 u8DHTAF5009221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <stir@ietf.org>; Tue, 13 Sep 2016 13:29: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>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <b7615c44-4881-0cff-44ad-7f350f3261e2@alum.mit.edu>
Date: Tue, 13 Sep 2016 13:29: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: <859C0A33-E957-4971-BA43-7CC2537FBE83@vigilsec.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFIsWRmVeSWpSXmKPExsUixO6iqJtpfiPc4Os1Hovla7cxOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8+FLpaCX+wVzevMGhhb2LoYOTkkBEwklj+ewNTFyMUhJLCV UeL8r8eMEM4VJolfn+4xg1QJC5hJNB/ZxgpiiwgIStybcZoJxBYSWM0ocfiCKIjNJqAlMefQ fxYQm1fAXmLP6TWMIDaLgKrEkq2PwXpFBdIkph/uZ4SoEZQ4OfMJWD2ngIPEymPnwWxmAVuJ O3N3M0PY8hLNW2czT2Dkm4WkZRaSsllIyhYwMq9ilEvMKc3VzU3MzClOTdYtTk7My0st0jXX y80s0UtNKd3ECAky4R2Mu07KHWIU4GBU4uEN+HE9XIg1say4MvcQoyQHk5Io7/w1QCG+pPyU yozE4oz4otKc1OJDjBIczEoivNVmN8KFeFMSK6tSi/JhUtIcLErivGpL1P2EBNITS1KzU1ML UotgsjIcHEoSvCEgjYJFqempFWmZOSUIaSYOTpDhPEDDG8CGFxck5hZnpkPkTzEqSonzTjEF SgiAJDJK8+B6YUngFaM40CvCvK0g7TzABALX/QpoMBPQ4C0gH/EWlyQipKQaGNkOyZc+nb/9 Uckil3vVuus3mta59Z/MP3xAOC9Wz8SsuprPeZoLh9/GC13++9SjZs3mWFL301ol+VvmnZ64 2u/CFw+lyv9RPOC/7G3ArTuC7ju/XMxrfmAaKj+x0lb65hZlvhKpY3afRNe4Hrz141zdvESW z6lRvId1XeW7A4JK7ivu7jW4oMRSnJFoqMVcVJwIADqhhsjdAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/rGuolfhgj0-mWNnbmCTpvJiLFCU>
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 17:29:15 -0000

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 / "/" / “+” / “="

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"=") ]

OTOH referencing RF4648 may be sufficient.

	Thanks,
	Paul