canonical plans for ubuntu with secureBoot (16.04 onward)

1. I finally got a new laptop (dell inspiron 15 5000) with all this venerable uefi crypto enforcing.
2. Managed to install 16.04 beta alongside windows 10, with strict secure boot; virtualBox and fluendo restricted format ok
3. Installing 16.04 release, I follow the ubuntu community uefi page where it says to install in uefi mode if the other system is installed in UEFI mode, so I refuse to disable uefi secureboot to install restricted formats. Patience for mp3.
4. Now everything boots in uefi mode. This seems cool and I trust canonical paths to software security.
4. But now i cannot install Virtualbox either. The install program of virtualbox requires you to disable uefi secureboot.

(With all my incompetence I guess that starting with the 16.04 release Canonical extends the trust check from the firmware to the loader to the kernel up to to the kernel modules.
This seems well in line with the 'trust only what signed by canonical' approach, an approach I would like to follow.)

But now I am at a crossroad. Should I disable uefi to run my VirtualBox images or wait that canonical signs the dkms modules needed by it?
Will this ever happen or only the mantainer of the modules (presumably not canonical) can sign them?

I then wonder how can be deployed an LTS release that requires to disable secureboot to install important service functions.

Wouldn't it better to allow unsigned modules as it happened in the 16.04 betas?
If we cannot have the whole security chain in place now, a better temporary step would have been to let the user to choose which ring to break: the secureboot or the kernel module verification. That would allow better coexistence with 'other' os and would confine the untrusted code to smaller parts.

What are the next steps that ubuntu will take to get the important modules signed? Will that ever happen?
If not what was the purpose of embracing all the secureboot key signing in the first place?

Forgive me if I could not find other places where this issue is discussed. All the forums seems to suggest 'disable secureboot' as the obvious plain solution, which to my understanding is plain and obvious, but not a solution.