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