Hi Richard, hi all, Interesting, Richard.
In message <[email protected]> you said "JSON schemas cannot forbid duplicate keys..." Since my idea does not save keys in the JSON data the duplicate key problem looks solved and the object nesting depth is solved in one go. As I suggested in my last mail, we should consider beleving keys in DNS. Regards, Timo It looks like Richard Clayton aimed to say: > In message <[email protected]>, Timo > Gerke <[email protected]> writes > >> I personally do not have a problem with JSON, but we strictly >> have to limit object depth. > > the JSON schema in the DKIM 2 spec already limits the depth > >> BTW: This concept completely contradicts the principles of >> RFC 5322. > > I don't understand that comment ... but if you are truly worried about > unlimited depth then you should break away from DKIM2 and start writing > an IETF draft to update RFC2046 ... MIME multipart and MIME message can > both be nested to any arbitrary limit (albeit, good luck interworking > when you get past two or three) > >> Standard JSON specifications lack strict object-key ordering > > absolutely ... why is this a problem ? > >> and >> duplicate key handling. > > JSON schemas cannot forbid duplicate keys ... so you have identified an > actual issue that the spec needs to address (though just providing some > text would have been far quicker and easier for all concerned). > > I will add some text to the -07 spec to explicitly forbid duplicate key > values. > > I will note that JSON parsing libraries already have calling parameters > for this issue -- since the consensus is that duplicate keys are pretty > much always wrong -- so implementors will be able to deal with this > change very quickly (if indeed they are not already doing so). > >> Introducing nested object complexity into >> the transport layer creates serialization risks that flat, native >> tag-value structures inherently avoid—which is why DKIM1 worked >> without JSON for 15 years. > > it escapes me what serialization could possibly be required ... > > ... and should probably note that DKIM1 did not have JSON but does have > its own complex set of issues relating to duplicates that many systems > deal with extremely poorly. See for example the "Inbox Invasion" paper > by Zhang et al. We believe that DKIM2 fully addresses authentication > issues related to the type of header field issues that they identified. > Timo Gerke Hamburg, Germany "If you think technology can solve your security problems then you don't understand the problems and you don't understand the technology." -- Bruce Schneier
OpenPGP_0x9F03DF9F597BF31E.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
