RE: On the need for presence service identifiers

A couple of (slightly less amiable) notes below. I'm beginning to fear that
this discussion is unlikely to bear fruit.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Tuesday, August 20, 2002 7:02 AM
> To: [email protected]
> Cc: [email protected]; [email protected]
> Subject: Re: On the need for presence service identifiers
> 
[snip]
> 
> 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.
> 

Actually, this reading is quite specious.  Why on earth couldn't the signed
content already contain a timestamp that was added when the presence
information is created? Why should the timestamp correspond to the time when
the notification was sent? Surely the timestamp should reflect the time that
the presence information is known to be valid - i.e. right now, when the
presence information is being assembled. How this could 'mislead' a client
isn't clear. If you receive a notification of presence data that is three
hours old (signed by the presentity), then you know it was true three hours
ago - there's nothing particularly misleading about that. A watcher could
trivially discard information that looked 'old', if that were appropriate,
or just display it with a caveat. If a watcher had previously received more
recent presence information, it wouldn't be deceived by this out-of-order
messaging. 

Adding the timestamp later, say when a notification is generated, is
problematic for a number of reasons. If the presence information is signed
by the presentity, then a timestamp added at notification time would be
outside the signature, and thus it could be tampered with arbitrarily.
Moreover, as you have astutely pointed out, notifications could be delayed,
for whatever reason - when watchers receive presence information, I think
they are interested in when this information was true, not in when this
information happened to be communicated to them. They know when it was
communicated to them - right now, when they just received it, right? Who
cares if someone else communicated this same piece of information earlier if
it has an internal timestamp.

The sorts of straw men you're attacking are uninteresting and unpersuasive.

> 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.
> 

If the presence service and the presentity are operated by the same entity
(say, me), then case (a) is reasonable, but not terribly useful admittedly.

> 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.
> 

These problems are hardly insurmountable. They are at worst equal in
difficulty to administering any PKI.

That much said, I agree that cases (a) and (b) are both less desirable than
allowing a presentity to sign presence information themselves.

> 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.
> 

If you mean here that end users (i.e. presentities) wouldn't be permitted to
sign their own presence information, then your model directly violates
RFC2778/RFC2779. This simply isn't acceptable.

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



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