OASIS Cyber Threat Intelligence (CTI) TC

Hi STIX WG,
 
John-Mark sent out his proposal for JSON Signing last week. I got some reports that some people did not receive his email. For next week s meeting, please review the proposal here:
 
https://www.oasis-open.org/committees/document.php?document_id=69653&wg_abbrev=cti
 
and come prepared to discuss.
 
Thanks!
 
Emily

HI Emily, I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original content. So a diff would be very helpful since the CACAO version is already being used in the wild. Reinventing the wheel is never a good idea and diminishes the value of OASIS as whole.  Bret On Mar 1, 2022, at 5:21 PM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote: Hi STIX WG,   John-Mark sent out his proposal for JSON Signing last week. I got some reports that some people did not receive his email. For next week s meeting, please review the proposal here:   https://www.oasis-open.org/committees/document.php?document_id=69653&wg_abbrev=cti   and come prepared to discuss.   Thanks!   Emily

Hi Bret,
 
Are you able to join us next week to discuss your concerns and hear the rationale for the differences?
 
Emily
 

From: Bret Jordan <bj@ctin.us>
Date: Wednesday, March 2, 2022 at 10:12 AM
To: Emily Ratliff <Emily.Ratliff@ibm.com>
Cc: "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXTERNAL] Re: [cti] STIX WG - Please review object signing proposal


 

HI Emily, I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original
content. So a diff would be very helpful since the CACAO version is already
ZjQcmQRYFpfptBannerStart













This Message Is From an External Sender





This message came from outside your organization.













ZjQcmQRYFpfptBannerEnd
HI Emily,

 


I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original content. So a diff would be very helpful since the CACAO version is already
being used in the wild. Reinventing the wheel is never a good idea and diminishes the value of OASIS as whole. 


 


Bret






On Mar 1, 2022, at 5:21 PM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote:

 


Hi STIX WG,


 


John-Mark sent out his proposal for JSON Signing last week. I got some reports that some people did not receive his email. For next week s meeting, please review the proposal here:


 


https://www.oasis-open.org/committees/document.php?document_id=69653&wg_abbrev=cti


 


and come prepared to discuss.


 


Thanks!


 


Emily




 

I m unable to attend such a meeting (due to many conflicts) but I would also ask the team provide a delta presentation or doc and help provide insight/why a delta needs to exist. I generally agree that coming up with 2 solutions for digital signing on STIX/CACAO (fundamentally JSON) makes no sense and will likely undermine the whole objective. Would it be possible for someone to provide a summary on the differences? Any insight on pro/con on what the delta does would also help. I m very familiar with the CACAO (fundamentally its just JSON) signing. So it would help me understand better if such a delta existed. Allan On Mar 2, 2022, at 8:27 AM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote: Hi Bret,   Are you able to join us next week to discuss your concerns and hear the rationale for the differences?   Emily   From: Bret Jordan < bj@ctin.us > Date: Wednesday, March 2, 2022 at 10:12 AM To: Emily Ratliff < Emily.Ratliff@ibm.com > Cc: cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject: [EXTERNAL] Re: [cti] STIX WG - Please review object signing proposal   HI Emily, I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original content. So a diff would be very helpful since the CACAO version is already ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd HI Emily,   I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original content. So a diff would be very helpful since the CACAO version is already being used in the wild. Reinventing the wheel is never a good idea and diminishes the value of OASIS as whole.    Bret On Mar 1, 2022, at 5:21 PM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote:   Hi STIX WG,   John-Mark sent out his proposal for JSON Signing last week. I got some reports that some people did not receive his email. For next week s meeting, please review the proposal here:   https://www.oasis-open.org/committees/document.php?document_id=69653&wg_abbrev=cti   and come prepared to discuss.   Thanks!   Emily  

We will try to get a list of differences out to you. A mechanical diff won t work in this case, so we will create a high level overview. Please be aware that this is coming forward as an extension object, not as an update to the specification
at this time.
 
Emily
 

From: aa tt <atcyber1000@gmail.com>
Date: Wednesday, March 2, 2022 at 10:34 AM
To: Emily Ratliff <Emily.Ratliff@ibm.com>
Cc: Bret Jordan <bj@ctin.us>, "cti@lists.oasis-open.org" <cti@lists.oasis-open.org>
Subject: [EXTERNAL] Re: [cti] STIX WG - Please review object signing proposal


 

