RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

> Given the TTLs and the key sizes in use on DNSSEC records, why do you believe > this? DigiCert is not sympathetic to disk space as a reason to not keep sufficient information in order to detect misissuance due to CAA failures. In fact, inspired by this issue, we are taking a look internally

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: However, what does this buy us? Considering that the ZSKs are intentionally designed to be frequently rotated (24 - 72 hours), thus permitting weaker key sizes (RSA-512), I don't know anyone who believes or uses these timings or

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tue, May 22, 2018 at 11:17 AM, Tim Hollebeek wrote: > > > Given the TTLs and the key sizes in use on DNSSEC records, why do you > believe > > this? > > DigiCert is not sympathetic to disk space as a reason to not keep > sufficient > information > in order to detect

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

What precisely was the antecedent of “this” in your message? Re-reading it, I’m not clear which sentence you were referring to. The only reasons I can think of for not keeping DNSSEC signed RRs are storage and/or performance, and we think those concerns should not be the driving force in

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tue, May 22, 2018 at 12:14 PM, Tim Hollebeek wrote: > What precisely was the antecedent of “this” in your message? Re-reading > it, I’m not clear which sentence you were referring to. > > > > The only reasons I can think of for not keeping DNSSEC signed RRs are >

RE: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

What that wall of text completely misses is the point I and others have been trying to make. The logs have to have enough information so you don’t end up in the situation Let’s Encrypt is currently, and unfortunately, in. Yes, what they did is compliant, and that’s exactly what most

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On 21 May 2018 14:59, Ryan Sleevi wrote:Given the TTLs and the key sizes in use on DNSSEC records, why do you believe this?This is a smoking gun because it's extremely strong circumstantial evidence. Why else would these records exist except that in fact the "victim" published

Fwd: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

Copying message accidentally sent directly to a list participant. -- Forwarded message -- From: Matthew Hardeman Date: Tue, May 22, 2018 at 3:47 PM Subject: Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident To: Ryan Sleevi

InfoCert Acquisition of Camerfirma

On Thursday, a representative of AC Camerfirma sent an email informing Mozilla that InfoCert [1] has taken control of Camerfirma. News of the deal was first published on May 4th. [2] Section 8.1 of our policy applies here (quoting version 2.6 draft): If the receiving or acquiring company is new

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

On Tue, May 22, 2018 at 12:11 PM Ryan Sleevi wrote: > Overall, I think this would be good to proceed, but there's certain > discrepancies called out under Questions that I think should be resolved > before doing so. I would suggest contacting WISeKey for follow-up on these, >

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

Thanks for the reminder, Wayne. I've reviewed the CPS and Audit Reports and have the following comments. I will note that, due to having already had someone else look at it, I only focused on information validation related to domains and IPs, and did not examine the policies around OV and EV, as

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

I think your position is both misguided and unrealistic, and I think you're using it as an opportunity to pursue a technical issue, when there is both a systemic issue at play (and can be demonstrated through all validation methods) and a fundamental misunderstanding as to the value it would

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tuesday, May 22, 2018 at 1:04:31 PM UTC-4, Paul Wouters wrote: > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > > However, what does this buy us? Considering that the ZSKs are intentionally > > designed to be frequently rotated (24 - 72 hours), thus permitting weaker > >

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tuesday, May 22, 2018 at 1:32:51 PM UTC-4, vduk...@gmail.com wrote: > On Tuesday, May 22, 2018 at 1:04:31 PM UTC-4, Paul Wouters wrote: > > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > > > > However, what does this buy us? Considering that the ZSKs are > > >

Re: 2018.05.18 Let's Encrypt CAA tag value case sensitivity incident

On Tue, May 22, 2018 at 1:03 PM, Paul Wouters wrote: > On Tue, 22 May 2018, Ryan Sleevi via dev-security-policy wrote: > > However, what does this buy us? Considering that the ZSKs are intentionally >> designed to be frequently rotated (24 - 72 hours), thus permitting weaker >>