I think you have some valid arguments, I also agree that the current X.411
printable string syntax has its limitations in an international scenario.
But I still think we should try and maintain compatibity between the two
label where possible.
I also agree that we can propose some ehancements to the X.411 label which
may help to keep alignment in the future.
But I disagree when you imply that a signed security label can be changed
when passes through a gateway, the aim is for as much interoperability as
possible, so the signatures of data objects which are not translated by
gateways can be applied end to end. In that case the security label cannot
be translated.
-----Original Message-----
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: John Ross <ross(_at_)jgross(_dot_)demon(_dot_)co(_dot_)uk>;
ietf-smime(_at_)imc(_dot_)org
<ietf-smime(_at_)imc(_dot_)org>; Paul Hoffman / IMC
<phoffman(_at_)imc(_dot_)org>
Date: Friday, March 27, 1998 5:33 AM
Subject: Re: Comment on ESS and Privacy Marks
John,
I respectfully disagree with your comments. The X.411 securityLabel syntax
was included in ESS to maximize the re-use of existing software. It was
not
included in ESS to provide direct bits-on-the-wire compatibility with
existing non-CMS security protocols. You state "An implementation which
understands the X.411 label...", but there are not any commmercially
deployed S/MIME user agents (that I know of) currently using the X.411
securityLabel syntax as an authenticatedAttribute. Therefore, direct
backwards compatibility between eSSSecurityLabels and S/MIME v2 agents
using
X.411 securityLabels is not an issue.
Any security heading that is currently using the X.411 securityLabel is not
implementing CMS, so a translation step will be required between CMS and
the
non-CMS security heading. When a CMS signedData object is received by an
organization implementing a non-CMS legacy security protocol, then software
that recognizes the CMS signedData format will be required to initially
decode and verify the original CMS signer's signature. That software will
then need to translate the received CMS signedData format into the format
of
the legacy, non-CMS security heading that includes the X.411 securityLabel.
In other words, there will need to be a gateway that tranlates the CMS
signedData object into the legacy format.
Therefore, any interoperability between eSSSecurityLabels and X.411
securityLabels will occur as part of the process of translating the CMS
signedData format to the non-CMS format that uses X.411 securityLabels (and
vice versa). During that translation process, the eSSecurityLabel can be
translated to an X.411 securityLabel. The received eSSSecurityLabel will
be
bits-on-the-wire identical to the X.411 SecurityLabel when the privacyMark
choice is PrintableString. If the eSSSecurityLabel privacyMark choice is
not PrintableString then the non-CMS translating software will need to map
the UTF8String to another representation such as a security-category
defined
by the recipient local organization's security policy.
IMHO, changing the original signer's eSSSecurityLabel privacyMark during
the
CMS-to-non-CMS translation process is acceptable because the originator's
CMS signature can't be verified by the end-user recipient anyway because
that user's legacy software won't have the capability of verifying CMS
signatures. In other words, the end-user's legacy software will not be
prepared to hash the original signer's signedData signerInfo
authenticatedAttributes in order to directly validate the original signer's
signature. The gateway will not be able to preserve the original signer's
signature during the translation process.
The X.411 SecurityLabel privacyMark syntax is woefully inadequate. I
encourage you to propose to the ITU that the X.411
securityLabel should be enhanced to be identical to the eSSSecurityLabel.
Please see my reponse to Chris Bonatti's messsage for my explanation of why
the "globally defined" security-category will not work.
In summary, I believe that the ESSPrivacyMark should not be changed.
================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
================================
At 08:28 AM 3/27/98 -0800, John Ross wrote:
The problem with the current proposal is not only on origination, but on
reception. An implementation which understands the X.411 label will expect
printable string and not expect UTF-8, so what does it do if the UTF-8
string contains extended characters, it may try to display them as
printable
characters, it may not?
I agree with Chris that a more elegant solution to this problem would be
to
define a security category to convey the enhanced string value? this
offers
a fully flexible solution which uses the valid extension mechanism
provided
by the X.411 label .
John Ross