ietf-dkim
[Top] [All Lists]

RE: [ietf-dkim] Re: 1368 straw-poll :

2007-02-26 12:11:17

[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

<Prev in Thread] Current Thread [Next in Thread>