All,
Upon further reflection, I agree with Jim that the ESS SecurityLabel
PrivacyMark syntax should be enhanced.
Recommend the following:
ESSPrivacyMark ::= CHOICE {
pString PrintableString (SIZE (1..ub-privacy-mark-length)),
utf8String OCTET STRING -- MUST contain UTF-8-encoded characters
}
Also recommend re-naming the ESS SecurityLabel as follows:
ESSSecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
security-classification SecurityClassification OPTIONAL,
privacy-mark ESSPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }
This will allow ESS-compliant software to construct a ESSSecurityLabel that
includes the ESSPrivacyMark pString CHOICE which will be directly compatible
with a standard X.411 SecurityLabel. This is true because the
ESSPrivacyMark pString CHOICE encoding is identical to the PricacyMark
printableString encoding because the CHOICE does add a tag.
Alternately, the ESS software can construct a ESSSecurityLabel that includes
ESSPrivacyMark utf8String CHOICE to meet the requirements of foreign
lanquages, etc.
This strategy allows CMS/ESS applications to share common access control
decision functions (ACDF) and other software modules that use the X.411
securityLabel syntax. The common ACDF software can be developed to
recognize the ESSPrivacyMark CHOICE so that it can accept standard X.411
SecurityLabels (containing PrivacyMark printableString) and ESS
SecurityLabels (containing either privacyMark pString or utf8String CHOICE).
The alternaive of defining a standard security category for UTF8-String
would be extremely difficult because every security policy would have to
recognize the standard SecurityCategory OID and syntax.
- John Pawling
At 02:35 PM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
John,
I have a real problem with this. What you are saying is that as a
general client it is not possible to make any sort of constent use the
the PrivacyMark field when building a security label policy. It is
usable if you are in the US but not otherwise. This is another case
where we are now looking at two different ways of accomplishing the same
task.
I made a general assumption that as a client I should show the contents
of the privacy mark someplace (otherwise why bother having the field),
but I am unable to do this in a general way.
If this is really what you want to do maybe we should make this a well
defined OID in the SecurityCategory upfront
jim
-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
Sent: Friday, February 13, 1998 1:18 PM
To: Ietf-Smime (E-mail)
Subject: Re: Comment on ESS and Privacy Marks
Jim,
I respectfully disagree with your proposal. Any information that one
would
wish to place in a PrivacyMark can also be placed within a
SecurityCategory.
The SecurityCategory is a pair of {OID, ANY}. An ASN.1 syntax can be
defined for use in the SecurityCategory ANY field that is identified by
the
SecurityCategory OID. The securityLabel security-policy-identifier
identifies the security policy which defines how the SecurityCategories
are
defined and used. An ASN.1 syntax can be defined for the
SecurityCategory
such that there are object identifiers identifying the various
sub-fields of
the SecurityCategory ASN.1 syntax. These OIDs can (among other things)
identify whether or not access control is required on the specified
sub-field. Therefore, one could define a SecurityCategory ASN.1 syntax
that
could include a BMPString (or other) which could be uniquely identified
as
not requiring access control. That achieves the same goal as your
proposal
without changing the SecurityLabel syntax. The SecurityLabel syntax
included in ESS was chosen to be compatible with the X.411 securityLabel
that is used in X.400 and many existing programs such as the US DoD
Defense
Message System. I believe that it is an important goal to retain the
X.411
SecurityLabel syntax in ESS to promote interoperability with existing
protocols and software that use the X.411 security label. Also, I
believe
it is important to retain the X.411 syntax so that CMS/ESS applications
can
share common access control decision functions and other software
modules
that are already developed for use with the X.411 security label syntax.
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 11:59 AM 2/13/98 -0800, Jim Schaad (Exchange) wrote:
I think that we have a problem with privacy marks as currently
represented in the ASN. To be specific we are currently limited to
PrintableCharacters. I believe that we must expand this to allow for
use of non-English langages. I therefore propose that we switch to the
following definition of PrivacyMark
PrivacyMark ::= CHOICE {
PrintableString (SIZE (1..ub-privacy-mark-length)),
BMPString (SIZE (1..ub-privacy-mark-length))
}
jim schaad