I see a rabbit hole here... So you're transitioning, so you sign twice (one with your old, one with your new) before you send to me.... and hey, I'm not the end point either, so I need to forward it along, but I'm also transitioning, so I sign both of yours, twice? I would kind of have to, wouldn't I? as I have no idea what downstream supports before I send to the next hop...
On Wed, Jan 25, 2017 at 1:39 PM, Brandon Long <[email protected]> wrote: > > > On Jan 24, 2017 3:51 PM, "John R Levine" <[email protected]> wrote: > > On Tue, 24 Jan 2017, Brandon Long wrote: > >> I'm not opposed to requiring support for different encryption algorithms, >> but we really need to clean up and understand exactly how we handle >> migration to a new algorithm, probably with a section in the draft >> specific >> to it with an example. >> > > Fortunately, we have experience migrating from SHA1 to SHA256 hashes with > DKIM. > > Basically, as soon as you have support for the new algorithm, you start > signing with both old and new. After a while (likely a year or more) you > try dropping the old signatures and see if your verification rates drop. > I'd think that DMARC reports would be useful here. Eventually the > verification rates are close enough that you stop using the old algorithm. > > > Sure, with dkim. With arc, it's a bit more complicated, we need to > understand exactly how to sign the chain if there are multiple AMS and AS > headers. We probably want text about what happens if only one verifies as > well, and whether a hop should continue signing both paths or just one. > > Brandon > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc > > -- PAUL ROCK Principal Software Engineer | AOL Mail P: 703-265-5734 | C: 703-980-8380 AIM: paulsrock 22070 Broderick Dr.| Dulles, VA | 20166-9305
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
