Policy 2.4 Proposal: Require OCSP responses to be signed by certs with lifetime longer than response

[Gervase Markham]

When an OCSP response signing certificate expires before the OCSP
responses signed by the certificate expire, multiple websites break,
particularly sites that use OCSP stapling. Make it a requirement that
every OCSP response must have a nextUpdate field that is before or equal
to the notAfter date of the certificate that signs it.

Proposal: add another sentence to the second bullet in point 3 of the
Maintenance section:

"The nextUpdate of the OCSP response must be before or equal to the
notAfter date of the certificate which signs it, and all other
certificates in the chain."

This is: https://github.com/mozilla/pkipolicy/issues/20

-------

This is a proposed update to Mozilla's root store policy for version
2.4. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates

[Ryan Sleevi]

On Fri, Dec 16, 2016 at 7:15 AM, Gervase Markham <ge...@mozilla.org> wrote:
> When an OCSP response signing certificate expires before the OCSP
> responses signed by the certificate expire, multiple websites break,
> particularly sites that use OCSP stapling. Make it a requirement that
> every OCSP response must have a nextUpdate field that is before or equal
> to the notAfter date of the certificate that signs it.
>
> Proposal: add another sentence to the second bullet in point 3 of the
> Maintenance section:
>
> "The nextUpdate of the OCSP response must be before or equal to the
> notAfter date of the certificate which signs it, and all other
> certificates in the chain."
>
> This is: https://github.com/mozilla/pkipolicy/issues/20

"all other certificates in the chain" seems ambiguous/problematic, as
written. I'm guessing you were meaning in the context of the SEQUENCE
OF Certificates within a BasicOCSPResponse - that is, the chain (if
any) embedded in an OCSP response should be time valid.

I highlight this since if you're using non-delegated OCSP, you may
have fully omitted the certs (since it is, after all, optional) in
order to save size, and as such, you don't quite 'control' the chain a
client may use. Similarly, you might be using a delegated responder,
but you're not an idiot and you care about performance, and as such,
are only including the delegated responder cert in certs, and leaving
the client to use the chain they constructed (which MUST have issued
the DR cert)

The reason I suspect you meant this is because you could have issues
where a CA has issued

Int A - NotBefore 1/1/2015 and NotAfter 1/1/2016
Int A' - NotBefore 1/1/2016 and NotAfter of 1/1/2017

Int A and Int A' share the same name and key, but the former has
expired, while the latter hasn't. Using an OCSP Response from "Int A"
(the name/key tuple) is fine - since Int A' is time-valid. You *don't*
want the CA shipping Int A in the BasicOCSPResponse.certs - you want
them shipping Int A' - but the existence of Int A shouldn't mean you
can't issue OCSP responses at all.

(This is that subtlety discussed in the Forum related to "What is a CA")

"The nextUpdate of the OCSP response must be before or equal to the

notAfter date of all certificates included within the
BasicOCSPResponse.certs field, or, if the certs field is omitted,
before or equal to the notAfter date of the CA certificate which
issued the certificate that the BasicOCSPResponse is for"

Is that materially the same as what you wanted to say (modulo my
terrible wording)? I can still see potential issues, but I don't want
to over-optimize for them quite yet if others think the above works.

[Gervase Markham]

On 16/12/16 21:22, Ryan Sleevi wrote:
> "The nextUpdate of the OCSP response must be before or equal to the
> notAfter date of all certificates included within the
> BasicOCSPResponse.certs field, or, if the certs field is omitted,
> before or equal to the notAfter date of the CA certificate which
> issued the certificate that the BasicOCSPResponse is for"
>
> Is that materially the same as what you wanted to say (modulo my
> terrible wording)? I can still see potential issues, but I don't want
> to over-optimize for them quite yet if others think the above works.

Yep, that's it, I think. (Well, it was Brian who reported that this
caused issues sometimes but, based on my now-expanded understanding of
the situation from your email, I think this is what is meant. But Brian
can correct me if that's wrong.)

The wording above seems OK to me, but if you can improve it, go right
ahead :-)

Gerv

[Gervase Markham]

On 16/12/16 15:15, Gervase Markham wrote:
> Proposal: add another sentence to the second bullet in point 3 of the
> Maintenance section:
>
> "The nextUpdate of the OCSP response must be before or equal to the
> notAfter date of the certificate which signs it, and all other
> certificates in the chain."

Resolution: fixed using Ryan's wording, with some reformatting of the
section.

Gerv