Expunge "cryptographic agility" from Coze vocabulary

[zamicol]

@LoupVaillant suggested to avoid semantical confusion by avoiding entirely the term "cryptographic agility". In its place we could say "provide loose primitive coupling."

The design goals would then become:

• Valid and idiomatic JSON.
• Human readable and writable.
• Small in scope.
• Provide loose primitive coupling.

Edit: Thinking more on this, perhaps the fourth design goal is dropped altogether since Coze implementations inherently provide loose primitive coupling, and that phrase itself would need to be rigidly defined. It also doesn't capture what I was trying to convey, that Coze provides "versioning" via "alg". Perhaps even something along the lines of "provide defined cipher suites". Edit2: or "Specify cipher suite expectations"

[LoupVaillant]

From the outside, it looks like your goal is to provide versioning, but instead of a version number you use a named cipher suite. Some kind of readable versioning. To this end, the best description I can think of is "Provide an upgrade path".

Now I must confess I'm not the biggest fan of readable names as version numbers. Without cryptographic knowledge users won't be able to tell which cipher suite is the latest, and that might cause problems down the line — or at least require you to be crystal clear which is which, and guide the upgrade path with an iron fist, say by frowning really strongly at implementers who don't default to the latest cipher suite like the specs says they should.

This could be remedied by prefixing the cipher suite name with the version number. Say, "alg": "v1 ES256" instead of the current "alg": "ES256". It's more characters unfortunately, but I personally see any other way.

Also, I noticed that you have both hashes and signatures. They appear to be completely disjoint. It would make sense then to let the version numbers be uncorrelated. For instance, if cryptographically relevant quantum computers ever become reality, you'll have to change the signature, but the hash might very well survive. In this case you would get "alg": "v2 PQ_LAT" and "alg": "v1 SHA256" respectively. I personally wouldn't bother synchronising the version numbers.

(Edit: that being said, I wouldn't fault you for deciding that version number prefixes are ugly, and stick to the descriptive names anyway. I've used a lot of words, but to be honest I was nitpicking more than I was actually criticising.)

[zamicol]

or at least require you to be crystal clear which is which, and guide the upgrade path

Yes, that is the goal.

And yes, from the other forum, my hope for Coze is to provide descriptive names as versions. I'm also in agreement with you on the method of upgrading that the only safe way "is to break users overnight, and force all providers to upgrade now. Coordinated release, CVE style." That's another reason why version numbers don't seem helpful. The other case of a totally broken algorithm should cause Coze to mark that value for "alg" as insecure and prohibit from further use.

I'd advocate that problems with Coze should be fixed while coordinating with implementations. Seperately, problems with primitive implementation needs to be addressed by implementors (if there's a problem with a Go implementation of Coze, Go Coze needs to work on the fix).

Coze assigns a hashing and a signing algorithm to a Coze signing "alg" ("ES256" is assigned SHA-256 and ECDSA P-256) which is used for all Coze related operations). If there was an application that was using ECDSA P256 with SHA-512/256 instead of SHA-256 that would require a new "alg" value, for example, something like "alg":"ES256_SHA-512/256".