Subject: RE: Last Call Comments on CMS-10

From: "Blake Ramsdell" <[email-masked]>
Date: Wed, 3 Feb 1999 12:27:48 -0800

> -----Original Message-----
> From: Russ Housley [mailto:[email-masked]]
> Sent: Wednesday, February 03, 1999 11:21 AM
> To: [email-masked]
> Cc: Ietf-Smime (E-mail)
> Subject: RE: Last Call Comments on CMS-10
> 
> 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.

Agree.

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: [email-masked] (John Pawling)
Date: Wed, 3 Feb 1999 15:42:10 -0500

All,

I respectfully disagree with Jim.  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.    This allows a single message to be sent to all recipients.
Otherwise, the user would need to send two messages:  the old S/MIME v2
message to legacy users and a new S/MIME v3 message to S/MIME v3 users.
This seems unworkable, because how does the originator know what flavor of
software will be used by each recipient. 

Furthermore, an S/MIME v3 user agent should be allowed to send an
envelopedData that includes a v0 RecipientInfo that can be processed by all
S/MIME user agents and a v3 RecipientInfo that can only be processsed by v3
user agents.  The version number of such an envelopedData should be v0.  If
the version number was v3, then the legacy software would reject the
envelopedData even though it includes a v1 ReceipientInfo that it could
process.  This allows a single message to be sent to all recipients.
Otherwise, the user would need to send two messages.  The old S/MIME v2
message to legacy users and a new S/MIME v3 message to S/MIME v3 users.  

I agree with Jim that the rules for setting the signedData and envelopedData
version number must be consistent.  Recommend that the Sec 6.1 text
regarding envelopedData version should be changed as follows:

"version is the syntax version number.  If originatorInfo is
present, then version shall be 2.  If all of the RecipientInfo
structures included have a version other than 0, then the version
shall be 2.  If unprotectedAttrs is present, then version shall be
2.  If originatorInfo is absent, any of the RecipientInfo
structures are version 0, and unprotectedAttrs is absent, then
version shall be 0."

- John Pawling

At 12:13 PM 2/3/99 -0800, Jim Schaad (Exchange) wrote:
>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
>
>From: [email-masked] [mailto:[email-masked]]
>Sent: Wednesday, February 03, 1999 7:59 AM
>To: Ietf-Smime (E-mail)
>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:
>>> From: [email-masked] [mailto:[email-masked]]
>>> Sent: Tuesday, February 02, 1999 2:43 PM
>>> To: Ietf-Smime (E-mail)
>>> 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

---

From: "David P. Kemp" <[email-masked]>
Date: Thu, 4 Feb 1999 13:26:11 -0500 (EST)

> From: [email-masked] (John Pawling)
> 
> I believe that programmers will implement one of the following:
> 
> a) examine the value of the version number and reject (or skip over, if
> applicable) fields with unrecognized syntaxes; or 
> 
> b) ignore the version numbers and just try to decode the object.
> 
> I believe that we should write the specs so that vendors can develop code to
> properly implement option a.

I agree with John and Blake that a mixture of signerInfos should be
allowed in a v1 signedData.  However, I agree with Eric that there
is little practical difference between a) and b).  Decoding until
you come to an unsupported version number should have the identical
behavior as decoding until you come to some unrecognized syntax.

"Jim Schaad (Exchange)" <[email-masked]> writes:
> shape or form to be able to parse one of these new messages.

There are general rules for extensibility which will allow new
features to be incorporated into existing structures without breaking
old software.  X.509 extensions are an example - new extensions can
be defined, and old software either accept or reject certs containing
unrecognized extensions without choking on the ASN.1.  The Certificate
version number doesn't get incremented above v3 every time a new set
of extensions is defined.

IMO, a version number should be incremented only when necessary to
prevent incorrect interpretation of an object.  A version which tries
to capture every detail of the enclosed subfields is unnecessarily
complex and redundant.  It is penny wise and pound foolish, because the
time saved by allowing receivers to do shortcut message rejection on
the outer object is overwhelmed by the complex logic required for
senders to propogate inner contents outward in order to construct
conforming version numbers in the various enclosing objects.

> From: Russ Housley <[email-masked]>
> 
> The crux of this issue is what S/MIME v2 code will do if it encounters a
> version 1 SignedData that contains a SignerInfo with a version other than
> 1.  Will your implmentation:
> 
> 	a) fail to parse the ASN.1 and report an error
> 
> 	b) check the version, skip it, and look for another SignerInfo
> 
> 	c) die ungracefully
> 		(if you do not want to admit this publically, please send 
> 		 private e-mail or use an anonymous service)

Similarly, what will S/MIME v2 code do if it encounters a version 3
SignedData.  If the answer to both questions is a) or c), then that
implementation is too flawed to affect our decision, and can justifiably
be ignored.

---

From: "Jim Schaad (Exchange)" <[email-masked]>
Date: Thu, 4 Feb 1999 12:12:50 -0800

OK -- I just consulted my developers.  We do a decode of the entire
SignedData or EnvelopedData object in one shot.  This means that we fail the
decode operation no matter if you put the version in or not.  We just get to
fail faster if you update the version.  Our product does not decode the
structure into pieces and attack the pieces individually.

jim

-----Original Message-----
From: Russ Housley [mailto:[email-masked]]
Sent: Thursday, February 04, 1999 8:34 AM
To: [email-masked]
Subject: Re: Last Call Comments on CMS-10

Calling all implementors...

	c) die ungracefully

Similarly, what will happen if the implementation encounters a version 0
EnvelopedData that contains a RecipientInfo with a version other than 0.
Same three choices.

Russ