I had not included the authenticated attributes in AuthenticatedData since
I
didn't see a reason for it (for my purposes, anyway). I could go ahead and
put it in, since it would work the same way as it does in SignedData.
I also have no objections to using a MAC in SignedData for those cases
where it will actually work (i.e. pre-shared key).
Regards,
Rich
----------
From: Jim Schaad (Exchange) <jimsch(_at_)EXCHANGE(_dot_)MICROSOFT(_dot_)com>
To: 'jsp(_at_)jgvandyke(_dot_)com'; 'Rich Ankney'
<rankney(_at_)erols(_dot_)com>;
ietf-smime(_at_)imc(_dot_)org
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
Date: Sunday, January 04, 1998 10:03 PM
It turns out that I was not fully functional when I wrote the list of
reasons below, and I left out what was to me the most important one.
What I want to do with the MAC modified signedData object is to run CMR
messages via it. This requires the ability to have authenticated
attributes travel with the message. This is a feature which is not
provided by the use of the AuthendicatedData structure, and thus the
reason that I put it into the signedData object. Notice that I was
very careful NOT to duplicate the same set of functionality as is
provided by Authenticated data, that is I am signing the Authenticated
attrubutes and not the data with the MAC algorithm.
That being said, I can live with the lack of support for this and
provide the introduction mechanism in a different way. This proposal
however does add a new level of ability that was not present in the PKCS
#7 1.5 specifications.
jim schaad
-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, December 31, 1997 6:22 AM
To: Jim Schaad (Exchange); 'Rich Ankney'; ietf-smime(_at_)imc(_dot_)org
Subject: RE: Incorporate some PKCS#7 V2.0 items into CMS
All,
I am not a MAC expert, but I have a few comments anyway. It seems that
the
security processing requirements for MAC objects are significantly
different
than the processing requirements for non-MAC signedData objects. If
this is
true, then I believe that it makes more sense to define a separate
object
(i.e. Rich's AuthenticatedData proposal) than to add complexity to
signedData (Jim's proposals to add ukm and RecipientIdentifier to
signerInfo). I assume that Rich's proposal is to use signedData to
provide
signature services other than MAC and to use AuthenticatedData to
provide
MAC services. This definition of two distinct objects allows an OID to
be
assigned for each which can be used to identify each object. When a CMS
object is received, the receiving agent can examine the contentInfo
contentType to quickly identify which type of processing is required to
validate the object.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 02:46 PM 12/30/97 -0800, Jim Schaad (Exchange) wrote:
I made these changes to the SignedData and Enveloped data fields for
two
reasons:
1. S/MIME is primarly concerned with the transport of these two
encoding formats and has not yet defined how to transport other
encoding
types, and
2. I wanted to keep the total number of "things" that I had to deal
with to a minimum.
We could easily add transport of other types if needed. The second
goal
is just a desire on my part and could easily be overridden by others.
It may be that the added complexity that I have added to the SignedData
and EnvelopedData out weight the benifits of having just the two types.
jim