Well, the new release of FireFox is out and it is not looking bad. It is really refreshing to see that after the browser wars were supposed to be over, we are seeing again some healthy competition. There are already a few nice features that FireFox introduced that Microsoft announced for IE7 which is due some time in December. Tabbed browsing is one of them, eliminating browser clutter.

Recently a German news weekly posted on their website that they are already seeing between 32% (weekdays) and 40% (weekends, from private PCs) FireFox usage, which is significantly more than the usual reported numbers of around 5% market share.

I expect a fairly interesting new battle in the browser wars epic with the arrival of WPF/E capable browsers [1] on the Microsoft platforms. This time HTML might be at stake, although I would be surprised if XAML applications would actually start to replace HTML applications on the public internet.

[1] For the uninitiated: WPF stands for Windows Presentation Foundation which is the long announced, yet to be delivered Avalon API for .NET. the "/E" stands for Everywhere - WPF/E is supposedly an IE-embedded Avalon/XAML runtime, that will render XAML instead of HTML.

...contains a nice collection of articles and factoids on the Open Document Format debate. Please take a look at it here.

Since I finally decided to follow my most basic instincts/conscience/sudden inspiration/whatever and setup a personal web site, I am now promoting it...

Please check http://www.beuchelt.com/ or http://www.beuchelt.net/ for my page. You will be able to get to this blog at http://blog.beuchelt.com/ and http://blog.beuchelt.net/, although the old address (http://beuchelt.blogdns.net:8080/ will stay).

In the unlikely circumstance that you are interested in taking a look at some of my older articles, please drop me a line at: work at beuchelt dot com.

My recent GSS-SAML musings lead me to think about the relation of security, applications and platforms. My firm belief until recently was that security should be handled low in the stack: in the network protocol layer, the operating system, etc. The benefit is quite obvious: by securing the transport, OS, etc., the applications and their developers can be fairly ignorant about security (which they mostly are anyways) and yet build a reasonably save solution.

Now, there is one problem with this model. In order to be really secure, the network and OS developer tend to put fairly restrictive security system in place. This in turn inconveniences the application developer whose first reaction to a security problem will be to simply shut security off. The results can be seen all over the internet ...

The security stack

I better solution - I think - would be to start formalizing a full security stack. By that I mean essentially the same as when talking about a network stack. A security stack should define clear security layers, with well-defined boundaries of security domain.

Such layers should be isolated, yet permeable for permissable security information. One example would be the public key of a specific identity for message integrity and confidentiality. The associated name and other attributes are not strictly required for this operation and should - as such - not be permitted to pass through the security layers.

A possible arrangement of the security stack could be modeled along the ISO network layer model (lowest to highet layer):

1. physical network security - This would include very low level protocols, such as e.g. EAP/802.1x
2. network transport security - I would put protocols such as IPSec into this layer
3. platform security - Here, GSS-API, Kerberos, and maybe SASL would be located
4. application transport security - Within this layer, we could find things like HTTP authentication
5. application security - This layer might justify another division, but probably not horizontally, but vertically in different silos, such as web services and applications (Liberty, SAML, WS-Security), databases, etc.

In today's world, many of the different protocols are not capable of easily passing security information through the different layers of this stack (although there are some notable exceptions).

It should also be noted that while some security protocols do provide for the inclusion of authentication and authorization data, many do not.

What would we gain, if we had such a stack?

A clearly defined stack could serve as a framework for classifying, combining, and architecting new security protocols. Features available in different layers of the stack could then percolate up and down. An example would be the privacy features in SAML that - when profiled properly - could then be available at lower levels, effectively allowing anonymous (or psedonymous), yet authenticated access to resources.

I just wanted to step back and thank my collegue Lauren Wood for her superb efforts organizing the XML conference (for the 5th year!). As a speaker, as well as an attendee, this was a most pleasant and interesting conference.

Once more, Microsoft is targeting ECMA as the consortium to sign of on their technology. Just as a few years ago, when they submitted parts of the CLR and C#. This time it is the Office '12' formats, which have become quite a burden under the current plans of the Commonwealth of Massachusetts, the E.U. and the Country of Denmark: All these three governmental bodies decided to require an open file format for all future forms and documents.

