[Cbor] Combining CBOR protocol libraries

Laurence Lundblade <lgl@island-resort.com> Thu, 20 May 2021 19:37 UTC

Return-Path: <lgl@island-resort.com>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id E0A353A234C for <cbor@ietfa.amsl.com>; Thu, 20 May 2021 12:37:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id yRkT1ybCl7_6 for <cbor@ietfa.amsl.com>; Thu, 20 May 2021 12:37:44 -0700 (PDT)
Received: from p3plsmtpa09-10.prod.phx3.secureserver.net (p3plsmtpa09-10.prod.phx3.secureserver.net []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE6E3A234E for <cbor@ietf.org>; Thu, 20 May 2021 12:37:44 -0700 (PDT)
Received: from [] ([]) by :SMTPAUTH: with ESMTPA id joUJlFYu04jcHjoUJlFVCl; Thu, 20 May 2021 12:37:43 -0700
X-CMAE-Analysis: v=2.4 cv=GqeHRm5C c=1 sm=1 tr=0 ts=60a6ba87 a=t2DvPg6iSvRzsOFYbaV4uQ==:117 a=t2DvPg6iSvRzsOFYbaV4uQ==:17 a=0XtbOteLAAAA:20 a=eNxEihdiSrps5bonez0A:9 a=QEXdDO2ut3YA:10 a=K5BRns4txGll-pm6:21 a=_W_S_7VecoQA:10 a=WQnItmPV2fbdzLaCP6-h:22 a=Z5ABNNGmrOfJ6cZ5bIyy:22 a=bWyr8ysk75zN3GCy5bjg:22
X-SECURESERVER-ACCT: lgl@island-resort.com
From: Laurence Lundblade <lgl@island-resort.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E0890120-D62D-4550-8D65-F5263DEA1B8C"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\))
Message-Id: <2AE5612D-B305-4F2C-BC1A-F36F0093F0C0@island-resort.com>
Date: Thu, 20 May 2021 12:37:43 -0700
Cc: rats@ietf.org
To: cbor@ietf.org
X-Mailer: Apple Mail (2.3445.104.17)
X-CMAE-Envelope: MS4xfMwib5FLSGXr0yB1S6lLrQzAplQu6md+c3w4HipDt0oSp/N9cJmg2/+i48YdyDyXKhznw1Ard7PD3zSzk5BkRtJsOr52ZhWCMWVULW/NGpf0tWUUhlPI 7wsTKUW75J5JpiuvBbJ91brbV4OjPkJSyMvnIMxAGykDDPBy/OEacPiSGMova5eBqEaNR2vykckc36+adNqjG2jRmZBwKRGpvk4=
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/xZP_46B2VE9ehfgrUlio7THFvF4>
Subject: [Cbor] Combining CBOR protocol libraries
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2021 19:37:46 -0000

This is in the context of defining how CoSWID should be integrated into EAT <https://github.com/ietf-rats-wg/eat/pull/102>, but seems like a general CBOR protocol library implementation issue.

Let’s say you have a CoSWID library that uses tinyCBOR for CBOR decoding. Further let’s say all you have is a header and lib, no source. You have a .h file and a .a file.

Same for an EAT implementation, but it uses QCBOR for CBOR decoding.

I assume the input to the CoSWID decoding library is a binary byte string with the encoded CBOR. Can’t really be anything else, can it?

How to you take the binary encoded CoSWID out of the EAT and feed it to the CoSWID library?

If the EAT claim to hold a CoSWID is defined like this

eat_coswid_claim = (
    coswid => concise-swid-tag

it is truly not possible to feed the CoSWID from the EAT to the CoSWID library. QCBOR, and as far as I know, most CBOR decoders do not provide access to a still-encoded sub-chunk of the CBOR they are decoding. There’s no way to get the binary CBOR encoded byte string out of the EAT.

It seems the only possibility here is byte string wrapping like this:

eat_coswid_claim = (
    coswid => bstr .cbor concise-swid-tag

I think this generalizes to just about every CBOR protocol that includes another CBOR protocol. Every time you put a CBOR protocol message inside another different CBOR protocol message is MUST be byte string wrapped!

OK, well maybe there can be some exceptions, but I don’t think they are universal enough that they can be assumed in CBOR protocol design.

If the two libraries use the same CBOR decoder, then EAT’s decoder instance can be handed to the CoSWID decoder for temporary use to decode the CoSWID. Or similarly, if the two protocols’s being combined always go hand-in-hand and thus will rarely be implemented by separate libraries, then implementations will usually use the same CBOR decoder.

Note that this doesn’t really arise for COSE payloads because they are always byte-string wrapped.

Seems like the CBOR-based X.509 certificates going into COSE headers partially have this problem. In a lot of cases the COSE library and the CBOR-based X.509 cert library will go hand-in-hand and use the same decoder. But note that without byte-string wrapping of CBOR-based cert, they will always have to go hand-in-hand. You will not be able to integrate a CBOR-Cert library that uses one CBOR decoder in with a COSE library that uses a different decoder.

So the up shot for me here is that best practice for a CBOR protocol that is embedded in another CBOR protocol is byte-string wrapping.