ietf-smime
[Top] [All Lists]

Re: security label

1998-04-09 11:09:21
John,

The ESSSecurityLabel Version2SecurityLabel meets your requirement to
communicate the same data as is communicated in the X.411 security label.
The existing access control mechanisms implemented for the X.411 security
label can be used in conjunction with the ESSSecurityLabel
Version2SecurityLabel.  Even though the ESSSecurityLabel
Version2SecurityLabel and X.411 security label syntaxes are slightly
different, they still carry the same data fields which result in the same
decoded data being presented to the access control software.

================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com                             
J.G. Van Dyke & Associates, Inc.   
www.jgvandyke.com         
================================



At 06:51 PM 4/9/98 -0700, John Ross wrote:
John (too many of us with that name)

I am aware that there may be many attributes that are signed over using CMS
signed data, I am aware that this requires major modification to the non-CMS
implementation.  However, I respectfully disagree with you that if you use
CMS as the security protocol that backward compatibility with the X.411
security label is not an issue.  In particular, environments that may want
to use a CMS security label are the same environments that may be using the
X.411 label, and have built and implemented access control based on decoded
data using the X.411 syntax.

However, seem pointless continuing a debate if you do not accept that
premise.

As to the issue on origination, I believe can easily be solved the X.411
label syntax should be used unless the extended character set is required.

Hope you have a good Easter holiday.

Regards

-----Original Message-----
From: John Pawling <jsp(_at_)jgvandyke(_dot_)com>
To: John Ross <ross(_at_)jgross(_dot_)demon(_dot_)co(_dot_)uk>; 
ietf-smime(_at_)imc(_dot_)org
<ietf-smime(_at_)imc(_dot_)org>
Date: Thursday, April 09, 1998 9:39 AM
Subject: Re: security label


John,

I respectfully disagree with your proposal because it adds significant
complexity to the ESSSecurityLabel syntax which I believe is not needed.
IMHO, S/MIME should only adopt the Version2SecurityLabel.  It provides the
equivalent capabilities as the X.411 security label.  That was the goal of
ESS.

IMHO,there is no requirement for bits-on-the-wire backwards compatibility
with the X.411 security label.  There are not any S/MIME v2 agents using
X.411 securityLabels so backwards compatibily is not an issue.

You stated:
The above should mean that any signature that signs over the x.411 label
will operate end to end even if it has to cross a gateway between  a
domian
that only suppports the X.411 securty label and a domain that supportes
both
the X.411 and version2 labels.

I respectfully disagree with your conclusion.  Please see my message to the
S/MIME mail list dated Fri, 27 Mar 1998 08:34:23 -0500, subject: "Re:
Comment on ESS and Privacy Marks" for a detailed explanation of why I
believe that your conclusion is impractical.  I am not going to repeat all
of that text here, but I want to reiterate the following point.  The
ESSSecurityLabel is not separately signed as part of CMS.  It is digested
along with the other CMS signedData signerInfo authenticatedAttributes as
part of the CMS signature generation process.  Therefore, if the signature
over the ESSSecurityLabel was to be preserved, then a non-CMS app would
need
to be able to hash the original signedData signerInfo
authenticatedAttibutes
and the content to verify the original CMS signature.  This will require
major modifications to the non-CMS apps.  If people are considering such
major modifications, then they should just consider implementing CMS as
their standard security heading.

In summary, I disagree with your proposal because it adds significant
complexity to the ESSSecurityLabel format which I believe is not required
because the CMS-to-non-CMS translating software can accommodate any
differences between the ESSSecurityLabel and X.411 security label
representations.

Furthermore, if your proposal is accepted, how would an originator know
which ESSSecuirtyLabel choice to use???  She would need to determine which
flavor that the recipient prefers.  What if some of the recipients prefer
X.411 and some prefer version2???  Would you then send two separate
messages???  This adds more and more complexity.

================================
John Pawling, jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
www.jgvandyke.com
===============================


At 10:32 AM 3/29/98 +0100, John Ross wrote:
As per pevious comments on compatiblity between X.411 security label and
the
eSSScecurityLable, I think the following would offer more compatibility
and
allow for the extended character set:

eSSSecurityLable::= Choice{
   x411-security-label  Security label,
   version2-security-label Version2Securitylabel}

SecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier OPTIONAL,
security-classification SecurityClassification OPTIONAL,
privacy-mark PrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }

Version2SecurityLabel ::= SET {
security-policy-identifier SecurityPolicyIdentifier,
security-classification SecurityClassification OPTIONAL,
privacy-mark  ExtendedPrivacyMark OPTIONAL,
security-categories SecurityCategories OPTIONAL }

ExtendedPrivacyMark ::= UTC-8 STRING.


Then rules can be specified, that mandate the X.411 label is generated
unless the extended character set is required, then version 2 security
label
shall be generated.

The above should mean that any signature that signs over the x.411 label
will operate end to end even if it has to cross a gateway between  a
domian
that only suppports the X.411 securty label and a domain that supportes
both
the X.411 and version2 labels.

I also think that maintains structual compatibility between the X.411 and
version2 signatures.

Any comments?

John Ross








<Prev in Thread] Current Thread [Next in Thread>