Design approach to MASS (was Re: [ietf-dkim] On per-user-keying)
eric+dkim at sendmail.org
Wed Aug 10 13:40:28 PDT 2005
--On August 9, 2005 10:04:39 PM -0500 Earl Hood <earl at earlhood.com>
> 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.
> 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?
More information about the ietf-dkim