I personally don't see the overengineering in JOSE; as you mention, a JWK (and JWKs) is not much more than the RSA key data we already know and love but formatted for Web and HTTP. It doesn't get more reasonable than that. JWTs, same story, it's just JSON data with a standard signature.

The spec (well, the RFC anyway) is indeed classically RFC-ish, but the same applies to HTTP or TCP/IP, and I haven't seen the same sort of complaints about those. Maybe it's just resistance to change? Most of the specs (JOSE, ACME etc) aren't really complex for the sake of complexity, but solve problems that aren't simple problems to solve simply in a simple fashion. I don't think that's bad at all, it's mostly indicative of the complexity of the problem we're solving.

▲

unscaled 2 days ago | parent | next [-]

I would argue that JOSE is complex for the sake of complexity. It's not nearly as bad as old cryptographic standards (X.509 and the PKCS family of standards) and definitely much better than XMLDSig, but it's still a lot more complex than it needs to be.

Some examples of gratuitous complexity:

1. Supporting too many goddamn algorithms. Keeping RSA and HMAC-SHA256 for leagcy-compatible stuff, and Ed25519 for XChaChaPoly1305 for regular use would have been better. Instead we support both RSA with PKCS#1 v1.5 signatures and RSA-PSS with MGF1, as well as ECDH with every possible curve in theory (in practice only 3 NIST Prime curves).

2. Plethora of ways to combine JWE and JWS. You can encrypt-then-sign or sign-then-encrypt. You can even create multiple layers of nesting.

3. Different "typ"s in the header.

4. RSA JWKs can specify the d, p, q, dq, dp and qi values of the RSA private key, even though everything can be derived from "p" and "q" (and the public modulus and exponent "n" and "e").

5. JWE supports almost every combination of key encryption algorithm, content encryption algorithm and compression algorithm. To make things interesting, almost all of the options are insecure to a certain degree, but if you're not an expert you wouldn't know that.

6. Oh, and JWE supports password-based key derivation for encryption.

7. On the other, JWS is smarter. It doesn't need this fancy shmancy password-based key derivation thingamajig! Instead, you can just use HMAC-SHA256 with any key length you want. So if you fancy encrypting your tokens with a cool password like "secret007" and feel like you're a cool guy with sunglasses in a 1990s movie, just go ahead!

This is just some of the things of the top of my head. JOSE is bonkers. It's a monument to misguided overengineering. But the saddest thing about JOSE is that it's still much simpler than the standards which predated it: PKCS#7/CMS, S/MIME and the worst of all - XMLDSig.

	▲	oneplane 2 days ago \| parent \| next [-]
		It's bonkers if you don't need it, just like JSONx (JSON-as-XML) is bonkers if you don't need it. But standards aren't for a single individual need, if they were they wouldn't be standards. And some people DO need these variations. Take your argument about order of operations or algorithms. Just because you might not need to do it in an alternate order or use a legacy (and broken) algorithm doesn't mean nobody else does. Keep in mind that this standard isn't exactly new, and isn't only used in startups in San Francisco. There are tons of systems that use it that might only get updated a handful of times each year. Or long-lived JWTs that need to be supported for 5 years. Not going to replace hardware that is out on a pole somewhere just because someone thought the RFC was too complicated. Out of your arguments, none of them require you to do it that way. Example: you don't have to supply d, dq, dp or qi if you don't want to. But if you communicate with some embedded device that will run out of solar power before it can derive them from the RSA primitives, you will definitely help it by just supplying it on the big beefy hardware that doesn't have that problem. It allows you to move energy and compute cost wherever it works best for the use case. Even simpler: if you use a library where you can specify a RSA Key and a static ID, you don't have to think about any of this; it will do all of it for you and you wouldn't even know about the RFC anyway. The only reason someone would need to know the details is if you don't use a library or if you are the one writing it.
	▲	folmar 2 days ago \| parent \| prev [-]
		`cfssl` shows how easy could getting certificates signed be for the typical use case. https://github.com/cloudflare/cfssl

▲

lmz 2 days ago | parent | prev [-]

Imagine coming from JWK and having to encode that public key into a CSR or something with that attitude.

▲

oneplane 2 days ago | parent [-]

Imagine writing your own security software when there are proven systems that just take that problem out of your hands so you don't need to complain about it.

	▲	lmz a day ago \| parent [-]
		I'm agreeing with you that the author is complaining too much. Going the other way they would probably go "and then we have to somehow encode the numbers '1 2 840 113549 1 1' somehow to mark the key type".