Yes, CAA transparency should exist. Right now CAA is only a point-in-time check by the CA with no way to verify what the CA saw or what was processed. This was one of the limitations raised during the discussions about adoption. Without some transparency, the reliance is on the CA to ensure the CAA record checking is properly done and not useful to subscribers. Despite the lack of transparency, CAA checking is still useful as it can help a CA prevent unauthorized issuance, even if the prevention/CAA record check results aren’t publicly available. CAA is a useful tool for CAs but could be a more useful tools for researchers if there was a good way to make the record check results more publicly available.
Jeremy From: Ben Laurie [mailto:[email protected]] Sent: Wednesday, November 29, 2017 3:01 PM To: Jeremy Rowley <[email protected]> Cc: [email protected]; [email protected] Subject: Re: Anomalous Certificate Issuances based on historic CAA records This whole conversation makes me wonder if CAA Transparency should be a thing. On 29 November 2017 at 20:44, Jeremy Rowley via dev-security-policy <[email protected] <mailto:[email protected]> > wrote: The Thawte records aren't showing any CAA record preventing wildcards either. Here's the Thawte CAA record logs for the domain: 2017-09-13 05:25:09.117 [pool-3058695-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk <http://trnava-vuc.sk> type: 257 result: 4 lookupTimeout: 500 2017-09-13 05:25:09.117 [pool-3058693-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Looking for alias for: trnava-vuc.sk <http://trnava-vuc.sk> 2017-09-13 05:25:09.117 [pool-3058696-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Lookup domain: trnava-vuc.sk <http://trnava-vuc.sk> type: 5 result: 4 lookupTimeout: 750 2017-09-13 05:25:09.117 [pool-3058692-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [trnava-vuc.sk <http://trnava-vuc.sk> ] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ] 2017-09-13 05:25:09.118 [pool-3058691-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of trnava-vuc.sk <http://trnava-vuc.sk> is: 1 2017-09-13 05:25:09.118 [pool-3058693-thread-1] [] INFO c.s.s.r.service.CAAV2CheckService - CAAResponse: CAAMatchCode : [32] : CAAInput : [*.trnava-vuc.sk <http://trnava-vuc.sk> ] : CAAMatchMessage : [CAA record not found] : CAADNSRecords : [ ] 2017-09-13 05:25:09.118 [pool-3058691-thread-2] [] INFO c.s.s.r.service.CAAV2CheckService - Time taken in seconds for CAA check of *.trnava-vuc.sk <http://trnava-vuc.sk> is: 2 Jeremy -----Original Message----- From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley <mailto:dev-security-policy-bounces%2Bjeremy.rowley> [email protected] <mailto:[email protected]> ] On Behalf Of douglas.beattie--- via dev-security-policy Sent: Wednesday, November 29, 2017 4:27 AM To: [email protected] <mailto:[email protected]> Subject: Re: Anomalous Certificate Issuances based on historic CAA records Hi Quirin, I'm curious about how you recorded the historical information from DNS, can you explain how this was requested and logged? We logged the data used for issuance of the GlobalSign certificate at the time of issuance and it's different from what you recorded. We logged that there was no “issuewild” entry and that "digicert.com <http://digicert.com> ", "globalsign.com <http://globalsign.com> ", "letsencrypt.org <http://letsencrypt.org> " and "rapidssl.com <http://rapidssl.com> " are all defined as “issue” at time of issuance. Doug On Friday, November 24, 2017 at 7:23:25 AM UTC-5, Gervase Markham wrote: > Hi Quirin, > > Thank you for your work on this topic. I would be grateful if you > could file Bugzilla bugs in the Misissuance component as follows, > giving your evidence of misissuance: > > On 22/11/17 23:50, Quirin Scheitle wrote: > > 1) Mix of wildcard and non-wildcard DNS names in SAN > > Batch: > > https://clicktime.symantec.com/a/1/4dVQ4kGvYsWRmDR0QMfBBhhwpXEgvnl0A7TEgxMQx-Y=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fmisissued.com%2Fbatch%2F32%2F > > Description: best confer > > https://clicktime.symantec.com/a/1/bRWz8YI8GaFJN5p0wMSlE_HKuFXeSpidx > > EosAdBNIhw=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTF > > qzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1B > > sUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noA > > PAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8 > > H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt > > 1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjh > > fxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF > > 6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fgroups.google > > .com%2Fd%2Fmsg%2Fmozilla.dev.security.policy%2FO9HZPMvHMY8%2FHtXR8S- > > 1AAAJ > > One bug per CA, please. > > > 4) Apparent non-evaluation of CAA records > > Batch: > > https://clicktime.symantec.com/a/1/ZSn0R3LPoUJA--jAELl6kXSjRsrKYmYOKsgQn5Gve1U=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Fmisissued.com%2Fbatch%2F33%2F > > Description: These cases appear as pretty straight-forward that they > > should not have been issued, but > > there might be good explanations > > One bug for the two Comodo certs, one for the Camerfirma cert. > > Thank you, > > Gerv _______________________________________________ dev-security-policy mailing list [email protected] <mailto:[email protected]> https://clicktime.symantec.com/a/1/oAalxx5y7jnwYJenYD34I2nHx_u_mkjdw0--8ecHQ0s=?d=rkGEi9PYD9VAuJcuuNl_82EIceTRmNUV-CSz6VnLprGkKWC5qO_pTFqzTqItIrlHULu_74YdlLpwafEHJsWyJlsnxXxdlqbrgtuvS2sVM1lDR58zsfgSszsL1BsUK0qlPgkKq9Jm-IsHuRYomXUaQ3iu5fLmzKVagdoX0LhTmygTygjdgc-zyO2ThD4noAPAfEow_4QSRxJzWUxIFdyghvj1lzF-xWhxb__1OvcJCp9aGkIYWZYDZ73ecMsovTuRD8H39wXh4pqzMlwLWvkpNPyQRRp7mHoxoa00SNpoC18PP-_01YOSM5ijfGx8vefcuDDcKt1DWhMNKto4Ezgv5Q2w_-J4j4EUpa9FliuJA2nOqD_Y2or0a_6EcFLl2sGoNa120tlyjhfxSMd6SBF4WxXgrWRvI2vQ324f-Zjgp9maEE02aJVanB-D5Fa2kjOEax5n8dtFGFmTHF6mGdm3Ciwy38yneQ5QEbjN038nIZxAwx1l9SBe&u=https%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] <mailto:[email protected]> https://lists.mozilla.org/listinfo/dev-security-policy
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
