[Standards] Proposal: Public Key pinning
Hello! Reading [1], I thought it would be neat to have the same on XMPP. The idea is that a server can pin the list of public keys that should be trusted for future connections. These contain the CA's public key, the leaf certificate's key or backup keys in case the current key is lost. This should make it easier to secure servers that use self-signed certificates (especially for s2s connections) and it can strengthen the security of servers that do use CA issued certificates. Of course, there are alternatives: * DANE. DNSSEC deployment is still low and DANE is low compared to that. Few DNS stacks include support for DNSSEC, so widespread DANE deployment is unlikely to happen soon. * SCRAM-SHA-1-PLUS can protect against MITM attacks by adversaries that don't have the user's password, but this is not a solution that would work well for s2s. * TACK [2] generalizes key pinning to a TLS extension. But that means it's probably also years away from actual deployment. * XEP-0257. I don't think this XEP matches exactly, but it comes close and could of course be adapted instead of introducing a new one. Anyway, I thought a new extension would be better, so I wrote a proposal for an extension which can be seen at [3]. It is meant to be an interim solution until DANE gets wide adoption. The format of the pins follows [1] - but it can also be seen as 2 1 1 or 3 1 1 TLSA records from DANE. In other words, much of the code written to support this can be reused for DANE. Any feedback on this proposal is very welcome. :) Regards, Thijs [1] = https://tools.ietf.org/html/draft-ietf-websec-key-pinning-08 [2] = https://tools.ietf.org/html/draft-perrin-tls-tack-02 [3] = https://xnyhps.nl/~thijs/linked/prosody/xep-cert-pinning.html signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/11/13 7:22 AM, Peter Waher wrote: > Hello Matthew > > Thanks for your response. My responses to your comments and > questions follow: > >>> I'm searching for the easiest way to make an extension >>> enabling simple tables. My thought was that the simplest way >>> (for IM client developers) was to perform add this extension >>> through XHTML-IM. Perhaps that is not so? >> >> It probably is, from a protocol perspective. I don't know if it >> is, from an implementation perspective, very simple. It depends >> what clients are using to render XHTML-IM today, and whether >> they support tables. >> >>> Would you prefer an extension dedicated to sending tabular >>> data only? >> >> That seems overkill to me in this case. Perhaps we could just >> push for (carefully) relaxing the restrictions in XEP-0071 that >> you feel prevents you from sending tables? > > This would me my preferred choice also. > >> The downside with this approach is that, although you could >> start sending tables today and be compliant, unless tables are >> documented somewhere then they won't ever be implemented in >> clients. > > True. With permission I could help write such an extension for you > all to revise. However, I would like to hear from Peter > Saint-André also, as he's the original author of the extension, if > he feels OK with this or prefers to do any additions himself. Travel and work have prevented me from reading this thread, or any others. I will try to catch up late this week. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgPxNAAoJEOoGpJErxa2pcG8P/2zwztuJC9SbAGWqUUsRTXbI rQ1a2QDpITvIuuyOPJ+gtqjJM36NkSl+dweQAYSM+3HewdTja99avECJovWWHow0 yaoVUA/E0Samcfg26CAvr16rcYsRbPRzM7rhlb19BFTQ/fcDd6fCEwHdyzqooV0f TVi9QPoogpqAFZMqAW6OgbUO+zqDCwmA2D07MzbQpOTDulwj8XrRhabXFiLGa4zN jDXU8E3R/LUd32pgReNpvDwhptKlmfUWKy+nBu5hgiFUs31LRjYpnCwrE7JO7ILc X4kVh04mtkmCxLDYLH3nb7PawE+HAlDpwq8yI1Dv2WQ168rqg93yQ1Cn86CjNqvE CQ1dINuExLPCpP+4ZoEtFAE3ECFJPWPqaN8DJ4fwNQ+A/LCbsO839iFJyXQbF37G ADuykUX5aEF5x+UYiNmj9MMhzBWJYHtheFJPZw1xp6FMNIJ7oj8JOI/W8kNBgnbD /nMBhRTsrJBLoGuYrbytAAjh23N2hq8k5xejg34T1BStHft1goOCur2ffnTJFfEe /C+KwHL6dtp4Q7uhFTKjPr/YoNxX96kK5NaokSMw1btiT/fV1tXkWub5bxH7t9gs SgpA4S4cQPioc09sYAKiUjPRJobBY4uj7hzdzM3MSGSKVPewl/jQofply/M8KWeB oQHrVK2rSaoKY7cRDsij =DU8v -END PGP SIGNATURE-
Re: [Standards] Concerns with "Data Forms - Dynamic Forms"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/29/13 12:12 PM, Peter Waher wrote: > Hello Matt > > Sorry for the late response to your concern regarding the Dynamic > Forms proposal: > >> Regarding < http://xmpp.org/extensions/inbox/dynamic-forms.html >> >, it has not yet been accepted by Council because there appear >> to be strong similarities between this and XEP-0050: Ad-Hoc >> Commands, at least as currently documented. It is requested that >> the document first be updated to discuss differences between it >> and XEP-0050 before being considered for Experimental. > > I've now updated the Dynamic Forms XEP with the following > sections: > > * Section describing the differences between Ad-Hoc commands > (XEP-0050) and Dynamic Forms. * A section describing asynchronous > server updates to forms * An implementation note on how to merge > fields during asynchronous updates. > > I hope these answer your concerns regarding the Dynamic Forms XEP. > I've attached the files to this mail. Updated in the inbox. Peter - -- Peter Saint-Andre https://stpeter.im/ -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSgPv1AAoJEOoGpJErxa2plx8QAIyV5NHAQOEg5kU3jYG2207G xfVj/nYHvLQoXghGr0UCLGiKyqVZIXrawtt8d2XCAA/bV8vZqoMyHi7lHdp3GQRZ t0/minUb4gc1JFlX0/ucOZt1CfqvsYToaioGhinAOXXiAITr85jRA5oWRCSYdDWe qNpGnmyHD9ZKr3wbwWBabOYjyLhGkjIyI6+GzJ0nT7aZiBOM12TCaTwURNsJYwB/ NqnDJ9daArIF+ADlfwDp5oMsuL+TBcQdfN10rfSuWJGTpLm4Qk22uo5iMnRm4ETm eQ8iFJOUNrfDT0aQo5oGATT6mlee0Hbs4WXXjHmZdZ4Vop9fxOFHWGmBlc40BE52 V+0H+ViPttkJUC69zASq4/qVI81quOnPuDffOL4UuAHvkkFep/epufEuwMMixPJV RWXbUY+v6wEAC8nwPFYBis+pPUBuh/sai99X/FoPEPcloD6GIgc112DR8bvJxP+M nQ7J7HeDXDi8/3g+jyhZQBqiJ0au51xbsuyyj8XDsCmrqT1warU7yF8QF5Bx9Z7c kY0fiMoOLSL15t82qYMowK22lE7PabPlApGKkOcZ0uN3H1OvPH8wJvBNyLBLwakQ is5FGwrH0n4FR+oA27750SmhzneQBSMyick2NCd8OfxfyTqQbW6B3vmLeLi7GV7E shhZRgCyYnlRyRe5UJ83 =rI5Y -END PGP SIGNATURE-
[Standards] Proposed XMPP Extension: Event Logging over XMPP
The XMPP Extensions Editor has received a proposal for a new XEP. Title: Event Logging over XMPP Abstract: This specification provides a common framework for sending events to event logs over XMPP networks. URL: http://xmpp.org/extensions/inbox/eventlogging.html The XMPP Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Re: [Standards] Suggestions for updates to XEP-0071: XHTML-IM
Hello Matthew Thanks for your response. My responses to your comments and questions follow: >> I'm searching for the easiest way to make an extension enabling simple >> tables. My thought was that the simplest way (for IM client developers) was >> to perform add this extension through XHTML-IM. Perhaps that is not so? > >It probably is, from a protocol perspective. I don't know if it is, from an >implementation perspective, very simple. It depends what clients are using to >render XHTML-IM today, and whether they support tables. > >> Would you prefer an extension dedicated to sending tabular data only? > >That seems overkill to me in this case. Perhaps we could just push for >(carefully) relaxing the restrictions in XEP-0071 that you feel prevents you >from sending tables? This would me my preferred choice also. >The downside with this approach is that, although you could start sending >tables today and be compliant, unless tables are documented somewhere then >they won't ever be implemented in clients. True. With permission I could help write such an extension for you all to revise. However, I would like to hear from Peter Saint-André also, as he's the original author of the extension, if he feels OK with this or prefers to do any additions himself. >> If that is the general consensus, I can write and propose such an extension. > >Are there any other things you find lacking in XEP-0071? If so, perhaps some >"Extended XHTML-IM" XEP would be in order? My personal needs regarding XHTML-IM is the following: 1) Very basic table support. The need is really to be able to output tabulated text. Nothing more fancy than that. If there's an option to left, center or right align contents of cells (or columns), even better but I can live without it. My option is to send plain text messages using tab characters (\t). This works as long as text in cells are roughly the same width, but not for content with more varying widths. 2) Possibility to include dynamically generated images in output (from API calls not stored in files). Since tags are supported in XHTML-IM, this can be done using one of two methods: 2a) Using the data URI scheme and embed the image in the HTML itself. XEP-0071 actually recommends against supporting the data URI scheme, but does not prohibit it. I would like to lift this non-recommendation, but keep a recommendation on size of message stanza. In an earlier mail I also write that it could be good to differentiate between what is recommended by the sender and what is recommended by the received. It could be recommended by the received (chat clients) to support this to some extent, but not recommended by senders, since full support for it may not be guaranteed. 2b) Mentioning the httpx URI scheme (XEP-0332) in the same section. If supported (by the src attribute in img tags), this would also solve the issue. Of the two needs, table support is clearly the most important. Best regards, Peter Waher
Re: [Standards] Updated XEP: Event Logging over XMPP
On Sun, Nov 10, 2013 at 10:13 PM, Peter Waher wrote:
> Thanks again for all feedback. It was a great response, and I’ve
> received very good input. I’ve made several corrections as I mentioned in
> previous mails. Here I’ve attached the latest version, together with XML
> and schema files, for insertion into the XSF inbox, and also added an
> appropriate acknowledgement section.
>
>
>
FWIW, I have a considerable preference for "event" over "log". A log is a
permanent record of events, and you'll note that the literature on logging
refers to events. In fact, the protoXEP uses that term of art throughout.
Second, I think the "message" attribute should be a child element, with the
message as content.
I think what's needed overall is to map RFC 5424 into XML, and allow
extension in roughly the same way that we extend stanza and stream errors.
So what you'd get would be the RFC 5424 HEADER construct as a containing
event element, and it would contain detail as either a
element with a sd-id attribute, or a element.
I'd personally drop in facility and severity into the event element itself,
because virtually everything uses those instead of PRI, but still.
The result looks roughly like:
{ A message here | Value }
As far as transport, I really think that any logging source ought to expose
itself as XEP-0060, but I could be wrong there.
Dave.
