Ian Brown writes, quoting Hal:
Other subpacket types are intended to be used with self-signatures,
allowing a key to make assertions about itself.
OK, just re-spotted this in Hal's post. This is obviously the place for
a key to assert that it is to be used for transient message encryption,
signing or (recovery-enabled) storage - or other purposes, as Adam's
message about Norwegian standards suggested. Can we discuss and design
such a sub-packet now?
I'm not sure that this would accomplish what you desire.
PGP already has sign-only and encryption-only keys, but these limitations
are implicit in the types of the keys. I prefer making things explicit,
so allowing a key state that it is sign-only or encryption-only would
be desirable (ignoring the difficulty of making statements with a key
which can't sign!).
For a key to say "I am signature-only" means that it should not be used
for encryption. If you were to encrypt a message to such a key then the
user would not be able to decrypt it.
For a key to say "I am encryption-only" means that it is not intended to
be used for signing. If you do somehow run across a signature by such a
key, you should not trust it.
Extending this to communications and storage keys would suggest the
following.
For a key to say "I am communications-only" means that it is not intended
to be used for persistent storage. A file encryption program might
not be supposed to use such a key to encrypt a disk file, for example.
(Although the user may be frustrated if the reason he was encrypting that
file with a communications-only key was because he intended to later send
it to that person!)
For a key to say "I am storage-only" means that it is not intended to be
used for communications. An email program would ignore such keys and not
try to encrypt messages to them.
Is this your intention? I don't see what problem it solves. Email keys
would presumably be marked as communications-only. All you would
have accomplished is to prevent people from encrypting disk files with
email keys. We can discuss this kind of feature but it would be helpful
to understand the specific goals better.
Hal Finney
hal(_at_)rain(_dot_)org
hal(_at_)pgp(_dot_)com