Re: [jose] JOSE.Next - Clear-Text Signatures?

[Anders Rundgren <[e-mail]>]

Hi Guys,
Happy New year!
Should I interpret the silence as "no interest"?

Since it has been proved beyond doubt that there's are no unsolved/unsolvable technical
issues using the principles of JCS, communities working with "business messaging" will
most likely (due to the absence of a standard) all develop their own take of clear-text
signatures.  This is perfectly OK but reduces the value of the great JOSE work which is
the rationale for considering a clear-text alternative as a JOSE.Next task.

It's easy to get some feeling for JCS; you can test it on-line at:
https://mobilepki.org/jcs

Recently I updated JCS to use the same ECDSA signature encoding as JOSE/WebCrypto/XML DSig
rather than the encoding used by OpenSSL, Oracle JCE and CMS.  Standards? The more the better :-)

A subset (only public keys are supported) but normalization-wise 100% JCS-compliant Python
implementation shows how painfully simple JCS is:
https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json

There's no benefit with sorting properties since predictable serialization order is anyway
something lots of people have requested.  Humans <> Computers.

Cheers,
Anders

On 2014-12-21 06:21, Anders Rundgren wrote:
> On 2014-12-20 23:55, Jim Schaad wrote:
>>
>>
>>> -----Original Message-----
>>> From: jose [mailto:[e-mail]] On Behalf Of Anders Rundgren
>>> Sent: Saturday, December 20, 2014 11:16 AM
>>> To: Richard Barnes
>>> Cc: [e-mail]
>>> Subject: Re: [jose] JOSE.Next - Clear-Text Signatures?
>>>
>>> On 2014-12-20 18:33, Richard Barnes wrote:
>>>    > Clear-text signing requires c14n or some other representation-fixing.
>>>    > If you have proposals for at least one of those, this may be viable.
>>>
>>> As mentioned in the "prospectus" there are multiple ways ahead.  Some kind
>>> of canonicalization scheme is undoubtedly one of them.
>>>
>>>    > Relying on implementation quirks is not OK.
>>>
>>> My specific proposal does not build on implementation quirks but on an
>>> explicitly required serialization method which doesn't "scramble" data.
>>> This may or may not be supported by the target JSON parser.  Since JSON
>>> parsers usually are pretty simple I don't see this as a insurmountable
>> obstacle:
>>> https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html#Int
>>> eroperability
>>
>> Based on a quick scan of this, all we need to do is to define a new parser,
>> a new data format (need to keep both the original text and the value for
>> some types) and a new serializer and we are home free.
>>
>> I don't think that is a viable proposal.
>
> The floating point issues may be a show-stopper from a standardization
> point of view but it has few practical implications since the target for
> JCS is security-protocols (its "cradle") and payments which rarely depends
> on floating point data.  99% "coverage" seems good enough :-)
>
> There's no need for new parser, a minute update of existing such may be required in some cases.
> A quick scan of programmer hangouts like "stackoverflow" shows that quite a few
> people ask for JSON parsers that honor property order regardless of the fact that
> JSON doesn't in any way require that so such an update have uses outside of signatures.
>
> As an exercise you could visualize the following counter-signed message in JWS:
> https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html#UserAuthorizesTransaction
> Well, to make it easier, here it is:
>
>       {
>         "payload":"<base64>",
>         "protected":"<base64>",
>         "header":<base64>,
>         "signature":"<base64>"
>       }
>
> Now consider how you would communicate that to a payment community who
> to date have been using XML.
>
> Somewhat related: Although Google's U2F is incompatible with "gold standards"
> like ISO 7816 and PKCS #11/NSS, it has gotten the biggest interest I have
> ever seen in this space.  The "traditional" software industry bogged down by
> legacy designs and ideas would never be able to pull off such a stunt.
>
> Anders
> "almost" standards-compliant
>
>> Jim
>>
>>
>>>
>>> Targeting the lowest common denominator is the governing standards
>>> strategy.
>>> IMO, this [often] thwarts innovation and creates lousy systems so I don't
>> care
>>> :-)
>>>
>>> Cheers,
>>> Anders
>>>
>>>
>>>>
>>>> --Richard
>>>>
>>>> On Sat, Dec 20, 2014 at 12:52 AM, Anders Rundgren
>>> <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>       Hi List,
>>>>       In theory JOSE is done since we have key containers, as well as
>> signature
>>> and encryption constructs.
>>>>
>>>>       In reality it is not because the topic I raised a long time ago
>> namely the
>>> ability to sign clear-text
>>>>       JSON data in a similar fashion like in XML DSig simply isn't going
>> away:  No,
>>> it is not only yours
>>>>       truly who is into JSON clear-text signing although it seems that
>> everybody
>>> is dealing with this
>>>>       issue in quite different ways.  This may actually only be good since
>> then
>>> there are some
>>>>       real-world (tested) schemes to select from.  AFAICT they all have
>> (even
>>> including my own take
>>>>       on the subject...), clearly identifiable pros and cons.
>>>>
>>>>       The rationale is simple: Documentation, Validation, Development and
>>> Debugging of
>>>>       complex JSON messages becomes easier if the content is provided in
>>> clear.
>>>>
>>>>       There could be justification for IETF taking on such a work-item.
>>>>
>>>>       Anders
>>>>
>>>>       _________________________________________________
>>>>       jose mailing list
>>>>       [e-mail] <mailto:[e-mail]>
>>>>       https://www.ietf.org/mailman/__listinfo/jose
>>>> <https://www.ietf.org/mailman/listinfo/jose>
>>>>
>>>
>>> _______________________________________________
>>> jose mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/jose
>>
>