Subject: [sacm] [sacmwg/draft-ietf-sacm-coswid] are SWID and CoSWID isomorphic? (#27)

From: Thomas Fossati <[email-masked]>
Date: Fri, 09 Oct 2020 04:47:18 -0700

It is not clear to me whether the intent is that SWID and CoSWID are equivalent data models?

If so, I think `entity-entry` is a bit problematic in this respect because `entity-extension` and SWID's `Meta(s)` are not the same thing.  An `entity-extension` could be constrained to resemble a `Meta` but this doesn't seem to be the case, at least in the version of the draft I'm reading (i.e., -15).

-- 
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/27

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 27 Oct 2020 05:34:06 -0700

Another bit that looks pretty suspicious is around the definition of payload and evidence:
```
payload-or-evidence //= ( payload => [ 2* payload-entry ] )
[...]
payload-or-evidence //= ( evidence => [ 2* evidence-entry ] )
```
where multiple payloads and evidences seem to be allowed in the same CoSWID.  This is different from SWID which allows at most one Evidence and/or Payload:
```
<xs:element name="Payload" type="ResourceCollection" minOccurs="0" maxOccurs="1">
[...]
<xs:element name="Evidence" type="Evidence" minOccurs="0" maxOccurs="1">
```

-- 
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/27#issuecomment-717212370

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 27 Oct 2020 05:39:17 -0700

At first glance it appears to be a 0-1 quantity. Alas, both (and other) are embedded in  a 0-n choice:

`<xs:choice maxOccurs="unbounded">`

-- 
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/27#issuecomment-717215040

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 27 Oct 2020 06:03:50 -0700

Thanks! I had overlooked the wrapping `choice`.  Do you know what purpose does it serve?

-- 
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/27#issuecomment-717228114

---

From: Thomas Fossati <[email-masked]>
Date: Tue, 27 Oct 2020 06:11:32 -0700

Another thing still on the alignment between CoSWID and SWID: in SWID there seem to be no restrictions about mixing Evidence and Payload (at least at a syntactic level).  Why is CoSWID enforcing their mutual exclusion?

-- 
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/27#issuecomment-717232607

---

From: Henk Birkholz <[email-masked]>
Date: Tue, 27 Oct 2020 07:29:20 -0700

The authors are currently meeting on a regular basis and are generating a shared agreement on all inputs, including yours. Each issue leads to discussions of various sizes, currently :-) One of the big topics discussed is the relationship between SWID and CoSWID. As soon as all authors agreed on a way to address a topic, e.g. SWID & CoSWID alignment, we will pull new content into the I-D and reply to the corresponding issue.

According to NIST SP 8060, file hashes are stored in XML any-attributes associated with file types. Currently, CoSWID provides more explicit structures and therefore is intentionally more specific (not allowing SHA1 or MD5, for example & or disallowing the mixture of Evidence and Payload). 

-- 
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/27#issuecomment-717283356

---

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

Since the use of `choice` in the SWID xsd looks like a misprint, and that it's contradicted by the spec [1], wouldn't it be better to make that explicit in the CDDL?  I.e.,:
```
payload-or-evidence //= ( payload => payload-entry )
payload-or-evidence //= ( evidence => evidence-entry )
```

[1] ISO/IEC 19770-2:2015, Section 8.5.3 and Section 8.5.6 (which might also contain another typo)

-- 
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/27#issuecomment-718797703

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 29 Oct 2020 07:53:35 -0700

As the release of the iso spec and corresponding xsd is simply inconsistent, there is no simple way forward here.

We came to the decision that it is likely that implementers start from the XSD, than from the written definition in the spec table (it seems you did, too?).
The assessment included that it does hurt less to allow more than one of each mutual exclusive type of element, than restricting the quantity to one and thereby - potentially - making transformation from a XML SWID tag that uses the unbounded quantity harder.

Having said this. Do you still think it would be better to restrict the quantity here to 1?

-- 
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/27#issuecomment-718806536

---

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

An implementation can always make the syntactic layer refuse to decode more than one entry (not what I do at the moment, but that can be easily fixed).  But I guess the naive implementer - including yours truly in the lot :-) - is likely to code the syntactic layer as per CDDL and then on top of that put a semantic layer that will refuse multiple entries.  And that space between syntax and sema checks potentially creates memory waste, and ultimately attack surface.

If YAGNI then drop it :-)

-- 
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/27#issuecomment-718832403