RE: On trusting presence intermediaries

Brief notes below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email protected]]
> Sent: Thursday, September 05, 2002 1:01 AM
> To: Mark Day
> Cc: John D. Ramsdell; [email protected]
> Subject: Re: On trusting presence intermediaries
> 
[snip]
> I do believe its valuable to have the notion of a server in the network 
> somewhere that is generating presence information on behalf of 
> principals in its domain; in fact, I believe this the common case.

Whether or not we call that server a 'presentity' or a 'presence service'
was really what most of the discussion was about.

> In 
> this case, I agree with the conclusion that the identity of this server 
> is contained in the SubjectAltName of the cert, and not in some other 
> header. I agree with Jon that it would probably be something like a 
> domain name (mitre.org).
> 
> I believe the disconnect we saw here was that John R. believed that 
> there needed to be an algorithmic mapping from the identity in the 
> SubjectAltName to the URIs for the presentities that they are permitted 
> to sign for, whereas others disagreed that such a mapping was needed or 
> in scope. I believe that there should not be an algorithmic mapping. 

It's not the algorithmic mapping that isn't in scope - it's the architecture
that something other than a presentity signs the request that is out of
scope. But that much said, supporting that architecture...

[snip]
> 
> All that is necessary from IMPP is that we can convey the identity of 
> the signer, and the identity of the presentity that the presence 
> document describes. The former is obtained from the SubjectAltName of 
> the cert, and the latter, from the PIDF. Thus, no changes are needed.
> 

... really doesn't require any changes to CPIM as a protocol anyway. I was
planning on throwing in some language on name subordination (which I'm
informed is the security term d'arte for this 'algorithmic mapping'
property) in the CPIM spec when we sharpen the security story in there; I
think it will give John the security property he wants. What we will avoid
is validating an architecture in which there is no end-to-end security of
notifications, since RFC2779 requires such security.

[snip]



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