Re: Successful LDAP signing test

From: Mike Markley <mike_at_markley.org>
Date: Sat, 20 Feb 2010 01:39:52 -0800

On Fri, Feb 19, 2010 at 11:49:32PM -0800, Murray S. Kucherawy <msk_at_blackops.org> wrote:
> On Fri, 19 Feb 2010, Murray S. Kucherawy wrote:
> >So the next question is: Which of the things you tried is actually
> >easier for an LDAP administrator to do? I'm fine with supporting
> >DER-style keys for LDAP (and probably SQL and maybe Sleepycat) but we
> >also need to consider that flat files can't use anything with linefeeds,
> >so all-on-one-line keys will have to be supported as well.
> >
> >Maybe we need a "PrivateKeyFormat" parameter that tells it how to
> >interpret whatever it gets back from the KeyTable?
>
> Another issue is that the "secretkey" parameter to libopendkim's
> dkim_sign() function expects a PEM-formatted key (which wasn't documented,
> though I've now fixed that). Changing it to require DER-formatted keys
> might make upgrading a pain for a lot of people that just use the library.
>
> I suppose we could include a utility function for converting PEM to DER if
> we make that change, though there's a potential for user mistakes when
> adding that bit of complexity there.
>
> We might be able to have dkim_sign() auto-select PEM/DER based on whether
> or not the first five bytes are "-----", but I'm not sure how safe that
> is.

Another attribute wouldn't be the worst thing ever, but as an
implementer, it wouldn't be my preference.

To answer the first question: if an LDAP administrator is primarily
using LDIF files to load data, then either base64-encoded DER (with no
headers/footers/newlines) is probably easiest. Importing any binary data
or anything with linebreaks in it is going to require the administrator
to either put the contents into a separate file or to base64-encode
it themselves. Anyone using a reasonable UI might not care.

As for the rest:

OpenSSL, per its own docs, won't accept an RSA private key in PEM format
that doesn't begin with "-----BEGIN RSA PRIVATE KEY-----" and end with
"-----END RSA PRIVATE KEY-----". I think it's safe enough to assume PEM
in that case. Whether it's safe to assume DER otherwise is another
question. Having tested with keylengths from 512 to 2048, it seems that
every private key in base64 format begins with 'MII'.
I don't know ASN.1 well enough to know how safe it is to assume that's
always the case, but it seems consistent to me. So my thinking is:

If it begins with '----BEGIN RSA PRIVATE KEY-----': assume PEM.
If it begins with 'MII': base64 decode into DER (optional) - like p=
   format in a selector record
If it begins with 0x00008230: treat as DER

Or, alternately, just do step 1 and treat the rest as DER. I feel that,
at least, #1 is really safe: per my own testing, OpenSSL will just
flat-out error if it's expecting a PEM-encoded key and you pass it
something without the right header and footer. If it doesn't meet those
criteria, OpenSSL won't treat it as PEM regardless, and there's no point
in OpenDKIM treating it as such.

-- 
Mike Markley <mike_at_markley.org>
I could write an album about riding in a bus and puking after a show
somewhere, but that's what Bon Jovi's for.
- Trent Reznor
Received on Sat Feb 20 2010 - 09:40:04 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:32:52 PST