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

Carsten Bormann <> Tue, 30 July 2019 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2CEAC120156; Tue, 30 Jul 2019 12:31:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.197
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NFLnBbgRi05Q; Tue, 30 Jul 2019 12:31:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 684D412010F; Tue, 30 Jul 2019 12:31:19 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (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 <>
In-Reply-To: <010701d546f9$a8281da0$f87858e0$>
Date: Tue, 30 Jul 2019 21:31:17 +0200
Cc: Benjamin Kaduk <>,,
X-Mao-Original-Outgoing-Id: 586207875.3243459-12457b4f99cd80d08c82c52f15160361
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <010701d546f9$a8281da0$f87858e0$>
To: Jim Schaad <>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <>
Subject: Re: [Ace] AD review of draft-ietf-ace-cwt-proof-of-possession-06
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Jul 2019 19:31:23 -0000

On Jul 30, 2019, at 19:10, Jim Schaad <> wrote:
> From: Benjamin Kaduk <> 
> 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


> (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.