Constantin describes in this article how to create an DVD-Audio disc on Linux/Solaris (and also emphasizes the difference between DVD-Audio and DVD-Video).

I assume that most people who are interested in DVD-Audio know that there are also commercial DVD-A solutions out there, like DiscWelder.

However, for the task at hand Constantin would not have needed to create a DVD-Audio disc, but instead could have simply used his favorite DVD-Video authoring tool and create a stereo 96kHz/24bit LPCM track on a DVD-Video. All fully compatible DVD-V players must support this format, thus you do not have to resort to DVD-Audio.

This is obviously different for multi-channel formats where the DVD-Audio format is the only viable alternative. For high-resolution, multi-channel tracks, you will also need an MLP encoder ... and here we are talking about some serious licensing fees.

tag: DVD-Audio, DVD-Video, High-Definition

PS: Here is an overview on the DVD-Video audio capabilities.

Paul picks up on an article by Pam about level of assurance with Windows CardSpace. He emphasizes the important point that assurance is not only affected by the underlying technology, but also by non-technical parameters like contracts.

I would go one step further and say that LoA is almost exclusively affected by non-technical factors. To be able to put any trust into a given authentication system (let alone an authorization system) you need minimally:

1. A contract between the RP and the IdP
2. A contract between the user and the IdP

Both contracts need to have provisions for the following areas:

1. Data governance (including privacy assurances and data handling)
2. Fault handling
3. Data updates
4. Contract termination
   
5. Liability
   
6. Arbitration and conflict resolution
   

Without such a framework most authentication and all authorization systems are only useful for 'low-value transactions' such as blogging or simple social networking. Or - in other terms - there is no level of assurance, even if the underlying technology supports the most fancy certificates or crypto algorithms.

Obviously, contracts of such kind can only be meaningful and economically viable, if the underlying technology is not broken and has the necessary features to support such provisions^[1].

Now, as far as the Windows CardSpace identity system is concerned, there are indeed multiple levels of assurance for the RP:

1. No assurance - self-managed cards, or any managed card where the Issuer is not enforced by the RP
2. Assurance - managed cards where a particular set of Issuer(s) is required by the R

Only in the later case there can be a reasonable level of trust by the RP that the user is actually who he/she claims to be relative to a given IdP. In that case the contract provisions between the RP and the IdP are in effect and it will depend on them how much trust the RP can put into the authentication and attribute statements.

The Liberty identity system has the necessarily technology and the business and legal frameworks for providing a very high level of assurance, but they are currently not ideally equipped to address the needs of little or no assurance (which typically include fast and extremely easy deployments). Hopefully, openLiberty wil help address these issues.

tag: identity, WCS, Liberty

[1]Thus, any identity system that relies on an universal federation (i.e. any IdP is admissible) cannot provide any meaningful level of assurance.

When you are working with Glassfish (like I am doing now), you might need to capture your HTTPS traffic. In an earlier post, I explained how to capture and decrypt any SSL/TLS traffic, as long as you have the server private key.

While this method is quite effective and universal, it is still a little cumbersome, especially since the actual SSL decoder in Wireshark is not yet fully integrated into the analyzer itself.

For Sun's Glassfish application server, there is a fairly simple way to monitor any web services HTTPS traffic:

simply go into the domain.xml file of your domain and add the following <jvm-options>:

<jvm-options>-DWSIT_HOME=${com.sun.aas.installRoot}</jvm-options>
<jvm-options>-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true</jvm-options> <jvm-options>-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true</jvm-options>

The server.log (in <installRoot>/domains/domain1/logs) will then contain the fully assembled web services exchanges.

tag: glassfish, java, wsit, SSL, HTTPS

Sorry, due to a recent surge in Trackbacks, I have deactivated this feature for the time being. Spammers are really an annoying bunch ...

What made it now just unbearable is that my blog was being misused to advertise the services of the worst health insurance that I ever had: United HealthCare. My conscience does not allow me to help this highly incompetent and - at times - immoral company in any way. It says a lot about a company (especially in HEALTH care) when they or their agents employ SPAM tactics to get people interested in their offer.

tag: blogging, spam, trackback

It seems that history is about to repeat itself: after Liberty formed, a lot of people wither felt left out or did not understand what all this 'identity stuff' was good for. Granted, Liberty was in 2002 about 5 years ahead of the rest of the market. At the time, I thought that this perception problem could be attributed to some abysmally bad marketing - I guess that this was only partially correct.

Today, the same complete lack of understanding is about to hit the "user-centric" identity community as well: Take a look at a post by Brian Huff and compare that with this post from Tim Bass (via James McGovern).

