I still believe that the legacy software is an issue because it will reject
the signedData when it detects the new version number that it doesn't
recognize, so the outcome is the same (i.e. the signedData won't be decoded
and verified). However, your recommended wording is fine with me.
- John Pawling
At 09:26 AM 2/26/98 -0500, Russ Housley wrote:
I do not think that "legacy software" is an issue. If any of the attributes
are critical, the version number should handle that situation.
Caution should be exercised in adopting any critical attributeswhich might
At 05:28 PM 2/25/98 -0500, John Pawling wrote:
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
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."
J.G. Van Dyke & Associates, Inc.