[kitten] CAMMAC ASN.1 module issues

[Greg Hudson <[e-mail]>]

While working on creating test vectors for CAMMAC using asn1c, I noticed
into three issues with the ASN.1 module.  Two are just matters of form,
but the third will affect the encoding if we decide to change it.  I
believe we're at a slightly awkward stage of the workflow for this
draft, but at least we are still before IETF last call.

1. The ASN.1 module needs IMPORTS declarations for the RFC 4120 types it
uses.  I have submitted a pull request to Tom's github repository with
the necessary import statements.

2. There is no OID in the module declaration.  I don't know how
important this is in practice, but all of the other Kerberos-related
ASN.1 modules I looked at have OIDs.

3. Verifier is defined as an untagged CHOICE with just one initial
choice:

   Verifier             ::= CHOICE {
         mac            Verifier-MAC,
         ...
   }

The last time we used this kind of extensibility was PA-FX-FAST-REQUEST
in RFC 6113:

   PA-FX-FAST-REQUEST ::= CHOICE {
       armored-data [0] KrbFastArmoredReq,
       ...
   }

While armored-data has an explicit [0] context tag, Verifier's mac field
does not.  Therefore, the Verifier-MAC will appear in the DER encoding
of Verifier with just its usual sequence tag (universal 0x10).

On the positive side, the lack of a context tag here typically saves
four bytes per CAMMAC (two for each Verifier).  If we never add
additional choices to Verifier, the unused extensibility costs us
nothing on the wire; the DER encoding looks just like it would if we had
directly used Verifier-MAC within AD-CAMMAC.

But if we do add additional Verifier choices, there is an implementation
constraint.  We would likely use context tags for subsequent choices, as
it would be an ASN.1 violation to simply add another field with a
sequence type.  The ASN.1 decoder for Verifier would need to be able to
process either a context tag or universal sequence tag.  The current MIT
krb5 ASN.1 implementation can handle this (we don't make assumptions
that choices use context tags; we just match the tag we read against the
expected tag of each choice in turn), but I don't know about other
implementations.

My current preference is to leave this alone, but I wanted to make sure
it was discussed explicitly in the working group and doesn't just slip
through.  Apologies if we discussed this before.