Now the question is, how do you include the control information (which
includes the secret key for the symmetric algorithm) for both the security
services? RFC 1847 is explicit about there being only two parts in any
security/multiparts body part, the control information for one security
service, and the protected data. I could imagine defining some
multi-security service body part that allows multiple this. That or
changing RFC 1847. I'm not sure this feature is so important that 1847
should be changed for this, but I thought it was worth bringing up.
I had always envisioned it as something like this:
-multipart/encrypted
-multipart/alternative
-application/encryption-control-info-1
-application/encryption-control-info-2
-application/encryption-control-info-3
...
-application/encrypted-material
I'm not especially wedded to this approach -- its just how I had envisioned
it, that's all.
Of course for this to work you have to have a symmetric encryption scheme
in common plus a means of teasing the control information out as a separate
critter. I believe both of these issues are going to prove to be more difficult
than the tweaks to multipart/encrypted will. Not impossible by any means,
mind you, but harder.
Another question: In RFC 1847, I was wondering if it might not be a good
idea to suggest that UA's should inform users that a signature could was
not verified because the particular security service was unavailable. It
doesn't seem like it should be required, but it seems a helpful thing to
do, especially for a UA that automatically verifies signatures.
There used to be prose about this and various other aspects of presentation and
control elements in the document. But it got yanked about 18 months back,
before Jim and Sandy took over as editors. The problem, it seems, is that once
you get into presentation you end up assuming secure presentation channels
(e.g. someone could modify your display software so as not to relay the "this
signature isn't valid" message to the screen) and some folks get very tense
when approaches are given that depend on such assumptions.
I disagreed with this decision then and I disagree with it now. It seems to me
that calling attention to the existance of these channels and the need to
secure them is more useful than simply ignoring them, letting people implement
poorly and get compromised as a result. And I did argue this point, but I lost
since practically everyone else in this WG (my coauthors included, as I recall)
disagreed with me.
Last, it's beginning to dawn on me that real strength of security
multiparts is its generality and usefulness in the long term. For example,
it seems possible to build support for security multiparts into the MIME
machinery of a UA and then more easily swap security services in and out as
security requirements change over the years. This seems important and I
haven't seen it mentioned explicitly here before.
You betcha. This has been my primary for advocating the use of security
mutiparts since day one. I have always wanted to be able to add code to my
gateways and user agents that deals with the framework and has callouts where
specific services can be tied in as needed. Goodness, I'm lazy, aren't I ;-)
The separation is actually quite clean. I can build software that accepts plug
and play modules for a huge variety of plug in services. None of the other
approaches provide this level of generality -- they aren't even close.
Ned