[cabfpub] Profiling OCSP & CRLs

[Ryan Sleevi]

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 <public at cabforum.org>
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:public-bounces at cabforum.org] *On Behalf Of *Doug
> Beattie via Public
> *Sent:* Wednesday, May 10, 2017 11:15 AM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Doug Beattie <doug.beattie at globalsign.com>
>
> *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:public-bounces at cabforum.org
> <public-bounces at cabforum.org>] *On Behalf Of *Peter Bowen via Public
> *Sent:* Wednesday, May 10, 2017 1:09 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Peter Bowen <pzb at amzn.com>
> *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 <public at cabforum.org>
> 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 <cspann at apple.com> 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 <public at cabforum.org>
> 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
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170510/1aec6f8b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6110 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170510/1aec6f8b/attachment.jpg>