[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany
Sent: Monday, February 26, 2007 12:30 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] Re: 1368 straw-poll :
Michael Thomas wrote:
been deprecated. To permit a graceful transition, both the
deprecated algorithm (whatever that might be) and some shiny new
algorithm must now be included with the message. Once
your verifier
adopts the shiny
[ Two valid signatures in the message ]
Wasn't this always the transition plan? The only crucial
point is that the Selector associated with the "weaker"
signature has to tell the verifier to expect the presence of
"stronger" signature.
Actually you would need to have the information in both records, otherwise I
can 'sign' a message with forged B in the expectation that you don't know how
to verify.
So the policy/key records become something like
_Policy.example.com TXT "DKIM"
K1._keys.example.com TXT "v=sijfhwiuhyfiuh a=rsasha1 also=k2._keys.example.com"
K2._keys.example.com TXT "v=weroiu23498y23 a=rsasha256
also=k1._keys.example.com"
OK that is indeed an additional way to do it.
The plus side is that it avoids the need to read the policy record at all.
The minus side is that you have more complexity in the key records and in
particular the key records are now expressing policy. It also means adding
features to the key record (not an issue for me but is for some).
At this point though we are discussing the requirement which simply addresses
the question of whether you need to be able to express the information at all
not where it is organized.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html