Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

From: [email-masked] (Peter Gutmann)
Date: Wed, 11 Jul 2001 14:37:34 (NZST)

"Pawling, John" <[email-masked]> writes:

>    [*** NEW ***] version is the syntax version number.  The
>    appropriate value depends on originatorInfo, RecipientInfo, and
>    unprotectedAttrs.  The version MUST be assigned as follows:
>
>     IF ((originatorInfo is present) AND
>         (any version 2 attribute certificates are present)) OR
>         (any RecipientInfo structures are pwri CHOICE) OR
>         (any RecipientInfo structures are ori CHOICE)
>     THEN version is 3
>     ELSE
>         IF (originatorInfo is present) OR
>            (unprotectedAttrs is present) OR
>            (any RecipientInfo structures are a version other than 0)
>        THEN version is 2
>        ELSE version is 0]

Didn't we already go through all of this in April?  My comment back then was:

  If the EnvelopedData version was incremented whenever a new RecipientInfo was
  added then it's bad, because adding a single vers.n+1 RI to a bunch of vers.n
  RIs will change the EnvelopedData version even though there are vers.n RIs
  there which could be processed (that is, the code could still process the
  EnvelopedData except that the presence of the vers.n+1 value for the
  EnvelopedData would stop it).  OTOH if the EnvelopedData version is only
  incremented when the overall structure of the EnvelopedData is changed then
  it's fine, because it won't try and decode something in a completely
  different format.

Consider what will happen if the scheme you propose is used.  If I produce
something with RSA and <foo, where foo = some exotic new method> key transport
and set the syntax version number to anything other than 0, existing clients
will break.  If I set it to 0 there's at least some chance that existing
clients will handle it if they see the RSA RI first (that is, setting it to 0
may or may not work, but setting it to n will definitely break an existing
client... I think I modified my code at one point to specifically emit the
original RI's first so that existing apps would see them before they saw any of
the new types).  In addition if an implementation sees a syntax version number
of n then that doesn't mean that there isn't version 0 (or whatever)
information in there which it can still use.  As a result the only behaviour
for an implementation which makes much sense is:

  - When consuming data, ignore the version number.  Just because it's labelled
    version 3 doesn't mean there isn't version 0 information in there
    somewhere, which makes the syntax version value meaningless.

  - When producing data, call it version 0.  This may or may not work with
    existing implementations, but it's better than calling it version 3 which 
    definitely won't work with existing applications.

As I mentioned in my previous post, once implementation developers consider the
implications of the syntax version numbers it won't matter what the spec says,
what will be implemented is what causes the least interop problems.  I'll
repeat again my previous suggestion that in this area the spec codify what
implementations are doing rather than forcing arbitrary restrictions on them.

Peter.

---

From: "Housley, Russ" <[email-masked]>
Date: Tue, 17 Jul 2001 19:34:39 -0400

Peter raises an interesting point here.

Does a change to a subordinate RecipientInfo structure necessarily require 
a change to the EnvelopedData version.  Consider the following.

Peter wants to encrypt a message for two recipients, Jim and John.  Jim has 
S/MIME v2!  To accomodate Jim, Peter uses RSA PKCS#1 v1.5 key transport for 
the 3-DES key.  John has a new widget, so Peter uses it to send the same 
3-DES CEK, but the new widget requires an updated RecipientInfo 
structure.  If the overall EnvelopedData version must be updated to handle 
the RecipientInfo for John, then Jim will reject the message, even though 
he would be able to parse the portion of the message intended for him.  Jim 
has no reason to decode the RecipientInfo intended for John.

What is the best way to handle backward compatibility?

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 18 Jul 2001 12:01:57 -0700

Russ,

It is my opinion that there is no way to handle this for backwards
compatability.  In all likely hood my code will croak upon hitting John's
RecipientInfo in the current world.  This is the reason that we are adding
the requirement to accept new RecipientInfo structures without croaking on
them in the future.

It is my belief that the EnvelopedData version number will no longer need to
be incremented after CMS-bis is published since complient implemenations
will know that there is a hole for adding new RecipientInfo types to the
structure.  Something that might have been implied in the past but was
definitely not explicit.

jim

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Housley, Russ
> Sent: Tuesday, July 17, 2001 4:35 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01
>
>
>
> >   added then it's bad, because adding a single vers.n+1 RI
> to a bunch of
> > vers.n
> >original RI's first so that existing apps would see them
> before they saw
> >any of
> >   - When consuming data, ignore the version number.  Just
> because it's
> > labelled
> >     existing implementations, but it's better than calling
> it version 3
> > which