Monday, October 08, 2007

keytool is a useful utility for dealing with Java keystores, but it has a significant disadvantage: you can not export private keys with a certificate using keytool. Therefore, the only thing you can so is to add the certificate as a trustedCert into the keystore, but not as a keyEntry.

Obviously, this is easily possible through the programmatic interface, but that can be hasslesome at times. At http://couchpotato.net/pkeytool/ you can find a really nice little tool that allows you to extract the private key in a separate file, and then re-import the private key file and the cert into a new keystore.

tag: , ,

Monday, October 08, 2007 4:49:30 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Friday, October 05, 2007

Ok - I just upgraded my blog engine to the 2.0 release of dasBlog. A big "Thank you!"
to the team for keeping up the great work.

One thing that does seem to work again is comments - so please giv it a try, if you like.

UPDATE: I just saw that the publishing times have been changed during the upgrade (or something else went wrong between the new version and Feedburner), so you will see a lot of new articles, that are not that new. Apologies.

Friday, October 05, 2007 3:09:54 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

Electronic health record are a very touchy subject, since these affect some of the most personal data. While a usable and reliable system for such electronic records would certainly save a lot of money and also prevent even more health-care related mistakes, the Microsoft HealthVault solution is probably the very worst way of trying to solve these problems.

Do not get me wrong - I do applaud Microsoft for trying to push this effort ahead, so that we (as a society) can make progress towards a reasonable solution. But a centralized (one is tempted to say: totalitarian), Passport-like data sink for my most personal data does not even sound bad to me[1]. Here are a couple of questions that came to my mind immediately after reading the announcement:

  • Why would I trust an unrelated and (health records wise) completely unexperienced company trust with my health records?

  • What happens in case of a data breach?

  • Why should I consent to having my data shipped to *any* other country?

  • Why is Microsoft only worried about third party "Program" provider satisfying *their* Privacy Policy needs and not mine.

  • What happens if health related surfing habits are harvested not through the HealthVault web site, but through the *required* Microsoft Passport account?

The list could go on and on after reading the boiler plate privacy policy. I just cannot understand why Microsoft is pressing forward into this area without taking much more caution to prevent security breaches (ha: they are using SSL and strong passwords!!) and limit liability. In this area (particularly when dealing with super personal data like real-time live sign data) there is no "get it right the third time".

Paul Madsen made a very good point of this area of application being ideally suited for Liberty technologies. I think that data as sensitive as medical records should be regulated to only be kept in federations: without my explicit consent data should not move from one silo (doctor A) to any other (doctor B or insurance). In fact, the way the (ineffective, but privacy preserving) way health care works today is a federation model.

tag:

[1] I am really in a Pauli mood today.

Friday, October 05, 2007 11:40:20 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

Dare Obasanjo offers a very balanced view on the recent announcement by Microsoft to release the .NET 3.5 source under a highly restrictive license. He writes:

This is one of those announcements I find hard to get excited about. Any developer who’s been frustrated by the weird behavior of a .NET Framework class and has wanted to look at it’s code, should already know about Lutz Roeder’s Reflector which is well known in the .NET devoper community. So I’m not sure who this anouncement is actually intended to benefit.

The Microsoft Reference License says:

"Reference use" means use of the software within your company as a reference, in read only form, for the sole purposes of debugging your products, maintaining your products, or enhancing the interoperability of your products with the software, and specifically excludes the right to distribute the software outside of your company.

So, if you look at the source code for .NET you better stop working on *any* plumbing or infrastructure code, because you might get tainted. Why are they doing this? I'd rather see the .NET code going under a GPL license, or even a BSD derivative.

Microsoft R-L is NOT open source - it is not even closed source Or, to use a Wolfgang Pauli expression: "This is so bad, it is not even wrong."

tag: , ,

Friday, October 05, 2007 10:53:55 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, September 24, 2007

I just ran across this song (from 2006) called "Download this Song" by MC Lars. You can certainly debate the quality of the song itself (although I still very much like "The Passenger"), but the point he is trying to make is probably quite right: 10 years from now, CDs will probably be considered either audiophile, totally redundant, or both. Popular music will at that time be produced, promoted, distributed, and listened to online.

However, I doubt that the small, but dedicated group of people interested in classical, contemporary, or Jazz music will be that easily converted - at least not without CD equivalent (or better) download offers.

Anyway, here is the video:

tag: , ,

Monday, September 24, 2007 8:07:23 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Friday, September 21, 2007

Kim writes about the recent Beta announcement[1] at Windows Live! about them accepting Windows CardSpace InfoCards for authentication. Having gone through rolling out an extensive public new and experimental Identity System deployment myself (Lauren is currently writing about that), I can appreciate the work that Kim and his colleagues are putting in.

In the interest of distilling use cases for Project Concordia and other venues it seems worth pointing out that - in this deployment - Windows CardSpace is being used solely as an authentication system: You can associate any Windows CardSpace card (only PPID is required) with your account - all other attributes are still being handled by the backend systems of Windows Live!. Any additional attributes that your Windows CardSpace card can provide will not be used for authentication or authorization.

This is very much in line with my description of the "glorified HTTP Redirect" use case of Windows CardSpace: here the secure UI on the client can actually help in preventing phishing attacks. The biggest competitor for this use case is OpenID which offers (roughly) the same features, but employs a radically different approach at solving the authentication problem. With PAPE it is somewhat more phishing resistant, but at this point, the CardSpace-based identity systems have - from my perspective - a clear lead in this area over OpenID.

Both authentication technologies face however that same issues: they allow delegation of responsibility for authentication and a rudimentary attribute exchange mechanism. But they do not address the need of service providers to maintain ownership of attributes about their users, except in trivial cases. For these - business driven - issues you need a framework that allows advanced models of federation and account linking and  - most importantly - goes beyond protocols and addresses the non-technical aspects of identity management as well.

