From: Peter Williams[SMTP:peter(_at_)verisign(_dot_)com]
Sent: Thursday, September 26, 1996 4:31 PM
To: smime-dev(_at_)RSA(_dot_)COM; 'spock'
Subject: RE: micalg parameter
I dont see why one needs non-standard micalg, values.
Ned explained the purpose of the field as, while doing one pass, one uses the
micalg value
to compute the hash of the first stream , and for PKCS7 protocol, its used
either in the signature, or else
in the messageDigest authenticatedAttribute, if the micalg value is
conformant with the PKCS7
alg ids. (If not, the first stream must be rehashed, obviously)
one determine which PKCS#7 case to use the hash value in, when validating the
elements of the
second bodypart.
That the 2nd bodypart has such a flexiblity of using the hash is not known or
relevant to handling the
first stream; the hash value is possibly used regardless of which of the
PKCS7 detached
signature handling options is determined.
There is no value I can see to using a non-standard hash indication. It
serves no purpose!
The decision to use it one way of the other, and if at all, is deduced from
the 2nd bodypart syntax,
uniquely.
What utility is provided by signalling at the outset that the 2nd bodypart
*may* have
authenticatedAttributes? Nothing changes in the handling of the
first stream's computation.
if an attacker changes this micalg value, would it cause a vulnerability or
mis-handling?
I may be partially at fault here for suggesting that we differentiate
between the MD5 that is used for MOSS, the MD5 that is used for PGP, and
the MD5 that is used for PKCS7 (S/MIME), all of which I believe create
their hashes based on different data. My reasoning is as follows: If
you are single-pass processing a signed message, or even separating the
process of hash creation versus signature validation, it seems that the
micalg would be more useful if it not only encapsulated the algorithm to
use (MD5) but the semantics for its use (most notably, what data should
be provided to the hashing function). I understand that you can use the
pairing of the micalg and the protocol parameters to accomplish this
also, but it seems that the more useful thing is to let micalg dictate
the algorithm and the semantics of the use of the algorithm.
Maybe I'm wrong. I have posted this to pem-dev (which is where I
believe discussion about security multiparts happens) in hopes of
getting some clarification about the use of micalg. It seems like an
arbitrary decision, but I'd prefer not to break the definition of the
micalg parameter in case this is not the way it was meant to work.
By the way, I think the "standard-ness" of micalg is dictated by the
security protocol, so making our own isn't *that* bad if it serves a
purpose.
Blake
(For PEM-DEV -- the original message that started this is below. My
apologies if this is not the correct place to discuss security
multiparts.)
----------
From: spock
Sent: Thursday, September 26, 1996 4:59 PM
To: smime-dev(_at_)RSA(_dot_)COM
Subject: micalg parameter
There have been some recent discussions on and off the smime-dev list about
values for the micalg parameter for multipart/signed S/MIME messages.
Because the PKCS7 signature is based on a hash of not only the message
content but also the PKCS 7 signed attributes contained in the detached
signature information, it may be useful to indicate this by creating unique
micalgs for S/MIME. To this end, I'd propose:
pkcs7-md5
pkcs7-sha-1
Comments ? Does anyone know if these parameters are case-sensitive ?
-steve