AWA: See, for example http://www.ietf.org/internet-drafts/draft-ietf-pkix-roadmap-09.txt
From Section 1.2:
Public Key Infrastructure (PKI) - The set of hardware, software, people, policies and procedures needed to create, manage, store, distribute, and revoke PKCs based on public-key cryptography.
Note that there's nothing in there about USING the keys/certificates to accomplish any particular (business or other) task. In other words, the applications are external to the PKI.
Section 2 of that draft has some more details.
OK. As the meaning of "people" vague, according to section 2, they are not general public but users of a specific PKI.
The question, then, is, why do you call it "Infrastructure"?
PKI, as defined in the draft, is just a mission specific structure, not an infrastructure.
It seems to me that you think PKI not only exists but also can be purchased.
AWA: Hmm - my terminology in my original posting was a bit suboptimal. *Part* of the PKI can be purchased - namely, the hardware and software. The "people, policies, and procedures" bits get tricky - you generally cannot buy them. (You can often buy "generic" policies and procedures manuals that have to be tailored to your specific environment/rules, but you can't buy a canned solution.)
Then, there can be no PKI standard, I'm afraid, though there can be PKI software/hardware standard.
And I feel more difficult to call a PKI an infrastructure.
And, of course, the actual applications/business processes still have to be provided from somewhere else.
In most, if not all, cases, actual applications/business processes requires realtime communication with CAs that shared key cryptography is just enough.
For example, if I use PK based certs for my bank account, I can withdraw cash from my accunt as many times as I want, unless remaining credential in my bank account is reduced in real time, which means I must communicate with my bank as CA, which should better be KDC.
Masataka Ohta