Al Arsenault;
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.
AWA:
Well, from "The American HeritageR Dictionary of the English Language,
Fourth Edition
Copyright C 2000 by Houghton Mifflin Company.": in fra struc ture: (noun)
1. An underlying base or foundation especially for an organization or
system...
So a PKI is an "infrastructure" for an organization or system; namely, the
organization or system that uses it. There's no requirement that a
particular "infrastructure" support the global internet, or any global
community for that matter.
So I call it an "infrastructure" because it meets the dictionary's
definition of 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.
AWA: We agree. Unless the laws, policies, personnel practices, etc. were
uniform for the entire world, there have to be differences between systems
set up according to, e.g., Hong Kong law vs. systems set up for Canadian law
vs. systems set up for Italian law. Even within a single political entity,
there are often differences between systems set up for, e.g., Health Care
applications and systems set up for financial applications. Since the PKI
includes the "people, practices and policies", things will differ. The
hardware and software may also differ, by the way: some
environments/communities may require specific key generation/storage
parameters be met (e.g., keys are only on certified hardware tokens, vs.
keys in software on any computer system); different user authentication
standards (e.g., PIN vs. biometric vs. SecurID vs...); etc.
Now, that being said: there can be no single standard. What there can be
(and is) is a framework of standards, which can then be selected/tailored
for the appropriate use. The US Government and Canadian Government have
sets of different standards for PKI (e.g., "Rudimentary assurance", "basic
assurance", "medium assurance", "high assurance", ...; Class 1, Class 2,
Class 3, Class 4). VeriSign and others offer different classes of PKI
support to their commercial customers. You pick what's appropriate, given
your specific application, environment, personnel, physical security, other
requirements, and acceptable cost/benefit tradeoffs.
So, no, there will never be a "single PKI" for the Internet, the universe,
or likely for an entire nation. Nor should their be, IMNSHO.
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
AWA: Well, Lynn Wheeler would be happy to hear that! If you're not
familiar with Lynn, he works for First Data Corp. and is one of the prime
pushers behind the ANSI X9.59 standard, also known as "Account Authority
Digital Signatures" or AADS. Basically, it assumes that for each account
you have (e.g., credit card account), there is an account authority (e.g.,
the credit card processor; like, say, his company) which holds the public
key for you, in your account record. Whenever you want to execute a
transaction with your card, you digitally sign it. The merchant sends the
whole transaction to the account authority, which verifies the digital
signature as part of the rest of the processing. The account authority does
the real-time check of the digital signature, your account balance, purchase
limits, etc. and gives an approval or rejection based on the total picture.
My response to your point is the same as it is to Lynn: that's appropriate
for SOME applications. If what I'm doing is exchanging S/MIME e-mail, which
has nothing to do with financial transactions, there's no reason to use the
AADS structure or anything else. All I want to know is that the mail came
from you; not whether it's okay to ship you a new DVD player because the
money has been transferred to me.
Different solutions for different applications. Use what's appropriate. I
think that your comment about "most, if not all, cases,
applications/business processes requires realtime communications with CAs"
is thus incorrect.
Al Arsenault