Re: JSON Description Language

On 12/07/2011 10:31 AM, Anders Rundgren wrote:
> On 2011-12-06 23:13, Richard L. Barnes wrote:
>> 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.
> When you encrypt or sign you indeed operate on binary data.
> However, the binary data doesn't have to be just a blob, it may very well be
> a serialized version of a complex document.
>
> Anyway, the question I raised was it not only targeted to this WG, but to the
> entire "JS-security community", including the JOSE folks.
> When you begin to design protocols that has been mentioned as a use-case for
> DOMCrypt, you *may* find that dealing with collections of anonymous security
> objects isn't entirely ideal.

Agreed, which is why the JOSE WG is listed as a dependency. Again, let's 
see how far things can go wtihout dealing with serializations though. Of 
course, unless one has a use-case that *requires* a serialization being 
handled natively by the API, in which case you need to write it up in 
1-2 clear sentences by Friday and send it to the mailing list.

> But this only represents *my* opinion and I'm done now :-)
> Pardon for wasting valuable list space.

Anders, thanks for sharing your opinion. We are trying to narrow scope 
and get together use-cases sentences for the charter, not get into an 
open discussion of serializations and JSON Schemas. If you want to 
engage in a general security discussions, there are lots of security 
mailing lists.

What would be a good use of your time would be a detailed review of the 
charter that makes arguments against the primary/secondary/out-of-scope 
features and a few clear use-cases for any features in primary or 
secondary scope. Your earlier mentioned use-case will go in to the 
update of the charter on Friday, which is the deadline for use-cases.
> Anders
>> 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 Wednesday, 7 December 2011 11:59:04 UTC