Adam Back writes:
Are PGP Inc's CAK features intended to be part of the now IETF
controlled Open-PGP standard?
Let me explain briefly what the new features are, then say something about
the directions in which we may want to go.
In older versions of PGP, key signatures were used for just a few things.
They could bind a userid to a key, or they could revoke such a binding.
They were also used for a user to revoke his own key by issuing a revocation
self-signature.
PGP now offers an extensible signature format. This allows key
signatures, both self-signatures by a key on itself, and ordinary key
signatures by keys on other keys, to do more than before. The extensions
are in the form of subpackets within the signature packet. Various
subpackets have been defined, and Open-PGP would be an excellent forum
to propose and design new subpacket types and corresponding data formats.
Some of the subpackets are modifiers of ordinary userid-binding signatures.
These allow signatures to have expiration dates; to be marked as non-
exportable (so that the signatures are only for your own use on the
keyring); to be "meta-signatures", which delegate to other keys the power
to choose trusted introducers; and to specify a regular expression which
restricts the power of signing keys.
Other subpacket types are intended to be used with self-signatures,
allowing a key to make assertions about itself. We have moved the
key's expiration date into this location, for example. There is also
the preferred-algorithms subpacket, which allows a key to specify
which conventional encryption algorithms it can accept and which it
would prefer. And here there is the new corporate message recovery key
(CMRK) subpacket.
The CMRK subpacket allows a key to request that when a message is
encrypted to it, the message should also be encrypted to a specified
additional key. The subpacket includes a flag byte which is designed to
allow the key to give information about the circumstances under which this
should be done. Only two values are presently defined, one specifying
an optional request, and the other meaning that the message will not be
read by the recipient if the additional encryption hasn't been done.
I won't address the controversy about this feature, as that is being
thoroughly discussed in other forums. Let me make two points, though:
We would like to move towards a mechanism to allow more power for keys
to make assertions. Matt Blaze's (still vaporware?) PolicyMaker project
showed how powerful such a general mechanism could be. SPKI is also
working along these lines, defining a certificate format which allows
keys to make very general classes of assertions.
The CMRK is one such type of assertion: "please cc to key X anything
encrypted for me". The key is requesting that the specified other key
by an additional recipient on encryption.
If we move to a sufficiently powerful language to allow keys to make
useful assertions, it seems to me that we will probably inherently
allow keys to make assertions of a type which some people may regard as
politically unacceptable, like this one. But to artificially constrain
the language so that it can only say things which are politically correct
will make a an already-difficult design task into an intractable one,
I'm afraid.
Ultimately, a fully general and flexible system of key assertions will
allow keys to say stupid things as well as smart ones. I believe that
the power gained from having such a language gives advantages which
outweigh the problems of misuse. (Note the similarities to the debate
over the PICS labelling technology, which some people oppose because it
could be misused.)
Secondly, with this type of assertion, as with others such as
the preferred algorithm packet, it is inherently in the sender's
(encryptor's) power to ignore it if he chooses. You can request that I
not use triple-DES, but I could still send you a message encrypted with
that algorithm. You would then have the choice to reject it or accept it.
This is a point which I owe to Phil Zimmermann.
There could eventually be other kinds of requests made by keys in their
self-signatures beyond preferred algorithms and additional recipients.
Keys could request that you don't use certain signing or hash algorithms,
for example. We could even have packets allowing keys to state that
they won't decrypt messages unless you include $1 in ecash in the header,
and similar unusual requests.
Because of the sender's power of choice, which is inherent in the
nature of communication, in my opinion the requests of a receiving
key should at best be considered advisory. In fact, in PGP 5.5 we
will now sometimes override the preferred algorithm subpacket and use
an algorithm which the recipient has stated that he will not accept.
(This is done when there are multiple recipients, and no algorithm is
acceptable to all parties.) Likewise in PGP 5.0 the user can override
the CMRK request even in its strongest form (although not in 5.5, because
that is intended for business-to-business communications).
Therefore, I very much agree with Jon Callas that an implementation which
(perhaps optionally) allows overriding the requests which a key makes
in its self-signatures should still be considered compliant. That is
consistent with the nature of the sender's power to create the message.
Hal Finney
hal(_at_)pgp(_dot_)com
hal(_at_)rain(_dot_)org