RE: Sub/Not Security, Presence service identifiers

On 20 August 2002 12:47, John D. Ramsdell wrote:
> "Adrian Bateman" <[email protected]> writes:
> 
> > Yes, I recognize the need to authenticate things as you say, but I
> > couldn't find anything in the RFC's related to the presence service.
> 
> Mark Day located the relevant quote:
> 
> 5.2.4 of RFC2779 says
> 
>    The protocol MUST provide means of protecting B from another
>    PRINCIPAL C "spoofing" notification messages about B.

Well, yes, I read that but this doesn't say anything about the presence
service being identified. It just says that there must be a way to
ensure that the message really came from B. 

> > If a presence service is in some way responsible for generating my
> > presence document based on some property such as a TCP/IP
connection, 
> > should it not have the responsibility for my presence URI, and hence

> > for being able to sign on my behalf?
> 
> It depends on what you mean by the phrase "sign on my behalf".  If you

> mean that a presence server should share your private key so that it 
> can sign documents as if it were you, this would be very bad.  A 
> private key should be used only by one subject.  Few security 
> conscious sites would allow private key sharing.

Why is this sharing? If the presence service has authority to generate
my presence document, why isn't it responsible for the private key that
represents my presence URI? If you are in an environment where you can't
trust the presence service server, then there would have to be need to
be communication to the client to request the signing, but that would be
an application implementation specific issue.

If the principal B trusts some "presence service" to deal with the
*generation* of the document, then doesn't this make the presentity and
the presence service synonymous?

Adrian.