<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 4, 2020 at 5:20 PM Michael Richardson <<a href="mailto:mcr@sandelman.ca">mcr@sandelman.ca</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Richard Hanley <<a href="mailto:rhanley@google.com" target="_blank">rhanley@google.com</a>> wrote:<br>
    > I think that CRL becomes more of an issue when communication is<br>
    > mutually authenticated.  If a client is given a certificate from the<br>
    > CA, then there should be a way for that client's cert to be revoked on<br>
    > a BMC.<br>
<br>
Again, it's the CA that issues the CRL.<br>
If you want to revoke authorization, then you need to do that.<br>
I'm unware of client-certificate based authorization in bmcweb at this time.<br></blockquote><div><br></div><div>There is some support for it in bmcweb. Intel added it at the beginning of the year.  We've just started looking into it, so I don't have a great idea of what is and isn't implemented yet.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
If your authorization process if just "signed by CA foo"<br>
(i.e. authentication), then you would have to rely on the CA to revoke the<br>
certificate.<br>
<br>
If your authorization process consists of a list of pinned EE certificates,<br>
then you could delete/mark-inactive the broken certificate.<br>
<br>
If you combine both methods, then in theory, you could have a "anything<br>
signed by CA foo, unless it is on blacklist X".  But that's not a CRL, that's<br>
a blacklist.<br>
<br></blockquote><div><br></div><div>Perhaps I mispoke here, but let's imagine a situation where a machine is suspected to have been tampered with.  In that case the machine could be re-imaged and have the CA sign a new cert with the same username.  The CA would then need to deploy the CRL to any servers (BMCs in this case) that interacted with that user. In practice (for us at least), that CA doesn't really know what users are authorized where, so the CRL is widely distributed.</div><div><br></div><div>That's also one of the reasons I like RBAC, and other systems like it. They do a really good job at cleanly separating authorization and authentication. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
--<br>
]               Never tell me the odds!                 | ipv6 mesh networks [<br>
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [<br>
]     <a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a>  <a href="http://www.sandelman.ca/" rel="noreferrer" target="_blank">http://www.sandelman.ca/</a>        |   ruby on rails    [<br>
<br>
</blockquote></div></div>