RE: Sub/Not Security, Presence service identifiers

The way the presence service identifier issue was raised in Yokohama
(following the list mail) was as follows:

7. A wrapper for presence information be defined that contains a name
   that identifies a presence service, and nothing else.

That was the idea that was opposed there - I imagine you agree that we don't
need one or those?

What we don't need is some sort of new header in 'message/cpim' bodies that
can contain an identifier for a presence service distinct from the
presentity - this would always be redundant with the subjectAltName of the
certificate that signed the notification, right? What we need is some
standard way for the recipient of a notification to inspect the
subjectAltName of the certificate of the signator and the URI to which they
had subscribed (in your example 'pres:[email protected]'), and then to
determine if the two correspond. The way in which the From header, the
'presence entity' tag in the PIDF and the subjectAltName should all
correspond in some fashion to the URI to which the watcher subscribed is the
important reference integrity property here. A failure of any of these to
correspond should be taken be the recipient of the notification as a cause
for security concern, at least.

So how should this correspondence work? You suggest that the subjectAltName
should be identical to the contents of the From header field - neither of
which corresponds directly to the URI to which the watcher had subscribed
(only the 'presence entity' tag does). So what grants a presence service
authority over the URI to which the watcher subscribed? You suggest that we
standardize a reserved user, 'notifier' in the domain of the URI of the
presentity, and assume that this user has authority over all users in the
domain. Which begs a few questions for me:

- I'm not really clear why we need to ascribe presence identities (with
usernames) to presence services - they are not presentities themselves. As a
litmus test, what would happen if you sent a subscription to
'pres:[email protected]'?

- Relying on a naming convention as an assurance of authority, like a
reserved username of 'notifier', is in my experience discouraged by the
security community. PKI enrollment is problematic - why would any
certificate provider prevent a badguy from getting a
'pres:[email protected]' certificate (since CAs will probably not be aware
of this specialized usage)? Which CA (if any) us authoritative over the PRES
URI namespace? What if my email username at mitre.org (or, maybe more
plausibly, yahoo.com), which is therefore also my desired IM/PRES URI
username, is already 'notifier'?

- And why does the subjectAltName of a certificate issued by a presence
service need to contain a pres:user@host subject rather than a domainname?
In my experience, a subjectAltName in a certificate used on the web today is
not structured like a an RFC822 identifier, it is structured like a
domainname (i.e mitre.org or www.mitre.org). Consider that using normal web
certificates (authoritative for mitre.org, say) could re-use existing CA
systems for enrollment. Wouldn't this be a better way to represent a
presence service? Shouldn't the holder of the mitre.org certificate be
authoritative for [email protected] (regardless of the URI scheme)?

I don't think we disagree about the requirements here, just the proposed
mechanism. We both think there should be a way for the recipient of a
notification to understand that the notification was created by a party that
is authoritative for the PRES URI to which the subscription was sent. This
is not a trivial problem, as we said in Yokohama. I just don't think that
presence service identifiers, as far as I understand your proposal in 7.
above, provide an appropriate solution.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, August 16, 2002 10:50 AM
> To: Peterson, Jon
> Cc: '[email protected]'
> Subject: Re: Sub/Not Security, Presence service identifiers
> 
> 
> Jon,
> 
> When thinking about the question posed in
> 
>    http://www.imppwg.org/ml-archive/IMPP-WG/200208/msg00003.html
> 
> imagine that the subject that pres:[email protected] identifies is a
> good and honorable MITRE employee who has had their laptop stolen.
> You don't want to have presence service for all of MITRE subverted
> just because one employee lost their laptop.  This demonstrates one
> needs an identity for each presence service.
> 
> John
> 
> [email protected] (John D. Ramsdell) writes:
> 
> > "Peterson, Jon" <[email protected]> writes:
> > 
> > ...
> > 
> > > I also take it from recent list discussion that there is not a
> > > demonstrated need for a presence service to have an explicit
> > > identifier in a notify operation.
> > 
> > How do you expect a client to answer the question posed in
> > 
> >   http://www.imppwg.org/ml-archive/IMPP-WG/200208/msg00003.html
> > 
> > Which instant inbox are you going to use and why?
> > 
> > John
> > 
> > 
> > 
> >   [reminder: [email protected] for non-technical 
> discussions, please]
> 



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