SSL Certificate management - proposed REST APIs

[Joseph Reynolds]

> Message: 4
> Date: Tue, 31 Jul 2018 20:19:38 +0530
> From: Jayanth Othayoth <ojayanth at gmail.com>
> To: openbmc at lists.ozlabs.org, bradleyb at fuzziesquirrel.com,
> ed.tanous at intel.com
> Subject: SSL Certificate management proposal.
> Message-ID:
> <CACkAXSrxyf819dQc+LEOfwahpcrK2QRH1AkXump-D9Ae+yaKBQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> This proposal provides a mechanism to replace the self signed certificate
> with  CA signed certificate based on BMC generated CSR.
> [...snip...]
>
> How to update a signed certificate on the BMC ?
> [...snip...]
>
> In order to support the above workflow, the BMC shall provide the 
> following
> REST APIs:
>     [...snip...]
>     - Upload digitally signed certificate.
>     - Activate digitally signed certificates
>     - Download digitally signed certificate
> [...snip...]
>
> Note: REST/D-bus details not included here.

Straw-man proposal for SSL certificate REST APIs

URIs:
/xyz/openbmc_project/certificates/ssl/{index}
         Represents a SSL certificate
         Supports GET, PUT, POST, DELETE
         JSON { "certificate": "..." }
     /xyz/openbmc_project/certificates/ssl/active
         Represents which certificate is used by SSL
         Supports GET, PUT, DELETE
         JSON { "data": "/xyz/openbmc_project/certificates/ssl/1" }
         See the magic below.

Notes:
  - These represent a collection of SSL certificates and optionally an 
active one.
  - The number of certificates can be zero or more.
  - The certificate numbering ({index}) must be stable across API 
operations.
  - The implementation can impose a maximum limit (16 is plenty?).
  - Duplicate certificates are allowed and are not detected.
  - Expired certificates are allowed and are not detected.
  - Mal-formed certificates are detected? TODO
  - The certificates and active certificate info persists across rebooting.

Magic for the active SSL certificate:
  - When SSL is started with no active certificate:
     + A certificate is created and used to sign itself.
     + The new certificate becomes the active certificate.
     + TODO: What if you already have the maximum number of certificates 
allowed?
  - When you attempt to delete the active certificate:
     + This is allowed.  TODO: Or maybe not allowed.
     + There will be no active certificate (see implementation note).
     + /xyz/openbmc_project/certificates/ssl/active is deleted.
     + The underlying certificate is not deleted.
  - When you PUT (replace) the active certificate:
     + This is allowed.  TODO: Or maybe not allowed.
     + The newly put certificate becomes active (see implementation note).
     + /xyz/openbmc_project/certificates/ssl/active does not change.

Implementation note: When you change the active certificate while SSL is 
running, does the behavior of SSL change immediately, or only for new 
connections?  How does this work?  TODO.

Ideas to support future behaviors:

1. To support future certificate types, the ssl element was used. Ideas:
     /xyz/openbmc_project/certificates/ssl
     /xyz/openbmc_project/certificates/host
     /xyz/openbmc_project/certificates/rootoftrust

2. There are two options to articulate the content of each certificate 
(such as an associated private key or certificate signing request): JSON 
and URIs:
JSON:
     { "certificate": "...", "privatekey": "...", "expiration": "DATE" }
URIs:
     /xyz/openbmc_project/certificates/ssl/1/certificate
     /xyz/openbmc_project/certificates/ssl/1/privatekey
     /xyz/openbmc_project/certificates/ssl/1/csr
The JSON approach seems way easier.

3. The URIs for certificate signing requests (CSR) could be:
/xyz/openbmc_project/certificates/csr/{index}
     /xyz/openbmc_project/certificates/ssl/csr
/xyz/openbmc_project/certificates/ssl/csr/{index}
depending on how many CSRs you wanted to support.  (But let's not debate 
that now).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20180801/9bc7ab54/attachment.html>