<div dir="ltr">Great. That's exactly the sort of discussion I think we want to have. I know there's a few other CAs that have privately reached out, so you're not alone, and perhaps your (public) response here will help encourage them to comment :)<div><br></div><div>Granted, it's important to consider that if a CA is compromised, we have a way to deal with that - revocation. Delegated responder certificates don't have that. That's called out with <a href="https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1">https://tools.ietf.org/html/rfc6960#section-4.2.2.2.1</a> , with the issue that checking CRL DP for responder certificates is, for better or worse, defeating considerable value in OCSP to begin with.</div><div><br></div><div>This is where the 30 day window comes from - trying to understand how to effectively and reasonably mitigate the issue, since this is fundamental in any trust system (c.f. Kerberos for an alternative, non-WebPKI example for addressing this)</div><div><br></div><div>Similarly, figuring out how to objectively evaluate the security of those responders. Your HSM is great, but if, for example, your responder is live-signing requests (e.g. to support nonces), then the HSM itself doesn't add value to the security properties, since you could compromise the 'signing platform' to mint an arbitrary number of responses (e.g. thisUpdate/nextUpdate rolling windows). That may sound somewhat academic/extreme, but CAs already leverage this capability (in what I would argue is insecurely) to pre-generate blocks of OCSP "Good" responses for weeks at a time. That's also what this profile tries to address/correct.</div><div><br></div><div>To spin the discussion around a little - what were the factors that lead you to design your system like this? Does it apply to all of your responders, or just your responders-for-intermediates? If the profile only applied to responders-for-leaves(and-TCSCs), does that change your thoughts? What were the design factors you were trying to account for, so we can see either how to design them into the profile, or find an 'end goal' that might account/allow for these?<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 9, 2017 at 2:35 PM, Bruce Morton <span dir="ltr"><<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-8827316089136288724WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Would like to discuss OCSP Responder certificate validity.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">The BRs do not discuss how OCSP systems should be operated. It would appear that a short validity period would be to mitigate against a low security policy on
 the OCSP responder and keys.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">In our case, we manage the OCSP responder similar to an issuing CA. The responder is in a secure zone and the keys are protected on a FIPS 140-2 Level 3 HSM with
 M of N controls. Since the keys perform a function which the CA could perform, we treat the keys in the same manner as a CA. As such, if the OCSP key is compromised, then the CA is also compromised and CA certificate revocation would be required. In this case,
 I do not think that a 30 (or 45) day upper-bound validity is required. We currently use 3 years, but it could be argued that the validity period could be even longer.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">Thanks, Bruce.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span style="font-size:11pt;font-family:calibri,sans-serif">From:</span></b><span style="font-size:11pt;font-family:calibri,sans-serif"> Public [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@<wbr>cabforum.org</a>]
<b>On Behalf Of </b>Ryan Sleevi via Public<br>
<b>Sent:</b> Monday, May 8, 2017 7:52 PM<br>
<b>To:</b> Curt Spann <<a href="mailto:cspann@apple.com" target="_blank">cspann@apple.com</a>><br>
<b>Cc:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>>; CA/Browser Forum Public Discussion List <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br>
<b>Subject:</b> [EXTERNAL]Re: [cabfpub] Profiling OCSP & CRLs<u></u><u></u></span></p><div><div class="gmail-h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">I think 30 days is what we should target as the upper-bound, so would that be suggesting that we should target 15 days as a SHOULD with 30 as a MUST?<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Or were you suggesting 30 as a SHOULD, 45 as a MUST, which in practice means... well, 45? :)<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Thu, Apr 27, 2017 at 12:57 PM, Curt Spann <<a href="mailto:cspann@apple.com" target="_blank">cspann@apple.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal">Hi Ryan,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Regarding delegated OCSP responder certificate validity, if 30 days is a desired goal (or a similar timeframe), I would recommend 45 days to allow the renewal to occur every 30 days, with a 15 day buffer for operational issues. Basically,
 for whatever target validity period we should add some buffer time.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">Cheers,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Curt<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal">On Apr 25, 2017, at 4:53 PM, Ryan Sleevi via Public <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>> wrote:<u></u><u></u></p>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi folks,<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">In response to various investigations about OCSP performance, operation, and trying to figure out how we can move to a world of more ubiquitous OCSP stapling, one of the things that comes up is that OCSP responses are very much like the
 pre-BR wild-west of certificates.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">I've tried to capture a starting point for discussion at <a href="https://github.com/sleevi/cabforum-docs/pull/2/files?diff=split" target="_blank">https://github.com/sleevi/<wbr>cabforum-docs/pull/2/files?<wbr>diff=split</a> . I've tried to annotate
 the changes, and the reason for the changes, so that people can understand them, their goals, and the implications.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">While I'd like to get this to the point of a Ballot, it's not quite there yet. In particular, it doesn't state Effective Dates, because I want to get a sense of the challenges that each bit may pose :)<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">If people find this approach useful, I'd like to also reform the CRL profile in a similar fashion.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">There's also a lot of ways to express these requirements. I considered using a table approach, which I suspect some of our ETSI-audited CA members will be familiar with, and which I find useful, but I thought it best to keep the initial
 discussions simple and textual, and then we can make it pretty once we're happy with the substance.<u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal">______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><u></u><u></u></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div></div></div>
</div>

</blockquote></div><br></div></div></div>