Document shepherd writeup for draft-ietf-dcrup-dkim-crypto-09
1. Summary
The Document Shepherd for this document is Jim Fenton. The responsible Area
Director is Alexey Melnikov.
DKIM [RFC6376] signs e-mail messages, by creating hashes of the message headers
and body and signing the header hash with a digital signature. Message
recipients fetch the signature verification key from the DNS. The defining
documents specify a single signing algorithm, RSA [RFC3447].
This document adds a new stronger signing algorithm, Edwards-Curve Digital
Signature Algorithm using the Curve25519 curve (ed25519), which has much
shorter keys than RSA for similar levels of security. This is important in
overcoming the practical limitations in storing long keys in DNS.
Publication is being requested as a Proposed Standard ("Standards Track" in the
draft).
2. Review and Consensus
This document represents the consensus of the dcrup working group. The need for
longer DKIM signing keys has become more acute as compute power (and therefore
the ability to factor short RSA keys) increases. Initially, two approaches were
considered: (1) publication of key fingerprints (hashes), rather than RSA keys
in DNS; (2) use of the ed25519 signing algorithm, which has shorter keys for
equivalent cryptographic strength. Ultimately, approach (1) was discarded
because (2) was sufficient to satisfy the goals of the specification. There was
also significant dicussion on the format to be used for publishing ed25529
public keys in DNS; a "raw key" format was adopted (without ASN1/DER wrapping).
The specification has received extensive review from significant members of the
email community and input (such as algorithm selection) from WG technical
advisor Eric Rescorla.
Multiple interoperating implementations exist, including dkimpy-milter, exim,
NoSpamProxy, and OpenDKIM.
3. Intellectual property
One IPR disclosure (#3025) was filed regarding this draft, but this is no
longer applicable because the disclosure related to the use of RSA
fingerprints, which has been removed in an earlier revision.
No other IPR claims are known.
4. Other Points
This document contains a normative reference to RFC 8032, an informational RFC
that describes ed25519. This is consistent with current practice; RFC 8032 is
already listed on the Downref Registry because of a similar reference in RFC
8037.
This document also contains a normative reference to RFC 3447, which has been
obsoleted by RFC 8017.
All references are listed as normative; it is possible that there is at least
one informative reference (most likely the reference to RFC 3447).
There is also a reference to a NIST FIPS standard. While not an IETF document,
we consider it sufficiently stable to be normatively referenced in a
standards-track document.
Section 9.2 (URIs) and the Discussion Venue reference in the introduction
should be removed by the RFC editor at publication.
In the opinion of the shepherd, the document is ready for publication.