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 protected]] On Behalf Of Anders Rundgren
> Sent: Wednesday, March 18, 2015 12:14 PM
> To: [email protected]; Justin Richer; John Bradley; Brian
Campbell
> Cc: [email protected]
> Subject: Re: [jose] Java-based JOSE implementation
>
> On 2015-03-18 10:04, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
> > Anders,
>
> Hi Luigi,
>
> > thanks again for the pointers. Interesting reading. I like your
> > approach a lot.
>
> Thanx!
>
> > 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!?
>
> 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
>
> >
> > 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.
> >
> >
> > Am 13.03.15 um 10:01 schrieb Anders Rundgren:
> >> On 2015-03-13 09:10, Prof. Dr.-Ing. Luigi Lo Iacono wrote:
> >>> 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.
> >>
> >> 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
> >>
> >
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
