Russ Housley writes:
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.
These extensions require a second decode pass to extract the extension
value from the OCTET STRING.
Can some folks with real life implemntation experience of ANY offer
suggestions?
Russ
Russ,
In practice, the second decode pass isn't because of the OCTET STRING.
Rather, because the sequence can have arbitrary values in arbitrary
order, the obvious data structure you would parse the values into
would be a union of all the possible value types. Unfortunately,
that is rarely the more desirable data structure to parse the data
into. So instead, the sequence is parsed to obtain the OIDs, and then
each value is parsed individually (when convenient to do so).
That is, the OCTET STRING by itself does not negate single pass decoding.
In fact, you can convert any OCTET STRING to an ANY by replacing
"OCTET STRING" in the ASN.1 with "[UNIVERSAL 4] IMPLICIT ANY"
(notwithstanding the howling from ASN.1 purists :). Most tools support
this, and in practice this sort of ASN.1 mangling is employed with
great success to provide implementation flexibility. Thus, from the
standpoint of implementation, I often prefer OCTET STRING to ANY
because I--as an implementor--can choose which way I want to treat the
data.
That said, I would vote for backward compatability: that AttributeValue
continue to be an ANY.
brian
briank(_at_)terisa(_dot_)com