Re: The issue of mime parsing

Andrew Rutherford <[email protected]>:

> On a different issue, RFC 3264, "An Offer/Answer Model with the
> Session Description Protocol (SDP)" describes something in my previous
> SIP example that's relevant here.
>
> In negotiating codecs over SIP, the idea is that in the first packet
> from the initiator, it proposes a preference list of acceptable codecs
> - basically everything it supports. In the 200 response, the receiver
> sends back just the one that they picked, which is then acknowledged
> by the initiator in an ACK.
>
> This has obvious implications when talking about "negotiating"
> acceptable encryption keys, given the SIP messages are end-to-end. The
> sender of the email could propose a list of encryption keys and
> techniques supported in preference order, and the receiver can respond
> with the one they have picked, or a message saying none were
> acceptable (which may give an alternate proposal list, which could
> lead to another round). The sender can then encode the email parts and
> place it into the appropriate storage facility before sending the ACK,
> and which point the receiver knows the parts can be picked up.

not neccessarily the sender.  lets assume you have the general
requirement of securing messages, and you don't trust keys from X or
keys managed by Y.  you prefer key management done by Z.  now the
receiver does not yet have a key signed by Z, but he accepts anything.

you have a rule saying "if receiver accepts anything, let im2000
decide".  this can lead to message encrypted to robot R, which has a
key by Z and relays for you.  meaning you will get the message over,
but it will be encrypted by R, for the receiver and signed by you.

> Now, the next bit depends on if the SIP message body is encrypted or
> not. If not, proxy servers in the path could modify the preference
> order to meet the specified policy requirements (eg, X is preferred
> over Y). This is typically used in the VoIP world by proxy servers
> who understand the network topology so know for a particular call if
> a low or high bandwidth codec is appropriate.

cool!  now people may think finding acceptable encodings/keys may
soon grow exponentially to the point of getting unmanagable, but
reality will show (i hope) that people either accept anything as long
as they trust the senders credentials or make relatively "bounded"
requirements on two or three entities they trust key management and
storage to.  conversion services, i believe, will be a list of, say,
a few dozen known ones and in addition to that automatic incarnations
(DNS?) that can be used on the fly.

guys, we have a wiki here on
<URL:http://wiki.haribeau.de/cgi-bin/wiki.pl?ProjectIM2000>, but!
this machine will be replaced this weekend.  i'll save the contents
tomorrow night.  also, i'll place a few of the longer and more
informative messages we exchanged the past days there.  if you tell
me you want to do this yourself, fine, that's actually how it's
supposed to be used.  you may want to tell me a WikiWord as a
heading, else those messages will go under your names or a
CommonTopicName, if either i can think of one or you can.

all of this will happen next week, but maybe you'll want to take a
peek at it.  at presnt, this is a sloppy usemod wiki which will be
replaced by one of Twiki.org, MoinMoin, php-wiki or even zwiki.

please don't change too much until saturday, because i can't tell
when the switch over will actually happen, and when i'll make the
final backup!

  clemens

-----BEGIN PGP SIGNATURE-----

iD8DBQE+g5z4pdlrZyFBkK8RAnUHAJ9zfjdajbt/wcr2t8Vp7zoXXlk8FgCgl+em
ylpwKQWYX9nrsR49Bm3CbaU=
=665Y
-----END PGP SIGNATURE-----