Amanda,
You provide a good example. I agree with much of what you
have said. Perhaps we disagree over whether one creates a standard
framework for expressing some aspects of policy (vs. mechanism) or
whether this is viewed as outside of the standards context. I believe
that some of the policy aspects are local matters, but others have to
be uniform, or we run the risk of loosing interoperability or creating
an ambiguous environment. The latter is a serious concern in a
security context.
For example, in a global email system, without a framework
for expressing the processing requirements and the meaning of various
features, it will not be possible for implementors to provide products
that respond in a uniform, predictable fashion upon receipt of message
that employ these features. Signatures are a prime example of this.
if my email system tells me something has a valid signature, that is
not necessarily sufficient. How is the identity of the signer
expressed? Does it relate directly to the email address or is it an
ID in some other ID space? Was the signature validated relative to a
particular trust policy, and if so, how is the nature of that policy
expressed? One might like to be able to process email from a variety
of sources but be able to associate varying degrees of credibility to
the purported identity of the originator, based on some understanding
of how I acquired the public key for the signer and had it bound to an
identity. It is not clear that the current spec requires a compliant
implementation to provide such info, and Jim agreed with me that there
should be some text added to address this concern.
In general, security is not well served if the sender of a
message cannot anticipate how the security features of the message
will be "interpreted" by the recipient's mail system, or if different
recipient mail systems interpret these features in different ways.
Yes, this can be complicated. However, we run the risk of
promulgating security technology that confuses users, or gives them a
false sense of security, if we merely say "here are some features,
figure out what they do for you."
I'm curious. You noted that your customers wanted secure
email and hence your interest in settling on a spec soon. What do
your customers want from secure email? Which security features are of
greatest concern to them, e.g., confidentiality, integrity and
authenticity, or non-repudiation? Do they want a system that will
allow secure communication only within a workgroup, within a large
organization, across pre-defined organizational boundaries, or do they
want a system that allows them to securely identify individuals with
whom they may never have previously communicated? Do they want email
that preserves the current email functionality and makes that
functionality secure, or do they require added functionality suitable
for more complex financial transactions, etc.?
If we don't have the answers to these questions, then we
cannot be sure than the product you provide meets the needs and/or
expectations of the users. We cannot evaluate the adequacy of a
protocol proposal absent this sort of requirements analysis. PEM had
a model of its environment, and that model was described to some
extent in the RFCs and was expanded upon in published articles. The
new spec does not have the same model, i.e., some of the changes are
at odds with the original model, and there is no comparable
description of a new model to match the new spec.
Steve