Hallam-Baker, Phillip wrote:
We all agree on the transition strategy here.
The question is purely what the policy is capable of expressing. If the
transition strategy means that you are always going to sign twice once with a
key selector of each type then that is what the policy must be capable of
expressing.
So would a requirement that "the protocol must be capable of expressing
everything it implements" satisfy you?
Mike
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Arvel Hathcock
Sent: Wednesday, February 28, 2007 7:31 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Deployment Scenario 7: Cryptographic
Upgrade andDowngrade Attacks
Mike, this is what I was trying to say in a previous post.
You are exactly right. We have already faced this situation
and it has proven itself in the field to work just fine.
Arvel
Michael Thomas wrote:
I'm still not seeing what the problem is with things as
they stand now.
We've already been through a transition with sha1 and sha256. The
solution was to make both signatures in the transition and set the
h=sha1|sha256; in the selector. All you do when you're ready to
completely transition is only sign with the new algorithm and set
h=sha256; in the selector. This is exactly the kind of case
we wanted
to get right for -base and as far as I can tell it worked
exactly as
intended.
I'm honestly not trying to be obtuse here.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html