Re: Root Certificates of USA CAs still trustworthy?

2013-10-17 Thread Gervase Markham
On 17/10/13 00:07, Phillip Hallam-Baker wrote: Each HSM vendor has their own security controls but a FIPS140 level 4 device won't release them except to another FIPS-140 device. There is no way to extract the key from the system unencrypted. Phil: what prevents a government just turning up

Re: Exceptions to 1024-bit cert revocation requirement

2013-12-11 Thread Gervase Markham
On 11/12/13 14:31, Kathleen Wilson wrote: There are a few cases where customers are asking CAs for more time to transition off of their 1024-bit certificates. What exactly are CAs asking for? Are they asking for permission to continue issuing such certs? Or are they asking for permission to not

Re: Revoking Trust in one ANSSI Certificate

2013-12-11 Thread Gervase Markham
On 10/12/13 06:20, Jan Schejbal wrote: The third sub-ca cert (Subject AC DGTPE Signature Authentification) includes a CRL DP for a CRL issued by sub-ca 2, validity 2011-09-09 to 2014-09-13. The CRL is empty. Look again. It seems that it now contains 1106 certificates (!), with widely varying

Re: DigiCert Request to Include Renewed Roots

2014-01-29 Thread Gervase Markham
On 29/01/14 05:08, Brian Smith wrote: Benefits of my counter-proposal: 1. Fewer roots for us to manage. Only for a very narrow definition of the word root. There's the same number of embedded trust anchor points. 3. Because of #1, there is potential for us to design a simpler root

Re: No CRL UI as of Firefox 24

2014-03-14 Thread Gervase Markham
On 13/03/14 19:20, Rick Andrews wrote: Since support for CRLs has been removed from Firefox, why does Mozilla's root policy (http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/maintenance/) require CAs to maintain and publish CRLs? Is it because Mozilla

Re: Revocation Policy

2014-04-29 Thread Gervase Markham
On 29/04/14 00:16, Kathleen Wilson wrote: My personal opinion… And mine: Free-at-the-point-of-issuance certs have been a great thing for the Internet, and I would be very sad to see them go away. I also think in general that the charging structures of (non-insurance :-) business models are best

Re: DRAFT: May CA Communication

2014-04-29 Thread Gervase Markham
On 28/04/14 20:04, Kathleen Wilson wrote: Please respond with one of the following: A) Mozilla’s spreadsheet of included root certificates has the correct link to our most recent audit statement, and the audit statement date is correct. B) Here is the most recent audit statement for our

Re: Revocation Policy

2014-04-30 Thread Gervase Markham
On 29/04/14 15:31, Jan Lühr wrote: I'd like to live in a world, were revocation is without any hassle an Community Driven CAs like CAcert are providing security for sites to be interested in. That sounds to me like: I'd like to live in a world where whatever costs there are for having a

Re: DRAFT: May CA Communication

2014-04-30 Thread Gervase Markham
On 30/04/14 00:24, Kathleen Wilson wrote: On 4/29/14, 3:44 AM, Gervase Markham wrote: Does the list on that wiki page need to include the Microsoft equivalent of the SGC EKU? Or are we not mentioning that? Yes, it's item #1 in the Things for CAs to Fix section. Item #1 refers to Netscape

Re: DRAFT: May CA Communication

2014-05-05 Thread Gervase Markham
On 01/05/14 17:55, Kathleen Wilson wrote: Do we need to _stop_ people using this OID, or is it sufficient to merely start to require that people use the correct one (Server Auth)? We want people to stop using the obsolete Netscape SGC OID. Why is it not sufficient to require people to use

Re: DRAFT: May CA Communication

2014-05-09 Thread Gervase Markham
On 09/05/14 01:13, Brian Smith wrote: We can *try* doing it for *end-entity* certificates. However: All good points. And I think doing it for EE certs gives us the safety we require. So let's not try for intermediates. Gerv ___ dev-security-policy

Re: EKUs covered in the Mozilla CA Program

2014-05-13 Thread Gervase Markham
On 13/05/14 03:22, Peter Bowen wrote: Is there a list of Extended Key Usages that are within scope for the Mozilla CA Program? I hope I can get this right... I believe the answer is: We'd like it to be the case that only serverAuth, and whatever the email EKU is, are in scope, and all certs

