> I hope you realize this doesn't make sense. Would minsign2 be able to read minsign1? For an end user, they will need to know even more out of band information about the signature they want to verify.
"Signify 2" would be a specification, not a program. A future Age or Signify implementation would be able to handle multiple versions of their specs without mixing their components together just as easily as:
- A TLS/SSL program (OpenSSL, LibreSSL, bssl, etc) can work with TLS 1.2 and 1.3.
- libcurl can handle HTTP/1.0, HTTP/1.1, and HTTP/2.0
Say Age 2 uses, I don't know, "AES-512" (I pulled that out of my ass for illustrative purposes, don't tell anyone) and Argon2id instead of AES-256 and the HKDF. Your choices would be Age 1 or Age 2; you wouldn't be able to use both AES-512 and the HKDF, or AES-256 and Argon2id. There would be fewer combinations to keep track of, making it easier for other implementations to support less as insecure standards get phased out (c.f. TLS 1.0, 1.1). Insecure standards will still be around and be relatively simple to implement for anyone interested (especially for Signify, whose spec is so basic).
This is how versioned specs are supposed to work, with iteration rather than extension. The command I demonstrated wouldn't have to change.
If Age followed the PGP approach, a future version would support choosing either AES-256 or AES-512, and either the HKDF or Argon2id. You'd mix-and-match, and write all the metadata into the file. It'd be much harder to move away from bad standards. Instead, right now, Age just writes the version of the Age spec being used; that implies the rest.
"Signify 2" would be a specification, not a program. A future Age or Signify implementation would be able to handle multiple versions of their specs without mixing their components together just as easily as:
- A TLS/SSL program (OpenSSL, LibreSSL, bssl, etc) can work with TLS 1.2 and 1.3.
- libcurl can handle HTTP/1.0, HTTP/1.1, and HTTP/2.0
Say Age 2 uses, I don't know, "AES-512" (I pulled that out of my ass for illustrative purposes, don't tell anyone) and Argon2id instead of AES-256 and the HKDF. Your choices would be Age 1 or Age 2; you wouldn't be able to use both AES-512 and the HKDF, or AES-256 and Argon2id. There would be fewer combinations to keep track of, making it easier for other implementations to support less as insecure standards get phased out (c.f. TLS 1.0, 1.1). Insecure standards will still be around and be relatively simple to implement for anyone interested (especially for Signify, whose spec is so basic).
This is how versioned specs are supposed to work, with iteration rather than extension. The command I demonstrated wouldn't have to change.
If Age followed the PGP approach, a future version would support choosing either AES-256 or AES-512, and either the HKDF or Argon2id. You'd mix-and-match, and write all the metadata into the file. It'd be much harder to move away from bad standards. Instead, right now, Age just writes the version of the Age spec being used; that implies the rest.