Russ,
I believe that the EnvelopedData version number-setting algorithm should be
changed when the
overall structure of the EnvelopedData syntax is changed (such as adding a
new alternative directly to the RecipientInfo CHOICE). 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. I still
believe that the EnvelopedData version number-setting text that I proposed
in earlier messages is the best solution.
In reference to your example, if the key management information required by
John is included in the ori alternative of the RecipientInfo CHOICE, then I
agree that Jim's receiving S/MIME implementation need not decode the
oriValue if it first finds a ktri alternative of the RecipientInfo CHOICE
for Jim. However, if the key management information required by John is
included in a new alternative added directly to the RecipientInfo CHOICE,
then I disagree with the notion that all S/MIME implementations can ignore
an unrecognized alternative in a CHOICE.
You stated: "If the overall EnvelopedData version must be updated to handle
the RecipientInfo for John, then Jim will reject the message," I disagree
with the theory that the EnvelopedData version value alone will cause
implementations to reject an EnvelopedData object. Nobody (except for
Peter) has 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.
In summary, adding new alternatives directly to the RecipientInfo CHOICE
does not maintain backwards compatibility with previous EnvelopedData
syntaxes. Using the ori syntax to add support for an additional key
management technique does promote backwards compatibility because it does
not change the overall structure of the EnvelopedData syntax.
===========================================
John Pawling, John(_dot_)Pawling(_at_)GetronicsGov(_dot_)com
Getronics Government Solutions, LLC
===========================================
-----Original Message-----
From: Housley, Russ [mailto:rhousley(_at_)rsasecurity(_dot_)com]
Sent: Tuesday, July 17, 2001 7: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