This blog has now relocated to a Wordpress installation on the Isode site. The new address is:
Over the last few months we've been adding a lot of new functionality to our XMPP server, M-Link, and this has been reflected in an increased tempo of releases. The latest release focuses on improving interworking with XMPP clients and servers which do not support security labels, adding new features of interest mostly to our customers and evaluators in the Govt/Intell/Military markets:
M-Link's support for security label functionality is well documented (see the whitepaper: Using Security Labels to Control Message Flow in XMPP Services). In this new release we add the concept of Default Labels, with the goal of supporting interworking with clients and servers that do not support labels within systems where security label support is required.
A Default Label can be configured for a Server, Peer, MUC room of Service (i.e. applied to one domain within a single server supporitng multiple IM domains).
FLOT (First Line of Text) Labels
This is the ability to insert a FLOT label at the start of any XMPP message. The text from the XEP-0258 display marking is used.
This ensures that clients not capable of XEP-0258 (XEP-0258: Security Labels in XMPP) will see security labels, and will help with deployments in mixed environments.
For local clients, this feature will be used automatically for clients that do not support XEP-0258 (or TransVerse) labels. This capability is enabled by default, but may be disabled. It can also be explicitly configured for peers, which will help supporting systems that are not XEP-0258 capable. Where a message has an HTML part, this is removed, so that only the text option (with the label) is present.
In the screenshots below we show this in operation in a chat between two users, one using the Psi client (which has no label support) and one using a pre-release copy of Swift (which does support XEP-0258 labels).
Improved/simplified support for TransVerse
We have simplified and improved support for the TransVerse Client, which uses IC-ISM labels and its own XMPP encoding. We've tested with Transverse 1.5 and Transverse 2.0 Alpha.
The "TransVerse Map" configuration has gone, and configuration is driven from the SPIF and the server's label catalog. For message delivery to TransVerse, M-Link will insert TransVerse Style labels using the XEP-0258 information, which Transverse will display, and look the same as XEP-0258 labels (colour and display string).
TransVerse supports label catalog discovery for MUC rooms only. M-Link will respond to these discovery requests with a TransVerse compatible catalog, filtered appropriately to the requestor's clearance and other applicable clearances (e.g., the room's clearance). When TransVerse sends a message with one of these labels, it will be treated the same as the corresponding XEP-0258 label and a XEP-0258 label will be inserted by M-Link. In cases where TransVerse does not support label catalog discovery, including chat or through-MUC 1-to-1 chat, TransVerse will offer it's default catalog (e.g., the US labels UNCLASSIFIED and UNCLASSIFIED/FOUO). These labels will not be generally recognized by M-Link.
Here is how Groupchat looks between TransVerse, Swift and Psi:
Equivalent label support
We've done some work on equivalent label support, and provided test data to help those interested in investigating and demonstrating this capability.
Note that this does NOT include label translation (e.g., replacement), which will be provided in a future release.
The key capability is that a policy can specify non-local labels as equivalent to local ones. This means that non-local labels (from peers or local clients) will be validated correctly. The sample data we provide with M-Link includes policy files (including variants with and without equivalents) and catalogs to set up the configuration shown in the diagram below.
The UK Demo policy is the one previously supplied, as is the NATO one. UK-NATO is a new policy, that includes (GENSER style) both UK and NATO labels, so that either can be used on the site (under appropriate clearance control). This can be useful for sites that wish to have users using both labels. Note that this is a new policy with a new policy id. Each of these policies has appropriate equivalents to the other policies.
We're happy to help anyone set up a configuration based on this.
Digital signatures for XMPP messages are a desirable addition to the currently standardized peer to peer digital signatures (strong authentication based on PKI). Digital signatures on XMPP messages can enable:
Previous attempts to standardize have not gained general acceptance, and have a number of problems. Ad hoc implementation efforts that we are aware of also have problems.
Isode is working to enable a standard. XEP-0274 "Design Considerations for Digital Signatures in XMPP" has been developed primarily by Isode staff and has just been published. It looks at requirements and possible approaches to meeting these requirement. It looks particularly at approaches using the XMLDSIG XML digital signature standard, which we believe is the most promising direction.
Both requirements and technical solution to address these requirements are complex. We believe that wide participation will be crucial to develop a workable and widely adopted standard in this space.
In Release R14.5 of Isode's M-Link XMPP Server, support has been added for XEP-0114 Jabber Component Protocol, which among other things can be used to provide a mechanism for connection of External Legacy IM Services. The JBuddy XMPP Gateway from Zion Software supports XEP-0114 and provides connectivity to AIM, ICQ, Windows Live/MSN and Yahoo Instant Messenger services. Isode's M-Link XMPP server has been certified by Zion Software as a tested compatible XMPP server for use with their JBuddy XMPP Gateway.
Isode CEO, Steve Kille, will be presenting at the next meeting of the HFIA in Munich on 14 September.
The Second International LDAP Convention (LDAPCon2009) will be held in Portland, Oregon on September 20th and 21st.
We're pleased to announce a new partnership between Isode and Fine Point Technologies. By combining Fine Point's over-the-air (OTA) provision technologies and Isode's M-Box Gateway product, we're able to offer mobile service providers a complete moble email solution for their subscribers with minimal user and operator intervention.