Redfish: Generating and installing CSR based certificates.

[Ratan Gupta]

Hi Jayanth,

On 15/02/19 10:52 AM, Jayanth Othayoth wrote:
>
>
> On Fri, Feb 15, 2019 at 9:54 AM Ratan Gupta 
> <ratagupt at linux.vnet.ibm.com <mailto:ratagupt at linux.vnet.ibm.com>> wrote:
>
>     Hi Jayanth,
>
>     I have some querys
>
>     On 14/02/19 7:23 PM, Jayanth Othayoth wrote:
>>     All,
>>     Please find the Redflish based CSR ( Certificate Signing Request)
>>     generation and installing the certificate in BMC.
>>     This is based on the latest Redfish spec (Reference:
>>     https://www.dmtf.org/sites/default/files/Redfish_2018_Release_3_Overview.pdf)
>>     and related documents.
>>     Included the Gerrit link related to  d-bus interfaces :
>>         Review Link:
>>     https://gerrit.openbmc-project.xyz/#/c/openbmc/phosphor-dbus-interfaces/+/16571/
>>
>>     Looking for the inputs  on this  design flow and any additional
>>     changes required from the security aspect on managing private
>>     keys in the BMC.
>>
>>       * The user performs the GenerateCSR action ( URIs:
>>         /redfish/v1/CertificateService ) with required parameters.
>>           o Certificate service provides a d-bus interface to
>>             generate CSR .
>>               + Certificate manager create Private key and saves the
>>                 service specific path
>>               + Returns the d-bus path for the newly created CSR.
>>
>     I am hoping this design is wrt Redfish, which explains the flow to
>     deploy CSR based certificate.
>
>     I was little confused about d-bus interface terminology here, I
>     understand that in redfish we have certificate service schema
>     which has action
>
>     GenerateCSR, I am assuming we are talking about the same.
>
>     GenerateCSR should not return the d-bus Path however it should
>     return the URI of the Certificate Collection where the certificate
>     will be installed.
>
> @ratan Certificate manager design is services ( HTTPS Server, LDAP 
> client etc) . we don't need to get collection object based uri here 
> because BMC web is running from collection object context . The  d-bus 
> object uri  mentioned here , just used to watch CSR is ready and 
> return info to redfish user.
I didn't follow that "certificate manager design is services".

I don't understand why implementation doesn't need to get the collection 
based uri.

GenerateCSR returns the the URI of the Certificate Collection where the 
certificate will be installed.

So the response which you get from the GenerateCSR, that would be used 
to POST the next request which will create a certificate resource.

What do you mean by "BMC web is running from collection object context 
"? I don't follow it.

What info you would send as part of GenerateCSR request, for that we 
need to adhere with the standard, and the standard says that it would 
be  the CSR string and
the URI of the Certificate Collection wherethe certificate will be 
installed(as per the schema definition)

>
>     Does the GenerateCSR creates CSR resource which can be modifiable
>     in future?
>
>>           o  Certificate service provides d-bus interface to download CSR
>>               +  The user need need wait for the creation of CSR
>>                 specific d-bus path to download the newly created CSR
>>
>     Does the certificate service schema have the action Download CSR?
>
> -No ,  Redfish GenerateCSR methods expect CSR text as output.
>
>     I hope that response of GenerateCSR returns the CSR, There should
>     not be another redfish call to get the CSR.
>
> - Single call from Redfish point.
>
>>           o  The user takes the CSR file and get it signed by the
>>             appropriate authority.
>>               +  This step is outside the scope of Redfish.
>>       *  The user navigates to the appropriate certificate collection
>>           o   Example: if trying to replace the HTTPS certificate for
>>             a Manager, navigate to the Manager’s Certificate
>>             Collection that is subordinate to the
>>             NetworkProtocol/HTTPS object
>>       * The user performs a POST on the Certificate Collection with
>>         the certificate string in the body
>>           o  Use the existing certificate upload d-bus interface.
>>       * Certificate manager validates the certificate with the
>>         available service specific private keys in the BMC.
>>       * After successful validation  pairs the private key used in
>>         the first step with the installed certificate.
>>
>     Would the implementation persist the CSR and associated private
>     key for verification?
>
> - yes.
>
>     I can understand that we can do the verification of public/private
>     key through oprenssl function, but is there a possibility that
>     user can change the CSR request(eg change the organization)
>
>  Redfish doesn't support this now , Any real use case for this?

How you would validate the Certificate with the CSR(which is persisted 
on the BMC).

CSR have the subject and other info and the public key.If user changes 
the subject info but doesn't change the public key,Can we verify that?

>     and get it signed and upload the certificate, How the
>     implementation takes care of it?
>
>     Now suppose user creates three CSR request and on the BMC we have
>     three associated private keys and once user upload the certificate
>
>     would the implementation starts matching the certificate public
>     key with all the stored private keys and once it gets matched
>
>     then the implementation creates the pairing?
>
>     How the certificates would be deleted?
>
>
> redfish supports only certificate replace. no delete ,
> Planing to check with redfish community on this , this feature will be 
> useful for Authority type certificates.
>
>
>>     Assumption:
>>
>>       * For a service, BMC allows maximum 3 ( ?) CSR requests. Any
>>         new request after this will remove the oldest private key
>>         information from the BMC.
>>       * User has to do a Factory removing  the private key from the
>>         system.
>>
>     Regards
>
>     Ratan Gupta
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20190215/388dba45/attachment.htm>