Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

First of all: Thanks for the transparency, the detailed report and quick response to this incident. A user on Hacker News brought up the possibility that the fairly popular DirectAdmin control panel might also demonstrate the problematic behaviour mentioned in your report[1]. I successfully

Re: Verisign signed speedport.ip ?

Until November 11, 2015, publicly-trusted CAs were allowed to issue certificates for internal names and reserved IP addresses. All certificates of this nature had to be revoked by October 1, 2016. More details here: https://cabforum.org/internal-names/ Patrick On 09.12.17 20:42, Lewis Resmond

Re: DigiCert-Symantec Announcement

On 28.09.17 19:06, Gervase Markham via dev-security-policy wrote: > On 26/09/17 03:17, Ryan Sleevi wrote: >> update in a year, are arguably outside of the scope of ‘reasonable’ use >> cases - the ecosystem itself has shown itself to change on at least that >> frequency. > > Is "1 year" not a

Re: PROCERT issues

On 21/09/2017 23:08, alejandrovolcan--- via dev-security-policy wrote: > Dear Gerv, I have attached a document that gives us a greater > response to each of the points, as well as Mr. Oscar Lovera sent you > an email with the same information > >

Re: Let's Encrypt and Wildcard Domains

In what way would this be a policy violation? Most CAs trusted by Mozilla issue wildcard certificates. Perhaps you were thinking of EV certificates? For EV, wildcard is indeed not permitted, but Let's Encrypt does not issue EV at all. On 29/08/2017 04:31, David E. Ross via dev-security-policy

Re: StartCom cross-signs disclosed by Certinomis

On 03/08/2017 10:47, Inigo Barreira via dev-security-policy wrote> 1. The un-revoked test certificates are those pre-sign ones with uncompleted > ctlog. So they are not completed certificates. > https://crt.sh/?opt=cablint=134843670 > https://crt.sh/?opt=cablint=134843674 >

Re: GoDaddy Misissuance Action Items

On 13/02/2017 16:15, Jürgen Brauckmann via dev-security-policy wrote: > Gervase Markham via dev-security-policy schrieb: >> 1) As with all CAs, update all their domain validation code to use one >> of the 10 approved methods; > > I'm probably confused regarding BRs pre/post Ballot 181: Aren't

Re: Appropriate role for lists of algorithms and key sizes

On 07/02/2017 08:11, Tom wrote: > Le 07/02/2017 à 05:01, Patrick Figel a écrit : >> On 27/01/2017 19:53, Ryan Sleevi wrote: >>> On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham >>> <g...@mozilla.org> > wrote: >>>> >>>> * RSA keys

Re: Appropriate role for lists of algorithms and key sizes

On 27/01/2017 19:53, Ryan Sleevi wrote: > On Fri, Jan 27, 2017 at 3:47 AM, Gervase Markham wrote: >> >> * RSA keys with a minimum modulus size of 2048 bits >> > > Nits and niggles: Perhaps 2048, 3072, 4096? > > - 8K RSA keys cause Web PKI interop problems > - RSA keys that

Re: Incident Report – Certificates issued without proper domain validation

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 review process, Peter Bowen ran a check

Re: WoSign has new roots?

On Tue, Nov 22, 2016 at 10:56 PM, Tobias Sachs wrote: > Am Dienstag, 22. November 2016 21:37:08 UTC+1 schrieb Lewis Resmond: >> Hello, >> >> I just noticed following announcement by WoSign: >> >> https://www.wosign.com/english/News/certificate_pre.htm >> >> If I understand

Re: Cerificate Concern about Cloudflare's DNS

On 03/11/16 10:59, Gervase Markham wrote: > However, I still don't get why you want to use Cloudflare's SSL > termination services but are unwilling to allow them to get a > certificate for your domain name. > > AIUI their free tier uses certs they obtain, but if you pay, you can > provide your

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