Re: [SPAM] Re: EKUs covered in the Mozilla CA Program

2014-05-14 Thread Gervase Markham
On 13/05/14 14:48, Peter Bowen wrote: I would add the old Netscape Step-Up/SGC (2.16.840.1.113730.4.1) and any EKU (2.5.29.37.0) to the list as well. The point of the bug I reference is that we'd like to stop caring about these (in code), because allowing anyEKU means that we include in scope

Re: OpenSSL Vulnerability

2014-06-10 Thread Gervase Markham
On 05/06/14 19:39, David E. Ross wrote: Does NSS use any code in common with OpenSSL? Not to my knowledge, but others are far more expert than me. Is any part of OpenSSL used in any Mozilla applications? Firefox OS ships (or used to ship) OpenSSL as part of its wifi stack. And of course

Re: Only accepting 2048 bit or better certificates

2014-06-23 Thread Gervase Markham
On 21/06/14 17:15, Kurt Roeckx wrote: There are still a few new certificates generated with 1024 bits. I've been filing bugs about those and there were only a few so far this month. Thank you for doing this work; it really is appreciated. Gerv

Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

2014-07-23 Thread Gervase Markham
On 23/07/14 10:06, nick.l...@lugatech.com wrote: The status quo today means that it is not possible to discriminate programatically between a DV and OV certificate in a standardized, reliable way. This is because Mozilla's position is that, in security terms, there is no relevant difference.

Re: Proposal: Advocate to get Section 9.3.1 (Reserved Certificate Policy Identifiers) made mandatory.

2014-07-23 Thread Gervase Markham
On 23/07/14 14:18, nick.l...@lugatech.com wrote: Clearly EV is very much the gold standard, but I there is a relevant general difference between EV and DV even if not a security one. It would be nice if Firefox could state that the certificate was DV or EV in a neutral way without making /

Re: New wiki page on certificate revocation plans

2014-08-04 Thread Gervase Markham
I am generally in favour of this plan - I think it's the right way to go. I am not sure we will ever get to hard-fail for plain OCSP, but I am very happy for that to be a data-driven decision somewhere down the line. On 01/08/14 03:07, Richard Barnes wrote: There's one major open issue

Re: New wiki page on certificate revocation plans

2014-08-04 Thread Gervase Markham
On 02/08/14 15:20, Jesper Kristensen wrote: * Have you considered adding support for multiple ocsp staples to allow stapeling of CA certs? There is a proposed standard for multi-stapling but as far as I remember it's not even finished yet, yet alone implemented and deployed. We decided that we

Re: New wiki page on certificate revocation plans

2014-08-05 Thread Gervase Markham
On 04/08/14 18:16, Erwann Abalea wrote: I imagine you have access to more detailed information (OCSP URL, date/time, user location, ...), could some of it be open? Not necessarily; I suspect this data was gathered using Firefox Telemetry, where we try very hard to avoid violating a user's

Re: Proposal: Switch generic icon to negative feedback for non-https sites

2014-08-11 Thread Gervase Markham
On 11/08/14 04:16, David E. Ross wrote: Rosenthal is also a reseller of X.509 subscriber certificates, which should mean he understands Internet security. Otherwise, how is he allowed to sell such certificates? I don't often say this, because it's not often true, but... LOL. Gerv

Short-lived certs

2014-09-04 Thread Gervase Markham
Short-lived certs are one plank of our future revocation strategy.[0] Currently, it is not permitted by the CAB Forum Baseline Requirements to revocation pointers out of a cert, ever. However, this is part of the big value of short-lived certs, as it's what unlocks their speed-increasing potential

Re: Short-lived certs

2014-09-04 Thread Gervase Markham
On 04/09/14 12:52, Hubert Kario wrote: It all depends on the exact definition of short-lived. If the definition is basically the same as for OCSP responses or shorter, then yes, they provide the same security as regular certs with hard fail for OCSP querying/stapling. The exact definition of

Re: Short-lived certs

2014-09-05 Thread Gervase Markham
On 04/09/14 14:14, Hubert Kario wrote: From what I heard (and my limited personal experience matches), is that the vast majority of clients not only completely ignore failures in OCSP retrieval (soft-fail) but completely lack any mechanism for revocation checking (be it OCSP or CRL). I

Re: Short-lived certs

