[cabfpub] Profiling OCSP & CRLs

Wed May 10 20:40:15 UTC 2017

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

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] 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
<mailto:public at cabforum.org> >
Cc: Peter Bowen <pzb at amzn.com <mailto: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
<mailto: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
<mailto: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
<mailto: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 <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public

_______________________________________________
Public mailing list
Public at cabforum.org <mailto: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/70d3d3d6/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 6110 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170510/70d3d3d6/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170510/70d3d3d6/attachment-0001.p7s>