Re: browser vendors and CAs agreeing on high-assurance certificat es
Steven M. Bellovin wrote: > In message <[EMAIL PROTECTED]>, Ben Laurie writes: >> Bill Frantz wrote: >>> On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote: >>> I don't see why not - the technical details actually matter. Since the servers will all share a socket, on any normal architecture, they'll all have access to everyone's private keys. So, what is gained by having separate certs? >>> I responded in private email: >>> With a POLA architecture, perhaps on a capability OS (dream, dream), they might not share access to the private keys. However, given current software, I grant your point. >>> Ben responded that I should post my comments to the list. >>> >>> There are two scenarios I see as being viable for separating the private >>> keys with a security barrier. One is the single machine case alluded to >>> above. Here the private keys would be in separate security domains, and >>> the common part of the web server, which listens on the socket, would >>> read the initial data on the TCP connection, select the correct security >>> domain, and "pass" the connection to that domain. While the common part >>> could continue to examine all the data, those data would be encrypted, >>> so the it would have the same access as any other untrusted node in the >>> path. >>> >>> The other scenario involves a network switch which performs the function >>> of the common code of the web server. It uses network address >>> translation to forward the connection's packets to the back-end computer >>> with the correct private key. Here the keys are protected by being kept >>> on separate computers. >> This would defeat the reason people share IP addresses, which is so they >> can share a single machine to reduce costs. Of course, a capability OS >> would permit this whilst separating keys, as you said. >> > It doesn't have to be a capability-based OS; one could easily envision > a (ahem) alternate browser strategy accomplish it. Consider, to pick a > non-random example, Apache. Apache 2.0.x (and I think 1.y, but I don't > run it so I can't be sure) forks several child processes to actually > serve the pages. What if the directives contained an > optional User directive that specified the uid each virtual host should > run as? You could have different processes for different virtual hosts. Apache 1.x does indeed service each connection within its own child process. Apache 2.x actually has a more flexible mechanism: it uses things called MPMs (Multi-Processing Modules) which choose how connections are handled. Some of them use threading and some use processes and some use both. There is an MPM called "perchild" which does exactly what you want: http://httpd.apache.org/docs/2.0/mod/perchild.html - sadly, it is not currently functional, though I'm sure that either money or time would make it so. > Yes, that would require more bookkeeping on the part of Apache; it > would also require more (perhaps many more) processes running > simultaneously. I think this is certainly a risk. > Both of those are much smaller changes than a > capability-based OS. (Hmm -- who was it who noted that capability- > based systems were the wave of the future, and always would be?) Someone firmly rooted in the past, perhaps? > A final note -- multiple IP addresses is not the same as multiple > machines. Lots of hosting companies dedicate an IP address to each > customer, but put them all on a single machine. True, but at least with multiple IPs you can bind separate instances of the webserver to each IP on conventional OSes, unlike name-based virtual hosting. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
In message <[EMAIL PROTECTED]>, Ben Laurie writes: >Bill Frantz wrote: >> On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote: >> >>> I don't see why not - the technical details actually matter. Since the >>> servers will all share a socket, on any normal architecture, they'll all >>> have access to everyone's private keys. So, what is gained by having >>> separate certs? >> >> I responded in private email: >> >>> With a POLA architecture, perhaps on a capability OS (dream, dream), >>> they might not share access to the private keys. However, given current >>> software, I grant your point. >> >> Ben responded that I should post my comments to the list. >> >> There are two scenarios I see as being viable for separating the private >> keys with a security barrier. One is the single machine case alluded to >> above. Here the private keys would be in separate security domains, and >> the common part of the web server, which listens on the socket, would >> read the initial data on the TCP connection, select the correct security >> domain, and "pass" the connection to that domain. While the common part >> could continue to examine all the data, those data would be encrypted, >> so the it would have the same access as any other untrusted node in the >> path. >> >> The other scenario involves a network switch which performs the function >> of the common code of the web server. It uses network address >> translation to forward the connection's packets to the back-end computer >> with the correct private key. Here the keys are protected by being kept >> on separate computers. > >This would defeat the reason people share IP addresses, which is so they >can share a single machine to reduce costs. Of course, a capability OS >would permit this whilst separating keys, as you said. > It doesn't have to be a capability-based OS; one could easily envision a (ahem) alternate browser strategy accomplish it. Consider, to pick a non-random example, Apache. Apache 2.0.x (and I think 1.y, but I don't run it so I can't be sure) forks several child processes to actually serve the pages. What if the directives contained an optional User directive that specified the uid each virtual host should run as? You could have different processes for different virtual hosts. Yes, that would require more bookkeeping on the part of Apache; it would also require more (perhaps many more) processes running simultaneously. Both of those are much smaller changes than a capability-based OS. (Hmm -- who was it who noted that capability- based systems were the wave of the future, and always would be?) A final note -- multiple IP addresses is not the same as multiple machines. Lots of hosting companies dedicate an IP address to each customer, but put them all on a single machine. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Bill Frantz wrote: > On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote: > >> I don't see why not - the technical details actually matter. Since the >> servers will all share a socket, on any normal architecture, they'll all >> have access to everyone's private keys. So, what is gained by having >> separate certs? > > I responded in private email: > >> With a POLA architecture, perhaps on a capability OS (dream, dream), >> they might not share access to the private keys. However, given current >> software, I grant your point. > > Ben responded that I should post my comments to the list. > > There are two scenarios I see as being viable for separating the private > keys with a security barrier. One is the single machine case alluded to > above. Here the private keys would be in separate security domains, and > the common part of the web server, which listens on the socket, would > read the initial data on the TCP connection, select the correct security > domain, and "pass" the connection to that domain. While the common part > could continue to examine all the data, those data would be encrypted, > so the it would have the same access as any other untrusted node in the > path. > > The other scenario involves a network switch which performs the function > of the common code of the web server. It uses network address > translation to forward the connection's packets to the back-end computer > with the correct private key. Here the keys are protected by being kept > on separate computers. This would defeat the reason people share IP addresses, which is so they can share a single machine to reduce costs. Of course, a capability OS would permit this whilst separating keys, as you said. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
On 12/24/05, [EMAIL PROTECTED] (Ben Laurie) wrote: >I don't see why not - the technical details actually matter. Since the >servers will all share a socket, on any normal architecture, they'll all >have access to everyone's private keys. So, what is gained by having >separate certs? I responded in private email: > With a POLA architecture, perhaps on a capability OS (dream, dream), > they might not share access to the private keys. However, given current > software, I grant your point. Ben responded that I should post my comments to the list. There are two scenarios I see as being viable for separating the private keys with a security barrier. One is the single machine case alluded to above. Here the private keys would be in separate security domains, and the common part of the web server, which listens on the socket, would read the initial data on the TCP connection, select the correct security domain, and "pass" the connection to that domain. While the common part could continue to examine all the data, those data would be encrypted, so the it would have the same access as any other untrusted node in the path. The other scenario involves a network switch which performs the function of the common code of the web server. It uses network address translation to forward the connection's packets to the back-end computer with the correct private key. Here the keys are protected by being kept on separate computers. Both approaches allow a web hosting ISP to protect its customers from each other. This mutual protection is much the same requirement as existed in the time-sharing systems KeyKOS was designed to support. Cheers - Bill --- Bill Frantz| gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Ben Laurie wrote: Ian G wrote: http://wiki.cacert.org/wiki/VhostTaskForce (The big problem of course is that you can use one cert to describe many domains only if they are the same administrative entity.) If they share an IP address (which they must, otherwise there's no problem), then they must share a webserver, which means they can share a cert, surely? Certainly they *can* share a cert. But a cert speaks to identity - at the human level the cert is supposed to (by some readings) indicate who the site is purporting to be and in some scenarios, there are people who think the cert actually proves that the site is who it claims to be. So regardless of the technical details of the underlying software (complex, I grant), websites SHOULD NOT share a cert. I don't see why not - the technical details actually matter. Since the servers will all share a socket, on any normal architecture, they'll all have access to everyone's private keys. So, what is gained by having separate certs? 1. Because the activity is being done "in the name of" the site. When a business "signs" or otherwise represents a site as purporting to be in the name of some business, we still want to do it in a way that separates out that business from every other. 2. The system operator has access to the private keys, yes, but he's just the agent, and this does not mean that anyone else has access. We have systems in place to separate out the protection of the keys from the rest of the business. Most small businesses have some level of cooperation where they share techies, systems, and other services, so it is probably more seen and more useful in the SOHO (small office home office) world. Of course, this is less interesting to the security world, because there isn't the money to pay for consultants there... All the more reason why the software should provide the best it can for free! I do agree that the process by which the additional names get added to the main cert needs to reflect ownership of the name, but that's a different matter. And I'm not claiming, btw, that this mechanism is better than the server name extension. However, I don't believe its as broken as some are claiming. Well, sure. For many uses it will be a useful stopgap measure, until SNI is deployed. It's only broken if you like a binary world, and you happen to fall on the zero side of the question. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Ian G wrote: > Ben Laurie wrote: >> Ian G wrote: > ... >>> http://wiki.cacert.org/wiki/VhostTaskForce > >>> (The big problem of course is that you can use >>> one cert to describe many domains only if they >>> are the same administrative entity.) >> >> >> If they share an IP address (which they must, otherwise there's no >> problem), then they must share a webserver, which means they can share a >> cert, surely? > > Certainly they *can* share a cert. But a cert > speaks to identity - at the human level the cert > is supposed to (by some readings) indicate who > the site is purporting to be and in some scenarios, > there are people who think the cert actually > proves that the site is who it claims to be. > > So regardless of the technical details of the > underlying software (complex, I grant), websites > SHOULD NOT share a cert. I don't see why not - the technical details actually matter. Since the servers will all share a socket, on any normal architecture, they'll all have access to everyone's private keys. So, what is gained by having separate certs? I do agree that the process by which the additional names get added to the main cert needs to reflect ownership of the name, but that's a different matter. And I'm not claiming, btw, that this mechanism is better than the server name extension. However, I don't believe its as broken as some are claiming. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Eric Rescorla wrote: > Ben Laurie <[EMAIL PROTECTED]> writes: >>> And we need SSL v2 to die so it doesn't interfere >>> with the above. >> Actually, you just disable it in the server. I don't see why we need >> anything more than that. > > The problem is that the ServerHostName extension that signals > which host the client is trying to contact is only available > in the TLS ClientHello. Sure, but if the server won't negotiate SSL 2, why is this a problem? -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Ben Laurie wrote: Ian G wrote: ... http://wiki.cacert.org/wiki/VhostTaskForce (The big problem of course is that you can use one cert to describe many domains only if they are the same administrative entity.) If they share an IP address (which they must, otherwise there's no problem), then they must share a webserver, which means they can share a cert, surely? Certainly they *can* share a cert. But a cert speaks to identity - at the human level the cert is supposed to (by some readings) indicate who the site is purporting to be and in some scenarios, there are people who think the cert actually proves that the site is who it claims to be. So regardless of the technical details of the underlying software (complex, I grant), websites SHOULD NOT share a cert. (by capitals I mean the RFC sense, not the shouting sense.) What we really need is for the webservers to implement the TLS extension which I think is called "server name indication." And we need SSL v2 to die so it doesn't interfere with the above. Actually, you just disable it in the server. I don't see why we need anything more than that. If browsers don't know what is available on the server, they send a Hello message that asks for what protocol versions and ciphersuites to use. This is the SSL v2 message, just in case so to rectify this situation we need to get all the browsers distro'd with SSL v2 turned off by default. The shorthand for this is "SSL v2 must die..." Thankfully, they did decide to do just that at last month's browser pow-wow. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Ben Laurie <[EMAIL PROTECTED]> writes: > Ian G wrote: >> Ben Laurie wrote: >> ... Hopefully over the next year, the webserver (Apache) will be capable of doing the TLS extension for sharing certs so then it will be reasonable to upgrade. >>> >>> >>> In fact, I'm told (I'll dig up the reference) that there's an X509v3 >>> extension that allows you to specify alternate names in the certificate. >>> I'm also told that pretty much every browser supports it. >> >> The best info I know of on the subject is here: >> >> http://wiki.cacert.org/wiki/VhostTaskForce >> >> Philipp has a script which he claims automates >> the best method(s) described within to create >> the alt-names cert. >> >> (The big problem of course is that you can use >> one cert to describe many domains only if they >> are the same administrative entity.) > > If they share an IP address (which they must, otherwise there's no > problem), then they must share a webserver, which means they can share a > cert, surely? Actually, the big problem if you run a virtual hosting server is that every time you add a new virtual domain you need a new cert with that domain in it. And that applies even if you put all the names in one cert. Really, the ServerHostName extension is better. >> What we really need is for the webservers to >> implement the TLS extension which I think is >> called "server name indication." >> >> And we need SSL v2 to die so it doesn't interfere >> with the above. > > Actually, you just disable it in the server. I don't see why we need > anything more than that. The problem is that the ServerHostName extension that signals which host the client is trying to contact is only available in the TLS ClientHello. -Ekr - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Ben Laurie wrote: > If they share an IP address (which they must, otherwise there's no > problem), then they must share a webserver, which means they can share a > cert, surely? this is a semantic nit ... certs are typically distributed openly and freely ... so potentially everybody in the world has free access to the same cert. what operations need is the same access to a high-assurance private key. given that there is access to a high-assurance private key ... then it is possible to scaffold various other operations. some of the issues surrounding private key high-assurance may preclude having replicated private keys, restricting use to a single physical entity. over ten years ago ... i helped a small isp set up a single server to host a larger number of different email domains ... which required doing several hacks/enhancements to sendmail. the early onset of some of the leading search engines started out with multiple-A records for load balancing and availability (i.e. dns having single host/domain name with a list of different ip-addresses) ... where they rotated the ip-addresses in the list. as their traffic ramped up, this wasn't sufficient ... in part because the ip-address lists got cached in a large number of different places ... as static lists. this resulted in the evolution of boundary routers that responded to the set of published ip-addresses and internally kept track of activity to backend servers ... and dynamically spread the load across an increasing/growing number of backends. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Ian G wrote: > Ben Laurie wrote: > ... >>> Hopefully over the next year, the webserver (Apache) >>> will be capable of doing the TLS extension for sharing >>> certs so then it will be reasonable to upgrade. >> >> >> In fact, I'm told (I'll dig up the reference) that there's an X509v3 >> extension that allows you to specify alternate names in the certificate. >> I'm also told that pretty much every browser supports it. > > The best info I know of on the subject is here: > > http://wiki.cacert.org/wiki/VhostTaskForce > > Philipp has a script which he claims automates > the best method(s) described within to create > the alt-names cert. > > (The big problem of course is that you can use > one cert to describe many domains only if they > are the same administrative entity.) If they share an IP address (which they must, otherwise there's no problem), then they must share a webserver, which means they can share a cert, surely? > What we really need is for the webservers to > implement the TLS extension which I think is > called "server name indication." > > And we need SSL v2 to die so it doesn't interfere > with the above. Actually, you just disable it in the server. I don't see why we need anything more than that. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Ben Laurie wrote: ... Hopefully over the next year, the webserver (Apache) will be capable of doing the TLS extension for sharing certs so then it will be reasonable to upgrade. In fact, I'm told (I'll dig up the reference) that there's an X509v3 extension that allows you to specify alternate names in the certificate. I'm also told that pretty much every browser supports it. The best info I know of on the subject is here: http://wiki.cacert.org/wiki/VhostTaskForce Philipp has a script which he claims automates the best method(s) described within to create the alt-names cert. (The big problem of course is that you can use one cert to describe many domains only if they are the same administrative entity.) What we really need is for the webservers to implement the TLS extension which I think is called "server name indication." And we need SSL v2 to die so it doesn't interfere with the above. iang - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
Ian G wrote: > >> BTW, illustrating points made here, the cert is for >> financialcryptography.com >> but your link was to www.financialcryptography.com. So of course Firefox >> generated a warning > > Indeed and even if that gets fixed we still have > to contend with: > > * the blog software can't handle the nature of a > TLS site (internal problems like non-working > trackbacks, internal links, posts, ...) > * the cert has to be shared with 3 other sites > * Firefox will still warn about it being a CAcert > signed certificate > * ... I'm sure there's more. > > Hopefully over the next year, the webserver (Apache) > will be capable of doing the TLS extension for sharing > certs so then it will be reasonable to upgrade. In fact, I'm told (I'll dig up the reference) that there's an X509v3 extension that allows you to specify alternate names in the certificate. I'm also told that pretty much every browser supports it. -- http://www.apache-ssl.org/ben.html http://www.thebunker.net/ ** ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ ** "There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit." - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
BTW, illustrating points made here, the cert is for financialcryptography.com but your link was to www.financialcryptography.com. So of course Firefox generated a warning Indeed and even if that gets fixed we still have to contend with: * the blog software can't handle the nature of a TLS site (internal problems like non-working trackbacks, internal links, posts, ...) * the cert has to be shared with 3 other sites * Firefox will still warn about it being a CAcert signed certificate * ... I'm sure there's more. Hopefully over the next year, the webserver (Apache) will be capable of doing the TLS extension for sharing certs so then it will be reasonable to upgrade. iang PS: SSL v2 must die! Wot, you mean you haven't turned it off in your browser yet? - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
| | >But is what they are doing wrong? | | | | The users? No, not really, in that given the extensive conditioning that | | they've been subject to, they're doing the logical thing, which is not paying | | any attention to certificates. That's why I've been taking the (apparently | | somewhat radical) view that PKI in browsers is a lost cause - apart from a | | minute segment of hardcore geeks, neither users nor web site admins either | | understand it or care about it, and no amount of frantic turd polishing will | | save us any more because it's about ten years too late for that - this | | approach has been about as effective as "Just say no" has for STD's and drugs. | | That's why I've been advocating alternative measures like mutual challenge- | | response authentication, it's definitely still got its problems but it's | | nothing like the mess we're in at the moment. PKI in browsers has had 10 | | years to start working and has failed completely, how many more years are we | | going to keep diligently polishing away before we start looking at alternative | | approaches? | I agreed with your analysis when I read it - and then went on to my next mail | message, also from you, which refers to your retrospective on the year and had | a pointer to an page at financialcryptography. So ... I try to download the | page - using my trusty Netscape 3.01, which with tons of things turned off | (Java, Javascript, background images, autoloading of images) remains my | work-a-day browser, giving decent performance on an old Sun box. | | Well, guess what: | | Netscape and this server cannot communicate securely | because they have no common cryptographic algorithm(s). | | So ... we have the worst possible combination: A system that doesn't work, | which is forced on you even when you don't care about it (I can live with | the possibility that someone will do a MITM attack on my attempt to read your | article). | | Sigh. BTW, illustrating points made here, the cert is for financialcryptography.com but your link was to www.financialcryptography.com. So of course Firefox generated a warning -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
| > Imagine a "E-commerce" front end: Instead of little-guy.com buying a cert | > which you are supposed to trust, they go to e-commerce.com and pay for a | > link. Everyone trusts e-commerce.com and its cert. e-commerce provides a | > guarantee of some sort to customers who go through it, and charges the | > little guys for the right. | | Do you mean like Amazon Marketplace and Amazon zShops? I think it's been | done already: | | http://www.amazon.com/exec/obidos/tg/browse/-/1161232/103-4791981-1614232 Well, yes, and eBay provides the same service. But how much protection are they providing for buyers? I think Amazon will cover the first $100 a customer paid. eBay gives you a bit of protection if you go with PayPal, but not a whole load - they rely on their reputation system. e-commerce.com would bring up a page saying: "We guarantee that transactions up to $nnn with this site will be to your satisfaction or your money back". The merchant would specify the maximum dollar value, and pay e-commerce.com based on the limit and, presumably, his reputation with e-commerce. (This is one way it might be set up - there are certainly other ways. And, even in this style, the entire wording of the guarantee would be something agreed upon between the seller and e-commerce. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
On 12/19/05 9:54 AM, [EMAIL PROTECTED] wrote: > Imagine a "E-commerce" front end: Instead of little-guy.com buying a cert > which you are supposed to trust, they go to e-commerce.com and pay for a > link. Everyone trusts e-commerce.com and its cert. e-commerce provides a > guarantee of some sort to customers who go through it, and charges the > little guys for the right. Do you mean like Amazon Marketplace and Amazon zShops? I think it's been done already: http://www.amazon.com/exec/obidos/tg/browse/-/1161232/103-4791981-1614232 -- Sidney Markowitz http://www.sidney.com - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: browser vendors and CAs agreeing on high-assurance certificat es
| 2) the vast majority of e-commerce sites did very few number of | transactions each. this was the market segment involving e-commerce | sites that aren't widely known and/or represents first time business. it | is this market segment that is in the most need of trust establishment; | however, it is this market segment that has the lowest revenue flow to | cover the cost of creating a trust value. ...which raises the interesting question of whether there is a role here for banks in their traditional role: As introducers and trusted third parties. Imagine a "E-commerce" front end: Instead of little-guy.com buying a cert which you are supposed to trust, they go to e-commerce.com and pay for a link. Everyone trusts e-commerce.com and its cert. e-commerce provides a guarantee of some sort to customers who go through it, and charges the little guys for the right. | there is actually a third issue for the vast numbers of low traffic | e-commerce merchants ... the lack of trust can be offset by risk | mitigation. it turns out that this market segment where there is | poissble litte reason for the customer to trust the merchant has had a | trust issues predating the internet ... at least going back to the | introduction of credit financial transactions. as opposed to trust, risk | mitigation was addressed in this period with things like reg-e and the | customer having a high level of confidence that disputes tended to | heavily favor the customer. this characteristics of risk mitigation, in | lieu of trust, then carried over into the internet e-commerce relm. Yup. This is the role E-commerce.com would play. Since e-commerce.com would actually be present in the transaction - as opposed to a distant cert authority - in principle it could charge in a way that made sense. If it's mitigating risk, the cost should be proportional to the risk - i.e., the size of the transaction and what e-commerce knows about little-guy and its history. -- Jerry - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