2014-09-05 Thread Gervase Markham
On 04/09/14 14:18, Rob Stradling wrote: Today, if an end-entity cert contains no AIA-OCSP URL and the server sends no stapled OCSP response, it's a violation of the BRs. I wonder if any clients out there would reject the cert in this situation? (I suspect not, but it's something to watch out

Re: Short-lived certs

2014-09-05 Thread Gervase Markham
On 04/09/14 14:25, Rob Stradling wrote: When attempting to access an HTTPS site with an expired cert on Firefox 32, you'll see a This Connection is Untrusted page that lets you add an exception and proceed. But when attempting to access an HTTPS site with a revoked cert, you'll see Secure

Re: Short-lived certs

2014-09-05 Thread Gervase Markham
On 04/09/14 19:20, Phillip Hallam-Baker wrote: 1) Any new scheme has to work equally well with legacy browsers and enabled browsers. Yes; I think short-lived certs meet that criterion. 2) Ditto for legacy servers and this is actually a harder problem as upgrading a server can force a

Re: Short-lived certs

2014-09-05 Thread Gervase Markham
On 05/09/14 00:06, Brian Smith wrote: Precisely defining a short-lived certificate is a prerequisite for a proper discussion of policy for short-lived certificates. It seems likely to me that short-lived certificates will be defined as certificates that would expire before the

Re: Short-lived certs

2014-09-05 Thread Gervase Markham
On 04/09/14 19:32, fhw...@gmail.com wrote: Could you (or anyone) elaborate a bit on the use cases where short lived certs are desirable? See other messages in this thread - it saves a significant amount of setup time not to have to wait for a response from the OCSP server. I'm also wondering

Re: Short-lived certs

2014-09-05 Thread Gervase Markham
On 05/09/14 10:47, Rob Stradling wrote: Unless the recently expired cert is found to be revoked, in which case you'd show Secure Connection Failed I presume? Yes :-) but after that we switch to Secure Connection Failed. What do you think of that idea? If the false positive rate drops to

Re: Short-lived certs

2014-09-09 Thread Gervase Markham
On 07/09/14 10:25, Jesper Kristensen wrote: However a stapled OCSP-response is not fully equivalent to an actively requested OCSP-response. A client may choose to not support stapling and always actively request an OCSP-response, if it believes this to be more secure. By allowing a short-lived

Re: Short-lived certs

2014-09-17 Thread Gervase Markham
On 16/09/14 23:13, Richard Barnes wrote: From a browser perspective, I don't care at all whether certificates excused from containing revocation URLs if they're sufficiently short lived. From a technical perspective, that is true. However, if we have an interest in making short-lived certs a

Re: Short-lived certs

2014-09-22 Thread Gervase Markham
On 17/09/14 08:34, Kurt Roeckx wrote: A browser could perfectly reject a certificate that doesn't comply with the BR because the required OCSP URI is missing. It could. If such browsers existed, I agree it would have a negative effect on the likelihood of success of a short-lived certs plan.

Re: Client certs

2014-09-25 Thread Gervase Markham
On 25/09/14 13:43, Steve Roylance wrote: You can encrypt communications if you have a public/private key pair You can; although most often that's provided by the server in the model of computing most prevalent on the web today. You can digitally sign (with the full support of digital

Re: Client certs

2014-09-25 Thread Gervase Markham
On 25/09/14 13:45, Michał Purzyński wrote: In order to leak the private cert you need to compromise the host. Leaking the password is easier - you can compromise the web application, the target server, the target company or the client’s machine. You have a few more attack vectors with

Re: Client certs

2014-09-25 Thread Gervase Markham
On 25/09/14 13:53, Kurt Roeckx wrote: On 2014-09-25 14:29, Gervase Markham wrote: A question which occurred to me, and I thought I'd put before an audience of the wise: * What advantages, if any, do client certs have over number-sequence widgets such as e.g. the HSBC Secure Key, used

Re: Client certs

2014-09-26 Thread Gervase Markham
On 25/09/14 17:53, Robin Alden wrote: I can send out a million client certificates for negligible cost. Good point. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org

Re: Client certs

2014-09-26 Thread Gervase Markham
On 25/09/14 22:33, Matt Palmer wrote: * Client certs can be invisibly stolen if a machine is compromised Well, the cert is quasi-public information, so it doesn't matter if they get stolen, invisibly or otherwise. The private key, on the other hand... grin But at any rate, just stick the

