Re: On trusting presence intermediaries

"real work" has kept me away from IETF stuff for the most part, so I am 
now catching up on quite a lot of email, including this very long 
thread. I *think* that it is resolved, with the resolution being no 
change, but I want to put my quick two cents in to support that resolution.

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. 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. 
Whether I trust that some entity foo (as identified in the 
SubjectAltName of the cert in the notification) can sign presence 
documents for some presentity pres:bar is a matter of *policy*, and 
therefore not subject to standardization, at least not within the 
confines of this working group. I would expect most devices would 
support a policy that states that mitre.org can sign for 
pres:[email protected]. I can even envision policies that allow 
for me to trust users to sign for other presentities - for example, my 
friends would trust presence documents for me 
(pres:[email protected]) signed by dynamicsoft.com, myself 
([email protected]) or my wife.

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.

I agree with the consensus that there is no need for a timestamp for 
when the notification is sent. I think Jon summarized the arguments in 
favor of this position nicely.

Thanks,
Jonathan R.


Mark Day wrote:
>>While this issue is straightforward for instant messaging, presence
>>presents problems.  In my opinion, a certificate should contain
>>subject alternative names that identify subjects in an actual system,
>>not the ones in the model defined in RFC 2778.  For example, if one
>>server is signing all presence information that comes from one domain,
>>I believe it should have one identifier that allows it to perform
>>this, and only this function.  There is nothing new here, we've
>>already been over this.
> 
> 
> We have indeed "already been over this" but I'm not sure we've ever
> established with any precision the answer to the following question:
> 
> Why is it important to support an implementation in which one server signs
> all presence information from one domain?
> 
> It's not clear to me why that's an especially desirable arrangement (the
> actual trust implications are somewhat obscure to me), but I'm not claiming
> any special expertise on the point.  Even if the answer is painfully obvious
> to you, I suspect that I and others would benefit from a somewhat more
> detailed explanation.
> 
> --Mark
> 
> 
> 
> 
> 
> 
>   [reminder: [email protected] for non-technical discussions, please]
> 


-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email protected]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com




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