RE: On trusting presence intermediaries

"Adrian Bateman" <[email protected]>
Newsgroups gmane.ietf.impp
Organization VisionTech Limited
Message-ID <00bf01c24f8a$e6fa26f0$6405010a@ADRIANXP>
On 29 August 2002 18:44, 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.

Do we need to cover this again? I'm concerned about quotes like "in an
actual system, not the ones in the model defined in RFC 2778". If it is
covered, surely it should be in terms of our requirements? I asked
before for a clarification in terms of which parts of RFC 2779 require
us to do this but I don't think one has been forthcoming to this point.

Adrian.
smime.p7s (application/x-pkcs7-signature, 3.1 KB) - not displayed
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.