@FD:stuff really makes me uncomfortable. It's a neat hack for commandline applications, but it would break down when designing a library API, as the "type" of data passed around the API would be ambiguous, or at least with possible side effects. That feels like "design smell" here and I would like this to be changed.
I would recommend using equivalent environment variables to the parameters instead, for example SIGN_WITH for --sign-with and so on. This would, of course, require switching positional arguments to options but I already explain why that would be a good idea anyways earlier.
File descriptors could be passable as distinct options, like --sign-with-fd for --sign-with.
I've dealt with commandline applications that have special meanings with @, and in retrospect, it was a bad idea. In particular, Python's argparse module supports using a prefix argument to mean "read options from this file" and I've used it to implement crude configuration file support for monkeysign and other programs. It's confusing for users and does not work very well.
Specifically in this case, I would also worry about security vulnerabilities with untrusted filenames being passed to the program.
I'm not convinced by this, but even if we don't adopt it, it needs an answer.