... all credit to the authors for bring all the discussion to
the point of concrete specification.
I agree. Based on your comments, we both agree that the I-D should
describe the security services that are provided by each MIME-PEM content
type. I think that the I-D should also describe the security services that
are provided by the possible combinations. In my opinion, few users will
care about the services offered by signed ciphertext.
Describing all the possible service combinations is a nice idea, but it is also
intrinsicly impossible to do. Both of these security services are building
blocks that can be combined in arbitrary ways with quite a few other MIME
services. (A set that is guaranteed to grow over time.) The result is a
combinatorial explosion of service combinations. And while some combinations
may not make any sense, there are certainly many others that do which we
haven't thought of yet.
There is a very real danger that in attempting to enumerate all the
combinations that make sense we'll condemn by implication some useful
combination of services we didn't think of and didn't document. I've seen this
happen as a result of overenthusiastic enumeration attempts in specifications
several times now.
As such, which I completely agree that the provided services need to be fully
described, I also think that that attempting to document combinations is very
risky and probably more of a disservice than a service. A few demonstrably
useful ones can be documented if need be, and preferably in some ancillary
informational document, but it needs to be clear that other combinations are
possible.
(I know Russ, you don't think much of trusted agent security
designs. But, MOA signatures computed by the MTA switch (without
complex crypto, albeit), over potentially-encrypted content are
actually being used between commercial VANs to perform charging
and settlement. Of course this has nothing to do with the VAN
users. Not does it have much to do with privacy or confidentiality.
but there is more to commercial provider-based message switching
than just the users.)
Peter, I understand this scenario, but I think that MIME-PEM would not be
well suited to this task. The VAN operator would rather have a mechanism
that signed the whole content. RFC1421 PEM is better suited to this task
because it always protects the whole content.
I disagree. First of all, there is nothing that says that RFC1421 always
protects the entire content. Second, MIME-PEM can be used to protect not only
the entire content but also the outermost message headers, making it a superior
service in this regard. Third, the price you pay for using RFC1421 is the loss
of content labelling. In many cases this is too high a price to pay.
Ned