[security-dev] Implementing JSON Security

Mon Aug 6 10:38:58 EDT 2012

Bill,
   definitely in usecases where the user has complete control over the 
client/server infrastructure, then we should recommend s/mime.  But in 
cases, where they are dealing with an infrastructure outside their 
control but requires JOSE, then we should provide them an 
implementation. Because if we don't enable their use cases, they will 
just go elsewhere.

Regards,
Anil

On 08/05/2012 10:22 PM, Bill Burke wrote:
> 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
>>