OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cacao-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

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.

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

4) For 2.6, how should we fix this?

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?Â

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

Â

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]