Chris,
I agree with Paul that the ESSSecuritylabel is completely compatible with
the X.411 SecurityLabel when the privacyMark choice is PrintableString. In
fact, I would encourage you to propose to the ITU that the X.411
securityLabel should be similarly enhanced.
Furthermore, I respectfully disagree with your counter-proposal of defining
a standard securityCategory syntax to hold the privacyMark UTF8String. The
X.411 spec states that the security policy in force (identified by the
securityLabel security-policy-identifier) is used to indicate the syntaxes
that are allowed to be present in the securityLabel security-categories.
This implies that every organization's security policy (that uses the
ESSSecurityLabel) would have to include the standard definition of the
privacyMark security-category using the identical OID. IMHO, there is no
way that all of the organizations are going to agree on any standard
security-categories or using an identical OID. Security-categories are
considered to be a matter of local policy and the various organizations are
not going to accept a standard security category forced on them.
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 02:54 PM 3/26/98 -0500, Bonatti, Chris wrote:
Let's be clear, however, that conveying the UTF-8 string as a security
category allows the result to be compatible regardless of whether UTF-8 is
used. There is already a perfectly good extension mechanism included in the
X.411 label. Can somebody spell out for me the reason for NOT using it to
address the UTF-8 requirement? The way I see it, the current solution is
creating a problem that does not need to be created.
Chris