ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Proposal for specifying syntax and semantics formultiple signatures

2006-04-01 17:55:45
Clarification on the STRONG policy:

o Neutral Signing Policy (SSP draft, o=~)
o Strong Signing Policy (SSP draft, o=-)

These two policies allow for additional signatures to be present.
So once again, in order to maintain the integrity and survival of
transports, the middleware must adhere to the domain signing policy.

In this case, for NEUTRAL, which says no signature is required,
a middleware now has the design options to offer:

    - Skip adding signature (passthru)
    - Optional, add 3rd party signature (3PS).
         - If adding, optional to remove original

However for the STRONG policy, the designs options are now:

    - Skip adding signature (passthru)
    - If Body Content will change, Add 3PS.

Much will depend if the middle ware is going to break the body content.

For the STRONG Policy....

However for the STRONG policy (Signature Required, 3PS optional),
consistency is established when the middleware designs options are now:

    - No Content Change Expected

         - Skip adding signature
         - Optionally Add 3PS

    - Content Change Expected - PROTOCOL VIOLATION SEE BELOW

         - (Optionally?) Remove Original
         - Must Add 3PS

The protocol violation begins when a policy requires an OA signature. So if
the content is broken, this will break the verification.

This is where SSP can be adjusted with additional policies, policy
attributes or provisions that offer guidance in the area of removing
signatures.

Also note the following real possibility:

A list manager is adamant about adding footers, even possibly change in
subject lines with list forum tags.  No one or software is going to dictate
this local list requirement.  However, he may desire to be support of DKIM
as well where it is possible.

This means that the LIST Server developers may offer design options to
control the subscription process to make the whole process easier.

For example:

   --- New DKIM List Server Options ---

    [X] Reject Subscription from Domain with the following
        Sender Signing Policies (SSP):

        [X] EXCLUSIVE
        [X] WEAK
        [X] NEVER (NO MAIL EXPECTED)
        [X] NO SIGNING (No current SSP available)
        [_] NEUTRAL
        [X} STRONG
        [X] USER

There is nothing in the world that prevents this from happening if its going
to make the whole DKIM issue easier to a) adopt, b) program and c) remove
liability and support responsibilities of the list owners.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>