AWA: See, for example
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
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.