Subject: RE: Last Call Comments on CMS-10

From: [email-masked] (John Pawling)
Date: Wed, 3 Feb 1999 10:58:58 -0500

Blake and friends,

I initially objected to the concept of allowing v1 and v3 signerInfos to
exist in the same signedData because I believed that the beneift was not
worth the problems that they will probably cause in legacy S/MIME products.
I suspect that many legacy products don't check the version number of the
singerInfo before decoding it.  If they don't check it, then they will
encounter an ASN.1 decode error when processing a v3 signerInfo which could
cause unpredictable behavior in the software.  

Upon further reflection, I now agree with Blake.  Potential deficiencies in
legacy products should not drive the design of the v3 S/MIME specs.  An
S/MIME v3 user agent should be allowed to send a signedData that includes a
v1 signerInfo that can be processed by all S/MIME user agents and a v3
signerInfo that can only be processsed by v3 user agents.  I agree with
Blake that the version number of such a signedData should be v1.  If the
version number was v3, then the legacy software would reject the signedData
even though it includes a v1 signerInfo that it could verify.

This concept raises another issue.  ESS states: "If any of the SignerInfos
included in a SignedData object include an eSSSecurityLabel attribute, then
all of the SignerInfos in that SignedData object MUST include an
eSSSecurityLabel attribute and the value of each MUST be identical."  I
believe that this statement should be changed to: "If any of the SignerInfos
included in a SignedData object include an eSSSecurityLabel attribute, then
all of the SignerInfos (including those marked as v1) in that SignedData
object MUST include an eSSSecurityLabel attribute and the value of each MUST
be identical." 
  
- John Pawling

At 02:53 PM 2/2/99 -0800, Blake Ramsdell wrote:
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Tuesday, February 02, 1999 2:43 PM
>> To: Ietf-Smime (E-mail)
>> Subject: RE: Last Call Comments on CMS-10
>> 
>> 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.
>
>I respectfully disagree -- it is possible to have multiple SignerInfos, some
>of which are v2 and can be processed by a v2 agent.
>
>If you reword this to be "if all of the SignerInfos are v3, then the parent
>SignedData should be version 3" or equivalent verbiage, then I think I'd go
>along with it.
>
>Blake
>--
>Blake C. Ramsdell
>Worldtalk Corporation
>For current info, check http://www.deming.com/users/blaker
>Voice +1 425 882 8861 x103  Fax +1 425 882 8060
>
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 03 Feb 1999 14:20:45 -0500

Based on John's response, I propose the following text:

version is the syntax version number.  If no attribute certificates are
present in the certificates field, the encapsulated content type is
id-data, and any of the 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 all of the
elements of SignerInfos are version 3, then the value of version shall be 3.

Russ