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.
True, but my question was: why duplicate that protocol information in the header
of the multipart/signed part ? The only information I need at this point is the
micalg so I can compute the mic as I read the signed message. And then, the
next part
will have all the necessary information about how to deal with the MIC I got.
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.
- how would sig-parallel look like ? (it would have to be encrypted, I guess)
Another thing: pem-signature allows for multiple sigs (if my memory's right). So
the semantices of a pem-sig followed by another pem-sig (or a pgp-sig) could be
the same, just allowing for other protocols.
What's the problem with:
content-type: multipart/signed; micalg="rsa-md5,pgp"; boundary="signed"
--signed
blablabla
--signed
content-type: application/pem-signature
one sig
another sig
--signed
content-type: application/pgp-signature
one sig
maybe one more sig, who knows
--signed--
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.
No, they just show that the second subpart of multipart/signed isn't limited to
pem-signature. But they don't make the protocol param any more useful !
- 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.
As above (:-), the value is already specified elsewhere (in the subpart) and
I don't see any interest in having it available earlier (in a sequential read) !
Stefan