我已经创建了一批新的证书，这些证书违反了BRS的4.9.9，这是在ASA必须满足的基准要求的第一个版本中引入的。这是https://misissued.com/batch/138/。
在受影响的CA中快速检查包括以下O个字段：Quovadis、GlobalSign、Digicert、HARICA、Certinomis、AS Sertifitseimiskeykus、Actalis、ATOS、AC Camerfirma、SECOM、T-Systems、WISeKey、SCEE和CNNIC。BRS第4.9.9节要求OCSP委派响应器MUST包括id-pkix-ocsp-nocheck扩展。RFC 6960在第4.2.2.2节中定义了OCSP委派响应器，id-KP-OCSPSigning作为EKU的存在表明了这一点。这些证书缺少必要的扩展，因此违反了BRS。由于绝大多数证书是在2013-02-01(Mozilla Root CA Policy v2.1生效日期)或之后发布的，因此这些证书未被起诉。您也可以考虑生效日期为2013-05-15(稍后在[1]中描述)，而不更改结果。此批次并不全面。根据crt.sh的数据，大约有293个证书符合"；的标准，这些证书是由受信任的、支持TLS的CA颁发的，带有OCSPSigning EKU，没有pkix-nocheck&34；。由于其他不符合标准，misissued.com在解析某些证书时遇到了一些问题，因此我只包含了一个样本。Censys.io知道大约有276个证书符合此标准，如您在[2]中所见。观点上的差异突出了CA需要仔细检查他们颁发的证书以了解的重要性。CA理解这与安全相关非常重要。根据基线要求第4.9.1.2节的定义，他们应在七(7)天内撤销这些CA，但此问题的严重程度也证明需要见证的密钥销毁报告是合理的，以便维护这些证书颁发者(可能包括CA的根)的完整性。原因很简单：在我检查的每个案例中，这些证书名义上似乎旨在颁发CA，而不是OCSP响应者证书。似乎许多CA在构建其证书配置文件时并不熟悉RFC 6960，并且在过去[3]中类似地忽略了对此问题的讨论，这突出了此问题的安全影响。我已经将此标记为CA需要仔细检查的安全问题，因为在除颁发CA之外的第三方操作此类证书的情况下，颁发CA已将生成任意ocsp响应的能力委托给该第三方！例如，考虑一下像https://crt.sh/?id=2657658699这样的证书。此证书来自HARICA，在技术上符合Mozilla对TLS的约束定义，因为它缺少id-kp。但是，因为它包括OCSP签名EKU，所以此证书可用于为HARICA的Root！签名任意OCSP消息！这也适用于不受技术约束的子CA。例如，考虑此证书https://crt.sh/?id=21606064。它是由DigiCert颁发给微软的，授予微软为Digicert的巴尔的摩CyberTrustRoot颁发的任何证书提供OCSP响应的能力。我们从DigiCert披露的信息中得知，该证书是由微软独立运行的。不幸的是，吊销该证书根本不足以保护Mozilla TLS用户。这是因为该子CA可以为自己提供成功验证的OCSP，并为其他已撤销的子CA提供OCSP，即使它已被撤销。也就是说，如果此子CA的密钥被恶意用来为自己签署良好的响应，它将被接受。这些安全问题在RFC 6960的4.2.2.2.1节中进行了讨论，并且与对CRL的依赖有关。Mozilla用户可以通过使用OneCRL得到保护，尽管这不会保护其他PKI参与者或不使用OneCRL的用例。略多于三分之一的受影响证书已经被吊销，这是令人鼓舞的。但是，我不知道有任何事件报告讨论此故障，也没有任何密钥破坏报告来保证这些密钥不会被恶意使用。虽然这看起来像是我们使用了错误的配置文件的良性故障，但它对最终用户造成了重大的安全影响，即使它是出于善意。这从第一个版本开始就是BRS的一项要求，并在OCSP RFC和CA中进行了详细说明。这样的疏忽是不可原谅的，特别是如果它是(最有可能的)解决某个特定CA软件供应商的产品的问题。回想一下，同样的理由(解决供应商产品中的一个问题)已经被用来证明MITM拦截是正当的。不幸的是，无知和恶意往往难以区分，因此必须一视同仁。