[Top] [All Lists]

RE: Attempt to clear off the open issues

1997-07-24 15:03:25
On Thursday, July 24, 1997 8:27 AM, Laurence Lundblade
[SMTP:lgl(_at_)qualcomm(_dot_)com] wrote:
micalg is required by rfc 1847. I think it should be required by S/MIME and
can't think of any reason not to include it.  The excellent reason for
requiring it is that it allows implementors to count on it and thus
simplifies their work.

A show of hands -- who is using it for one-pass processing in S/MIME?
The only other simplification of translator work would probably be the
trivial rejection of a candidate message based on the presence of an
unknown micalg (if you don't recognize the micalg, then don't process
the message).  In both of these cases, the absence of the micalg is not
fatal -- only annoying.

This is not to assume that no one in the future will be using it for
one-pass processing, but to point out that "SHOULD if at all possible"
might be more appropriate language due to the lack of implementations
that use it, and to support the point that I am about to make.

The problem that I have with it being MUST is that I believe that the
conversion between signedData and multipart/signed is a useful if not
necessary transformation, as evidenced by the fierce debate that has
raged about it.  If the micalg is mandated, then it could potentially
become impossible to convert a signedData entity to multipart/signed,
since the converter may not understand how to convert the
AlgorithmIdentifiers specified in digestAlgorithms to their micalg
string representation.  Granted, the AlgorithmIdentifiers and their
micalg string mapping are defined for the two "in vogue" algorithms --
MD5 and SHA-1, so this should not be an issue for at least a little

Maybe this is a bigger point -- is it better to have strict language in
the spec and have implementations that bend or break the rules, or
better to have softer but still effective language in the spec which
allows implementations to always be conformant with no loss of