Re: Criticism of Google Re: Google Trust Services roots

* Peter Kurrasch via dev-security-policy: > By "not new", are you referring to Google being the second(?) instance > where a company has purchased an individual root cert from another > company? It's fair enough to say that Google isn't the first but I'm > not aware of any commentary or airing of

Re: Researcher Says API Flaw Exposed Symantec Certificates, Including Private Keys

* Nick Lamb via dev-security-policy: > In order for Symantec to reveal anybody's private keys they'd first > need to have those keys, which is already, IIRC forbidden in the > BRs. I think this requirement was dropped because it makes it unnecessarily difficult to report key compromises. There

Re: Draft Email - Non-Disclosed SubCAs

* Kathleen Wilson: > The following was stated in Mozilla’s March 2016 CA Communication > (https://wiki.mozilla.org/CA:Communications#March_2016): > Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any > certificate which directly or transitively chains to the root > certificates

Re: WoSign and StartCom: next steps

* Hanno Böck: > Minor sidenote: there have been some concerns about TLS security > vulnerabilities of the qihoo 360 browser [1] [2]. While this is not > directly related to the operation of a CA, it surely would increase the > community's trust of qihoo 360 if these issues get resolved quickly. >

Re: Cerificate Concern about Cloudflare's DNS

* Patrick Figel: > On 17/09/16 16:38, Florian Weimer wrote: >> * Peter Bowen: >> >>> On Sat, Sep 10, 2016 at 10:40 PM, Han Yuwei <hanyuwe...@gmail.com> >>> wrote: >>>> So when I delegated the DNS service to Cloudflare, Cloudflare >>>&

Re: Incidents involving the CA WoSign

* Richard Wang: >> Thus, do you believe it was faithful and accurate for Management to >> warrant that the CA was operated in compliance with the BRs, given >> that Management was aware of incidents of non-compliance? > > This is my fault that I think it is not serious enough to state in > the

Re: Cerificate Concern about Cloudflare's DNS

* 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 that? > > I would guess that they have a clause in their

Re: Cerificate Concern about Cloudflare's DNS

* Ben Laurie: > On 10 September 2016 at 15:43, Erwann Abalea wrote: >> Ironically, since you're not the Subscriber, you cannot request for >> the revocation of this certificate, at least not directly to the >> CA. If you want this certificate to be revoked, you need to ask >>

Re: WoSign Issue L and port 8080

* Nick Lamb: > On Sunday, 11 September 2016 21:05:12 UTC+1, Lee wrote: >> does dns hijacking or dns cache poisoning count as mitm? > > A careful CA validator does DNS only by making authoritative queries, > so they're not subject to cache poisoning since they don't look at > cached answers. I'm

Re: Nation State MITM CA's ?

* Jakob Bohm: > Could they, hypothetically, simply claim to use the real certificate on > the connection from their MiTM machines to the real server to do > practical control validation? They would have to claim, also, that > they are holding the private key of the MiTM certificate "in trust" on

Re: Forbid creation of non-constrained intermediates for external entities

* Florian Weimer: * Kai Engert: The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal

Re: Forbid creation of non-constrained intermediates for external entities

* Rob Stradling: On 24/03/15 19:58, Florian Weimer wrote: snip There's also an ongoing effort to defang CT and make the data much less useful, so CT could turn meaningless fairly soon. Huh? The work on name redaction worries me. ___ dev-security

Re: Forbid creation of non-constrained intermediates for external entities

* Gervase Markham: On 25/03/15 10:27, Florian Weimer wrote: * The CNNIC CPS is incorrect, and they no longer run an Entrust-sponsored sub-CA. I believe this is the correct answer. Quoting Bruce Morton in this thread: Please note that the intermediate certificate which Entrust issued

Re: Forbid creation of non-constrained intermediates for external entities

* Daniel Micay: In other words, if you want the responsible choice to be made in these cases then you should be contacting news publications to shame Mozilla into doing the right thing - not a Mozilla mailing list. Ugh, surely there has to be a better way. I sometimes get carried away and

Re: Consequences of mis-issuance under CNNIC

* Gervase Markham: On 24/03/15 09:38, Florian Weimer wrote: The intermediate certificate which prompted this discussion had C=EG, which does not align well with a limitation to the Chinese market. I'm not entirely sure what you are saying here. Are you saying you are suprised not to see .eg

Re: Forbid creation of non-constrained intermediates for external entities

* Kai Engert: The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. In this case, wouldn't this require the removal of the Entrust root, not just

Re: Consequences of mis-issuance under CNNIC

* Kurt Roeckx: I understand that the name constraint applies to the SubjectAltName. Under the Baseline Requirements the SAN must be present. If there is a CommonName it should match one of the SANs. If the CAs abided by the baseline requirements, we wouldn't have to consider name

Re: Forbid creation of non-constrained intermediates for external entities

* Daniel Micay: These rules would be a lot more meaningful if any new additions to the trust store were required to have Certificate Transparency implemented for the sake of auditing, along with a deadline for other CAs to put it in place. CT would have meant this was trivially caught *much*

Re: Name Constraints

* Richard Barnes: I've been doing some research on the potential benefits of adding name constraints into the Mozilla root program. I've drafted an initial proposal and put it on a wiki page: https://wiki.mozilla.org/CA:NameConstraints Questions and comments are very welcome. A

Re: Stop using SHA1 in certificates

* Kurt Roeckx: But it's unclear if this is really a policy or just what some people think should happen. If we do this, it should not just apply to end-entity certificates, but also to intermediate certificates (but not the self-signature of root certificates). Obviously, that's rather