Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit
2006-04-18 18:47:48
On Apr 18, 2006, at 5:36 PM, Stephen Farrell wrote:
Doug,
Your response is non-responsive :-(
Douglas Otis wrote:
On Apr 18, 2006, at 4:10 PM, Stephen Farrell wrote:
Douglas Otis wrote:
The duration of the signature should cover the "expected"
distribution of transit times for a message from the originator
to recipient.
Sure. Can you get us the peer reviewed stats so we can remove
those quotes from "expected"?
I certainly don't have 'em, and in the absence of such real,
agreed-upon information I think we're just wasting time speculating.
Section 5.2 in the base draft makes an _unsupported_ speculation
about adequate key availability. The transit period should extend
beyond norms for SMTP, as indicated in other places within the
this Base and the Threat draft, when describing MUA signing and
verification.
So you have no data to offer.
When talking about transports, such as those related to the MUA,
transit times include SMTP delivery plus delays created by the
typical vacation/convention/civic duties, etc.
If 7 days provides for the SMTP transport, and people in Sweden and
France want to verify messages following their 5 week vacation, then
this would require a minimum of 42 days of key availability. The
suggestion for 45 days provided an additional 3 days to assure
availability following such a vacation.
The table below outlines minimum paid vacation mandates for full time
workers:
Country Vacation Time
Argentina 14 calendar days
Australia No national law, but 4 weeks is standard
Belgium 20 days, premium pay
Bulgaria 20 business days
Canada At least 2 weeks, determined by provincial law
Chile 15 working days
Czech Republic 4 weeks
France 5 weeks
Germany 4 weeks
Hong Kong 7 days
Hungary 20 work days
Ireland 4 weeks
Israel 14 days
Italy Mandated vacation, length determined by employment
contract
Japan 10 days paid time off (includes other leave time)
Mexico 6 days
Poland 18 working days
Puerto Rico 15 days
Saudi Arabia 15 days
Singapore 7 days
South Africa 21 consecutive days
South Korea 10 working days
Spain 30 calendar days
Sweden 5 weeks
Taiwan 7 days
The Netherlands 4 weeks
Turkey 12 work days
UK No national law, implementing EC directive (4 weeks
annual leave)
Ukraine 24 calendar days
US No national requirement. Some public employee
requirements.
Venezuela 15 paid days
Source: Keller, William L., Timothy J. Darby, and American Bar
Association.
International Labor Law Committee.
International Labor and Employment Laws. 2 vols. Washington, D.C.:
Bureau of National Affairs, 1997, 2002 Supplements
http://www.ilr.cornell.edu/library/research/QuestionOfTheMonth/
archive/vacationtime.html
Concerns regarding how long a key should remain available depends
upon what transport is being protected by the signature/key
mechanism. The desire was to focus upon determining the transports,
rather than offering conservative estimates for what the transports
may require when accessed directly by the recipient. Too short a
period unfortunately removes protection from some of these transports.
There are recent mails talking about "months later", those
discussions are not, IMO, in scope and are significantly
distracting.
Deciding whether other transports beyond SMTP might expect
protection by DKIM message verification could be productive
without too much distraction.
DKIM is to be used for:
1) SMTP only
Starting at the MSA and ending at the MDA mailbox.
2) SMTP + other transports
Starting at the originator and ending when first viewed by the
recipient.
So we agree that "months later" is irrelevant. Good.
What is relevant is the transport being protected. Each transport
demands a different duration of key availability, even though in most
cases, the key will be used within a few days.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Re: [ietf-dkim] authentication result headers are an unsafe alternative, (continued)
- Re: [ietf-dkim] authentication result headers are an unsafe alternative, Scott Kitterman
- Re: [ietf-dkim] authentication result headers are an unsafe alternative, Douglas Otis
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Scott Kitterman
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Stephen Farrell
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Douglas Otis
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Stephen Farrell
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Douglas Otis
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Stephen Farrell
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Douglas Otis
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Stephen Farrell
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit,
Douglas Otis <=
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Stephen Farrell
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Lyndon Nerenberg
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Stephen Farrell
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Lyndon Nerenberg
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Stephen Farrell
- [ietf-dkim] Collecting SMTP delivery data., Lyndon Nerenberg
- Re: [ietf-dkim] Collecting SMTP delivery data., Hector Santos
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Douglas Otis
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Stephen Farrell
- Re: [ietf-dkim] DKIM in the MUA should not be the goal, just a side benifit, Douglas Otis
|
|
|