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.