I would say two use cases, one for each. A bit more bloated, but as I've dealt with changing specs that had details that weren't included "because it's obvious", I'm prefer over-communication rather than the alternative.
By defining it as two use cases, it cuts any ambiguety as to whether there are any more things hidden in the fine print, plus, i like a spec that practically states "These two, and only these two".
I hope that makes sense. I'm by far no authority on UML, but someone who's been on the receiving-end of them for ages.