Subject: Re: [fdt] [Cacao] Public Comment for CACAO Draft

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Dec 2020 08:52:42 +0100

On 2020-09-25, at 21:04, Michael Richardson <[email-masked]> wrote:
> > HTML: https://docs.oasis-open.org/cacao/security-playbooks/v1.0/csd01/security-playbooks-v1.0-csd01.html
> I found having section 2 full of data types at the beginning a bit jarring.

With little mistakes such as

> signed 54-bit value ([-(2**53)+1, (2**53)-1]), […] as defined in [RFC7493]. 

or the empty description column in 2.1.4 (which creates serious work if you try to fill it in).

(What was the variable name syntax?)

Seriously, I don’t expect application layer specifications to get all these details right.
The draft makes pretty good use of the limited vocabulary that it has.

It would be an interesting exercise to write this up in a more actionable way.
Or, maybe write a draft that provides vocabulary that can be used by a draft like this.

Grüße, Carsten

---

From: Bret Jordan <[email-masked]>
Date: Tue, 15 Dec 2020 13:38:31 -0700

Comments inline....

> > signed 54-bit value ([-(2**53)+1, (2**53)-1]), […] as defined in
BRET: Please help me understand how this is wrong, since this was copied
from the RFC.

> or the empty description column in 2.1.4 (which creates serious work if
BRET: Yes, this is still a draft document and there are few TODOs and a few
missing descriptions. If you have suggestions for text for these, that
would be fantastic.

> Or, maybe write a draft that provides vocabulary that can be used by a

BRET: I started writing an ID to capture the data types and common
constructs that need to be created by these higher level specifications. I
even started an ID for how data markings should be done. But my question is
where do I submit these? Do I keep going through the independant submission
process? Or can we get a working group for this kind of work.  Also, if
there are things wrong or things that I did not do correctly, please help
me fix them.

Thanks
Bret

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Dec 2020 00:44:44 +0100

Hi Bret,

On 2020-12-15, at 21:38, Bret Jordan <bret.jordan=[email-masked]> wrote:
> 
> Or can we get a working group for this kind of work.

I would consider a document that defines vocabulary like this to be a good component for CDDL, which the CBOR WG already is chartered to evolve.  A bit like a modern version of the good parts of part 2 of WSD [1], which is probably still the best document of that kind that we have.

(Clearly, I’m not suggesting that CACAO wait for this to spring up, I just see the CACAO document as another item to look at that motivates finally doing this.)

Grüße, Carsten

[1]: https://www.w3.org/TR/xmlschema-2/

(Oh, and the difference between a 54-bit two's-complement signed integer and an I-JSON integer is that the former includes an INT54_MIN of -2**53, while the latter doesn’t (*), which you correctly copied from I-JSON — int54 may be vernacular for the latter, but this is off-by-one.  This little factoid is pretty much inconsequential (**) for CACAO, but a document like the above would get this detail right.)

(*) because it actually does include both +0 and -0.
(**) INT54_MIN *can* be represented in the typical JSON implementation number systems that I-JSON was accommodating, as can be 2**53 — it’s just no longer uniquely distinguishable from INT54_MIN-1 or 2**53+1.  So this little mistake is even more innocuous.

---

From: Bret Jordan <[email-masked]>
Date: Tue, 15 Dec 2020 19:43:33 -0700

Perhaps I can work on an ID for this and submit it to the CBOR working
group? We have done very similar things in STIX and TAXII as well. So it
would be good for me to take all the content I have written and done for
all three of this specifications (STIX, TAXII, and CACAO) and put them
together in a single ID that you and others can help with and comb through
with a fine tooth comb.  Does that seem reasonable to you?

Thanks,
Bret
PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
"Without cryptography vihv vivc ce xhrnrw, however, the only thing that can
not be unscrambled is an egg."

On Tue, Dec 15, 2020 at 4:45 PM Carsten Bormann <[email-masked]> wrote:

> I would consider a document that defines vocabulary like this to be a good
> component for CDDL, which the CBOR WG already is chartered to evolve.  A
> bit like a modern version of the good parts of part 2 of WSD [1], which is
> probably still the best document of that kind that we have.
>
> (Clearly, I’m not suggesting that CACAO wait for this to spring up, I just
> see the CACAO document as another item to look at that motivates finally
> doing this.)
>
> Grüße, Carsten
>
> [1]:
> https://clicktime.symantec.com/3SRZL7zFYPHB8G5QV1wAVd27Vc?u=https%3A%2F%2Fwww.w3.org%2FTR%2Fxmlschema-2%2F
>
> (Oh, and the difference between a 54-bit two's-complement signed integer
> and an I-JSON integer is that the former includes an INT54_MIN of -2**53,
> while the latter doesn’t (*), which you correctly copied from I-JSON —
> int54 may be vernacular for the latter, but this is off-by-one.  This
> little factoid is pretty much inconsequential (**) for CACAO, but a
> document like the above would get this detail right.)
>
> (**) INT54_MIN *can* be represented in the typical JSON implementation
> number systems that I-JSON was accommodating, as can be 2**53 — it’s just
> no longer uniquely distinguishable from INT54_MIN-1 or 2**53+1.  So this
> little mistake is even more innocuous.
>
> --
> Cacao mailing list
> [email-masked]
>
> https://clicktime.symantec.com/3FbpPgtTsB92u5j6v6Zq9827Vc?u=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fcacao
>