David P. Kemp wrote:
From: Russ Housley <housley(_at_)spyrus(_dot_)com>
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
This might be a problem for some implementations, but it doesn't have
to be.
Amen. Folks have been handling ANY (TYPE-IDENTIFIER.&Type in 1994,
almost) for some time. Folks using 1988 Tools that are implementing
the ASN.1:1994 SET protocol implement TYPE-IDENTIFIER.&Type using
the same code they use for ANY. Such toolkits then augment this code,
or have the using application do so, with a little code to verify
that the hex blob that follows the ANY is a valid ASN.1 type. Simple.
X.509 has three extensible object classes: certificate extensions,
algorithms (as used in algorithmIdentifier), and RDN attributes. Only
certificate extensions are encapsulated in an OCTET STRING hole.
If one wants a robust certificate decoder, one must be prepared to find
unrecognized data in the other two classes.
Yes. My understanding is that the Cert Extensions class used OCTET
STRING only for backwards compatibility with deployed X.400 systems.
At one point my certificate decoder was not robust :-). But I believe
it can handle anything now without croaking. At least it deals
correctly with all instances of unsupported data types that have been
thrown at it so far.
This is correct behavior for any decent ASN.1 tool. As versions of this
standard evolve, such tools are supposed to expect new types: BMPString
in 1994, UTF8String in 1998. The obvious way to handle such events is
to simply treat them like an open type (ANY). That is the same thing as
saying, merely step over the tag and length octets and leave the thing
undecoded. This is precisely how SET MsgExtensions, a derivative of
X.509 Extensions work. The sequence is decoded, and an OID inside and
a BOOLEAN criticality flag are fully decode. The associated type is
not fully decoded, but carried as an open type (ANY - a struct with an
integer length and a pointer to a character string).
Phil
--
Phillip H. Griffin Griffin Consulting
asn1(_at_)mindspring(_dot_)com ASN.1-SET-Java-Security
919.828.7114 1625 Glenwood Avenue
919.832.7008 [mail] Raleigh, North Carolina 27608 USA
------------------------------------------------------------
Visit http://www.fivepointsfestival.com
------------------------------------------------------------