Re: Digicert issued certificate with let's encrypts public key

On May 18, 2020, at 23:58, Peter Gutmann via dev-security-policy wrote: > > > > This isn't snark, it's a genuine question: If the CA isn't checking that the > entity they're certifying controls the key they're certifying, aren't they > then not acting as CAs any more? They are really only

Re: Use of Certificate/Public Key Pinning

On Mon, 12 Aug 2019, Nuno Ponte via dev-security-policy wrote: Recently, we (Multicert) had to rollout a general certificate replacement due to the serial number entropy issue. Some of the most troubled cases to replace the certificates were customers doing certificate pinning on mobile apps.

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

> On Aug 12, 2019, at 14:30, Wayne Thayer via dev-security-policy > wrote: > > Mozilla has announced that we plan to relocate the EV UI in Firefox 70, > which is expected to be released on 22-October. Details below. Relocate seems a wrong word here. You are basically removing it. A few geeks

Re: DarkMatter Concerns

On Tue, 26 Feb 2019, Rob Stradling via dev-security-policy wrote: Hi Scott. It seems that the m.d.s.p list server stripped the attachment, but (for the benefit of everyone reading this) I note that you've also attached it to https://bugzilla.mozilla.org/show_bug.cgi?id=1427262. Direct link:

Re: [FORGED] Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec

On Thu, 6 Dec 2018, Peter Gutmann via dev-security-policy wrote: Paul Wouters via dev-security-policy writes: Usually X509 is validated using standard libraries that only think of the TLS usage. So most certificates for VPN usage still add EKUs like serverAuth or clientAuth

Re: Incident report - Misissuance of CISCO VPN server certificates by Microsec

> On Dec 5, 2018, at 16:49, Jakob Bohm via dev-security-policy > wrote: > > > > Another question of relevance: > > Does the applicable VPN hardware and software (Cisco VPN servers and > compatible VPN clients) work with certificates that omit all the TLS- > related EKUs, thus allowing

Re: Mitigating DNS fragmentation attacks

On Oct 14, 2018, at 21:09, jsha--- via dev-security-policy wrote: > > There’s a paper from 2013 outlining a fragmentation attack on DNS that allows > an off-path attacker to poison certain DNS results using IP fragmentation[1]. > I’ve been thinking about mitigation techniques and I’m

Re: A vision of an entirely different WebPKI of the future...

On Thu, 16 Aug 2018, Matthew Hardeman via dev-security-policy wrote: 1. Run one or more root CAs Why would people not in the business of being a CA do a better job than those currently in the CA business? I recognize it's a radical departure from what is. I'm interested in understanding

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: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Mon, 30 Apr 2018, Tim Hollebeek wrote: What about the cases we discussed where there is DNSSEC, but only for a subtree? I don't know what that means? You mean a trust island not chained to the root? If so, then yes, that is a zone without DNSSEC since it is missing a DS in its parent (or

RE: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Mon, 30 Apr 2018, Tim Hollebeek via dev-security-policy wrote: I don't think this opinion is in conflict with the suggestion that we required DNSSEC validation on CAA records when (however rarely) it is deployed. I added this as https://github.com/mozilla/pkipolicy/issues/133 One of the

Re: "multiple perspective validations" - AW: Regional BGP hijack of Amazon DNS infrastructure

On Wed, 25 Apr 2018, Ryan Hurst via dev-security-policy wrote: Multiple perspectives is useful when relying on any insecure third-party resource; for example DNS or Whois. This is different than requiring multiple validations of different types; an attacker that is able to manipulate the DNS

Re: On the value of EV

On Mon, 11 Dec 2017, Ryan Hurst via dev-security-policy wrote: The issues with EV are much larger than UI. It needs to be revisited and a honest and achievable set of goals need to be established and the processes and procedures used pre-issuance and post-issuance need to be defined in

Re: On the value of EV

On Mon, 11 Dec 2017, James Burton via dev-security-policy wrote: EV is on borrowed time You don't explain why? I mean domain names can be confusing or malicious too. Are domain names on borrowed time? If you remove EV, how will the users react when paypal or their bank is suddenly no longer

RE: Anomalous Certificate Issuances based on historic CAA records

On Thu, 30 Nov 2017, Tim Hollebeek via dev-security-policy wrote: [somewhat off topic, you can safely hit delete now] So it turns out DNSSEC solves CAA problems for almost nobody, because almost nobody uses DNSSEC. The only people who need to use CAA are the CA's. They can surely manage to

Re: Anomalous Certificate Issuances based on historic CAA records

On Thu, 30 Nov 2017, Wayne Thayer wrote: [cut CC: list, assuming we're all on the list] - Subscribers already (or soon will) have CT logs and monitors available to detect mis-issued certs. They don't need CAA Transparency. It's not for subscribers, but for CA's. Transparency is nice, but

Re: Anomalous Certificate Issuances based on historic CAA records

> On Nov 29, 2017, at 17:00, Ben Laurie via dev-security-policy > wrote: > > This whole conversation makes me wonder if CAA Transparency should be a > thing. That is a very hard problem, especially for non-DNSSEC signed ones. Paul

Re: Incident Report – Certificates issued without proper domain validation

On Wed, 11 Jan 2017, Patrick Figel wrote: On 11/01/2017 04:08, Ryan Sleevi wrote: Could you speak further to how GoDaddy has resolved this problem? My hope is that it doesn't involve "Only look for 200 responses" =) In case anyone is wondering why this is problematic, during the Ballot 169

Re: Reuse of serial numbers

On Tue, 6 Sep 2016, Kyle Hamilton wrote: That seems unlikely to me (in that browsers don't really keep a server cert database). Has that changed? I talked with Dan Veditz (at Mozilla) around 5 years ago regarding the fact that NSS had told me of duplicate serial numbers being issued by a

Re: Should we block Blue Coat's 'test' intermediate CA?

While not stating an opinion on the question asked, let me note that having an empty crl could be fine if all their test certificates expire within the hour. Sent from my iPhone > On Jun 14, 2016, at 21:02, Mat Caughron wrote: > > > Adding fuel to the fire that

Re: Should we block Blue Coat's 'test' intermediate CA?

On Tue, 31 May 2016, doliver...@gmail.com wrote: Here is Bluecoat showing off their MITM appliance. https://www.bluecoat.com/security-blog/2014-01-02/exploring-encrypted-skype-conversations-clear-text Note that it only shows a MITM TLS when you install their CA. Which, whether we like it or

Re: StartCom (false) vulnerability report

On Thu, 24 Mar 2016, Peter Kurrasch wrote: 3) The claim that CT leads to better security is partially specious. My argument here is also one I've made before wherein having an audit trail such as CT typically only helps after the fact--only after a problem is discovered. We've even had posts

RE: [FORGED] Re: [FORGED] Re: Nation State MITM CA's ?

On Tue, 12 Jan 2016, Peter Gutmann wrote: Or we ensure that firefox and chrome refuses to see those sites at all, because they refuse a downgrade attack. So users will switch to whatever browser doesn't block it, because given the choice between connecting to Facebook insecurely or not

Re: Nation State MITM CA's ?

On Thu, 7 Jan 2016, Jakob Bohm wrote: It would appear from this information, that this CA (and probably others like it) is deliberately serving a dual role: 1. It is the legitimate trust anchor for some domains that browser users will need to access (in this case: Kazakh government sites