[Top] [All Lists]

Re: micalg semantics and use

1997-07-27 23:36:22
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
single pass.

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

I have a table for this.

and then present the result of that hash to the callout that can do the
actual signature validation?

No. What I present is a general hash structure my generic hash routines use
(routines that support MD2, MD4, MD5, SHA-1, RIPEMD128, RIPEMD160, and HAVAL)
with the intermediate result of proccessing the first past, leaving the
finalization for the signature-specific routine(s).

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.

Yes, but it seems that when this is done protocol designers have always placed
this information after the signed data. As such, while it isn't possible to
finish up the hash calculation completely, it is still possible to write
generic multipart/signed support code that operates in a single pass. But
micalg is an essential part of this.

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?

This depends on whether or not we keep on designing signature schemes
taking one pass processing into account.


<Prev in Thread] Current Thread [Next in Thread>