I m unable to attend such a meeting (due to many conflicts) but I would also ask the team provide a delta presentation or doc and help provide insight/why a delta needs to exist. I
generally agree that coming up with 2 solutions for digital ZjQcmQRYFpfptBannerStart













This Message Is From an External Sender





This message came from outside your organization.













ZjQcmQRYFpfptBannerEnd
I m unable to attend such a meeting (due to many conflicts) but I would also ask the team provide a delta presentation or doc and help provide insight/why a delta needs to exist.

 


I generally agree that coming up with 2 solutions for digital signing on STIX/CACAO (fundamentally JSON) makes no sense and will likely undermine the whole objective.


 


Would it be possible for someone to provide a summary on the differences? Any insight on pro/con on what the delta does would also help.


 


I m very familiar with the CACAO (fundamentally its just JSON) signing. So it would help me understand better if such a delta existed.


 


Allan


 






On Mar 2, 2022, at 8:27 AM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote:

 


Hi Bret,
 
Are you able to join us next week to discuss your concerns and hear the rationale for the differences?
 
Emily
 

From: Bret Jordan < bj@ctin.us >
Date: Wednesday, March 2, 2022 at 10:12 AM
To: Emily Ratliff < Emily.Ratliff@ibm.com >
Cc: " cti@lists.oasis-open.org " < cti@lists.oasis-open.org >
Subject: [EXTERNAL] Re: [cti] STIX WG - Please review object signing proposal


 

HI Emily, I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original
content. So a diff would be very helpful since the CACAO version is already
ZjQcmQRYFpfptBannerStart













This Message Is From an External Sender





This message came from outside your organization.













ZjQcmQRYFpfptBannerEnd
HI Emily,

 


I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original content. So a diff would be very helpful since the CACAO version is already
being used in the wild. Reinventing the wheel is never a good idea and diminishes the value of OASIS as whole. 


 


Bret







On Mar 1, 2022, at 5:21 PM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote:

 


Hi STIX WG,


 


John-Mark sent out his proposal for JSON Signing last week. I got some reports that some people did not receive his email. For next week s meeting, please review the proposal here:


 


https://www.oasis-open.org/committees/document.php?document_id=69653&wg_abbrev=cti


 


and come prepared to discuss.


 


Thanks!


 


Emily




 





 

The extension part of it would be an extension to add a top-level property to each object called signatures with a type of list of signature and an extension to add a new object. But people have always been able to add their objects. Everything else is not an extension but rather how you do it.  The other extension that might be useful for STIX land is an extension to the identity object to enable a way to share public keys. But that part is not what I am talking about.  It appears that JMG just took what we did in CACAO and tweaked a few things and submitted it. What I want to know is what are the changes and why did he do them? The designs we have in CACAO are a based on a compromise between what we need for signing JSON data and the IETF s JOSE Working Group. Keep in mind that the design we have in CACAO is also in process to go through the IETF s system to become an RFC. So understanding what JMG has changed and why he did it, is critical. Otherwise you might very well end up with a solution for STIX that is incompatible with the rest of the industry.  Bret On Mar 2, 2022, at 9:51 AM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote: We will try to get a list of differences out to you. A mechanical diff won t work in this case, so we will create a high level overview. Please be aware that this is coming forward as an extension object, not as an update to the specification at this time.   Emily   From:   aa tt < atcyber1000@gmail.com > Date:   Wednesday, March 2, 2022 at 10:34 AM To:   Emily Ratliff < Emily.Ratliff@ibm.com > Cc:   Bret Jordan < bj@ctin.us >, cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   [EXTERNAL] Re: [cti] STIX WG - Please review object signing proposal   ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization.   ZjQcmQRYFpfptBannerEnd I m unable to attend such a meeting (due to many conflicts) but I would also ask the team provide a delta presentation or doc and help provide insight/why a delta needs to exist.   I generally agree that coming up with 2 solutions for digital signing on STIX/CACAO (fundamentally JSON) makes no sense and will likely undermine the whole objective.   Would it be possible for someone to provide a summary on the differences? Any insight on pro/con on what the delta does would also help.   I m very familiar with the CACAO (fundamentally its just JSON) signing. So it would help me understand better if such a delta existed.   Allan   On Mar 2, 2022, at 8:27 AM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote:   Hi Bret,     Are you able to join us next week to discuss your concerns and hear the rationale for the differences?   Emily   From:   Bret Jordan < bj@ctin.us > Date:   Wednesday, March 2, 2022 at 10:12 AM To:   Emily Ratliff < Emily.Ratliff@ibm.com > Cc:   cti@lists.oasis-open.org < cti@lists.oasis-open.org > Subject:   [EXTERNAL] Re: [cti] STIX WG - Please review object signing proposal   ZjQcmQRYFpfptBannerStart This Message Is From an External Sender   This message came from outside your organization.   ZjQcmQRYFpfptBannerEnd HI Emily,   I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original content. So a diff would be very helpful since the CACAO version is already being used in the wild. Reinventing the wheel is never a good idea and diminishes the value of OASIS as whole.    Bret On Mar 1, 2022, at 5:21 PM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote:   Hi STIX WG,   John-Mark sent out his proposal for JSON Signing last week. I got some reports that some people did not receive his email. For next week s meeting, please review the proposal here:   https://www.oasis-open.org/committees/document.php?document_id=69653&wg_abbrev=cti   and come prepared to discuss.   Thanks!   Emily

