<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite" style="color: #000000;">Message: 4
<br>
Date: Tue, 31 Jul 2018 20:19:38 +0530
<br>
From: Jayanth Othayoth <a class="moz-txt-link-rfc2396E"
href="mailto:ojayanth@gmail.com"><ojayanth@gmail.com></a>
<br>
To: <a class="moz-txt-link-abbreviated"
href="mailto:openbmc@lists.ozlabs.org">openbmc@lists.ozlabs.org</a>,
<a class="moz-txt-link-abbreviated"
href="mailto:bradleyb@fuzziesquirrel.com">bradleyb@fuzziesquirrel.com</a>,
<br>
    <a class="moz-txt-link-abbreviated"
href="mailto:ed.tanous@intel.com">ed.tanous@intel.com</a>
<br>
Subject: SSL Certificate management proposal.
<br>
Message-ID:
<br>
    <a class="moz-txt-link-rfc2396E"
href="mailto:CACkAXSrxyf819dQc+LEOfwahpcrK2QRH1AkXump-D9Ae+yaKBQ@mail.gmail.com"><CACkAXSrxyf819dQc+LEOfwahpcrK2QRH1AkXump-D9Ae+yaKBQ@mail.gmail.com></a>
<br>
Content-Type: text/plain; charset="utf-8"
<br>
<br>
This proposal provides a mechanism to replace the self signed
certificate
<br>
with CA signed certificate based on BMC generated CSR.
<br>
[...snip...]
<br>
<br>
How to update a signed certificate on the BMC ?
<br>
[...snip...]
<br>
<br>
In order to support the above workflow, the BMC shall provide the
following
<br>
REST APIs:
<br>
   [...snip...]
<br>
   - Upload digitally signed certificate.
<br>
   - Activate digitally signed certificates
<br>
   - Download digitally signed certificate
<br>
[...snip...]
<br>
<br>
Note: REST/D-bus details not included here.
<br>
</blockquote>
<br>
Straw-man proposal for SSL certificate REST APIs
<br>
<br>
URIs:
<br>
   <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>xyz/openbmc_project/certificates/ssl<span
class="moz-txt-tag">/</span></i>{index}
<br>
      Represents a SSL certificate
<br>
      Supports GET, PUT, POST, DELETE
<br>
      JSON { "certificate": "..." }
<br>
   /xyz/openbmc_project/certificates/ssl/active
<br>
      Represents which certificate is used by SSL
<br>
      Supports GET, PUT, DELETE
<br>
      JSON { "data": "/xyz/openbmc_project/certificates/ssl/1" }
<br>
      See the magic below.
<br>
<br>
Notes:
<br>
 - These represent a collection of SSL certificates and optionally
an active one.
<br>
 - The number of certificates can be zero or more.
<br>
 - The certificate numbering ({index}) must be stable across API
operations.
<br>
 - The implementation can impose a maximum limit (16 is plenty?).
<br>
 - Duplicate certificates are allowed and are not detected.
<br>
 - Expired certificates are allowed and are not detected.
<br>
 - Mal-formed certificates are detected? TODO
<br>
 - The certificates and active certificate info persists across
rebooting.
<br>
<br>
Magic for the active SSL certificate:
<br>
 - When SSL is started with no active certificate:
<br>
   + A certificate is created and used to sign itself.
<br>
   + The new certificate becomes the active certificate.
<br>
   + TODO: What if you already have the maximum number of
certificates allowed?
<br>
 - When you attempt to delete the active certificate:
<br>
   + This is allowed. TODO: Or maybe not allowed.
<br>
   + There will be no active certificate (see implementation note).
<br>
   + /xyz/openbmc_project/certificates/ssl/active is deleted.
<br>
   + The underlying certificate is not deleted.
<br>
 - When you PUT (replace) the active certificate:
<br>
   + This is allowed. TODO: Or maybe not allowed.
<br>
   + The newly put certificate becomes active (see implementation
note).
<br>
   + /xyz/openbmc_project/certificates/ssl/active does not change.
<br>
<br>
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.
<br>
<br>
Ideas to support future behaviors:
<br>
<br>
1. To support future certificate types, the ssl element was used.
Ideas:
<br>
   /xyz/openbmc_project/certificates/ssl
<br>
   /xyz/openbmc_project/certificates/host
<br>
   /xyz/openbmc_project/certificates/rootoftrust
<br>
<br>
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:
<br>
JSON:
<br>
   { "certificate": "...", "privatekey": "...", "expiration":
"DATE" }
<br>
URIs:
<br>
   /xyz/openbmc_project/certificates/ssl/1/certificate
<br>
   /xyz/openbmc_project/certificates/ssl/1/privatekey
<br>
   /xyz/openbmc_project/certificates/ssl/1/csr
<br>
The JSON approach seems way easier.
<br>
<br>
3. The URIs for certificate signing requests (CSR) could be:
<br>
   <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>xyz/openbmc_project/certificates/csr<span
class="moz-txt-tag">/</span></i>{index}
<br>
   /xyz/openbmc_project/certificates/ssl/csr
<br>
   <i class="moz-txt-slash"><span class="moz-txt-tag">/</span>xyz/openbmc_project/certificates/ssl/csr<span
class="moz-txt-tag">/</span></i>{index}
<br>
depending on how many CSRs you wanted to support. (But let's not
debate that now).
<br>
<br>
</body>
</html>