Double mumble.
Jim,
Per the response to Levine's concern, I'd rather simply have text that dodges
the question of multiple signatures, here. Multiple sigs are fine, but the
figure is trying to look at a more contained topic. I believe that having the
figure explicitly show multiple sigs will, for example, require showing
multiple
private/public key pairs, and probably some sort of iterative behavior to cycle
through each key. Since this is an architectural diagram, rather than a
functional flow chart, I don't think the complexity of iteration is needed.
Can you live with that?
Here is the complete section:
<artwork name="DKIM Service Architecture"><![CDATA[
|
|- RFC2822 Message
V
+--------+ +--------------------------------+
| Private| | ORIGINATING OR RELAYING ADMD |
| Key +..>| Sign Message |
| Store | +---------------+----------------+
+--------+ |
(paired) |
+--------+ | +-----------+
| Public | | | Remote |
| Key | [Internet] | Sender |
| Store | | | Practices |
+----+---+ | +-----+-----+
. V .
. +--------------------------------+ .
. | RELAYING OR DELIVERING ADMD | .
. | Message Signed? | .
. +-----+----------------+---------+ .
. |yes |no .
. V | .
. +------------+ | .
+......>| Verify +-----+ | .
| Signatures | | | .
+-----+------+ | | .
pass| fail| | .
V | | .
+--------+ | | .
+........>| Assess | | | .
. | Signer | V V .
. +---+----+ +-------+ .
. | / Check \<............+
. +------->/ Signing \
. | / Practices \<..........+
. | +-------+-------+ .
. | | .
. | V .
+----+--------+ | +-----------+ +------+-----+
|Reputation/ | | | Message | | Local Info |
|Accreditation| +------->| Filtering | | on Sender |
|Info | | Engine | | Practices |
+-------------+ +-----------+ +------------+]]>
</artwork>
</figure>
<t>As shown in <xref target="DKIMSvc" />, basic message processing is
divided between a signing Administrative Management Domain (ADMD)
and a validating ADMD. At its simplest, this is between the
Originating ADMD and the delivering ADMD, but can involve other
ADMDs in the handling path. <list style="hanging">
<t hangText="Signing"> Signing is performed by an authorized
module within the signing ADMD and uses private information
from the Key Store. Within the originating ADMD, this might
be
performed by the MUA, MSA or an MTA.</t>
<t hangText="Validating"> Validating is performed by an
authorized module within the validating ADMD. Within a
delivering ADMD, validating might be performed by an MTA, MDA
or MUA. The module verifies the signature or determines
whether a signature was required. Verifying the signature
uses
public information from the Key Store. If the signature
passes, reputation information is used to asses the signer
and
that information is passed to the message filtering system.
If
the signature fails or there is no signature, information
about the related signing practices is retrieved remotely
and/or locally, and that information is passed to the message
filtering system. </t>
<t hangText="Note:"> By virtue of showing a single
private/public
key pairing, <xref target="DKIMSvc" /> can be taken to refer
to a single message signature. The figure is not intended to
comment upon single vs. multiple signature and merely shows
the sequential relationship between a signer and a validator
and their functional components. </t>
</list>
</t>
Jim Fenton wrote:
John Levine wrote:
At the end of section 5, just before the header 5.1 (page 15 of the txt
version) it says:
Note: Figure 1 does not show the effects on the message handling
when multiple signatures or non-author signatures are present.
By my reading, fig 1 covers all signatures, single, multiple, author,
or otherwise, e.g., in the figure it says Verify Signatures with
Signatures in the plural.
Suggested fix: delete the note.
I'm still having a little trouble with Figure 1. The box that says
"Verify Signatures" has a "pass" and "fail" output; does that mean "one
or more signatures pass", "all signatures pass", or what?
This might be addressed by following "verify signatures" with a decision
box that says "Valid signatures?" with outputs "none" and ">= 1". This
might even replace the "Message signed?" decision box.
I had been thinking it would be nice to have a decision box to see if
the valid signatures are author signatures for all authors, but I'm OK
if that is lumped into "Assess Signer" (which should really be "Assess
Signer(s)").
Also please note that Eric's comment on terminology in the Section 5
intro (with which I agree) applies to Figure 1 as well.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html