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:
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
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
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
10. Section 12.3.1, paragraph 3. I would like to change the
to "A CMS Implementation should support mixed key-encryption and
Disgree. I am reluctant to change "may" to "should." What
do other people
11. Section 12.3.3 - Please insert the following paragraph
in this section
" A CMS implementation should support mixed key-encryption
encryption algorithms. For example, a 128-bit RC2
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
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
think before changing "may" to "should."