In TLS 1.3 as well as other similar data models like paseto there's been moves to make crypto options more rigid to prevent "negotiation hell" which allows for potential insecurities.
I'd like to see us do something similar if we're going to expand the crypto primitives used:
For example, one suite would use: XChacha20Poly1305 with x25519/ed25519 keys
Another would use: AES-GCM with ES256K keys
And a final option would be: AES-GCM with P-256 keys to support cryptographic enclaves.
I'd also like to see us standardize on an encoding scheme to make implementation easier. If we can't choose one than I'd like to see us support a standard way to support multiple encodings.
In TLS 1.3 as well as other similar data models like paseto there's been moves to make crypto options more rigid to prevent "negotiation hell" which allows for potential insecurities.
I'd like to see us do something similar if we're going to expand the crypto primitives used:
For example, one suite would use:
XChacha20Poly1305withx25519/ed25519keys Another would use:AES-GCMwithES256Kkeys And a final option would be:AES-GCMwithP-256keys to support cryptographic enclaves.I'd also like to see us standardize on an encoding scheme to make implementation easier. If we can't choose one than I'd like to see us support a standard way to support multiple encodings.
Where do others fall in regards to this thinking?