Subject: RE: Last Call Comments on CMS-10

From: [email-masked] (John Pawling)
Date: Tue, 2 Feb 1999 17:43:15 -0500

All,

I believe that a version 3 SignerInfo MUST cause the parent SignedData
version to be 3.  This strategy allows the receiving software to be able to
distinquish between an S/MIME v2 or v3 message by looking at the first field
in the signedData.

- John Pawling

At 02:12 PM 1/12/99 -0800, Jim Schaad (Exchange) wrote:
>Russ:
>
>> -----Original Message-----
>> From: Russ Housley [mailto:[email-masked]]
>> Sent: Tuesday, January 12, 1999 11:36 AM
>> To: Jim Schaad (Exchange)
>> Cc: Ietf-Smime (E-mail)
>> Subject: Re: Last Call Comments on CMS-10

<snip>

>> >7.  Section 5.1: Text on version needs to be expanded to 
>> deal with SKI.
>> >Must be 3 if any SignerInfo version is 3.
>> 
>> Are you saying that a version 3 SignerInfo should cause 
>> parent SignedData
>> version to be 3?
>> 
>> Is there a reason to prohibit version 3 SignerInfo from being 
>> encapsulated in a
>> version 1 SignedData?
>
>This is the backwards compatability thing.  Everywhere else we have done --
>you get a new version all the way up (See EnvelopedData) if you do something
>new on an inner object.  This prevents you from starting something you may
>regret.  If we don't do this here, then I don't see why we should be doing
>it in EnvelopedData.  I don't care which of the two we correct, but make
>them consistant.

>
>> 
>> >10. Section 12.3.1, paragraph 3.  I would like to change the 
>> first sentence
>> >to "A CMS Implementation should support mixed key-encryption and
>> >content-encryption algorithms."
>> 
>> Disgree.  I am reluctant to change "may" to "should."  What 
>> do other people
>> think?
>> 
>> >11. Section 12.3.3 - Please insert the following paragraph 
>> in this section
>> >"   A CMS implementation should support mixed key-encryption 
>> and content-
>> >   encryption algorithms.  For example, a 128-bit RC2 
>> content-encryption
>> >   key may be wrapped with 168-bit Triple-DES key-encryption key.
>> >   Similarly, a 40-bit RC2 content-encryption key may be wrapped with
>> >   128-bit RC2 key-encryption key."
>> 
>> As with comment 10, I would like to hear what other people 
>> think before
>> changing "may" to "should."
>
>Can I at least get you to agree to put in the paragraph with the "may"
>syntax even if I get no support for "should"?
>
>> 
>> >12. Ditto 11 for section 12.6
>> 
>> Ditto.  As with comments 10 and 11, I would like to hear what 
>> other people
>> think before changing "may" to "should."
>> 
>
>> 
>> Russ
>> 
>
>jim
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 03 Feb 1999 10:23:24 -0500

John:

I agree.  How about this for replacement text in section 5.1:

The fields of type SignedData have the following meanings:

version is the syntax version number.  If no attribute
certificates are present in the certificates field, the encapsulated
content type is id-data, and all elements of SignerInfos are version 1,
then the value of version shall be 1.  Alternatively, if attribute
certificates are present, the encapsulated content type is other than
id-data, or any of the elements of SignerInfos are version 3, then the
value of version shall be 3.

Russ