I threw together a very basic and simplified example of the concept i explained below
Can see the usage of the signed object. being part of the distribution, but its not ârequiredâ that the JSON and the encoded object match, because all you need to really care about is the signed objectâs payload, and you ability to validate that payload (see the headers example screenshot in the link above).
Feedback always welcome!!
Enjoy the weekend! Steve
@Jason thanks for that link. Good reading!
@Bret: Agreed! So from implementation my view was (of course
not locked down, as i have yet to write the code ! ;) ): To
implement the âreaderâ of the json as a way to navigate the data,
not necessarily a way to recreate the signed
representation..Â
So this is where the âstrategyâ comes into play. But as the
most simple of implementations, it would be to maintain a list of
trusted sources. This is not ideal nor standardized; But I
will leave the standards up to the people working on the white
papers!
So a âx_signatureâ property would likely contain who issued it, and
that content would be cross-ref with the consumerâs list of
âtrusted sourcesâ, and the specific coded strategy does the
validation. This can obviously be greatly improved: but my
goal is object at rest validation and not just during initial
receipt. The object should be able to be signed and passed
around, stored (, etc. Like a signature on a digital
document, or a JWT key. If you want to get extra fancy you
could possibly get into a array of signatures as older signatures
expire and you want to revalidate. But thats a whole other
problem space for future work.
If worse case occurs and there is risk that consumerâs cannot
re-create the canonical representation (for the number type issue
or whatever issue), then I believe I would store/keep the canonical
representation / the original json string representation that was
submitted, and keep it with the processed/in-mem object: meaning
that there would be the âprocessedâ object and the âraw objectâ
which is the original raw string received. This starts to
double storage needs; Â Â
This storage is only needed if you are re-transmitting the data, or
you are a consumer who needs to re-validate the upstream data
sometime in the future. If you are a general consumer and not
a re-distributor (you may distribute but it is only your own
content), then generally you only need to validate your STIX data
on receipt, and mark in your CTI system that it is valid.
As a standard gets created over time, raw representations can be
removed, and the rest seemingly remains the same.
The problem with that is how to you guarantee that
someone can recreate the hash to verify it? What do you use
for the canonical representation? What do you do with the
JSON number type if it is an int or a float, or a double float
?Â
On the surface this seems like it should be
super easy to solve, but there are some complexities with it.
Â
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."
Thanks for the quick feedback.
So given lack of standards, in the mean time I am going to
implement a custom property that implements a signing/validating
strategy pattern and for a first pattern just use something similar
to how JWT tokens sign their content for public key
validation.
Specifically so that someone can have a signed content and
verify that content with a ~public PKI listing.
âFor meâ at the moment, the specific signing standard is
not overly important as long as a consumer knows where to find the
upstream public signatures for downstream/consumer
validation.
something like âx_signature: â â, which can be easily
implemented with helpers in a libraryâs implementation.
Would you say that a standard is ânearâ? or 2020+ type of
thing?
Stephen,
Thanks for the question. Yes,
this is a known issue that the TC needs to address. One of
the major problems is that IETF JOSE working group has yet to
define a canonical representation of JSON data. This makes signing
the STIX objects difficult, as there is not yet any RFC for doing
what we need. We have talked about a few different options internal
to our CTI TC for how this could be done, but the solution would be
limited to STIX and TAXII, rather than an industry wide
standard.Â
To this end I have been bringing up
this issue in the IETF JOSE WG mailing list, and trying to get a
work item started during the Prague IETF meeting to address
this. If you are interested in signed JSON content, either
for STIX or something else, I would highly encourage you to join
the discussion atÂjose@ietf.org. There seems to be a few people on
the JOSE mailing list that, like me, want to see this work get
done. However, as you may know, all standards work (even here
in OASIS) is consensus based. Meaning, the more people that want
something done, the more likely it will get
done.Â
Â
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."
Hey all
I am looking for some experiences working with âsigningâ objects
(SDOs, SROs, Data Marking Definitions, etc). I am looking at
using a custom property, but wanted to get some feedback if others
are doing this?
use case: As bundles are passed around in STIX, There are different
actors/identities that are consuming this information. Has
there been thought on a common standard for signing bundles and
each item within a bundle (in the case where a bundleâs objects
were provided by different actors, but was bundled by someone
else).
Thanks!
Steve
Stephen
Russett
@stephenrussett
|