[ietf-dkim] Characteristics for describing an SSP proposal

[Dave Crocker]

Folks,

I have been ruminating on the different kinds of confusion that some/many of 
us keep having with discussion about SSP proposals.  I keep trying to figure 
out what details should be included in a proposal, to make it possible for 
everyone to understand it adequately and evaluate it on the same terms.

So I propose we formulate a template for proposals.  A draft is below, but I 
encourage folks to suggest changes:



PROBLEM/BENEFIT

1.  In non-technical terms, what is the information that will be obtained by a 
message recipient, about a domain holder's practice?

     This is intended to describe the high-level information, not the 
low-level DNS query.


2.  Why should we believe that recipients will feel a strong need to obtain 
this information?



SYSTEM IMPACT

3.  Where does the recipient obtain the query domain name from?


4.  At what point in a recipient's message processing will the query be made?

     The Overview draft contains a diagram that describes DKIM processing, and 
provides a basis for citing what step the query will be made at (or before, or 
after.)  If the diagram is insufficient, please let me know what changes to it 
might help.


>                                          |
>                                          | - RFC2822 Message
>                                          V
>                      +---------------------------------------------+
>  +-----------+       |         ORIGINATING OR RELAYING ADMD        |
>  |           |       |         ============================        |
>  |  Signer   |       |                                             |
>  | Practices +......>|  SIGN MESSAGE                               |
>  |           |       |   ...> ADD A SIGNATURE HEADER FIELD         |
>  +-----+-----+ .....>|   .     GET (Domain, Selector, Priv-Key)    |
>        .       .     |   ...   COMPUTE SIGNATURE                   |
>        .       V     +----------------+----------------------------+
>        .   +-------+                     | - Message 
>        .   |       |                     |      1*(Domain, Selector,
>        .   |  Key  |                     |         Sig)
>        .   | Store |                 [Internet]
>        .   |       |                     |  
>        .   +---+---+                     V
>        .       .     +---------------------------------------------+
>        .       .     |          RELAYING OR DELIVERING ADMD        |
>        .       .     |          ===========================        |
>        .       .     |                                             |
>        .       .     |  VERIFY MESSAGE (Verifier Practices)        |
>        .       .     |   ...> VERIFY A SIGNATURE HEADER FIELD      |
>        .       .     |   .     GET A SIGNATURE                     |
>        .       .....>|   .     LOOKUP PUB-KEY (Domain, Selector)   |
>        .             |   .     VERIFY SIGNATURE VALUE              |
>        .             |   ...   EVALUATE SIGNATURE CONSTRAINTS      |
>        .             +-------------------+-------------------------+
>        .                                 |  - Verified Domain(s) 
>        .                                 V  - [Report]
>        .             +---------------------------------------------+
>        .             |                                             |
>        .             |   MESSAGE DISPOSITION                       |
>        .............>|       SIGNER PRACTICES                      |
>        .............>|       REPUTATION                            |
>        .             |                                             |
>  +-----+------+      +---------------------------------------------+
>  |            |
>  | Reputation |
>  |            |
>  +------------+



5. Is the query made for:

    a) All signed messages

    b) All unsigned messages

    c) Other (please describe the conditions)


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net