Hi, > Hmmm, I'm not sure I agree. One use case is that you want a domain > config in which well-known OS-es, signed by the MS UEFI certs, just boot > with SB enabled. (Some of our internal folks really want this.) > > Another use case is that you want a domain in which SB *can* be enabled, > but your installer is signed with a different certificate chain (or it > is unsigned), and with *just* the MS certs enrolled, it wouldn't boot at > all. So you want the SB *feature*, but definitely not the initial > enrollment / SB *operational mode*. So "secure-boot-enrolled-keys" also has SB turned on. > For me to understand you better, are you suggesting merely that I: > > - rename @secure-boot-enrolled-keys to @enrolled-keys, and > > - drop the reference to @secure-boot from the end of the @enrolled-keys > documentation paragraph? (Namely, "@secure-boot-enrolled-keys is only > valid if the firmware also supports @secure-boot"). Yes. So "secure-boot" specifies "firmware binary supports secure-boot" and "enrolled-keys" specifies "firmware nvram template has keys enrolled (and SB enabled). Other question: Do we want allow to specify which certs/keys are enrolled? Which would probably mean to drop "enrolled-keys" from features and make it an optional string instead, then specify "'enrolled-keys' : 'Microsoft'" in the json file. cheers, Gerd -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
