EDIT: I've revised my original answer, sorry. The basic 'protocol' remains the same, however, I've removed the need for private-public keys, and just use symmetric encryption. There was a fundamental flaw anyway in the key exchange in my original answer.

This is best answer I can come up with that I think is secure against one person purposefully delaying their choice.

Let me illustrate.

The Setup

1. Let's designate the participants Alice and Bob.
2. Alice and Bob also each encrypt two messages, one containing "True" and the other "False" using their respective keys; both messages are then sent to the other participant.
3. Alice receives both of Bob's messages, and doesn't know the contents of either. She chooses one message, encrypts in again it using her key, and sends it back to Bob.
4. Bob also chooses one of Alice's messages, encrypts that one, too, using his key, then sends that back to Alice.

Both participants now have two encrypted messages, each one either True or False, that can only be opened using their one or both of their respective keys.

Alice has one that came from Bob (encrypted using Bob's key), which she chose and sent back (encrypted using her key). She also has one she got back from Bob, originally encrypted using her key, then encrypted using Bob's key.

Bob has the reverse: one of True/False encrypted using Alice's key, and one of his own True/False messages back from Alice, also encrypted using Alice's key.

All they have to do now is exchange keys.

The resolution

Alice decrypts her choice (from Bob's first pair) using Bob's key to get True/False, and also decrypts the message she got back from Bob (also using Bob's key) to get one of her own True/False messages (still encrypted using her key, but can be easily identified).

Bob decrypts his choice (from Alice's original pair) using her key, and also decrypts the message he got back from Alice (again using her key) to find out Alice's choice.

Both participants now know what they 'chose', and can undisputably verify what the other one chose. They can each XOR both to get the final True/False (or Heads/Tails) result.

Security

It doesn't matter whether one participant 'waits' or delays before sending their key—the other participant already has an irrefutable copy of their 'ballot'.

The only purpose it would serve is to deny the other person the ability to verify the final result, which would easily be grounds to disqualify the whole coin-toss.

Even if Bob could magically create two keys that could somehow decrypt a True message into a False message (and False into True) so he can 'wait' to open Alice's choice before turning in his; it won't work with the encrypted True/False messages that originally came from Alice.

Note that constructing a key that'll decrypt a single ciphertext into a(ny) desired plaintext is possible—in fact, if you use the XOR cipher then it becomes trivial. With modern symmetric algorithms, however, the problem is largely intractable.

The problem with the dual e-mail is that if one participant waits then it's not exactly fair. There has to be a way to lock the information about both the call and the toss result in a vault such that both participants can unlock the vault at any given time without having to rely on the other. You might not have to do both; just lock one of either the call or the toss result, transmit the other, then the key to the vault should be sent, as well as proof that the vault has not been tampered before the other party's transmission.

Well let's think about what a real coin toss is like. You have two participants, and a trusted entropy-based random number generator i.e. the coin. Well, more-or-less trusted because both participants can see the result at the same time, and your trust your friend enough that he can't have absolute control over the coin on how it lands.

Now in a half-duplex communications channel, the general idea of synchronicity isn't there. So you have to throw out your idea of what a coin toss is. We can't have one person control the entropy of the system (i.e. perform the coin toss), since he cannot be trusted, but we can get the effect of a coin toss if both participants contribute to the entropy of the system.

Alice and Bob both have a random number generator. This could be a 20-sided dice, or a prng lookup table, or off the top of their heads. Alice and Bob create separate lists of say 10 random integers ranged from, say, 1 to 100.

Now to be fair, they agree first (through email) who will be heads and who will be tails. This does not require any special verification beyond their agreement.

Alice picks a number from 1 to 10 that will be an index into Bob's table, and Bob will pick a number from 1 to 10 that will be an index into Alice's table.

When both parties have received the others index, they exchange tables. Both parties now have both indexes and both tables and take the sum of the values at each index. They should now arrive the same number N.

From here, N mod 2 to get 0 = heads or 1 = tails.