Subject: [jose] Java-based JOSE implementation

From: "Prof. Dr.-Ing. Luigi Lo Iacono" <[email-masked]>
Date: Thu, 05 Mar 2015 13:04:59 +0100

Dear all,

we developed an own JOSE implementation in Java, mainly because we
missed the JSON serialisation in almost all of the available libs. You
can grasp it here:

http://jw-asterisk.realsoasecurity.de/

We are still doing some polishing, that is why the sources are still
lacking. Stay tuned, though, updates will follow soon...

The documentation and especially the unit tests should help in taking
the first steps.

Let us know what you think about it...

BR, Luigi.

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Wed, 11 Mar 2015 18:38:45 +0200

Thanks for sharing this.

I see that you support JSON and compact serialisation, but what is
flattened serialisation?

Thanks,

Vladimir

On 5.03.2015 14:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
> _______________________________________________
> jose mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose

-- 
Vladimir Dzhuvinov :: [email-masked]

---

From: "Prof. Dr.-Ing. Luigi Lo Iacono" <[email-masked]>
Date: Thu, 12 Mar 2015 14:18:00 +0100

Dear Vladimir,

yes, we do support the flattened serialisation, but you are right, we
did not mention it in the "feature list". This is mainly because we do
not see any benefit in having this serialisation. We followed the
discussions on it and had own discussions internally. I do not see the
point to define a distinct serialisation which is very close to an
already existing one. This increases complexity only and that's it. The
marginal amount of data reduction coming with the flattened
serialisation is ridiculous in comparison to the JSON serialisation with
only one signature. I personally like the second approach more, since it
still give you the flexibility to add further signatures along the way.
Basically, this is the way our architecture supports multiple
signatures. They are added by the signing parties one after the other.
From our perspective, this is the only realistic use case here. Having a
signing process in possession of multiple distinct private key breaks
with a lot of security principles. At least in my understanding or do I
miss something here!?

In our architectural approach a JwsDocument is constructed by a JwsMaker
(either from scratch or by parsing an existing one):

JwsDocument jws = JwsMaker.generate...

Having such an object, getting a particular serialisation is just a
matter of calling the respective method:

- Compact: jws.getCompactSerialisation();
- Compact DETACHED: jws.getCompactDetachedSerialisation();
- JSON: jws.getJsonSerialisation();
- JSON PRETTYPRINTED: jws.getJsonSerialisation(true);
- JSON DETACHED: jws.getJsonDetachedSerialisation();
- JSON PRETTYPRINTED & DETACHED: jws.getJsonDetachedSerialisation(true);
- JSON Flattened: jws.getJsonFlattenedSerialisation();
- JSON Flattened PRITTYPRINTED: jws.getJsonFlattenedSerialisation(true);
- JSON Flattened DETACHED: jws.getJsonFlattenedDetachedSerialisation();
- JSON Flattened PRITTYPRINTED & DETACHED:
  jws.getJsonFlattenedDetachedSerialisation(true)

Hope that helps!?

Do not hesitate to ask further questions. We are happy to help and
further feedback is welcome!

BR, Luigi.

---

From: Justin Richer <[email-masked]>
Date: Thu, 12 Mar 2015 10:08:09 -0400

Just to add some perspective, if by “flattened” serialization, you mean the compact serializations of JWS (header.payload.signature) and JWE (header.stuff.stuff.stuff.stuff I forgot the order), then there are huge advantages to these, and they’re the only ones that I personally use.

The simplicity gained in processing the compact forms, both in terms of generating and consuming. With the compact forms, you get something that can be dropped on the wire into an HTTP header, form parameter, query parameter, a string in just about any language, all without any quoting or further processing. Plus, to get back to the crypto calculations, you use the literal strings sent across the wire, which is a really nice feature.

I’ve personally yet to have a use case that required the multiple signatures or other features of the JSON serialized flavor, nor have I seen much uptake of it in the wild compared to the compact forms.

 — Justin

> On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono <[email-masked]> wrote:
> 
> Dear Vladimir,
>

---

From: Brian Campbell <[email-masked]>
Date: Thu, 12 Mar 2015 08:49:39 -0600

flattened is not the same as compact FWIW

compact ->
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.1

flattened ->
https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.2.2

On Thu, Mar 12, 2015 at 8:08 AM, Justin Richer <[email-masked]> wrote:

