JSON Web Proofs

Further, base64 doesn't actually encode strings, it encodes bytes. If you're doing cryptography on something, you want to have a canonical byte representation. Canonicalizing JSON itself is error-prone, whereas decoding b64 gives you the same bytes every time.

Not only is JOSE base64 encoded, but many situations have base64 payloads embedded in the JSON, meaning payloads are double encoded, and as far as I'm aware, JOSE headers are always base64 encoded, regardless of the outer (re-)encoding. Each round of base64 encoding adds overhead.

For example, if starting with a 32 byte payload, the first round base64 encodes as 43 bytes, then is inserted into JSON, and then base64 re-encoded as 58 bytes. The starting payload of 32 balloons to nearly twice the size of 58.

For a direct example from one of the RFCs the header `{"alg":"RS256"}` becomes `"eyJhbGciOiJSUzI1NiJ9"`. That's 15 bytes unencoded, human friendly JSON and 20 bytes as encoded unfriendly base64.

Further, there's a later RFC 7797 that was intended to address the complaints of this, the 'JOSE JSON serialization Unencoded Payload Option', but that too failed to address encode ballooning in the headers. From the RFC:

{ "protected": "eyJhbGciOiJIUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19", "payload": "$.02", "signature": "A5dxf2s96_n5FLueVuW1Z_vh161FwXZC4YLPff6dmDY" }

That encoded header is 58 bytes but when unencoded, {"alg":"HS256","b64":false,"crit":["b64"]}, it is 42 bytes. There's no compelling reason for this design.

The better solution? Just stay as JSON.

I have more to say, but I'll leave it there. You can also check out my presentation on the matter here: https://docs.google.com/presentation/d/1bVojfkDs7K9hRwjr8zMW...

Right now a relevant slide is 115, or control-f "ballooning", or I have other text documents up on Github.

The header is JSON and could have potentially used another encoding for space. The payload and signature are both binary, so they needed a way to be represented in the 66 or so safe characters across all of those uses. In that case, non-padded URL-safe Base64 encoding is the best option.

Unfortunately, nested JWTs (signed and encrypted) as well as embedded binary data (such as public keys and thumbprints) in a JSON format also need to be base64 encoded. So there's a bit of a penalty in size for including these in the message, and that puts a bit of a design motivation in applications using these to limit such binary data within the messages themselves.

There is COSE, which uses CBOR to be entirely binary, but CBOR is rather robust and library support isn't close to what we have for JSON support.

For JSON Web Proofs, the goal is to define the core primitives in terms of binary data, such that a CBOR encoding does not require reinvention.

An example of such an approach is in the RFC appendix: https://datatracker.ietf.org/doc/html/rfc7519#appendix-A.2

Perhaps the biggest misconception about JOSE specs and JWT is that they are components, not a “batteries included” format. They are meant to be used to define further applications, such as ACMEv2.

Libraries often are written to solve specific problems (say, validating an OpenID Connect id_token) and blur the decisions such specifications made in profiling for their own use.

The nesting approach provides for non-repudiation of the decrypted JWT, which is important for federated identity use cases.

They're all made of base64url-encodes segments, separated by a period. The first segment is always the header, and you can easily identify them by starting with "eyJh".

A plain JWT has two segments, the second is the payload. In practice AFAIK it's not really used because it's just bloating your data.

JWS has a third segment that's the signature of the payload plus private key, and can be verified if you have the public key. JWT.io is a site where you can play with these.

JWE has five segments including an encrypted symmetric key, the IV and ciphertext.

So yeah, JWE is technically a different subtype. I'll only note you can stick an already-encrypted payload in a plain JWT or a JWS, and you can also take a JWT or JWS and encrypt it, and none of these is the same as actual JWE token.

(Full disclosure, I've written one implementation: https://github.com/auth70/paseto-ts)

After quickly skimming these drafts, I can’t tell whether it’s fixed. Certainly a lot of algorithm names are sprinkled around the encoded objects, but I didn’t spot a description of what a public key is.

I am moderately concerned by statements like:

6.3.2. Issuer Setup To use the MAC algorithm the issuer must have a stable public key pair to perform signing. To start the issuance process, a single 32-byte random Shared Secret must first be generated. This value will be shared privately to the holder as part of the issuer's JWP proof value

Few if any cryptosystems are intended to be secure if the private key is used in the wrong algorithm. This paragraph reads like one party should, as part of the API used by the application, one party sends 32 bytes, char[32]-style, to another. I don’t think any new design should work like this. New designs should fail hard when misused or when parties disagree as to what protocol variant they’re speaking.

Is there something in here to make the new standard clearly immune to algorithm confusion attacks?