Re: [jose] [secdir] JWK member names, was: SECDIR review of draft-ietf-jose-json-web-key-31

[Tero Kivinen <[e-mail]>]

Tim Bray writes:
> The chance  of the JOSE working group moving the vast world of
> deployed JSON infrastructure round to 0.00.   Thus putting a MUST
> reject in here would essentially say you can’t use well-debugged
> production software, and would be a really bad idea.

And are none of those jose parsers open source? If any of them is open
source, then someone who wants to use jose, could take one, fix it to
reject duplicates, and use that still well-debugged production
software, with small patch, and he just need to add regression test
case for the new patch, and rerun the normal regression tests to know
everything else still works.

If all of them are closed source software which you cannot patch, then
it might be better that people write proper open source parser which
actually tries to be secure.

> On the other hand, if JOSE specified that producers’ messages MUST
> conform to I-JSON, and a couple other WGs climbed on that bandwagon,
> and the word started to get around, I wouldn’t be surprised if a few
> of the popular JSON implementations added an I-JSON mode.  That
> would be a good thing and lessen the attack surface of all
> JSON-based protocols (which these days, is a whole lot of them).

And if we say MUST reject structures with duplicate keys, that would
perhaps force them even more, especially as those vendors really
wanting to be conformant would start asking that.

On the other hand, I think most of the vendors would just issue
request for the fix, but still continue using the relaxed parser,
regardless what we write in the specification here. At least if we say
MUST then they hopefully will put the feature request in. If we say
SHOULD, they will not...
-- 
[e-mail]