We've started exercising the new feature in RHCS 7.2 which lets you specify a Kerberos principal name as a value for an issued certificate's subjectAlternativeName, as specified in the PKINIT RFC. (Prior to that, I'd been doing testing using principal names encoded the way Windows expects them, so I was looking forward to it.) So I handed the certificate to my parsing code, and (you guessed it) it didn't work. Grrr. Turns out I'd been using a different (and as it turns out, incorrect) decoding template than the one I was using to encode values as a sample. Luckily, fixing that was quick work.

Made some headway on semi-automating the process of generating certificates with the right values in them using OpenSSL. Need to make sure the keys and certificates can be bundled up into PKCS#12 bags, which p12util will like, before I can go much further down that road.

Lots more.

DH key agreement using the Oakley predefined groups is working now, and I think authorization data is being correctly encoded, too. That leaves error reporting and handling (in the protocol) and logging (for troubleshooting) before it's more or less feature-complete. Whee!

A mailing list thread exceeds its usefulness once it exceeds n messages. The actual value of n varies, but I'd ballpark n at around 20, adjusting up or down for the list's signal/noise ratio and the average dickishness of the frequent posters.

Directing people to mailing list archives as a strategy to cut down on the noise-level of a mailing list rarely works because, like the list itself, the archives are full of noise.

Fleshed out more of the CMS implementation today, so that it implements the required-by-the-spec 3DES content encryption in enveloped-data messages. And NSS's cmsutil even seems to like the output.

Some version of DH key agreement/delivery is now working, too. So far it doesn't use any of the predefined domain parameter groups, so its dog slow because the client has to generate new DH paramaters for every request, but it seems to work.

A couple of things that're going to make interop testing a pain is that I've been doing all of the development with the benefit of an RHCS installation to issue the certificates, and am making pretty full use of NSS's databases, which can be filled with certificates with different defined trust parameters for each one. But for real testing, I'm probably going to have to be able to consume the PEM-formatted keys and certificates which OpenSSL prefers.

Lots of them. More on why later.

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.

Give religious handout, obtained in Boston, to a religious zealot screaming at no one in particular, in Cambridge. Check.