[cabfpub] Profiling OCSP & CRLs

Wed May 10 21:15:02 UTC 2017

What would you like to discuss about it? It's already required.

On Wed, May 10, 2017 at 5:00 PM, Ben Wilson <ben.wilson at digicert.com> 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:sleevi at google.com]
> *Sent:* Wednesday, May 10, 2017 2:58 PM
> *To:* CA/Browser Forum Public Discussion List <public at cabforum.org>
> *Cc:* Ben Wilson <ben.wilson at digicert.com>
>
> *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 <
> 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://lists.cabforum.org/pipermail/public/attachments/20170510/a8c9ff1b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6109 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170510/a8c9ff1b/attachment-0006.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 6020 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170510/a8c9ff1b/attachment-0007.jpg>