Reading (For Dummies)

Firefox 2.0.0.3 and Non-Repudiation Certificates

Not a lot has been said about the 2.0.0.3 release of Firefox, and the most interesting/bad change that I've found isn't even documented in the release notes. From Firefox 2.0.0.0 on, Firefox stopped allowing users to sign client requests with non-repudiation certificates. At least, 2.0.0.{0,1,2} would not automatically use these certificates, and if you chose to automatically select a client cert, those versions would ignore any cert with the non-repudiation flag set. 2.0.0.3 revers to the pre-2.0 behavior of automatically choosing non-repudiation certs for signature requests.

This has been an interesting issue in the DoD, and hasn't even been well-understood by those users. I thought it would be worthwhile to write about it.

DoD has a PKI system set up that is quite well-documented. There are a number of certificate authorities that issue user certificates. The user certificates are loaded onto DoD issued smartcards (which run a proprietary applet called CAC). Every user gets three certificates: one encryption cert, and two signing certs. One signing is supposed to be used for signing documents and emails and the like, and other is supposed to be used for authentication. The former would usually be referred to as "non-repudiation", that is it is a strong and nonrevocable association between the user and thing signed. The reason to discern between signing and authentication is that authentication data for most protocols is often partially (sometimes wholly) generated by a remote system, and the signature verifies identity. Obviously if you sign something that was generated by someone else, the signature should not be strongly tied to your identity (especially if the server sent you something like ASCII like "dear boss, I hate your guts, love, reid").

DoD has been doing the Wrong Thing for a long time, though. Namely, they issue both signing certificates as "non-repudiation" -- there is no way to distinguish them. Technically, neither should be used for authentication. Using them for authentication is ambiguous -- it allows third parties to get a user to sign data that the third party generated, with a certificate labelled as being one that strongly identifies the signature with a user-generated data.

The most common signing operation by far for DoD folks is visiting websites. The troubling part here is that any SSL-enabled website can request a client signature. It's not really an attack (yet), but the server issuing the request contributes to the data that gets signed. In other words, if a hapless DoD user visits https://reallybackhackersite.com, and sends his/her signature, reallybackhackersite might be able to do evil things with the signature. More troubling is the fact that most PKCS#11 implementations cache a user's PIN (users find it annoying to type in their PIN often). Even without this badness, it would be fairly easy for a user to fall victim to a bad site.

Not a whole lot bad can be done with this right now. The future causes worry, though. Servers that still accept collisionable hashing algorithms for the signature (like md5 and sha1) are certainly at risk. Others may be as well...I'm still not 100% sure how the client signature gets generated (time time time). Certainly DoD should err on the side of paranoia -- there are lot of people interested in breaking defense systems. It puzzles me why Firefox chose to yield to DoD's wishes on this, but as a recent conversational buddy recently said, "You have to go with the market."