Ryan, This seems reasonable when you are dealing with an online CA. When you are dealing with a root CA, it is currently reasonable to only bring it online once a year to update the CRL, as that is the required frequency. For many offline CAs it is quite a production to use the HSM, so I think the maximum duration of delegated responder certificates signed by root CAs should be at least a year.
Thanks, Peter > On May 8, 2017, at 4:51 PM, Ryan Sleevi via Public <[email protected]> > wrote: > > 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? > > Or were you suggesting 30 as a SHOULD, 45 as a MUST, which in practice > means... well, 45? :) > > On Thu, Apr 27, 2017 at 12:57 PM, Curt Spann <[email protected] > <mailto:[email protected]>> wrote: > Hi Ryan, > > 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. > > Cheers, > Curt > >> On Apr 25, 2017, at 4:53 PM, Ryan Sleevi via Public <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi folks, >> >> 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. >> >> I've tried to capture a starting point for discussion at >> https://github.com/sleevi/cabforum-docs/pull/2/files?diff=split >> <https://github.com/sleevi/cabforum-docs/pull/2/files?diff=split> . I've >> tried to annotate the changes, and the reason for the changes, so that >> people can understand them, their goals, and the implications. >> >> 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 :) >> >> If people find this approach useful, I'd like to also reform the CRL profile >> in a similar fashion. >> >> 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. >> _______________________________________________ >> Public mailing list >> [email protected] <mailto:[email protected]> >> https://cabforum.org/mailman/listinfo/public >> <https://cabforum.org/mailman/listinfo/public> > > > _______________________________________________ > Public mailing list > [email protected] > https://cabforum.org/mailman/listinfo/public
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
