At 3:04 PM -0700 7/24/97, Blake Ramsdell wrote:
On Thursday, July 24, 1997 8:27 AM, Laurence Lundblade
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.
Well, I'll raise my hand a little. One thing are planning is to assume your
local message store is secure and compute the hash values as we insert them
into the local message store (e.g. as they come done via POP). This gains
substantial efficiency at read time for big messages you're verifying while
just looking at the text.
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
Well, that's a good point. We definitely ought to get the mapping straight
no matter what. I guess my off-the-cuff answer would be that we should get
rid of signedData completely and use application/mime wrapping of
multipart/signed instead so there's no conversion issue and thus removing
this argument about making micalg optional :-).
This seems like a subjective trade-off so I don't have a strong opinion.
I'll say that we should still make it required because I think we want to
make the signature verification process faster and easier than the
conversion process because signature verification is going to be done much
more widely, more frequently, and on smaller platforms (like the Newton or
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
Good point too...