Re: ASN.1 Encoding Technique

[Love Hörnquist Åstrand <lha@kth.se>]

"Geoff Elgey" <Geoff.Elgey@quest.com> writes:

> G'day,
>
>> Consider the following ASN.1:
>>
>> Record ::= SEQUENCE {
>>    name [0] Name OPTIONAL,
>>    oid  [1] OBJECT IDENTIFER
>> }
>
> This reminds me -- in order to get a UPN from an extension in a Certificate, I
> had to change the definition of GeneralName in rfc2459.asn1 from:

I've already notice this problem and have updated the defintion some time
ago.

> The problem is that implicitly tagged named types are not handled correctly in
> Heimdal's ASN.1 code.
>
> When attempting to decode an otherName field of GeneralName, the decoder
> attempts to decode the tag [0], then calls the decode function for Othername,
> which attempts to decode the tag for SEQUENCE. Of course, just the tag for [0]
> is required for the 'otherName' field as OtherName is implicitly tagged.

If you check the current code-base, there is lib/asn1/canthandle.asn1 that
describes the current problems with the current asn1 compiler.

The reason why I didn't fix it when I found the problem is that I didn't
want to add a new entry point for every structure, and didn't want to
change the API/ABI by adding a flag to the decode_/encode_ functions.

The workaround is bad because then you don't get a name of the element
(anonymous structure), so you have to restort to doing stuff like this:

	GeneralSubtrees gs;
	if (tnc.permittedSubtrees) {
	    gs.val = tnc.permittedSubtrees->val;
	    gs.len = tnc.permittedSubtrees->len;
	    ret = append_tree(&gs, nc->nc.permittedSubtrees);
	}

Love

PGP signature