Okay. I'm working on something and will post it soon. ________________________________ From: Ryan Sleevi <r...@sleevi.com> Sent: Friday, May 10, 2019 11:54:14 AM To: Jeremy Rowley 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. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
