ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] multiple keys under same selector+domain?

2006-04-11 16:06:08
Just to be clear, I am not asking about the syntax or structure of the 
selector.  I am asking about different keys under the same selector.  They are 
essentially orthogonal issues, unless I am missing something.

/Dave

--
bbiw.net

(via handheld)  

-----Original Message-----
From: Stephen Farrell <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
Date: Tue, 11 Apr 2006 22:35:08 
To:dcrocker(_at_)bbiw(_dot_)net
Cc:DKIM IETF WG <ietf-dkim(_at_)mipassoc(_dot_)org>
Subject: Re: [ietf-dkim] multiple keys under same selector+domain?



Dave Crocker wrote:
Folks,

I did a quick scan of -core and did not find this issue dealt with:

When moving to a new key for a domain, may the same selector be used, or 
is the signer required to use a different selector?

Stated differently:  Is it true that a given selector+domain DNS lookup 
name will produce at most one key, forever?

I think some folks believe that it might produce a different key, over 
time, and I'd like us to be clear about whether it can do that.

Well, this was sort-of discussed in Dallas in response to issue
#1230 (raised by me, roundly rejected by all:-) where there was a
strong consensus not to include additional structure in selectors on
the basis that any such guidance didn't belong in the base document.

So, from the point of view of base- I believe we have decided that
its 1:1 only. I guess that decision was incidental to handling the
dead issue, but I got a strong impression that this was what people
wanted. And I'd be very surprised if that consensus had changed.
And section 3.1 of base is pretty clear about this, even if it says
"should" and not "MUST".

That doesn't stop someone else coming up with whatever scheme they
like later on of course. And I suspect that no-one would notice
if someone reused a selector a decade down the road. If you changed
every week you might generate hassle (for yourself) since someone
may quite reasonably have cached the key beyond the TTL of the
record.

Anyway I bet that getting people to change their keys at all will
be the problem!

Stephen.

PS: Issue #1230: https://rt.psg.com/Ticket/Display.html?id=1230


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