4 ms·
We're in agreement that JOSE could have been much simpler. Again, I'm not a fan of JOSE, but I definitely see a gaping need for something like it. Defining the
by Zamicol 5y ago
We're in agreement that JOSE could have been much simpler. Again, I'm not a fan of JOSE, but I definitely see a gaping need for something like it.
Defining the "however you like" parts is the chief role of something like JOSE. Cryptographic standards like Ed25519 or ECDSA are not messaging formats. There needs to be an agreed way to send messages. That's the point of JOSE.
> so you need an actual written standard for how to shove the signed data and the signature into a single [...] you could just encode a tuple of (data, signature) [...] Need the header to encode which key to use to verify it? Fine, add a description of the key to the tuple [...] Need algorithm agility? Fine, treat the algorithm as part of the public key.
That's what JOSE defines.
- amluto 5y agoSo does RFC 8032. So do PKCS #1 and #7. It is every bit as easy and well defined to say “put a PKCS #7 message in PEM form in a header” or “put a base64-encoded RFC 8032 message in a header” as it is to say “put a JOSE message in a header”. There is no need for a special standard explaining with great verbosity how to glue existing standards that already fit together just fine. Especially when the standard tells you how to do it wrong as JOSE does.