This is a great discussion and I want to thank everyone for their continued input. Let me try and summarize my interpretation based on the input from this thread and related RFC.
My interpretation is an “unknown” OCSP response should be used in the following conditions: 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder is NOT authoritative (wrong issuing CA). 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative (correct issuing CA) but for whatever reason the OCSP responder does not know the status of the requested certificates and ONLY if the certificate for which the status is requested contains another OCSP responder URL available in the AIA extension. My interpretation is a “revoked” OCSP response should be used in the following conditions: 1. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the requested certificate has been revoked. 2. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the CA corresponding to the issuerNameHash and issuerKeyHash has been revoked. 3. When the OCSP request contains an issuerNameHash and issuerKeyHash for which the OCSP responder IS authoritative and the requested certificate has not been issued. This OCSP response MUST include the extended revoked definition response extension in the response, indicating that the OCSP responder supports the extended definition of the "revoked" state to also cover non-issued certificates. The SingleResponse related to this non-issued certificate MUST specify the revocation reason certificateHold (6), MUST specify the revocationTime January 1, 1970, and MUST NOT include a CRL references extension or any CRL entry extensions. [1] I agree number 3 above is in conflict with the BRs as pointed out by Wayne. - Curt [1] RFC 6960: https://tools.ietf.org/html/rfc6960 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
