* 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
* 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 u
* mono riot:
>> I've been wondering if CT is a good tool for things like safe
>> browsing to monitor possible phishing sites and possibly detect
>> them faster.
>
> Are there general proposals yet on how to distinguish phishing vs
> legitimate when it comes to domains? (like apple.com vs app1e.com
* 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
* 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.
>
* Patrick Figel:
> 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
* 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 ass
* 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 terms of service or
> c
* 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
>> Cloudflare.
>
> Sure
* 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
* 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
* 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 interm
* 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
* Bruce:
> On Tuesday, March 24, 2015 at 3:41:50 PM UTC-4, Florian Weimer wrote:
>> * Kai Engert:
>>
>> > The discovery of any unconstrained and unrevoked intermediate CA
>> > certificate that isn't controlled by the root CA organization results in
>>
* 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
* Rob Stradling:
> On 24/03/15 19:58, Florian Weimer wrote:
>
>> 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.
__
* 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 *muc
* 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 jus
* 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 constrain
* Gervase Markham:
> On 24/03/15 09:35, Florian Weimer wrote:
>> Sadly, name constraints do not work because they do not constrain the
>> Common Name field. The IETF PKIX WG explicitly rejected an erratum
>> which corrected this oversight.
>>
>> NSS used to
* 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
* Gervase Markham:
> On 24/03/15 00:59, Peter Kurrasch wrote:
>> Is the proposal to limit CNNIC roots to only .cn domains or would
>> others be allowed?
>
> That's a matter for discussion. We do have some data (thanks, Richard)
> from CT and other places on the prevalence of CNNIC certificates in
* Kurt Roeckx:
> So it's my understanding that they were only supposed to issue
> certificates for their own domain(s). Why wasn't this enforced by
> using a name constraint?
Sadly, name constraints do not work because they do not constrain the
Common Name field. The IETF PKIX WG explicitly rej
* 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 PKI
* Kurt Roeckx:
>> RFC 5280 is pretty clear that implementations must support end-entity
>> certificates without the subjectAltName extension under under a CA
>> which has name constraints.
>
> But the CA/B baseline requirements does require a SAN, so there is
> no reason for us not to require it.
* Kurt Roeckx:
> On Sun, May 25, 2014 at 12:17:11PM +0200, Florian Weimer wrote:
>> * Kathleen Wilson:
>>
>> > Unless it is technically constrained as described in section 9 of the
>> > policy.
>>
>> Unfortunately, a conforming implementation of PKIX
* Kathleen Wilson:
> Unless it is technically constrained as described in section 9 of the
> policy.
Unfortunately, a conforming implementation of PKIX validation makes
name constraints useless as a security feature (see bug 394919 for
details).
___
dev
* Jeremy Rowley:
> She's clarified in the discussion thread that it is all SubCAs chained to
> the a CAs root certificate that must be disclosed, regardless of who
> controls the private key.
In any case, control over the private key is only one aspect. It's
also important who runs the Registrat
* Peter Eckersley:
> Florian, there's something that about legal rules that is often quite
> unintuitive to those of us with technical backgrounds: lawyers don't
> necessarily expect them to be followed exhaustively all of the time.
And they tend to withhold compassion (or technical judgments).
* Jürgen Brauckmann:
> Cloudflare set up a challenge with nginx on Ubuntu. Seems some
> people succeeded in extracting the servers private key:
>
> https://www.cloudflarechallenge.com/heartbleed
FWIW, I've asked Comodo to revoke the Cloudflare certificate due to
this compromise. The challenge it
* 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 unlik
* martin:
> The subjects's name is not the domain name, it is the legal entity's name.
> Point one means: The subject's name in the certificate must match the name of
> the domain owner. (checked f.e. via www.denic.de, with www.iana.com)
> Point two means: The subject's name must match the name o
* Kathleen Wilson:
>> The primary document is the CPS which is provided in English.
>> https://pki.atos.net/EJPKI-WebFrontend/Public/TrustedRoot/Download?File=AtosTrustedCA_CPS_v1.6.pdf
Clause 77 is both overly restrictive (domain name must match
registered company name) and permissive (domain ow
33 matches
Mail list logo
