BRs: Clarify OCSP Profile and organize as appropriate

[BenWilson-Mozilla]

The content in BR § 4.9.10 belongs in BR § 4.9.9, and BR § 4.9.10 should say “No stipulation.”

According to my reading of RFC 3647, section 4.9.9 (along with section 4.10) should indicate whether OCSP is a component of the PKI and the availability, uptime, etc. of online status information. Section 4.9.10, on the other hand, is for stating the obligations of relying parties to check that online status information (similar to section 4.9.6). Here is the relevant excerpt, that supports my position that the list under section 4.4.9 of RFC 3647 translates to the information lower down in the table in Section 6):

• On-line revocation/status checking availability, for instance, OCSP and a web site to which status inquiries can be submitted;

• Requirements on relying parties to perform on-line revocation/status checks;

[sleevi]

Thanks for filing this @BenWilson-Mozilla . It's actually a bit more complex than you've outlined. I've retitled to reflect this.

The situation as it stands is that 4.9.9 contains profile requirements on an OCSP responder certificate (this belongs in Section 7.1, for certificate profiles) and OCSP response profiles (this belongs in 7.3). Similarly, 4.9.10 also contains elements of OCSP response profiles, which also belongs in Section 7.3.

The requirement of the OCSP responder uptime and capabilities (such as the GET method) does indeed belong in 4.9.9.

I've moved this from "clean-up" to "enhancement", since this is broadly the OCSP and CRL profiling work previously discussed, and which is currently pending the completion of the Certificate Profile work.

[barrini]

Ben to continue working on this

[BenWilson-Mozilla]

According to RFC 3647 section 6:
4.9.9 On-line revocation/status checking availability
4.9.10 On-line revocation checking requirements

[clintwilson]

I think for the current TBRs (version 2.0.4), the main change that should be considered is moving some of 4.9.9 and 4.9.10 to 7.3, e.g. the following text seems to better fit in 7.3... I think

4.9.9

OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST either:

Be signed by the CA that issued the Certificates whose revocation status is being checked, or
Be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked.

In the latter case, the OCSP signing Certificate MUST contain an extension of type id-pkix-ocsp-nocheck, as defined by RFC6960.

4.9.10

The validity interval of an OCSP response is the difference in time between the thisUpdate and nextUpdate field, inclusive. For purposes of computing differences, a difference of 3,600 seconds shall be equal to one hour, and a difference of 86,400 seconds shall be equal to one day, ignoring leap-seconds.

For the status of Subscriber Certificates:

OCSP responses MUST have a validity interval greater than or equal to eight hours;
OCSP responses MUST have a validity interval less than or equal to ten days;
For OCSP responses with validity intervals less than sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol prior to one-half of the validity period before the nextUpdate.
For OCSP responses with validity intervals greater than or equal to sixteen hours, then the CA SHALL update the information provided via an Online Certificate Status Protocol at least eight hours prior to the nextUpdate, and no later than four days after the thisUpdate.