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
At 05:00 PM 1/11/00 , [EMAIL PROTECTED] wrote: >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). 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. Further, CA's (well, the cautious ones) carefully limit their liability to third parties who rely on their statements - the customer of a CA is likely to be different from the end user who wants or needs to rely on the CA's assertion. The above model would change both of the above practices - putting the CA on the hook to the end user, and making a positive warranty about one or more aspects of the software's performance. At present, the risk ( = cost) of software failure rests on the purchaser/licensee, who's frequently unable to measure or calculate or otherwise account for it, so it's mostly ignored. Shifting that cost to the publisher/licensor or a CA or their insurers means that the cost will be measured and calculated and not ignored. Because end users mostly don't account for that cost, they're not likely to assign a high value to a transaction which shifts that cost to another party; but the party to whom the cost is shifted will want to value the transaction at its cost, or higher, because the cost can't and won't be ignored. The difference in apparent value of that cost-shifting transaction makes it unattractive to one or the other of its participants. Thus, while the scenario you describe is an attractive one (especially if I've got my end-user hat on), I suspect that it's unlikely to see the light of day any time soon. -- Greg Broiles [EMAIL PROTECTED] PGP: 0x26E4488C
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.
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
Peter Cassidy <[EMAIL PROTECTED]> on 01/10/2000 wrote > > I am engaged in an expansive and challenging authoring assignment > regarding PKI's rationale in the large e-commerce plexus. I'm casting > about for ideas on the killer PKI application. I'd like to hear any ideas > - however wild or domesticated - in this space. I can repay all kindnesses > with beer and whatever appreciations that providence provides I can bestow > in the future. 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
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
the original design point for much of PKI was distributed credentials for non-face-to-face, offline, electronic ... i.e. parties that had no prior business relationship and at the moment performing authentication function the relying party wasn't online (analogous to letters of credit in the days of sailing ships long before there was electronic connectivity). frequently online authentication provides higher quality, specifically targeted and more timely information that could be available with a generalized credential created sometime in the past. Some trade-offs are the descreased cost of offline vis-a-vis online authentication transaction and the reduced quality and/or timelyness of the information (stale vis-a-vis current). Online costs are drastically dropping as internet and related technologies become pervasive. So traditional PKI opportunity would appear to be 1) authentication circumstances involving volume costs that have to come in below the dropping online costs (but can still cover the cost of a PKI infrastructure), 2) authentication circumstances &/or transactions that aren't dependent on timely information, and 3) wouldn't require a combination of offline & online (since an online authentication operation can always subsum any of the offline pieces, eliminating duplication of infrastructures). Majority of existing e-commerce paradigms involve parties with 1) either direct prior relationship or indirect prior relationship thru some financial institution, 2) account-based timely &/or aggregated nformation, and 3) online operation. Into such an environment, PKI needs to find a thread between the existing paradigms that doesn't require online access &/or account-based timely/aggregated information between parties with no prior relationship. Peter Cassidy <[EMAIL PROTECTED]> on 01/10/2000 03:08:00 PM To: [EMAIL PROTECTED] cc: [EMAIL PROTECTED], [EMAIL PROTECTED] (bcc: Lynn Wheeler/CA/FDMS/FDC) Subject: Killer PKI Applications Friends, I am engaged in an expansive and challenging authoring assignment regarding PKI's rationale in the large e-commerce plexus. I'm casting about for ideas on the killer PKI application. I'd like to hear any ideas - however wild or domesticated - in this space. I can repay all kindnesses with beer and whatever appreciations that providence provides I can bestow in the future. Regards and thanks, Peter 617 491 2952
Re: Killer PKI Applications
On Mon, Jan 10, 2000 at 06:08:00PM -0500, Peter Cassidy wrote: > > Friends, > > I am engaged in an expansive and challenging authoring assignment > regarding PKI's rationale in the large e-commerce plexus. I'm casting > about for ideas on the killer PKI application. I'd like to hear any ideas > - however wild or domesticated - in this space. Trust management in a cash based world. With digital cash, I expect it to become much more tempting to hit-and-run; without a trust system to limit this, digital cash will not be able to take off to its full potential. Iff digital cash is able to take off somewhat without fully functional PKI, I believe it will pull PKI up with it. Eivind.