For the longest time, the license that came with the Office XML formats was far less than open - bottomline was: you can look, but you cannot really implement.

Now Microsoft promises that this will change under the ECMA process.

For all attendees of XML 2005: I just updated my paper on Using SAML for Platform Security. Please check http://2005.xmlconference.org/proceedings for the updated version.

All non-attendees: The proceedings will be made publicly available by Nov 30, this year. I will also publish the paper here.

I have just configured dasBlog to use cross posts. Let's see if this post makes it to my old blogs.sun.com blog.

For those reading this on blogs.sun.com: my new blog is at http://beuchelt.blogdns.net:8080/.

Hmm - 2nd try.

Please find the PDF slide deck for my presentation at XML 2005 here:

XML 2005 - Using SAML for Platform Security

The paper for this talk will be - as far as I understand - available for public download some time later this year or early next year from the conference Web Site.

The open document discussion is also raging within the halls of the European institutions. Please see for a report and some industry responses here.

On that page, you will also find a letter from Jonathan Schwartz of Sun Microssystems, Inc. on the report by the Commision.

Now, here is an interesting talking point: XML Encryption (XMLEnc) is bad.

"Why?", you might ask. Well, in their lack of infinite wisdom, the XML encryption community left out a very important concept: Authenticated Encryption, i.e. combining signatures and encryption to produce ciphertext that maintains confidentiality and can be associated with a key (i.e. a subject/identity/principal/whatever). Section 6.1 in XMLEnc-Core reads:

"The application of both encryption and digital signatures over portions of an XML document can make subsequent decryption and signature verification difficult."

and

"[...] the interaction of encryption and signing is an application issue and out of scope of the specification."

So, essentially, AE is left as an exercise to the reader. This is not good, particular since AE is not too complex, and - in fact - quite well understood. See RFC 3961 (Kerberos) or "Authenticated Encryption ..." by M. Bellare et al.

Without AE, XML encryption is not complete and - for many real security applications - useless.

Yesterday, we had our first day at the booth here at XML 2005. We were able to attract a fairly large crowd, talking about the Identity products, StarOffice, the XML Registry, JWSDP and Open Solaris. Up there is a picture of the booth prior to opening the showfloor.

Living in Massachusetts, I strongly support the state's move to migrate their publications and documents to a truely open format (i.e. OASIS Open Document).

Now I recently ran across a public petition to the German Parliament to enact a similar regulation for the German authorities.

Now: if you are German and feel like this is a good idea, please go here: http://itc.napier.ac.uk/e-Petition/bundestag/view_petition.asp?PetitionID=11

Due to very limited internet connection, I have to be brief. Here are some of the result of my trip to IETF 64:

• There is definitively a fairly broad interest in using SAML within the GSS-API framework.
• A small group is currently discussing feasibility and scope of such a approach

Originally, we proposed three major modes of combining SAML with GSS:

• An internal decoration approach: SAML assertions could be used WITHIN existing mechanisms (such as e.g. Kerberos) to carry addtional attributes associated with the principal.
• An external decoration approach: Similar, but instead of using pre-existing extension points, use the stackable mechnism approach instead (see www.ietf.org, kitten WG). This approach would have the clear benefit of being composable with mechnisms that do not have extension points (e.g. Username/Password).
• A native mechnanism: A SAML AuthN statement is exclusively used. While - IMHO - most promising, this approch will be technically most challenging: first, there is no key exchange defined, second, the only crypto related XML standards (XMLDSig, XMLEnc) are - at best - poor

I will post more after XML 2005.

Well, I have to admit, it is a lot easier than it used to be. A few caveats, though:

• I prefer to configure after the installation manually. I had one nasty failure during install at some time when I was using automatic configuration during install (This was actually because I installed JES on an AD domain controller, so port TCP/389 was bound, so the LDAP configuration would fail, and (almost) all other configuration after that depends on the availability of the config server).
• When configuring the directory server, please edit the directory server properties file before running DSConfig.bat. The README doesn't say so, but I had a much better time when I did.

When uninstalling JES, you might end up with a case where the Directory Server Windows Service was not unconfigured. In that case, you must go to HKLM\System\CCS\Services and delete the keys for slapd-(your server identifier here).