Justin Karneges wrote: > On Tuesday 03 March 2009 11:05:25 Peter Saint-Andre wrote: >> My question is, where does the definition of XLTS really belong? >> >> It feels odd *not* to define it in XEP-0166, since that is the core >> Jingle spec and the addition of security contexts changes how sessions >> are negotiated. > > I think it's fine to put the transport security bits into XEP-0166.
That feels like the right approach to me (why send someone off to an I-D or RFC to read about Jingle Security when they're reading XEP-0166?). > I also suggest dropping the term "XTLS". That name used to have a meaning, > but today it is misleading, and I don't think we need a special name anyway. Yeah, probably. I used it here to provide continuity, but I agree that it is confusing because specifying transport security preconditions in Jingle is not analogous to DTLS (the only other *TLS technology that I know of). > Security in Jingle can simply be called just that: Jingle Security. Or > Jingle Transport Security. Whatever name you happen to use for the new > section in XEP-0166. :) Right. I think "Transport Security Preconditions" is fine. Then we need each transport definition to specify how it handles those. >> On the other hand, if we define security contexts in an Internet-Draft >> then it is more likely to receive proper security review within the >> IETF. However, at that point it seems that we might be bringing in a >> whole raft of dependencies. Perhaps that is manageable (I don't think >> it's appropriate to suddenly move all of the Jingle specifications to an >> XMPP WG!), but I want to make sure that we can manage this work in such >> a way that we receive the proper security reviews for XTLS without >> burdening the IETF with masses of new work. > > No matter how you slice it, anyone doing a security review will have to read > the whole of Jingle. Well, at least they would need to understand XEP-0166 and look at how several of the various transport specs handle security preconditions. > So unless you plan to publish the entire thing as IETF > material, Not a good idea, I think. > I'd say it doesn't matter much what you do otherwise (such as > publishing just an e2e XML streams spec). It would certainly make draft-meyer-xmpp-e2e-encryption quite a bit shorter. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
