There are a few standard approaches for this sort of thing.
The first, is to run all computers in lockstep. That is, no computer computes the physics for a frame until everyone has received the commands issued by all the other players during that frame. This may sound a little silly, but it's actually a pretty good system for games which are only being played on LANs. It keeps everyone in synch (assuming a deterministic game) without having to exchange a lot of data. Downside is that your frame rate is limited by network latency, which makes it pretty impractical for use on the Internet.
The second approach is the "ownership" approach, where every object is owned by just one game client. That client is responsible for updating the physics on that object, and all other clients receive information about the object's movements over the network. Locally, they'd either set the object into kinematic mode and explicitly move it around based upon dead-reckoned network data or else perform local physics and correct those physics calculations based upon the dead-reckoned network data. This can be complicated, especially if objects need to be able to change ownership between players mid-game, but it's the standard way to handle this for games played in a peer-to-peer network configuration (as opposed to having a single central server).
The third approach is to have an authoritative server. This is basically the same as the "ownership" approach above, except that the server owns everything, and each client is always either kinematically moving the objects, or moving them via physics and then correcting. Commands from clients get sent to the server, along with a timestamp of when that command was given. The server then retroactively applies those commands, as though they had arrived earlier. (This is complicated to do, and I'm not sure that Box2D will allow you to do it. If not, you can ignore this part)
If you're planning to have a server and to be playable across the internet, then this third approach is probably going to be the way to go. You'll definitely want to be looking up articles on dead reckoning and error correction in order to help hide the pops when updated data arrives from the server, but otherwise what you've laid out seems a pretty reasonable approach.
