are SWID and CoSWID isomorphic?

[thomas-fossati]

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

Another point of apparent divergence is the explicit definition of hash in the file-entry map. In SWID hashes are introduced via Meta and there can be any number of them (e.g., one for SHA1, one for MD5, one for SHA256).

Surely, in CoSWID one could add an extra-hash extension via file-extension like this:

$$file-extension //= (
  extra-hash => hash-entry / [ 2* hash-entry ],
)
extra-hash = -666

but then I wonder why can't we just do the above and get rid of the special diversion? (We'd be exercising the extension path too, which seems like a plus.)

[thomas-fossati]

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">

[henkbirkholz]

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">

[thomas-fossati]

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

[thomas-fossati]

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?

[henkbirkholz]

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

[thomas-fossati]

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)

[henkbirkholz]

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?

[thomas-fossati]

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 waste of resources (on the constrained side, where they are more scarce), and ultimately attack surface.

If YAGNI then drop it :-)

[david-waltermire]

I believe we should follow the spec as it is normative, not the XSD. So we should restrict the payload and evidence to a single optional instance.

[henkbirkholz]

that would result in:

payload-or-evidence //= ( payload => payload-entry )
payload-or-evidence //= ( evidence => evidence-entry )