3 ms·
We need dynamically selectable trust. I don't mean the simple ability exposed in most browsers to add/remove certs. That still assumes one set of trust that us
by pdkl95 11y ago
We need dynamically selectable trust.
I don't mean the simple ability exposed in most browsers to add/remove certs. That still assumes one set of trust that used globally, which is completely incorrect.
Maybe I don't trust $COUNTRY to handle their root certificate for most uses. Currently we handle that case by removing the cert completely. Trust, however, is not a simple boolean value, and maybe I do trust that certificate for $COUNTRY's official government pages. I should be able to specify that I trust some certificate for some domain (or other, non-domain based use!), but not for others.
As another example, consider a local Web Of Trust. whenever Web Of Trust is brought up, people complain about the difficulty of key exchange. Well yes, that's a difficult problem, but there is no reason that it has to be solved for all use-cases before anybody starts using it. Maybe a circle of (usually physically local) local friends want to have secure communications. They can share a key in person easily, and so it should be easy to give access to a private forum by simply sharing a key/cert on a USB disk.
We can currently approximate those cases, but it is not well supported, and is certainly not something that most users would be expected to be able to do. We can fix some of that with a better UI, but I'm suggesting a far more fundamental change, because actually solving problems like key sharing will not be easy, and I suspect they will only be solved once we have infrastructure in place. HTTP was successful because it did not require that everybody implements the full, fairly complex specification. Instead, we had a fluid, extensible protocol that allowed anybody to extend it, and that allowed for the development of a wide variety of software.
The problem with traditional PKI (at least as implemented) is that it assumes that we can assign an absolute trust value to anything. In reality, trust is relative, and may in fact have multiple values at the same time. Until software is designed around those realities, it will always be inflexible and insecure for any use case where the needed trust assumptions do not reflect the assumptions made by the authors the software.
Unfortunately, I'm a old-style UNIX nerd who is fine with using GPG, and I'm not sure what the UI for a dynamic-trust system would even look like. sigh
- calgoo 11y agoI agree with you on this. The only way we can trust, is if we know thee people. And even then it's normally not 100%. For example, if you want to take someone out to a nice restaurant. You might ask friends and colleagues, but some might have different tastes or some might just have an incentive for you to go there. So once you have a few options, you can then Google those choices to see if they match what you are looking for. So for something as simple as a dinner, we are already doing several checks to validate the place and comments that people have made. The issue comes when the web is involved, as we expect instant reaction and response. We also hate having to answer repeated question as it interrupts our though process. So we need a web of trust, but also with the option of sharing in you personal web of trust. So for an example, I want to go to page: newcorp.com, but the certificate warns me it's not allowed by my chosen web of trust. So I query so see if anyone on my local web of trust has an allowed setting for this page. It finds that Bob does, but I have set Bob as a low trust setting so it won't allow me to go there, but it will say that Bob's web of trust does. Do you trust Bob's choices to allow access? This would at least allow people to make choices of trust that they understand. As humans we thrive in groups, as long as they are not to big, and the Internet is a huge group of people. It's a lot easier to choose if I trust Bob from the office then for example Google, ICAN or even Mozilla. That way, the non-tech people can see the web of trust of their tech friends and make a choice on what they have set. It's a thought, but I think we need to bring trust and security back to our local, controllable environment. The Internet will keep on integrating with our every day life's in ways that are hard the even think about now. So we need to figure out security and trust now, not once my jacket is talking to the street lamp telling it that the light should be lower because I had eye surgery yesterday and should not have strong lights around me. How the hell do we add security to all those types of functions that will come. Sorry for the long rant, but it's something that worries me about the future.
- userbinator 11y agoThey can share a key in person easily, and so it should be easy to give access to a private forum by simply sharing a key/cert on a USB disk The truly paranoid would probably prefer a printout on paper; I've actually done this before with HTTPS self-signing.
- e12e 11y agoOne idea that might be both workable, and possible would be to a) have reasonable way to choose CAs (not just, oh this, XYX corp sounds trustworthy, I'll let them in), and b) have a capabilities system that's not entirely embedded in the CA system. So, I could have my own CA, or GNU/Debian could have their own CA -- and I/they could sign a capabilites document allowing NORID to sign off on .no-domains, but not on any other TLDs. Or I could trust Microsoft and Google with their own domains (a whitelist), and nothing else. Such lists could be distributed in a similar way to certs and revocation lists -- and might take us from a 100% broken system, to a 80% working system -- which is probably as good as automated(ish) trust is going to get anyway. [edit: I don't think delegating trust is completely wrong. It's insane to think that 10 billion people will get the required knowledge to make good trust decision for software etc. Most people can't even do that for normal stuff like money. Anyone remember nt-bugtraq? I loved that. I still can't read official MS security bulletins. I usually only see that there's a patch, rated at some comically low importance, and usually have no idea if I really need the patch or not. And I consider myself rather technical, and while windows isn't my prime platform, it's not completely alien either. The summaries on nt-bugtraq was gold. "This is remote root in default install of IIS". Ok, I don't run IIS. Note-to-self, make sure this patch is installed if I do. "This is local login bypass in GINA". Ok, lets install that, prioritize public facing machines. Etc. That is why I'd like the ability to trust third-parties to help manage trust. I don't think MS is maliciously complicating their security bulletins, I just think they're trapped in an obscure dialect of Coroporatese that I don't speak, and really have no desire to learn. Maybe I should order a few copies of "On Writing Well" and ship them to Seattle, att: MS security team.] [ed2: Actually: https://technet.microsoft.com/en-us/library/security/ms15-jun.aspx https://technet.microsoft.com/en-us/library/security/ms15-ju... is better than what I remember. Note that the page doesn't mention certificates, and the new update doesn't appear to be mentioned on: https://technet.microsoft.com/en-us/security/advisory https://technet.microsoft.com/en-us/security/advisory either.]