RE: [cacao-comment] comments on security-playbooks-v1.0-csd01.docx

Hi Jordan. Mi comments inline

BR,

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ Juan

From: cacao-comment@lists.oasis-open.org <cacao-comment@lists.oasis-open.org> On Behalf Of Bret Jordan
Sent: Wednesday, 9 September, 2020 20:54
To: Postlbauer, Juan <jpc@hpe.com>
Cc: cacao-comment@lists.oasis-open.org; Odini, Marie-Paule (CMS ww) <marie-paule.odini@hpe.com>
Subject: Re: [cacao-comment] comments on security-playbooks-v1.0-csd01.docx

Hello Juan,

Thank you for your comments and review of the document. The way you have sent your comments is great.

1) Yes, in section 2.3 it would be good to have a vocab, but we were not sure what the entries should be or if there was an existing vocab that we could just use. If you know of one, or if you know of additional entries we should include, please let us know so we can add them. [Postlbauer, Juan] . https://enterpriseintegrationlab.github.io/icity/Contact/doc/index-en.html has âhomeâ , âofficeâ and âcottageâ for addresses. And for phones it defines Home, Work, Cell, Fax and TollFree

2) Someone can correct my grammar if I am wrong, but I believe in section 2.4 it is correct when it says "MUST only contain the characters" where characters are plural, and then we define in the list the type of characters that can be used. So yes, you can have multiple underscores in a key name.[Postlbauer, Juan] ÂI would then remove the âanâ: â..numerals 0-9, and underscore (_)

3) In 2.5 for the hash type. Yes, that is a potential problem. But then there is also the problem of support a bunch of hash types that other people do not understand. It is a trade off between useability and futureproofing. I am not sure which way is right. In the STIX world we went too far in the other direction and thus made a mess of things. So here we were trying to make it easier to implement. But your point is very valid. Maybe we add a hash_type but require it to be SHA256 for this version of the spec, or SHA512. Thoughts???[Postlbauer, Juan] ÂMakes all sense to me. In ETSI specs there is also a closed of list of allowed algos

4) For 2.6, how should we fix this?[Postlbauer, Juan] ÂInclude -180.0 but exclude +180.0 (or the other way around)

5) For 5.1 yeah it might be good to keep things in the same tense and form. I am not tied to complete and completion could be a good option. Is there a better word choice?

6) For 7.8. That is great. Can you propose something that would address this? [Postlbauer, Juan] ÂI would provide a string field specifying the type of authentication (e.g Password, OAuth2, Certificate). And then a dictionary with the parameters (and the valid keys in this dictionary depend on the authentication type ). ÂSo a sample value could be:

[Postlbauer, Juan] Â

authentication_type=âOAUTH2â

authentication_parameters: {

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ clientId=âxxxxâ

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ clientPassword=âyyyyâ

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ tokenEndpoint=âhttps://whatever.it.is/the/endpointâ

ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ }

7) For 7.9, good point. That was an oversight from a copy-paste.

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 Wed, Sep 9, 2020 at 11:02 AM Postlbauer, Juan <jpc@hpe.com> wrote:

First message to the mailing list, so I donât know if you prefer the comments to be plain text in the email messages or if I should attach an edited version of the document with tracking changes and comments. Tell me if the text below is not enough

Some comments:
in 2.3 , it states that the keys could be things like "work", "home", "personal", etc. Would it be worth to have a vocabulary for that?
at the end of 2.4 (page 12 ) it says and an underscore (_). Is there a reason why only one can be present? Or should if be and underscores(_)
in 2.5 hash is used for SHA256. At some point in the future, SHA256 might become obsolete, need replacement, and then confusing will arise. I suggest to have a hash_algorithm indicating the type of hash and then a hashÂ_value indicating the value (ETSI SOL001 and SOL004 do this)
in 2 .6, longitude says between -180.0 and 180.0 inclusive. But -180.0 and 180.0 represent the same longitude, so if the sentence means both inclusive then there may be representation ambiguity (and comparisons will need to take this into account.
in 5.1 on_success and on_failure use nouns, but on_complete uses a verb. Shouldnât it be on_completion for consistency?
7.8 specifies the key in http_auth as authentication, token or credentials. It would need more details. E.g if it is a token, what is the header that carries this token? Or if it is username+password, how are they encoded in this single field?
7.9 states that the key inside ssh_auth must be username, password, or certificate. Technically what you use for ssh is not a certificate; it is a private_key

HTH,
Juan Postlbauer

cacao-comment message