On Apr 18, 2006, at 1:03 PM, Scott Kitterman wrote:
On 04/18/2006 15:43, Douglas Otis wrote:
Or the primary goal of offering protection for all obtainable use
cases?
I guess we disagree about MUA level verification being obtainable.
I actually have some e-mail accounts I only check about once or
twice a year. If we design for the MSA-MTA-MDA case, it should
cover most typical MUA cases too.
When the design criteria handles the typical MUA use scenarios, it
would also meet the needs of the MSA/MDA verification case. Checking
email every 6 months does not represent the typical use of email.
In the MSA-MTA-MDA case we can place an upper bound on how long
from signing to delivery. With the MUA case, we could spend weeks
arguing over it to no point.
DKIM verification is still specified as taking place beyond the MDA.
MUA verification was the reason for excluding the envelope. The MUA
use case has already resulted in design considerations.
MUA level verification will never have the same level of
reliability as MTA/MDA verification for a variety of reasons, of
which this is only one, so lets not focus on it.
The MUA verifications should not have lower reliability due to poor
key availability recommendations. As this is forgoing perhaps
critical protections, there should be a reason offered besides
verification at the MUA may take longer. Add a statement that MUA
verifications may take longer than verification at the MDA.
5.2 Select a private-key and corresponding selector information
,---
| A signer SHOULD NOT sign with a key that is expected to expire within
| seven days; that is, when rotating to a new key, signing should
| immediately commence with the new key and the old key SHOULD be
| retained for at least seven days before being removed from the key
| server.
'__
Here the draft has completely discounted DKIM verification at the
MUA. : (
To ensure MUA verification remains practical and safe, the draft
should change key availability recommendations.
: A signer SHOULD NOT sign with a key that is expected to expire within
: 45 days; that is, when rotating to a new key, signing should
: immediately commence with the new key, and the old key SHOULD be
: retained for at least 45 days before being removed from the key
: server.
Adding the expiry within the key could still retain the shorter SMTP
acceptance constraint.
: A signer SHOULD NOT sign with a key that is expected to expire within
: 45 days; that is, when rotating to a new key, signing should
: immediately commence with the new key, and the old key SHOULD be
: retained for at least 45 days before being removed from the key
: server. The signer may add a retirement date that represents the
: time the key was no longer used for signing.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html