comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]

[Miloslav Trmac]

----- Original Message -----
> > Imagine the user source having a high priority. If trust policy
> > information is present about a certificate in the user source, then the
> > system source is not consulted. So it's an either/or system, albeit per
> > certificate.
> >
> > Of course this may be flawed. If so, would be happy to hear details
> > about problems and complexity/use-case trade-offs involved.
> 
> This brings forth the classic question of system administration: If
> the System (OS) says "Trust X", but the System (Admin) says "Do not
> trust X", and the user says "Trust X", what's the (effective) trust
> policy? The Sys Admin would like the answer to be "Do not trust" -
> after all, they are the administrative role for the system.
> 
> Conversely, in a world where the System (Admin) says "Trust X", and
> the user wants to say "Do not trust X", then it seems desirable that
> the more restrictive policy is applied.
> 
> I don't have a good solution here, but there are several, and that was
> the problem that I was trying to articulate.

Looking at this purely from the enforcement view, user's policy should override the system one:
1) If the admin can limit what executables the user can run, the admin can also prevent the user from setting the user's policy, so the priority of the policies doesn't matter.
2) If the admin can't limit the executables run by the user, the user can always modify the program to ignore the system policy and connect anyway, so the admin doesn't have the power to dictate policy anyway.  (Of course, "modify the program" is a rather high bar to overcome...)

Looking at this from the view of "doing the right thing by default", the admin should be able to e.g. revoke a CA without worrying about the users overriding that decision - I'm tempted to classify this as an UI problem rather than a problem of designing a secure mechanism.
    Mirek