Jim (and friends),
The current ESSSecurityLabel syntax is backwards compatible with the X.411
securityLabel syntax except when the privacyMark UTF8String CHOICE is
present. IMHO, there is significant value in maximizing backward
compatibility of the ESSSecurityLabel syntax with the X.411 securityLabel
syntax . There are many security protocols (such as MSP 3.0, ACP120, X.411)
which use the X.411 securityLabel. IMHO, it is beneficial to maximize the
consistency of the security label syntaxes used in these various security
protocols to make life easier for the users and for the implementors of
these various protocols.
Furthermore, there are folks that would like to see a standard security
label syntax used in all security protocols (e.g. X.411, S/MIME v3, etc).
They have selected the ESSSecurityLabel as their candidate to serve as the
standard security label. They are planning to propose a change to the X.411
syntax that would add support for the privacyMark UTF8String CHOICE. If they
are successful, then the X.411 securityLabel and ESSSecurityLabel syntaxes
would be identical. They are also planning to propose the ESSSecurityLabel
to ISO as the international standard security label. Maximizing
compatibilty with X.411 is important to this group.
Also, there are organizations that would like to achieve interoperability
between S/MIME v3 applications and legacy applications that use the X.411
securityLabel. Maximizing the backward compatibility of the
ESSSecurityLabel with the X.411 securityLabel makes their job easier.
In summary, I don't believe that changing the ESSSecurityLabel from a SET to
a SEQUENCE is a necessary change. I believe that the version number should
be deleted from the ESSSecurityLabel syntax because the attribute OID
uniquely identifies the syntax. Furthermore, changing the ESSSecurityLabel
from a SET to a SEQUENCE significantly decreases the backward compatibility
of the ESSSecurityLabel syntax with the X.411 security label syntax, so I
oppose the proposal.
- John Pawling
At 01:46 PM 5/23/98 -0700, Jim Schaad (Exchange) wrote:
Once upon a time in the vague recesses of my mind I remember this issue
coming up. While I agree there are a number of good reasons for not having
the version field anyway (versioning could be done by just using a new OID
if necessary), I though that we had agreed that we were going to fix this by
turning the SET into a SEQUENCE and thus getting the version field first.
We have already made the break with the old encoding of security labels so
there should be no problem with this.
jim