* Adam Back wrote:
[Declare it reserved.]
I don't like this. I prefer a clear semantics who to deal with:
10 - symmetric key recovery key (REQUIRED)
This option consits of a class octet, a asymmetric cryptosystem
identifier octet, and twenty octets of the fingerprint. The last eight
octets are the key ID. So only keys of the packet format four or
higher can be used. This is found on a self-signature.
The class octet is one, if the use of this recovery key is required.
If it is zero, the use of this recovery key is up to the user. If data
is encrypted to such a key, it MUST/MAY (depending on the class octet)
be encrypted to each recovery key, too.
Keys containing this subpacket are local storage keys only. They MUST
NOT be used in communication. They SHOULD be droped from keyrings
outside the desired storage enviroment to avoid message key recovery.
They MUST NOT occur on public keyservers. If such a key arrives over
the Internet, a warning MUST be produced and the key MUST be droped
(prefered) or disabled locally.
or:
If the subpacket exists, the key SHOULD be droped, keyservers MUST NOT
accept the key. If a user likes to respond he MUST get a warning and MAY
choose from one of the following options:
- Ignore the request (default/MUST, if no user interaction)
- Fake a session key matching the IV and padding tests of the
policy enforcer (which is possible *evil grin*)
- Use it as requested.
Furthermore I request to reinclude the older proposals key usage, URL,
finger, ... (texts avail)