Zhenfei Tai <ztai@google.com> wrote:
    > For our use case it's a more restricted environment in which we don't want
    > to have plaintext certificates in the request. Instead we want to send a
    > pair of encrypted key and certificate from the host to the BMC and there
    > will be another daemon to decrypt them using an internal library.

certificates are public objects.
Perhaps you are transfering a private key?
Is this an IDevID-like installed by the manufacturer, or is this a cert/key
to be used on the production floor (DC).

If you have a daemon present that can decrypt things, then you already have a
private key (or symmetric key) present, and that key is subject to attack.
(Unless you add yet another layer of indirection via TPM chip....)

I strongly recommend that you do not invent new technology here.
EST (RFC7030) is considered the best technology here, with SCEP (RFC8894)
being a legacy choice.

    > My questions are:
    > 1. Is this a reasonable approach?
    > 2. Shall we define an OEM schema for our request?

Finally, I am working on a BRSKI (RFC8995, aka
draft-ietf-anima-bootstrapping-keyinfra, not quite published, still in middle
of AUTH48) module for OpenBMC.   You may prefer help with that instead of
inventing something that hasn't gone through the same level of review.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [