In ESMTP/SMTP there are extension mechanisms. Clients/Servers can use
this mechanism where the other party has it also. This is a very
powerful and simple to add feature. I think we need such an extension
mechanism in OpenPGP.
One example I am thinking of is transparent tunneling of SMTP headers
inside the encrytion envelope when both sides are using an encrypting
proxy such as Ian Brown's Enigma.
(This allows mutliple recipients to be broken up into separately
delivered single recipient messages and the Cc fields reconstructed by
the decryption agent for the MUA. Useful also for mixmaster delivery,
which such a proxy agent can automatically manage.)
Another might be opportunistic forward secrecy via sending of new EG
keys within each message with relatively short expiry times.
Both of these would be hacky if one had no formal way to determine the
extensions the recipient's software could handle, as one would be
forced to hack or tweak various values in the existing spec in ways
which would hopefully not break other implementations.
I want to be able to encode:
Extension: Forward-secrecy, SMTP-header-tunneling
In such a way that implementations without these extensions will
know to ignore those it does not understand.
It would seem that these extensions should be self signed and perhaps
attachable to userIDs so that different userIDs could be marked for
different capabilities. (Perhaps the client you use at your home
email address has the FS extension, but the one at the office does
(btw I am now manually using the FS extension... use key below for
Nov, on 2nd Dec the private key gets burnt).
Type Bits/KeyID Date User ID
pub 2048/CA2A006D 1997/11/06 Adam Back
<aba(_at_)dcs(_dot_)ex(_dot_)ac(_dot_)uk> (FS key, Nov 97)
-----BEGIN PGP PUBLIC KEY BLOCK-----
-----END PGP PUBLIC KEY BLOCK-----