Bill Stewart <stewarts(_at_)ix(_dot_)netcom(_dot_)com> writes:
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 :-)
CMR was not defined as an extension, it was proposed for inclusion in
the standard. Perhaps it would be less controversial if it were also
an extension. (Now there's an idea.)
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?
It is a problem for PGP.
Say I want to be able to tunnel information.
If I can not determine from the recipients public key whether he has
the tunneling extension, I must insert the information into the
plaintext, and this could confuse the recipient, and/or the recipients
software where the software does not support tunneling.
If I know that the recipient does not support this extension I can
avoid this risk by not using it in this case.
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
I think probably what you would do is to use the key which is nearest
to it's expiry date of those marked as forward secret. (You could
mark the keys as forward secret with another extension record).
Also, there is already I think a "valid from" date. So another way of
avoiding using a long term key which happens to expire before a short
lived one would be to use the "valid from" date to avoid using
relatively long lived keys where still valid shorter lived keys are
available.
I am happy to discuss or put together a proposal for how this might
work out, but the above comment was just arguing for an extension
system which allows things like this to be done as extensions.
The beauty of an extension feature is that the extension implementors
can hash it out in practice, and bring it back to the standards
process as tried and tested technology for next time around.
Also it allows us to move forward in a focussed manner to get
something minimal and workable out _now_. We could be hear until next
year arguing about Forward secrecy, and politically controversial CMR
extensions, etc.
Extensions are a useful way of focussing the discussion on what is
necessary now. If anyone brings up a "I want to do X" -- we just say
"fine use an extension" -- end of argument.
Supporting this automatically isn't straightforward -
what if the new encryption key expires _before_ the old one?
Use it instead. You are trying to give the message you are about to
send maximal forward secrecy. The way to do this is to use of the
available keys marked for forward secret use the one which expires
soonest.
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 is no inherent reason why RSA sign only and RSA encrypt only
keys could not be used. It would be interesting to have this
functionality expressible within the standard. (Perhaps it is... I am
not sure).
But yes, the extension I had in mind once we had an extension
mechanism, was to have forward secret EG subkeys.
I wasn't thinking directly about having forward secret signature keys.
But they too are interesting. To make a signature key forward secret,
you publish the private key :-)
(Then non-timestamped documents signed by you have lost much of their
proof of authorship).
If you wanted to do this it would actually argue that you had a
certification only signing key, as well as a document signing key.
You disclose the private document signing key when it expires. You
destroy the private forward secret decryption key when it expires.
Interesting stuff.
(Incidentally the Norwegian? standards document that I posted excerpts
from earlier makes this distinction between key uses... they see a
need for separate certification keys. Also they see a need to time
stamp signatures where the signature is intended to have meaning after
the signature key has expired. The application they are thinking of I
think is long term contracts.)
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?
All I was really proposing was that there be a flexible extension
mechanism so that we can put it in and get on with this iteration of
the standard without having people clamoring for their favourite
feature to go in at this stage.
Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`