[ietf-dkim] Deployment Scenario 7: Cryptographic Upgrade
andDowngrade Attacks
Hallam-Baker, Phillip
pbaker at verisign.com
Wed Feb 28 16:49:57 PST 2007
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.
> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Arvel Hathcock
> Sent: Wednesday, February 28, 2007 7:31 PM
> To: ietf-dkim at mipassoc.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
>
More information about the ietf-dkim
mailing list