On 26/10/16 01:27, Percy wrote: > WoSign will roll out a globally trusted intermediate cert to sign new > certs with the existing WoSign system that had so many control > failures. > > Does Mozilla and this community accept such a work-around for WoSign? > If we do, then what's the point of

Re: WoSign: updated report and discussion

On 07/10/16 13:23, Jakob Bohm wrote: > On 07/10/2016 13:12, Gervase Markham wrote: >> ... * WoSign agrees it should have been more forthcoming about its >> purchase of StartCom, and announced it earlier. >> >> * WoSign and StartCom are to be legally separated, with the >> corporate structure

Re: Comodo issued a certificate for an extension

On 02/10/16 12:01, Jason Milionis wrote: > Still no response from COMODO CA, that's interesting, but why? They published an incident report a couple of days ago. For some reason, it's not visible in the Google Groups archive of m.d.s.p (at least for me). Here's an alternative link:

Re: Cerificate Concern about Cloudflare's DNS

On 17/09/16 16:38, Florian Weimer wrote: > * Peter Bowen: > >> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei >> wrote: >>> So when I delegated the DNS service to Cloudflare, Cloudflare >>> have the privilege to issue the certificate by default? Can I >>> understand like

Re: WoSign Issue L and port 8080

On 11/09/16 22:05, Lee wrote: >> In order to spoof a CA's domain validation request, an attacker >> would need to be in a position to MitM the connection between the >> CA and the targeted domain. > > does dns hijacking or dns cache poisoning count as mitm? I was mentioning this in order to

Re: WoSign Issue L and port 8080

On 10/09/16 22:37, Lee wrote: > Right - I figured that out about 30 seconds after reading an email > about allowing verification on ports 80 and 443. But you only need > to get the initial certificate one time - after that you should be > able to renew using port 443 and I didn't see anything

Re: Sanctions short of distrust

On 03/09/16 01:15, Matt Palmer wrote: > On Fri, Sep 02, 2016 at 03:48:13PM -0700, John Nagle wrote: >> On 09/02/2016 01:04 PM, Patrick Figel wrote: >>> On 02/09/16 21:14, John Nagle wrote: >>>> 2. For certs under this root cert, always check CA's >>>&g

Re: Sanctions short of distrust

On 02/09/16 21:14, John Nagle wrote: > 2. For certs under this root cert, always check >CA's certificate transparency server. Fail > if not found. To my knowledge, CT does not have any kind of online check mechanism. SCTs can be embedded in the certificate (at the time of

Re: Incidents involving the CA WoSign

Richard, the problem with this approach is that the *subscriber* might not be authorized to make this decision for the parent domain. To go back to the GitHub case, the "owner" of a github.io subdomain telling you that they are authorized to own a certificate that covers github.io is irrelevant,

Re: About the ACME Protocol

On 20/07/16 04:59, Peter Kurrasch wrote: > Regarding the on-going development of the spec: I was thinking more > about the individual commits on github and less about the IETF > process. I presume that most commits will not get much scrutiny but > a periodic (holistic?) review of the doc is

Re: About the ACME Protocol

Before getting into specifics, I should say that you're likely to get a better answer to most of these question on the IETF ACME WG mailing list[1]. On 08/07/16 16:36, Peter Kurrasch wrote: > I see on the gitub site for the draft that updates are frequently > and continuously being made to the

Re: StartEncrypt considered harmful today

On 08/07/16 08:04, Peter Gutmann wrote: > Or is it that ACME is just a desperate attempt to derail StartCom's > StartEncrypt at any cost? That doesn't make any sense - ACME has been in production for close to a year, while StartAPI was launched this April (and StartEncrypt just a couple of weeks

Re: StartEncrypt considered harmful today

On Friday, July 1, 2016 at 9:35:20 AM UTC+2, Eddy Nigg wrote: > So far less than three hundred certificates have been issued using > this method, none should have been effectively issue wrongfully due > to our backend checks. Can you comment on how your backend checks would have prevented any