ietf-smime
[Top] [All Lists]

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

2001-07-10 19:37:36

"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.