Add guidance/limits for size and complexity of object members
Closed this issue · 0 comments
Comment:
The last bullet of section 3 says "any number of other
members" and in general there are no limits here on size
or complexity of the objects. (There are some should
statements, which is good.) I wonder if there's a
potential DoS vector there? Speculating, a DoS couuld be
based on the CPU if calculations based on the object are
complex, or it could be based on the size of the object
being VERY BIG. Are either of those realistic? (I'm not
saying they are, just asking.) I'm guessing it'd not make
sense to have a max size to these things, but is there any
guidance that you could offer to implementers or would it
be good to say that implementations SHOULD have some
maximum size (I don't care how you'd want to measure that)
with a recommendation that it be able to handle things up
to at least some nominated size? (Section 11.2 does talk
about this for senders/creators but says nothing for
recipients/readers.)