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...
You should check the usage note section of the dictionary. It eventually says the organization or system should be society or, at least, large enough.
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.
I didn't say it need to be "global" or world wide.
But, it should be large enough, trust relationships within which is not single threaded and is complex.
Then, there can be no PKI standard, I'm afraid, though there can be
PKI software/hardware standard.
AWA: We agree.
OK.
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.
The problem of people working for PKI is that they tend to neglect easier alternatives.
Societies need infrastructures for security, not necessarily public key ones.
When users have to have real time communication with CAs, which is almost always the case, it is a lot easier, simpler, more efficient (and, thus, a lot more secure) to use shared key cryptography.
Shared key cryptography must also be tailored for each mission. However, it is so simple that it does not need complex standard. E.g., because it is real time, we don't need time stamps for certs nor CRLs. We can just say, "use plain password" or "use challenge and response", which is more useful than a complete, if ever, set of some PKI standard.
Note that I know KDCs dedicated to KDC function is just as useless as CAs dedicated to CA function. But, credit card company is a KDC to manage user accounts.
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.
How do you think about "secure DNS" as a PKI? DNS may be claimed to be an application by itself. However, as DNS is used for many different real applications, I think it is too generic to be useful.
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.
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.
I don't know Lynn. But, he might feel unhappy to hear that, when communication is required in real time, shared key cryptography works a lot better and we already have the global infrastructure of banks and credit card companies.
Can I have a mail address of him?
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.
I just presented a paper on Dec. 15th that, if an attacker have a cert with which 1M JPY (100K USD) transaction is allowed, he can use it 1,000 times a second for 1,000 second from 1,000 different locations, without causing noticable amount of traffic (if a transaction consumes 1KB, aggregated traffic is merely 8Mbps for 1,000 second) total damage of which is 100T USD, a lot more than enough to ruin the world economy. Note, of course, that CRLs are not expected to be issued so frequently.
And, it is just reported today that, on Dec. 14 in Germany, three people performed false transactions of net auction for 2 hours, total damage of which is 130M EURO.
So, it is dangerous to the world economy to have security infrastructure without real time communication for things with monetary values.
The problem of the world of capitalism almost everything has monetary value.
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.
If a case involves on-line money, real time communication is always required. Most, if not all, cases do.
Masataka Ohta