China MITMing icloud.com

2014-10-21 Thread Gervase Markham
https://en.greatfire.org/blog/2014/oct/china-collecting-apple-icloud-data-attack-coincides-launch-new-iphone Cert is here: http://www.mediafire.com/download/ampbnqncc277krv/fakeicloudcert.zip I'd be very interested to know why (as reported) the Qihoo 360 browser doesn't throw an error for this

Re: Updating Peers of Mozilla's CA Certificates and CA Certificate Policy modules

2015-02-16 Thread Gervase Markham
On 06/02/15 21:37, Kathleen Wilson wrote: How do you all feel about the idea of one (or more) of the representatives of the CAs in Mozilla's program also being a Peer of the CA Certificates module? I second Jeremy's point; it seems unwise to me for someone in a formal relationship with a CA to

Re: Name Constraints

2015-03-19 Thread Gervase Markham
On 12/03/15 22:54, Peter Kurrasch wrote: This backwards compatibility problem is a fatal flaw, but I have an alternative in mind: establish and enforce boundaries within the intermediates. The browser can enforce a policy that a technical constraint be specified somewhere between the root and

Re: Name Constraints

2015-03-24 Thread Gervase Markham
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 (in

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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 in that list? How

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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 rewrite), but it's not

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Gervase Markham
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

Re: Name Constraints

2015-03-24 Thread Gervase Markham
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 should

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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 those scans, broken down by

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Gervase Markham
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

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Gervase Markham
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 system

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Gervase Markham
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 in

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Gervase Markham
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 we

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

2015-03-25 Thread 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 to CNNIC expired in 2012

Re: 答复: Consequences of mis-issuance under CNNIC

2015-03-25 Thread Gervase Markham
On 25/03/15 17:45, Ryan Sleevi wrote: That is, in a hypothetical world where E1 is pursued (for any CA), the CA can simply backdate the certificate. They'd be non-compliant with the Baseline Requirements, presumably, but that is somewhat how we got here in the first place. So purely on a

Re: Name Constraints

2015-03-26 Thread Gervase Markham
On 26/03/15 03:59, Peter Kurrasch wrote: Perhaps I chose my words poorly because my intention actually was to avoid having to pass judgment at all. Instead of saying to a CA we don't trust you enough, please constrain I was hoping for something along the lines of everybody is asked to

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread Gervase Markham
On 27/03/15 19:09, Peter Kurrasch wrote: 1) Mozilla could refuse to validate any intermediate cert which CNNIC has issued to a subordinate CA. (Note: I'm not sure that's the technically precise term here.) Basically, CNNIC may issue intermediates for itself but those paths going outside their

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread Gervase Markham
On 30/03/15 16:34, Richard Barnes wrote: Adding the intermediates would allow CNNIC to continue to issue end-entity certificates, and not penalize site owners immediately (as Peter notes). However, it would prevent the acceptance of other intermediates, since the improper issuance of

Re: Consequences of mis-issuance under CNNIC

2015-03-31 Thread Gervase Markham
On 31/03/15 02:34, Peter Gutmann wrote: So this is now a convenient excuse to kick out CNNIC, after the initial attempts to not let them in in the first place failed. I've always wondered, what do people have against CNNIC and Turktrust in particular? I haven't seen anyone in this thread

Re: 答复: 答复: Consequences of mis-issuance under CNNIC

2015-03-27 Thread Gervase Markham
On 27/03/15 06:41, Man Ho (Certizen) wrote: Yeah, if this device is designed to issue certificates automatically. Why does it have this feature? The answer is obviously for traffic monitoring. But then why Paloalto would develop such problematic feature which violate security principle? If it

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread Gervase Markham
On 30/03/15 16:34, Richard Barnes wrote: After some further thought on this issue, I would like to propose the following course of action: 1. Remove the CNNIC root certificates 2. (possibly) Temporarily add the CNNIC intermediate certificates After consideration, I want to record two

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Gervase Markham
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

Re: Name Constraints

2015-03-25 Thread Gervase Markham
On 24/03/15 21:12, Peter Kurrasch wrote: As to who should be forced to constrain, this is controversial. I would argue that everyone should be forced, but that has certain problems. One can argue that only government-run and certain other CA's should be forced but then we are put in the

