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


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: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Housley, 
Russ
Sent: Tuesday, July 17, 2001 4:35 PM
To: pgut001(_at_)cs(_dot_)aucKland(_dot_)ac(_dot_)nz
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

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

At 02:37 PM 7/11/2001 +0000, Peter Gutmann wrote:

"Pawling, John" <John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com> 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.