Re: Successful LDAP signing test

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Sat, 20 Feb 2010 08:37:53 -0800 (PST)

On Sat, 20 Feb 2010, Mike Markley wrote:
> 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.

So that's what I've done. dkim_sign() now checks to see whether or not
the provided "secretkey" paramter starts with "MII"; if it does, it will
pass the secretkey to the base64 decode function and store the output,
otherwise it makes a copy of the provided key directly. Then in
dkim_eom_sign(), there's a second check for "-----"; if it's there, the
PEM decode function is called on the stored key, otherwise the DER decode
function is called. That handles the PEM and base64-encoded DER forms;
passing in raw DER will be copied directly and passed to the PEM
functions, which will error out. (Passing in raw DER as a string, which
is what the API currently expects, is a tricky prospect to begin with.)

I also updated libopendkim/docs/dkim_sign.html accordingly.

To test this, I tried changing opendkim/tests/t-sign-rs-tables.keys so
that rather than referencing a file containing a PEM key, that file
actually contains the base64-encoded DER key just by stripping off the
begin/end tags and concatenating the lines of the key, including the
whitespaces "vi" inserts when you do line joins. The test still worked.
Then I reverted that file to its original form to test the PEM version,
and that still worked.

Let me know if it works for you. And thanks for all this feedback!
Received on Sat Feb 20 2010 - 16:38:12 PST