Re: address prefixes allowed for domain control validation

2015-03-23 Thread Gervase Markham
On 22/03/15 23:18, Kathleen Wilson wrote: I'm thinking we need to update our wiki page: https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs Well, the current list is in the BRs, so we either need to update the BRs, or we need to decide that we want to be more

Re: Name Constraints

2015-03-26 Thread Gervase Markham
On 26/03/15 13:18, Peter Kurrasch wrote: So, how much work does Mozilla feel like doing? You know my views; other Mozilla people will have to speak for themselves. And then we'll have an argument to see whose view prevails :-) However, this dialogue was very useful in exploring some of the

Re: address prefixes allowed for domain control validation

2015-03-23 Thread Gervase Markham
On 23/03/15 16:41, Robin Alden wrote: That would be nice! Wouldn't it? :-) Of all email-based domain control validation we perform those email addresses (on the same domain being applied for) are used as follows: admin@33.9% hostmaster@ 7.8% webmaster@

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Gervase Markham
Hi Matt, On 01/04/15 23:44, Matt Palmer wrote: I'd like to see discussion of what happens if things *don't* go according to plan, though. The plan relies quite a bit on CNNIC's cooperation, both to provide the list of existing certificates, as well as making (and abiding by) the undertaking

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Gervase Markham
On 02/04/15 02:42, Reed Loden wrote: From http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html Indeed. It seems that Google have independently come to very similar conclusions to us. Gerv ___

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Gervase Markham
On 01/04/15 22:41, Richard Barnes wrote: That's certainly an option. I didn't want to prescribe a specific mechanism in my initial proposal, since this seemed like an implementation detail. In principle, just a list of issuer/serial pairs would be sufficient to recognize bad certs, if CNNIC

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Gervase Markham
On 02/04/15 19:33, Daniel Micay wrote: Is there really a way we could notice this? Other than a leak from an employee at CNNIC... To be used, certs generally have to be public. Which means people can find them. And compare them to lists. We may end up coding the whitelist into Firefox, we may

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Gervase Markham
On 02/04/15 09:49, c.le...@gmail.com wrote: China has a enormous internet population and enormous number of websites. Yes CNNIC acted like a dangerous kid. But you really think making all Chinese unable to do any online transaction is the solution we want to push? Our plan will not have that

Re: Requirements for CNNIC re-application

2015-04-13 Thread Gervase Markham
On 11/04/15 01:05, Brian Smith wrote: If a US-based CA were in a similar situation, would we consider name constraining them to *.com, *.org, *.net, *.us? If it were a US government CA, we could certainly constrain to .gov and .mil. No, because that's not much of a constraint. For people

Re: Policy about root cert transfers

2015-04-24 Thread Gervase Markham
On 24/04/15 08:17, Man Ho (Certizen) wrote: The term transfer a root certificate is new to me. What are the rationale of such transferal? Move from one location to another location, or from one HSM to another HSM? Ownership of the CA had changed from one organization to another organization?

Re: DRAFT of next CA Communication

2015-04-30 Thread Gervase Markham
On 29/04/15 17:23, Kathleen Wilson wrote: I will appreciate your feedback on the email and the survey (use link below). All looks good to me. Although it's a shame Salesforce seems not to be able to embed links. Gerv ___ dev-security-policy mailing

Re: DRAFT of next CA Communication

2015-05-06 Thread Gervase Markham
On 05/05/15 21:54, Kathleen Wilson wrote: EXAMPLE/DRAFT Survey Link: https://community-mozillacaprogram.cs21.force.com/Communications/TakeSurvey?id=a04q004jpXoAAIcId=caId=none LGTM. Gerv ___ dev-security-policy mailing list

Re: Name-constraining government CAs, or not

2015-05-15 Thread Gervase Markham
On 15/05/15 00:01, Ryan Sleevi wrote: On Thu, May 14, 2015 9:02 am, David E. Ross wrote: With cyberwarfare constantly discussed in the news, U.S. Congress, and other venues, it appears to me that government CAs should indeed be restricted to the TLDs of their respective jurisdictions.

Re: Name-constraining government CAs, or not

2015-05-15 Thread Gervase Markham
On 14/05/15 17:02, David E. Ross wrote: There is an ongoing dispute between the U.S. and China whether the government in China is behind attacks on both government and commercial computer systems in the U.S. This is NOT to question the trustworthiness of the government of China but to give

