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