ietf-smime
[Top] [All Lists]

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

2001-07-11 08:06:14

Peter,

My comments are in-line.

-----Original Message-----
From: pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz 
[mailto:pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz]
Sent: Wednesday, July 11, 2001 10:38 AM
To: John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com; 
ietf-smime(_at_)imc(_dot_)org
Subject: RE: Comments to draft-ietf-smime-rfc2630bis-01

<snip>

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, 

[John: That is not what I am proposing.  I am proposing that the
EnvelopedData version number-setting algorithm should be changed because the
overall structure of the EnvelopedData syntax is being changed due to the
addition of the pwri and ori alternatives to RecipientInfo; and due to the
addition of the 2000 X.509 Attribute Certificate syntax to OriginatorInfo.
The ori syntax provides a mechanism for adding support for additional key
management techniques to RecipientInfo without changing the overall
structure of the EnvelopedData syntax.  The EnvelopedData version number
will not need to be changed if new key management techniques are added using
ori.] 

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

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.  When we
had this discussion in April, nobody (except for you) stated that their
implementations rejected an EnvelopedData based solely on the version value.
The S/MIME Freeware Library will not reject an object based solely on the
version value.  Typically, the version value is used as part of the process
of trying to determine why an implementation could not successfully process
an EnvelopedData object.] 

 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.

[John: The overall structure of the EnvelopedData is being changed.]

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.  

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.] 

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.

[John: I disagree.  The version value is used as part of the process of
trying to determine why an implementation could not successfully process an
EnvelopedData object.]

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

[John: I disagree with your statement that the EnvelopedData version number
value alone will cause implementations to reject an EnvelopedData.] 

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.

[John: I believe that most implementations will not reject an EnvelopedData
based solely on the version number value, so I believe that my proposal does
not force arbitrary restrictions on them.]

Peter.