ietf-mailsig
[Top] [All Lists]

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

2005-08-09 20:13:46


I think it is worth back-tracking to understand why there are people,
including myself, looking to make DKIM more extensible.

A core problem with DKIM is that it combines several components
together when they can be separated, allowing for greater flexibility
and choices.  DKIM violates basic software design principles.

For example, computing a cryptographic hash of mail message data
(including canonicalization methods) in itself is a useful capability.
From a software design perspective, such functionality should be
encapsulated and not tied to any specific application (in this case,
DKIM).

  Side Note: A digest method for email messages does not have
  to mandate a specific header field representation of the digest.
  It can limit itself to the algorithm itself, and potential standard
  digest algorithmic identifiers for use in applications.

Creating a digital signature of message, and placing it in the message
header, is another component.  Again, this does not need to be tied
to a specific application, like DKIM.

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).

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.

--ewh

<Prev in Thread] Current Thread [Next in Thread>
  • Design approach to MASS (was Re: [ietf-dkim] On per-user-keying), Earl Hood <=