[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
