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
not, etc).
Comments?
(btw I am now manually using the FS extension... use key below for
Nov, on 2nd Dec the private key gets burnt).
Adam
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-----
Version: 2.6.3i
mQENAzRiPnQAAAEIAMQqkuRbiy3sofhHVTTGp2UCYQL9VY91CGMXqKW5Y0IgR0qS
SLlq6xmdI1OkLuyxPNClLs9Qkie6LXJK7oFuNhEOmoNkLATgAHs3R2Jr24O6jmUf
F+ohoII6iUyE8RNO1iv2L94fi6IR6bZTvcIPb6gcqEtFNjg07oc2d0O419dJfCud
Z95/Hh91b/J6GesbKd66rqnyhrszmBQ6cbLKGtTj8BWSg04KLDcZRxxzfcFWltF3
qFV36/cUIbK+ev10ZJw/z1iV8t/pzQ8kOvVlNbyOOZ3+/HpIrC2BEdhpGFDQSQlA
duWxNAmiorSxhmGfWBDa0ZCGj2sKW7W/OcoqAG0ABRO0LUFkYW0gQmFjayA8YWJh
QGRjcy5leC5hYy51az4gKEZTIGtleSwgTm92IDk3KYkBFQMFEDRiP8I+e8qoKLJF
UQEB3O8H/2nW1Ng2A0gkk7ueCt/o2tnWFiK8p1V4RPtZ/SpU9xSolJIYs8evYFTg
VFyZEKR1YZ/a1gp0pr1/3b6vRHidJgzZpRpx21jDXMPx8VLS32NQRTJkN7+OMiAo
ls5Oj8LRRlWroXfGnb7YxV+O8J7r11YaCMB/eMObrg7VMFg9Q8V0ct8gYQvCu9hZ
jwYn/Ldi1A5HQdCce7n9EzHoChjjGFGIH5IlPquSbfMLJP7VASimwoBhe7dq3rLz
u9Y1oOAq4xQ3K9Op7ieR28Ad+OBmv+qQP22BJ3u2OtwnabIOgjJ4uH6Ulr+r6qwo
oEVT2p9hCKBTW1uZk/19TZSX04VfCHyJARUDBRA0Yj7wW7W/OcoqAG0BAc4GB/9r
EHKIVCD+XPDPVKCuiovhHb61BHQKc+fT+xfemR/fg2FHdTz1Arrsubqr/IdYHsNK
OwWf9J2/IOcKPqhMKh3i42cIMaJ4VM5T5CFGlVEfr7GUDjFzljz4oGfAwfY6IWnL
ozpfqe2bzt72uWvAvPkxx+Ue8qQqDlU57udihP8dtA0qgH+JAMJ5bjvg1krdbIg9
T3989mbmBg+6tlxq3Vfp/Zb9D1rD/XC2+JyoGIdaLej2tIXxisq7uixwDSX6jEJX
4wW0qEnONNwlIukJLEu69WqUeOEJhCV1jRNvY3m8rmyKSHr5p037LRX3GmdrNwsW
RPRFkNaBTo/OFhUtH1Nx
=9Cl1
-----END PGP PUBLIC KEY BLOCK-----