James A. Donald wrote: > This was the scenario envisaged when PKI was created, > but I don't see it happening, and in fact attempting to > do so using existing user interfaces is painful. They > don't seem designed to do this. > > My product, Crypto Kong, http://echeque.com/Kong was > designed to directly support this scenario in a more > convenient fashion - it keeps a database of past > communications and their associated keys, but there did > not seem to be a lot of interest. I could have made it > more useful, given it more capabilities, but I felt I > was missing the point
i've seen some discussions that were either/or regarding pki & pgp; aka pki advocates attempting to position pki as a OR to pgp. the issue is that both pki and pgp require a local trusted public key repository as the basis for establishing trust. pki then layers on it, these certification authority business processes, specialized digitally signed messages called digital certificates, etc to address first time communication between strangers where the relying parties have no other resources for determining information about the sender in an offline environment. they then advocate that all (personally) digitally signed operations are required to have attached x.509 identity digital certificates that has been digitally signed by a certification authority. we saw some of that when we did work on the cal. state & fed. electronic signature legislation http://www.garlic.com/~lynn/subpubkey.html#signature one possible interpretation might be that it would have increased the revenue stream for the certification authority industry. drastically improving the useability of the interface to the trusted public key repositories could be viewed as having two downsides 1) certification authorities that haven't payed to have their public keys preloaded can more easily join the club, 2) the pgp-like scenario becames much easier, potentially drastically reducing existing reliance on the digital-certificate-only (and certification authority only business process) digital-signed-operation model. part of the problem with the trusted third party certification authority model is that its primary benefit in the case of first time communication betweeen two strangers ... where the relying party has no other recourse to information about the other party. this is actually an extremely small percentage of communications. we saw some of this working on the original e-commerce activity http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 where we layed out hypothetical certification issues for merchants ... including things like having FBI background checks for all merchant employees. the problem is that e-commerce transactions have been quite bi-model whith the largest percentage of transaction occuring as repeat business with well-known merchants. in these cases, consumers have established trust via a large number of other mechanisms ... so there is little added value that a certification authority can provide ... especially if they aren't willing to stand-behind and guarantee all merchant transactions (ssl then is primarily countermeasure to mitm-attack and evesdropping on transaction as opposed to a certification/trust issue). the rest of the remaining transaction are spread around to a large number of different merchants having a few transactions each. the issue here is that the incremental revenue flow for a few transactions a month couldn't possibly cover the cost of a certification process that involved things like fbi background checks on all merchant employees. the large majority of transactions are either repeat business and/or with extremely well-known merchants ... this doesn't satisfy the PKI target profile of first time communication between complete strangers. simple countermeasure to mitm-attack and countermeasure is achieved by having stored the merchant's public key (from the consumer's standpoint). from the merchant standpoint they already have transaction guarantees on credit card processing from their contract with financial institution. the threat/vulnerability model here is client-originated fraudulent transactions that aren't strongly authenticated. here, x9.59 standard http://www.garlic.com/~lynn/index.html#x959 http://www.garlic.com/~lynn/subpubkey.html#x959 allows for digitally signed transaction where the public key is registered with the consumer's financial institution and the digital signature is verified by the consumer's financial institution as part of verifying the transaction. the other part of x9.59 standard is that it specifies that account numbers used in x9.59 transactions can't be used in non-authenticated transactions. this eliminates both data breaches and evesdropping as a threat/vulnerability for fraudulent financial transactions ... aka the requirement given the x9a10 working group for x9.59 standard was to preserve the integrity of the financial infrastructure for all retail payments. if data breaches and evedsdropping no longer can result in fraudulent transactions, then there is much less reason for sophisticated countermeasures for those threat/vulnerabilities (ssl is no longer needed to prevent evesdropping on the account number, since evesdropping on the account number no longer provides any practical fraudulent benefit). simple public key registration as part of financial account operation (in an onging relationship that a consumer has with their financial institution) not only is a certificateless digital signature model http://www.garlic.com/~lynn/subpubkey.html#certless but also eliminates much of the requirement for existing major use of digital certificates; that of providing ssl encrypted communication http://www.garlic.com/~lynn/subpubkey.html#sslcert as countermeasure for evesdropping for the purpose of account number havesting http://www.garlic.com/~lynn/subpubkey.html#harvest furthermore, not only does simple x9.59 digital signature authenticated transactions eliminate the threat/vulnerability of evesdropping for account number harvesting, but it also eliminates the threat/vulnerability of data breaches for account number harvesting aka the harvesting could still go on, but the threat/vulnerability of fraudulent transactions as a consequence of harvesting is eliminated ... note that phishing attacks for the purpose of account number harvesting is also eliminated as a threat/vulnerability ... phishing can still go on, account numbers cna still be harvested, the account numbers are useable for fraudulent transactions w/o the digital signature. misc. past posts mentioned bi-model transaction distribution and/or having suggested employee fbi background checks as part of merchant certification process. http://www.garlic.com/~lynn/aadsm6.htm#terror3 [FYI] Did Encryption Empower These Terrorists? http://www.garlic.com/~lynn/aepay10.htm#83 SSL certs & baby steps http://www.garlic.com/~lynn/2001j.html#5 E-commerce security???? http://www.garlic.com/~lynn/2001j.html#54 Does "Strong Security" Mean Anything? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]