ietf-smime
[Top] [All Lists]

RE: Incorporate some PKCS#7 V2.0 items into CMS

1997-12-31 07:17:53
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

-----Original Message-----
From: Rich Ankney [mailto:rankney(_at_)erols(_dot_)com]
Sent: Tuesday, December 30, 1997 1:13 PM
To: ietf-smime(_at_)imc(_dot_)org; John Pawling
Subject: Re: Incorporate some PKCS#7 V2.0 items into CMS


From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
All,

IMHO, CMS should be algorithm independent.  If changes are required to
support HMAC (as stated by Jim), then those changes should be
considered
for
incorporation into CMS.  We should also consider Jim's proposed
changes
related to supporting key agreement algorithms such as the derived
password
keys in PKCS#12.

The AuthenticatedData structure I proposed several weeks ago (and which
will
be in draft 3) was designed explicitly to support HMAC (and DES-MAC).  I
believe it will support the password derived MAC (at least as defined in
PKIX-3)
as well.

AuthenticatedData uses the key management stuff from EnvelopedData, and
a SET OF MAC (one MAC per algorithm, allowing different recipients to
use
different algorithms:

AuthenticatedData ::= SEQUENCE {
 version Version,
 originatorInfo [0] OriginatorInfo OPTIONAL,
 recipientInfos RecipientInfos,
 contentInfo contentInfo,
 macs MACS }

RecipientInfo ::= SEQUENCE {
 version Version,
 rid RecipientIdentifier,
 macAlgorithm AlgorithmIdentifier
 keyEncryptionAlgorithm KeyEncryptionAlgorithmIdentifier,
 encryptedKey EncryptedKey }

MACS ::= SET OF MAC

MAC ::= SEQUENCE {
 algorithm AlgorithmIdentifier,
 authenticator OCTET STRING }

Notes:

1.   This construct supports provision of an authenticator (MAC) by a
single
originator.
2.  The originator may compute multiple MACs in order to accommodate
multiple recipients who use different algorithms.  For a given
algorithm,
the originator will provide a single MAC, and transport the key to all
recipients which use that algorithm.
3.  Key management is based on that in EnvelopedData; the
macAlgorithm field is added to the RecipientInfo field to assist the
recipient in locating the appropriate MAC in the MACS field.
4.  There is no support for multiple originators, or for authenticated
or 
unauthenticated attributes.
5.   Some discussion on deriving both content-encryption and MAC keys
from
the same keying material (DH shared secret, or RSA-encrypted "blob" a
la SSL) might be in order.

Regards,
Rich



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