3 ms·
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. Virtu
by bitexploder 5y ago
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.
- dboreham 5y agoI 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.
- Zamicol 5y agoHere'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.