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.
Actually, I don't think we even disagree on that. The question for me
is whether or not they belong in the same standard. I view MIME/PEM as
being an alternate mechanism which supports the same policies as RFC 1421,
parts of which (namely the MIME security multipart) can be used to support
other policies as well.
As I've stated before, I am completely in favor with standardizing policy
(as in X.509, PCA hierarchies, etc.). I just think these are separate
issues from the representational mechanism issues that the MIME/PEM proposal
is concerned with, and should not serve to hold up the proposal.
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.
Agreed, completely. And I think that discussing how the RFC 142x policy
framework needs to be revised is the next big thing for us to work on.
I just want to see the MIME/PEM mechanism sent along first :).
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?
There are two basic sets of requirements. Corporate users want all of the
above, and are well served by the existing policies in PEM (PCAs and all).
They just want to use MIME as a transport format in addition to vanilla
RFC 822 text.
Casual (home) users tend to want only confidentiality, occasionally integrity,
and are generally content to handle their own key management and certification
(which is one reason PGP has succeeded in these environments more than in
corporate environments). Since the MIME/PEM representation allows this kind
of policy in addition to the classic PEM policy framework, in a single
representational framework, I view MIME/PEM as giving me exactly what I want
at the moment.
Now, as an implementor, I will certainly distinguish between PEM policy and
other policies in my user interface...
Amanda Walker
InterCon Systems Corporation