On Sun, Apr 19, 2020 at 6:13 AM Nick Lamb wrote:
> It's possible that I'm confused somehow, but for me §9.16.3 of the BRs
> does not have numbered item 5, and neither this nor §9.6.1 define
> "contractual jeopardy" nor do they clear up why a subscriber would want
> to shut down their service and
On 19/04/2020 11:13, Nick Lamb via dev-security-policy wrote:
On Sat, 18 Apr 2020 22:57:03 -0400
Ryan Sleevi via dev-security-policy
wrote:
The Baseline Requirements address this. See 9.16.3 (particularly item
5) and 9.6.1 (6).
For better or worse, the situation is as Neil described and
On Sat, 18 Apr 2020 22:57:03 -0400
Ryan Sleevi via dev-security-policy
wrote:
> On Sat, Apr 18, 2020 at 6:39 PM Nick Lamb via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > What does "contractual jeopardy" mean here?
>
> The Baseline Requirements address this.
On Sat, Apr 18, 2020 at 6:39 PM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> What does "contractual jeopardy" mean here?
The Baseline Requirements address this. See 9.16.3 (particularly item 5)
and 9.6.1 (6).
For better or worse, the situation is as Neil
On Fri, 17 Apr 2020 18:34:00 +0100
Neil Dunbar via dev-security-policy
wrote:
> timestamp checking etc, etc]. Ryan's writeup calls out the revoked
> situation under the heading of 'make sure it is something the client
> will accept' - if the client understands OCSP responses at all, it
> needs
On 17/04/2020 14:22, Nick Lamb via dev-security-policy wrote:
GOOD means_at least_ the good CertStatus (also 0) in OCSP. We'll see
why in a moment.
Fair enough. That's what I thought - so holding onto the last successful
OCSP report you have, even if you get exception status codes
On Thu, 16 Apr 2020 13:56:34 +0100
Neil Dunbar via dev-security-policy
wrote:
> On 16/04/2020 00:04, Nick Lamb via dev-security-policy wrote:
> For the avoidance of doubt (and my own poor brain) - does 'GOOD' here
> mean OCSP status code 'successful' (0) AND returning a 'good' status
> for the
On 16/04/2020 14:49, Kurt Roeckx via dev-security-policy wrote:
On 2020-04-16 14:56, Neil Dunbar wrote:
I would have thought that an OCSP-stapling implementation which got
an OCSP status code 'successful' (0) with a 'revoked' status for the
certificate would want to pass that on to the
> As owner of the certificate, I think you actually don't want to do that,
> because things will stop working. If it's revoked you want to get a new
> certificate, and as long as you don't have the new one, you want to use the
> old certificate and staple the good OCSP response.
>
That depends on
On 2020-04-16 14:56, Neil Dunbar wrote:
I would have thought that an OCSP-stapling implementation which got an
OCSP status code 'successful' (0) with a 'revoked' status for the
certificate would want to pass that on to the client, replacing any
prior OCSP successful/status-good report,
On 16/04/2020 00:04, Nick Lamb via dev-security-policy wrote:
Specifically: You should cache your stapled GOOD answers in durable
storage if practical, and when periodically refreshing you should report
non-GOOD answers to the operator (e.g. logging them as an ERROR
condition) but always
On Tue, 14 Apr 2020 13:13:59 -0700
Andy Warner via dev-security-policy
wrote:
> From 2020-04-08 16:25 UTC to 2020-04-09 05:40 UTC, Google Trust
> Services' EJBCA based CAs (GIAG4, GIAG4ECC, GTSY1-4) served empty
> OCSP data which led the OCSP responders to return unauthorized.
No new lessons
12 matches
Mail list logo
