<div dir="ltr"><div>On Tue, Jul 31, 2018 at 11:21 PM Ed Tanous <<a href="mailto:ed.tanous@intel.com" target="_blank">ed.tanous@intel.com</a>> wrote:<br>
><br>
> On 07/31/2018 07:49 AM, Jayanth Othayoth wrote:<br>
> ><br>
> > The workflow for updating a signed certificate on the BMC consists of:<br>
> > 1. Generating a CSR on the BMC<br>
> > 2. Exporting the CSR from the BMC onto the user’s storage device<br>
> > 3. Obtaining a singed certificate corresponding to the CSR from a CA<br>
> > 4. Importing the signed certificate on the BMC<br>
> ><br>
><br>
> This workflow is somewhat of a non starter for a lot of organizations<br>
> and IT departments. First, it requires that every BMC have its own<br>
> private key, which isn't always desired.<br>
> Second, it means that you either have to be able to specify all<br>
> parameters that a user would want to specify about his key (number of<br>
> bits, EC vs RSA, ect).<br>
> Third, it requires that every BMC be provisioned by the intermediate<br>
> authority, which can be difficult if keys either have a cost associated<br>
> with them, or are difficult to acquire.<br>
><br><br>
> I would vote that we should start with the key and certificate upload<br>
> flows, as they are far simpler to implement, and better understood in<br>
> practice then try to go after the BMC CSR implementation if it's still<br>
> required.<br>
><br>Agree with your concern, but from the security standpoint transmitting
private key over network is not recommended. Additionally a simplified
method also can be provided for customers who wants that.<br>
> ><br>
> > Additional Requirements:<br>
> ><br>
> > * BMC should store the Signed certificate and private key in a<br>
> > persistent secured storage location..<br>
><br>
> What does this mean exactly? Encrypted disk backed by hardware<br>
> security? Is it just implying file system permissions?<br></div>Storage method can be varied based on the implementation. Curenlty looking at file system permissions.<br><div>
><br>
> > * Activate process shall validate the new certificate against the<br>
> > private key and information in the CSR.<br>
> You don't really define what the "activate process" is in this context.<br>
> I suspect you're talking about a process designed for cert upload, but<br>
> I'm not really sure given the context.<br>
><br>Upload process just save the Signed certificate in a BMC location and "activation" will replace the curently used certificate in the secured location and restart all the impacted services. <br>
> > * Successful certificate activation shall replace the existing<br>
> > certificate and private key.<br>
> > * A new CSR generate request will overwrite the previous CSR. User<br>
> > should take caution to not repeat CSR requests to prevent<br>
> > overwriting pending CSRs.<br>
><br>
> If you're going after a CSR flow, I don't think you can do this to a<br>
> user. Having a CSR immediately overwrite would mean that it invalidated<br>
> the old one, and you have a period of time where your BMC interfaces are<br>
> down while you request a new certificate from your intermediate authority.<br>
><br>As mentioned earlier curently used certificate will be replaced only after the successful activation. So there wont be any downtime during CSR creation process.<br>
> > * Certificate management operation should be restricted for certain<br>
> > privilege levels.<br>
><br>
> Which privilege levels? This requirement should be more specific.<br>
><br>User privilege level need to be discussed more.<br>
> > * As part of Boot process, a new self-signed certificate is generated if:<br>
> ><br>
> > * No CA signed certificate is present or corrupted.<br>
> > * A self-signed certificate is not present or corrupted.<br>
><br>
> Agree with these two, and I believe this is how all the web clients<br>
> currently work.<br>
><br>
> > * The certificate has expired.<br>
> Disagree with this one. If the certificate has expired AND it was a<br>
> self signed cert, it could be replaced, but it doesn't happen much in<br>
> practice, as self signed certs usually have a very long validity period<br>
> (10 years or more).<br>
> If a certificate that a user has uploaded expired, it should be left<br>
> expired until the user decides to replace it. We shouldn't be changing<br>
> keys and certificates seemingly randomly or automatically.<br>
> There's also a question of how you determine if a certificate is<br>
> "expired". There are no guarantees that the BMC clock is accurate at<br>
> all times, and the potential race conditions in supporting this outweigh<br>
> the benefit.<br></div><div><br></div><div>Agreed.<br></div><div>
> ><br>
> > * Validity of the certificate must be ensured by the user or client<br>
> > application by periodically checking the expiry date. Certificate<br>
> > management feature may be be enhanced in future to generate events<br>
> > when the certificate is about to expire.<br>
> ><br>
> > * Existing REST session will be tossed during certificate activate<br>
> > process.<br>
> I assume you mean restarted? I would word this requirement a little<br>
> differently.<br>
><br>
> * While the web services may restart to begin using the new certificate,<br>
> it shall not interrupt any update flows, and return codes returned by<br>
> all interfaces shall be correct.<br>
><br></div><div>Agreed.<br></div><div>
> ><br>
> ><br>
> > Note: REST/D-bus details not included here.</div></div>