It seems astounding to me that both authors (who claim to be working in 'SOA') have so little understanding of the problems, technologies, and solutions in the identity space. Granted, I am a geek working in this area, but both Tim and Bex claim to be architects and decorate themselves with shiny titles (CTO, CISSP, Oracle ACE Director). They should know better.

Both advocate (in so many words) 'a simpler identity system' (heard that one before) and 'authentication - and that's it'. Both paint existing standards in a very bad light, describing them as 'immature, confusing and less-than-proven  security standards' or asking 'Makes you wonder why people bother to call them "standard," doesn't it?'.

Ok, guys you do not understand identity - get over it and hire someone who does. The good old days where everyone was getting ready for the global directory and its PKI are over. It's not only about authN and authZ in these days, but about the much bigger business and regulatory issue like trust or identity theft.

It seems that the larger identity community (Liberty, InfoCard, OpenID) is about to experience the same pushback that Liberty was facing initially. Let us hope that our joint communication efforts today will help to get over this 'perception gap'.

--

Here are a few comments regarding Brian's post:

1. CardSpace, OpenID, SXIP, (parts of) WS-*
Are not even by the widest possible definition standards, but rather a collection of protocol specifications. Some of these are even proprietary, IPR protected technologies (e.g. SXIP) that are not even covered by a NAC. Also, why are you not including real identity protocols by industry consortia, that are free to implement like e.g. ID-WSF?

2. SPML, XDAS
These OASIS standards have - per se - nothing to do with identity. They *touch* upon identity and security, but are not core to it. Otherwise you should also include HTTP, IMAP, SOAP, and even TCP.

3. LDAP, SAML 2, (parts of) WS-*, XACML
The are (in a wider sense) identity and security related standards. But so are many, many others (Kerberos, X.509, WSPL, XML-Enc, etc.) that you chose to omit. And interestingly enough, most of these standards build on each other or are complementary. So where is the issue?

4. The API issue
There is no unified, standadized API to all these protocols? For starters, only protocol organizations typically create protocols, not APIs (one notable exception is the GSS-API). If you want to create a 'standard' identity API, go to the JCP and suggest a JSR. That organization is probably the body with the biggest amount of standardized APIs, and it is - by most standards - fairly open today. On the other side, if you take the contract-first approach serious, every WSDL or SOAP profile is a reasonable API documentation. In fact this approach allows you select your platform of choice.

Regarding Tim's post:

His list of immature protocols is simply ridiculous: SAML - well established since 2001: go ask the Shib folks, who are running the larger chunk of the academic environment on this protocol. XML Enc and Dsig - yes, there are a few problems (authenticated encryption or key exchange), but none of these problems are insurmountable and have been solved for a long time.

tag: identity, saml

Wireshark can decrypt SSL traffic as long as you have the server private key. This can be extremely useful, if you have to debug HTTPS traffic and cannot use HTTP instead or put a MITM in the front (e.g. Windows CardSpace applications).

Unfortunately, the documentation on this feature is at this time rather thin. the wireshark wiki has one page dedicated to it (along with some sample traces - great to get started!!), but there is some information missing. This is what I did:

1. Make sure that the server private keys are in unencrypted PKCS#8 PEM format (RSA)

If in doubt, take a look at your key file. If it is binary, chances are that it is in a DER format which cannot be used with wireshark. Assuming that you have at least an PKCS#8 DER file, you can instruct openssl to convert this file for you:

openssl pkcs8 -nocrypt -in derfile.key -informat DER -out key.pem -outformat PEM

If your DER file is encrypted, you need decrypt the key with the right passphrase first. After you are done, you first line in the key.pem file should look like this:

-----BEGIN RSA PRIVATE KEY-----

2. Configure Wireshark to use this key

You have to go into the Preferences for SSL and configure the RSA key list. Check the wireshark wiki on how to do this. Make sure to specify the debug file - you really need this!

3. Capture you traffic and debug

If you now start to capture your traffic, you *should* be good to go. Make sure that you find a line like

ssl_init private key file c:\temp\key.pem successfully loaded

in you ssl debug line (at the top).

One particular issue that I had was that I got in the debug file for the first application packet the following debug output:

ssl_restore_session can't find stored session

This happens if your client talked to the server before you started the trace (or during an earlier trace) and some key exchange messages are missing. Restart your client (e.g. CardSpace or the browser) and the server, and you should be good to go. 

tag: ssl, network sniffing, wireshark

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: security, java, keytool

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.

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: healthvault

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

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: opensource, .NET, Microsoft