Subject: Re: Last Call Comments on CMS-10

From: [email-masked] (John Pawling)
Date: Thu, 4 Feb 1999 11:08:31 -0500

Eric,

You wrote:
>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.

I disagree with this statement.  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.

You wrote:
>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?

CMS already states that the envelopedData version must be 3 if
originatorInfo is present.

- John Pawling

---

From: Russ Housley <[email-masked]>
Date: Thu, 04 Feb 1999 11:34:25 -0500

Calling all implementors...

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 happen if the implementation encounters a version 0
EnvelopedData that contains a RecipientInfo with a version other than 0.
Same three choices.

Russ