Ned Freed wrote:
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.
In any case, use of multipart/signed is preferable, and multipart/signed
is the only reasonable thing to send to a public forum.
In cases where use of multipart/signed is not possible, the advantages
of using application/signed instead of signedData are:
* application/signed deals with the problem the same way for all
signature systems which make use of multipart/signed
* It is trivial for intermediaries to convert a multipart/signed into an
application/signed and vice versa. Such intermediaries need not have
knowledge of the particular signature system being used (e.g. PKCS #7).
To UAs without explicit support for it, application/signed is of course
100% opaque, same as for signedData.
The advantages of application/signed over signedData may well not be
worth the effort required to deploy application/signed.