Work continues on getting PKINIT support... working in time for the both the next upstream MIT Kerberos release, and the next RHEL release. At some point I must've read the plans the CITI folks had for their implementation, because the implementation I'd been working on followed their loadable-module plan as well.

Despite my poor handling of things, interested parties have been exceptionally cool and encouraging about it, and I'm looking forward to being more involved in the upstream process in the present and future.

The module-loading interface is still evolving as we figure out more about what we all need that chunk of code to do (I for one am still reading and re-reading specifications), which is about the best possible outcome I could've hoped for. The interface masks pretty much all of the details from libkrb5, which means that the calling application doesn't even know that PKINIT is being used, and in practice that turns out to be a mixed bag. On the upside, clients like pam_krb5 and krb5-auth-dialog should magically work, but the cost is that it's difficult to programmatically choose PKINIT over password-based authentiation and vice-versa. I don't really know how to solve that one without giving libkrb5 some internalized knowledge of which preauth mechanisms (by number) use public keys and which ones use passwords, and that's not exactly going to be future-proof.

The module itself is at a point where, when loaded by upstream SVN (or a backport), it can use NSS's database of certificates and PKCS#11 modules to interface with one or more smart cards, locate the certificate which corresponds to a Kerberos principal name, and use that certificate and its associated private key to get initial credentials from a Win2k3r2 KDC using whichever draft version of the spec is appropriate for this case.

Which is pretty sweet, but it has a sucky part. The sucky part is that the KDC's certificate usually doesn't include any Kerberos-specific information, so the client can't know that it should trust the KDC to issue credentials for the realm. Sure, it could match the DNSName subjectAltName value against the configured list of KDCs, but that's not something we can do yet. (Hmm, should see what people think of that.) Meantime you get to configure clients to trust KDCs based on the GUID values they carry in their certificates. Messy, but it works.

The module also aims to implement the published version of the protocol for both client and server, and hopefully that's what they speak when they talk to each other, though I haven't done any interop testing or analyzed network traffic to verify that yet. I'm going to have to sort out how to create the right certificates with the right data in them, and how to wrap them up into PKCS#12 messages for importing into NSS (or alternately, how to read PEM-formatted keys directly), before I can do proper interoperability testing with Heimdal's implementation.

Dear Lazyweb: when I wrap a SignedData message inside of an EnvelopedData message, am I supposed to wrap the SignedData inside of a ContentInfo first? It's kind of redundant. (For now, I'm trying to support KDCs which answer this question either way, because I can't tell.)

Short-term, one major problem is that while PKINIT specifies two ways to communicate the AS reply key to the client (sign it and then encrypt^Wenvelope it, or derive it on both the client and server using Diffie-Hellman-Merkle key agreement), only the first is currently supported. That's not really supposed to be done, because it amounts to using a key, which is designated to be used only for signing data, to encrypt some data. I've been spending part of this week on getting the basics of the DH key delivery method going, and hopefully will have that finished this week. The big items after that are fleshing out the CMS implementation (mainly adding new ciphers to EnvelopedData handling), generating authorization data, and generating and responding to e-data provided by the KDC. I'll worry about including OCSP responses in the KDC's responses later.

Interested parties should either check out the CVS bits from elvis.redhat.com, or check Raw Hide within the next week or two. I'm going to try to get a backport in there in anticipation of the upcoming upstream 1.6 release, so that I can try to get the module into Fedora Extras earlier during the FC7 development cycle.