Re: [cacao] Slides for tomorrow's call

[Frans Schippers <f.h.schippers@hva.nl>]

Dear member

My comments on the sheets of todayâs meeting.

Playbooks are written in Jason Unicode (coded as UTF-8)

Page 6: Overview properties
I agree with the introduction of identities.
They form a reference to a person and/or organisation with contact information as well as signature and encryption keys.
They should be searchable in de database [ Either centralised or decentralised (an other topic)]
as well as the playbooks.

Page 7: Overview properties
Should playbooks have version (could be the modification timestamp)
The created identities should also be listed (owners)
How do we modify a playbook? Who is allowed to change a playbook.
Change increases the version. Voting on new version?
A new version is accepted if the majority of owners have signed the updated playbook.
Do we go for and integer-timestamp or string-timestamp?

Page 9: Overview properties
Deprecated could be a timestamp instead of yes-no.
Missing this field indicates that it is not deprecated.

Based on who is able to execute a playbook we could have more types.
An execution my humans can be less specific than fully-automated playbooks.

Page 10: Overview properties
I would prefix any CACAO-uuid with âcacaoâ so âcacao-identityâ

Page 11/12:
I see the notion of a structure play book coded in Json.
However this is not so human readable.
I would stick to a more natural program language like Python
And code those condtructs in JSON,
Or use a beautifier to show human-readable text.
We need subroutine/process with parameter and return mechanism.
Let's donât invent an other programming language.

Page 13:
Any referential action should have a uuid cacao-action

Page 14:
Ik donât like mixed lists: ( "model-1â, { â } â }
We have to have more realistic playbooks to determine how to describe them.
The example is too simple.

Page 14:
What about side-effects.
Condition means that some steps are not executed.
What about exeptions?

Page 16
The essence of signing is that it is implicitly revoked when a change is made.
We could argue that change of some properties wonât effect the hash and therefor the
Signature.

Extra notes:
In the long term signed would (automatically) ask to resign a changed playbook (of part of it)

I would suggest that alle uuid objects are searchable on a centrale (or distributed) database/storagesytem.
Certain properties can be used to narrow down the search.

Frans

> On 30 Sep 2019, at 18:31, Bret Jordan <Bret_Jordan@symantec.com> wrote:
> 
> All,
> 
> Here are the slides for tomorrow's call.
> 
> Thanks
> Bret
> 
> <2019-10-01 CACAO TC Meeting.pdf><ATT00001.txt>



Frans Schippers
Cyber Security
Lecturer / Researcher

Amsterdam Universe of Applied Science
HBO-ICT
Wibautstraat 2-4
1091 GM Amsterdam

PGP: 12D1 D930 488C 22B7 6AFF  BFF7 218C 865E D6E0 6B48

Attachment: signature.asc
Description: Message signed with OpenPGP