I stated that I didn't think we should specify a particular security
policy, but that we also shouldn't just leave it unspecified. My proposal
has a SHOULD for configurability (by a system administrator, as you
suggested), but failing that, has as neutral a policy as possible (i.e.,
let the recipient decide). Some environments are large enough that they get
products trailored to their requirements, but most of us just have to
choose from what's available in the marketplace. If we leave it
unspecified, then some implementors may hardcode one or another particular
decision, which is in effect hardcoding a particular security policy. At
least, if the recipient is allowed to decide, then it supports a procedural
security policy.
I also proposed a return status mechanism which can be used both for
configuration and by automated processes. Because it is specified in the
spec, it is interoperable.
Does anyone feel we can make configurability mandatory?
elliott ginsburg
At 01:21 PM 4/7/98 , Bob Relyea wrote:
Elliott Ginsburg wrote:
I want to propose a change to how signature validation failure is
handled. In
the current draft, it essentially says that the user agent must do
something
when signature validation fails, but what it does is up to the
implementation.
I don't think it is acceptable to leave this decision unspecified; here is
some
of my rationale:
Your rationale, it seems to me, argues for leaving the action unspecified
in the
spec. If we pick a particular security policy in the spec, we preclude the
use of
S/MIME in shops which have different security policy.
Some products targeted for specific environments will implement a policy
consistant with that environment. Many products will provide flexible
validation
policies that can be configured by a system administrater. All of these
argue for
*NOT* specifying these semantics in the spec. Validation belongs to some
other
working group as it goes well beyond just checking email signatures.
bob