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

From: Anders Rundgren <[email-masked]>
Date: Sat, 20 Dec 2014 06:52:09 +0100

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

---

From: Richard Barnes <[email-masked]>
Date: Sat, 20 Dec 2014 12:33:46 -0500

Clear-text signing requires c14n or some other representation-fixing.  If
you have proposals for at least one of those, this may be viable.  Relying
on implementation quirks is not OK.

--Richard

On Sat, Dec 20, 2014 at 12:52 AM, Anders Rundgren <
[email-masked]> wrote:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>

---

From: Anders Rundgren <[email-masked]>
Date: Sat, 20 Dec 2014 20:16:15 +0100

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#Interoperability

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 <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi List,
>     _________________________________________________
>     jose mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
>

---

From: "Jim Schaad" <[email-masked]>
Date: Sat, 20 Dec 2014 14:55:10 -0800

> -----Original Message-----
> From: jose [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Saturday, December 20, 2014 11:16 AM
> To: Richard Barnes
> Cc: [email-masked]
> Subject: Re: [jose] JOSE.Next - Clear-Text Signatures?
> 
> As mentioned in the "prospectus" there are multiple ways ahead.  Some kind
> of canonicalization scheme is undoubtedly one of them.
> 

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.

Jim

> 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
> <[email-masked]
> <mailto:[email-masked]>> 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
> >     https://www.ietf.org/mailman/__listinfo/jose
> > <https://www.ietf.org/mailman/listinfo/jose>
> >
>

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 21 Dec 2014 06:21:44 +0100

> 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

---

From: Anders Rundgren <[email-masked]>
Date: Sun, 21 Dec 2014 07:41:45 +0100

In my case I got the desired functionality by replacing HashMap with:
http://docs.oracle.com/javase/7/docs/api/java/util/LinkedHashMap.html

"This implementation spares its clients from the unspecified, generally chaotic ordering provided by HashMap"

"This technique is particularly useful if a module takes a map on input, copies it, and later returns
  results whose order is determined by that of the copy. (Clients generally appreciate having things
  returned in the same order they were presented.)"

Anders