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