> Just to add some perspective, if by “flattened” serialization, you mean
> the compact serializations of JWS (header.payload.signature) and JWE
> (header.stuff.stuff.stuff.stuff I forgot the order), then there are huge
> advantages to these, and they’re the only ones that I personally use.
>
> The simplicity gained in processing the compact forms, both in terms of
> generating and consuming. With the compact forms, you get something that
> can be dropped on the wire into an HTTP header, form parameter, query
> parameter, a string in just about any language, all without any quoting or
> further processing. Plus, to get back to the crypto calculations, you use
> the literal strings sent across the wire, which is a really nice feature.
>
> I’ve personally yet to have a use case that required the multiple
> signatures or other features of the JSON serialized flavor, nor have I seen
> much uptake of it in the wild compared to the compact forms.
>
>  — Justin
>

---

From: John Bradley <[email-masked]>
Date: Thu, 12 Mar 2015 12:38:30 -0300

Yes flattened is a special case of the JSON serialization that has only one signature.

I don't know that there is a huge benefit to it over the regular JSON serialization that supports multiple signatures.

Some people really wanted it at the time.  

Supporting the general JSON serialization would be a higher priority for me.  In most cases I have seen, as Justin points out people wanting a single signature go with compact.

John B.

> On Mar 12, 2015, at 11:49 AM, Brian Campbell <[email-masked]> wrote:
> 
> compact -> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.1 <https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.1>
> 
> flattened -> https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.2.2 <https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#section-7.2.2>
> 
> On Thu, Mar 12, 2015 at 8:08 AM, Justin Richer <[email-masked] <mailto:[email-masked]>> wrote:
> > On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > Dear Vladimir,
> >
> >>> http://jw-asterisk.realsoasecurity.de/ <http://jw-asterisk.realsoasecurity.de/>
> >>>
> >>> [email-masked] <mailto:[email-masked]>
> >>> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> >>
> >> --
> >> Vladimir Dzhuvinov :: [email-masked] <mailto:[email-masked]>
> >>
> >>
> >>
> >> [email-masked] <mailto:[email-masked]>
> >> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> >>
> >
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jose <https://www.ietf.org/mailman/listinfo/jose>
> 
>

---

From: Justin Richer <[email-masked]>
Date: Thu, 12 Mar 2015 13:20:02 -0400

My bad, I totally missed that.

  -- Justin

On 3/12/2015 11:38 AM, John Bradley wrote:
> I don't know that there is a huge benefit to it over the regular JSON 
> serialization that supports multiple signatures.
>
> Supporting the general JSON serialization would be a higher priority 
> for me.  In most cases I have seen, as Justin points out people 
> wanting a single signature go with compact.
>
> John B.
>
>
>> On Mar 12, 2015, at 11:49 AM, Brian Campbell 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>     Just to add some perspective, if by “flattened” serialization,
>>     you mean the compact serializations of JWS
>>     (header.payload.signature) and JWE
>>     (header.stuff.stuff.stuff.stuff I forgot the order), then there
>>     are huge advantages to these, and they’re the only ones that I
>>     personally use.
>>
>>     The simplicity gained in processing the compact forms, both in
>>     terms of generating and consuming. With the compact forms, you
>>     get something that can be dropped on the wire into an HTTP
>>     header, form parameter, query parameter, a string in just about
>>     any language, all without any quoting or further processing.
>>     Plus, to get back to the crypto calculations, you use the literal
>>     strings sent across the wire, which is a really nice feature.
>>
>>     signatures or other features of the JSON serialized flavor, nor
>>     have I seen much uptake of it in the wild compared to the compact
>>     forms.
>>
>>      — Justin
>>
>>     > On Mar 12, 2015, at 9:18 AM, Prof. Dr.-Ing. Luigi Lo Iacono
>>     <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     >
>>     > Dear Vladimir,
>>     >
>>     > - JSON Flattened DETACHED:
>>     jws.getJsonFlattenedDetachedSerialisation();
>>     <mailto:[email-masked]>
>>     >>
>>     >>
>>     >>

---

From: "Prof. Dr.-Ing. Luigi Lo Iacono" <[email-masked]>
Date: Fri, 13 Mar 2015 09:10:38 +0100

Seems that there is some uncertainty about this "special" serialisation.
I would actually vote for replacing the flatened JSON serialisation with
one, that provides a real benefit. Taken up on a discussion I read
earlier on the list, wouldn't it be more sensible to have a "readable"
JSON serialisation (i.e., leaving the signed payload "human readbale")!?
This would of course require some form of normalisation/canonicalisaton
as used e.g. in XML Security. Still, this would be something valuable to
have and a real distinguishing point in comparison to the other
serialisations.

