Re: On the need for presence service identifiers

"Peterson, Jon" <[email protected]> writes:

> We could also admit of an alternative architecture, as you have
> encouraged us to, in which some other entity than [email protected]
> signs the presence information. This introduces complications for
> us, and makes our life slightly harder, because it would require us
> to have some other rule for the watcher to determine if the
> signature matches the URI to which they subscribed. This model would
> ignore the end-to-end security requirements for notification
> presented in RFC2779, but we can entertain it nervertheless for the
> time being. However, I doubt there is a possible rule in which the
> watcher would be assisted by some header that provided information
> about the presence service - at best, that header would be redundant
> with the subjectAltName of the cert.  

Agreed.  The current idea is that a presence service identifier will
only appear in the subjectAltName of an X.509 certificate.  No other
part of the protocol will use it, and systems not using X.509
certificates will never see it.

> Therefore, the real question is how the subjectAltName of the cert
> would be structured for the presence service. You argue that it
> should be a URI, and therefore you need some elaborate way of
> explaining the fact that this URI isn't the same URI to which the
> watcher subscribed - I countered that a domainname seemed adequate
> and didn't suffer from this problem.

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?

> The point is that there is no security property that is wanting if
> there is no separate identifier for a presence service. No bad guy
> can forge presence information generated by the presentity if we
> assume the 'equality' rule I describe above (that the signator of
> notifications must be the same as the URI to which one subscribed).
>
> If we allow that some third-party can generate presence information
> on behalf of the presentity (which neither 2778 or 2779 seem to
> endorse), then we would have to come up with some other rule (like,
> the domainname in the subjectAltName of the certificate (mitre.org)
> must be identical to the domainname of the URI
> (pres:[email protected]) to which the watcher subscribed, say). If
> you want to call that domainname a 'presence service identifier',
> then sure, the subjectAltName of a certificate would contain one of
> those. But none of this particularly argues that either URIs for
> presence services (with or without username conventions), or From
> headers in some sort of wrapper around presence information in
> notifications, are required. All of these are at best redundant to
> existing security properties. 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.

John



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