[sacm] [sacmwg/draft-ietf-sacm-coswid] can't use CDDL to validate seemingly valid CBOR (#29)

Thomas Fossati <notifications@github.com> Wed, 14 October 2020 10:41 UTC

Return-Path: <noreply@github.com>
X-Original-To: sacm@ietfa.amsl.com
Delivered-To: sacm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF083A1483 for <sacm@ietfa.amsl.com>; Wed, 14 Oct 2020 03:41:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
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 Wic85EvLD_aH for <sacm@ietfa.amsl.com>; Wed, 14 Oct 2020 03:41:42 -0700 (PDT)
Received: from out-26.smtp.github.com (out-26.smtp.github.com [192.30.252.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673343A1485 for <sacm@ietf.org>; Wed, 14 Oct 2020 03:41:42 -0700 (PDT)
Received: from github.com (hubbernetes-node-5aebad7.ash1-iad.github.net [10.56.121.75]) by smtp.github.com (Postfix) with ESMTPA id 34EA85E07AC for <sacm@ietf.org>; Wed, 14 Oct 2020 03:41:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1602672101; bh=5ZGsWVYiwAjUH7bewTnNymzz6iGZQ049cOUrBS+ujXI=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=Gfh4v+j84jUFCeg4BzpOIwFutwGqCq1aFort761+Pf0wv3ZmP3jwA9jyfOvMFssuP +IrteMdJXDxyaGs3bKiRJ2sEdY9mihz6qyTpPod2ZcYgsuwWu1nvIesG22j3P3mAB6 6GLrvCZUTAiMWANDadmoilaG3R23zEA3hk9eK3Sg=
Date: Wed, 14 Oct 2020 03:41:41 -0700
From: Thomas Fossati <notifications@github.com>
Reply-To: sacmwg/draft-ietf-sacm-coswid <reply+ACTMJUKIAMWF3VDJ5LGMGF55SK3OLEVBNHHCV7W7PY@reply.github.com>
To: sacmwg/draft-ietf-sacm-coswid <draft-ietf-sacm-coswid@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <sacmwg/draft-ietf-sacm-coswid/issues/29@github.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f86d5e531310_5319b415639"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: thomas-fossati
X-GitHub-Recipient: sacm
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: sacm@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/sacm/xhEY1bDYyOhXbwCKD1GSiX-hB90>
Subject: [sacm] [sacmwg/draft-ietf-sacm-coswid] can't use CDDL to validate seemingly valid CBOR (#29)
X-BeenThere: sacm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: SACM WG mail list <sacm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sacm>, <mailto:sacm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sacm/>
List-Post: <mailto:sacm@ietf.org>
List-Help: <mailto:sacm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sacm>, <mailto:sacm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Oct 2020 10:41:44 -0000

If I try to validate the following minimalist (and seemingly valid) `file-entry` using the CDDL provided in the draft:
```
# diag
{ 24: "fw.bin" }

# pretty
a1                 # map(1)
   18 18           # unsigned(24)
   66              # text(6)
      66772e62696e # "fw.bin"
```
I get the following error from the [cddl](https://rubygems.org/gems/cddl) tool:
```
$ cddl file-entry.cddl validate min.cbor
CDDL validation failure (nil for {24=>"fw.bin"}):
["fw.bin", [:prim, 3], nil]
["fw.bin", [:prim, 3], null]
```
This happens because the inlined `any-attribute` consumes all of the map, leaving nothing for `fs-name => text` (this is what the rather cryptic message from the cddl tool is about.)

One could fix this specific bit of CDDL by relocating `global-attributes` to the bottom of the `filesystem-item`, but given the pervasiveness of the `global-attributes` group embedding, it's almost certain that similar situations will arise in other places too depending on the relative positioning of the various pieces.

My suggestion would be to make `global-attributes` a map instead, in order remove ambiguities by enforcing tighter namespace segregation.

Note that SWID uses explicit name spacing to cleanly handle these kinds of conflicts.  For example, the following is valid SWID because the `foofoo` extension is explicitly provided under the `tns` namespace:
```
<SoftwareIdentity
  xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
  xmlns:tns="http://localhost/foo.xsd"
  name="Roadrunner boot loader"
  tagId="example.acme.roadrunner-sw-bl-v1-0-0"
  version="1.0.0"
  tns:foofoo="bing"
>
[...]
</SoftwareIdentity>
```
Whereas this non-namespaced `foofoo` (closely matching the `any-attribute` philosophy) would fail validation:
```
<SoftwareIdentity
  xmlns="http://standards.iso.org/iso/19770/-2/2015/schema.xsd"
  name="Roadrunner boot loader"
  tagId="example.acme.roadrunner-sw-bl-v1-0-0"
  version="1.0.0"
  foofoo="bong"
>
[...]
</SoftwareIdentity>
```

So more generally it seems to me that the way `global-attributes` are currently handled is way too lax and doesn't reflect the original SWID approach.





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/sacmwg/draft-ietf-sacm-coswid/issues/29