There is a problem with making essSecurityLabel critical. This means
that it cannot be used in S/MIME v2 clients and they will not understand
the signed message which comes in. The version on the signedData object
would be 3. With this change we have now moved to the point where no
items in ESS (except for mlExpansionHistory which is a server side
"feature") can be done with S/MIME v2. If we accept this then we need
to re-write the intro to ESS.
jim
-----Original Message-----
From: jsp(_at_)jgvandyke(_dot_)com [mailto:jsp(_at_)jgvandyke(_dot_)com]
Sent: Wednesday, February 25, 1998 2:29 PM
To: Russ Housley; phoffman(_at_)imc(_dot_)org
Cc: ietf-smime(_at_)imc(_dot_)org
Subject: Re: Criticality of Authenticated Attributes
All,
I agree with Russ. Furthermore, I believe that essSecurityLabel should
be
the only attribute that is required to always be critical. ESS should
not
require criticality for attributes that legacy products need to process
(contentType, messageDigest, signingTime, smimeCapabilities). I don't
believe that the following new attributes should be mandated to always
be
critical: contentIdentifier, mlExpansionHistory, receiptRequest, and
contentHints. So, that only leaves essSecurityLabel as being mandatory
critical.
Furthermore, I recommend that the following text should be added to the
description of the critical flag in CMS, Sec 5.2: "Note that setting
critical to TRUE will cause interoperability problems with legacy
software
that does not recognize the AuthAttribute ASN.1 syntax."
================================
John Pawling
jsp(_at_)jgvandyke(_dot_)com
J.G. Van Dyke & Associates, Inc.
================================
At 08:48 AM 2/25/98 -0500, Russ Housley wrote:
Paul:
Please add a sentence to the description of each authenticated
attribute.
We need to specify whether the attribute is always critical, never
critical, or the originator's choice.
I think that security label should always be critical.
Russ