All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: Zhenfei Tai <ztai@google.com>
Cc: gmills@us.ibm.com, OpenBMC Maillist <openbmc@lists.ozlabs.org>,
	Justin Chen <juschen@google.com>, Ed Tanous <edtanous@google.com>,
	Richard Hanley <rhanley@google.com>
Subject: Re: bmcweb: Install encrypted certificate to BMC
Date: Sat, 17 Apr 2021 14:50:48 -0400	[thread overview]
Message-ID: <10871.1618685448@localhost> (raw)
In-Reply-To: <CAMXw96PmAoSb5LJj-CzYA-47D-nCy81gBa=T94N_u2fqWL54EQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1562 bytes --]


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    [



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

  reply	other threads:[~2021-04-17 18:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-17  0:23 bmcweb: Install encrypted certificate to BMC Zhenfei Tai
2021-04-17 18:50 ` Michael Richardson [this message]
2021-04-19  7:18   ` Ed Tanous
2021-04-23 13:26     ` Patrick Williams
2021-04-23 16:37       ` Ed Tanous

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10871.1618685448@localhost \
    --to=mcr@sandelman.ca \
    --cc=edtanous@google.com \
    --cc=gmills@us.ibm.com \
    --cc=juschen@google.com \
    --cc=openbmc@lists.ozlabs.org \
    --cc=rhanley@google.com \
    --cc=ztai@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.