ietf-smime
[Top] [All Lists]

RE: Last Call Comments on CMS-10

1999-02-03 08:41:50
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



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
>>
>