On Friday, July 25, 1997 6:45 PM, Ned Freed
micalg is required by rfc 1847. I think it should be required by
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!
And mine as well. Note that I don't implement S/MIME myself, what I do
implement is hooks that allow callouts after I've done the calculation to
actually verify the signature. And I depend on micalg to do all this in a
In your case, Ned, do you hash the first part of multipart/signed using
the algorithm implied by micalg (something as follows):
pgp-md5, rsa-md5, pkcs7-md5 == Hash with MD5
rsa-sha1, rsa-sha, rsa-sha-1, pgp-sha1, pkcs7-sha1 == Hash with SHA-1
and then present the result of that hash to the callout that can do the
actual signature validation?
It seems that there may be a case (such as PGP/MIME) where other
information needs to be presented to the hash function along with the
content so that the correct hash can be recreated. I think PGP 2.6x
does something like MD5(first part of multipart/signed + signature
classification + signature time stamp) (from RFC1991 section 6.2), but I
may have this wrong.
I guess the point is -- is it always possible to complete a hash of the
first part of multipart/signed and have a satisfactory answer for the
signature validator? Is this enforced by micalg? My reading of it is
that it is not enforced. I think that Laurence is trying to do a
similar thing to what you are doing (precompute the hash and then hook
out to signature verification).
I'm not trying to be a wiseass -- I am just making sure I understand