I am not at all keen on languages for describing how to analyze policy either.
So I don't think we can hope to develop a system that allows the user to define their own policy. Even trying to do that client side is likely to fail. So I see two options. Either the user trusts the browser provider to choose the right policy for them or they choose some agent to act on their behalf. The user can choose between trustycorp red label and trustycorp black label security policies. But micromanaging when a cert is to be accepted or not is not going to work. The other side of security policy I can see working is when a site makes a statement 'this is how our security configuration should look'. Now such a statement is not necessarily going to be an infalible indicator that a policy violation is some sort of attack, see DKIM. But just as DKIM records are useful to spam management companies, security policy statements do have some use. On Thu, Feb 2, 2012 at 5:21 PM, Daniel Kahn Gillmor <[email protected]> wrote: > [quoting from two separate e-mails] > > dkg wrote: > >> So that leaves us with option (1), which has the sticky issue of needing >> to gather these personal/idiosyncratic requirements from users and >> interpret them into some sort of coherent technical policy. I know we >> can't solve those UI issues on this list, but i'd hope that any proposed >> solutions will at least consider the need to adjust for the user's >> circumstances and propose some kind of reasonably coherent policy >> approach to account for those circumstances. > > > On 02/02/2012 04:25 PM, Jon Callas wrote: >> >> On Feb 2, 2012, at 12:50 PM, Phillip Hallam-Baker wrote: >> >>> We are never going to achieve perfect security for either our users or >>> ourselves. >> >> Which is why we should stick to mechanism over policy. > > I think i'm in agreement with you here, Jon, and i hope i haven't > confused the matter by my use of the word "policy" in the above > paragraph. I'd appreciate clarification if you think i'm misunderstanding. > > The mechanism(s) we build need to be capable of implementing the user's > policies, as expressed in some coherent (and hopefully comprehensible) > way. But in designing these systems, we should not presume to set > policy for all users. > > Choice of mechanism seems likely to affect the range of possible > supported policies, though (e.g. if presenting a single, standard X.509 > certificate is the only mechanism a server has to introduce itself, > there's no way to express or implement a client's policy that requires > corroboration from independent parties). So i don't think we can fully > avoid discussion of policy, if only to trot out example policies to see > if a proposed mechanism can support them. > > Regards, > > --dkg > _______________________________________________ > therightkey mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/therightkey -- Website: http://hallambaker.com/ _______________________________________________ therightkey mailing list [email protected] https://www.ietf.org/mailman/listinfo/therightkey
