[cabfpub] Profiling OCSP & CRLs

[Jeremy Rowley]

"Infrequently used" was a poor choice of words on my part.  We agree with you that OCSP stapling should and can be used for all certs (and didn't mean to imply otherwise).  Instead, I meant that most of these devices are not frequently connected to the Internet.  Some of them connect periodically, distributing out-of-date OCSP responses when OCSP stapling is used.  More than anything against OCSP stapling, I was thinking that it seems like a waste of resources to pre-sign OCSP responses for each device when the devices themselves only rarely call back to us for the a stapled response.  

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Monday, July 10, 2017 3:18 PM
To: Jeremy Rowley <jeremy.rowley at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Profiling OCSP & CRLs

I suppose one challenge I have with "infrequently used" is that it effectively states that CAs do not believe that OCSP Stapling should/can be used for all certificates. That is, I think one vision of the future would be to say all sites support OCSP stapling, and all (Web PKI) clients request OCSP stapling, because that gets us to a world where we have security by default (stapling as the default, not the exception, with hard fail on its absence or revocation).

So I think it may be necessary to start thinking about designs that move away from 'infrequently used' certs, and look to providing OCSP responses for all certs, and since ideally all servers will staple, to just pre-generate. I think you're right in that it most likely involves a move to FIPS 140-2 Level 2 hardware (at least, under today's available systems), so that we can get the necessary volume of signatures, but I think pre-generation may be something that CAs really need to start thinking about and planning for now, so we can figure out how to make this real in five years and finally have the revocation system everyone says they want.

Anyways, agreed, "future wish list" - and I think that's one of the things that may require folks to think more about and figure out what that vision looks like.

On Mon, Jul 10, 2017 at 5:08 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> More of "it would be nice" for OCSP responder certs.  Right now, we run all OCSP through our CA hardware.  Yes - your summary is exactly what I was thinking. We can roll responder certs pretty easily but the signing limit is often hardware-based. Moving to Level 2 hardware gives us more flexibility for large volume, infrequently used certs where OCSP pre-signing doesn't make sense.  Regardless, it's on a future wish list rather than something urgent.
>
> -----Original Message-----
> From: Ryan Sleevi [mailto:sleevi at google.com]
> Sent: Monday, July 10, 2017 3:01 PM
> To: Jeremy Rowley <jeremy.rowley at digicert.com>
> Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
> Subject: Re: [cabfpub] Profiling OCSP & CRLs
>
> I'm not sure - are you suggesting that the BRs (and/or NetSec
> guidelines) allow for that? Or is that more a "Would be nice"?
>
> For the incremental improvement of a normative profile, I'd rather keep the status quo - which I believe already requires the hardware key protection at Level 3 in Section 6.2.7 (but am curious to know if/how CAs have interpreted it otherwise, given the risks).
>
> That said, if we're talking about future system design, I think going to Level 2 does seem reasonable, but will be tricky to work out. As covered in past discussions, we'd still want to see the overall system treated as a High Security target - that is, it should have all the same design and protections around issuance. The preproduction requirement was meant to address this, but to address concerns from some CAs that have a large number of IOT certificates, they wanted to have online responders - which means issuance systems connected to the Internet, which means a much greater risk, HSM or not. I suspect we'd want to see a validity period of something like 14 days (twice that of the maximum permissible OCSP response) - is that what you were thinking?
>
>
> On Mon, Jul 10, 2017 at 4:47 PM, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
>> A shorter validity period for responders isn’t painful, but could we 
>> have a looser interpretation on hardware?  What if delegated 
>> responder certs were stored in FIPS 140-2 Level 2 if they were short periods?
>>
>>
>>
>> From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan 
>> Sleevi via Public
>> Sent: Monday, July 10, 2017 11:48 AM
>> To: public at cabforum.org
>> Subject: Re: [cabfpub] Profiling OCSP & CRLs
>>
>>
>>
>> Based on the public discussion, here on the list and on the GitHub, 
>> and the private discussions, both off-list and at the CA/Browser 
>> Forum F2F in Berlin, I've attempted to update the draft to reflect the discussions.
>>
>>
>>
>> To review the overall diff, with inline annotations, 
>> https://github.com/sleevi/cabforum-docs/pull/2/files
>>
>>
>>
>> To review the difference of those discussions, you can compare with
>> https://github.com/sleevi/cabforum-docs/compare/03d4055ef2a08ad4bdecf
>> 9 aab42440da080b244b...3171d339a9b5ca1e57b77c5175c6ea853f4cf24c
>>
>>
>>
>> Here's the summary form:
>>
>> - From the discussion related to a target of 30/31 days for Delegated 
>> OCSP Responders, it is clear that some CAs strongly prefer 
>> longer-lived responder certificates, largely due to the operational 
>> challenges involved with offline issuance scenarios. To balance that, 
>> based on the private discussions had with several CAs regarding their 
>> infrastructure, I've attempted to capture this in 4.9.1.2. In short, 
>> if a long-lived Delegated OCSP Responder is misused or compromised, 
>> the revocation status of all issued certificates is called into 
>> question, and since it's not possible to recover from this scenario 
>> (such as within 30 days), the only mitigation identified is to fully 
>> revoke the issuing CA certificate. This appears to be the standard 
>> assumption for several CAs practicing these long-lived responders, 
>> and hopefully aligns with their own operational security practices.
>>
>> - The response lifetime to a subordinate CA is dropped to 3 months 
>> (from the existing, implied one year), based on the suggestion of Doug Beattie.
>>
>> - To account for IOT scenarios raised by some members, the 
>> requirement to pre-produce OCSP responses has been relaxed. If you're 
>> using a Delegated OCSP Responder (which has a specific technical 
>> profile associated with it), and its validity period is less than 31 
>> days, CAs are exempt from the MUST requirement. I'm curious how folks 
>> would feel if this date was tightened further - perhaps to 15 days 
>> for the Responder - to best balance the risk of an Internet-facing 
>> signing system versus the benefit of not requiring a large number of 
>> responses. Personally, given the HSMs currently or pending 
>> availability, I still strongly believe that pre-producing and 
>> distributing responses across-the-board is the best security architecture, but I'm willing to see some of that phased in over time.
>>
>>
>>
>> From the discussion, there were some broader points discussed, and 
>> from some of the offline discussions, some rather surprising 
>> architecture disclosures, so I'm curious on how best to express the following:
>>
>>
>>
>> I had thought it clear that, under the current Baseline Requirements, 
>> all Delegated OCSP Responder Private Keys were subject to the same 
>> requirements as "CA Private Key" - that is, Sections 5.2, 6.1.1.1, 
>> and
>> 6.2 absolutely applied. Some CAs indicated that they did not share 
>> that interpretation - for example, that it was acceptable to deploy 
>> the CA private key directly to their CDN partners, or it was 
>> acceptable to maintain a copy of the private key on the disk of the 
>> OCSP responder system. I'm curious, more broadly, if the Forum 
>> members share that interpretation or have reason to believe it's a 
>> desirable property, and if not, where might be appropriate to best clarify this.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170711/1e68a7dd/attachment.p7s>