The template compiler was applying IMPLICIT tags to CHOICE types. This
is very wrong, as the tag of a CHOICE's taken choice cannot be replaced
without making it impossible to figure out what the choice was. An
example of this is GeneralName's directoryName, which is an IMPLICIT-
tagged CHOICE.
Separately, the non-template compiler was requiring inlining of
IMPLICIT-tagged CHOICEs, which also happens in GeneralName's
directoryName case:
```
205 Name ::= CHOICE {
206 rdnSequence RDNSequence
207 }
...
287 GeneralName ::= CHOICE {
288 otherName [0] IMPLICIT -- OtherName --
SEQUENCE {
289 type-id OBJECT IDENTIFIER,
290 value [0] EXPLICIT heim_any
291 },
292 rfc822Name [1] IMPLICIT IA5String,
293 dNSName [2] IMPLICIT IA5String,
294 -- x400Address [3] IMPLICIT ORAddress,--
--->295 directoryName [4] IMPLICIT -- Name -- CHOICE
{
296 rdnSequence RDNSequence
297 },
298 -- ediPartyName [5] IMPLICIT EDIPartyName, --
299 uniformResourceIdentifier [6] IMPLICIT IA5String,
300 iPAddress [7] IMPLICIT OCTET STRING,
301 registeredID [8] IMPLICIT OBJECT IDENTIFIER
302 }
```
Anyways, that's fixed now, though changing that will require making
corresponding changes to `lib/hx509/`.
We're getting closer to parity between the two compilers. The template
compiler is still missing support for `SET { ... }` types. Speaking of
`SET { ... }`, the regular compiler generates code that uses `qsort()`
to sort the encoded values values of the members of such a set, but this
seems silly because the order of members is knowable at compile time, as
for DER and CER the order by the tags of the members, from lowest to
highest (see X.690, section 9.3 and X.680, section 8.6). As it happens
using `qsort()` on the encodings of the members works, but it would be
be better to sort in `lib/asn1/asn1parse.y` and then not have to bother
anywhere else. Sorting SETs at definition time will help keep the
tamplate compiler simple. Not that we _need_ `SET { ... }` for anything
in-tree other than the X.690 sample...
While we're at it, let's note that the core of PKIX from the RFC
2459/3280/5280/5912 consists of *two* ASN.1 modules, one with
default-EXPLICIT tags, and one with default-IMPLICIT tags, and
Heimdal has these merged as a default-EXPLICIT tags module in
`lib/asn1/rfc2459.asn1`, with `IMPLICIT` added in by hand in all the
tags in the default-IMPLICIT tagged module. This fixes one recently
added type from PKIX that didn't have `IMPLICIT` added in manually!
Nicolas Williams
8fde460772