RE: CAA Certificate Problem Report

I'm struggling to get my head around what you're asking for. I think you're seriously asking if there's a way to skip all the actual security of DNSSEC and get a secure answer anyway? No. The answer is "No". If you're comfortable with answers that might be lies, you can skip DNSSEC entirely.

Re: CAA Certificate Problem Report

> On Sep 11, 2017, at 18:30, Ryan Sleevi via dev-security-policy > wrote: > > On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> >>> On Sep 11, 2017, at 17:41, Ryan Sleevi

Re: CAA Certificate Problem Report

On Mon, Sep 11, 2017 at 3:09 PM Jonathan Rudenberg via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > That seems like very poor logic and

Re: CAA Certificate Problem Report

> On Sep 11, 2017, at 17:41, Ryan Sleevi via dev-security-policy > wrote: > > That seems like very poor logic and justification. > > Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for > literally years now, perhaps it's worth asking

RE: CAA Certificate Problem Report

Well, we are checking CAA and DNSSEC per our implementation. Looks great on our side and against our tests. Some individuals disagree though. From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Monday, September 11, 2017 3:42 PM To: Jeremy Rowley ; Jonathan

Re: CAA Certificate Problem Report

That seems like very poor logic and justification. Given that CAA and DNSSEC has been discussed in the CA/Browser Forum for literally years now, perhaps it's worth asking why CAs are only now discovering issues. That is, is the only reason we're discovering issues because CAs waited for the last

RE: CAA Certificate Problem Report

I would support that. I can't recall why it's in there. -Original Message- From: Jonathan Rudenberg [mailto:jonat...@titanous.com] Sent: Monday, September 11, 2017 3:19 PM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: CAA

Re: CAA Certificate Problem Report

> On Sep 11, 2017, at 17:03, Jeremy Rowley via dev-security-policy > wrote: > > For a little more context, the idea is that we can speed up the CAA check for > all customers while working with those who have DNSSEC to make sure they > aren't killing

RE: CAA Certificate Problem Report

For a little more context, the idea is that we can speed up the CAA check for all customers while working with those who have DNSSEC to make sure they aren't killing performance. If there's a way to group them easily into buckets (timeout + quick does DNSSEC exist check), working on improving

RE: CAA Certificate Problem Report

I think that's the opposite of what I'm saying. CAs don't need to do DNSSEC provided 1) they don't want to issue certs where DNSSEC is implemented and 2) the CAA record check times out, and 3) there is a way to check if DNSSEC is present without doing the entire chain validation. #3 is what

Re: CAA Certificate Problem Report

On Monday, 11 September 2017 18:33:24 UTC+1, Jeremy Rowley wrote: > That's the entire corpus of information related to DNSSEC in the BRs. Under 4 > and 5, we successfully returned a DNS record. The lookup didn’t fail so the > sentence "the domain's zone does not have a DNSSEC validation chain

RE: CAA Certificate Problem Report

Not saying we implemented DNSSEC checking correctly, but I don't think the requirements are as clear as you present them. The BRs state that: " CAs are permitted to treat a record lookup failure as permission to issue if: • the failure is outside the CA's infrastructure; • the

Re: Certificate with Debian weak key issued by Let's Encrypt

I'd like to push a bit harder on searching for more systemic remediations. "We forgot to get around to revoking it" is a pretty common element of CAs' post-mortems, I think it'd be good for us to dig deeper. For example, does Let's Encrypt have a runbook that gets used on misissuance reports? Is

Re: CAA Certificate Problem Report

On 09/09/17 10:21, Jeremy Rowley wrote: > Certificate 1 contains a single DNS identifier for > big.basic.caatestsuite.com . This DNS > name has a CAA resource record set that is too large to fit within a single > DNS UDP packet, but small enough to fit within a

Re: Certificate with Debian weak key issued by Let's Encrypt

This was simple human error. There isn't a programmatic fix. Our team is planning to scan our database for weak keys again early this week. In any case, any weak key certs issued prior to our July 20 fix will expire in at most 37 days. On Monday, September 11, 2017 at 8:24:49 AM UTC-5, Alex

Re: Lack of CAA checking at Comodo

Hi Hanno. Thanks for reporting this to us. We acknowledge the problem, and as I mentioned at [1], we took steps to address it this morning. We will follow-up with an incident report ASAP. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1398545#c3 On 11/09/17 15:18, Hanno Böck via

Lack of CAA checking at Comodo

Hi, On saturday I was able to receive a certificate from comodo depsite the subdomain having a CAA record only allowing Let's Encrypt as the CA. Here's the cert: https://crt.sh/?id=207082245 I have by now heard from multiple other people that confirmed the same. Seems right now Comodo isn't

RE: StartCom cross-signs disclosed by Certinomis

Hi Gerv, Those updates are referred basically to the format of the report in which Franck asked to include specific information such as the serial number, names, etc. according to your instructions. The report itself has not been changed (that´s forbidden). Regarding the qualifications or

Re: CAs not compliant with CAA CP/CPS requirement

El viernes, 8 de septiembre de 2017, 21:25:20 (UTC+2), Andrew Ayer escribió: > The BRs state: > > "Effective as of 8 September 2017, section 4.2 of a CA's Certificate > Policy and/or Certification Practice Statement (section 4.1 for CAs > still conforming to RFC 2527) SHALL state the CA's policy

Re: CAs not compliant with CAA CP/CPS requirement

Let me pull the data and share it with you. For some reason we saw a few sub domains right before the 8th. We added *.digicerts.com at the last minute until we had time to figure out why. I suspect it's being caused by documentation or a partner telling the customers the wrong thing. Once we

Re: StartCom cross-signs disclosed by Certinomis

Hi Franck, On 03/08/17 08:59, Franck Leroy wrote: > On end of June the audit report form PwC was available but with still some > minor issues. I asked StartCom to correct them. > > On July 14th the audit report and the policy were updated and published on > StartCom website. The audit reports

Re: CAs not compliant with CAA CP/CPS requirement

Hi Ben and Jeremy, On 09/09/17 01:25, Ben Wilson wrote: > Those are typos. See section 4.2.1 of our CPS posted here: > https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf This reads: "The Certification Authority CAA identifying domains for CAs within DigiCert’s

Re: PROCERT issues

Hi Alejandro, Thank you for this initial response. It is, however, far less detailed than we would like to see. In the email I sent to you letting you know that we were looking at PROCERT, I wrote: "You may wish to review a similar issue list we created for Symantec:

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

Hi Connie, On 06/09/17 20:38, cornelia.enk...@gmail.com wrote: > SwissSign has identified the following incident: > two Certificate signed with SHA1: Violation BR 7.3.1 Thank you for this report. There have been a couple of reasonable follow-up questions here in the m.d.s.p. group; could you

Re: StartCom cross-signs disclosed by Certinomis

Getting back to this very late... I am studying this situation today. On 07/08/17 10:21, Franck Leroy wrote: > Then in November 2016 I contacted Kathleen and Gerv to know if there was some > stoppers to work with Inigo to help StartCom to be back in the business. > There was no opposition as

Re: CAs not compliant with CAA CP/CPS requirement

Am Freitag, 8. September 2017 21:25:20 UTC+2 schrieb Andrew Ayer: > The BRs state: > > "Effective as of 8 September 2017, section 4.2 of a CA's Certificate > Policy and/or Certification Practice Statement (section 4.1 for CAs > still conforming to RFC 2527) SHALL state the CA's policy or practice