Re: On the need for presence service identifiers

"Adrian Bateman" <[email protected]> writes:

> On 20 August 2002 13:16, John D. Ramsdell wrote:
> > One way to correctly answer this question is to use the convention 
> > that a PRES URI's identifies a presence service if and only if it's 
> > local part is the string "notifier".  Of course, there are other 
> > conventions that can be used to distinguish presence service 
> > identifiers.
> 
> And another is to expect that the message is signed by a key associated
> with 'pres:[email protected]' where the signature includes the Datetime
> header in which case the From address isn't relevant. Either the
> presence document signature is valid (and matches the entity attribute)
> including the appropriate timestamp so the document is trusted, or it
> isn't and it is discarded or whatever.

Let's follow Adrian's suggestion and imagine that presence services
use presentity identifiers in their 'From' header.  There are two
cases: (1) the presence service is allowed to sign messages using the
presentity identifier, or (2) it can only pass along presence
information signed by the owner of the presence information.

Let's look at case 2 first.  Suppose a client fetches presence
information from a presentity.  Since the signed content of the
presence information is fixed a creation time, it cannot include a
timestamp that indicates when the presence service sent the
notification.  A spoofing presence service can simply send old
information thereby misleading a client.  Clearly, a timestamp
indicating when the presence service acted must be part of the signed
content, and therefore, a presence service must sign content.

For case 1, there are two possibilities: (a) the presence service and
a user share a private key, or (b) the presence service has it's own
certificate and private key for each user.  In other words, there are
two certificates for each presentity.

Case (a) is a non-starter.  No security conscious site is going to let
more than one subject use the same private key.

Case (b) presents a logistics problem, especially for presence
services that support a large number of users.  A presence service
must maintain an up-to-date database of keys and certificates and the
certificates must match the user's.  Worse yet, when a user changes
their certificate, the organization must remember to update the
presence server's certificate too.  This solution is a looser.

If you give a presence service an identity, only one is needed.
Furthermore, it can be deemed as the only legitimate provider of
presence service.

John



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