PKINIT encoder/decoder issues

[Kevin Coffman]

On Tue, Oct 7, 2008 at 9:59 PM, Ken Raeburn <raeburn at mit.edu> wrote:
> I'm doing a bit of work on the ASN.1 encoder routines in the MIT
> Kerberos library, and in preparation for that am trying to make sure
> that more of the encoders and decoders are actually tested under "make
> check".  The mechanism we have for other (base protocol) types tested
> in src/tests/asn.1 is pretty straightforward:
>
> * We create a sample data structure, encode it, and compare the result
> (in hex) against saved copies.
>
> * We create a sample data structure, encode it, and feed the result
> through a little ASN.1 pretty-printer, and compare the result against
> saved copies.
>
> * We take a string with a sequence of hex values (stored separately
> from the above -- that's probably a bug), convert it to binary, feed
> it to the decoder to get a data structure, create our sample data
> structure, and recursively compare the two.
>
> These tests check for self-consistency and that our encodings don't
> change.  Checking whether the expected and actual results are
> *correct* is a separate matter, obviously.
>
> Extra tests are sometimes run for sequences with optional fields, or
> cases where we want to support some non-distinguished encoding variants.
>
> There are currently no tests for the PKINIT types; I've been working
> on writing some.  However, I see a few possible problems:
>
> In krb5_pk_authenticator_draft9, kdcRealm is set in the client-side
> plugin code but never used in the encoder or decoder.  (So obviously
> initializing and comparing the field doesn't work.)  It's a reference
> to the realm data stored in the kdcName field, and looks to me like it
> could just go away.

Yes.  I think there was some confusion.  The kdcRealm field is
redundant and unused.

> In krb5_pa_pk_as_req_draft9, we encode the optional field
> encryptionCert with a tag of 3, but when decoding, it looks like we
> want it to be 2, duplicating the tag on kdcCert.
>
> In the trusted_ca encoding, with the principalName choice, the decoder
> is complaining about an incorrect tag value; I think it may be out of
> sync.

According to the draft9 definition of PA-PK-AS-REQ, kdcCert should be
tag 2 and encryptionCert should be tag 3.  My initial reaction is that
this is a typo/bug in asn1_decode_pa_pk_as_req_draft9().
Unfortunately, I can't easily recreate the test environment to verify
that.

> The ANY DEFINED BY seems to confuse our pretty-printer.  I'm not sure
> what to do about that except skip those tests when pretty-printing.
> Is there something we can stuff in that field that won't confuse it
> too much?

We used dumpasn1 (http://www.cs.auckland.ac.nz/~pgut001/dumpasn1.c) to
look at ASN.1 structure.  Maybe there is something in that code that
would help the pretty-printer?

> Could someone more knowledgeable than I about the ASN.1 encodings and
> the innards of PKINIT please take a look at this?  I can make my
> preliminary test cases available if it would help.
>
> Ken