cti-stix message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [cti-stix] Digital Signatures
- From: "Jason Keirstead" <Jason.Keirstead@ca.ibm.com>
- To: Bret Jordan <Bret_Jordan@symantec.com>
- Date: Sat, 13 Oct 2018 18:19:47 -0300
RE #2, from my research (ref. https://tools.ietf.org/html/rfc7493#section-2.2) I don't think affects us.
"I-JSON
messages SHOULD NOT include numbers that express greater magnitude
or
precision than an IEEE 754 double precision number provides, for
example, 1E400 or 3.141592653589793238462643383279.
An I-JSON sender cannot expect a receiver to treat an integer whose
absolute value is greater than 9007199254740991 (i.e., that is
outside the range [-(2**53)+1, (2**53)-1]) as an exact value.
For applications that require the exact interchange of numbers
with
greater magnitude or precision, it is RECOMMENDED to encode them
in
JSON string values."
We have nothing that requires
volume or precision like that that I am aware of. None of the numbers
we currently use in STIX would realistically require 64 bit precision.
However in general IMHO any STIX
signature should not have anything to do with JSON. We want to be signing
content, not a specific serialization thereof. If the way STIX defines
signing requires JSON serialization, then we can never have any other representation
of STIX used or transmitted.
I think it might make a lot more sense
to define a way to generate a signature having nothing to do with JSON.
-
Jason Keirstead
Lead Architect - IBM.Security
www.ibm.com/security
"Things may come to those who wait, but only the things left by those
who hustle." - Unknown
From:
Bret Jordan <Bret_Jordan@symantec.com>
To:
"cti-stix@lists.oasis-open.org"
<cti-stix@lists.oasis-open.org>
Date:
10/12/2018 06:01 PM
Subject:
[cti-stix] Digital
Signatures
Sent by:
<cti-stix@lists.oasis-open.org>
I have been doing some research and work
on figuring out how to make digital signatures a reality for STIX. On
the surface this seems like it should be really easy. But it is not
until you peel back the layers that you begin to see that there is a set
of problems (which I guess have been well known for years). I have
reached out to the working group at the IETF that is responsible for JSON
signatures and JSON encryption. You can follow that discussion on
the jose@ietf.org mailing list.
Problems:
(1) There is no defined canonical serialization
for JSON. This means the following examples are all possible depending
on the JSON library and programming language you use.
{ "type" : "indicator",
"id" : "indicator--1234"}
{"type":"indicator","id":"indicator--1234"}
{"id":"indicator--1234","type":"indicator"}
{
"id":"indicator--1234",
"type":"indicator"
}
{
"id":"indicator--1234",
"type":"indicator"
}etc etc etc.
This means there is no way for a consumer
to unmarshal the data and then verify the signature. The only thing
they can do is verify the byte stream on receipt, which is what JOSE RFC
7515 defines. But if that organization (ISAC, ISAO, Vendor) decides to
re-share the content back out, there is no guarantee that the STIX they
send will match the attached signature (unless they keep a copy of the
original byte stream and send it instead).
We can solve some of this by defining a
canonical representation for STIX. Meaning, all white space is removed,
all CR / CRLF are removed, all keys are sorted in some UTF8 friendly way.
There are several personal drafts and solutions that have tried to
address this [1], [2], [3].
(2) The JSON number type that we use in
some parts of STIX is not uniformly deserialized. Meaning, some architectures
/ programming languages will deserialize it to a float, some to a double
float, some to who-knows-what. This means that even if you define a canonical
representation the signatures may still fail since one library may treat
the number data differently.
We could solve this by making all STIX
number types quoted strings. This is apparently the best practice in all
IETF standards that use and define JSON. This has been a known problem
for many years. So I would suggest that we consider changing our
spec to say that all numbers, integers, floats, etc in STIX MUST be treated
as strings, aka quoted strings in JSON.
Another option is to force all numbers
to be coerced into an IEEE 754 double precision number and be serialized
according to ECMAScript V6+ rules. However, there is no library support
for this.
3) There are a few other problems as well.
One is that "\u0020" and " " both represents a space
character. But once again I think these can all be addressed.
Ultimately I think this is a solvable problem,
but I do not feel that it should be solved completely in our TC. I
think we should make our spec work better with JSON by changing our numbers
to strings. Then those that are interested in ensuring that STIX content
can be signed and maybe even encrypted, should help me work with the JOSE
Working Group at the IETF to figure out a standard for canonical JSON and
see about getting RFC 7515 updated to support this.
References:
- https://tools.ietf.org/html/draft-rundgren-json-canonicalization-scheme-01
- https://gibson042.github.io/canonicaljson-spec/
- https://cyberphone.github.io/doc/security/jcs.html#Reference.JEF
Bret
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]