Sections 4.9.9 and 4.9.10

[mttcpr2]

4.9.9

I think we concluded we are only permitting the CA delegated model, correct? That aligns with the mods we made to the OCSP cert profle. Assuming that's settled, this section's content could be entirely replaced with this:

OCSP responses MUST conform to RFC6960 and/or RFC5019. OCSP responses MUST be signed by an OCSP Responder whose Certificate is signed by the CA that issued the Certificate whose revocation status is being checked.

Note that I removed the id-pkix-ocsp-nocheck verbiage because we have that in the cert profile so there's no need here.

4.9.10

I want to call attention to this combination of requirements:

• must use random serial numbers
• responder is not allowed to return "good" for non-existent certs
• responder must be updated at least every four days

Effects on (pre-generated / cache only) responders:

• cache generation cannot use only the CRL to determine revocation status because it doesn't provide the "good list"
• cache generation must have access to CA cert repository (or copy) to get said list
• certificates issued today may receive unauthorized responses for up to four days
• certificate revoked today may be considered valid for up to four days

If you ask me, that's all relatively ugly. If you want to minimize the lag time, due both to the random serial numbers (urge to start ranting suppressed) and the no "good" rule you're basically forced to have online responder keys with a complete cert repository behind it instead of something elegant and secure like using the CRL on the responder. In any case, I just want to be sure we gave this some thought.

Aside from above, a three minor things:

1. POST is assumed to be supported, but we should be explicit: The CA SHALL support an OCSP capability using both the GET and POST
2. Given the SHOULD to SHALL NOT change in the preceding paragraph, the final paragraph should be deleted.
3. Propose adding: The OCSP responder SHALL use the CRL for determining certificate revocation status. The OCSP response thisUpdate SHALL match the CRL thisUpdate.

The last one is because it keeps responders honest. Without it, they tell you their information is more current than it is when their data could be old and a new CRL has fresher, different, data. You can avoid having them ever contradict one another if thisUpdate is set correctly.

[mttcpr2]

If I didn't mention it elsewhere already, we should add an ocsp response profile to go with our crl profile.

[LarryFrank]

I think we concluded we are only permitting the CA delegated model, correct?

Current proposed text has EITHER CA signs the response or delegated model.

Note that I removed the id-pkix-ocsp-nocheck verbiage because we have that in the cert profile so there's no need here.

Removed.

•must use random serial numbers

Should be in the profile - has nothing to do with OCSP directly...

•responder is not allowed to return "good" for non-existent certs

BR says "SHOULD NOT respond with a "good" status"

•responder must be updated at least every four days

Text says that.

•cache generation cannot use only the CRL to determine revocation status because it doesn't provide the "good list"
•cache generation must have access to CA cert repository (or copy) to get said list
•certificates issued today may receive unauthorized responses for up to four days
•certificate revoked today may be considered valid for up to four days

See "should" above. Can respond good (just shouldn't - i.e., means no actual requirement...) But random serial numbers make pre-gen hard - so maybe the impact is no pre-gen.
Not just a "pre-signed" issue. BR allows revoked certs to be considered valid for a lot more that that! - given that CRL issuance may be up to 7 days and valid for 10 days - so could be 21 total... Current text says every day with a max of 7 days (current Fed policy) - so max is only 11 days - but will change to say it has 4 hours after CRL generation to get the most recent info. CRL" - that way, it is a max of 28 hours. Should generate a new proof list every time.

1.POST is assumed to be supported, but we should be explicit: The CA SHALL support an OCSP capability using both the GET and POST

BR does not require POST - it does require GET. Certainly can include POST but not required. Did not make that change.

2.Given the SHOULD to SHALL NOT change in the preceding paragraph, the final paragraph should be deleted.

I don't know what that is trying to change - "should" on "good"?

3.Propose adding: The OCSP responder SHALL use the CRL for determining certificate revocation status. The OCSP response thisUpdate SHALL match the CRL thisUpdate.

I did change to say "The OCSP Responder SHALL update the information used to respond to requests within 4 hours of a new CRL being issued by the CA for all requests, including CA certificates. "