Account confirmers, Anti-spam team, Confirmed users, Bureaucrats and Sysops emeriti
4,925
edits
CA/PROCERT Issues: Difference between revisions
Jump to navigation
Jump to search
Strike Issue Q
(Add RFC reference) |
(Strike Issue Q) |
||
| Line 85: | Line 85: | ||
PROCERT OCSP responses are signed with SHA-1 and, since they reflect an attacker-controlled serial number, is vulnerable to a chosen prefix attack. This is not formally against documented policy but in the [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 April 2017 CA Communication], PROCERT affirmed that "SHA-1 certificates are no longer used in the infrastructure related to our root certificates included in Mozilla's CA Certificate Program. (e.g. SHA-1 is no longer used to sign OCSP responses)." They asserted something similar in the [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 March 2016 CA Communication]. However, this appears not to be true. | PROCERT OCSP responses are signed with SHA-1 and, since they reflect an attacker-controlled serial number, is vulnerable to a chosen prefix attack. This is not formally against documented policy but in the [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026 April 2017 CA Communication], PROCERT affirmed that "SHA-1 certificates are no longer used in the infrastructure related to our root certificates included in Mozilla's CA Certificate Program. (e.g. SHA-1 is no longer used to sign OCSP responses)." They asserted something similar in the [https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000000iHdtx&QuestionId=Q00010&QuestionIdForText=Q00011 March 2016 CA Communication]. However, this appears not to be true. | ||
==Issue Q: CRL Distribution Points Using HTTPS (August 2012 - August 2017)== | ==<strike>STRUCK: Issue Q: CRL Distribution Points Using HTTPS (August 2012 - August 2017)</strike>== | ||
[https://crt.sh/?id=192913260&opt=cablint,x509lint This example certificate] has a CRL Distribution Point value of "https://publicador-psc.fii.gob.ve/crlsha256/cacrl.crl". This an HTTPS URL. Because of the chicken-and-egg problem, many clients refuse to attempt to download CRLs from HTTPS endpoints. BRs section 7.1.2.2 b) also require that the URL be HTTP. The certificate used on that site chains up to a different part of the Venezuelan government CA system, and so may well not be trusted by a client which trusts PROCERT anyway. crt.sh knows of around 97 certificates with this problem. | [https://crt.sh/?id=192913260&opt=cablint,x509lint This example certificate] has a CRL Distribution Point value of "https://publicador-psc.fii.gob.ve/crlsha256/cacrl.crl". This an HTTPS URL. Because of the chicken-and-egg problem, many clients refuse to attempt to download CRLs from HTTPS endpoints. BRs section 7.1.2.2 b) also require that the URL be HTTP. The certificate used on that site chains up to a different part of the Venezuelan government CA system, and so may well not be trusted by a client which trusts PROCERT anyway. crt.sh knows of around 97 certificates with this problem. | ||
===PROCERT Response=== | |||
PROCERT noted that this certificate was not issued by PROCERT. On checking this turned out to be correct; it's issued by another part of the same Super-CA hierarchy, as are all the other 96 certificates found in the original search. So this issue has been struck. Apologies to PROCERT. | |||
==Issue R: Incorrect Encoding of or Inappropriate Use of TeletexString (December 2015 - August 2017)== | ==Issue R: Incorrect Encoding of or Inappropriate Use of TeletexString (December 2015 - August 2017)== | ||