ietf-smime
[Top] [All Lists]

Re: Comment on ESS and Privacy Marks

1998-03-27 06:33:12
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



<Prev in Thread] Current Thread [Next in Thread>