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
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html