- What's the rationale behind having both 'protocol' and
'micalg' on the multipart/signed type ?
I can see the interest of the micalg parameter, since it allows
single pass processing, and allows for multiple algorithms. But
the protocol parameter seems rather useless to me, and prevents
the use of multiple signature parts. So that the use of both
pem and pgp signatures forces the use of a pem-signature part
even for pgp signatures or the opposite. Why not drop that
protocol param ?
As you observe, the "micalg" parameter tells you that multiple message
integrity checks have been applied to the content. However, it does not
tell you the relationship between those values.
The value of the protocol parameter tells you the content type of the
control information. In the PEM/MIME specification, only one value is
defined: application/pem-signature. However, the Security Multiparts
specification allows for other values to be defined.
In particular, one could imagine defining a "multipart/sig-alternative"
control information content type that allowed the inclusion of several
signatures on a content where the verification of any one means the
content is authentic. One could also imagine defining a
"multipart/sig-parallel" control information content type that required
the verification of all the signatures before the content is considered
authentic.
These examples are intended to demonstrate that the value of the
protocol parameter could convey a great deal of information, limited
only by what is included in a specification.
- What's the point of having the 'protocol' argument on
multipart/encrypted ? Same question here, what's the use of
the protocol param ?
As above, we define one particular value with specific semantics.
Others are possible.
- The PEM-MIME draft seems to "open" the structure of PEM
messages. Or rather, it pushes it from inside the PEM message to
the MIME structure. But it has been done only partly, it seems.
Why has it been decided to stop here and not have (for example)
the signature being a private-key-encrypted part containing the
MD5 result ? This would allow fancy variations, like have the
signature itself public-key-encrypted (so that only selected
people can know who signed the document).
You can do this by defining a new control information type according to
the requirements of the security multiparts specification. This is
exactly why we separated these two specifications.
Jim