Several years ago (5 to the week) I designed and implemented a PKI infrastructure for enrolling users, enabling them to send secure (i.e. encrypted) S/MIME messages. The nifty bits were that we have an off-site enrollment "agency" that create the private keys which are kept in a safe and a certification authority that does the actual signing. The enrollment agency and the authority transmit signing requests and signed (public) certificates to eachother via custom made XML messages. The whole thing is of course managed in LDAP.
All has been well, and both OpenSSL and the pile of code I wrote at the time, have been performing admirably. Just one thing was missing, and that was certificate renewal, which I postponed, because I knew I had plenty of time® to implement that.
Time flies…
Suddenly, the first announcement of expired certificates arrives. Damn. Ok, no problem: simply renew the certificate, right? OpenSSL forsees that, so I simply start re-issuing the certificates from the original Certificate Signing Requests, which we keep in store; that is easy.
No sir. Nothing doing.
Upon re-issuing a certificate, it gets a new serial number assigned and the combination of that plus the private key is not sufficient to access S/MIME messages encrypted to the old certificate pair. It took a bit to find, but I managed to create some code which does just that. Actually it is of course documented: if you look carefully at section 6.2 of RFC 3852 the fog lifts.
Remember: re-use the serial number, or you are in trouble. 
Care to hazard a guess as to what this sequence of numbers represents?
27.55, 33.45, 39.95, 47.95, 58.95
(more…)
ZDNet writes:
Anyone who actually wanted Vista already has it.
Who wants to get one of these as a holiday gift, anyway?
via.
The source code of the excellent Mulberry IMAP client has been released, and it includes a CalDAV client.
My whatmon extension or add-on for Mozilla's Firefox and Thunderbird has had a small update.
If you prefer to download it from the official Mozilla addons site you'll have to wait until it has been processed off the queue, but you can already get the current version chez moi.
Enjoy.
User-defined functions are compiled as shared object files and then added to and removed from the MySQL server dynamically.
I hacked up a small test to demonstrate their implementation, although I'll only show you the results here.
CREATE TABLE u ( username varchar(20) );
INSERT INTO u VALUES ('jpm');
SELECT * FROM u;
+----------+
| username |
+----------+
| jpm |
+----------+
So far, nothing special, but now for something completely different:
CREATE FUNCTION ldapcn RETURNS STRING SONAME 'libudf_jp2.so';
The CREATE FUNCTION loads the shared object file into the server's address space, where it remains available until the function is dropped from the data dictionary.
SELECT username, LDAPCN(username) AS cn FROM u;
+----------+---------------+
| username | cn |
+----------+---------------+
| jpm | Jan-Piet Mens |
+----------+---------------+
During the SELECT, MySQL invokes my UDF, passing it the string argument, and I go off and search for the user in an LDAP directory tree, returning the user's Common Name as the function's value. That in turn is the result of the function which MySQL uses.
Powerful.
More on MySQL UDF.
