Re: extension mechanism needed

[Bill Stewart <stewarts@xxxxxxxxxxxxx>]

At 12:15 PM 11/14/1997 GMT, Adam Back wrote:
>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.

Extension mechanisms require a communication mechanism between
the ends of the connection.  ESMTP is interactive, so it's easy.
In PGP, the only interaction mechanism from the recipient to the sender
is the public key record.  There's already an extension mechanism
for indicating algorithm choices.  There's another extension mechanism
for indicating additional recipients, but it's apparently controversial :-)


>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 sounds like a problem for the application programs on the ends,
not a problem for PGP itself?

>Another might be opportunistic forward secrecy via sending of new EG
>keys within each message with relatively short expiry times.

That sounds like there's a need for the sender of a key to indicate
that it should be used in preference to a previous key, e.g.
	New: Adam Back, 0x22222222, expires 2/2/1998
	Old: Adam Back, 0x11111111, expires 1/1/2000
Supporting this automatically isn't straightforward -
what if the new encryption key expires _before_ the old one?
And does the extension only apply to EG/DSA keys, or to
RSA keys as well (which has lots of complex interaction with trust models.)?

There's an obvious need to deal with the semantics of accepting keys,
and it sounds like you're proposing that this needs more options?
				Thanks! 
					Bill
Bill Stewart, stewarts@xxxxxxxxxxxxx
Regular Key PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639