Re: Killer PKI Applications
your comments don't appear to be inconsistent with Jane Winn's writings on PKIs for instance her paper:: Hedgehog and Fox: PKI and Plublic Private Sector Risk Management The Hedgehog and the Fox: Distinguishing Public and Private Sector Approaches to Managing Risk for Internet Transactions, 51 ABA Administrative Law Review 955 (1999) This article argues that much recent and proposed electronic commerce legislation is based on flawed assumptions regarding risk management and the practical utility of current electronic commerce technologies. Such flawed legislation would produce a loss allocation system that would undermine incentives that currently exist to improve the technological infrastructure of Internet commerce. This paper was presented at a conference at American University in March 1999. http://www.smu.edu/~jwinn/hedgehogfox.htm or other papers at her site: http://www.smu.edu/~jwinn/ Greg Broiles [EMAIL PROTECTED] on 01/12/2000 01:47:04 AM To: Lynn Wheeler/CA/FDMS/FDC@FDC, "Bill la Forge" [EMAIL PROTECTED] cc: "bram" [EMAIL PROTECTED], "Peter Cassidy" [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Killer PKI Applications . While this would certainly be an interesting goal to achieve, I think it's worth remembering that current software industry practice is for the software publishers themselves to disclaim all or almost all warranties regarding the performance of their software or its lack of errors .. so you're asking CA's to guarantee something that publishers themselves don't, at present.
Re: Killer PKI Applications
digital signature enhanced radius (for ISP access authentication, i.e. replacing the password with public key in the authentication database and replacing the password with digital signature on authentication transactions) and in-coming address spoof filtering at ISPs (similar to intranet address spoof filtering for packets coming in from the internet, the ISPs would do address spoof filtering on packets coming into the internet from their customers) would go a long way for addressing a lot attacks (w/o requiring PKI). then for things like denial-of-service attacks (w/o address spoofing) ... account-based infrastructures would still use account-based public key transactions. In the case of boundary pre-filtering for things like denial-of-service attacks ... there is still trade-off with ASN.1 decoding public key ops that are still computationally intensive ... can be greater than TPC-C (for most of the current e-commerce transactions there would still have account-based authentication processing ... boundary pre-filtering represents duplication of effort could lead to faster resource exhaustion). It is likely then that a lot of the non-addresses-spoofed attacks would be from compromised machines (given ISP authentication incoming packet address spoof filtering by ISPs). Part of the issue is that almost all current e-commerce is transactional account-based paradigm (because of requirements for information timeleness and/or information aggregation). Part of the PKI design point/advantage is targeted to peer-to-peer, anarchy, offline, lacking any account infrastructures. Work on compromised machine exploits still has quite of bit of work to do and PKI might play in program execution authentication ... say next generation of virus checkers also check for valid program/executable digital signatures. Even then there is a design trade-off between having the visus checker include a (account) table of acceptable public-keys vis-a-vis each program having an appended certificate in addition to the digital signature ... and the virus checker only having a table of CA public keys. Does the user want to pass approval on only the list of trusted CAs or does the user want to pass approval on each individual developer's public key? Once the user decides not to trust the CA as to whether programs from individual vendors are to be accepted ... then the user creates their own table of acceptable public keys (not relying on the CA/PKI trust infrastructure). bram [EMAIL PROTECTED] on 01/11/2000 10:41:32 AM To: Lynn Wheeler/CA/FDMS/FDC@FDC cc: Peter Cassidy [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Killer PKI Applications The first thing something needs to be a killer application is to be an application. The problem with PKI is that it isn't an application, it's a system. A killer app needs to have a very specific purpose, and needs a very immediate motivating factor for it's use. Think web browser. I'm more than a little bit skeptical that the world has much use for PKI just yet. PKI is useful for stopping active attacks, but right now almost everything on the internet is subject to passive attacks. Fix the first problem first, only then will it become clear how to solve the second problem. -Bram
Re: Killer PKI Applications
Claim is that the draft X9.59 financial industry standard (for all retail payments) could provide the level of integrity that would justify better than card/consumer present rates; i.e. the level of the integrity of the transaction is at least card present ... and the characteristic of X9.59 makes the account number pretty much worthless in non-signed transactions (i.e. even if every account number from X9.59 transactions were kept at a merchant server database ... and that database was compromised, the information could not be used for fraudulant transactions). One of the charters to the X9A10 working group for X9.59 was to preserve the integrity of the financial infrastructure with only a digital signature and be applicable to all retail based payments. The X9.59 mapping to existing payment card infrastructures, while relying on digital signatures does not rely on certificates and/or associated PKI/CA infrastructures. For more information see various references at: http://www.garlic.com/~lynn/ Randy Witlicki [EMAIL PROTECTED] on 01/11/2000 04:15:07 PM Please respond to Randy Witlicki [EMAIL PROTECTED] To: Peter Cassidy [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] cc:(bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Re: Killer PKI Applications The killer app should make somebody very rich. Perhaps where the consumer can make an online purchase, same as now with an SSL browser link, but they are using a credit card from "Hettinga National Bank" where the consumer gets a 1/2 percent rebate and the merchant gets charged 1/2 percent less than other credit cards (to encourage the merchant to recommend Hettinga National Bank to their customers). This would likely require disintermediation of of various finanacial processing links, maybe PKI, and perhaps even Digital Bearer Certificates. In this case, PKI is probably a Business-to-Business backend tool. Or have I been mis-reading Bob's cogitating and rants ? - Randy - For help on using this list (especially unsubscribing), send a message to "[EMAIL PROTECTED]" with one line of text: "help".
Re: Killer PKI Applications
the other problem with the CA approach is what is the CA certifying. Are they purely certifying the name of the company producing software applications ... or are they certifying every application that each software company produces. If I have to decide every company that I'm willing to accept software from ... then I've gone to a per company process that can be done with online authority and I'm maintaining a list of per company-based accpetable software sources. I don't need am not using a hiearchical CA-based trust infrastructure (possibly other than in a purely contrived manner). For the CA-based trust infrastructure to work for this scenerio ... the CA needs to be asserting the trust/quality/integrity of applications produced by each software company (so that I only need to record CA-level trust decisions) ... once I need to record vendor-level trust decisions then I've truncated any trust hierachy (embodied by a CA which then becomes superfulous/redundant). "Bill la Forge" [EMAIL PROTECTED] on 01/11/2000 01:19:34 PM To: Lynn Wheeler/CA/FDMS/FDC@FDC, "bram" [EMAIL PROTECTED] cc: "Peter Cassidy" [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Killer PKI Applications Once the user decides not to trust the CA as to whether programs from individual vendors are to be accepted ... then the user creates their own table of acceptable public keys (not relying on the CA/PKI trust infrastructure). Part of the problem with taking the CA approach is in dealing with multiple roots. We've drilled down on this problem a few times and having a signed list of acceptable keys is a solution that keeps coming back up. Frankly, I think this is an area where XML is going to play quite well. And I'm delighted with the latest draft on XML-based digital signatures: http://www.w3.org/TR/xmldsig-core/ Bill la Forge, CTO JXML, Inc.
