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

From: Thomas Fossati <[email-masked]>
Date: Wed, 14 Oct 2020 03:41:41 -0700

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

---

From: cabo <[email-masked]>
Date: Wed, 14 Oct 2020 04:20:27 -0700

>From a tool perspective, I think having a map with both a catch-all like that provided in global-attributes and an extensible socket like `* $$coswid-extension` in a single map can be problematic even if the order is fixed: extensions not known will then turn up in global-attributes, known extensions in $$coswid-extension, which may or may not be what the application expects.  

-- 
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#issuecomment-708337213

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 14 Oct 2020 05:51:46 -0700

> From a tool perspective, I think having a map with both a catch-all like that provided in global-attributes and an extensible socket like `* $$coswid-extension` in a single map can be problematic e…

I agree, the two extension points (`global-attributes` and the various `-extension` sockets) should be separated.

-- 
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#issuecomment-708380819

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 28 Oct 2020 05:52:44 -0700

The proposal discussed between authors is:

separate any-attribute labels from any other labels in maps by using:

```
global-attributes = (
  ? lang => text,
  ? any-attributes = { + any-attribute },
)
```

An alternative and less invasive approach would be to allow all labels in the same map, but moving the "catch all" any-attribute to the end of each map any-attribute occurs in.

Which approach would you prefer?

-- 
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#issuecomment-717912153

---

From: cabo <[email-masked]>
Date: Wed, 28 Oct 2020 06:18:38 -0700

```
Syntax.

-- 
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#issuecomment-717926390

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 28 Oct 2020 06:19:52 -0700

`? any-attributes : { + any-attribute },`

:o)

-- 
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#issuecomment-717927062

---

From: cabo <[email-masked]>
Date: Wed, 28 Oct 2020 06:21:43 -0700

You need a label number then.

-- 
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#issuecomment-717928179

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 28 Oct 2020 06:29:07 -0700

Yes, but first we have to agree on the way forward, just reordering the members of map in a way that global-attributes are always appended to the set would not require a new label. As adding such a global label might shift quite a few labels and impacts implementations, I am very careful here.

-- 
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#issuecomment-717932767

---

From: cabo <[email-masked]>
Date: Wed, 28 Oct 2020 06:30:34 -0700

I'm also a bit more focused on the result than on the way of specifying it -- moving the globals to later in the group sequence might solve this problem already.  You just can't have two catch-alls.

-- 
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#issuecomment-717933662

---

From: Henk Birkholz <[email-masked]>
Date: Wed, 28 Oct 2020 06:56:06 -0700

My favored proposal is "just" a reordering, like this:

all defined-label members,
extension-point,
global-attributes,

Implying that extension-points are not to mess with the lang label in global attributes.

-- 
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#issuecomment-717949867

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 29 Oct 2020 07:19:08 -0700

> Implying that extension-points are not to mess with the lang label in global attributes.

This seems the least invasive solution implementation-wise.  In fact, this has zero impact on my code.

-- 
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#issuecomment-718783805