Re: Successful LDAP signing test

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Fri, 19 Feb 2010 11:53:34 -0800 (PST)

On Fri, 19 Feb 2010, Mike Markley wrote:
> I've now been able to send correctly-signed messages using LDAP KeyTable
> and SigningTable. I'll use the last couple of notes you sent, Murray, to
> flesh out the sample schema and do some doc work. Maybe even a quick
> LDAP how-to.

Terrific! Some of that text might be useful in improving the
opendkim.conf(5) man page if the KeyTable and SigningTable descriptions
are currently lacking.

There was a suggestion by someone from the OpenLDAP project to propose an
LDAP schema to the IETF for standardization. Are you interested in an
effort like that? It's far from urgent or mandatory, but might be
something of interest we could tackle especially if it will be of benefit
to the community.

For extra credit: Does the new opendkim-genzone tool work for the sample
key you put in LDAP?

> I now feel more strongly that we should support DER private keys in
> LDAP. Simply stripping out the headers and inserting the PEM data into
> the LDAP attribute resulted in a "dkim_eom(): resource unavailable:
> PEM_read_bio_PrivateKey() failed" error. I ended up having to
> base64-encode the PEM file (which is already base64-encoded) and specify
> in my LDIF file that the value was so encoded.
>
> This happens because of the line breaks in the PEM file: LDIF doesn't
> have a good way to handle newlines in an attribute value. That being the
> case, it's actually easier to get DER into the LDIF; PEM is just DER
> + base64 + header/footer, and LDIF natively supports specifying
> attribute values in base64, so all you have to do is:
> attributeName:: <PEM file with header, footer, and newlines stripped)

What mechanism would you suggest for indicating that the input keys are
DER-formatted? A fourth attribute in the query? A command-line flag?
Something else? I don't really want to assume DER if the installation is
using LDAP because, for example, it might be hard to do the same thing in
the Sleepycat DB and OpenDBX cases.
Received on Fri Feb 19 2010 - 19:53:53 PST