W3C home > Mailing lists > Public > public-identity@w3.org > December 2011

Re: JSON Description Language

From: Richard L. Barnes <rbarnes@bbn.com>
Date: Tue, 6 Dec 2011 17:13:20 -0500
Cc: Harry Halpin <hhalpin@w3.org>, Anders Rundgren <anders.rundgren@telia.com>, "public-identity@w3.org" <public-identity@w3.org>
Message-Id: <6E4191FB-D3DB-441B-B6C6-7CC8955B7497@bbn.com>
To: Ron Garret <ron@flownet.com>
I fail to see how all this relates to a *crypto* API.  As I read the deliverables in the charter, they're focused on low-level crypto operations, which operate on octets, not structured data.

IOW, if you were using JOSE, then you would use the Crypto API to do the hard part (encrypting / decrypting / signing / verifying the actual protected octets) and just use generic JSON utilities for the formatting.

--Richard



On Dec 6, 2011, at 4:28 PM, Ron Garret wrote:

> Ah^2.
> 
> This might just be a difference in terminology.  I presume you're referring to vulnerability 2b in the layer cake paper?
> 
> When I think of name spaces (particularly within the context of XML, which is how Anders raised the issue) I think of disambiguating the semantics of identifiers with the same name, e.g.:
> 
> <key><type>public</type><algorithm>RSA</algorithm><modulus>...</modulus><exponent>3</exponent></key>
> 
> <key><type>residential</type><manufacturer>Schlage</manufacturer><pinCount>8</pinCount></key>
> 
> None of the vulnerabilities in [2] are like that.  They are vulnerabilities that arise from ambiguities in deserialization (i.e. the mapping of strings of characters to data structures, including identifiers, e.g. vulnerability 2c) or from disagreements about protocol (e.g. vulnerability 2a) or from straight crypto vulnerabilities (e.g. vulnerability 1).  But AFAICT none of the issues raised in [2] arise because of ambiguity in the semantics of an identifier that has been correctly parsed.
> 
> The whole premise that you would want to use the same identifier for two different purposes depending on context seems highly questionable to me for the matter at hand.  When it comes to security, simplicity is invaluable.  Many of the vulnerabilities in [2] (and #2b in particular) could be fairly said to arise directly from the unnecessary complexity of extant standards (BER in particular).  On this view, unless a compelling case can be made for why the semantics of identifiers should be context-dependent, the lack of namespaces (in the XML sense) in JSON is arguably a feature, not a bug.
> 
> rg
> 
> 
> On Dec 6, 2011, at 10:49 AM, Harry Halpin wrote:
> 
>> On 12/06/2011 04:31 AM, Ron Garret wrote:
>>> On Dec 5, 2011, at 6:51 PM, Anders Rundgren wrote:
>>> 
>>>> The following is related to DOMCrypt and similar...
>>>> 
>>>> http://tools.ietf.org/html/rfc4627
>>> It is?  What does JSON have to do with DOMCrypt?
>> Currently, while DomCrypt is a JS API, it does not use the formats specified by JOSE WG that is producing specs like JWT [1], but just straight unformatted arrays that can be converted to formats like those specified by JOSE or even in ASN.1.
>>>> Having a strong background in XML schema authoring I'm slightly
>>>> puzzled by the enthusiasm of using "secure" objects that (seem) to
>>>> have no notion of explicit (built-in) name-spaces or a description
>>>> language.
>>> I'm puzzled in what sense you think that JSON is "secure".  The only security claim made for JSON that I know of is that it can be safely parsed by the Javascript eval() function.
>> 
>> Please read this paper [2]. Due to some level of complexity and ambiguity of parsing Common names and inconsistencies amongst implementations (most likely due to ambiguity in specs or difficulty of parsing ASN.1), leads to a number of very dangerous attacks some of which actually happened in browsers. Therefore, simple syntax that can be easily and uniformly implemented reduces attacks.
>> 
>>> Can you please clarify why you think this is relevant to this group?
>> 
>> Note the dependency on JOSE WG in charter again. If we do need higher-level data-formats, we will use JSON rather than ASN.1.
>> 
>> cheers,
>>   harry
>> 
>> [1] http://tools.ietf.org/wg/jose/
>> [2] http://www.ioactive.com/pdfs/PKILayerCake.pdf
>>> rg
>>> 
>>> 
>> 
> 
> 
Received on Tuesday, 6 December 2011 22:13:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 6 December 2011 22:13:53 GMT