On 2015-03-18 20:51, Jim Schaad wrote:
Slight rehash of the clear text signature topic....
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.
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
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
