Now, I would argue that neither of application/signed nor signedData are
"purely composite", at least no more so than MIME under encryption.
They're both MIME under opaque digital signatures.
On the contrary, the entire purpose of using a construct like multipart/signed
is for the object to be selectively opaque at most, so that people without
signature processors can still process the content. And the minute you start
talking about objects being selectively opaque you're talking about purely
composite objects. There is no slope here -- one step in the direction of
having regular MIME processors handle the content as MIME and it is over.
If, on the other hand, the intent is for application/signed to be 100% opaque,
then we're not talking about a composite object in the MIME sense. And then
none of the MIME rules about composites apply. But the minute you do this the
whole point of having application/signed and/or multipart/signed vanishes,
since the only reason to use such a complex structure is so that extant
processors can see the content for what it is. Once this is no longer an
issue you might as well use signedData and be done with it.
The only technical
difference between application/signed and signedData is whether the
container parses like MIME or parses like PKCS7, and how difficult it is
for a gateway to convert a multipart/signed into one or other.
True enough, but in practice this is all the difference in the world.
Ned