Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06

Carsten Bormann <cabo@tzi.org> Tue, 30 July 2019 19:31 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEAC120156; Tue, 30 Jul 2019 12:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 NFLnBbgRi05Q; Tue, 30 Jul 2019 12:31:19 -0700 (PDT)
Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684D412010F; Tue, 30 Jul 2019 12:31:19 -0700 (PDT)
Received: from [192.168.217.120] (p548DCCB9.dip0.t-ipconnect.de [84.141.204.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 45ymrP4KPczyNP; Tue, 30 Jul 2019 21:31:17 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <010701d546f9$a8281da0$f87858e0$@augustcellars.com>
Date: Tue, 30 Jul 2019 21:31:17 +0200
Cc: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-ace-cwt-proof-of-possession.all@ietf.org, ace@ietf.org
X-Mao-Original-Outgoing-Id: 586207875.3243459-12457b4f99cd80d08c82c52f15160361
Content-Transfer-Encoding: quoted-printable
Message-Id: <6A3D405F-F702-4FAB-834B-C258043C655E@tzi.org>
References: <20190730155605.GM47715@kduck.mit.edu> <010701d546f9$a8281da0$f87858e0$@augustcellars.com>
To: Jim Schaad <ietf@augustcellars.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/y_fPgWe-m8B2OpJChQ1qhoURuPU>
Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 30 Jul 2019 19:31:23 -0000

On Jul 30, 2019, at 19:10, Jim Schaad <ietf@augustcellars.com>; wrote:
> From: Benjamin Kaduk <kaduk@mit.edu>; 
> 
> We should be consistent across examples about whether the use of CBOR
> diagnostic notation also requires a disclaimer about "with linebreaks for
> readability".
> 
> [JLS] I don't believe that this disclaimer needs to be present.  Unlike the
> JSON document where what is being presented is in fact JSON, what is being
> presented here is simply a more user friendly readable version of the binary
> data.  

Right.  But it is still useful for the reader to be able to look up how that notation works.

CBOR diagnostic notation was originally defined in Section 6 of RFC 7049, precisely for the purpose of discussing CBOR data items in a human-readable way.
Many current documents make use of some extensions of the original diagnostic notation, such as the use of whitespace in hex strings.  These extensions are documented in Appendix G of RFC 8610, Extended Diagnostic Notation (EDN).  This is what always should be referenced, and then no disclaimer is needed.

Grüße, Carsten

PS.:

> (A different question would be if the hex should be presented but
> that is not what the ACE group is doing in general.)

I don’t think that showing a hex representation of the encoded bytes is needed either; CBOR should be well-known enough to readers of this document via CWT already.