[ietf-dkim] Proposed documentation split between DKIM and "DOSETA"

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.





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


-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html