William As I have just started to monitor this list, forgive me if my remarks are misdirected or out of turn. That being said, I do know PKI.
The "Mao Zedong" PKI (aka 'little pki') is unlikely to be useful for the authentication problem that you describe. The ease of little PKI construction follows from the fact that Relying Party and CA are conceptually the same entity. In such schemes, there is no attempt to provide assurance for the benefit of 3rd parties, indeed most little PKI are constructed explicitly to prevent 3rd party reliance, say by (among other things) assigning random strings to the Subject DN attribute. A collection of such PKI then, with all due respect, seems unlikely to provide a basis of industry 'trust'. This is not to say that little PKI cannot useful. Three or four years ago when the PKI bug was particularly virulent in healthcare, a number of service providers (Quadramed and HealthLogic come to mind) initiated litte PKIs. I have helped clients implement little pki as part of their programs to strengthen user authentication. These are easily and cheaply constructed, especially since practices are generally not subject to 3rd party scrutiny. The problem with such PKI is that, while their utility is limited, the cost of end user support is only slightly less than in more traditional PKI as, after all, subscriber private keys still have to be protected. Since end user support can be a major PKI cost component, little PKI becomes economically unsound if the consuming app is not so highly valued that it can bear all of that support cost. Traditional PKI models may have an economic advantage as, in principle, that support cost is distributed to a larger relying party community. I think it is important to distinguish between two uses of PKI in this (CPP) context: 1) to provide key material that can be used to secure transactions. As you point out, there is no particular need for 3rd party's here. Self signed certs can be used just as well as those signed by 3rd parties, pgp certs that are also signed by the trading partner seem to be the traditional favorite of health plans / CH. The issue is, of course, that trading parties are relying upon the 'security' of the channel thru which the public key assertion is accomplished. If healthcare trading partners relied upon keys simply as a matter of publication in a CPP Registry, then effectively they are relying upon the publisher of the CPP. Absent other security mechanism, the Registry owner potentially assumes CA type liability. 2) to provide key material that can be used to 'authenticate' a particular CPP, say with the subject's digital signature . Here I think Ron Bowron has the right idea that the PKI used in this context really is derivative of the credentials (licenses) issued by the various states to providers and plans. But while I agree that it makes sense for the license boards and departments of insurance to provide such certs with the qualifying license, I think that this is very unlikely to happen anytime soon. In every cases where I have identified license board interest in PKI, it is a relying party interest. So if PKI is to be used in this manner, I think there is little alternative to establishing some assurance standard and then expecting CPP submitters to acquire certs from a CA providing that assurance. <Examples of such assurance standards can be found in soon to be published "Standard Healthcare Certificate Policy" ... one by the ASTM e31.20 and another by the ISO TC215>. The CPP publisher can provide some value add in 'certifying' the CA's. I point out, though, that the second use of PKI can be avoided were the CPP Registry publisher to provide assurance as to the authenticity of published CPP. Here I think PKI provides a good model. For example, this SNIP workgroup could establish minimum responsibilities for the CPP publisher in authenticating and protecting submitted CPP. This is 'guidance' for users of published CPP and is analogous to a communities of interest's Certificate Policy. A Registry provider then would assert its compliance with that standard thru a published set of its practices. The published practices are analogous to a cps; the Registry provider contractually obligates itself to following those practices. This approach provides a rationalization of a Registry provider's limited liability assertion. This is important, because as we all should know, ultimately it is another 3rd party, the Court, that will determine the Registry provider's actual liability. I suspect that the PKIX RFC 2527 (CP / CPS Framework) as well as any number of Healthcare CP would provide a good starting point for this aspect of a "Minimum Standards for CPP Providers" document. Regards, Bill Pankey
begin:vcard n:Pankey;Bill tel;fax:209.754.9135 tel;work:209.754.9130 x-mozilla-html:TRUE url:http://www.tunitas.com org:the Tunitas Group ;http://www.tunitas.com version:2.1 email;internet:[EMAIL PROTECTED] title:consultant adr;quoted-printable:;;PO Box 278=0D=0A6693 Sierra Vista Lookout Road=0D=0A;Mountain Ranch;CA;95246; fn:Pankey, Bill end:vcard discussions on this listserv therefore represent the views of the individual participants, and do not necessarily represent the views of the WEDI Board of Directors nor WEDI SNIP. If you wish to receive an official opinion, post your question to the WEDI SNIP Issues Database at http://snip.wedi.org/tracking/. Posting of advertisements or other commercial use of this listserv is specifically prohibited.