Derik,

I would have to go with Choice 1.  Generally, it would be my intent to prevent the Entities from becoming coupled with the DTOs.  I would think about having all of the DTO's interact through a service layer.  If the scenario was significantly complex I would also think about writing some sort of mapping code between DTOs and Entities that would remove the need to write a lot of manual value assignments.

Take it for what its worth :)

I'm with Rob. Think about separating the mapping of dto to business objects out into another class if these scenarios start to get more complex. I'll use something like:

new PersonDtoAssembler(person).AssembleDto();

I usually lean towards option 1 as well.  Yes, maintaining the mapping layer between DTOs and Entities can get tedious at times, but I think the separation of concerns you gain is usually worth it.  

If your DTOs do nothing more than mirror your domain objects, then that's probably a sign of a problem.  I usually create "screen-specific" DTOs which can vary quite a bit from my actual domain objects.  So a well maintained mapping layer is essential in this case.

And something I experimented with on my current project, was injecting "formatter" (aka, Strategy) classes into my mappers to encapsulate any special logic for calculated fields and changes in data representation.  This makes it super easy to change formatting logic (in a single place) either using decorators or by just changing the existing formatters.  It also makes sure your DTOs are truly "dumb" objects, if that's your goal.  

These little strategy classes can also be re-used if necessary, like an IDateOfBirthFormatter, which can be injected into any mappers that need to populate DTOs that show date of birth values on screens/reports.

As usual, there's always many solutions to the same problem, but for me, adhering to SRP and OCP principles as closely as possible allows me to keep systems much more maintainable and extensible.