I think it will be quite interesting which authentication technology (OpenID and Windows CardSpace) will get how much market space. OpenID has a head start as far as IdPs and community acceptance goes, but Windows CardSpace has the backing of Microsoft and - starting with Windows Server 2008 - a REALLY large number of relying parties.

tag: , , ,

[1] The service has been available for some time now.

Friday, September 21, 2007 8:04:54 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Tuesday, September 18, 2007

Just to satisfy myself that the Solaris 10 U4 iSCSI target is working well, I fired up a few file system stress test processes to see if the Solaris machine (and the iSCSI initiator) hold up.

For the test itself, I took an old but reasonably reliable SQL Server hard drive test (can be downloaded e.g. from here). I took the default parameters with medium workload (100MB files), especially since my test drive was a virtual machine on my laptop. Write caching was off. The purpose of this test was not to create a performance evaluation or a real stress test, but much more a proof-of-concept that the two systems would work together.

Here is the final result:


The next step would be a full stress test, preferably with at least 3 or 4 high-powered drivers. That might take some time, though. Meanwhile: happy SAN building.

tag: , ,

Tuesday, September 18, 2007 8:21:14 AM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Monday, September 17, 2007

... but it seems that the marketeers at Microsoft are finally getting interoperability: Dino Chiesa blogs about how SCA is an endorsement for WCF. That in itself might be a questionable statement, but he makes a very good point about what makes interoperability a reality:

"The WS-* work the industry has pursued since 1999 shows that we (vendors, customers, developers, pretty much everybody0 recognized that protocols were the sine-qua-non for interop. PROTOCOLS people, not programming models. Protocols, Protocols, Protocols, Protocols, Protocols, Protocols!

And let 1000 flowers bloom! Given a standard protocol, the world can support a myriad of programming models, and they can look like anything they want. As long as each implementation produces the same on-the-wire protocol, they can all intercommunicate. Glory be!"

One is tempted to say: "Finally!" or "Words of wisdom!" or even "Took 'em while, but they finally got there." Yes, Dino: I could not agree more. To enable full interoperability between particular software components running on different machines (and perhaps even operating system - and I mean to go beyond Windows 98, 2000, XP, 2003, Vista, CE, and mobile) you need full protocol disclosure. And just to clarify: this would mean syntax and semantics of all network communications between two systems that are meant to be interoperable.

So, if we are talking about OS level interoperability like "samba" or "PC NetLink" (yes, I've been that long at Sun) and "NT-SAM" or "Active Directory", this would also apply, correct? Can we expect a gesture towards the samba community in the near future?

Hoping for a positive answer on this one ...

tag: , , ,

Monday, September 17, 2007 3:26:01 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Friday, September 14, 2007

Here is a really nice add-on that got shipped with Solaris 10 update 4 (08/07): starting with this OS release, Solaris supports iSCSI targets. Together with the Microsoft iSCSI initiator for 2000/XP/2003, this allows building a very comprehensive and compelling SAN (Storage Area Network). Here is a screenshot:

Now, in order to get this to work, you need to do the following things:

  1. Install Solaris 10 08/07 (update 4)

  2. Install Windows and the Microsoft iSCSI initiator 2.05 build 3392

  3. Follows these guidelines to configure a target

  4. Read up on the MS initiator on how to discover and mount an iSCSI target

Overall, this procedure is not very difficult and you will have a system running within a few minutes. 

Please note that I did not (yet) test CHAP authentication or Vista compatibility, but - given some time - I will try this later.

tag: , ,

Friday, September 14, 2007 3:21:12 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 
Tuesday, September 11, 2007

Yesterday, Kim Cameron picked up on a recent article Bob Blakley. The central theme is about Stefan Brands' criticism of OpenID. While Bob sets out to ask the OpenID 2.0 folks some hard questions about what kind of problem they are actually trying to solve, Kim opines that some of the criticism brought forward by Stefan (and Bob) is unfair, since it is out of the scope of what the original intent for OpenID was.

Instead, Kim suggests that there is a spectrum of identity systems which address different needs. Thus, all such systems including SAML 2, WS-Federation and - by extension - the WS-Trust based InfoCard identity system[1] should answer the questions posed by Bob to OpenID 2.0:

"[Bob] argues that the OpenID specification should include an articulation of the constraints on what it is attempting to achieve.

I agree, with the proviso that other protocols, like SAML 2.0 and WS-Federation, should do the same."

A lofty goal, who could not agree to that: it is most crucial that software architects and designers spend time on defining the boundaries of a given solution. However, prior to limiting and classifying solutions, it would also be neat to actually identify (sic!) the problem/use-case of the solution under examination.

Although I try not to sound like a broken record, I do have to come back to a favorite theme song of mine: Liberty Alliance has done all these nasty and boring use-case evaluations, requirements, and scope definition like privacy and trust evaluations. Interestingly enough, a lot of these often fairly generic assessments is indirectly offered to other identity systems through Project Concordia.

tag: , , , ,

[1] Kim writes: "Popping up a level, we need a spectrum of solutions to identity problems.  Ergo, the identity metasystem." This is - in my opinion - an obvious example of why the term identity meta-system is very misleading: here it does not necessarily refer to the 'meta'-system defined by the InfoCard architecture, but rather to what I jokingly referred to as the "Aleph 0 Identity System" - a 'true' meta-system of protocols, deployments, etc.
But such a 'true' meta-system is not exclusively a WS-Trust based replacement for HTTP Redirect (WSTBRFHR), like the InfoCard identity system .

Tuesday, September 11, 2007 1:17:00 PM (Eastern Standard Time, UTC-05:00)  #    Comments [0]  | 

Copyright by Gerald Beuchelt.