The way you're asking the question (and proposing two alternatives) it is as if the only concern is that the driverId is still valid at the time the car is created.
However, you must also be concerned that the driver associated with driverId isn't deleted before the car is either deleted or given another driver (and possibly also that the driver isn't assigned to another car (this if domain restricts a driver to only be associated with one car)).
I suggest that instead of validation, you allocate (which would include validation of presence). You will then disallow deletions while still allocated, thus guarding against the race condition of stale data during construction, as well as the other longer term problem. (Note that the allocation both validates and marks allocated, and operates atomically.)
Btw, I agree with @PriceJones that the association between the car and driver probably is a responsibility separate from either the car or the driver. This kind of association will only grow in complexity over time, because it sounds is like a scheduling problem (drivers, cars, time slots/windows, substitutes, etc...) Even if it more like a registration problem, one may want historical registrations as well as current registrations. Thus, it may very well merit its own BC outright.
You can provide an allocation scheme (such as a boolean or reference count) within the BC of the aggregate entities being allocated, or within a separate BC, say, the one responsible for making the association between car & driver. If you do the former you can allow (valid) deletion operations issued to the car or driver BC; if you do the latter, you will need to prevent deletions from the car & driver BC's and instead send them thru the car & driver association scheduler.
You might also split some of the allocation responsibilities between BC's as follows. The car & driver BC each provide an "allocation" scheme that validates and sets the allocated boolean with that BC; when their allocation boolean is set, the BC prevents deletion of the corresponding entities. (And the system is setup so that the car & driver BC only allow allocation and deallocation from the car/driver association scheduling BC.)
The car & driver scheduling BC then maintains a calendar of drivers associated with car for some time periods/durations, now and future, and notifies the other BC's of deallocation only on the last use of a scheduled car or driver.
As a more radical solution, you can treat the car & driver BC's as append-only historical-record factories, leaving ownership to the car/driver association scheduler. The car BC may generate a new car, complete with all the details of the car, along with its VIN. The ownership of the car is handled by the car/driver association scheduler. Even if a car/driver association is deleted, and the car itself is destroyed, the car's records still exist in the car BC by definition, and we can use the car BC to look up historical data; while car/driver associations/ownerships (past, present, and potentially future scheduled) are being handled by another BC.