From: Russ Housley <housley(_at_)spyrus(_dot_)com>
By defining a DEFAULT value for the BOOLEAN, all non-critical attributes
will be backward compatible. Also, we can use the S/MIME 3 version to
indicate that critical attributes are present. This use of version should
keep an S/MIME 2 implementation from having an ASN.1 decode error. The
ASN.1 would be:
Attribute ::= SEQUENCE {
attributeType OBJECT IDENTIFIER,
critical BOOLEAN DEFAULT FALSE,
attributeValues SET OF AttributeValue }
AttributeValue ::= ANY
On the other hand, the critical attribute list makes no change to the
syntax. However, an S/MIME 2 implementation would simply ignore this
attribute as it would any other unsupported attribute. So, the criticality
of the attributes would not really be imposed.
This breifi analysis leads to to the coluclusion that the critical boolean
is a better path. Is there concensus on this point?
Russ
What is the behavior of an S/MIME v2 implementation on receiving a
message with version=3 ?
If this behavior (I assume it is to refuse to decode or display the
message at all) is an acceptable outcome for a message containing
a critical authenticated attribute, then I agree that the boolean
flag is better.
But if the goal is to maximize backward compatibility of v3-generated
messages to v2 implementations, acknowledging that S/MIME v2
implementations have *no* support for criticality processing, then
the OID list approach is better.
I guess it is up to those who have some application for critical
attributes in mind to decide whether the preferred v2 UA behavior is to
reject the message or to process/display it (perhaps with an indication
that an unrecognized attribute was attached).