ietf-smime
[Top] [All Lists]

Re: Comment on ESS and Privacy Marks

1998-03-27 21:15:35
John Pawling wrote:

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.

John,

    With all due respect, you guy must have a unique view of backward 
compatibility.  Yeah, sure the definition has a printable string mode, but if 
you actually USE the enhancement.  Existing ACDFs will choke.  Any time you 
elect for "sender's choice" this issue arises.

    Modifying X.411 is a nice idea for the long term, but it also doesn't 
address the concern for backward compatibility with existing ACDFs.


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.

    This just doesn't make any sense.  If the various security policies won't 
support an additional category, then why should we expect them to support the 
new syntax at all?  Surely any organization whose policy specifies use of a 
privacy mark with extended characters would require support of a pre-defined 
category defined for that purpose.  On reception, supporting the category is 
certainly no more of a stretch than support policy mapping for every 
organization's policy.  They would all have to implement the new syntax for the 
privacy-mark field anyway, so getting them to implement reception of the new 
category should be no harder.  Plus, with the category approach, you have the 
additional benefit that you get graceful degradation for systems that don't 
process the new syntax.

    What exactly are the benefits to the current approach that make it so 
desireable?  This is, after all, a new attribute so there shouldn't be a lot of 
inertia to overcome.

Chris B.


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