ietf-smime
[Top] [All Lists]

RE: Attempt to clear off the open issues

1997-07-25 16:11:41
On Friday, July 25, 1997 10:04 AM, Laurence Lundblade
[SMTP:lgl(_at_)qualcomm(_dot_)com] wrote:
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.

But the problem is that you will not know which digest algorithm a
particular message part will need in order to complete its signature.
"rsa-md5", "pgp-md5" and "pkcs7-md5" are all legal values to identify
the MD5 algorithm (even though, as you will probably find out at some
point, the data that is presented to these hashing algorithms is not
completely derived from the content, but may also be found in the
signature part as well).  At some point someone will come up with
"zoondap" which happens to be MD5.  The only option you're going to have
in your case is to compute all of the hashes that you know how to do,
and then provide those to any plugin that might need them so that they
can make the determination if any of the hashes is suitable for their
needs.

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.

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 :-).

Careful -- these are separate, treacherous waters to navigate.  This
discussion is already starting up again in a separate thread, raising
some issues about application/mime and various politics that I was not
aware of.  The point is taken, however.

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
Pilot).

I have talked with Paul offline, and I agree that we should make micalg
a MUST.  I will also suggest that if micalg isn't present that the
implementation SHOULD NOT throw its hands up in the air and walk away,
but should instead try to make an effort (however inefficient) to
resolve this problem.  This is, most likely, hashing the data using all
of the algorithms understood by the application, and then using the one
required to verify the signature (which will be determined when the
signature part is parsed).  The overhead is the resource overhead of
redundantly hashing the data (time and memory requirements).

Blake

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