Hello Bret, A few weeks ago, the Signing WG started meeting, and I presented both the work I had originally done, and your work (I didn't present the JSF work), and a discussion was held and the WG decided to adopt the core of your proposal, but in reviewing it a number of issues was identified and discussed in the WG. Note, I haven't put author names, credits, and the like on the proposal, as I expect that we will clean this up before being officially published. I have made a note to include a reference that this is based upon the CACOA standard. 1. RS256 uses PKCS1 v1.5 signing, which, despite IETF recommending it, has long been recommended against by Cryptographers[1], so I decided to require a different algorithm. I expect that the required supported algorithms will be discussed further. I proposed Ed448 as it has better a margin of security, but as Jeff Mates points out, it hasn't made it to a NIST standard which means that it isn't FIPS compliant, BUT it is in a two year old draft, so likely will be adopted soon. 2. The public key is moved off the Signature Object and on to the Identity Object. This saves the need for every Signature Object from having it, when it really is per Identity. As public keys need to be verified by some out of band mechanism (as you cannot trust public keys provided by a possible attacker), it made the most sense to put it on the Identity Object. There is text on how to do verification of both the object and public key in the proposal. (In discussion this, the alternate 3. Because STIX has objects like SRO, Observed Data, Grouping, and Report objects where it is advantageous to be able to sign the entire set of related objects at once, related_to and related_version were modified to be lists such that a single object can cover all the related objects. This was primarily done to address Jeff Mates's concern wrt the Grouping and Report objects. Because of this, the WG decided to drop embedded signatures and just always use it as a separate Signature Object. 4. _ref[s] was added to properties that needed it to comply w/ the STIX policy. 5. valid_from/_until were dropped, as it is expected that the signature be valid from the creation till it is revoked. valid_from/_until can be achieved via dating the signing object and it's revocation objects appropriately. 6. The hash algorithm was changed to SHA-512, which provides better margin of security, but also better performance on modern systems. 7. Some of the complexities of message signing was dropped, (base64url encoding before signing) as it was providing additional complexity for no benefit. The reason RFC7515 did it was that in 3.1[2], they were adding additional data to be signed, which is not done in the CACOA standard. Note that there are other minor implementation details that were added due to the WG discussions and implementation work I did, but the above is the list of differences to CACOA and the reasons they were changed. [1] https://crypto.stackexchange.com/questions/3850/is-rsassa-pkcs1-v1-5-a-good-signature-scheme-for-new-systems [2] https://datatracker.ietf.org/doc/html/rfc7515#section-3.1 On Wed, Mar 2, 2022 at 8:12 AM Bret Jordan < bj@ctin.us > wrote: HI Emily, I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original content. So a diff would be very helpful since the CACAO version is already being used in the wild. Reinventing the wheel is never a good idea and diminishes the value of OASIS as whole. Bret On Mar 1, 2022, at 5:21 PM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote: Hi STIX WG, John-Mark sent out his proposal for JSON Signing last week. I got some reports that some people did not receive his email. For next week s meeting, please review the proposal here: https://www.oasis-open.org/committees/document.php?document_id=69653&wg_abbrev=cti and come prepared to discuss. Thanks! Emily

Please submit these changes to the CACAO TC so we can look at adopting some of them. It would be good to have a single signing solution that just works. The reason we added the extra internal B64 was due to feedback from the IETF.  I was okay with leaving it out. But it is currently in the Clear-Text JSON Signature proposal that is in the editors queue.  So we may want to think about that.  Bret On Mar 8, 2022, at 11:49 AM, John-Mark Gurney < jgurney@copado.com > wrote: Hello Bret, A few weeks ago, the Signing WG started meeting, and I presented both the work I had originally done, and your work (I didn't present the JSF work), and a discussion was held and the WG decided to adopt the core of your proposal, but in reviewing it a number of issues was identified and discussed in the WG. Note, I haven't put author names, credits, and the like on the proposal, as I expect that we will clean this up before being officially published.  I have made a note to include a reference that this is based upon the CACOA standard. 1. RS256 uses PKCS1 v1.5 signing, which, despite IETF recommending it, has long been recommended against by Cryptographers[1], so I decided to require a different algorithm.  I expect that the required supported algorithms will be discussed further.  I proposed Ed448 as it has better a margin of security, but as Jeff Mates points out, it hasn't made it to a NIST standard which means that it isn't FIPS compliant, BUT it is in a two year old draft, so likely will be adopted soon. 2. The public key is moved off the Signature Object and on to the Identity Object.  This saves the need for every Signature Object from having it, when it really is per Identity.  As public keys need to be verified by some out of band mechanism (as you cannot trust public keys provided by a possible attacker), it made the most sense to put it on the Identity Object.  There is text on how to do verification of both the object and public key in the proposal.  (In discussion this, the alternate 3. Because STIX has objects like SRO, Observed Data, Grouping, and Report objects where it is advantageous to be able to sign the entire set of related objects at once, related_to and related_version were modified to be lists such that a single object can cover all the related objects.  This was primarily done to address Jeff Mates's concern wrt the Grouping and Report objects.  Because of this, the WG decided to drop embedded signatures and just always use it as a separate Signature Object. 4. _ref[s] was added to properties that needed it to comply w/ the STIX policy. 5. valid_from/_until were dropped, as it is expected that the signature be valid from the creation till it is revoked.  valid_from/_until can be achieved via dating the signing object and it's revocation objects appropriately. 6. The hash algorithm was changed to SHA-512, which provides better margin of security, but also better performance on modern systems. 7. Some of the complexities of message signing was dropped, (base64url encoding before signing) as it was providing additional complexity for no benefit.  The reason RFC7515 did it was that in 3.1[2], they were adding additional data to be signed, which is not done in the CACOA standard. Note that there are other minor implementation details that were added due to the WG discussions and implementation work I did, but the above is the list of differences to CACOA and the reasons they were changed. [1]  https://crypto.stackexchange.com/questions/3850/is-rsassa-pkcs1-v1-5-a-good-signature-scheme-for-new-systems [2]  https://datatracker.ietf.org/doc/html/rfc7515#section-3.1 On Wed, Mar 2, 2022 at 8:12 AM Bret Jordan < bj@ctin.us > wrote: HI Emily, I would like to see a diff of this proposal from the proposal I submitted to this TC based on what CACAO did. From what I can tell, JMG just tweaked my original content. So a diff would be very helpful since the CACAO version is already being used in the wild. Reinventing the wheel is never a good idea and diminishes the value of OASIS as whole.  Bret On Mar 1, 2022, at 5:21 PM, Emily Ratliff < Emily.Ratliff@ibm.com > wrote: Hi STIX WG,   John-Mark sent out his proposal for JSON Signing last week. I got some reports that some people did not receive his email. For next week s meeting, please review the proposal here:   https://www.oasis-open.org/committees/document.php?document_id=69653&wg_abbrev=cti   and come prepared to discuss.   Thanks!   Emily