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

[Eric Allman]

--On August 9, 2005 10:04:39 PM -0500 Earl Hood <earl at earlhood.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