Hi Rolf,
I think your concerns are reasonable. But I think the "marketing" of DKIM can
be managed and maintained as it has its own momentum now; meanwhile, the idea
of creating a new technology (say, something that protects HTTP transactions)
that looks 95% like DKIM but is called something else seems to me to be a path
that would introduce even more confusion to the industry.
The concept of building a toolkit as a basis, to which you add a few plugins to
get DKIM or a few different ones to get something similar for a different
medium, is quite appealing.
Thinking at strictly a marketing level, which is the thrust of your remarks,
would the answer to "What is DKIM?" and "What does DKIM do?" really change all
that much?
-MSK
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Rolf E.
Sonneveld
Sent: Friday, January 07, 2011 3:48 PM
To: dcrocker(_at_)bbiw(_dot_)net
Cc: DKIM Mailing List
Subject: Re: [ietf-dkim] Proposed documentation split between DKIM and "DOSETA"
Dave,
On 1/7/11 9:58 PM, Dave CROCKER wrote:
Folks,
Here's the proposal that Barry just announced, for splitting the DKIM
specification into a DKIM-specific portion and an underlying, more generic
portion that could be re-purposed for other services. It's current working
acronym is DOSETA.
Note that when combined the two documents would produce a DKIM protocol that is
over-the-wire identical with the current DKIM[1]. In other words, this exercise
does not change the DKIM protocol at all. It merely re-apportions the
documentation for expanded use...
d/
[1] I should acknowledge that things are moved around massively, and that this
effort uncovered some hiccups in the existing DKIM document which are now fixed.
But again, no protocol changes.
First of all I would like to express my serious concerns about two things:
1. it has taken some four years to make DKIM what it is now. And with that, I
don't mean the protocol specification itself, but I mean adoption, deployment,
acceptance of DKIM, the level of knowledge about DKIM within organizations,
reputation of the spec. etc. Although the adoption rate may seam slow, over
time we see real progress in the percentage of DKIM signed messages. Today
someone forwarded me the following announcement of Google:
http://googleappsupdates.blogspot.com/2011/01/email-authentication-using-dkim-now.html
. My concern is that, after all these years, now redefining what DKIM is, will
certainly not help acceptance and deployment growth. It may work
counterproductive and it may make organizations afraid of investing in such a
changing technology, even if the changes are much smaller then they seem to be.
Technology is one thing, Public Relations is something completely different.
2. although I understand the reason why you would like to redefine DKIM and
make a distinction between the core elements (DOSETA) and the mail-specific
implementation of these elements (DKIM), in my view it's too late to make this
split. Splitting up these things will cause a lot of confusion with the public
(CEO's that need to decide whether to invest in something like DKIM). Let us be
realistic: today many people don't exactly understand what DKIM does; the
discussions about DKIM on this ietf-dkim list illustrate this very well (see
threads like 'What DKIM provides, again' and 'The usual misunderstanding about
what DKIM promises' etc. etc.). Even on this list there is no consensus about
what DKIM really is. Splitting up DKIM now will mean even less people
understand what we're doing here and what DKIM really is.
So to summarize: from a technology point of view it may be a good idea to make
this split, from a DKIM acceptance point of view this will turn into a
deception.
Proposal for reapportion rfc4871bis (that is, DKIM)
---------------------------------------------------
Abstract
DomainKeys Identified Mail (DKIM) permits a person, role, or organization
that owns the signing domain to claim some responsibility for a message by
associating the domain with the message. This can be an author's organization,
an operational relay or one of their agents. DKIM separates the question of the
identity of the signer of the message from the purported author of the message.
Assertion of responsibility is validated through a cryptographic signature and
querying the signer's domain directly to retrieve the appropriate public key.
Message transit from author to recipient is through relays that typically make
no substantive change to a message or its content and thus preserve the DKIM
signature.
Table of Contents
1. Introduction
1.1 Signing Identity
1.2 Terminology and Definitions
2. Signing and Verification Protocol
3. Extensions to DOSETA Template
3.1 Signature Data Structure
3.2 Relationship between SDID and AUID
3.3 Stored Key Data
4. Considerations
4.1 Security Considerations
4.2 IANA Considerations
5. References
5.1 Normative References
5.2 Informative References
A. MUA Considerations
B. End-to-End Scenario Example
B.1 The User Composes an Email
B.2 The Email is Signed
B.3 The Email Signature is Verified
C. Types of Use
C.1 Alternate Submission Scenarios
C.2 Alternate Delivery Scenarios
Proposal for specification of re-usable components
--------------------------------------------------
(The working acronym is DOSETA, for DOmain SEcurity TAgging.)
Abstract
DomainKeys Security Tagging (DOSETA) is a component mechanism that enables
development of a security-related service, such as authentication or encryption,
with keys based on domain names; the name owner can be any actor involved in the
handling of the data, such as the author's organization, a server operator or
one of their agents. The DOSETA Library provides a collection of common
capabilities, including canonicalization, parameter tagging, and retrieval of
self-certified keys. The DOSETA Signing Template affixes a signature to data
that is in a "header/content" form. Defining the meaning of the signature is the
responsibility of the service that incorporates DOSETA. The signature is
validated through a cryptographic signature and querying the signer's domain
directly, to retrieve the appropriate public key.
Table of Contents
1. Introduction
1.1 DOSETA Features
1.2 DOSETA Architecture
2. Terminology and Definitions
2.1 Identity
2.2 Actors
2.3 Syntax
3. DOSETA Library
3.1 Canonicalization
3.2 Tag=Value Parameters
3.3 Key Management
3.4 Selectors for Keys
3.5 DNS Binding for Key Retrieval
3.6 Stored Key Data
4. DOSETA Header/Content Signing Template
4.1 Cryptographic Algorithms
4.2 Signature Data Structure
4.3 Signature Calculation
4.4 Signer Actions
4.5 Verifier Actions
4.6 Requirements for Tailoring the Signing Service
4.7 Signing by Parent Domains
5. Semantics of Multiple Signatures
5.1 Example Scenarios
5.2 Interpretation
6. Considerations
6.1 IANA Considerations
6.2 Security Considerations
7. References
7.1 Normative References
7.2 Informative References
A. Creating a Public Key
Regarding the draft ToC's you sent I have one question: the current chapters 5
(Signer Actions) and 6 (Verifier Actions) of RFC4871 seem to show up in the ToC
of the "DOSETA" document. The current chapter 5 of 4871bis however describes
how e-mail messages are to be signed and as such 'Signer Actions' for DKIM
should show up in the ToC of RFC4871bis and the same is true for Verifier
Actions. But maybe you take chapters 5 and 6 of 4871bis and put them in chapter
2 of the new DKIM?
For the discussion it would help if you would describe for each paragraph of
the current RFC4871bis draft, where that paragraph would fit in the new
documents, either in DKIM or DOSETA or (some parts) in both.
Regards,
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html