If people think that this is worth a discussion, then maybe we should
kick-off an explicit thread on it.

Another point I would like to raise is to have an additional mandatory
header entry specifying the JWS/JWE version used. As the standards will
evolve over time, it would be good to know, with what version of the
JWS/JWE standards a given object have been protected.

BR, Luigi.

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 13 Mar 2015 10:01:44 +0100

> kick-off an explicit thread on it.

Human-readable JSON signatures is a reality although not as an IETF standard.

Since nobody is interested in bringing in the complexity of XML DSig normalization,
there seems to be some possible routes ahead.

Phillip Hallam-Baker have proposed a scheme based on separating the payload and
the signature where the payload is used "verbatim" reducing normalization and
canonicalization to exactly ZERO:
http://www.ietf.org/mail-archive/web/acme/current/msg00224.html

I have FWIW designed and also implemented a scheme which is based on JSON's
intrinsic normalization (white-space removal + character escapes) but adds the
constraint that a verifier honors the property order of the serialized object:
https://openkeystore.googlecode.com/svn/resources/trunk/docs/jcs.html
Since a JSON parser-core typically is less than 500 lines of fairly simple code
I don't see that upgrading existing parsers with an ordered dictionary would be
a show-stopper.   It surely didn't stop me at least :-)
Runnable Java+JavaScript implementation: https://mobilepki.org/jcs
Partial Python implementation: https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py
Minimal .NET implementation: https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs

Cheers,
Anders

---

From: Vladimir Dzhuvinov <[email-masked]>
Date: Fri, 13 Mar 2015 22:09:25 +0200

> http://www.ietf.org/mail-archive/web/acme/current/msg00224.html

Sounds appealing :)

---

From: "Prof. Dr.-Ing. Luigi Lo Iacono" <[email-masked]>
Date: Fri, 13 Mar 2015 21:38:05 +0100

Thanks a lot for the pointer, Anders. Will check them soon!

Cheers, Luigi.

Am 13.03.15 um 10:01 schrieb Anders Rundgren:
> Partial Python implementation:
> https://code.google.com/p/openkeystore/source/browse/python/trunk/src/org/webpki/json/JCSValidator.py
> 
> Minimal .NET implementation:
> https://code.google.com/p/openkeystore/source/browse/resources/trunk/docs/JCSDemo.cs
> 
> 
> Cheers,
> Anders
>

---

From: "Prof. Dr.-Ing. Luigi Lo Iacono" <[email-masked]>
Date: Wed, 18 Mar 2015 10:04:16 +0100

Anders,

thanks again for the pointers. Interesting reading. I like your approach
a lot. While crawling though the web I stumbled upon this fall asleep draft:

https://tools.ietf.org/html/draft-staykov-hu-json-canonical-form-00

Have you been aware of this one!?

Anyway, I still think that JOSE requires a readable JSON serialisation.
I am not really familiar with the IETF procedures and seing that no one
else reacted on the suggestion so far, I guess that raising such
thoughts in the mailing list is not enough. What needs to be done in
order to have a discussion on replacing the flatened JSON serialisation
by a readbale JSON serialisation?

Thanks and BR, Luigi.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 18 Mar 2015 20:13:45 +0100

> Anders,

Hi Luigi,

> a lot.

Thanx!

> While crawling though the web I stumbled upon this fall asleep draft:
>

Yes, I think so.  As you can see "there are many roads to Rome" :-)

One school says: "You must canonicalize data in a similar way as for XML",
while another school claim that "Canonicalization is lunacy!".

Full canonicalization like in the I-D above forces you to use a stand-alone
canonicalizer which is like building a parallel single-purpose JSON parser.

Using text "as is" makes canonicalization a zero issue but I felt that it would
be cooler using a standard (or moderately updated) JSON parser for creating
and validating signatures.  This design also enables security properties like
keys to be handled exactly as any other properties.

When I found (on stackoverflow) that many developers also feel that parsers that
read properties A, B, C but outputs them as A, C, B as inferior, the decision to
maintain strict property input/creation order became obvious.

I'm currently not considering an IETF process, it seems like a better idea establishing
this scheme through open source and actual usage :-)

JCS was designed for supporting complex signature systems like:
https://openkeystore.googlecode.com/svn/wcpp-payment-demo/trunk/docs/messages.html#UserSignedAuthorization

Regards,
Anders

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 18 Mar 2015 12:51:32 -0700

What do you consider to be clear text signatures?

Would you consider carrying a payload that is a JSON string which is not
base64-ed to be plain text?

