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. 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. Jeremy From: Ryan Sleevi <r...@sleevi.com> Sent: Friday, May 10, 2019 11:54 AM To: Jeremy Rowley <jeremy.row...@digicert.com> Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CAA record checking issue On Thu, May 9, 2019 at 10:05 PM Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org <mailto:dev-security-policy@lists.mozilla.org> > wrote: We checked all the applicable CAA records and found 16 where the CAA record would not permit us to issue if we were issuing a new cert today. What we are proposing is to revoke these certificates and reissue them (if they pass all the proper checks). The rest would pass if we issued today so we were going to leave these where they are while disclosing them to the Mozilla community. Could you share the risk analysis that helped you reach this latter conclusion? That is, CAA is a time of check thing, and, as you note, you can't be sure they were appropriately authorized at the time of issuance. Thus, even if the site operator is a DigiCert customer now, or might have disabled CAA now, there's no ability to determine whether or not they previously approved it - or even whether the holder of that old certificate is still the authorized domain representative now (e.g. in the event of a domain transfer or sale) In general, the default should be to revoke all. That said, if there's a thorough analysis that has considered this, and other scenarios, and that, on the whole, has led DigiCert to believe the current path is more appropriate, it'd be great if you could share that analysis. I think Tim's questions are useful as well, in understanding the reasoning. Basically, without stating a position on whether your analysis is right or wrong, I'm hoping you can show your work in detail, and all the factors you considered. That sort of analysis is what helps the community build confidence that the chosen path, despite being a violation of the BRs, is a reflection of a CA thoughtfully considering all perspectives.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
