SHA-1 Usage in OCSP Responder

[Harshal Sheth]

Hello,

The following certificates are using the SHA-1 signature algorithm. They will all be valid for approximately three months in 2018, as none have been revoked thus far.

https://crt.sh/?id=62407589&opt=cablint
https://crt.sh/?id=62416636&opt=cablint
https://crt.sh/?id=62423790&opt=cablint
https://crt.sh/?id=62423799&opt=cablint
https://crt.sh/?id=62423818&opt=cablint
https://crt.sh/?id=62423833&opt=cablint
https://crt.sh/?id=62423686&opt=cablint
https://crt.sh/?id=62423690&opt=cablint

Based on the information contained within the subject, they appear to be involved in OCSP responder signing. The BR states "CAs MUST NOT issue OCSP responder certificates using SHA‐1 (inferred)." by 2017-01-01. I am not sure if this applies, as all of these certificates were entered to CT logs on 2016-12-12.

[Doug Beattie]

Hi Harshal,

Yes, we took the option of pre-generating some OCSP signing certificates in 2016 for use in 2017 and 2018 vs. creating long validity OCSP signing certificates or moving to SHA-256. Since the not-before dates are in 2017 when this would have been prohibited, so we posted them to CT logs in 2016 so there was no confusion about when they were created.

Regarding your statement that they don’t appear to be revoked: OCSP signing certificates can’t be revoked, thus they will never show up as revoked.

While browsers don't trust SHA-1, there are some legacy applications that do, and they probably don’t support SHA-256 OCSP signed certificates. When the validation rate of these SHA-1 SSL certificates falls acceptably low, we'll revoke the SHA-1 CA and turn off all of the related OCSP services, but until then we have a few OCSP signing certificates we can use to provide revocation services.

Doug

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy