Subject: RE: Last Call Comments on CMS-10

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Wed, 3 Feb 1999 12:13:39 -0800

John and Russ,

I completely disagree with this.  I don't think that it is any type of a
fair statement to say that down level clients should be able in any way,
shape or form to be able to parse one of these new messages.  This is why
the MUST occurs in the S/MIME documents.

I don't think it is a deficency of a down level client to be able to
completely fail if the ASN does not completely match to spec, I think this
is normal.  If a down-level client is not looking at version numbers then it
will deal with what it deals with, but I think that we need to give them
help not to kill them selfs.  

If you are going to go with this agruement then I want to take you arguement
to the logical extreme.  The text in section 6.1 should be changed so that
the version number there does not have anything to do with the version
numbers in RecipeientInfos.  The same aguements about down-level clients
appear just as valid here as with SignedData.  You should either get none of
the cake or the entire cake, not just the pieces you happen to like.

jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 03, 1999 7:59 AM
To: Ietf-Smime (E-mail)
Subject: RE: Last Call Comments on CMS-10

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: EKR <[email-masked]>
Date: 03 Feb 1999 15:35:01 -0800

> the MUST occurs in the S/MIME documents.
The problem is that these are combined new and old messages.

> help not to kill them selfs.  
I don't believe that the version number matters here much. The
way I see it, a client that's smart enough to skip innapropriately
versioned Signer or RecipientInfos should be smart enough to
skip over a different CMS version number and see if it can
really read the message.

> appear just as valid here as with SignedData.
I tend to agree here. OTOH, if OriginatorInfo is present, then
it seems that the version number must be increased. Else what
good is the version number in the first place?

-Ekr

-- 
[Eric Rescorla                                   [email-masked]]