ietf
[Top] [All Lists]

Re: Last Call: <draft-bormann-cbor-04.txt> (Concise Binary Object Representation (CBOR)) to Proposed Standard

2013-08-17 08:02:51
But tag 24 makes it harder for pedantic security devices to validate CBOR, 
somewhat like an "eval" statement.

Well, eval is Turing-equivalent, while tag 24 has quite narrow semantics.
So the added onus should be much more limited.

Is a "strict mode" decoder required to decode/validate the contents of this 
tag?

Good question.
In my mental model, the "CBOR data"-tagged byte string is handed to the 
application, and this would then have to explicitly call the decoder again if 
needed (usually in strict mode again).
If the application does task the decoder to decode it as well, the strict mode 
should transfer to that (unless the application has explicitly said otherwise).

And security aside, this usage means that endpoints (sender and receiver) 
work a bit harder, in order to make the life of middleboxes easier. This may 
or may not be the right trade-off, depending on your architecture.

There may be other reasons for a sending application to facilitate deferring 
decoding a part of the structure.

I'm not as sure about the continued importance of the premise here.
The premise seems to be "you are only middlebox-friendly if you provide a 
highly efficient way to skip large swaths of coded data the middlebox happens 
not to be interested in".
Unless the application knows precisely what the middlebox is trying to do (like 
in Joe's routing example), this may be hard to achieve.
With the move to architectures where every byte needs to be touched anyway 
(say, for encryption, or with transports like Minion), this also becomes less 
relevant.

I'm pretty sure the encoder-friendliness of item-counting (as opposed to 
byte-counting) approach trumps any middlebox-friendliness aspect here.

... switching messages here:

This is indeed good text. I suggest to also add: "A tag followed by an
aggregate data item (map or array) applies to all members of the data item."

This is not a property of tags in general.  A tag tags just the one item it 
contains.
(This sentence could be used to describe a specific property of the "expected 
conversion" tags, but saying it this way might be confusing.  For these three 
tags, the additional onus of inheriting the "expected conversion" to byte 
strings embedded in the tagged data item is only paid by JSON converters.)

Grüße, Carsten


<Prev in Thread] Current Thread [Next in Thread>