On Sat, 17 May 2008 13:30:27 +1000 Daniel Black <[EMAIL PROTECTED]> wrote: >On Sat, 17 May 2008 12:31:37 am Mike Markley wrote: >> On Fri, May 16, 2008 at 07:42:14AM +1000, Daniel Black ><[EMAIL PROTECTED]> wrote: >> > i'm hoping people have picked this up however just fyi, dkim-genkey uses >> > openssl to generate DKIM keys (rsa). >> > >> > http://www.debian.org/security/2008/dsa-1571 >> > >> > http://www.ubuntu.com/usn/usn-612-1 >> >> Indeed, and thanks for the notice. Scott Kitterman (who maintains the >> Ubuntu package) mentioned this to me (as the Debian maintainer), and I'm >> working on an upload that will draw attention to this and urge >> recreation of any compromised keys found in the configuration. >> >> In the meantime, concerned Debian users certainly don't need to wait on >> me to recreate their keys :). >> >> Worth noting as well is the fact that this also applies to dk-milter's >> gentxt.csh (or to any keys generated for either with Debian's OpenSSL). > >Thanks Mark, > >Packaging questions for you are: >should /var/db/dkim/ be created as you've referred to it in >the /usr/share/doc/dkim-filter/examples/dkim-filter.conf.sample.gz > >README.Debian refers to gentxt.csh in the examples directory (which it isn't) >and dkim-genkey is included.
Mark and I had already discussed that issue. It used to be gentxt.csh. I believe he intends to address this in his next upload. >I've written the following which you (and anyone else) are free to edit >redistribute to http://wiki.debian.org/SSLkeys or >http://www.debian.org/security/key-rollover/ > >Dkim-filter uses RSA keys to generate digital signatures. > >It is recommended that you regenerate a new key on a new selector. > >Steps: > >1. using dkim-genkey or the instructions >(/usr/share/doc/dkim-filter/README.Debian) to generate a new key using a >unused sector name. > >mkdir -p /var/db/dkim/ >dkim-genkey -s {{selectorname}} -d {{mydomain.org}} -D /var/db/dkim > >2. Publish this new key in DNS. > >Public key dns record is listed in /var/db/dkim/{{selectorname}}.txt > >Add {{t=y;}} if you are still testing (refer to RCC 4871) > >3. edit /etc/dkim-filter.conf as follows >{{Selector}} set to the new selector name {{selectorname}} >{{KeyFile}} set to new RSA private key >filename /var/db/dkim/{{selectorname}}.private > >4. remove old key and restart dkim-filter > ># rm /var/db/dkim/{{oldselector}}.* ># /etc/init.d/dkim-filter restart > >5. After about 3 days to allow for email delivery delays >remove old selector from DNS > I think these instruction would be useful for standard key transitions, but I wonder if it is appropriate here. These keys should be considered compromised and so, unless the domain has a very restrictive ADSP policy, I think the selector should be pulled immediately. If you've got a very restrictive ADSP policy, then I'd drop the ADSP record, wait the TTL of the record, and then pull the selector. Signing with the new selector could start as soon as the key record is published . After 3-4 days the old ADSP may be restorem Scott K ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
