Hacker News Reader

Comment by formerly_proven | Hacker News Reader

In the spirit of nand-gate: "An IETF[1] is angry and shocked that an internet does not want to use their crypto dumpsterfire"

Case in point, the mentioned COSE format makes signatures by defining protected and unprotected attributes of the payload and then computing signatures over the Canonical CBOR encoding of the protected attributes. All this is done so that you can have parts inside your payload that can be changed without invaliding the signature, and it of course requires two-phase canonicalization. Yes, PASETO is absolutely, unequivocally a better choice than J/COSE.

Sign. The. Goddarn. Bytes.

[1] Actually not just any IETF but the dude who made an incompatible fork of msgpack named after himself.

View on HN

I had not known about JOSE and other subsequent “standards” until this article. Everyone knows JWS is a dumpster fire and to continue to pack on additional “standards” on top of it???

The original medium blog post seems fine to me.

Sounds like a salty standards author, who worked on something nobody actually wants…

Unfortunately, some have used "JWS" to refer to JOSE, because that's all they personally used. JOSE is the standard. JWS is a subset. Same with JWK, JWE, JWT, ect... It's all JOSE.

Here's an example from three years ago: https://news.ycombinator.com/item?id=21783303

I think lately I've been seeing people use more correct terminology with JOSE.

Oh my god the name just clicked. I knew some of the history but didn't catch he named it after himself.

Ha that's funny. I remember looking at CBOR and wondered why anyone would use it instead of MessagePack. Looking at it again, it seems different for the sake of being different.

From the CBOR wikipedia page:

> CBOR was inspired by MessagePack, which was developed and promoted by Sadayuki Furuhashi. CBOR extended MessagePack, particularly by allowing to distinguish text strings from byte strings, which was implemented in 2013 in MessagePack.

> Integers (types 0 and 1): For integers, the count field is the value; there is no payload. Type 0 encodes positive or unsigned integers, with values up to 264−1. Type 1 encodes negative integers, with a value of −1−count, for values from −264 to −1.

WTF? JavaScript got it wrong not being able to represent 64-bit integers. CBOR wants to make 65-bit signed integers(!) by combining 64-bit positive (type 0) and 64-bit negative (type 1). A rational person would make 64-bit unsigned, and 64-bit signed types like most languages and hardware. Only an academic would propose something as disconnected. To fully support a CBOR negative (type 1) integer you'd have to use a 128-bit signed or something like that.

Back then msgpack didn’t distinguish between binary and UTF-8 strings, though that was added latter. But yeah, even if you needed to create your own format to change that you don’t need to turn your integer support into a trash fire while you’re at it.

Nominative determinism?

I am not up to speed on this spec. Why on earth would they not just create an format that signs all of the bytes and makes that easy. It’s not expensive. Virtually all of the web runs on TLS… and it does fine.

I don't know anything about this spec, but typically the reason is that you want to be able to generate and verify signatures in a place and at a time where the transport isn't known. Therefore there are no "bytes" to sign. In essence the idea is to define an abstract transport (e.g. encode as JSON) and sign that. Then subsequently it doesn't matter how the bits are sent from A -> B -> C, you can always verify the signature by recreating that abstract encoding.

Obviously this is less efficient than signing the transport payload, but that doesn't help if you just don't have access to the transport payload, or when there are N different kinds of encoding used in different places in the system.

Here's an example I've encountered with a user/server system.

A user signs a message with a key and uses a thumbprint to refer to the public key. The server system needs a public key, not just the thumbprint, to verify the message. The server does not accept full public keys in the signed message since public keys are large and thumbprints are sufficient.

One design is to transport the public key along with the signed message. This allows the server to verify and store the whole signed message even if the server doesn't store the public key.

Reply on news.ycombinator.com