Currently it is able to use SecureBoot.ResetKeys or SecureBootDatabase.ResetKeys to Delete/Reset the secure boot key database. We have the request to install the certificate for secure boot. But the property "Certificates" in SecureBootDatabase is readonly and no action defined for certificate installation. Is there any concern to add this support?
Let me elaborate a bit more on the request. We want to enable the secure boot for a specific OS while its certificate is not in the secure boot db, so we have to install certificate by USB stick. Obviously it is not convenient for a bunch of servers. We are looking at the redfish to provide an interface to normalize this case. I'd appreciate your comments on this.
It's reasonable that the property "Certificates" in SecureBootDatabase is readonly since it's only a link links to the CertificateCollection. I think it's fine to create a certificate by POSTing to CertificateCollection with those requiredOnCreate described in Certificate_v1.xml like others creating a resource in a collection.
Thanks. The redfish interface is clarified. The question is back to the secure boot. Is it OK to install the certification for secure boot by POSTing to collection. Currently the uEFI either needs the physical presence to install the certificate without KEK verification or use KEK to verify the certificate while installing using uEFI API from OS. Any concern to install the certificate without KEK verification via Redfish interface? I think it should be OK in terms of security that uEFI fetches the certificate from BMC and installs the cerficate without KEK verification. It might be a UEFI question.
I think that will largely be dependent on the scope and capabilities of your implementation. I can see KEK verification could be done by the Redfish service, and when the user attempts to install the certificate, the POST request is rejected (likely a 400 Bad Request with messages indicating KEK verification failures). One other possibility is if the certificate needs to be actively consumed and verified by UEFI, the POST operation could result in a task, and the task doesn't finish until UEFI extracts the certificate from the BMC, verifies it, and responds to the BMC with the outcome of the sequence.
Thanks, Mike. What you described makes sense. Currently the server vendor has PK/KEK/DB/DBX preloaded in uEFI, but that's limited to the specific OS vendor like MSFT. Unfortunately there is no signing of preloaded KEK for our certificate but we need to install it and enable the secure boot. So far there is no consensus on the verification, It depends on the implementation. It could be your described implentation. The net is we want to install the certificate without KEK verification. How can we make it clear that no verification for the certificate installation? ... Add a new action with explicit parameter ...? Any idea?
If this is something you expect a user to control directly, it sounds like you'd need to use an OEM property that the client can provide when installing the certificate. If this is going to be a common use case for others, then we probably need to discuss this further internally.
However, I suspect quite a few users don't necessarily understand this type of control. You could simply accept the certificate as is at all times. There could also be logic internally to make decisions on whether or not to verify the certificate.
It is common use case in secure boot especially for the OS vendor. It is new to install secure boot certificate thru Redfish interface. I don't see any implementation for it so far. Correct me if my misunderstanding. It is good to discuss it further and clarity the expected behavior. I think it can ease the secure boot, for OS vendor in particular.