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
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?
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
the current draft, it essentially says that the user agent must do
when signature validation fails, but what it does is up to the
I don't think it is acceptable to leave this decision unspecified; here is
of my rationale:
Your rationale, it seems to me, argues for leaving the action unspecified
spec. If we pick a particular security policy in the spec, we preclude the
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
policies that can be configured by a system administrater. All of these
*NOT* specifying these semantics in the spec. Validation belongs to some
working group as it goes well beyond just checking email signatures.