I'd set up my CI system to do this on every commit to
master, that is, after the release branch merges.
The first very straightforward reason for this is that the commit to
master gets tagged with the release, and you want the thing you ultimately publish to match exactly the version of the source code at the tag. While there shouldn't be any merge surprises if git flow is run perfectly, it's still better to publish the content of a tag and not the commit immediately before a merge.
The second reason is that it is a very simple rule that can be automated. If you do any amount of final testing on the release branch, you need to make a manual decision as to whether or not you can release or not; your CI system (probably) can't make that decision just based on the presence of a release branch. On the other hand, since every commit to
master is merging in a release (or hotfix) branch that you've fully validated, the commit itself is a signal that you're ready to release.