I've noted the discussion of privacy-mark character sets here and the GREAT
concern over ASN.1 encodings, but have witnessed little sound and fury over the
break in backward compatibility that this change to the label will create.
I think that expanded character sets are generally useful, but you need to
recognize that you're not necessarily working from a blank slate. The label in
the previous ESS draft was aligned with the X.411 security label. This label
structure has gained a fair amount of acceptance, and is used in a number of
areas including X.500, and non-OSI systems. I was pleased to see it appear in
ESS. Changing the privacy-mark field makes the ESS label incompatible with the
existing X.411 security label structure. Using an alternate encoding or
character set for the existing field is certain to impact existing
implementations that provide and consume security labels.
If the requirement for richer character sets is legitimate, then why not
define a security category to convey the enhanced string value? That has the
advantages of being fully compatible with the X.411 label, providing the
desired functionality, and also affording the opportunity to perhaps more
accurately identify the character set (i.e., one category OID for UTF-8,
another for Unicode, etc.).
Chris
---------------------------------------------------------------
| International Electronic Communication Analysts, Inc. |
| Christopher D. Bonatti 9010 Edgepark Road |
| Vice-president Vienna, Virginia 22182 |
| bonattic(_at_)ieca(_dot_)com Tel: 301-212-9428 Fax: 703-506-8377 |
---------------------------------------------------------------