Re: Definition of the pres: URI in impp-pres-01

This is getting off topic, but...

Jonathan Rosenberg <[email protected]> writes:

> Well, there are many tricky issues lurking in such a solution.
> 
> First and foremost is security. If we want to provide end-to-end
> encryption of the presence document, how would that be done? Would we
> need to somehow create and manage group shared keys? Egads! Would you
> need to encrypt it N times, one for each watcher? That defeats the
> purpose of your mechanism. Would we need to forsake e2e security? I
> hope not.

You could encrypt it the PGP way.  You create a random session key,
encrypt the presence document in that key, then you encrypt the
session key for each recipient.

> Secondly is authorization. What if the presentity wishes for one of
> those watchers to receive the presence document, but not others? Or,

The presentity includes the list of the watchers in the message, so it
can say which watchers should get the message.  If you want these five
watchers to get it and those other five not, then you only include the
former in the "to" field.

> if it wishes for one of them to receive one subset of the presence
> information, and another to receive a different subset?

_THIS_ is certainly a troublesome issue.  Is this actually done
in real systems?  I can understand the theoretical nature of
the question.

> The model you are discussing also seems to imply a different
> architecture. There is a bunch of clients, a local aggregation server
> of sorts, and a presence server managing the presentity. Our current
> CPP protocol is built for the more simple case of a client and a
> presence server. There is no notion of this third intermediary, which
> seems like it would need to be incorporated into the protocol.

I know the CPIM architecture certainly went client - server - server -
client; I clearly missed the dichotomy of architectures when this was
split into CPP.  I must look closer.

> A problem, yes. It is definitely something you need to help
> scalability in very large systems. But, its significant security
> implications imply its usage in very specific situations where there
> is strong trust between the two domains. I do not think it is ever
> practical in the inter-domain case you describe above.

I'm not so sure.  I think it works fine in MOST situations, even with
end-to-end security requirements...  Except in the case where you want
to send "different" presence documents to different people.  In that
case you need to send multiple documents, so you may as well send
multiple messages.  However, I still believe that the "normal" case is
sending the same document to all your watchers.

> Even if it was practical, it certainly seems like something which is
> beyond the 'baseline' model we have been following for CPIM/CPP all
> along.

*sigh*  Yes, I know.

> -Jonathan R.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email protected]                        PGP key available



  [reminder: [email protected] for non-technical discussions, please]