Re: Some thoughts on high-assurance certificates
Ed Reed wrote: Getting PKI baked into the every day representations people routinely manage seems desirable and necessary to me. The pricing model that has precluded that in the past (you need a separate PKi certificate for each INSURANCE policy?) is finally melting away. We may be ready to watch the maturation of the industry. In your long and interesting email you outlined some issues with the tool known as PKI. What I'm curious about is why, given these issues and maybe 100 more documented elsewhere **, you propose that: Getting PKI baked into the every day representations people routinely manage seems desirable and necessary to me. We have this tool. It has many and huge issues. What I don't understand is why the desire is so strong to put this tool into play, when it has singularly failed to prove itself? Where does the bottom-up drive come from? Why is it that what people do routinely isn't driven top-down, so that the tools they need are application driven, but is instead subjugated to the tools-first approach, even against such negative experience and theory? iang ** some here: http://iang.org/ssl/pki_considered_harmful.html - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Some thoughts on high-assurance certificates
Peter - In the absence of a legal framework for defining, limiting and allocating liability, there's going to be nothing much better than reputation-based assurance for certificates, I'm afraid. The issues are systemic, and broad. They begin with the registration problem you cite. The problem you describe derives from trying to use a credit-card liability limit oriented business process to support financial institution international letter of credit transactions. Won't happen. Can't happen. When insurers have looked at what they need in order to satisfy themselves that their liability for potential loss has been adequately limited, they've focused on a few areas: 1) is the liability being distributed sufficiently that each bearer can, indeed, meet their duties should losses be incurred? 2) is the likely hood of loss increased once the first lost has occurred? In other words, do the backers face the prospect of a catastrophic cascade of losses, or is the likelyhood of loss #2 unrelated to the prospect of loss #1? 3) are the parties in the system competent and able to perform their duties, and is that demonstrable or simply a matter of faith? The sort of high assurance certificates business I've investigated in the past has involved the need to support potential losses across the system in the $600,000 Million range. Beyond the capacity for any one insurer, and so requiring more than just good faith and judgment by one backer. There is a technical component to the solution that requires something more than well, I think so confidence in the duties you ask the parties in the system to perform. Lacking scientific, analytical support for claims that keys are protected, that their use is as intended, and that relying parties have documentary evidence of the claims being made and liabilities being accepted (or not), you fail both #1 and #3, above. The ability to stop a loss from cascading is crucial - Phishing is one thing, or 419 scams that prey on individuals, but breakdowns in trust that span an entire supply chain or an industry is something else entirely. One approach that's been proposed has been to focus on the minimal liability each player must accept, and to make sure they have concrete, demonstrable means to manage their risk. For instance, if an intermediary CA needs only to be able to guarantee two things - not to issue different certificates with the same identifier, and to protect the signer's private keys - they may be able to do that in a fashion that can be warranted by insurers. Interestingly enough, if you follow that approach, the whole PKI business turns into providing non-repudiable certificates of insurance or warranty. Insurance folks already have ways and means of calculating risk and pricing insurance and warranties. The certificate, signed by an insured CA, simply represents the insurance coverage provided for breach of the claims made in the certificate being signed. That the CA's certificate is signed means the claims in the certificate are warranted by the signer - an insurance company, for instance. The strength of the non-repudiation claims, and the breadth of claims that are warranted, are going to be based in the technology protections provided against fraudulent misrepresentation, and the processes (minimal as possible) associated with them. That includes high quality crypto, high assurance operating systems, and high integrity business practices. Each are measurable, comparable, Is this person an employee of this company? Dunno, who's paying their workman's comp (here's the insurance company certificate saying they're covered). If no one is paying, that's an indication. If someone stops paying, that's another indication (they let the certificate expire, in conjunction with the insurance coverage). Getting PKI baked into the every day representations people routinely manage seems desirable and necessary to me. The pricing model that has precluded that in the past (you need a separate PKi certificate for each INSURANCE policy?) is finally melting away. We may be ready to watch the maturation of the industry. Ed On Mon, Oct 31, 2005 at 8:38 am, in message [EMAIL PROTECTED], Peter Gutmann [EMAIL PROTECTED] wrote: A number of CAs have started offering high- assurance certificates in an attempt to... well, probably to make more money from them, given that the bottom has pretty much fallen out of the market when you can get a standard certificate for as little as $9.95. The problem with these certificates is that, apart from the fact that the distinction is meaningless to users (see work by HCI people in this area), they also don't fit the standard CA business processes. CAs employ people whose job role, and job expertise, lie in shifting as much product as possible as quickly as possible (as has already been demonstrated in the race to the bottom for supplying standard certificates), not in enforcing PKI theology on their clients.
Re: Some thoughts on high-assurance certificates
Ed Reed wrote: Getting PKI baked into the every day representations people routinely manage seems desirable and necessary to me. The pricing model that has precluded that in the past (you need a separate PKi certificate for each INSURANCE policy?) is finally melting away. We may be ready to watch the maturation of the industry. as part of some work on cal. fed. e-signature legislation ... one of the industry groups involved was the insurance industry. rather than PKI certificates, there was some look at real-time, online transactions ... where the liability was calculated on the basis of each individual transactions. The PKI certification model ... somewhat is paradigm for the letters of credit offline scenario from the sailing ship days. in the modern world ... that somewhat states that the certificate is issued for a period of time ... possibly one year ... and theoritically covers all operations that might occur during the period of that year ... ragardless of the number of operations that might be involved during that period ... where each operation carried liability. in the online scenario ... rather than having a stale, static certificate that carried with it implied liability for the period of time, independent of the number of operations ... each individual operation was a separatee liability operation. one could imagine insurance on a large tanker for a period of a year with regard to sinking. that translation to an electronic world ... would be that the tanker would have an arbitrary number of sailings ... and could sink on each sailing ... and having sunk on a previous sailing ... wouldn't prevent it from its next assignment and sinking again. the insurance in the credit card industry is that there is an online operation for each transaction ... and each transaction involves the merchant being charged a value proportional the transaction value. the liability is taken on each online transaction ... rather than for a period of time ... regardless of the number or magnitude of the transactions. this is somewhat with respect to my previous reply that the certification and assurance of the certificaqtion can be independent of the way that certification is represented. in the past for the offline world ... having a stale, static certificate representing that certification was useful ... because there was no way of obtaining real-time, online certification information. with ubuquitous online availability, there has been more and more transition to real-time online certification represwentation especially as the values involved increases (frequently the real-time, online certification representation can involve higher quality and/or more complex information ... like real-time aggregated information ... which is rather difficult with a stale, static represnetation creaed at some point in the past) - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Some thoughts on high-assurance certificates
A number of CAs have started offering high-assurance certificates in an attempt to... well, probably to make more money from them, given that the bottom has pretty much fallen out of the market when you can get a standard certificate for as little as $9.95. The problem with these certificates is that, apart from the fact that the distinction is meaningless to users (see work by HCI people in this area), they also don't fit the standard CA business processes. CAs employ people whose job role, and job expertise, lie in shifting as much product as possible as quickly as possible (as has already been demonstrated in the race to the bottom for supplying standard certificates), not in enforcing PKI theology on their clients. There are only a very small number of people who understand the theology behind certificates sufficiently to be able to explain the motivation behind the various steps in the process of issuing them, and none of them are going to be employed in doing certificate checking for CAs. Instead, the task will be managed by, and performed by, the same people who spam everything in the US that has a pulse with pre-approved credit card applications, loans, and similar items. Here's a real-world example of this process in action. A user approached a large public CA for a high-assurance certificate and specifically requested that his identity be checked thoroughly via his hard-to-forge paper documents. The CA did the usual standard-assurance checking (whois lookup, email to the whois contact address, caller ID check on the calling number, all easily spoofed), and then announced that the user had been pre-approved for the high- assurance certificate, *before* the user had supplied his authenticating documents. Made perfect sense, they'd done the equivalent of running a credit check before pre-approving a credit card or loan or whatever. Their proactive service and rapid attendance to the customer's needs put them ahead of the competition... ... except that this isn't something like a standard credit-check business. The user tried explaining this to the CA employees doing the checking, but they just didn't understand what the problem was. They'd done everything right and provided outstanding service to the user hadn't they? And therein lies the problem. The companies providing the certificates are in the business of customer service, not of running FBI-style special background investigations that provide a high degree of assurance but cost $50K each and take six months to complete. The same race to the bottom that's given us unencrypted banking site logons and $9.95 certificates is also going to hit high-assurance certificates, with companies improving customer service and cutting customer costs by eliminating the (to them and to the customer) pointless steps that only result in extra overhead and costs. How long before users can get $9.95 pre-approved high-assurance certificates, and the race starts all over again? Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
