ietf-dkim
[Top] [All Lists]

Re: Design approach to MASS (was Re: [ietf-dkim] On per-user-keying)

2005-08-10 13:45:07


--On August 9, 2005 10:04:39 PM -0500 Earl Hood <earl(_at_)earlhood(_dot_)com> wrote:

DKIM should only define what makes DKIM, well, DKIM.  That is mainly
the DNS-based management of cryptographic keys and attributes that
are unique to the DKIM-method of signing.

This approach appears to make good sense from a design perspective
and it also allows mail signatures based upon XMKS and/or PKIX to be
defined (in the future) without having to re-define common reusable
components (and to hopefully reduce debates on the scope of DKIM and
its extensibility).

I think we have fundamental differences about what comprises DKIM. DKIM specifies both the method of creating signatures and the method for doing key lookups as parameters. The initial definition of these are rsa-sha1 and dns respectively, but they can and probably should be extended in the future. An implementation that used rsa-sha256 and http or pkix would still be DKIM.

IMO, this will not take much more time than lumping everything in
one spec.  If I were designing things, I would have at least the
following initial deliverables:

  1. Mail digest specification.
  2. Mail header-based digital signature specification.
  3. DNS-based key management and verification specification (i.e.
DKIM).

It may be the case that (1) and (2) are combined, but I do not think
it is required.

If anything, DKIM is 1+2. I agree that the binding for dns-based key management could be pulled out into another document. It seemed to me at the time that this wasn't necessary. For example, RFC2046 defines both the text MIME type and text/plain subtype; the failure to have them in separate documents hasn't prevented the addition of new text subtypes. But other than creating more work for authors and making it a bit harder for readers to find all the correct documents, I don't see any damage in it either.

Is the wording of the current draft insufficiently clear about the ability to extend these fields?

eric
_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim

<Prev in Thread] Current Thread [Next in Thread>