On Tue, Mar 24, 2015 at 8:52 PM, Kathleen Wilson wrote:
> ... which includes local-parts of "admin", ...
Perhaps better as "which are limited to" or some such? Includes makes
it sound non-exhaustive.
--
https://annevankesteren.nl/
___
dev-security-po
> * Browser people detected this misissuance
This one, but not at least several others issued by this CA.
> * Browser people acted fast to untrust the offending ICA
Yes, but not the root which issued it in violation of many of the
policies for the trust store, despite strong language implying th
> Take a few deep breaths. Just breathe. There. Good.
If that's what helps you sleep at night. It remains a fact that browser
vendors chose to hand the keys to the castle to an organization known at
the time to be one of the largest distributors of malware in the world.
I'm not talking broadly abo
> To be fair, Debian and other projects have even lower security standards.
>
> That is, they still mark CACert as secure for SSL in "stable" (how is that
> not a security update relevant, even if fixed in Untable?!)
CACert is not nearly as bad as many of the CAs Mozilla actually
considers to be
On 24/03/15 08:33 PM, Ryan Sleevi wrote:
> On Tue, March 24, 2015 4:44 pm, Daniel Micay wrote:
>> They're willing to set the security standards *really low* because all
>> that matters is market share. I can't really understand how they ended
>> up in the position of having the dominant trust st
On Tue, March 24, 2015 4:44 pm, Daniel Micay wrote:
> They're willing to set the security standards *really low* because all
> that matters is market share. I can't really understand how they ended
> up in the position of having the dominant trust store used by FOSS
> projects. Debian and other
> I'd be happy to make a
> mozilla-is-irresponsible-for-shipping-a-browser-with-no-sandbox-and-not-enforcing-CA-policy-and-more
> mailing list but I'd still express my strong opinions here too.
IMO, refusal to actually enforce the CA policy is identical to other
stupid decisions like Firefox not u
On 24/03/15 06:21 PM, Ryan Sleevi wrote:
>
> It's difficult to have a discussion with you when you mount attacks ("This
> happened because of your negligence" / "Can you please stop pretending
> that the people involved in PKI are responsible")
I think most people would consider those to be state
On Tue, March 24, 2015 3:27 pm, Kai Engert wrote:
> Couldn't you get an intermediate that's constrained to the list of
> domains that Google controls?
And this was the part that has been repeatedly discussed on this list and
in the CA/Browser Forum, and which the answer for Google (and for a lar
On Tue, 2015-03-24 at 14:29 -0700, Ryan Sleevi wrote:
> For example, is your intent to prevent Google from running its own
> intermediate for its properties? That's the effect of this proposal.
Ryan, thanks for your detailed response. Let me start by replying to the
above part of your response.
I
Anyin,
It seems that the mailing list strips attachments. I copied the ones
you attached to this message a shared location. They are at:
https://pzb-public-files.s3-us-west-2.amazonaws.com/B1.pdf
https://pzb-public-files.s3-us-west-2.amazonaws.com/B2.pdf
Thanks,
Peter
On Mon, Mar 23, 2015 at
On Tue, March 24, 2015 3:11 pm, Daniel Micay wrote:
> That's not a zero tolerance policy. It's an example of compromise where
> in exchange for more lenience, the CAs have to do something. You have to
> demonstrate that they have something to gain by showing that the
> policies have teeth thoug
> That's not a zero tolerance policy. It's an example of compromise where
> in exchange for more lenience, the CAs have to do something. You have to
> demonstrate that they have something to gain by showing that the
> policies have teeth though.
(removing a shiny green bar
signature.asc
Descrip
Okay, so if a CA doesn't want to cause a service disruption for their
customers when this happens, they will implement CT. You can remove
their certificate and make a press release saying you wouldn't have
distrusted their old certificates if they implemented CT. I'm sure CT
will jump to the top of
On Tue, March 24, 2015 2:50 pm, Daniel Micay wrote:
> There's no service disruption caused by not trusting any certs from the
> CA created after say, 3 weeks from now. They utterly failed to comply
> with numerous rules and if those policies have any real teeth behind
> them their time as a tru
Today the Mozilla CA policy and the CAB Forum categorize CAs as either
Root CAs or Intermediate CAs. However the reality is that the line is
not always clear between the two and this leads to uncertainty of what
requirements apply in various circumstances. For example, the Baseline
Requirements re
Anyway, really hard to see how two browsers holding a majority of the
market share do not have all of the cards in their hands. This happened
because of your negligence and will continue to happen. It's a good
thing you don't sell your browser to your users because then they'd have
standing to sue
Absolutely agreed. There is ample evidence that CNNIC has not upheld their
responsibilities in Mozilla's Certificate Inclusion Policy. Can someone please
file a bug to remove CNNIC as a trusted root CA?
-Daniel
On Tuesday, March 24, 2015 at 2:18:12 PM UTC-7, Ryan Sleevi wrote:
>
> Based on the
On 24/03/15 05:29 PM, Ryan Sleevi wrote:
>
> I also think extreme care is needed before proposing blanket
> zero-tolerance policies. It's no accident that no program spells those out
> - it's a recognition of complexities. Even the few places in the Baseline
> Requirements that spell out hard actio
On Tue, March 24, 2015 11:26 am, Kai Engert wrote:
> Thoughts?
I don't believe this is reasonable/responsible.
For example, is it your intent to prevent Let's Encrypt from becoming
cross-certified? That's the effect of this proposal.
For example, is your intent to prevent Google from running it
On Mon, March 23, 2015 3:47 pm, Richard Barnes wrote:
> Dear dev.security.policy,
>
> It has been discovered that an intermediate CA under the CNNIC root has
> mis-issued certificates for some Google domains. Full details can be
> found
> in blog posts by Google [0] and Mozilla [1]. We would
On Mon, March 23, 2015 3:47 pm, Richard Barnes wrote:
> Dear dev.security.policy,
>
> It has been discovered that an intermediate CA under the CNNIC root has
> mis-issued certificates for some Google domains. Full details can be
> found
> in blog posts by Google [0] and Mozilla [1]. We would
Looping back in the mail list which was dropped by mistake The issues at hand are: Who will choose to self-constrain? Who should be forced to constrain? Who benef
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
> > the immediate removal of the root CA from the Mozilla CA lis
On 24/03/15 04:10 PM, Daniel Micay wrote:
> On 24/03/15 03:40 PM, 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
>>> the immediate removal of the root CA from
On 24/03/15 03:40 PM, 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
>> the immediate removal of the root CA from the Mozilla CA list.
>
> In this case, wouldn'
On 24/03/15 03:58 PM, Florian Weimer wrote:
> * 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
* 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
On 3/23/15 8:36 AM, Kathleen Wilson wrote:
Just to be clear... This is the wording copied as-is from the wiki page.
I have not proposed any changes yet -- I'm looking for your input on how
to update this wiki page, and I appreciate the input you all have
provided so far.
Thanks,
Kathleen
On 3/
* 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
> Technically, this is true. I just find it odd that the offending
> certificate suggests a relationship with a non-Chinese market, while
> at the same time, Richard's data only shows the top gTLDs and various
> China-related TLDs.
Why would the Chinese military directly implicate China for a
cer
> At least there'd be clarity about the immediate removal on discovery.
I find it hard to believe that a business centered entirely around the
CA business would self-report this or any other issue if they knew it
would lead to removal. At the moment, the only incentive to report is
the potential g
On Tue, 2015-03-24 at 14:52 -0400, Daniel Micay wrote:
> > Thoughts?
>
> I think it's a good policy, but like the current policies it cannot
> really be enforced because there is no way to validate compliance.
At least there'd be clarity about the immediate removal on discovery.
Kai
__
> Thoughts?
I think it's a good policy, but like the current policies it cannot
really be enforced because there is no way to validate compliance.
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
On 24/03/15 02:11 PM, Charles Reiss wrote:
> On 03/23/15 22:47, Richard Barnes wrote:
>> Dear dev.security.policy,
>>
>> It has been discovered that an intermediate CA under the CNNIC root has
>> mis-issued certificates for some Google domains. Full details can be found
>> in blog posts by Google
This is a suggestion for stricter rules regarding the creation of
intermediate CA certificates that are issued by root CA certificates
included in the Mozilla CA list.
Every CA organization should be ultimately responsible that the
intermediate CA certificates they create will never be used in a M
On 03/23/15 22:47, Richard Barnes wrote:
> Dear dev.security.policy,
>
> It has been discovered that an intermediate CA under the CNNIC root has
> mis-issued certificates for some Google domains. Full details can be found
> in blog posts by Google [0] and Mozilla [1]. We would like to discuss wh
On Mon, 2015-03-23 at 17:47 -0500, Richard Barnes wrote:
> It has been discovered that an intermediate CA under the CNNIC root has
> mis-issued certificates for some Google domains. Full details can be found
> in blog posts by Google [0] and Mozilla [1]. We would like to discuss what
> further ac
Regarding Peter's questions,
- What response has their been from CNNIC on this issue? How do they explain
issuing a subordinate CA certificate with a private key not being on a HSM
meeting the Baseline Requirements?
We informed MCS Holding provide an official report(attached) for this issue and
It's so not ture. I am sure this misuse is not intentional. Actually the
MCSHolding is contact CNNIC first early in the 2015. After dicussion, we
signed agreement to issue a 2 weeks intermediate root for testing propose.
And we take action to revoke the intermediate root as soon as we received
rep
Hello Anyin,
i would like to inform you that i will hold our testing lab for a 2 days to
respond to your inquiries
and this will be the only chance for you to audit and to get a more clear
picture for our feedback
after two days, the logs and information might be unavailable due to our
applica
Hello Anyin,
It's really unfortunate to get such absolute incorrect and prejudiced feedback
I sent the truth inside the requested report and i am ready to submit any
required proofs from our Firewall Logs as we reported
I don’t think being a company established 8 years ago with a very successfu
On 24/03/15 13:18, quanxunz...@gmail.com wrote:
> As it is shown that, CNNIC doesn't have any proper audit policy for
> issuing external subCA, and it is the first time they do so, can we
> at least untrust any external subCA issued by CNNIC before their
> updating policy gets reviewed?
You mean w
On 24/03/15 14:25, Florian Weimer wrote:
> Technically, this is true. I just find it odd that the offending
> certificate suggests a relationship with a non-Chinese market, while
> at the same time, Richard's data only shows the top gTLDs and various
> China-related TLDs.
This may be a limitation
Le mardi 24 mars 2015 15:32:10 UTC+1, Florian Weimer a écrit :
> * Kurt Roeckx:
> > We know that not everybody does add the SANs. But I think that if
> > there is a name constraint and there is no SAN we should just either
> > reject the certificate for being invalid or for not matching.
>
> Thi
* 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 be different (before the mozilla::pkix
* 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
Le mardi 24 mars 2015 09:59:47 UTC+1, Gervase Markham a écrit :
> On 24/03/15 00:00, Peter Bowen wrote:
[...]
> > - What response has their been from CNNIC on this issue? How do they
> > explain issuing a subordinate CA certificate with a private key not
> > being on a HSM meeting the Baseline Req
On 24/03/15 12:40, Peter Kurrasch wrote:
> I'm confused because it sounds like you're advocating for the status
> quo but I didn't think that was your position?
I am not in favour of non-consensual name constraints for CAs in
general. I think it would either be ineffective in improving security
(i
As it is shown that, CNNIC doesn't have any proper audit policy for issuing
external subCA, and it is the first time they do so, can we at least untrust
any external subCA issued by CNNIC before their updating policy gets reviewed?
- Xidorn
___
dev-sec
I'm confused because it sounds like you're advocating for the status quo but I
didn't think that was your position?
Original Message
From: Gervase Markham
Sent: Tuesday, March 24, 2015 4:25 AM
To: Peter Kurrasch; Richard Barnes;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Name
On 2015-03-24 10:35, Florian Weimer wrote:
* 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 Nam
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 be different (before the mozilla::pkix rewrite), but it's
> not P
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" in that list?
> Ho
* 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
On 24/03/15 05:01, Peter Kurrasch wrote:
> 1) As a first step on the path to fairness, perhaps there can be
> agreement that the goal of any name constraint policy should be the idea
> that a single root does not "get the whole internet". Maybe a whole CA
> organization might, but a single root sho
On 23/03/15 22:47, Richard Barnes wrote:
> We propose to add name constraints to the CNNIC root in NSS to minimize the
> impact of any future mis-issuance incidents.
I think it's worth noting that alternative options (both more and less
severe) would be considered, if people want to make a case
Yes, we are working on fixing this issue with our CA system.
Regards,
An Yin
CA Product Manager
-邮件原件-
发件人: dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org
[mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表
Gervase Markham
发送时间: 2015年3月24日 17:09
收件人: Ku
Hi David E.Ross,
I am not so sure the if you could receive the mail from MCS, so I attached
their response as following,
Hello Anyin,
It's really unfortunate to get such absolute incorrect and prejudiced
feedback
I sent the truth inside the requested report and i am ready to submit any
required
On 24/03/15 09:03, Kurt Roeckx wrote:
> 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?
The implied answer to this question from statements by the CNNIC
representative is that their syste
On 24/03/15 02:23, David E. Ross wrote:
> What assurance is there that the mis-issued certificates were not
> intentional.
All of the evidence we have seen does fit with the scenario as outlined
in the two blog posts. Of course, most of that evidence comes from CNNIC
(and MCS via CNNIC). But the
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?
Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.
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
those scans, broken down by T
On 24/03/15 00:00, Peter Bowen wrote:
> Is there any data on this intermediate?
>
> - Was it publicly disclosed as per Mozilla's unconstrained subordinate policy?
Kathleen would need to say to be certain, but my understanding is no.
> - Was it issued since their latest complete audit period ende
On 23/03/15 22:49, Jeremy Rowley wrote:
> Although CT would not have prevented issuance, requiring CT for all
> certificates would have detected the misissuance much sooner.
I'm not sure that's true. The intermediate itself would not count as a
misissuance. The Google cert the firewall created wo
Does any part of CNNIC's CPS cover issuing external subCAs at all? When did
CNNIC start issuing external subCAs?
I am afraid we don't have issuing external subCAs in CPS. This is the first
time we try to issueing an external subCAs just for testing propose.
We decided to discuss external SUBCAs a
On 03/23/15 22:47, Richard Barnes wrote:
> Dear dev.security.policy,
>
> It has been discovered that an intermediate CA under the CNNIC root has
> mis-issued certificates for some Google domains. Full details can be found
> in blog posts by Google [0] and Mozilla [1]. We would like to discuss wh
69 matches
Mail list logo
