Closed quartzjer closed 9 years ago
@temas how's this look?
This is an armchair designer question, for that I apologize. But I'm curious :) so...
Any reason you didn't adopt JWK as the key transport mechanism? If you already committed to JSON, I think you are only saving a bit by putting the public key in binary. Also, you'll have to specify the binary format for each CS (maybe you already did this).
Perhaps you could map hashnames with the Key ID in the JWK model for example.
Excellent question, as that was highly considered :)
Each Cipher Set does indeed specify the binary format for it's public key material, so future ones could definitely choose JWK for that purpose.
The problem(s) with requiring it for all by default is pretty simple and compound: other cipher sets (both 1a
and 3a
) use public keys that are not (yet) specified as JWK alg
options, and the 1*
sets are designed specifically for embedded/lightweight usage where ideally a complete handshake can fit in <100 byte MTUs (very size sensitive).
The mapping to/from JWKs is really straight forward so I expect a lot of interop/compatibility and future sets to use more of those defaults, but it's up to each cipher set to express its own requirements :)
+1
This was prompted by @temas to simplify the key handshake, attaching the packet as the BODY.