In short, it is entirely up to you.
Both options you mention are valid, just pick the one that fits your team best.
If you spend a fairly predictable amount of time performing maintenance work, then just reduce the amount of time available for the sprint so that you have more 'overhead'.
If you find the the time cannot be predicted, make it part of the sprint backlog.
For what it's worth, I use Kanban now
I no longer use fixed-sprints because when I started to use SCRUM I quickly found that it was not assisting me. I now use Kanban with a workflow that I developed myself; my reasons for this were three-fold:
- I found that organising work around use-cases tended to de-empahsise overall domain analysis and design (to the point of it not being part of the documented workflow at all).
- Organising around use-cases (as you identify) does not suit bug fixes, revisions to spec/scope, or other miscellaneous pieces of work.
- I find that I am better able to predict when I will have a particular feature ready rather than having an arbitrary sprint duration (usually two-weeks).
On my KanBan boards, my main work-items are functions rather than use-cases. These are defined by a domain-level analysis process that identifies use-cases, derives the functions from it and defines them as components.
I also have smaller work items that are linked back to their parent function, these are: Revisions (change in a function's scope), Defects (i.e. bugs or deviations from the stated function requirements), Oddities (minor changes that are not either of the others).
This gives me a good view of how much maintenance work I have to do in the next week or two and how much new development.