Understanding dtb generation wrt uboot (with signing)

I'm working on 2.2/Morty, with a custom board.
Ultimate goal is to create a FIT image with a signed configuration. But I'm trying to just work through step by step and understand the relationships between u-boot, kernel, dtb, and the fit image - would appreciate any guidance!
So far, I've built and booted a fitImage.

It seems, however, that I need to program my modified dtb into the Flash (i.MX6 cpu) - if I program in the manufacturer's default then the kernel doesn't get my modified one. May be a problem for another time - I can program mine into Flash if need be.

First thing I'm puzzled by is that the dtb *is* in tmp/deploy/images/mymachine/ , but is called "zImage--4.4-r0-mymachine-20170727160613.dtb". Also with a symlink "zImage-mymachine.dtb". (If I'm understanding things right, this is because the fitImage contains a compressed kernel...?)

Then I set UBOOT_SIGN_ENABLE = "1", and re-bitbake the u-boot target. It only gets as far as re-building the kernel, which fails on the do_assemble_fitimage stage because uboot-mkimage is being told to use "u-boot.dtb"

So I'm unsure what setting(s) I need to tweak to pull things into line. Why 'zImage... .dtb' being built yet 'u-boot.dtb' being looked for?

...

After studying things in more depth, I've now grasped that the relationships with the uboot-sign class are, not circular, but a bit to-and-fro between kernel and u-boot. Please correct me if I've got any of this wrong:
The 'final' signed dtb, for use by U-Boot, consists of the U-Boot dtb (i.e. the traditional U-Boot hardware blob) plus the fitimage dtb tree;
The latter encompasses the kernel and the hardware blob from the *kernel*.
It seems a bit tortured to have two hardware device blobs involved in this, but I kinda get the issues of keeping sync between two (https://stackoverflow.com/questions/30711327/why-device-tree-structure-dts-file-is-needed-both-in-bootloader-and-kernel-sou).

The first complication I have is that my [manufacturer-dervied] U-Boot doesn't seem to compile a dtb - instead the manufacturer just uses the one built with the kernel. I don't mind this too much - I don't particularly need a separate dtb to be built within U-Boot, and its arguably easier to *not* have to maintain two sets of sources. However this does aggravate the uboot-sign'ing, since there's no .dtb for kernel-fitimage.bbclass to use ("Step #7").

Is there some means already hooked into the class(es) whereby I can easily have the kernel dtb used in 'Step #7' instead?
I thought I might be able to do this by setting UBOOT_DTB_IMAGE but it looks like the kernel's dtb hasn't yet, at this point in the build sequence, been installed into ${DEPLOYDIR}. Should I be aiming to make use of 'EXT_DTB'?

I'm not sure what you mean by fitImage dtb. Do you mean a dtb encapsulated in the fitImage for use by the kernel, the quasi-dtb that describes the fitImage components, or something else?

For U-Boot verified boot to work, U-Boot needs the public key that matches the private key used to sign the components in the fitImage. This public key must be stored independently of the fitImage otherwise anyone could just sign the fitImage with whatever key they want and then include the corresponding public key as well. Instead, the public key is stored in U-Boot's control dtb. For modern U-Boot targets, this dtb already exists to describe the hardware to U-Boot (see firefly or ast2500 targets) so storing the public keys there is just leveraging an existing data storage mechanism. This control dtb is baked into the U-Boot binary that gets flashed onto the target.

This gets a bit more complicated when you notice that fitImage components are signed individually. Each image (kernel, dtb, ramdisk) is signed separately as are configurations described in the fitImage. Further, each of those components can be signed with different and/or multiple keys. Maybe you use different keys for each product but use a single fitImage across them all. All of the public keys used need to be included in the U-Boot control dtb.

Yocto uses this process adapted from the U-Boot examples:
* build U-Boot with control dtb as provided in source
* generate unsigned FIT
* sign the FIT and update the control dtb with the public keys used
* rebuild U-Boot with the updated control dtb

If your target doesn't require a control dtb for boot, you can create a very simple one that just contains the empty key-related nodes.