RFC 1847 again, section 2.1:
The attribute token for the micalg parameter is "micalg", i.e.,
parameter := "micalg" "=" value
The Message Integrity Check (MIC) is the name given to the quantity
computed over the body part with a message digest or hash function,
in support of the digital signature service. Valid value tokens are
defined by the specification for the value of the protocol parameter.
The value may be a comma (",") separated list of tokens, indicating
the use of multiple MIC algorithms. As a result, the comma (",")
character is explicitly excluded from the list of characters that may
be included in a token used as a value of the micalg parameter. If
multiple MIC algorithms are specified, the purpose and use of the
multiple algorithms is defined by the protocol.
That seems rather odd, as "value" is not defined specifically for the
micalg parameter, and the definition immediately preceding the quoted
text (for value as used in the protocol parameter) doesn't seem to be
applicable. "token" is mentioned in the text, and Content-Type header
field parameter values are specified in RFC 2045 as amended by RFC 2231.
The really odd part is that the quoted text above mentions that the
value can be a comma-separated list and mentions excluding comma. But
comma is in the list of tspecials defined in RFC 2045, and therefore
can never be part of a "token" and cannot appear unquoted (and unencoded)
in a parameter value.
Oh please, this isn't rocket science. Surely it is obvious that multiple hash
algorithms can be applied to the same object simultaneuously. In situations
where multiple hashes are needed by the signature, the micalg parameter permits
specification of more than one. Comma is the separator used to delineate
multiple values, so comma is specifically excluded from the characters that
can be used in the name of a hash.
You're confusing the word token used in the generic sense of "a semantic
unit of information" and the token ABNF production.
And no, I don't think the text is at all unclear in its present form. You're
going far out of your way to assign a nonsensical interpretation to the
words.
Content-Type: multipart/signed ; micalg="md5,sha1"
is syntactically legal per RFC 2045, but the micalg parameter value is
a single quoted-string (as opposed to a token) and not a comma-separated
list of tokens.
No, it is a list of tokens. Just not a list of tokens in the ABNF sense.
RFC 2045/2231 Content-Type parameter syntax doesn't seem to provide for a
list of values in a parameter, unlike RFC 2298's syntax for the
Disposition-Notification-Options header field, which does explicitly
provide for a list in disposition-notification-parameters.
Which is why the list has to be embedded in a single value.
To further complicate matters, RFC 3335 section 5.3.1 refers to "the"
micalg value used by the sender in multipart/signed (not a list of
values) and the usage in the Received-content-MIC MDN field would
seem to preclude use of multiple algorithms (and that section is
where 3335 refers to an IANA registered MIC algorithm ID). Unless,
that is, multiple Received-Content-MIC fields may appear in an MDN --
RFC 3335 is silent on that matter.
It seems fairly obvious that if the value is a list you'd simply put the
list into a single header field.
So how does all this tie together? Does RFC 1847 require a third level of
parsing (after the low-level RFC 822 parsing and the Content-Type field
parsing) to see if the parameter value contains commas?
Of course it does.
Is it even
possible to use a list of values as suggested in 1847?
Of course it is.
If so, does
1847 really mean a quoted-string (or continuation equivalent) rather
than a list of tokens (which is not permitted by the 2045 syntax)?
It really means a list of tokens inside of a quoted string. This is really
silly, you know.
Ned