RE: [Standards] dialback: piggybacking
I don't know. Although it's confusing as hell to the first time implementer, this is pretty common practice in current implementations. Small scale servers like Google Talk make extensive use of it from what I recall... :) Jabberd used to do it as well (though I can't confirm that with recent editions). -JD > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Chris Mullins > Sent: Friday, June 15, 2007 6:11 PM > To: XMPP Extension Discussion List > Subject: RE: [Standards] dialback: piggybacking > > [Removing Piggybacking] > > +1 on removing piggybacking. > > In fact, change that: > +3E8 > +Avogadro's Number > +Graham's Number > +Skewes first, second and third number > > ... This has caused so much grief, and so many bugs, that eliminating > it > would be a great thing. > > The poor guy here who maintains our S2S code will probably throw a > party > when this happens! > > -- > Chris Mullins
RE: [Standards] dialback: piggybacking
[Removing Piggybacking] +1 on removing piggybacking. In fact, change that: +3E8 +Avogadro's Number +Graham's Number +Skewes first, second and third number ... This has caused so much grief, and so many bugs, that eliminating it would be a great thing. The poor guy here who maintains our S2S code will probably throw a party when this happens! -- Chris Mullins
Re: [Standards] compliance: cert(s)
Peter Saint-Andre wrote: Mridul Muralidharan wrote: Justin Karneges wrote: On Thursday 14 June 2007 2:59 pm, Peter Saint-Andre wrote: Would it be appropriate to recommend that client and server developers bundle support for the root certificate under which the XMPP ICA issues domain certificates? The XSF is not in a position to vouch for the trustworthiness of a certificate authority. +1 The XSF runs the XMPP Intermediate Certification Authority, so I'd hope we can trust it. We do not run the root CA upon which the XMPP ICA depends. ICA has value since it provides as easy way to obtain an xmpp certificate with the oid defined ... which is usually a pain. But this is just based on top of startcom - and the trust for startcom should come from web of trust, not because xsf vouches for it. So xmpp ica is as trust worthy as startcom ca is. If tomorrow we support other ca's, or possibly move away from ica, the protocol spec would still remain unchanged, and tls's web of trust will take care of certificate verification (for people with ocsp enabled for example). Which is why I mentioned that we could have a wiki of a page which talks about how deployers/admins (not developers) can obtain xmpp certificates (we do not have client certs there do we ?) from xca and point a link from protocol to that page as 'helpful info'. This could then be referenced by developers, admin and deployers; while we could keep it up to date more easily. > At best, you could cite some other organization as being the basis of the recommendation. For example, a XEP could claim that StartCom is WebTrust-certified, and is therefore generally accepted as trustworthy for economic usage over the open internet. That said, I think making a recommendation like this is mostly redundant. Yes, if it is trusted, most keystores will already include it as a ca by default. The certificate for the root CA is included in the Mozilla store, the store on various flavors of Linux as well as Mac OS X 10.5. I do not know when it might be included on Windows. Not yet the last time I checked. Mridul Peter
Re: [Standards] Removing PEP nodes?
On Jun 15, 2007, at 22:35, Peter Saint-Andre wrote: Why not? You should have received it when the PEP service sent it to you (the account owner automatically receives a copy). Hmmm no, the experimental implementation for ejabberd (the only one available right now) doesn't do this. Oh well, I guess I have to wait for an official one. andy
Re: [Standards] compliance: cert(s)
Matthias Wimmer wrote: Hi Peter! Peter Saint-Andre schrieb: You also won't find any recommended CA in RFC 2818 (HTTP over TLS). Certificates for websites don't include specialized OIDs, either. Well dNSName is some sort of specialized OID for websites (and other services using the same addressing sceme 'domains'). The id-on-xmppAddr is also not a special OID for XMPP, but an OID for any service sharing the same address space (e.g. my SMS service shares the address space with my Jabber server and e.g. if I would authenticate the SMS clients using X.509 certificates, I would have to use id-on-xmppAddr as well. How do you suggest we make server developers aware that it's a good idea to bundle the XMPP ICA cert and StartCom root cert (and for client developers the root cert)? Do we really have to make them aware of? The fact that the XSF runs the ICA and that many servers in Jabber space already use certificates from there should make server developers aware enough about the existence of the StartCom CA and that it is good to bundle this CA. So well my "problem" might be, that I do not see any need to make developers more aware of the existence as they already are. Sure, I see your point. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] compliance: cert(s)
Hi Peter! Peter Saint-Andre schrieb: >> You also won't >> find any recommended CA in RFC 2818 (HTTP over TLS). > > Certificates for websites don't include specialized OIDs, either. Well dNSName is some sort of specialized OID for websites (and other services using the same addressing sceme 'domains'). The id-on-xmppAddr is also not a special OID for XMPP, but an OID for any service sharing the same address space (e.g. my SMS service shares the address space with my Jabber server and e.g. if I would authenticate the SMS clients using X.509 certificates, I would have to use id-on-xmppAddr as well. > How do you suggest we make server developers aware that it's a good idea > to bundle the XMPP ICA cert and StartCom root cert (and for client > developers the root cert)? Do we really have to make them aware of? The fact that the XSF runs the ICA and that many servers in Jabber space already use certificates from there should make server developers aware enough about the existence of the StartCom CA and that it is good to bundle this CA. So well my "problem" might be, that I do not see any need to make developers more aware of the existence as they already are. Matthias -- Matthias Wimmer Fon +49-700 77 00 77 70 Züricher Str. 243Fax +49-89 95 89 91 56 81476 Münchenhttp://ma.tthias.eu/
Re: [Standards] compliance: cert(s)
Matthias Wimmer wrote: Hi Justin! Justin Karneges schrieb: The XSF runs an ICA, but that alone is not enough of a reason for XMPP developers and users to trust it. The reason the XMPP ICA is interesting is because it is under StartCom control, and StartCom is widely trusted. To better understand what I mean, just imagine if the XMPP CA was an independent root CA. The value comes not from the XSF's booming voice, but from StartCom. :) Anyway, there's nothing wrong with having a recommendation, and I see you've already published new versions of the XEP with it. However, it does come off as an advertisement, which is a strange thing to have in a XEP. You could just as well advertise Equifax, I'm sure they have a number of XMPP domain certificates issued too. Right, bundling does have value. The Psi 0.11 release candidate ships the StartCom root, for example. However, Psi only does this because Mozilla does this. Really, it is important here to realize who is in a position to vouch for trust. XSF and Psi are unable do this, but the Mozilla Foundation is, and so that's the authority Psi draws from, *not* any XSF recommendation. +3 ... one for each chapter ... While I do bundle the StartCom root certificate with jabberd14 as well, I also do not do this because of any XEP. I never said that was the reason to bundle it it. Me as well, I would consider it at least very strange if any XEP advertizes or recommends any certification authority. You can use any CA you want. It's just that for Jabber servers the XMPP ICA makes life easier for server admins. You also won't find any recommended CA in RFC 2818 (HTTP over TLS). Certificates for websites don't include specialized OIDs, either. How do you suggest we make server developers aware that it's a good idea to bundle the XMPP ICA cert and StartCom root cert (and for client developers the root cert)? Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Removing PEP nodes?
Andreas Monitzer wrote: On Jun 15, 2007, at 20:07, Peter Saint-Andre wrote: Andreas Monitzer wrote: Hi, I'm currently implementing PEP into libpurple, and have some issue I can't quite find explained in the XEPs: How do I remove a personal event? I think you would use the syntax defined in XEP-0060: http://www.xmpp.org/extensions/xep-0060.html#publisher-delete What should I supply as the item id? I don't have that value. Why not? You should have received it when the PEP service sent it to you (the account owner automatically receives a copy). /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] compliance: cert(s)
Hi Justin! Justin Karneges schrieb: > The XSF runs an ICA, but that alone is not enough of a reason for XMPP > developers and users to trust it. The reason the XMPP ICA is interesting is > because it is under StartCom control, and StartCom is widely trusted. To > better understand what I mean, just imagine if the XMPP CA was an independent > root CA. The value comes not from the XSF's booming voice, but from > StartCom. :) > Anyway, there's nothing wrong with having a recommendation, and I see you've > already published new versions of the XEP with it. However, it does come off > as an advertisement, which is a strange thing to have in a XEP. You could > just as well advertise Equifax, I'm sure they have a number of XMPP domain > certificates issued too. > > Right, bundling does have value. The Psi 0.11 release candidate ships the > StartCom root, for example. However, Psi only does this because Mozilla does > this. Really, it is important here to realize who is in a position to vouch > for trust. XSF and Psi are unable do this, but the Mozilla Foundation is, > and so that's the authority Psi draws from, *not* any XSF recommendation. +3 ... one for each chapter ... While I do bundle the StartCom root certificate with jabberd14 as well, I also do not do this because of any XEP. Me as well, I would consider it at least very strange if any XEP advertizes or recommends any certification authority. You also won't find any recommended CA in RFC 2818 (HTTP over TLS). Matthias -- Matthias Wimmer Fon +49-700 77 00 77 70 Züricher Str. 243Fax +49-89 95 89 91 56 81476 Münchenhttp://ma.tthias.eu/
Re: [Standards] Removing PEP nodes?
On Jun 15, 2007, at 20:07, Peter Saint-Andre wrote: Andreas Monitzer wrote: Hi, I'm currently implementing PEP into libpurple, and have some issue I can't quite find explained in the XEPs: How do I remove a personal event? I think you would use the syntax defined in XEP-0060: http://www.xmpp.org/extensions/xep-0060.html#publisher-delete What should I supply as the item id? I don't have that value. andy
Re: [Standards] compliance: cert(s)
Justin Karneges wrote: On Friday 15 June 2007 11:03 am, Peter Saint-Andre wrote: Mridul Muralidharan wrote: Justin Karneges wrote: On Thursday 14 June 2007 2:59 pm, Peter Saint-Andre wrote: Would it be appropriate to recommend that client and server developers bundle support for the root certificate under which the XMPP ICA issues domain certificates? The XSF is not in a position to vouch for the trustworthiness of a certificate authority. +1 The XSF runs the XMPP Intermediate Certification Authority, so I'd hope we can trust it. We do not run the root CA upon which the XMPP ICA depends. The XSF runs an ICA, but that alone is not enough of a reason for XMPP developers and users to trust it. The reason the XMPP ICA is interesting is because it is under StartCom control, and StartCom is widely trusted. To better understand what I mean, just imagine if the XMPP CA was an independent root CA. The value comes not from the XSF's booming voice, but from StartCom. :) Anyway, there's nothing wrong with having a recommendation, and I see you've already published new versions of the XEP with it. However, it does come off as an advertisement, which is a strange thing to have in a XEP. You could just as well advertise Equifax, I'm sure they have a number of XMPP domain certificates issued too. The XEP says that developers "should consider" bundling it. That's a pretty weak suggestion and it is in the implementation notes without all-caps conformance language. Use your best judgment about how to proceed. /psa smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] compliance: cert(s)
On Friday 15 June 2007 11:03 am, Peter Saint-Andre wrote: > Mridul Muralidharan wrote: > > Justin Karneges wrote: > >> On Thursday 14 June 2007 2:59 pm, Peter Saint-Andre wrote: > >>> Would it be appropriate to recommend that client and server developers > >>> bundle support for the root certificate under which the XMPP ICA issues > >>> domain certificates? > >> > >> The XSF is not in a position to vouch for the trustworthiness of a > >> certificate authority. > > > > +1 > > The XSF runs the XMPP Intermediate Certification Authority, so I'd hope > we can trust it. We do not run the root CA upon which the XMPP ICA depends. The XSF runs an ICA, but that alone is not enough of a reason for XMPP developers and users to trust it. The reason the XMPP ICA is interesting is because it is under StartCom control, and StartCom is widely trusted. To better understand what I mean, just imagine if the XMPP CA was an independent root CA. The value comes not from the XSF's booming voice, but from StartCom. :) Anyway, there's nothing wrong with having a recommendation, and I see you've already published new versions of the XEP with it. However, it does come off as an advertisement, which is a strange thing to have in a XEP. You could just as well advertise Equifax, I'm sure they have a number of XMPP domain certificates issued too. > The certificate for the root CA is included in the Mozilla store, the > store on various flavors of Linux as well as Mac OS X 10.5. I do not > know when it might be included on Windows. Right, bundling does have value. The Psi 0.11 release candidate ships the StartCom root, for example. However, Psi only does this because Mozilla does this. Really, it is important here to realize who is in a position to vouch for trust. XSF and Psi are unable do this, but the Mozilla Foundation is, and so that's the authority Psi draws from, *not* any XSF recommendation. -Justin
[Standards] UPDATED: XEP-0212 (XMPP Basic Server 2008)
Version 0.4 of XEP-0212 (XMPP Basic Server 2008) has been released. Abstract: This document defines the XMPP Basic Server 2008 compliance level. Changelog: Per community discussion, changed XMPP Core and XMPP IM references back to RFCs with recommendation for developers to also consult bis drafts; added reference to XEP-0178; suggested bundling of root and intermediate certificates for XMPP ICA. (psa) CVS Diff: [currently unavailable] URL: http://www.xmpp.org/extensions/xep-0212.html
[Standards] UPDATED: XEP-0211 (XMPP Basic Client 2008)
Version 0.4 of XEP-0211 (XMPP Basic Client 2008) has been released. Abstract: This document defines the XMPP Basic Client 2008 compliance level. Changelog: Per community discussion, changed XMPP Core and XMPP IM references back to RFCs with recommendation for developers to also consult bis drafts; added reference to XEP-0178; suggested bundling of root certificate for XMPP ICA. (psa) CVS Diff: [currently unavailable] URL: http://www.xmpp.org/extensions/xep-0211.html
Re: [Standards] compliance: cert(s)
Tomasz Sterna wrote: Dnia 14-06-2007, czw o godzinie 17:59 -0700, Justin Karneges napisał(a): For example, a XEP could claim that StartCom is WebTrust-certified, and is therefore generally accepted as trustworthy for economic usage over the open internet. And what if StartCom isn't trustworthy anymore, goes out of bussines or anything? Would we change the XEP then? Sure, why not? Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] Removing PEP nodes?
Andreas Monitzer wrote: Hi, I'm currently implementing PEP into libpurple, and have some issue I can't quite find explained in the XEPs: How do I remove a personal event? I think you would use the syntax defined in XEP-0060: http://www.xmpp.org/extensions/xep-0060.html#publisher-delete Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
Re: [Standards] compliance: cert(s)
Mridul Muralidharan wrote: Justin Karneges wrote: On Thursday 14 June 2007 2:59 pm, Peter Saint-Andre wrote: Would it be appropriate to recommend that client and server developers bundle support for the root certificate under which the XMPP ICA issues domain certificates? The XSF is not in a position to vouch for the trustworthiness of a certificate authority. +1 The XSF runs the XMPP Intermediate Certification Authority, so I'd hope we can trust it. We do not run the root CA upon which the XMPP ICA depends. > At best, you could cite some other organization as being the basis of the recommendation. For example, a XEP could claim that StartCom is WebTrust-certified, and is therefore generally accepted as trustworthy for economic usage over the open internet. That said, I think making a recommendation like this is mostly redundant. Yes, if it is trusted, most keystores will already include it as a ca by default. The certificate for the root CA is included in the Mozilla store, the store on various flavors of Linux as well as Mac OS X 10.5. I do not know when it might be included on Windows. Peter -- Peter Saint-Andre XMPP Standards Foundation http://www.xmpp.org/xsf/people/stpeter.shtml smime.p7s Description: S/MIME Cryptographic Signature
[Standards] Removing PEP nodes?
Hi, I'm currently implementing PEP into libpurple, and have some issue I can't quite find explained in the XEPs: How do I remove a personal event? For example, the user published his/her mood using XEP-0107. Now he/ she wants to remove this information, without overriding it with a new mood. My guess is that it could look like this: Maybe I missed it, but I couldn't find that info anywhere in XEP-0107 nor in XEP-0163. XEP-0060 considers this syntax to be incorrect, but the situation is quite different there (I can't use , since I don't have an id). What is the correct way to do that? andy
Re: [Standards] compliance: cert(s)
Dnia 14-06-2007, czw o godzinie 17:59 -0700, Justin Karneges napisał(a): > For example, a XEP could claim that StartCom is > WebTrust-certified, and is therefore generally accepted as trustworthy > for economic usage over the open internet. And what if StartCom isn't trustworthy anymore, goes out of bussines or anything? Would we change the XEP then? -- Tomasz Sterna Xiaoka Grp. http://www.xiaoka.com/
Re: [Standards] Hop Check reconnects
On Fri Jun 15 10:50:52 2007, Ian Paterson wrote: 4. If my server's encrypted connections with my contact's server go down and are replaced by unencrypted connections. Reading through XEP-0219, I'm left wondering about a few things. First off, Ian's point 4 above seems to be on the mark - we don't care if the hops were encrypted when we asked, we care if they're encrypted now. Second, I'm not sure we normally care which links are not encrypted - we care if all of them are or not. The mechanism described in XEP-0219 might help an experienced user detirmine where the fault lay, and can be used to answer the question, but it's a lot of information to go through to answer a boolean question. Thirdly, some of this information ought to be kept private. Something is nagging me that including the SASL mechanism used for authentication is probably not a good idea. I think there's probably more than the obvious case that knowing a hop uses no mutual authentication allows an attacker to scan for potential spoofing victims. I'm pretty sure that the network addresses should be omitted, too. I had a quick chat with Ian about whether we might distribute encryption information in presence - such that servers implementing the extension would alter presence stanzas en-route to contain an overall indicator of the encryption state of the path - but not only does Ian disagree, but I've also realized that this doesn't solve the issue either. I think some mechanism for maintaining a path-state database is useful, though, and to my mind, adding this information to presence remains the obvious way to do it. But we want to also know that a stanza sent to a specific destination will only go across encrypted links, and the only way I can see to do that would be to attach that requirement to the stanza itself, presuambly as an attribute on the stanza. Neither fiddling with presence, nor new top-level stanza attributes, are particularly popular, of course, with good reason, but I think the need might justofy the cost in this instance. Dave. -- Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED] - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
[Standards] Hop Check reconnects
Quoting XEP-0219: > As a user, I may want to know three things: > 1. If my connection to my server is encrypted. > 2. If my server's connection to my contact's server is encrypted. > 3. If my contact's connection to their server is encrypted. I'd add a fourth item: 4. If my server's encrypted connections with my contact's server go down and are replaced by unencrypted connections. This could occur, for example, if a man-in-the-middle disrupts the communication channels and then removes the elements from the servers' subsequent attempts to reconnect. At first glance this is harder to implement, but without it AFAICT hop-check isn't secure (even if you trust the servers). Servers could implement this by remembering all the servers they have connected securely to and never again accepting insecure connections with those servers. That way they would never have to inform their clients about the change in circumstances. Or we could add a requirement to XEP-0219 that all servers supporting Hop Check MUST in all cases employ server-2-server connections only if they are encrypted. In fact perhaps that requirement could be included in RFC 3920bis? - Ian
