Re: Can we copy trust?
[Moderator's note: I'm letting just this one through, because I think Peter's point bears repeating. --Perry] [EMAIL PROTECTED] [EMAIL PROTECTED] writes: IT departments put corporate trusted CA certificates in employees computers. The US DoD puts their trusted root certificates in DoD computers. All these actions copy trust with high fidelity. They don't copy any trust at all, they copy a (usually expensive) cryptographic cookie that turns off browser warning messages. (They do copy the cookies with high fidelity though, if one bit is corrupted then the cookie becomes invalid). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Bill Frantz wrote: really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Toolhttp://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. that was one of the business case problems early in SSL for electronic commerce ... namely majority of ecommerce was with repeat sites ... while design point of digital certificates is for first time communication between strangers. the other factor that bounded what merchants would pay was liability in electronic commerce ... there were already paying significant interchange fees as part of protecting the consumer. certification authorities weren't looking at taking on any of that aspect. the combination has been pushing digital certificates into the no-value market segment ... which, in turn, further limits what would could be charged for. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ed Gerck wrote: Ben Laurie wrote: But doesn't that prove the point? The trust that you consequently place in the web server because of the certificate _cannot_ be copied to another webserver. That other webserver has to go out and buy its own copy, with its own domain name it it. A copy is something identical. So, in fact you can copy that server cert to another server that has the same domain (load balancing), and it will work. Web admins do it all the time. The user will not notice any difference in how the SSL will work. Obviously. Clearly I am talking about a server in a different domain. -- http://www.apache-ssl.org/ben.html http://www.links.org/ 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: Can we copy trust?
[Moderator's note: Please do not top post. --Perry] I am thinking that trust is a relationship. A trusts B. So if you start with A trusts B and you do some operation that results in C trusts B then you have not copied anything because A trusts B is not equal to C trusts B. You can't call that operation a copy. I can't think of any scenario where it even makes sense to talk about copying trust. The closest thing I can think of would be a document, or record in a database, or a certificate, or similar thing that reminds me that I trust X. That is consistent with Bill Frantz's comment on memory. (hi Bill) I can copy the reminder, but that doesn't copy the trust. The trust exists, it seems to me, with or without the reminder (even if I have temporarily forgotten about it). Kind regards, -Bill On Jun 2, 2008, at 6:24 PM, Ed Gerck wrote: Bill Frantz wrote: [EMAIL PROTECTED] (Ed Gerck) on Monday, June 2, 2008 wrote: To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. In my real-world experience, this way of gaining trust is only really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. Recognition = a channel of information memory = a channel of information When you look at trust in various contexts, you will still find the need to receive information from sources OTHER than the source you want to trust. You may use these channels under different names, such as memory which is a special type of output that serves as input at a later point in time. The distinguishing aspect between information and trust is this: trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel. In other words, self-assertions cannot transfer trust. Trust me is, actually, a good indication not to trust. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool http://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. Yes, where recognition is the OTHER channel that tells you that the value (given in the original channel) is correct. Just the value by itself is not useful for communicating trust -- you also need something else (eg, a digital sig) to provide the OTHER channel of information. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Bill Soley wrote: I am thinking that trust is a relationship. A trusts B. So if you start with A trusts B and you do some operation that results in C trusts B then you have not copied anything because A trusts B is not equal to C trusts B. You can't call that operation a copy. Trust is indeed expressed by relationships. And those relationships can be transmitted with proper consideration -- just not in your example. In the case of SSL certs, a simple file copy is enough. Cheers, Ed Gerck Addendum: Did you have a chance yet to read Kelly's paper? In that paper, he is looking for stuff that can't be copied -- because he hopes that such stuff is scarce and valuable. When copies are free, you need to sell things which can not be copied. Kelly says that we can't copy trust. So, if I have 100 servers for the domain example.com does this mean that I have to buy 100 trusted SSL certs from the CA? Or, is any copy of the SSL cert as trustworthy as the original? - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ed Gerck wrote: Bill Frantz wrote: [EMAIL PROTECTED] (Ed Gerck) on Monday, June 2, 2008 wrote: To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. In my real-world experience, this way of gaining trust is only really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. Recognition = a channel of information memory = a channel of information When you look at trust in various contexts, you will still find the need to receive information from sources OTHER than the source you want to trust. You may use these channels under different names, such as memory which is a special type of output that serves as input at a later point in time. It is useful and efficient to get trust from third parties, but not essential, imho. If you find yourself meeting someone for the first time in random circumstances, you can get to know them over time, and trust them, fully 2nd party-wise. Trust comes from events of risk and reward, not from channels. It just so happens that the best expressions of risk and reward are over independent therefore 3rd party channels. The distinguishing aspect between information and trust is this: trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel. Trust is an expression of something you may rely on. It has risks, liabilities, obligations, etc. Information does not (yet). In other words, self-assertions cannot transfer trust. Trust me is, actually, a good indication not to trust. Well. Actions speak louder than words. The *act* of a third party is to put their own reputation at risk if they say trust this 2nd person. This works if the two people are independent, but not if the two people are dependent (or the same). If they are independent, the costs incur to one party and the benefits incur to another party. So the independent cost of placing the reputation at risk is a significant event. You can rely on someone who will incur cost on your behalf. Saying trust me carries no risks because the benefits cancel out the risks. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool http://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. Yes, where recognition is the OTHER channel that tells you that the value (given in the original channel) is correct. Just the value by itself is not useful for communicating trust -- you also need something else (eg, a digital sig) to provide the OTHER channel of information. Attempting to cast trust as a aspect of channels is a technological approach, and will lead one astray, just as PKI did; trust is built on acts, of humans, and involves parties and events, risks and rewards. The channels are incidental. You can see this better in the study of negotiation. It is possible using this theorypractice to build trust, or to prove that no trust can be achieved. Negotiation is primarily a paradigm of two parties. (Economists will recognise it as game theory, prisoner's dilemma, perhaps agent-principal theory, etc.) Your comment that someone who says trust me is in fact signalling that they cannot be trusted ... is more clearly explained in negotiation. Often, someone will state up front that they want to find the win-win; which is a signal that they are in the win-lose, because real win-win is about actions not words, and words in this case would lead to a false sense of security. iang - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
On Mon, Jun 2, 2008 at 12:37 PM, Ed Gerck [EMAIL PROTECTED] wrote: In the essay Better Than Free, Kevin Kelly debates which concepts hold value online, and how to monetize those values. See www.kk.org/thetechnium/archives/2008/01/better_than_fre.php Kelly's point can be very useful: *When copies are free, you need to sell things which can not be copied.* The problem that I see and present to this list is when he discusses qualities that can't be copied and considers trust as something that cannot be copied. Kelly says trust cannot be copied at the top of his missive then doesn't list it as one of the eight generatives (I may be missing something but I think generative is the wrong word for something that cannot be copied but Kelly makes up his own definition for generative as something generated uniquely in place). Well, in the digital economy we had to learn how to copy trust and we did. For example, SSL would not work if trust could not be copied. After this list has destroyed the as implemented SSL model of trust over and over again, I'd be wary of claiming that SSL allows trust to be copied. Even so, SSL doesn't really copy trust, it works by only trusting the root. You don't have to trust the target site's self assertions about its own identity because you trust the root to only validate for sites that are what they claim to be. On Mon, Jun 2, 2008 at 3:29 PM, Ed Gerck [EMAIL PROTECTED] wrote: A copy is something identical. So, in fact you can copy that server cert to another server that has the same domain (load balancing), and it will work. Web admins do it all the time. The user will not notice any difference in how the SSL will work. Copying server certificates isn't copying trust either. In this case all servers with the same certificate are the same entity - at least to whatever needs to trust it. This whole thing with SSL and certificates is a red herring when it comes to copying trust. When I trust a site, that site doesn't have the trust, I do. To copy that trust, albeit with low fidelity, I merely have to communicate that trust to some other person. There are sites on the net that allow me to communicate my trust to others. eBay is probably making the most money at it with their seller reputation system. Sellers with a better reputation will attract more business and sell quicker and at higher prices. eBay makes more money when more product moves at higher prices but it cannot inflate seller's reputations because that would instantly be recognized by buyers and eBay would become a pariah and some other site would take over. Other sites like Amazon, Bizrate, and Angie's List provide similar trust distribution services with different underlying business models. This is a trust model that appears to work. If a eBayish/Verisigny company did an OCSP-like service that returned a current eBay-like reputation number for the trustworthiness of the site in question, I don't think we would need band aids like PetNames or even a hierarchical PKI. Sites could just use self-signed certificates with a field pointing to their reputation responder. Instead of trusted root certificates, browsers could have trusted reputation responder certificates. Microsoft would charge reputation responders to include their certificates, reputation responders would charge companies to maintain their reputations, everybody would make money. When a reputation responder goes bad, slashdot would have fun, Microsoft would pull their cert, there will be some vulnerable users that don't ever get updated responder certificate lists, and the entities that had trust housed at the bad responder will have to generate new certs and rebuild their reputation elsewhere. This, of course, doesn't have a chance of occuring because SSL works good enough and people will ignore the bad reputation warnings just like they ignore SSL warnings now. -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ben Laurie wrote: Obviously. Clearly I am talking about a server in a different domain. And we (Kelly and I) were talking about copying trust, where a copy is (as usual) a reproduction, a replication of an original. If you are copying trust from a domain, as represented by a SSL cert signed by a trusted CA, it should be a reproduction of /that/ trust -- not trust on a different domain. If you want to copy trust to a different domain, then we need to transfer the trust. This is also /possible/, as you know, as long as the issuing CA has set the CA bit in the SSL certificate. Object Signing CA certs must have the Object Signing CA bit set. In summary, in SSL you can both copy and transfer trust. Without further evidence, which can be provided in pvt if desired by anyone, (1) SSL is not such only example in the Internet; and (2) we can likewise copy and transfer trust in our social interactions, not just in our digital interactions. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
IanG wrote: Ed Gerck wrote: When you look at trust in various contexts, you will still find the need to receive information from sources OTHER than the source you want to trust. You may use these channels under different names, such as memory which is a special type of output that serves as input at a later point in time. It is useful and efficient to get trust from third parties, but not essential, imho. If you find yourself meeting someone for the first time in random circumstances, you can get to know them over time, and trust them, fully 2nd party-wise. Yes, and the OTHER channels needed for trust are exactly those time-defined channels that you set up as you get to know them over time. Each interaction, each phrase, each email exchanged is another channel. Still, you can be talking to Doris in a p2p interaction over months and never realize it's actually Boris. This can happen in personal meetings as well, not just online. The point being that (1) you need those other channels and can recognize them even if you are just in a p2p interaction; and (2) be careful because whatever channels you have, they will only span a certain, limited extent in the interaction that you want to trust, so your reliance space must be contained within that extent. Attempting to cast trust as a aspect of channels is a technological approach, and will lead one astray, just as PKI did; trust is built on acts, of humans, and involves parties and events, risks and rewards. The channels are incidental. Shannon's information theory is a general approach that, even though it has limitations as any other model, has allowed researchers to deal with both social and technical aspects of trust. The important point, contrary to what PKI did, is to base the technical definition of trust on the social mediation of trust that we have learned over thousands of years. Thus, when we look at linguistics and other areas where we find expressions of social experience and communication in a culture, we see that the unique, defining aspect of trust is that trust on something or someone needs /OTHER/ channels of information (where memory is also a channel) than the information channel we want to trust. This social-linguistic observation transfers directly to the definition we can use with information theory for the technical aspect of trust, allowing the /same/ model of trust to be used in both worlds, as: trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel. From this abstract definition, you can instantiate a definition that applies to any desired context that you want -- social and/or technical -- while assuring that they all have the same model of trust. Examples are provided at the top of http://mcwg.org/mcg-mirror/trustdef.htm As usual, information is defined as: information is that which is transferred from a source to a destination. If the same information is already present at the destination, there is no transfer. That's why information is surprise; there's no surprise if the information already exists at the destination. You can see this better in the study of negotiation. It is possible using this theorypractice to build trust, or to prove that no trust can be achieved. Negotiation is primarily a paradigm of two parties. You can use different models. I believe that trust is a more fundamental model than negotiation, as we can have trust without negotiation. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
[EMAIL PROTECTED] wrote: You don't have to trust the target site's self assertions about its own identity because you trust the root to only validate for sites that are what they claim to be. From the viewpoint of the user (which is the viewpoint used by Kelly), we see that trust can be copied when different users, accessing different servers for the same domain, do not know that they are using different copies of the /same/ SSL cert. In fact, no copy is less of an original than the original itself! We see that the trust relationship represented by that SSL cert can be copied without any loss, as many times as you wish (for the possible dismay of the CA). If the CA bit is set, trust can even be transferred to multiple domains, and the trust represented by each such SSL cert in each domain can be copied without limit as well. As to another point of your comment, the problem most people have with PKI is not that SSL does not work. SSL does not even need PKI. The problem can be explained in terms of extent of trust. If you don't define your extent of trust in a CA, for example in your acceptance policy of records signed by certs from a CA, you may run into difficulties. The difficulties are /solved/ (within your risk model) when you correctly define the extent of trust -- rather than just taking a trust in all matters attitude. For example, even though I do not trust a CA's CRLs, I may trust that CA to prevent rogue use of its private-key for signing end-user certs. This trust, limited by this extent, can be used in automating use of certs from that CA -- for example, only accept signatures from end-user certs of that CA if the cert is less than 31 days old (or, 15 days -- whatever your risk model says). Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
On Tue, Jun 3, 2008 at 1:05 PM, Ed Gerck [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: We see that the trust relationship represented by that SSL cert can be copied without any loss, as many times as you wish My understanding is that an SSL certificate is only a method to carry the assertion that the holder of the private key is the the subject named in the certificate (with possible limitations on the allowed uses of the private key). By using the certificate, one does not trust the subject - one does trust the signer of the certificate as an entity that verified the subject named in the certificate represents the actual subject (this is true even for self signed certificates grin/). Copying the SSL certificate does not copy trust but sometimes copying some certificates do copy trust. Say Alice browses around the web looking to buy a widget and when her browser hits a particular HTTPS protected site, it pops up an untrusted certificate warning. Alice goes and moves on to another site. Bob goes to the same site and his browser doesn't pop up the warning because Microsoft has automatically updated his computer's trusted CAs list. Bob's browser trusts the site and Bob trusts his browser so Bob buys the widget. Alice's browser didn't trust the site, and Alice, being a remarkable woman, actually paid attention to her browser and moved on. So we see, the trusted CA certificates do carry trust (heck, trusted is part of the name), and, when Microsoft copied the new trusted CA certificate into Bob's computer, Microsoft managed to copy trust. IT departments put corporate trusted CA certificates in employees computers. The US DoD puts their trusted root certificates in DoD computers. All these actions copy trust with high fidelity. But this method rings of an edict from on high, Thou shalt trust These methods still don't have the: // copy Alice's trust in Charlie to Bob Copy(Alice[trust--Charlie], Bob) capability. The low fidelity ways of Epinions and eBay seem to be the only examples I can come up with that allow for that type of trust copying. For example: // copy the trust in Charlie a large group of eBayers has to Bob MaybeCopy(eBayClaim.LargeGroup[trust--Charlie], Bob) The copy may or may not happen depending on Bob's feelings about the size of the group or the extent of the trust. Of course, the eBayesque trust copying happen in wetware. To move it to hardware would require an online protocol and method to register trust. I can see shades of the old PGP web-of-trust with added subtleties for timeliness and dispute resolution. As to another point of your comment, the problem most people have with PKI is not that SSL does not work. SSL does not even need PKI. I meant SSL as we use it - I believe the vast majority of SSL use involves a hierarchical PKI. I have rarely seen the use of pre-shared keys or self-signed certificates (which is technically still a PKI). -Michael Heyman - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
ADMIN: end of Can we copy trust discussion
I don't think anything new is being said in the Can we copy trust discussion, so I'm calling a halt to it. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ben Laurie wrote: Ed Gerck wrote: Ben Laurie wrote: But doesn't that prove the point? The trust that you consequently place in the web server because of the certificate _cannot_ be copied to another webserver. That other webserver has to go out and buy its own copy, with its own domain name it it. A copy is something identical. So, in fact you can copy that server cert to another server that has the same domain (load balancing), and it will work. Web admins do it all the time. The user will not notice any difference in how the SSL will work. Obviously. Clearly I am talking about a server in a different domain. Up until recently, you could buy a cert for one domain, use *it* to issue a cert for another domain, and the major web browsers wouldn't kick at the traces provided you sent both certs in the ssl handshake. Thankfully, they fixed that before *too* many phishers figured it out. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Can we copy trust?
In the essay Better Than Free, Kevin Kelly debates which concepts hold value online, and how to monetize those values. See www.kk.org/thetechnium/archives/2008/01/better_than_fre.php Kelly's point can be very useful: *When copies are free, you need to sell things which can not be copied.* The problem that I see and present to this list is when he discusses qualities that can't be copied and considers trust as something that cannot be copied. Well, in the digital economy we had to learn how to copy trust and we did. For example, SSL would not work if trust could not be copied. How do we copy trust? By recognizing that because trust cannot be communicated by self-assertions (*), trust cannot be copied by self-assertions either. To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. To copy trust, all you do is copy the information from those channels in a verifiable way and add that to the original channel information. We do this all the time in scientific work: we provide our findings, we provide the way to reproduce the findings, and we provide the published references that anyone can verify. To copy trust in the digital economy, we provide digital signatures from one or more third-parties that most people will trust. This is how SSL works. The site provides a digital certificate signed by a CA that most browsers trust, providing an independent channel to verify that the web address is correct -- in addition to what the browser's location line says. Cheers, Ed Gerck (*) Trust as qualified reliance on information in http://nma.com/papers/it-trust-part1.pdf and Digital Certificates: Applied Internet Security by J. Feghhi, J. Feghhi and P. Williams, Addison-Wesley, ISBN 0-20-130980-7, 1998. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Ed Gerck wrote: In the essay Better Than Free, Kevin Kelly debates which concepts hold value online, and how to monetize those values. See www.kk.org/thetechnium/archives/2008/01/better_than_fre.php Kelly's point can be very useful: *When copies are free, you need to sell things which can not be copied.* The problem that I see and present to this list is when he discusses qualities that can't be copied and considers trust as something that cannot be copied. Well, in the digital economy we had to learn how to copy trust and we did. For example, SSL would not work if trust could not be copied. How do we copy trust? By recognizing that because trust cannot be communicated by self-assertions (*), trust cannot be copied by self-assertions either. To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. To copy trust, all you do is copy the information from those channels in a verifiable way and add that to the original channel information. We do this all the time in scientific work: we provide our findings, we provide the way to reproduce the findings, and we provide the published references that anyone can verify. To copy trust in the digital economy, we provide digital signatures from one or more third-parties that most people will trust. This is how SSL works. The site provides a digital certificate signed by a CA that most browsers trust, providing an independent channel to verify that the web address is correct -- in addition to what the browser's location line says. But doesn't that prove the point? The trust that you consequently place in the web server because of the certificate _cannot_ be copied to another webserver. That other webserver has to go out and buy its own copy, with its own domain name it it. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ 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: Can we copy trust?
Ben Laurie wrote: But doesn't that prove the point? The trust that you consequently place in the web server because of the certificate _cannot_ be copied to another webserver. That other webserver has to go out and buy its own copy, with its own domain name it it. A copy is something identical. So, in fact you can copy that server cert to another server that has the same domain (load balancing), and it will work. Web admins do it all the time. The user will not notice any difference in how the SSL will work. Another point: When we talk about a copy, we're technically talking about a transmission. To copy a web page to your hard disk is to transmit bits from the web server to your disk. To say that we cannot copy trust would, thus, be the same as to say that we cannot transmit trust. But we can and do transmit trust -- we just have to do it right (see refs in previous post). Similarly, we have to do it right when we transmit data (for example, if we don't have enough bandwidth or if there is too much noise, the data will be not be 100% transferred). Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
[EMAIL PROTECTED] (Ed Gerck) on Monday, June 2, 2008 wrote: To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. In my real-world experience, this way of gaining trust is only really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool http://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. Cheers - Bill - Bill Frantz| The first thing you need when | Periwinkle (408)356-8506 | using a perimeter defense is a | 16345 Englewood Ave www.pwpconsult.com | perimeter. | Los Gatos, CA 95032 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Can we copy trust?
Bill Frantz wrote: [EMAIL PROTECTED] (Ed Gerck) on Monday, June 2, 2008 wrote: To trust something, you need to receive information from sources OTHER than the source you want to trust, and from as many other sources as necessary according to the extent of the trust you want. With more trust extent, you are more likely to need more independent sources of verification. In my real-world experience, this way of gaining trust is only really used for strangers. For people we know, recognition and memory are more compelling ways of trusting. Recognition = a channel of information memory = a channel of information When you look at trust in various contexts, you will still find the need to receive information from sources OTHER than the source you want to trust. You may use these channels under different names, such as memory which is a special type of output that serves as input at a later point in time. The distinguishing aspect between information and trust is this: trust is that which is essential to a communication channel but cannot be transferred from a source to a destination using that channel. In other words, self-assertions cannot transfer trust. Trust me is, actually, a good indication not to trust. We can use this recognition and memory in the online world as well. SSH automatically recognizes previously used hosts. Programs such as the Pet Names Tool http://www.waterken.com/user/PetnameTool/ recognize public keys used by web sites, and provide us with a human-recognizable name so we can remember our previous interactions with that web site. Once we can securely recognize a site, we can form our own trust decisions, without the necessity of involving third parties. Yes, where recognition is the OTHER channel that tells you that the value (given in the original channel) is correct. Just the value by itself is not useful for communicating trust -- you also need something else (eg, a digital sig) to provide the OTHER channel of information. Cheers, Ed Gerck - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
