Blake Ramsdell wrote:
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?
Count our hand raised!
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
while.
Okay, I think what we're talking about is the possible introduction
of a new hash algorithm, which your translator cannot convert to a
new micalg string because one hasn't been defined yet. I understand
the problem of that, but I'm not sure how important it is. This new
algorithm is obviously *not* one of the ones already listed in the
S/MIME spec (meaning, it isn't MD2, MD5, or SHA-1). So how many
S/MIME agents out there would be able to receive and verify such a
message anyway? Ours can't -- those are the only 3 hash algorithms
we currently recognize. We would certainly incorporate and support
any new algorithm that became trusted and used, but wouldn't/shouldn't
a new micalg be defined by the same time that new versions of S/MIME
agents started supporting it anyway?
What I'm saying is that I understand your issue but I think that it is,
in practice, not likely to be any real stumbling block -- and as such
I'd like to stick with the proposal of making the micalg parameter be
required because I think agents should be able to *count* on doing
one-pass processing.
lisa