What would you like to discuss about it? It's already required. On Wed, May 10, 2017 at 5:00 PM, Ben Wilson <[email protected]> wrote:
> One thing that hasn’t been discussed is the use of the OCSP no-check > extension. > > > > *Ben Wilson, JD, CISA, CISSP* > > VP Compliance > > +1 801 701 9678 <(801)%20701-9678> > > > > *From:* Ryan Sleevi [mailto:[email protected]] > *Sent:* Wednesday, May 10, 2017 2:58 PM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *Cc:* Ben Wilson <[email protected]> > > *Subject:* Re: [cabfpub] Profiling OCSP & CRLs > > > > I'm not trying to disagree here, but I'm trying to find out how we can > best specify reasonable expectations. > > > > That is, there's a lot - a *lot* - that can go wrong with 1 year OCSP > responders/CRLs. So if we're going to allow them, we need CAs to think > about the technical risks and make proactive suggestions on how best to > codify that. Because just a blanket "1 year responder" can go very wrong > > > > On Wed, May 10, 2017 at 4:40 PM, Ben Wilson via Public < > [email protected]> wrote: > > I agree that a one-year validity for OCSP Responders / CRLs is a > reasonable timeframe for off-line CAs. > > > > *Ben Wilson, JD, CISA, CISSP* > > VP Compliance > > +1 801 701 9678 <(801)%20701-9678> > > > > *From:* Public [mailto:[email protected]] *On Behalf Of *Doug > Beattie via Public > *Sent:* Wednesday, May 10, 2017 11:15 AM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *Cc:* Doug Beattie <[email protected]> > > > *Subject:* Re: [cabfpub] Profiling OCSP & CRLs > > > > There are CAs that are kept off-line other than roots, so perhaps the > requirement should apply to all “off-line” CAs, assuming we can come to > agreement on what that means. > > > > Doug > > > > > > *From:* Public [mailto:[email protected] > <[email protected]>] *On Behalf Of *Peter Bowen via Public > *Sent:* Wednesday, May 10, 2017 1:09 PM > *To:* CA/Browser Forum Public Discussion List <[email protected]> > *Cc:* Peter Bowen <[email protected]> > *Subject:* Re: [cabfpub] Profiling OCSP & CRLs > > > > 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]> 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]> > 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 . 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] > 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 > > >
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
