On Fri, May 10, 2019 at 3:55 PM Jeremy Rowley <jeremy.row...@digicert.com> wrote:
> The analysis was basically that all the verification documents are still > good, which means if we issued the cert today, the issuance would pass > without further checks (since the data itself is good for 825 days). > Because of this, customers with domains that didn’t prohibit Digicert in > their CAA record (anywhere in the chain) could simply reissue the > certificate without a problem. We could require this of all customers. For > the 16, issuance would fail if the CAA check was performed today. > Therefore, we want to revoke those. > > > The one reason I wanted more time to respond is that we think we may have > most CAA records in our Splunk data for the time of issuance. Our new plan > is that we will revoke all certs unless we can confirm the CAA record was > permissive at the time of issuance. I don’t know the number of certs that > we will revoke yet. I’ll post an update when we compare the Splunk data to > the issuance data. > Thanks for answering. I was hoping you had a more thorough analysis ;) I do have other questions about the implementation details, but I'll add those to the bug, so we can focus this discussion on the immediate remediation steps. I guess my reservation with such an approach (and this is more a metapoint) is consider issuing an EV certificate without having the supporting documentation and/or without validating the documentation. You later come back to the documents, validate them, and find out you got lucky - the information was actually correct, even though the controls failed and the process wasn't followed. Do you revoke the certificates, on the basis the process failed, or do you not revoke them, because they were eventually consistent? This might sound like a hypothetical, but it's a question this industry has faced in the past [1][2], and browsers have reached different conclusions than CAs. It's not immediately clear to me how the proposed response here differs from those past responses, and may highlight some of the difference in philosophies here. An analysis that considered these past events, and how they were received by the community, and how there may be different facts here that lead to different conclusions, would be useful in both validating and justifying the proposed course of action. > The real problem was the CA would kick off a request to the CAA checker. > If the CA encountered an error, the request would time out. The CAA record > may still have checked the CAA records appropriately but the CA never > pulled the information to verify issuance authorization. So it’s a > mis-issuance unless we can pull the data and prove it wasn’t. Combing > through the archive data will take a while. > [1] https://wiki.mozilla.org/CA:Symantec_Issues#Issue_C:_Unauthorized_EV_Issuance_by_RAs_.28January_2014_-_February_2015.29 [2] https://wiki.mozilla.org/CA:Symantec_Issues#Issue_T:_CrossCert_Misissuances_.28January_2010_-_January_2017.29 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