Name-constraining government CAs, or not

2015-05-14 Thread Gervase Markham
Hi everyone, The topic of name-constraining government CAs, probably to the TLD(s) of their territory(ies), has come up numerous times. I'd like to try and hash out, once and for all, whether we think this is actually a good idea, so we can decide to work towards doing it, or decide actively not

Re: Name-constraining government CAs, or not

2015-05-18 Thread Gervase Markham
On 17/05/15 23:28, Peter Bowen wrote: I'll bite. What if Mozilla puts a simple rule in place? All CAs must either: - Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a assessor who meets the requirements of BR 8.2 or - Be named constrained The result of that would be

Re: Name-constraining government CAs, or not

2015-05-18 Thread Gervase Markham
On 18/05/15 11:26, Kurt Roeckx wrote: I think it only makes sense to name constrain a government CA if the name constrained only covers government websites, and not all websites in the country. Examples would be covering *.gov and *.go.jp. I think that restricting them to *.jp, *.in, *.cn

Re: Name-constraining government CAs, or not

2015-05-18 Thread Gervase Markham
On 17/05/15 02:12, Ryan Sleevi wrote: I say this because knowing Gerv, and having participated with him on the call, I suspect that in part this is motivated by https://cabforum.org/2015/04/16/2015-04-16-minutes/ , in which Microsoft has suggested they'll require government CAs (definition not

Re: Name-constraining government CAs, or not

