> The CRL question is not about it being a requirement, but rather the fact
> that it could / would lead to disparate treatment between CRL and OCSP for
> the same certificate, which does not feel right.
The CRL would only grow if the (pre-cert || cert) needed to be revoke for any
Great feedback. This is exactly the type of input needed to get clarity around
operating OCSP responder services for certificates in the WebPKI ecosystem.
> I think an important part missing from this, overall, is to highlight that
> these clauses only apply with respect to definitive
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
1. When the OCSP
> On 19/09/2019 01:09, Curt Spann via dev-security-policy wrote:
>> In the WebPKI ecosystem I have seen a wide range of OCSP responses for OCSP
>> requests using SHA256 for the issuerNameHash and issuerKeyHash. I
In the WebPKI ecosystem I have seen a wide range of OCSP responses for OCSP
requests using SHA256 for the issuerNameHash and issuerKeyHash. I have observed
the following types of OCSP responses:
1. “good” response with issuerNameHash and issuerKeyHash using SHA256
2. “good” response with
My interpretation is once a precertificate has been signed with the issuing CA
key the corresponding OCSP service should only respond with "good" or
"revoked". In this case an "unknown" response indicates the specific serial
number for the issuing CA has not been assigned which isn’t the case.
I created the following bug:
dev-security-policy mailing list
Mail list logo