Re: [ietf-dkim] Proposal: Do the semantics first, then straw poll

I'm somewhat similar to you, Phill, as I can equally support keeping  
or removing x=. I think that x= is basically a Good Thing. On the  
other hand, removing it wouldn't be so bad, either. I voted to keep  
in the straw poll primarily because it seems that we can't *just*  
remove it, we have to remove it and then add in other stuff. That  
other stuff makes my head hurt.
I think that one underlying semantic issue we're dealing with is the  
desire some people have to turn this all into a huge Internet-wide  
finite state automaton, and that's neither a good idea nor possible.
x= is a good thing because many, many people will change their DKIM  
keys every time they change what mail server they're using. This key  
will have a years-long, if not decades-long life. Using x= lets them  
blow off bit rot in messages that they are "responsible" for. I also  
believe that it is a Good Thing that DKIM is not an archival  
signature system for many privacy-related reasons that are tangential  
to this discussion, and x= kinda sorta helps.
The issue, then, is what happens when I have my expiration being  
(e.g.) a month and I decide out of the blue to change keys. The  
answer is that some messages now won't verify, which means they are  
"suspicious" which interacts with SSP and other things to make it so  
that some message might be flagged, filed, rejected or whatever in  
ways that they would not have had I left the key there. This is  
merely reality. It's not a big deal. It can be described in BCP  
documents, HowTos, and so on.
Getting rid of x= is a good thing because getting rid of it doesn't  
change the squishiness, it just makes it more obvious. There are  
going to be some keys that will be around essentially forever, and  
some that will be somewhat ephemeral. (Ironically, the signatures you  
least care about -- like the ones coming from my personal domain --  
are going to be the ones most stable.) But when it comes down to  
brass tacks, some weird combination of SSP, BCP, receiver filtering/ 
delivery policy and so on is going to come into play, but *only*  
*when* *an* *abrupt* key change takes place. In the normal, running  
environment, it doesn't matter whether we have x= or not.
And this is why I both don't care whether we have it or not and think  
we should keep it. When push comes to shove, it's going to be the  
practices around edge situations that matter. x= has goodness, and  
the proposals to remove it have more hair and seem to be more complex  
than keeping it.
        Jon

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