Re: [Acme] [jose] [Json] Signed JSON document / Json Content Metaheader / JSON Container

[Anders Rundgren <[e-mail]>]

On 2015-01-29 14:14, Justin Richer wrote:
> Relying on side-effects of a handful of contemporary implementations is
> dangerous at best and absolutely foolhardy at worst, especially when it
> comes to security systems. You *need* to have a formal canonicalization,
> normalization, or serialization in order for these things to work in
> practice.

You are right: JCS isn't guaranteed to run on any JSON implementation.

However, JCS doesn't rely on side-effects, it has a formal normalization
scheme (the description may be crap but there is one at least), which is
explicitly implemented in two (yes, only two) reference implementations.

Then I have with the help of available documentation and communication
with the authors, verified that two "commercial" JSON implementations
also can support "predictive serialization" which BTW is a requested
item by the general JSON community for the simple reason that humans
(unlike computers) find it somewhat odd that if you define properties
A,B,C they come out as A,C,B.

The only (known NB) "fly in the soup" is that floating-point serialization
usually requires some specific measures to work as mandated by the JCS
normalization scheme.  If this is a show-stopper and can't be corrected,
your best option is using JWS of course.  The idea was never ever to
"compete" but to "complement".  I have adjusted the JCS during the voyage
so that it nowadays reuses JOSE algorithms, curves, public key objects, and
signature blob format.  "Crypto compatible".

> Otherwise, you're betting on luck, and that's just daft.

Since I don't consider myself a gambler, I guess I have to settle on "daft" then :-)

Anders


>
>    -- Justin
>
> On 1/29/2015 12:38 AM, Anders Rundgren wrote:
>> On 2015-01-29 05:25, Fraser Tweedale wrote:
>> Hi Fraser,
>>
>>> I agree the JSON ship has sailed, but there *are* drawbacks.
>>
>>
>> The JSON ship may have sailed but it is actually more like a dinghy when
>> look closer making a turn or two fairly realistic.
>>
>> Using predictable serialization which is anything but rocket-science,
>> "canonicalization" can [often] be reduced to "stringify":
>>
>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html
>>
>> https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json
>>
>> https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs
>>
>>
>> Anders
>>
>>> On Wed, Jan 28, 2015 at 11:03:05PM -0500, Phillip Hallam-Baker wrote:
>>>> On Wed, Jan 28, 2015 at 9:57 PM, Nat Sakimura <[e-mail]>
>>>> wrote:
>>>>
>>>>> On a side note: if such a spec is to be defined here, IMHO, it
>>>>> should use
>>>>> the algorithms and probably header parameters specified by JWA,
>>>>> etc. It
>>>>> should limit the scope to payload processing and expression of the
>>>>> entire
>>>>> thing in JSON Log like format, and leave the rest to JOSE.
>>>>>
>>>>
>>>> Absolutely. In fact that is why I am not raising it in JOSE as that
>>>> just
>>>> provides the format for the main crypto attributes.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> On Thu Jan 29 2015 at 11:51:24 Manger, James <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> A signed JAR file meets some of these requirements.
>>>>>>
>>>>>> Metadata and signatures are in extra files in the ZIP archive:
>>>>>> META-INF/MANIFEST.MF, META-INF/MYKEY.SF, META-INF/MYKEY.RSA.
>>>>>>
>>>>>> Content is the other files in the archive.
>>>>>>
>>>>>> It is not JSON of course, and the signature & certs are packaged in
>>>>>> ASN.1, but it is a useful comparison. It avoids BASE64 on the
>>>>>> content; can
>>>>>> adds signatures, digests, and other metadata; can transport
>>>>>> content and
>>>>>> metadata as a regular blob (*.jar file); can sign complete code
>>>>>> distributions.
>>>>>>
>>>>>>
>>>>>>
>>>> I have used signed jar files. But Sun rather poisoned the well there by
>>>> suing Microsoft over control of Java followed up by further lawsuits
>>>> from
>>>> Oracle.
>>>>
>>>> I can't imagine anyone is going to accept Jar or anything involving
>>>> assinine.1 as a wire format for packaging. Those days are long past.
>>>> The
>>>> way you get coherence is to pick one encoding and stick to it. JSON
>>>> seems
>>>> to have been the one we picked. It has all the functionality offered
>>>> by the
>>>> alternatives and none of the drawbacks.
>>>
>>> There are ∞ valid ways to serialise a JSON object.  If a JSON object
>>> is signed over, it must be canonicalised, or signed over and
>>> transported in serialised form.  JOSE takes the latter approach
>>> (base64url-encoded serialised JSON object, inside a JSON object),
>>> while JWK thumbprint draft uses canonicalisation.  ASN.1 encodings
>>> and deterministic binary serialisations can avoid the need for these
>>> sorts of hacks.
>>>
>>> I agree the JSON ship has sailed, but there *are* drawbacks.
>>>
>>> Regards,
>>> Fraser
>>>
>>>> _______________________________________________
>>>> Acme mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>>
>>>
>>> _______________________________________________
>>> Acme mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>
>> _______________________________________________
>> jose mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/jose
>