Subject: [ietf-dkim] New Issue: selectors and key rollover

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Mar 2006 09:52:50 +0000

Section 3.1 says that a new selector should (albeit lowerase
should) be used when keys are rolled. This seems a bit clunky
and may lead to selectors with counter-intuitive names. Why not
include a version number or key ID that'd allow this to be
done better? The version could be included as the last part of
the selector starting from zero, e.g. "alice.0" -> "alice.1" ->
"alice.2" etc.

That might also allow selectors to support >1 private key per
selector per domain - which will be useful for cases where >1
signing MTA exists and h/w crypto is used - some h/w crypto
devices might not support cloning the same private key over
multiple devices.

S.

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

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Mar 2006 15:45:25 +0000

> the selector starting from zero, e.g. "alice.0" -> "alice.1" ->

That can certainly be suggested as a strategy or best practice and can
be done now without changes to the specification.

In that light, is the issue just better word-smithing?

Mark.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 16 Mar 2006 16:00:58 +0000

> In that light, is the issue just better word-smithing?

Almost. I think some guidance, and maybe examples would be
good and probably sufficient. In which case this could be
dealt with a just another editorial nit. Or, we might want
to change the ABNF to specifically allow for a numeric
key Id/version that increments. I don't have a strong
opinion either way but wanted to ask the question.

S.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 09:22:53 -0800

> the selector starting from zero, e.g. "alice.0" -> "alice.1" ->

are you discussing threats or are you discussing design enhancements?

If the former, it sounds like the latter.  So, how is this relevant to a threat 
analysis?

If the latter, it is difficult to understand why it is better to add more 
mechanism, when the one you are concerned about is supposed to be an opaque 
string that its creator can formulate according to any template it wishes.

d/
-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html