Fri, 27 September 1996 11:41 UTC

Received: from cnri by ietf.org id aa05558; 27 Sep 96 7:41 EDT
Received: from neptune.hq.tis.com by CNRI.Reston.VA.US id aa27116; 27 Sep 96 7:41 EDT
Received: from neptune.tis.com by neptune.TIS.COM id aa16976; 27 Sep 96 7:19 EDT
Received: from relay.hq.tis.com by neptune.TIS.COM id aa12802; 26 Sep 96 20:19 EDT
Received: by relay.hq.tis.com; id UAA12329; Thu, 26 Sep 1996 20:23:09 -0400
Received: from sol.hq.tis.com(10.33.1.100) by relay.tis.com via smap (V3.1.1) id xma012321; Thu, 26 Sep 96 20:22:41 -0400
Received: from relay.hq.tis.com by tis.com (4.1/SUN-5.64) id AA01613; Thu, 26 Sep 96 20:24:53 EDT
Received: by relay.hq.tis.com; id UAA12311; Thu, 26 Sep 1996 20:22:39 -0400
Received: from host9.deming.com(206.63.131.9) by relay.tis.com via smap (V3.1.1) id xma012304; Thu, 26 Sep 96 20:22:35 -0400
Received: by cane.deming.com with SMTP (Microsoft Exchange Server Internet
Message-ID: <9609270713.aa16971@neptune.TIS.COM>
X-Date: (the original message had no date)
Date: Fri, 27 Sep 1996 18:41:00 -0000

Mail Connector Version 4.0.993.5)
	id <01BBABCE.CD8E0530@cane.deming.com>; Thu, 26 Sep 1996 17:18:58 -0700
Message-Id:
<c=US%a=_%p=Deming_Software.%l=CANE-960927001857Z-550@cane.deming.com>
From: Blake Ramsdell <BlakeR@deming.com>
To: "'smime-dev@RSA.COM'" <smime-dev@rsa.com>, 'spock' <spock@rsa.com>, 
    'Peter Williams' <peter@verisign.com>
Cc: "'pem-dev@tis.com'" <pem-dev@TIS.COM>, 
    "'ned@innosoft.com'" <ned@innosoft.com>
Subject: RE: micalg parameter
Date: Thu, 26 Sep 1996 17:18:57 -0700
X-Mailer:  Microsoft Exchange Server Internet Mail Connector Version 4.0.993.5
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: pem-dev-approval@neptune.tis.com
Precedence: bulk

>From: 	Peter Williams[SMTP:peter@verisign.com]
>Sent: 	Thursday, September 26, 1996 4:31 PM
>To: 	smime-dev@RSA.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@RSA.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
>
>
>
>
>

  •