RE: On the need for presence service identifiers

More promising - I think we may be honing in on a few important points here.
Some responses below. Before I speak to them, though, I wanted to note the
following from the Security Expectations Appendix in RFC2779:

A5. A can tell the difference between a message generated by the
   user, and a message legitimately generated by the agent on behalf of
   the user.

       Discussion: This could be quite difficult to enforce and could
       unduly restrict usage scenarios; this is omitted from the
       requirements.

I believe that this indicates that during the design of RFC2779, some
consideration was given to whether or not there needed to be a way to
distinguish between a presentity identity and a 'presence service identity'
(in keeping with how I believe Mr. Ramsdell intends the term 'presence
service') as generators/senders of presence data - however, the authors of
RFC2779 seem to indicate here that this is not a requirement. A number of
these other rejected Security Expectations are also interesting (like A7,
which may shed some light on why the string 'replay protection' doesn't
appear in RFC2779).

More below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Wednesday, August 21, 2002 7:42 AM
> To: Peterson, Jon
> Cc: [email protected]
> Subject: Re: On the need for presence service identifiers
> 
>
[snip]
> 
> I agree that essential content of a presence service identifier is a
> domain name.  The choices for elements in a subjectAltName are:
> otherName, rfc822Name, dNSName, x400Address, directoryName,
> ediPartyName, uniformResourceIdentifier, iPAddress, registeredID.  I
> chose to use a URI that has the domain name as its scheme specific
> part.  Would you like to suggest an alternative?
> 

In a previous mail I thought I had identified one already - dNSName.

The justification that I offered for this choice over a pres URI (even a URI
of the form 'pres:domainname') was enrollment. Today, it is very common for
mitre.org to possess a certificate for 'mitre.org'. If you go to a CA and
ask for a site certificate, that are rules that dictate whether or not you
will be issued that certificate that are well understood. There are no such
rules or practices today (to my knowledge, anyway) for certificates bound to
a 'pres' URI. It isn't clear that any CA would have proper policies to
handle enrolling new parties into the PKI that would prevent bad guys from
getting certificates.

Now, we all know that such policies could be developed, and so on. The
question is, if there is something we could recommend to encode in the
subjectAltName that works with existing CA practices, shouldn't we recommend
it?

> > The point is that there is no security property that is wanting if
> > As far as I can tell, all you need is
> > to know who you subscribed to, and to look at who signs the response
> > - period.
> 
> The problem with not having a presence service identifier appears when
> a presence service is signing notifications.  In this case the server
> must maintain a private key and a certificate for each presentity it
> serves, because the presentity's URI must be in the subjectAltName of
> the presentity's certificate.
> 

And just for the record, I have spent some time questioning the need for a
presence service to sign a notification, or at least arguing that there is
an additional end-to-end requirement that must be satisfied that this
doesn't appear to meet. Although this will doubtless come through from my
other mail, I don't yet find the argument for notification-specific
timestamps convincing.

Above, on an academic point, you also seem to be saying that in the absence
of a presence service identifier, were a presence server to sign
notifications, it would have to keep private keys for each presentity that
it serves. I agree that is one possibility, yes. But I also think there are
valuable cases in which this is perfectly plausible. One important one is
when the presentity and the presence service (since they are just logical
roles) are located on the same physical device. Any case in which there is a
single presence service to a presentity would not be problematic. Again, I
get the sense that you have some architecture in mind in which a 'presence
service' is some sort of service provider like Yahoo that does the sorts of
things that Yahoo provides today in an IMPP solution - but RFC2778 means
something very modest by a 'presence service' that assumes no particular
deployment architecture.

> John
> 



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