All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael Richardson <mcr@sandelman.ca>
To: Richard Hanley <rhanley@google.com>
Cc: OpenBMC Maillist <openbmc@lists.ozlabs.org>
Subject: Re: Survey for Certificate Management Needs
Date: Mon, 04 May 2020 20:20:24 -0400	[thread overview]
Message-ID: <26047.1588638024@localhost> (raw)
In-Reply-To: <CAH1kD+bKnGtca3SzAyaSwz4pQHG9EMWJfKHLtGHXMh=_jOTCtw@mail.gmail.com>

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


Richard Hanley <rhanley@google.com> wrote:
    > I think that CRL becomes more of an issue when communication is
    > mutually authenticated.  If a client is given a certificate from the
    > CA, then there should be a way for that client's cert to be revoked on
    > a BMC.

Again, it's the CA that issues the CRL.
If you want to revoke authorization, then you need to do that.
I'm unware of client-certificate based authorization in bmcweb at this time.

If your authorization process if just "signed by CA foo"
(i.e. authentication), then you would have to rely on the CA to revoke the
certificate.

If your authorization process consists of a list of pinned EE certificates,
then you could delete/mark-inactive the broken certificate.

If you combine both methods, then in theory, you could have a "anything
signed by CA foo, unless it is on blacklist X".  But that's not a CRL, that's
a blacklist.

--
]               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:[~2020-05-05  0:20 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-04 18:04 Survey for Certificate Management Needs Richard Hanley
2020-05-04 21:21 ` Michael Richardson
2020-05-04 22:19   ` Richard Hanley
2020-05-05  0:20     ` Michael Richardson [this message]
2020-05-05  2:13       ` Richard Hanley

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=26047.1588638024@localhost \
    --to=mcr@sandelman.ca \
    --cc=openbmc@lists.ozlabs.org \
    --cc=rhanley@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.