On Thu, May 11, 2017 at 2:28 PM, Tim Shirley <[email protected]> wrote:
> Ah yes, good point. Both the private key of the responder cert AND the > system used to generate the OCSP responses need to have comparable > protections/controls to the private key of the associated online CA AND the > system used to generate certificates from that CA. I believe if you > achieve that, then you’ve done all you can do there, especially since the > CA itself could be used to sign the responses directly if you’ve > compromised the system to that degree. > Yup. Exactly this - it's trying to find how to capture this in the BRs in a meaningful way :) > That being said, I don’t see any insurmountable issues with requiring 30 > day lifespans for online CA OCSP responders either. Since the CA is > online, renewal of its OCSP responders could be automated. The challenging > one is the offline CA case. I’m not particularly fond of pre-production > either, but didn’t have any better suggestions. I agree the pre-produced > responder certificates would have to be very carefully protected (ideally > offline) in that scenario to provide any meaningful security improvement. > But perhaps the mechanism of deploying those responders wouldn’t have to be > as much of a production as accessing the offline CA would be, since a > leaked responder would only be useful if there was also a > non-administrative need to revoke an online CA during (or prior to) the > responder’s validity period. That would enable the rotation to be > performed more frequently than would otherwise be practical. You’re still > going to want a hard limit on how far in advance you could pre-produce > them, but maybe that can be on the order of 6-12 months instead of having > to access your root CA keys every 3 weeks or so to meet a 30 day > requirement. > Yup. You've exactly hit on what the goal is - and now trying to figure out how to word the requirements to capture. I put 30 days as what I would like to see the _effective security goal_ as, and with the hope that if we can reasonably agree on that as the desirable goal, we can figure out how to design/require the system to achieve that, even if the functional validity is greater than :)
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
