Re: JSON Description Language

On 12/06/2011 10: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.
>

I have no idea why namespaces or semantics of identifiers came up, 
perhaps Anders is as usual off topic. We will *not* be using XML 
directly in this work at all. As brought up by Steve Farrell earlier, 
there has already been work in putting PKI in pointy-brackets and that 
had little deployment success.

The problems referred to in the PKI Layercake paper where problems of 
syntax and implementation that came from excessive complexity due to 
ASN.1-based  BER. This is another reason we want to scope this WG away 
from certs, as that particular field is in motion again. If there will 
be cert-based work, it will be in another WG.

  Namespaces and other semantics adds complexity to parsing (please see 
HTML5  WG critique of XML namespaces), so if we use a syntax it will be 
based on the JOSE WG work. However, we will go as far as possible with 
using arrays that can be processed downstream into other syntaxes, which 
could be JOSE WG work or even XML if one so desires.

Any sort of JSON Schema is out of scope for this working group. There is 
work on such a schema in the IETF, but it's quite preliminary [1]. Enjoy.

         cheers,
            harry

[1] http://tools.ietf.org/html/draft-zyp-json-schema-03
> 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 21:49:39 UTC