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: [email protected] [mailto:[email protected]] On Behalf Of Rolf E. Sonneveld Sent: Friday, January 07, 2011 3:48 PM To: [email protected] 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
