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 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 | in a facility that processes | 16345 Englewood Ave > 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
