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:[email protected]] On Behalf Of Anders Rundgren
Sent: Saturday, December 20, 2014 11:16 AM
To: Richard Barnes
Cc: [email protected]
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
<[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/__listinfo/jose
<https://www.ietf.org/mailman/listinfo/jose>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
