According to the specification, signing of any type is out of scope:
- Any kind of signing (which is not a tooling problem, but a trust and key distribution problem, and to the extent that tools matter you should just use signify/minisign, and for keys we should probably use SSH ones)
This is, in my opinion, a missed opportunity. This project is an opportunity to not only build a new tool that addresses issues that plague other tools (such as GPG), but also to build support in the community around this tool. By placing this restriction on the functionality that age may contain, age is less useful, and will require the use off additional tools (and additional keys to manage) to achieve the same functionality that users will likely expect.
This expectation can be demonstrated by looking at the open issues (such as #38 & #49), and conversation on Twitter about age - the lack of signing support is striking potential users as a surprise, as it would be assumed that a tool of this nature would include signing support. There is, without question, user interest in this feature.
There are, as noted in the quoted section above, issues with signing support, in that it can involve key distribution and trust, which are complex issues - that said, these issues need not be addressed by age, as a solution is not required to allow users that wish to validate that an encrypted file is from the expected sender/system to perform this validation. Adding optional support for signing a file with the sender's key is a trivial matter; adding an additional header to the age file format is a simple matter, adding CLI support for this is likewise, a simple matter.
In use cases where it is desirable to validate the sender, it would not be unreasonable to require users to transmit their public key out-of-band (from a UX perspective, this could use the proposed aliases.txt
file to display a friendly name for known senders). It is possible that key distribution methods could evolve around age, though these should be allowed to evolve organically, and it is not necessary for age to address this at this point in time.
While there are tools such as signify and minisign (which I am personally a fan of), it is not a good user experience to require users to make use of an additional tool, with additional keys, to perform signing of files they produce.
I would propose that an optional header be added, which includes the sender's public key and a signature of the hash of the encrypted data. When a file is decrypted, this signature would be validated, and decryption should fail if this check fails. The user can either manually review the public key for a match to known senders, or age could look up the public key in the proposed aliases.txt
file and display a friendly name. This could be done with minimal impact, would improve protection of files that have been signed, and require no extra effort from those that don't have a need to perform this validation.
I appreciate that this could lead to a push for greater development of a key distribution & trust solution (which could evolve into a interesting side project, though that's another conversation), though it will without doubt lead to a better user experience and lead to further use cases for age.