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

From: David Waltermire <[email-masked]>
Date: Thu, 18 Feb 2021 06:38:48 -0800

@henkbirkholz I don't think this issue has been addressed yet. We should address this now before the spec enters the IESG queue.

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

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 18 Feb 2021 07:35:45 -0800

I might be missing something obvious here, but the inline CDDL addresses the issue like the full CDDL spec.

The inline order is:

* stuff
global-attributes
* $$extension-point

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

---

From: cabo <[email-masked]>
Date: Thu, 18 Feb 2021 07:45:50 -0800

Yes, and that was the problem, as global-attributes contains a catch-all that catches everything before the $$extension-point

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

---

From: cabo <[email-masked]>
Date: Thu, 18 Feb 2021 07:47:30 -0800

Why is that catch-all not another extension-point?

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

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 18 Feb 2021 07:47:50 -0800

oh... thanks, of course. There is a fix for that out there. Will graft another PR from that.

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

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 18 Feb 2021 07:50:41 -0800

because that might be... less isomorphic to the XSD that literally uses the any attribute.

Do you think it would be more elegant to add another socket? Is there a real world advantage?

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

---

From: cabo <[email-masked]>
Date: Thu, 18 Feb 2021 07:57:22 -0800

Right now your CDDL will validate any 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/29#issuecomment-781444832

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 18 Feb 2021 08:01:00 -0800

that is the point. well-defined, well-defined extension, and "the rest" are distinguished. "Careful parsing" can start with "the rest" now. We could discuss mandating the use of a CDDL extension for every single occurring map index, but the agreement was to allow for 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/29#issuecomment-781447680

---

From: David Kemp <[email-masked]>
Date: Thu, 18 Feb 2021 09:21:54 -0800

Isn't the point from the original issue that SWID does not accept (non-namespaced) anythings?  The philosophy of writing a security specification that says "I'll accept A, B, C, and anything else" seems like a problem.  Contrary to the ijson approach of allowing anything that isn't prohibited, defining an extension before accepting CoSWIDs that match it seems prudent.

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

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 18 Feb 2021 10:10:13 -0800

Well, while I absolutely agree with the concept you illustrated, the ISO provided XSD representing a security specification that allows for that behavior. Quoting from https://standards.iso.org/iso/19770/-2/2015-current/schema.xsd:

```
<xs:anyAttribute namespace="##other" processContents="lax">
<xs:annotation>
<xs:documentation>
Allows any undeclared attributes on any element as long as the attribute is placed in a different namespace.
</xs:documentation>
</xs:annotation>
</xs:anyAttribute>
```

While ##other is required, in the end processContent is lax. That is exactly what we are mapping here in CoSWID.

We can diverge from that and be more strict. I am fine with the idea, but we have to come to consensus.

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

---

From: David Kemp <[email-masked]>
Date: Thu, 18 Feb 2021 10:46:19 -0800

Extensibility can be viewed as error handling: an unrecognized attribute in a normal container is known bad, but in an extension-point container the application can search for a newer version of the same namespace or try to resolve a different namespace,  Successful resolution allows the attribute to be recognized and validated, unsuccessful raises the validation error.

I don't know how XML treats _namespace="##other"_, but it might require the specified namespace to resolve before validation succeeds.

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

---

From: David Kemp <[email-masked]>
Date: Fri, 19 Feb 2021 07:37:21 -0800

My mistake: processContent="lax" does mean that extension schema is not required.  I hope consensus can be obtained on making CoSWID equivalent to "strict".

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

---

From: Henk Birkholz <[email-masked]>
Date: Fri, 19 Feb 2021 07:48:00 -0800

At the moment it seems that we are steering towards a targeted and concise 2nd WGLC. We'd start such a potential WGLC with a less strict spec definition that maps the "lax" concept in alignment with ISO. One outcome could be that the work here will trigger errata in ISO, but that result is neither implied nor guaranteed. If there are changes to ISO in the future, we can adhere to them and adapt the CoSWID specification. Does that sound feasible?

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

---

From: cabo <[email-masked]>
Date: Fri, 19 Feb 2021 09:27:35 -0800

For another view at strict/lax, see 

<https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-02.html#name-formal-syntax-of-sdf>
and
<https://www.ietf.org/archive/id/draft-ietf-asdf-sdf-02.html#name-json-schemaorg-rendition-of>

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

---

From: Henk Birkholz <[email-masked]>
Date: Sun, 21 Feb 2021 11:20:35 -0800

Closed #29 via #37.

-- 
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#event-4356685254