Subject: RE: S/MIME signed attributes

From: "Pawling, John" <[email-masked]>
Date: Tue, 9 Jan 2001 14:38:27 -0500

Chung,
 
In both cases, these are signed attributes.  The IETF S/MIME working group
decided that it was important that the encapsulated content type and the
information identifying the signer's certificate(s) be cryptographically
bound to the digital signature of the RFC 2630 SignedData object.  RFC 2634
provides a detailed discussion regarding the purpose of the
signingCertificate signed attribute.

===========================================
John Pawling, [email-masked]
Getronics Government Solutions, LLC
===========================================

-----Original Message-----
From: Chung, KwonSung [mailto:[email-masked]]
Sent: Tuesday, January 09, 2001 12:42 AM
To: ietf-smime
Subject: S/MIME signed attributes

Hello All,

In S/MIME signed message at MS Outlook and Netscape Messanger, the
signed message has sevral signed attributes.

I have two questions related these signed attributes.

1. "contentType" Signed Attribute
    In "encapContentInfo", the type of content is determined.
"contentType" represents the same information about content type. Why is
the same information included again?

2. "signingCertificate" Signed Attribute
    In "certificates", certificate which was used to sign message is
included. But "sigingCertificate" has the same data - the certificate
used to sign message- as value. Why?
This attribute is not used by MS Outlook and Netscape Messanger. I don't
know what the usage of this attribute is.

Thank you.

Chung

---

From: Vamsi Motukuru <[email-masked]>
Date: Fri, 12 Jan 2001 16:47:11 -0500

All,

My question is concerning the CMS authenticated data type.

RFC2104 allows the HMAC key to be of any length. If this is the case, then 
the KEKRecipientInfo can not be used to transfer the Recipient Info unless 
the length of the authentication key matches that of a Triple-DES or RC2 
Key as this is required by the Key Wrap Algorithms.

Thanks,
  Vamsi

---

From: Russ Housley <[email-masked]>
Date: Fri, 12 Jan 2001 17:15:12 -0500

Vamsi:

RFC 2630 includes details for key management of RC2 keys and 3DES keys.  If 
you want to manage a different key, then you need to specify that 
algorithm.  I think all of the fields that you need are present, right?

Russ

---

From: Vamsi Motukuru <[email-masked]>
Date: Fri, 12 Jan 2001 17:44:20 -0500

Russ,

Thanks for the clarification.

The RecipientInfo structure definition needs no changes to support my 
requirements.

Vamsi

At 05:15 PM 1/12/01 -0500, Russ Housley wrote:
>Vamsi:
>
>RFC 2630 includes details for key management of RC2 keys and 3DES 
>keys.  If you want to manage a different key, then you need to specify 
>that algorithm.  I think all of the fields that you need are present, right?
>
>Russ
>
>>RFC2104 allows the HMAC key to be of any length. If this is the case, 
>>then the KEKRecipientInfo can not be used to transfer the Recipient Info 
>>unless the length of the authentication key matches that of a Triple-DES 
>>or RC2 Key as this is required by the Key Wrap Algorithms.
>>
>>Thanks,
>>  Vamsi
>