From: Mike Jenkins <[email protected]> Date: Wednesday, October 24, 2012 12:21 AM To: <[email protected]> Subject: Re: [therightkey] Improving Trust
> I don't think trust is that nebulous an idea for many things that people do > with browsers. We've got to stop convincing people that "this certificate is > okay", and start informing them "it's okay to enter a credit card number > here". > > I often wonder why the browser doesn't have the ability for me to label my > trust anchors with labels like "bank" and "school", and then indicate to me > when a certificate validation has terminated in a labeled trust anchor. How I > apply those labels is my policy - based on prior experience, or obtaining a > "fingerprint" from a letter from the bank, or what have you. It doesn't even > prevent me from working with other banks, unless I want to limit myself. This is along the lines of a browser feature I've wanted for a while the means for the user to indicate the nature of what they are doing i.e., I'm shopping or banking or doing medical stuff, etc. A narrow trust anchor store associated with purposes like these could allow the posture of the browser to vary based on what the user says they are doing. > > This would be even more useful for device apps, that could be initialized to > only use one trust anchor from the list. > > There have got to be ways to do this that are fairly straightforward, not too > tedious for youth and not too complicated for elderly folks. [Have I insulted > everyone yet? Alrighty then.] > > Mike > > On Tue, Oct 23, 2012 at 2:46 PM, Bill Frantz <[email protected]> wrote: >> On 10/23/12 at 10:35 AM, [email protected] (Rick Andrews) wrote: >> >>> ... IMO the browser vendors have not helped much to improve the status quo. >>> They created a trust system in which all CAs are trusted equally, and they >>> are reluctant to remove any CA's trusted roots from their browser. I'd like >>> to brainstorm how those issues can be addressed. >> >> Trust is such a nebulous idea. For example, I could trust by cousin to abuse >> alcohol before he died from alcohol-related causes. >> >> What I think we are trying to do is ensure that the user can rely on the >> normal clues to people use to correctly identify a web site (or other >> computer-mediated communication). Probably users use different visual, and >> possibly audible clues, but probably the primary clue they use is the look >> and feel of the web page. How do we get our public key based trust system to >> separate out the fishing sites? >> >> We have tried to train users to look at the browser's crome. To the extent we >> have been successful, we can now discuss how to improve both the use >> interface from the crome, and the underlying trust model that supports that >> interface. If we are going to assign differently levels of assurance to >> different CAs, we will need to reflect those different levels in the chrome >> UI. >> >> One way to improve the underlying trust model is to use more that one >> identification technique. We currently use only the PKIX/CA system. As Rick >> points out, all CAs are equal as far as our trust model is implemented. If we >> could notice that the last time we visited this site, it had the same public >> key, that would improve trust, giving us two paths of recognition. If we also >> got the same information through DANE, that would give us three paths. >> >> When these paths disagree, we have a problem. What do we do when the CA has >> issued a CRL with the site, but the public key is the same as the last time, >> and the site doesn't use DANE. What if site uses DANE and it says the key >> belongs to the site? Should we have more paths to establish identity, the >> number of possibilities will grow rapidly. >> >> >> Consider a nearly real world trust establishment problem. My son is driving >> from California to Pittsburg PA to go to collage. I receive a communication >> from him saying the car has needed major repairs and to please send him >> $2000. How do I establish trust in this communication. >> >> If the communication is two-way, a phone call for example, I can engage in a >> dialog similar to the security questions requested by web sites. If it is a >> voice call, I can use my built in voice recognition system. >> >> If the "send to" address for the money in on a logical route between CA and >> PA, I'll react differently than if it is in Nigeria. >> >> Etc. etc. >> >> Cheers - Bill >> >> ------------------------------------------------------------------------- >> Bill Frantz | Airline peanut bag: "Produced | Periwinkle >> (408)356-8506 <tel:%28408%29356-8506> | in a facility that processes >> | 16345 Englewood Ave >> www.pwpconsult.com <http://www.pwpconsult.com> | peanuts and other nuts." - >> Duh | Los Gatos, CA 95032 >> >> _______________________________________________ >> therightkey mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/therightkey >> <https://www.ietf.org/mailman/listinfo/therightkey> > > _______________________________________________ therightkey mailing list > [email protected] https://www.ietf.org/mailman/listinfo/therightkey
_______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
