Hello Tim,I have been out of action since early last week so I apologize if this discussion has gone dormant.
Thanks for the timely response and as always full of good information. I was concerned that people used different certificates systems would be incompatible and that I might need to have several different certificates. I will look at the documents very carefully and see what I want to do.
Thanks for your time.
There is a major practical issue with certificates, and that is how one can be sure of the authority on which they were issued. More precisely, one wants to know if one can trust the authority. This problem is the chain of trust problem.
S/MIME and PGP/MIME take different approaches to the trust issue.
The PGP approach depends upon creating a locally verifiable chain of trust. It supports the building of a trust community from the ground up. Some attempts to ease this building via automation are evident in the various pgp keyservers available.
S/MIME follows from the IETF PKIX work which builds trust communities from the top down, relying upon automated process's for following chains of trust.
The top down effort has two major practical issues:
No one single root of the trust tree can be agreed on, and that has lead to multiple 'roots'. To see this in practice, take a look on your web browser of choice at the list of certificate authority certificates available. Mine has close to 100 listed. Some work and much PKIX specification has gone towards creating cross trusts among 'roots', but I think from an inter-operability standpoint, it's an unknown.
Automated following of the trust chains is both a complicated business (involving as it does both multi-layer referrals, unknown authority policy checking behavior, cross authority referrals, multiple revocation mechanisms and others I am not aware of) and each implementor has had different ideas on how to do it, thus leading to both inter-operability problems as well as security breaches.
The bottom up effort has one major practical issue:
Building the trust community is too much manual labor, and automated tools are not really defined in a standard way.
Over the last decade or so, I started out doing inter-operability testing of S/MIME in the early days of PKIX and implementation efforts. Despite the built-in S/MIME of both Microsoft's Outlook and Netscape's mail reader, no critical mass of users developed. I still have my e-mail signing certificate from a now defunct Certificate Authority that was issueing them for free. Who is going to pay $5/year/certifcate?
Within the last 2 years I switched my efforts to PGP/MIME since it did not rely on 'authorities' to establish themselves and allowed individuals to create trust communities for free. No critical mass here has followed either. My trust community is pretty much limited to Tim Churches right now!
One would have expected that in this era of spam e-mail and widepread virus/worm spreading via e-mail, more people would be interested in who is who in e-mail. However, it appears to me that most people would rather someone else solve these problems then taking action themselves!
Implications for medical messaging:
HL7 has long taken the view that they would not build in security mechanisms as long as existing message layer standards were in place. S/MIME was early looked at as the 'way'. Now, it seems the faith is being put into XML digital signature http://www.w3.org/Signature/ .
Both of these approaches build on the PKIX work. So does the US Government. I am certain this is because of the top down nature of the architecture, i.e. the notion of creating a 'root' trust authority, from which all other trust stems. It's natural for large agencies, NGO or GO to want to posistion themselves as the 'trusted' ones.
My personal opinion is that the business world and the world of individual privacy runs counter to that model and creates a resistance. But even if that is not a big issue, the technical inter operability and the complexity of the standards themselves are so great that nothing really practical is on the near term horizon.
No one has found the 'right' combination of automation and scalability yet. Neither PKIX scaling downwards nor PGP scaling upwards have found the magic ease of use to build a community of trust which will drive forward this technology.
-- Wayne Wilson An attachment containing my pgp-signature is included. My public key fingerprint is: 9325 05AD 866B BCCB 45BF E86A 63E1 C6ED 4130 5461 My public key can be downloaded from wwwkeys.us.pgp.net
pgp00000.pgp
Description: PGP signature
