Thanks for bringing this to our attention.
We started investigating and will inform the community of our
findings as soon as we have a clear enough picture.
For now we can say that the irregular OSCP responses reported by your OCSP Watch concern 3 pre-certificates.
Adriano
ACTALIS S.p.A.
Dear Andrew,
Dear all,
Thank you for providing this work regarding OCSP responses and for sharing the detailed list of concerned certificates. We have analyzed SwissSign’s certificates on the list and herewith give a wrap-up of our insights.
SwissSign’s 10 certificates on the list provided under https://sslmate.com/labs/ocsp_watch/ all share the same specifics:
They are precertificates where no final certificates with the according serial number have been issued, the OCSP response for these certificates is «unknown» and they were issued before July 2021.
In September 2021 SwissSign changed the handling of precertificates to not only be compliant with BRG 4.9.10 (which states that a definitive OCSP response is optional for precertificates) but also to follow the recommended practice detailed in “CA/Required or Recommended Practices” (https://wiki.mozilla.org/CA/Required_or_Recommended_Practices).
Because of this constellation (MAY clause in BRG and Mozilla recommended practice) we assumed that it was acceptable to simply let the remaining precertificates in the status “unknown” where no final certificate was issued.
Best regards
Adrian
Adrian Mueller
SwissSign AG
Based on our y2021 logs, we found that the
incorrect OCSP responses for those 3 pre-certificates was caused
by an undetected and isolated DB problem during the insert
phase. That specific issue was addressed by an update we
deployed in August 2021, so the same situation cannot happen any
more. For those 3 pre-certificates we have remedied the
situation by implementing a specific procedure to re-insert the
missing pre-certificates into our DB.
Thanks again, Andrew, for reporting the anomaly.
Adriano
ACTALIS S.p.A.
Hi Vijay,
RFC 6960, Appendix A.2 says:
“An HTTP-based OCSP response is composed of the appropriate HTTP
headers, followed by the binary value of the DER encoding of the
OCSPResponse. The Content-Type header has the value
"application/ocsp-response".”
I believe this is clear guidance that the Content-Type must be “application/ocsp-response” regardless of whether delegated responder certificates are used.
Thanks,
Corey
--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/d039e4b0-e009-46fd-9402-a9e107a8fb75n%40mozilla.org.
I believe this is an acceptable response and there is no problem.
The OCSP response are signed via dedicated responder cert (not the CA), and hence it contains this cert data. Else the OCSP verification fails.