ietf-smime
[Top] [All Lists]

RE: Comment on ESS and Privacy Marks

1998-02-13 15:28:56
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