[security-dev] Implementing JSON Security

Sun Aug 5 23:22:35 EDT 2012

So basically, everybody is doing their own thing...So...why don't we do 
our own thing too and lead instead of follow whatever is currently 
blowing in the wind?

On 8/3/12 4:40 PM, Anil Saldhana wrote:
> Bill, I asked Axel Nennker (T-Mobile Germany) who is working on JOSE for
> many months now.
> Here is his reply:
>
> ==================
> I think S/MIME is good enough if your communication partner knows how to
> handle it and you are in the position to choose. And S/MIME is more
> mature than JW*. I am sure S/MIME implementation had a bunch of
> interoperability issues in the first year(s).
>
> The problem is that you don't always have a choice as a developer. If
> you are programming the client for a specific API like OpenID Connect
> than you have to implement whatever the server understands.
> Today everybody is stuffing parameters into JSON objects. If you want
> end to end security it is easy to put all your request parameters into a
> json structure, sign/encrypt it for the intended recipient and send it out.
> It is true that this tends to reinvent the wheel for some use cases and
> maybe the new security is all but theater because the eager programmers
> in that hot startup are inventing an insecure protocol although they are
> using "secure" building blocks. Some will reinvent SSL and get it wrong.
> So the answer is not easy.
> I think application servers/frameworks should support jsoncrypto but
> some education of developers is needed. But this is true with all
> crypto. You can use it wrongly.
>
> There was a long discussion on the JOSE mailing list about a
> vulnerability in a library that used my code. The same questions arose.
> My code provides building blocks but they were put together in such a
> way that an attacker could launch a Bleichenbacher attack against the
> server. There was no way for my code to prevent or detect this attack.
>
> Coming back to the S/MIME topic. Currently my implementation just allows
> to encrypt and integrity protect one chunk of data. If you have a big
> plaintext and want to send it encrypted/signed in chunks then there is
> currently no method to do this in jsoncrypto. You have to protect each
> chunk individually. If I finish the Cipher API then this would
> automatically work. So in that big-file case you might want to use
> S/MIME (currently).
> ======================================
>
>
> On 08/03/2012 02:26 PM, Anil Saldhana wrote:
>> Bill, I agree on the S/Mime part.
>>
>> But the challenge is we cannot control what the clients use. If they use
>> JSON Web Encryption and JSON Web Signatures as their payload interacting
>> with a JAX-RS implementation, then you will fall short.
>>
>> JWE and JWS are being standardized at IETF along with OAuth2. JSON Web
>> Token (JWT) is one of the prominent tokens in use with OAuth2. Of course
>> Eran complained loudly about JWT.
>>
>> On 08/03/2012 01:54 PM, Bill Burke wrote:
>>> Also multipart/signed or a combination of multipart/signed and encrypted
>>> is supported as well.  I've tried it out in python as well.  So, JSON is
>>> not required as a payload and you can sign or encrypt basically anything
>>> you want.
>>>
>>> On 8/3/12 2:50 PM, Bill Burke wrote:
>>>> Looks like you're encrypting the whole document?  Why not use S/MIME
>>>> multipart/encrypted?
>>>>
>>>> http://docs.jboss.org/resteasy/docs/2.3.4.Final/userguide/html/ch38.html
>>>>
>>>> On 8/3/12 2:10 PM, Anil Saldhana wrote:
>>>>> Last few hours, I prototyped the outgoing json payload encryption that
>>>>> is described here:
>>>>> https://docs.jboss.org/author/display/SECURITY/Securing+JAX-RS+Payload
>>>>>
>>>>> On 08/02/2012 11:28 AM, Bill Burke wrote:
>>>>>> So why are you wasting your time with this?
>>>>>>
>>>>>> On 8/2/12 12:26 PM, Anil Saldhana wrote:
>>>>>>> If Jackson needs to implement JSON security, they will have to code it.
>>>>>>> The pragmatic thing for Jackson would be to just incorporate this teeny
>>>>>>> library via maven dependency.
>>>>>>>
>>>>>>> On 08/02/2012 11:24 AM, Bill Burke wrote:
>>>>>>>> FYI, again, unless this works with Jackson, the de facto JSON parser,
>>>>>>>> you're probably not going to have many people taking advantage of this
>>>>>>>> work...
>>>>>>>>
>>>>>>>> On 8/2/12 12:20 PM, Anil Saldhana wrote:
>>>>>>>>> The German Researcher Axel Nennker created a separate project
>>>>>>>>> http://code.google.com/p/jsoncrypto/. He has given me commit rights so I
>>>>>>>>> can mavenize his project.
>>>>>>>>>
>>>>>>>>> On 07/31/2012 10:15 AM, Anil Saldhana wrote:
>>>>>>>>>> I created a wiki article.
>>>>>>>>>> https://docs.jboss.org/author/display/SECURITY/JSON+Security
>>>>>>>>>>
>>>>>>>>>> Will be adding more examples to this article.
>>>>>>>>>>
>>>>>>>>>> On 07/30/2012 11:22 AM, Anil Saldhana wrote:
>>>>>>>>>>> Hi All,
>>>>>>>>>>>               as you know currently IETF is working on securing JSON.  The drafts
>>>>>>>>>>> are all available here:
>>>>>>>>>>> http://datatracker.ietf.org/wg/jose/
>>>>>>>>>>>
>>>>>>>>>>> So last week, I implemented at least the bare minimum we require to
>>>>>>>>>>> secure JSON.  But encryption is tricky given that there are a lot of
>>>>>>>>>>> algorithms that are not yet available in the JDK implementation but are
>>>>>>>>>>> available via the BouncyCastle project.
>>>>>>>>>>>
>>>>>>>>>>> Look at the supported table:
>>>>>>>>>>> http://www.ietf.org/mail-archive/web/jose/current/msg00928.html
>>>>>>>>>>>
>>>>>>>>>>> While I was doing my implementation, I found out that there is a German
>>>>>>>>>>> researcher working on a project called xmldap.org and has implemented
>>>>>>>>>>> the drafts fully. He has been doing this for months. His license is MIT
>>>>>>>>>>> style.  I have requested him to create a separate independent project
>>>>>>>>>>> for JOSE so everybody can reuse his work, rather than create umpteen
>>>>>>>>>>> implementations.  He has agreed to work with me.
>>>>>>>>>>> http://ignisvulpis.blogspot.com/2012/06/ecdh-es-for-json-web-encryption.html
>>>>>>>>>>>
>>>>>>>>>>> Regards,
>>>>>>>>>>> Anil
>>>>>>>>>>>
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com