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.
