> 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.
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.
It may not be the only information you need. Architecturally, the
question you have to ask is what is the expected division of labor when
supporting security services?
If the model you imagine is that a MIME agent will always be integrated
with the agent that supports the security services, then I believe
you're correct; the protocol parameter is superflous.
However, suppose the MIME agents of the world only know about
multipart/signed to the extent that they understand that there are two
body parts and that one is data and one is control information. A MIME
agent of this sort probably will not explicitly support any security
services. Instead, it will transfer control to a different agent for
processing of the data stream. Without the protocol parameter it does
not know which agent to transfer control to without parsing more of the
content. However, doing so defeats the desire to support one pass
processing.
The inclusion of the protocol parameter provides an early decision point
for a MIME implementation.
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--
The problem with this is that multipart/signed is defined to have
exactly 2 body parts. (PGP is not a valid micalg either but that's a
minor point.) I think perhaps what you're looking for is something like
the following:
content-type: multipart/signed;
protocol="multipart/pem-parallel";
boundary="signed";
micalg=XXX
--signed
data here
--signed
content-type: multipart/pem-parallel;
boundary="sig"
--sig
signature one
--sig
signature two
--sig
signature three
--sig--
--signed--
Jim