Re: StartCom & Qihoo Incidents
On 10/14/2016 01:00 PM, Gervase Markham wrote: K) StartCom impersonating mozilla.com. https://bugzilla.mozilla.org/show_bug.cgi?id=471702 StartCom's (former) CEO Eddy Nigg obtained a key and certificate for www.mozilla.com and placed it on an Internet-facing server. I do consider it a significant error of judgement for Eddy to have chosen www.mozilla.com, rather than a site owned and controlled by him or by a third party with whom he had an agreement, for his demonstration. Well, at time I didn't think that much - I noticed it when requesting a certificate for startcom.org in order to investigate a completely different issue and later got one for mozilla.org (note it wasn't .com). Initially I thought about some really high-profile name, but then I tried with mozilla.org since I assumed that A) Mozilla will forgive me and B) I was frequently involved here at that time. :-) Surprisingly it worked and I got my certificate for mozilla.org On the other hand, this happened 8 years ago. I'd be interested in your comments, Ryan, on whether you think it's appropriate for us to have some sort of informal "statute of limitations". That is to say, in earlier messages you were worried about favouring incumbents. But if there is no such statute, doesn't that disadvantage incumbents? No code is bug-free, and so a large CA with many products is going to have occasional troubles over the years. If they then have a larger issue, is it reasonable to go trawling back 10 years through the archives and pull out every problem there's ever been? This is a genuine question, not a rhetorical one. I believe there is also something called "reasonability " - I believe during my tenure StartCom tried to reduce risks first and foremost through its policies, honestly and earnest. And then unintentional mistakes and issues can happen Of course every CA wants to issue hundreds of thousands of certificates, but it usually doesn't start like this. I admit that some of the issues were due to growth pain, scalability or simply doesn't happen below a certain number of users/certificates. Any programmer working on larger scale projects and long enough in the profession can tell some stories about bugs that happen only every 50K or 50M time. I don't want to offer cheap excuses, but reality has it that things do happen and this is also part of that "reasonability". CAs must however have policies and procedures in order to evaluate issues that do happen, make the correct assessment and deliver a reasonable solution based thereof. This is the logic of a correctly functioning CA (or other businesses for that matter), this is what auditors verify and what software vendors should expect. There is no business, no software and no certificate authority without fault - realistically and reasonably. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartCom & Qihoo Incidents
On 10/12/2016 10:11 PM, Ryan Sleevi wrote: As Gerv suggested this was the official call for incidents with respect to StartCom, it seems appropriate to start a new thread. Ryan, it was probably easy to dig up any possible claimed or proven issue ever surrounding StartCom during its ~ 10 years of operation. But if this is your level of measurement for remaining in a root store, than you have probably some other and larger CAs that would require your immediate attention more urgently Incidents with StartCom: As most issues have been discussed and explained at that time, I'm not sure about it's usefulness to repeat the same arguments and explanations again. Most issues you are listing were mostly minor (but makes your list longer of course) and have been effectively and properly dealt with. K) StartCom impersonating mozilla.com. https://bugzilla.mozilla.org/show_bug.cgi?id=471702 StartCom's (former) CEO Eddy Nigg obtained a key and certificate for www.mozilla.com and placed it on an Internet-facing server. You make this appear as if StartCom used its capacity as a certificate authority to somehow abuse somebody or something, but for the wider audience: I was able to obtain a certificate for mozilla.org from Comodo without having the authority to validate said domain name - in fact I could have obtained also wild cards and many more certificates for any domain name would I have been willing to pay for it. I installed the certificate at a local server as a proof in the same fashion millions of web sites install theirs. The private key has never published to any third party and was eventually destroyed. Interesting that you are using it to shoot the messenger from back then and list this as an item against StartCom :-) I hope the above show that the odds are if the original StartCom systems are restored, we're likely to continue to have significant BR violations - a pattern StartCom has repeatedly demonstrated over several years. There is no plan to use software that doesn't comply to the various requirements and it has never been. I'm not claiming that there have been zero issues during the last ten years, but StartCom has had always clear policies and practices in place about how to deal with an issue reasonably according to its significance, seriousness and importance. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign: updated report and discussion
On 10/11/2016 11:57 AM, Gervase Markham wrote: There is also the case of StartEncrypt. While no known cert-to-wrong-person misissuance occurred because the researchers in question used domains they already controlled to prove their point, but there seemed to be multiple holes by which this might be possible. I haven't forgotten it and mentioned that Inigo has several tasks at hand: "/... he'll have to review also other areas and implement controls in case they were lacking or insufficient, something he's doing as we speak/" This includes obviously development cycles and other areas, even if no issues have been detected or reported. Of course, people can reasonably disagree on the seriousness of the issue (standalone, and by comparison with e.g. WoSign issue N), and it is true that StartCom took this codebase wholesale from WoSign, but it seems incomplete to leave this out entirely. It wasn't my intention to ignore it, but I understand that this issue has been quickly contained at that time. Eddy: does StartCom currently have any fully-automated certificate issuance mechanisms, or does every certificate request pass by human eyes before issuance? Generally speaking it's semi-automated with a flagging system that forces about 20% of all lower level certificates for a manual review and approval by the verification team. Of course EV and code signing certificates are issued only manually. The rest is issued automatically. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign: updated report and discussion
Hi Kathleen, On 10/10/2016 09:39 PM, Kathleen Wilson wrote: I would like to remind everyone that when making decisions about what to do about CA mis-issuance, it is expressly *not* a goal for me to mete out punishment. Rather, my primary goal is to help keep end-users safe, based on the information that is available. Allow me to add some of my thoughts into the discussion. I've read most of the comments and arguments made here so far and assume that most participants have the relevant information so that I don't have to repeat them again I was directly responsible for StartCom for many years and gained some experience in running a certificate authority, writing policies and implementations thereof. I've helped to draft important guidelines and requirements for CAs and in general learned about the mesh of software vendors, certificate authorities and (web) PKI. I'm probably one of the faces of this industry and would offer my two cents in this capacity hereby The problematic issue in relation to StartCom is obviously the _two backdated SHA1 certificates_ - however from the strictly technical point of view I don't think that the user-base of Mozilla in general and the relying parties in particular were much more at risk than relying on any other SHA1 certificate that was obtained legitimately before the 1st of January 2016. The risks were probably minimal since the certificate properties besides that were validated correctly. However, a completely different matter must be considered here - that of compliance to the requirements set forth by the relevant bodies and software vendors. Besides the _loss of trust_ in this particular case, non-compliance happens many times due to _insufficient controls_. Being it either that the requirements weren't correctly understood (not the case here), or insufficient controls to prevent such non-compliance and wrongful certificate issuance. The remediation and corrections StartCom proposed are significant in this respect - basically Mr. Richard Wang has been removed from his position and unfortunately for him is paying a high price for overstepping his authority. The parent company (WoSign) too has been released of all its responsibilities and a full separation has been set into motion. The choice of Inigo Barreira as the new CEO of StartCom is probably a good one and we all assume that he wouldn't approve the backdating of certificates judging from his long-time recordhowever one of the immediate tasks of Inigo will be to implement controls that will make such abuse impossible - not by him and not by anybody else. I believe this is the _core issue and remediation_ here, which was the failure in first place. (Obviously he'll have to review also other areas and implement controls in case they were lacking or insufficient, something he's doing as we speak). But by looking at StartCom's performance besides that, I believe that some of the voices and arguments haven't been reasonable during this discussion! Was there a CA certificate compromise? Has StartCom lost control of its issuance processes? Has StartCom in general failed to validate certificate properties correctly? Has StartCom lost its ability to abide and comply to the policies and requirements set forth? Has and does StartCom present an undue risk to the user-base of Mozilla (and relying parties in general)? I believe that none of the above applies which would warrant such dramatic steps on part of the software vendors and StartCom is generally operating correctly. The particular failure that did happen can be dealt with properly, firmly and professionally as proposed; _without knocking StartCom out of business_. I believe StartCom is still an important part of today's SSL landscape and it shouldn't be in anybody's interest to remove it as a viable alternative to current mix of the established certificate authorities - except if somebody is looking for revenge or other personal matters -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom: next steps
On 10/07/2016 12:38 PM, Gervase Markham wrote: I am a little surprised it hasn't appeared by now. We did not agree a specific deadline, but my impression was that it would appear in a few days, which I mentally interpreted as "by the end of the week". Today is Friday, so there is still time for my vague expectations to be met :-) I'm sure Edward, Tan and Inigo are working on it furiously. Perhaps they can give a status update and an estimated time of publication? Hi Gerv, I'm sorry for the somewhat late reply due to holidays/weekends and flight connections of the participants of the meeting. First thanks for hosting the meeting and I'm sorry that I personally couldn't attend. WoSign already provided its incident report which includes basically most information regarding the various issues and failures. There were parts of the proposed steps mentioned already, hereby I'm trying to summarize it. Next week we'll add sub sections and dates to it: 1) Legal Structure - Separation of StartCom and Wosign's legal structure - StartCom reports directly to Qihoo 360. 2) Management / Board - Mr. Tan is appointed Chairman of StartCom, Inigo Barreira appointed CEO/Director of StartCom. 3) Team / Operations - Tan and Inigo work to separate StartCom and Wosign verification, development and management teams. Basically any previously shared functions (where they existed) will be separated. 4) System / Software - Any shared infrastructure will be separated from WoSign, current code base will be reviewed by Qihoo 360 and audited internally. StartCom makes the systems available for an external security audit as necessary. 5) All certificates past, present and future will be logged with CT compliant log servers. 6) Public Documentation - StartCom will present its near-term plan and update as it progresses. Item 6 is currently the outlined steps above, plus most specifications, sub steps, specific dates in particular for items 3 and 4. I assume that steps and promises StartCom commits to will be audible and/or easy to be confirmed. I assume that Inigo will report to the mailing list sometimes directly too in order to update on the progress. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom audit reports
On 09/23/2016 10:11 PM, Peter Bowen wrote: On Fri, Sep 23, 2016 at 10:46 AM, Eddy Nigg wrote: Speaking only for StartCom here, as far as I know and as per auditing standards, all intermediate CAs are audited (no external intermediates existed). As to network security, I believe this is part of the Baseline Requirements audit. But if necessary I can ask our auditors and also WebTrust directly if there is really missing something. I assume that all is included, covered and implied, but should a mistake have happened in the statements made by the auditors I'm sure we can get a corrected statement or explanation. I'm super happy that this was all checked. I know other auditors have re-issued opinion letters when they missed things unintentionally. Maybe you could ask EY to reissue to include the list of SubCAs and the full coverage. Traditionally the intermediate CA certificates were never listed explicit, at least in our audit reports. Intermediate CA certificates can change more frequently and I assume that's the reason for it. I don't like to bother them unnecessarily, but should Mozilla come to the conclusion that something was indeed missing, I'll go and get it from them. One other question on your report: It says the services were provided at Eilat, Israel during the period Jan 1, 2015 to Dec 31, 2015. Richard said in an email a few hours ago that the StartCom validation team was also in the UK. Did that team not spin up until January 2016 or later? The UK team was trained and started to work much later in 2016. Besides that some of the Israeli personnel is until this very date still in the UK overseeing the operation there. But what the audit concerns, this is not part of the 2015 report, that's correct. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: WoSign and StartCom audit reports
On 09/23/2016 05:53 AM, Peter Bowen wrote: Review of StartCom audit reports for the period 1 January 2015 to 31 December 2015 Good: - Uses AICPA standards - Uses current criteria versions Bad: - Only covers two roots, not subordinate CAs (true for all three reports: CA, BR, and EV) - Does not provide assurance that subordinate CA certificate requests are accurate, authenticated, and approved - Does not provide assurance that it meets the Network and Certificate System Security Requirements as set forth by the CA/Browser Forum Speaking only for StartCom here, as far as I know and as per auditing standards, all intermediate CAs are audited (no external intermediates existed). As to network security, I believe this is part of the Baseline Requirements audit. But if necessary I can ask our auditors and also WebTrust directly if there is really missing something. I assume that all is included, covered and implied, but should a mistake have happened in the statements made by the auditors I'm sure we can get a corrected statement or explanation. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
On 09/05/2016 10:54 AM, Gervase Markham wrote: Hi Eddy, On 04/09/16 09:51, Eddy Nigg wrote: I don't want to extend this discussion unnecessarily, but as a side note you don't know which agreements this employee has signed with StartCom and/or WoSign and hence you can't make a judgement on it either. Lets leave this to the professionals dealing with it. If he has signed an agreement with StartCom and/or WoSign which prevents him from pointing out, after leaving employment, facts which are in the public domain, then I suggest that those clauses in the agreement are an unconscionable[0] restriction on his freedoms and you should not be enforcing them. Again, I don't think we can and will solve this in public, however I believe it's the complete right of a company (and employer) to decide how and when it wants to make an official public announcement about its business (and being just in order to complete a currently ongoing transaction first). Not every employee is authorized to represent the company and inform third parties (at his/her convenient timing and consideration) even if he/she knows about it and/or some information has been placed into (partly) public domain as part of a business process. I hope my explanation makes it clear that this ex-employee was not authorized to provide any information about StartCom or WoSign. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Incidents involving the CA WoSign
On 09/04/2016 09:20 AM, Peter Gutmann wrote: Peter Bowen writes: It was brought to my attention that there is another incident. This is great stuff, it's like watching a rerun of Diginotar .says the audience on the backbenches gleefully but no, what are you talking about?? Even though some nasty and undesired errors happened here, its in no comparison to what happened at Diginotar which basically lost control over the CA. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 09/02/2016 07:02 PM, Nick Lamb wrote: On Friday, 2 September 2016 08:50:02 UTC+1, Eddy Nigg wrote: Lets speak about relying parties - how does this bug affect you? As a relying party I am entitled to assume that there is no more than one certificate signed by a particular issuer with a certain serial number. If I have seen this certificate and verified by whatever means I choose that it's OK, then I can safely assume that any time I see a certificate in the future signed by that issuer with that same serial number it's the same one, and skip the verification process. Well, according to the CA policies and relying party terms, you should always check with the CRL or OCSP responders if a certificate is considered valid or not. So the verification process shouldn't be skipped beyond the advertised refresh time (in CRLs/OCSP). Of course if you do some sort of certificate pinning based on serial and issuer, than this wouldn't work. But I'm not aware of any common software that doesn't use the certificate's public key for pinning and relies just on a serial numbers. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Incidents involving the CA WoSign
On 09/03/2016 11:02 PM, Percy wrote: I agree completely that we shouldn't imply fundamental guilt by association. However, WoSign threatened legal actions against Itzhak Daniel's disclosure compiled purely from public sources. I just want to make sure the disclosure was not buried after the content was taken down. I don't want to extend this discussion unnecessarily, but as a side note you don't know which agreements this employee has signed with StartCom and/or WoSign and hence you can't make a judgement on it either. Lets leave this to the professionals dealing with it. (Of course your copying and distributing of the content originally published by him can be also used against him, just some food for thought) As such, there can be many more things you don't really know regarding this or other business transactions. And probably this is the wrong forum for such matters in any case. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 09/02/2016 09:38 AM, Jakob Bohm wrote: 4. Violations that are purely technical but cannot actually endanger relying parties (such as issuing non-unique certificates to the correct entities, or issuing certificates with too early expiry dates). This would be the case with the StartCom serial number assignment bug. The way Eddy Nigg describes the issue, it appears there is some kind of low level race condition in the code or hardware that increments and uses the serial number counter deep inside the CA, perhaps in a heavily locked down HSM that prevents fixing the issue without generating a new CA key. You are pretty close If this is the case, and they correctly store the actually issued certificates with the wrong serial numbers, the main problem would be the inability to revoke one certificate without revoking the others, while a secondary problem could be relying parties rejecting the certificates if they actually see more than one of a set of conflicting ones within their local cache lifetime. Since both of those problems would be limited to the certificates not being trusted when the facts that should get them trusted are in place, there is no real danger. You nailed it - I just asked the question about how it affects relying parties in an other reply to the list, you answered already. StartCom is of cause one of those high speed DV CAs, that promise cheap DV issuance within minutes of the request being submitted. So preventing occasional non-dangerous (but obviously non-compliant) serial number collisions would require more than average skill by hardware, firmware and software engineers. True - and this was planned AND implemented. That said, they really, really should have set up an automated test script that scans issued certificates for the problem and raises an alarm so such certificates would be reissued (with distinct serial numbers) and revoked within a few days of each failure. True that we could have done what you suggested. I don't really recall why we didn't, though I think things got easier with CT today for similar issues. The fact is that it didn't had really an effect on the certificate holder or relying parties (except in case of a revocation in which case both certificates would have been revoked and probably issued again depending on the circumstances of the revocation). -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers
On 09/01/2016 01:29 PM, Peter Gutmann wrote: I also get the feeling that a lot of PKI software won't handle the revocation properly, because they're expecting to revoke *the* certificate, not the certificate, and the other certificate, and that other one there too, and that one in the corner, and ... . In other words I'm assuming most code will treat serial numbers as unique and assume the revocation acted on when the first cert has been marked as invalid. From my experience, once one of the certificates has been revoked, it's basically for all of them with the same serial and issuer. At the PKI all certificates with the same serial must be revoked however to get a unique serial order. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 09/01/2016 11:52 AM, Nick Lamb wrote: On Thursday, 1 September 2016 08:54:16 UTC+1, Eddy Nigg wrote: Not so, rather according to my assessment, the cost and everything it entailed (including other risks) to fix that particular issue outweighed the benefits for having it fixed within a time-frame shorter than that. It seems to me that was not your decision to make. The relying parties trust StartCom on the basis that it will do what it said it would do, not just whatever "in your assessment" offers most benefits to you. The only option that was permissible without seeking some exception was to cease issuance until the problem was repaired. First of all the issue can have been considered fixed due to machine test - evidence for some occurrences took month to resurface and at such low numbers that couldn't be reproduced (something almost required to fix a bug). I'm not sure if you or others here are programers, but knowing how things work and once we had evidence that there was still a very low occurrence, a plan was set up which included a different hardware and infrastructure. To StartCom, ceasing issuance feels like a really big risk, that is understood. But for the relying parties it's not. Lets speak about relying parties - how does this bug affect you? -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 09/01/2016 04:20 AM, Matt Palmer wrote: That sounds an awful lot like "we can't fix our own systems", which is a... terrifying thought. Not so, rather according to my assessment, the cost and everything it entailed (including other risks) to fix that particular issue outweighed the benefits for having it fixed within a time-frame shorter than that. "Some time" being about a year longer than you stated it would take in the bug. That's quite some time. If hardware changes and other infrastructural changes are involved than this time-frame can reasonable perhaps. CA infrastructures are usually not fast-moving ones according to my experience. This wasn't about changing a line or two in some software component. You were knowingly violating a MUST provision of RFC5280. From experience there have been many RFC violations, sometimes even knowingly and intentionally by software vendors (browsers), certificate authorities and even policy writers such as CAB Forum. Mozilla, Microsoft, Google and others are sometimes violating or not conforming to RFCs for this reason or the other. The implication and severity of such a violation matters probably. The audit letter included an attestation from Management that, during the time of the audit, management believed that the CA complied with the Baseline Requirements. True, we could demonstrate steps performed, plans produced, implementations performed etc. on this particular issue. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 08/31/2016 03:19 PM, Matt Palmer wrote: That bug appears to pre-date *all* of the certificates listed above. Further, the last communication on that bug (2014-09-22), from Eddy Nigg (of StartCom), said: It's a hard and software related capacity issue of the queue managing the certificates and the real solution will be only available after a hardware upgrade we are planning for Nov-Dec this year. So that's presumably Nov-Dec 2014... and 12 months later, duplicate serial numbers were still appearing. Right, however we could limit this occurrence to a minimum at that time - an entirely new infrastructure was in the pipeline already which solved the problem completely. Please note that such infrastructures are fairly complex and therefore also hard to deal with sometimes. I acknowledged in the bug report that we were able significantly reduce this issue, though not eliminate entirely. It's somewhat disconcerting that the response from StartCom in that bug report was, essentially, a mixture of, "it's not our fault, the software did it" and "ain't no thang". To me, that isn't a particularly useful attitude for a CA operator. The correctness of the software which is deployed is of *crucial* importance to the trustworthiness of a CA. True, but as explained above, some more drastic changes had to be done in order to correct this issue completely, not something done over night. The corrective measure and eventual implementation was however there on the way, even if it took some time. Regarding our "attitude", even though this issue was certainly not desired, it wasn't comparable to a wrongful issuance leading to possible abuse - some client software would however stopped working when encountering a duplicate serial. And to my assessment this wasn't a situation which required to take an entire system down in order to "fix" it (which was necessary in this case). Is anyone aware of any attempts by StartCom to proactively report these BR violations to Mozilla or any other trust store operator, at or around the time of issuance? I don't see any mention of the 2015 misissuances in the most recent BR audit report (https://startssl.com/ey-webtrust-br.pdf), either. Does this mean that StartCom were unaware that they had issued these duplicate certificates, despite having a history of doing so, or did they mislead their auditors? Neither - the software wasn't designed to issue certificates with duplicate serials, neither was that done knowingly or willfully. Since we are talking about an occurrence of perhaps one in 40-50 thousand certificates or less, it's not really something that can be measured by an auditor. What can be measured are software design, actions performed, implementation of plans to solve a particular issue. PS. it appears that most certificates mentioned originally have already expired, so there isn't much to revoke today except one. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Reuse of serial numbers by StartCom
On 08/31/2016 05:56 AM, Peter Bowen wrote: In reviewing the Certificate Transparency logs, I noticed the StartCom has issued multiple certificates with identical serial numbers and identical issuer names. https://crt.sh/?serial=14DCA8 (2014-12-07) https://crt.sh/?serial=04FF5D653668DB (2015-01-05) https://crt.sh/?serial=052D14BA553ED0 (2015-02-07) https://crt.sh/?serial=05B42A4FE11129 (2015-05-17) https://crt.sh/?serial=0615C666E8C56E (2015-08-05) https://crt.sh/?serial=0693A7FCC84DD3 (2015-11-10) Each of these serial numbers has two distinct certificates with no apparent relation between the subject entities. There were a couple of certificates which resulted in duplicate serials - this could happen under certain circumstances, a bug that has been fixed by now. We'll look into revoking and reissuing them. -- Regards Signer: Eddy Nigg, Founder StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartEncrypt considered harmful today
On 07/01/2016 05:54 PM, Patrick Figel wrote: Can you comment on how your backend checks would have prevented any misissuance? My understanding of the report is that this was not so much an issue with the client software, but rather an oversight in the protocol that allows Domain Validation checks that are not sufficient in assuring domain ownership, thus the issue was very much a backend issue. I assume there are reasonable controls in place to prevent misissuance for high-risk domains, but what about other domains? Would they have been affected by this? Hi Patrick, Depending on the flagging parameters and the attending certificate officer, the (some) certificate might or might have not been issued - I'm careful with this statement as suspicion can arise for this or the other reason, but it's not 100%. High-profile names would have been flagged and not issued though. I would also be curious about why the certificate has not been logged to CT, given StartCom's prior statements with regards to CT adoption. We are checking it, it might have been logged at the wrong place. I'll try to provide an answer on this too when possible. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: StartEncrypt considered harmful today
On 06/30/2016 06:30 PM, Rob Stradling wrote: https://www.computest.nl/blog/startencrypt-considered-harmful-today/ Eddy, is this report correct? Are you planning to post a public incident report? Hi Rob and all, There were indeed a couple of issues with the client software - known bugs have been fixed by our developers (hope there wont be anything more significant than that :-) ). 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. At the moment I don't believe that a public incident report is necessary, but should anything change in our current assessment we will obviously act accordingly. I instructed additional verifications and confirmations to assert that assessment. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Only accepting 2048 bit or better certificates
On 06/21/2014 07:15 PM, Kurt Roeckx wrote: But I would like to start enforcing the 2048 bit as soon as possible. Do we have some criteria for at which point we're willing to break compatibility? I'm in favor of enforcing it which will help reduce even mistakenly issued certificates with smaller keys to be detected quickly and there will be no incentive to use such keys for web sites (there are other use-cases for non-browsers and those should be still permitted I guess). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about disclosing subCA certs
On 05/22/2014 08:48 PM, Ryan Sleevi wrote: Applications that fail to consider the trust bits - or, for that matter, constraints - are at their own risk, because they're misusing the trust list. Requiring that Mozilla's Root Policy keep them in consideration is akin to requiring Mozilla consider applications that don't support/implement Name Constraints, or fail to implement RFC 5280 correctly. Well, just for the record according to the RFC you mentioned there are no trust bits for CA roots. Either it's a self-signed CA root or it's not - it can sign basically anything for any purpose, same goes for sub-ordinate CAs that are not name-constraint. The trust bits Mozilla implemented for its root store (similar has Microsoft done it for theirs) are not documented or found RFC 5280. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about disclosing subCA certs
On 05/20/2014 11:55 PM, Moudrick M. Dadashov wrote: Eddy, do you mean SSL client authentication? We too rely on this a lot. Yes -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> smime.p7s Description: S/MIME Cryptographic Signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Question about disclosing subCA certs
On 05/19/2014 07:40 PM, Rick Andrews wrote: Kathleen, that means we'll be disclosing a number of intermediates used to sign certificates that are not used for SSL, Code Signing or Mail (the three trust bits that Firefox lets me view/edit). For example, we issue a lot of client auth certs from our public roots. Based on your previous comments, I assume you expect those to be disclosed too, even though Mozilla products likely will never encounter them, or work with them if encountered. Please confirm. Doesn't Firefox and Thunderbird do certificate authentication? At least we are using it quite often too :-) -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/29/2014 05:31 PM, Jan Lühr wrote: - By advertising certs to be "non-free" and putting the actual price tag on it, alternate CAs like CAcert might get a boost in popularity, emphasizing their importance for global internet security. At the moment, many people skip CAcert in favor of StartSSL, cuase they just can get a "free" certificates in major browsers. 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. And lets assume CAcert would gain that popularity - how do you expect that to be financed exactly? Do you really believe this could be sustained with ideology? I suspected that there are a few CAcert groupies around here with this discussion ;-) But I tell you a little unknown secret, the first time I heard about charging for revocations it was exactly from the folks like Duane and later Ian. You can ask them and they might even confirm it, because they too were looking for solutions to a problem. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/29/2014 12:05 AM, Jan Lühr wrote: Does StartSSL violate Mozilla's policies by not revoking certificates assumed to be compromised? (Compromised, due to heartbleed, not revoked, because of non-paying subscribers?) /Assumed/ it perhaps a good description since it's rather difficult to confirm an actual compromise and if the certificate/key was supposedly hosted at an affected server during its life-time. We believe it's the responsibility of the subscriber to make the correct assessment and do whatever is necessary to get the certificate revoked (or not). I don't want to speak for other CAs (as we are currently taking the burnt on this one), but I'm pretty sure that other CAs have their limits as well what revocations concerns and certificates are not endlessly revoked. Netcraft reports about many reissued certificates, but relatively few revocations: http://news.netcraft.com/archives/2014/04/25/heartbleed-why-arent-certificates-being-revoked.html So this can't be just an issue of StartCom, but perhaps easier to hit because there is a charge involved. Our CRLs can be measured and I believe we've done a fairly good job during those hectic days when the bug was disclosed. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/28/2014 10:11 AM, Jeremy Brookman wrote: If we take the StartSSL principle that subscribers need to pay a fee to request revocation even in the case of key compromise where there is no malpractice, but then combine it with the subscriber obligation to request revocation in the case of (confirmed?) key compromise, then in receiving a signed class 1 certificate, subscribers accept a financial liability in circumstances outside their control. That's probably true, it's not a negligence on part of the subscriber, in this case it's probably simply bad luck (a different software could have had a bug with similar result at a different time). We've seen it in the past that it can happen (weak keys). Can this product therefore really be described as "100% Free"? That's of course a question of interpretation and probably also of simplicity. Not all services are free of charge of course and our FAQ tries to explain that like this: https://www.startssl.com/?app=25#90 (item 90) -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/28/2014 05:53 AM, Eric Mill wrote: I appreciate how diligent you're being about responding to everyone. And, as I've said elsewhere, I haven't believed that there's an ethical problem with offering free certs with paid revocations as a general business practice. OK Resist generalizing: would offering a one-time free revocation for any domain whose owner says the word "Heartbleed" be feasible *right now* for Startcom? Could Startcom get through it okay? I don't think so, not without a financial loss, which we would have to cover from somewhere else. A change to the business model would be more likely in the future, which I however wouldn't really like to see, but there are different options and considerations on the table. All in all the actual result is rather positive with most subscribers complying to the requirement and pay their fees, with the exception of a rather noisy minority - which in turn I can understand too and maybe was to be expected. Presumably, your CRL lists have already expanded and your bandwidth costs increased. If the number of vulnerable certificates is small enough that you haven't felt guilt-ridden about charging them for revocation, it should also be small enough that the additional marginal cost of waiving the fees for them shouldn't cost you that much. I think the question about guilt isn't appropriate - I don't feel guilt-ridden. We follow a policy and business model we decided long time ago which is implemented. As any competitor can charge whatever they want for whatever they want, they don't have to feel guilty either, they are running a business. Our CRLs doubled or more since the bug, our OCSP infrastructure isn't exactly cheap either and those that receive the benefits from it are charged a fee as we disclosed and implemented. Part of having a sustainable business is having enough of a buffer so that you can weather an occasional tornado without having to lock your neighbors out of the shelter. I believe that's exactly the point, sustainability is important and we took care that the operation will be sustained even in case of a tornado (see also other reply to the list regarding insurance). The subscriber has obligations too and if it happens, the subscriber has to carry some of the costs (maybe never, maybe only once or maybe more than once, that's the risk/benefit). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/28/2014 08:53 PM, Zack Weinberg wrote: I find this both surprising and disturbing. Are you saying that you tried to obtain insurance against the possibility of this sort of catastrophe (keys compromised due to bug in software maintained by third parties) but could not, because no insurer would write the policy? The typical insurance is protection against claims by third parties due to a failure by the CA. Those are fairly expensive but possible, whereas the sort of catastrophe you mentioned I haven't heard of so far. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/26/2014 06:45 PM, Zack Weinberg wrote: If a business chooses to give some or even all of its services away free, those who benefit from those services are still customers and still in the same ethical relationship with the business as people who paid for services (perhaps the same service, perhaps not). We call all of them "subscribers" and we make no difference between a "paying" subscriber and "non-paying" - the difference is only the verification level and respective certificates according to that level. Some of the services carry a fee and some don't - for example no validated subscriber pays actually for the certificates, he/she pays for the validations performed which entitles them for certain type of certificates. In particular, the business may *not* duck out of ethical obligations incurred by circumstances beyond any customer's control (e.g. catastrophic bugs in software everyone relies on ;-) just because some of its customers are not *paying* customers. Nobody ducks here - such a bug is not under the control of the subscriber and not of the issuer of the certificates, nor can the issuing instance control with which software the certificates are being used, how the keys are handled and so forth. This is not a one-way street and it takes at least two to tango. The subscriber has to comply to the terms and conditions (Subscriber Obligations) the issuer set forth. And the subscriber has to pay certain fees when they apply. CAs should be carrying insurance to cover exactly this sort of low-probability-but-still-foreseeable, high-cost event. Interestingly CAs can insure themselves for mistakes made at their end (errors and omission, but not for mistakes of others. That's exactly the reason why those costs can't be turned onto the insurer (otherwise we'd have done exactly that). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/26/2014 10:53 PM, Daniel Micay wrote: If the free certificates were not creating revenue by luring people into the paid offerings, I doubt they would be offered. There's no need to feel pity for a working business model. You probably aren't around long enough to remember or know about how the StartCom CA was started. Of course to be a serious and realistic certificate provider that has taken down the costs of SSL certificates in general and in order provide an alternative to the existing model, a different business model had to be implemented that makes the operation sustainable. Of course those that enroll for higher validations actually pay partly the issuance costs of the non-validated (Class 1, Free) certificates, however those costs are fairly low considering they share the same infrastructure and personnel. Bottom line is, that though StartCom needs the higher validations in order to sustain the operations, it's the result of the former and the free certificates are not the result of the latter (initially StartCom had only domain control validated and free certificates). -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/25/2014 08:50 PM, Jan Lühr wrote: What's your argument here? Is "crying foul" "Unjustified", because nobody "cried foul" the moment you published your policies? It's unjustified if as a subscriber you are not willing to accept the terms and conditions of that service, e.g. you want to accept the convenient part of it but not commit to your obligations. Please consider: Heartbleed-scale problems have hardly happened before. True - the closest would be probably the Debian weak keys. I'ven't considered any mass-key-compromise scenarios before I did - I learned from the Debian weak keys a lot. Personally, I am "crying foul" because I'm re-thinking your policies having heartbleed in mind. You can't really rethink our policies, this is something we might have to do at some point. You can either agree or disagree with them though. Personally, I vote no. StartSSL is not revoking certificates assumed to be compromised, if a subscriber doesn't pay. You are expecting to receive all benefits without taking responsibility for your part? Or lets put it like this: As you stated before, how likely is it that such an event like this one occurs? It might have never happened and in fact some 83% are not affected (world-wide), which means that they will happily keep obtaining certificates without ever paying a dime. Would you have used a different software, you could be easily one of those 83% too. Now, exactly because of this and other scenarios, where revocation of a certificate is necessary or is requested for any other reason by the subscriber and it's not due to a failure of the CA we decided to charge a fee in order to protect us from losses. Otherwise the current business model would probably not work...and I'm not even talking about easy abuse that's possible with the current model without raising a fee. -> You say it is small / low by describing the circumstances under which it happens and causes an impact. Currently the facts show that StartCom's revocation numbers are not lower, in fact a bit above average. And here some more interesting facts: http://news.netcraft.com/archives/2014/04/25/heartbleed-why-arent-certificates-being-revoked.html -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/25/2014 07:14 PM, Zack Weinberg wrote: Please see http://www.lightbluetouchpaper.org/2014/04/25/heartbleed-and-rsa-private-keys/ for more detail. Thanks for that link, we'll certainly study it too. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/24/2014 08:15 PM, Eddy Nigg wrote: Without leaking any more data from Netcraft I can tell you that the revocation rate of StartSSL is in fact higher than any other CA except GlobalSign Sorry, this statement should have said higher than the average and not every CA. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/24/2014 05:04 AM, Radu Hociung wrote: On Wednesday, April 23, 2014 6:00:41 PM UTC-4, Eddy Nigg wrote: I do have a few questions to you! How can you know that a site using a certificate from ANY CA isn't or wasn't affected by the Heartbleed bug? I'm planning on a more thorough answer that cross references the SSL observatory data from 2010 with a fresh update, and with published CRLs. One would expect that each CA would have about 17% of their issued certificates be revoked and re-keyed due to heartbleed. In a day or two I should have some stats. Don't waste your time, I'll help you: https://isc.sans.edu/crls.html Now, using current data from Netcraft which I'm not really allowed to publish shows StartCom with slightly above 100,000 certificates. Without leaking any more data from Netcraft I can tell you that the revocation rate of StartSSL is in fact higher than any other CA except GlobalSign, but their situation is unique (and maybe also problematic due to the CRL size). Assuming that 17% of all certificates were affected by teh bug you can see easily that about 1.5% of all certificates were revoked in average excluding GlobalSign. StartCom's revocations is currently slightly short of 2%, above average. It also means that in average there are still 15.5% of certificates that might be affected and still not revoked, assuming none of them expired. Not that I believe that those keys in fact have been compromised, but applying your logic there are a bunch of CAs you probably should disable now. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/23/2014 10:32 PM, Radu Hociung wrote: What will you do do avoid this? Check what's behind the (now meaningless) green lock? what if the site replaced its certificate with a new one, non-startcom ? You can still be MITM'd using the existing, valid cert, so you can't even be certain that you're safe. I do have a few questions to you! How can you know that a site using a certificate from ANY CA isn't or wasn't affected by the Heartbleed bug? Do you know how many certificates from CAs other than StartCom have NOT been revoked? And can you tell me which of the currently installed certificates no matter who the issuer is were issued after a revocation of a previous certificate? Once you can answer me these questions I have an interesting surprise for you Consider also that the presence of Startcom in this market is a barrier to entry to other, honest and potentially inexpensive CAs. No, it's not, otherwise StartCom would own 100% of the market share which it doesn't. The offerings of StartCom suite certain users and others not. How can they compete with the perceived "free" certificates that Startcom floods the SSL space with? They are free of charge no matter what - and under normal circumstances will not cost anything. Approximately 17% might be affected by this bug, another 87% are not. This means users are getting year after year a free service for 0.00 US$ from StartCom and keep getting it now and in the future, the rare exception which isn't even under our control are revocations. And if it wouldn't be necessary to raise a fee for that we wouldn't either. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/10/2014 07:05 PM, Eddy Nigg wrote: I agree - I've saw the tweets bug reports and this posting. I'll be glad to join the discussion and we intend to take a public stance as soon as things calm down a bit. Currently all hell is lose, but I promise to get back to you all in due time and will explain our position, policy and practices and also refute some of the claims that were made. In the meantime please be patient, thanks. Alright - things have calmed down luckily by now. As my first input to the discussion please read carefully my explanation, thoughts and comments I've written down in my blog at https://blog.startcom.org/?p=230 -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
On 04/10/2014 10:46 AM, Kaspar Janßen wrote: Hi, initially i filled a bugreport [1] about the consequences of CVE-2014-0160 but this seems to be a better place for a discussion. There were still a discussion about the problem which may be interesing. I agree - I've saw the tweets bug reports and this posting. I'll be glad to join the discussion and we intend to take a public stance as soon as things calm down a bit. Currently all hell is lose, but I promise to get back to you all in due time and will explain our position, policy and practices and also refute some of the claims that were made. In the meantime please be patient, thanks. -- Regards Signer: Eddy Nigg, COO/CTO StartCom Ltd. <http://www.startcom.org> XMPP: start...@startcom.org Blog: Join the Revolution! <http://blog.startcom.org> Twitter:Follow Me <http://twitter.com/eddy_nigg> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 03/07/2014 07:10 AM, From spark0...@gmail.com: According to Mozilla's definition of independent party, KISA is independent organization from Sub-CAs(not employees nor director) The minute a CA signs a certificate of/for another CA, it's not independent at all. In fact a tight relationship exists between the two parties and a CA can't audit another CA. For this the BR sets forth a requirement for an independent audit by a (different) auditing firm than the CA signer/issuer, in order to avoid any conflict of interests. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Seeking guidance on proceeding with KISA root inclusion request
On 03/04/2014 09:38 PM, From Kathleen Wilson: My personal preference is to proceed with the process to approve/include the KISA root under the condition that Mozilla would constrain the CA hierarchy to *.kr. However, KISA does not want to constrain their CA hierarchy to *.kr. I have also suggested that KISA have each subCA apply for inclusion as separate trust anchors, but KISA does not want to take that approach either. I think the BR and Mozilla's own policy has set the proper requirements defined for any CA operating under another CA (root). This should apply here too which excludes the CA performing a (self) audit for the sub ordinate CAs for example. In respect to limiting issuance to a TLD, Mozilla might have to set a criteria for it first. Being a national (local) CA could be such a criteria. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: DigiCert Request to Include Renewed Roots
On 01/29/2014 08:50 PM, From Jeremy Rowley: 1) These root certificates are used in many different systems, not just Mozilla. If Mozilla doesn't embed all of them, the ones not embedded will essentially be untrusted. The roots proposed are simply replacements for our existing root certificates, and our plan is to phase out the current DigiCert root certificates once there is sufficient ubiquity in the new roots. Jeremy, not that I overly care, but are you saying that all these roots plus the existing roots were accepted in the Microsoft roots program? I thought there is a hard limit of three roots these days and if correct and enforced by Microsoft your argument doesn't hold. I'd say that you probably should have not more than three roots, maybe each with a particular algo and hash. From those you can and should issue intermediate CA certificates according to the various purposes you outlined in your mail. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Exceptions to 1024-bit cert revocation requirement
On 12/12/2013 12:31 AM, From Kathleen Wilson: I understand that this is not fair to the CAs who have done a great job of transitioning off of 1024-bit certs. Right - potential customers knock at various doors in respect to such certificates and I believe to have given the right answers to them that it's not possible to obtain such certificates anymore when approached. Indeed if this isn't something applied equally it might be very difficult to enforce other requirements in the future if at the first opportunity there is yet another exception to the previous exception etc...if experience shows that it doesn't pay out to comply to requirements, than why care next time? -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revoking Trust in one ANSSI Certificate
On 12/10/2013 10:52 AM, From Erwann Abalea: You're right, of course. Mozilla has twice expressed its concerns about MITM certs linked to a public CA, and all public CAs including IGC/A was told to perform some checks on the complete set of certificates chaining to the root, reporting any deviation. But budgets are needed to change all the procedures, perform internal audits, change software, run training programs, etc. From http://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ for a certificate to be used for SSL-enabled servers, the CA takes reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate /or/ has been authorized by the domain registrant to act on the registrant’s behalf; It's been there for how many years now? It's not about MITM, it's really about doing the bare minimum - if a CA does that it never lets a certificate be used knowingly for MITM purpose. If hasn't done that up to now due to budget constraints or whatever other reasons, I suggest to take measures accordingly. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revoking Trust in one ANSSI Certificate
On 12/10/2013 02:48 AM, From Erwann Abalea: As Kathleen mentioned in bug 948175, governments need to vote budgets. :-) Issuing certs for google.com and other sites (assuming) without any validation has nothing to do with BR compliance, budgets etc. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revoking Trust in one ANSSI Certificate
On 12/09/2013 11:12 PM, From Ryan Sleevi: According to https://wiki.mozilla.org/CA:Communications#January_10.2C_2013 (see the Responses section), this CA has indicated that they do not expect to begin operating in full compliance to the Baseline Requirements and to Mozilla's 2.1 Inclusion Policy until Dec 2015/January 2016. Thanks Ryan - then we probably should understand what Mozilla does or intends to do in such cases. Maybe this shows that something must be done (when we are assuming that by today every CA is compliant already and this should not be possible according to BR AND Mozilla's requirements). -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revoking Trust in one ANSSI Certificate
On 12/09/2013 08:09 PM, From Kathleen Wilson: On 12/9/13 9:42 AM, Kathleen Wilson wrote: Mozilla Security Blog post: https://blog.mozilla.org/security/2013/12/09/revoking-trust-in-one-anssi-certificate/ Google's blog post: http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certificate.html The CA's public statement: http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html http://www.ssi.gouv.fr/en/the-anssi/events/revocation-of-an-igc-a-branch-808.html Microsoft's security advisory: http://technet.microsoft.com/en-us/security/advisory/2916652 Opera's security blog post: http://blogs.opera.com/security/2013/12/certificate-update/ Well wellany actions applied upon the CA to improve controls in order to prevent another such occurrence? Is this CA compliant to the BR and Mozilla's CA policy and requirements? Any bug to track that? -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New problematic practice
On 12/04/2013 11:40 AM, From Rob Stradling: [1] http://social.technet.microsoft.com/wiki/contents/articles/1760.windows-root-certificate-program-technical-requirements-version-2-0.aspx Interesting! Was there an official publication of those (new) requirements? At least we weren't aware and it will probably take some time to implement them. Also there is no explanation why that shouldn't be allowed anymore and it should bother anybody if they are randomized. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New problematic practice
On 12/04/2013 02:44 AM, From Jan Schejbal: Issuing a backdated end-entity certificate should be considered misissuance. (Possibly allowing a small, clearly defined amount of hours that certs can be backdated for technical reasons.) Not necessarily technical, but we use the validity time to add some additional randomness to the cert and issuance, respectively expiration time varies +- 24 hours into each direction. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: New problematic practice
On 12/02/2013 08:38 PM, From Brian Smith: Why? Could you please explain what problem would be created if the renewed certificates had a different (later) notBefore time? Traditionally we kept same or similar start date/time when extending an existing CA certificate with a new signature and new expiration date. Like this previously issued certificates can be still verified with the new one, in particular S/MIME but not only. An end-user certificate that has been issued before the new/extended certificate has been, can't have a earlier before-date than the issuer (or at least shouldn't). But it can still correctly chain to the new one which is usually the whole idea of such PKI acrobatics. :-) -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla not compliant with RFC 5280
On 11/08/2013 09:02 PM, From Jeremy Rowley: What does this mean for CAs who, relying on Mozilla’s checking of OCSP and support of the baseline requirements, established an expensive and geographically diverse infrastructure? Probably get a smaller bill at the end of the month ;-) Mozilla’s main argument is that revocation checking without hard-fail provides little security. Although I disagree with the premises, if the lack of hard-fail is really the issue, the obvious solution is to turn it on. Most of the CAs would be happy about that. +1 -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 11/02/2013 02:00 AM, From Brian Smith: Does the end-entity certificate have an EV policy OID from any of our EV CAs? If so, verify that the certificate is valid for that policy OID, trusting only that CA's root. During this validation, check OCSP, and fall back to CRLs using CRLDP. Thanks for confirming this, Brian. The normal certificate checking path does not do CRL fetching, and it *never* has. So, for any CA that isn't in our EV program, Firefox has never done CRL fetching. But the code would actually exist to do that in that case. The CABForum EV guidelines have required EV CAs to support OCSP for a very long time. Absolutely. So, there's no justification for Firefox to fall back to CRL fetching for EV certificate verification any more. I don't really agree with that however - I've been an advocate to certificate status checking along the lines Firefox apparently has done for EV certificates. No infrastructure can be 100% perfect and for this I think the fallback to CRLs is quite useful. In numbers I assume that's small a minority and in case of EV I also assume that the CRLs are fairly thin, not affecting performance a lot. Of course I'd like to see this for all certificates, not only EV really. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 11/02/2013 01:00 AM, From fhw...@gmail.com: Or to put it another way, everyone could stop issuing CRLs immediately and have no appreciable impact on Internet security. I think that would surprise many people. Obviously it would have an impact on other browsers and systems. But true, it wouldn't affect Firefox and friends (this time in the negative way). It's however nothing new, it would be news to me that it checks any CRL at all. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 11/02/2013 12:32 AM, From fhw...@gmail.com: So if this really is the case, it seems to me that this constitutes a zero day vulnerability in Firefox. I don't mean to sound alarmist but...??? It's not since it's always been like this and one of the reasons CAs must provide OCSP revocation capability. It would be however /nice/ to have a CRL fallback... -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/31/2013 09:41 PM, From Kathleen Wilson: That's true for non-EV. The validation path for EV is different. Which developer can confirm this? Where is the code for it? It's just news for me and I'm a bit surprised, but enterily possible. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/31/2013 04:40 PM, From Jean-Marc Desperrier: Eddy Nigg a écrit : If Firefox really uses the CRLDP No, it has never used the CRLDP to download the CRL. People need to import the CRL manually and then activate the auto-update, and nobody does it. What's more if the CRL becomes outdated for some reason, there will be no warning. Thanks for confirming -Kathleen, Firefox by default doesn't use CRLs. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/29/2013 04:26 PM, From Gervase Markham: To illuminate the debate: are you able to quote a case study from the Web PKI where a relying party has successfully claimed on such a warranty? And if not can we remove SSL please from the browsers? We don't need that in that case since nobody was a victim (of a system that apparently seems to work) who had to make claims against a CA. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/28/2013 09:51 PM, From Brian Smith: On Mon, Oct 28, 2013 at 12:27 PM, Stephen Davidson wrote: Virtually every CA relying party agreement (RPA) that I know stipulates that a user must validate the SSL using CRL or OCSP in order to place any reliance on the certificate. Removal of that capability from browsers renders those RPAs useless, and effectively removes warranties from the SSL sector. Aren't these RPAs already useless? Anyway, AFAICT Mozilla didn't agree to any RPA agreement with any CA. Also, our users have not agreed to any such agreements. Perhaps it worthwhile to clarify this by forbidding such requirements on relying parties as part of our CA policy. Actually you did by adding a root who's policy Mozilla ought to know fairly well. Mozilla is a relying and/or acts as a relying party on parts of the obligations and on behalf of the user. A user using a software that doesn't check revocation (knowingly) may NOT rely on a certificate. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/25/2013 11:47 PM, From Rick Andrews: A number of CAs have been actively working to improve the performance of their CA infrastructures, and have made significant improvements. For reference: https://revocation-report.x509labs.com/ ( just that the cert expired there :-) ) -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/24/2013 08:01 PM, From Kathleen Wilson: For EV certs Firefox has always checked the CRL when the OCSP AIA URI was not provided. EV treatment would not be given if current revocation information was not obtained. If Firefox really uses the CRLDP, then I suggest to keep that option still open meaning if no stapled OCSP response, use the normal pointers and if that fails use CRL. Remove EV (and the "secure" UI indicators if you want from any other certificate) when certificate status can't be verified. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/24/2013 08:30 AM, From Ben Wilson: So long story short, yes, the OCSP URI does need to be in the AIA of the certificate. Thanks Ben, that's perfect. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/23/2013 10:31 PM, From Kathleen Wilson: I'm not sure I understand your message. Are you saying that even if OCSP stapling is used, the certs must have the OCSP URI in them, in case the server's stapled response doesn't work, and the browser needs to fallback to the OCSP URI in the cert? Yes, exactly. Also servers can be configured the easiest by having it simply use the included OCSP URI in the certificate. In the case of EV certs, Mozilla is still checking the CRL when the OCSP URI is not provided. Since when does Firefox check CRLs? I believe it never did except if configured manually (which is probably almost never). Are you saying that (instead of the above proposal) the revocation checking should do the following? 1) Check for OCSP stapling response from server. 2) If cannot get a valid OCSP stapling response, then use OCSP URI in AIA to try to get OCSP response. 3) If these attempts fail, then check CRL. 4) If both OCSP and CRL fail, then EV treatment will not be given. That really would be perfect (I think the best it can get with current implementations). However IMO the fallback to normal OCSP is a must. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Netcraft blog, violations of CABF Baseline Requirements, any consequences?
On 10/22/2013 09:02 PM, From Kathleen Wilson: As I mentioned previously, I don't believe the lack of OCSP URI in those EV certificates was causing security risk to end users. Now that OCSP stapling is available, I think we should give Verizon a little bit of time to move their customers to OCSP. I've been on the sidelines for most of this and other discussions here, however I don't think this is correct at all - if the server doesn't provide a correct stapled response, the browser must still be able to find the OCSP response on its own. Additionally servers usually will use the exact same information to find a valid OCSP response to include as a browser would, and this response must be fairly frequently updated too. Except if the server admin bothers to configure that manually which I doubt over the longer term for most. There IS a significant risk if a certificate can't be revoked, this isn't just about EV treatment. Stapling or not still requires to provide a source to check for the certificates status independently, both for the server AND in case stapling fails for this or the other reason (outdated, wrong etc.). -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Discrepancy regarding 1024-bit roots
On 10/09/2013 11:05 AM, From Rob Stradling: The BRs are minimum requirements, not maximum requirements. Therefore, I see no discrepancy. Should we allow 1024-bit roots to continue to be enabled for SSL, as long as the certs issued in their hierarchy are in compliance with the BRs? No. I think it's time to update the BRs! +1 -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
