RE: Last Call Comments on CMS-101999-02-03 08:41:50
John:
I agree. How about this for replacement text in section 5.1:
At 05:43 PM 2/2/99 -0500, John Pawling wrote: >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:housley(_at_)spyrus(_dot_)com] >>> 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 >> >
|
|