-----Original Message-----
From: Russ Housley <housley(_at_)spyrus(_dot_)com>
To: ross <ross(_at_)jgross(_dot_)demon(_dot_)co(_dot_)uk>
Cc: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
Date: Saturday, 31 January 1998 6:41
Subject: Re: Critical Attributes
:All:
:
:The current ASN.1 syntax of attribute is actually a bit of a problem. If
:an attribute is encountered that is unknown, the ASN.1 decoder might die.
:To avoid this problem, X.509v3 extensions all have a type of OCTET STRING.
This just pushes the problem up one level.
This problem is common with any OID anydefined by construction.
Unknown syntax is a common issue that all implementor have to address in
many other places today.
Once done its not a problem, so I would not worry about fixing a non
existant problem.
:These extensions require a second decode pass to extract the extension
:value from the OCTET STRING.
I prefer to handle in a single pass, unknow syntax should be handled in the
first pass, the OCTET STRING
just complicates the problem for NO gain.
General solution dont mess with the syntax to fix broken parsers, fix the
broken parsers, keep it simple.
:
:Can some folks with real life implemntation experience of ANY offer
:suggestions?
:
:Russ
:
:
:>-----Original Message-----
:>From: Russ Housley <housley(_at_)spyrus(_dot_)com>
:>To: ietf-smime(_at_)imc(_dot_)org <ietf-smime(_at_)imc(_dot_)org>
:>Date: Thursday, January 29, 1998 9:53 AM
:>Subject: Critical Attributes
:>
:>
:>>All:
:>>
:>>There has benn much discussion of attribute criticality. It is my view
:>>that there is concensus that the feature is needed. Two mecanisms for
the
:>>addition of this feature have been offered.
:>>
:>>First alternative: include a BOOLEAN in the attribute definition that
:>>states the criticality of the the attribute. If the attribute is marked
:>>critical and an implementation does not know how to process the
attribute,
:>>then the message must be rejected.
:>>
:>>Second alternative: include a new attribute that lists the OIDs of all
:>>critical attributes.
:>>
:>>In terms of backward compatibility with S/MIME 2, these two mechanisms
have
:>>very different implications.
:>>
:>>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
:>
smime.p7s
Description: S/MIME cryptographic signature