I.e.
{"signature":"abc...def", "payload":"{'tag1':'value1','tag2':'value2'}",
"headers":"...."}

The item to be signed is not at the top level, but it is readable by humans.
Jim

> -----Original Message-----
> From: jose [mailto:[email-masked]] On Behalf Of Anders Rundgren
> Sent: Wednesday, March 18, 2015 12:14 PM
> To: [email-masked]; Justin Richer; John Bradley; Brian
Campbell
> Cc: [email-masked]
> Subject: Re: [jose] Java-based JOSE implementation
> 
> > thanks again for the pointers. Interesting reading. I like your
> > approach a lot.
> 
> Thanx!
> 
> Using text "as is" makes canonicalization a zero issue but I felt that it
would be
> cooler using a standard (or moderately updated) JSON parser for creating
and
> validating signatures.  This design also enables security properties like
keys to
> be handled exactly as any other properties.
> 
> When I found (on stackoverflow) that many developers also feel that
parsers
> that read properties A, B, C but outputs them as A, C, B as inferior, the
decision
> to maintain strict property input/creation order became obvious.
> 
> I'm currently not considering an IETF process, it seems like a better idea
> establishing this scheme through open source and actual usage :-)
> 
> https://openkeystore.googlecode.com/svn/wcpp-payment-
> demo/trunk/docs/messages.html#UserSignedAuthorization
> 
> Regards,
> Anders
> 
> >
> > I am not really familiar with the IETF procedures and seing that no
> > one else reacted on the suggestion so far, I guess that raising such
> > order to have a discussion on replacing the flatened JSON
> > serialisation by a readbale JSON serialisation?
> >
> > Thanks and BR, Luigi.
> >
> >
> >>> I would actually vote for replacing the flatened JSON serialisation
> >>> with one, that provides a real benefit. Taken up on a discussion I
> >>> read earlier on the list, wouldn't it be more sensible to have a
"readable"
> >>> This would of course require some form of
> >>> normalisation/canonicalisaton as used e.g. in XML Security. Still,
> >>> this would be something valuable to have and a real distinguishing
> >>> point in comparison to the other serialisations.
> >>>
> >>> If people think that this is worth a discussion, then maybe we
> >>> should kick-off an explicit thread on it.
> >>
> >> Since nobody is interested in bringing in the complexity of XML DSig
> >> normalization, there seems to be some possible routes ahead.
> >>
> >> Phillip Hallam-Baker have proposed a scheme based on separating the
> >> payload and the signature where the payload is used "verbatim"
> >> reducing normalization and canonicalization to exactly ZERO:
> >> I have FWIW designed and also implemented a scheme which is based on
> >> JSON's intrinsic normalization (white-space removal + character
> >> escapes) but adds the constraint that a verifier honors the property
> >> order of the serialized
> >> object:
> >> Since a JSON parser-core typically is less than 500 lines of fairly
> >> simple code I don't see that upgrading existing parsers with an
> >> ordered dictionary would be

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 18 Mar 2015 22:55:54 +0100

> The item to be signed is not at the top level, but it is readable by humans.

That would of course qualify as a clear text signature.

JCS was inspired by enveloped XML signatures which I found "pretty" since they
just introduces an extra element in an existing XML object (i.e. context is
unchanged), although JCS is much, much more primitive.

Anders

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 19 Mar 2015 17:31:53 +0100

Slight rehash of the clear text signature topic....

> The item to be signed is not at the top level, but it is readable by humans.
Yes, this is indeed a human readable signature.

Below are three examples which shows the primary motive why JCS embeds signatures in JSON
objects rather than as in your example/proposal embedding JSON objects in signature objects.

Unsigned JSON Object

{
   "@context": "https://json.example.com/protocol"
   "@qualifier": "Init",
   "property-1": ...
   "property-2": ...
      ...
   "property-n": ...
}

Optionally signed JSON Object

{
   "@context": "https://json.example.com/protocol"
   "@qualifier": "Request",
   "property-1": ...
   "property-2": ...
      ...
   "property-n": ...
"signature":
     {
       ...
     }
}

Signed JSON Object

{
   "@context": "https://json.example.com/protocol"
   "@qualifier": "Response",
   "property-1": ...
   "property-2": ...
      ...
   "property-n": ...
   "signature":
     {
       ...
     }
}

That is, JCS maintains the message structure which makes message validation and documentation nicer.

https://openkeystore.googlecode.com/svn/resources/trunk/docs/keygen2.html#KeyCreationRequest

Anders