2015-05-18 Thread Gervase Markham
On 17/05/15 00:45, Eric Mill wrote: Governments are not subject to the same kind of leverage, accountability or market forces that corporations are. The legal constraints they operate under are different, your likelihood of prevailing in a legal action against them is different (and highly

Re: Name-constraining government CAs, or not

2015-05-18 Thread Gervase Markham
On 18/05/15 14:45, Gervase Markham wrote: On 17/05/15 23:28, Peter Bowen wrote: I'll bite. What if Mozilla puts a simple rule in place? All CAs must either: - Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a assessor who meets the requirements of BR 8.2 or - Be named

Re: Name-constraining government CAs, or not

2015-05-18 Thread Gervase Markham
Before I reply, can I say that this level of informed and considered debate is _exactly_ what I was looking for? Thanks to everyone who has participated so far. On 15/05/15 19:49, Ryan Sleevi wrote: - By introducing a demarcation of power/privilege by government or not (which still suffers from

Re: Name-constraining government CAs, or not

2015-05-19 Thread Gervase Markham
On 19/05/15 02:15, Matt Palmer wrote: I disagree that we, the browsers and standards bodies of the Internet have very different leverage. In either case, if a CA misbehaves, their root certs can be pulled from the trust store (or otherwise neutered). That doesn't change because the CA is run

Re: Name-constraining government CAs, or not

2015-05-19 Thread Gervase Markham
On 18/05/15 17:39, Kurt Roeckx wrote: On the other hand, if it covers the whole country, they can abuse it for domains in that country, but not for other domains. I'm not sure why you would find it acceptable that they can abuse it in their own country. Some countries, AIUI, do not have an

Re: DRAFT of next CA Communication

2015-04-13 Thread Gervase Markham
On 09/04/15 21:12, yuhongbao_...@hotmail.com wrote: What about Mozilla's own aus3.mozilla.org certificate for which the SHA-1 intermediate was pinned? I'm afraid I don't understand the question, or how it relates to the CA Communication. Can you clarify? Gerv

Re: Requirements for CNNIC re-application

2015-04-09 Thread Gervase Markham
On 08/04/15 01:31, Richard Barnes wrote: decides to require of them. The purpose of this thread is to discuss what additional steps, if any, we should require. CNNIC has already provided Mozilla with a list of certificates issued before 1 Apr 2015. We are working on publishing this list.

Re: Requirements for CNNIC re-application

2015-04-14 Thread Gervase Markham
On 14/04/15 00:15, Peter Kurrasch wrote: Let's use an example. Suppose CNNIC issues a cert for whitehouse[dot]gov presumably without permission ;-)... and let's further suppose that CNNIC includes this cert in the CT data since they have agreed to do that. What happens next? If no-one

Re: Requirements for CNNIC re-application

2015-04-14 Thread Gervase Markham
On 14/04/15 01:19, Matt Palmer wrote: I'm not a fan of browser-imposed name constraints on CAs, at a philosophical level. An important principle of the Mozilla root program, IMO, is that it works for the public good (insofar as the public is represented by users of Mozilla products). A name

Re: Consequences of mis-issuance under CNNIC

2015-04-06 Thread Gervase Markham
On 05/04/15 13:12, Erwann Abalea wrote: It would be very helpful if you could provide some evidence of this. Qihoo 360 is a browser member of the CABForum, the product treats certificate validation errors differently than other browsers, in a non secure way. But having additional certificates

Re: Consequences of mis-issuance under CNNIC

2015-04-06 Thread Gervase Markham
On 03/04/15 01:46, Matt Palmer wrote: On the other hand, CNNIC's blog post suggests that they haven't. There's some serious cognitive dissonance going on here. Just to close this loop: CNNIC have now supplied us with a ZIP file of all their currently-valid issued certificates. Given that

Re: Are CAs required to update their CPS annually

2015-04-06 Thread Gervase Markham
On 04/04/15 04:20, Eugene wrote: According to the CA Baseline Requirements section 8.2.1, The CA SHALL develop, implement, enforce, and **annually update** a Certificate Policy and/or Certification Practice Statement that describes in detail how the CA implements the latest version of these

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Gervase Markham
On 02/04/15 12:42, Sebastian Wiesinger wrote: the plan would be to continue allowing current certificats (perhaps with some sort of whitelist) while not accepting new certificates. Could you ask Google to share their whitelist? Until they announced, we were not aware that Google would be

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

2015-06-19 Thread Gervase Markham
On 17/06/15 22:50, Brian Smith wrote: By small scope, I'm referring to CAs who limit their scope to a certain geographical region, language, or type of institution. I'm not sure how that neuters my objection. CAs who do more than DV will need to have local infrastructure in place for identity

Re: Requirements for CNNIC re-application

2015-06-11 Thread Gervase Markham
On 30/05/15 20:20, Brian Smith wrote: By the way, what is Firefox's market share in China and other places that commonly use CNNIC-issued certificates? My understanding is that it is close to 0%. That's why it was relatively easy to remove them in the first place. It also means that there's no

Re: Requirements for CNNIC re-application

2015-06-11 Thread Gervase Markham
On 28/05/15 23:07, Richard Barnes wrote: I agree that if CNNIC is to reapply, it should be with a new root. It creates a clean break between the past and the future. It clarifies that the new audits that are required apply to the new thing, and that the old thing is dead. It's marginally

Re: CA scope transparency (was Re: Name-constraining government CAs, or not)

2015-06-11 Thread Gervase Markham
On 06/06/15 02:12, Brian Smith wrote: Richard Barnes rbar...@mozilla.com wrote: Small CAs are a bad risk/reward trade-off. Why do CAs with small scope even get added to Mozilla's root program in the first place? Why not just say your scope is too limited to be worthwhile for us to

Re: Requirements for CNNIC re-application

2015-06-11 Thread Gervase Markham
On 28/05/15 00:32, Peter Kurrasch wrote: I think this is the crux of the problem: how do we want to treat all the existing certs which chain to this root? That's not the only problem. Requiring CNNIC to apply with a new root would also require them to go through the inclusion process again in

Re: Name-constraining government CAs, or not

2015-06-11 Thread Gervase Markham
On 31/05/15 23:43, Ryan Sleevi wrote: I agree, this is the strongest argument against government CAs presented in this thread, and I wish this, rather than the musings of secret courts and maybe impossibles, was the core of your argument. These arguments apply not just to government CAs

Re: Publicly disclosed and audited policy

2015-06-17 Thread Gervase Markham
On 16/06/15 02:54, Peter Bowen wrote: First, the policy says All disclosure MUST be made freely available and without additional requirements, including, but not limited to, registration, legal agreements, or restrictions on redistribution of the certificates in whole or in part. If I read

Re: Requirements for CNNIC re-application

2015-05-27 Thread Gervase Markham
On 26/05/15 22:26, Kathleen Wilson wrote: But this raises the question of whether their re-application can be for the same (currently-included) root certificates, or if it has to be for a new root certificate. In other words, should we consider taking the stance that we will require a new root

  1   2   3   4   5   6   7   8   9   >