在 2016年10月18日星期二 UTC+8下午10:38:07，Inigo Barreira写道： > Hi all, > > > I´ve been reading some emails that need clarification form both sides. > > Firstly I´d like to remind, if I´m not wrong, that Kathleen proposed an > action plan for distrusting StartCom, which has been taken as the final > decission, but with a small option to regain the trust for StartCom in > Mozilla if we can make her recover the confidance in StartCom. > > Two weeks ago, there was a meeting between StartCom and Mozilla that > everybody was aware and on friday of that week, StartCom published the > outcome of that meeting, having this last week to set specific dates and > tasks for making it real. The surprise came when Kathleen droped the > email with the sanctions plan. In any case, StartCom published on > friday, at 10:30 CET, a remediation plan (it was already done by > thursday that week, but it´s difficult to coordinate with so many hours > of difference) on StartCom´s website. Surprisingly, there hasn´t been > any comment, in this mailing list, to that message (I even had to ask > Gerv if I posted correctly) in which there is more detailed information > on the next steps to be done. > > Here´s the link again: > https://www.startssl.com/report/StartCom_Remediation_Plan_14102016.pdf > > So, regarding the situation of StartCom I think that some people has > lost what happened and it´s considering Wosign and Startcom the same. > > Let´s focus on the 3 issues for which StartCom has been proposed to a > sanction (hopefully we can change that), and these are: > > 1.- Bad coding of a new solution called startencrypt, which basically > was barely used and not affected StartCom > > 2.- Issues with serial numbers, not able to generate serial numbers > starting with zero and the reuse of some. Those were bugs fixed on time > and were because of a software and hardware upgrading as explained > before, due to the acquisiton of Wosign because the PKI was cloned. This > is also indicated in the plan > > 3.- Backdating 2 certs for Tyro. I think this is the issue that has made > Mozilla to include Startcom in the equation and fine it. But as also > explained this is not a security issue (same as other SHA1 certs > legitimacy issued on time) but a bad practice > > In any case, this mailing list is called mozilla.dev._security_.policy, > and for these 3 issues, imho there´s no security problem. We can talk > about how things have been done, there´s been some cheating, hidden > info, bad practices, etc. That´s totally true but as Mozilla always > remembers about their users base, these have not been affected by any > security problem. Recently some emails remembered the comodogate, the > diginotar, etc. back in 2011, and those were different because the > attacker had control over the issuance process and some certificates > were issued without knowledge and/or consent of the CA, and this is not > what has happened to StartCom in which all the cryptographic material > was under control of the companies (including wosign) > > Of course, there has been bad decissions, bad practices and procedures, > etc. but if you see the plan, there you can find all the actions that > are taking place to avoid this situation again. > > In any case, taking as examples the recent issues affecting Comodo and > Globalsign (I´m just mention these because have been published at the > same time) it makes me feel with a strange feeling. Comodo issue was an > unintentionally or unauthorized issuance of a certificate for a ".sb", > can´t remember now, (could be compared to the 2 backdated certificates) > and globalsign revoked an intermediate certificate and later un-revoked > it (I don´t know if this is allowed in the RC 6960, but in ETSI once a > certificate is revoked, you can´t reisntate it status). Again, those are > examples and the only concern for me, it´s that the bar in the case of > StartCom is not the same in the case of others, again, taking into > account what has mentioned above and the control over the keys has not > been lost. The price for StartCom is too high. > > For some specific questions that are around this issue, for example, > those related to communicate the end users, I have to say that: > > - Mozilla runs a root program on a voluntary basis. So any CA may join, > stay or leave on its own discretion. If the CA decides to join, then it > shall follow the root program requirements > > - Every CA must have its own procedures and practices for doing its > business, independently if decides to join a specific root program or not > > - Mozilla and other root programs can impose its rules to the CAs that > voluntary decide to adhere to the programs but can´t have any decission > on what a CA decides or not related to its business. Of course comments, > suggestions, etc. are welcome in the comunity > > - StartCom has made publicly this report in which they explain what are > going to do, dates and tasks, for everybody to check out the ongoing > tasks. I will indicate periodically how these tasks are going > > - The decission on what/how/when to communicate whatever to the StartCom > customers is a decission of StartCom. Mozilla and the rest of the root > programs can make comments or suggestions for sure, but can´t interfere. > And this is not a matter of trust or something similar I´m reading here. > And again, taking into account that the security of the end users have > not been affected. > > > I´d also like to comment the issue regarding the CT, which I think is > unfair, but let me explain: > > - Firefox does not support CT yet > > - All CT log servers operators out there have to follow the same > requisites, for example, RFC 6962 up to now, and google requires some > more requisites to be admitted into Chrome browser. These are the same > for every CT log server operator independently who manages them > > - There are additional tools, such as crt.sh, that are also valid to > check out certificates > > so and as stated in the plan: > > - Before Mozilla asked, StartCom started publishing all their > certificates in the CT logs > > - In the document, you can see that for EV (and to meet google > requisites) StartCom uses a google and non-google log server > > - for the non-EV certificates, StartCom uses a google and non-google log > server. These non-google log servers were announced to be include in > release 54 (which has been already released) > > - StartCom has been in touch with other CT log server operators but it´s > complicated due to the number of certificates StartCom issues. Not all > log servers accept these numbers for many reasons, i.e. performance > because can´t create some delays that will affect its status in Chrome. > Having said this, I´ve contacted Symantec to see how´s the current > situation (were some talks in the past), also was commented the choice > of using CNNIC log server (but maybe there are suspicions), and was > planned to talk in person with Digicert. > > In any case, StartCom follows the google rule of one google and one > non-google log (which of course this does not have to be the same rule > in case of Mozilla but as Firefox does not support it, will be > contradictory to have some other rules) and don´t understand the > reasoning of not using the StartCom one, when ALL of them have to pass > the same requirements. > > > Finally, I´d like to ask Mozilla if the remediation plan released by > StartCom last friday can make Mozilla regain the confidence and trust in > StartCom with the current roots. Maybe there are some additional steps > to make or some other conditions proposed by Mozilla, but in general, I > think this plan is good enough to be maintained in the Mozilla root > program because it solves all the issues that have happened. > > I´d also like to know if we are forced to set up new roots to be > admitted because that will make us need some more time and in any case, > need to know the auditor Mozilla is suggesting to contact them asap for > arranging agendas. > > > Lastly, and now I´m finishing, also has been said about the transparent > of the process, how different root programs work, a unique source of > information, etc. I think this is good, but it´s only one leg, the > information to provide to the root programs, but it will be good to have > also another one listing the issues and the penalties. For example, > something similar of what the EU Commission is doing with eIDAS and > article 19, in which CAs have to communicate to their supervisory body > (the equivalent of the browsers root program) all the incidents they > have and then decide based on a specific procedure and with the help of > a tool. ENISA is working in developing this tool and providing this > procedure to all SB and TSPs, and this procedure is divided into > different categories with different levels and possible issues that are > going to be treated differently and with accordingly sanctions, from > monetary to distrust. With this solution, all CAs will know in advance > what will happen if you make a mistake and not treat them on a > one-by-one case and applying different resolutions for similar > incidents. The aim is to be the more objective possible. > > If you think this option will improve the transparency of an open > collaboration, I´m willing to help. > > > Best regards, > > Iñigo Barreira > > CEO > > StartCom CA Limited > > > El 18/10/2016 a las 1:26, Kathleen Wilson escribió: > > All, > > > > Here’s a summary of your input, and my thoughts. > > > > ~~ > > What about NSS? > > We discussed this in the NSS team call last week, and the general decision > > was that the rules we put in place regarding these Affected Roots for > > Mozilla will also be put in place inside NSS. > > That doesn’t help all consumers of the NSS root store, just the ones who > > use NSS validation. > > I’m not sure what we can do about other consumers of the NSS root store, > > other than publish what we are doing and hope those folks read the news and > > update their version of their root store as they see appropriate for their > > use. > > > > ~~ > > Several comments about Mozilla’s Action #4. > >> 4) Remove the Affected Roots from NSS after the SSL certificates > >> issued before October 1, 2016, have expired or have been replaced. > > I will change the date to October 21, 2016 to be consistent with the date > > previously listed. > > > > When I wrote that we would remove the Affected roots after the certs had > > expired or been replaced, I was incorrectly only thinking about the 1-year > > SSL certs. > > > > My intent was to find a reasonable date in the future when current clients > > have had enough notice and time to transition to other root certificates. > > Based on the data from Kurt, it looks like a year might be too little time. > > Two years seems like a lot of time. > > > > ~~ > > Regarding actions for the CA… > > Several suggestions that Mozilla require or strongly urge the CA owners of > > the Affected Roots to reach out to their subscribers asap to let them know > > about these changes, and give those clients time to transition. > > > >> subscribers > >> deserve some warning even of the risk that invalidation would > >> happen in future, not to mention that they will not be able to > >> receive renewals from these CAs, at least for some time. > >> WoSign and StartCom are still actively selling certs which cost > >> one hundreds or more dollars. I think Mozilla should mandate > >> that WoSign/StartCom inform their users of such incidents or > >> at least the imminent distrust by Mozilla > > I would hope that the CA would figure out how to communicate this to their > > customers in order to help their customers have minimum disruption. > > > > The CA could create new root certs, and put information on their website to > > make it easier for users to manually import their new root certs, and also > > put information on their website for their current customers who will need > > to get new intermediate certs, and instruct their customers about > > downloading the new root certs. That’s basically what CAs whose root certs > > aren’t included in NSS (and aren’t cross-signed by an included root) have > > to do anyways. > > > > I’m not sure what I could reasonably require (and enforce) of the CA in > > regards to communicating with their customers. > > > > I recall that my security blog about CNNIC got censored in China, so I'm > > not sure what Mozilla can do about informing the CA's customers of this > > pending change/impact. > > > > > > ~~ > >>> 4. Provide auditor attestation that a full performance audit has been > >>> performed confirming compliance with the CA/Browser Forum's Baseline > >>> Requirements[6]. This audit may be part of an annual WebTrust BR > >>> audit. It must include a full security audit of the CA’s issuing > >>> infrastructure. > >> I would recommend that Mozilla retain the option to approve the > >> security auditor, and that it be an external company. > > I will add the sentence: “The auditor must be an external company, and > > approved by Mozilla.” > > > > > > ~~ > >> 5. 100% embedded CT for all issued certificates, with embedded SCTs > >> from at least one Google and one non-Google log not controlled by the > >> CA. > > As suggested, I will add: > > ”The CA SHOULD NOT fulfill the non-Google log requirement by using > > logs that they run themselves. For as long as they do so, they will > > need to demonstrate ongoing evidence of efforts to get other logs > > to take their volume, and why those efforts have not been successful." > > > >> I should add that if StartCom/WoSign have a CT log codebase capable of > >> taking the volume necessary, they could always open source it, and then > >> pay a 3rd party to run an instance of it, with an arms-length contract. > >> That sort of solution may well be acceptable, depending on contract > >> details. > > I don't think that changes the sentence that is being added. > > > > > > ~~ > >> Please can Mozilla ensure that both EY Hong Kong and the overarching parent > >> organisation in the United Kingdom (in Southwark) are informed of this ban > >> and get a copy of Mozilla's findings if they haven't already ? > > I think Gerv is doing that. > > > > It will also impact CNNIC. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1177209#c13 > > So, does CNNIC's audit get grandfathered in? Or does CNNIC have to get > > audited by a different auditor before they can re-apply for full inclusion? > > > > ~~ > > I think we need to add an action item regarding making sure that all of the > > code and systems used by the CA are well-designed and updated, and fully > > meet the CA/Browser Forum’s Baseline Requirements. > > > > What would be a reasonable requirement to state for each of the CAs? > > > > Are there tests that we could require the CA to run/pass that would satisfy > > our concerns about quality of the code and systems? > > > > Thanks, > > Kathleen > > > > > > > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > -- > Iñigo Barreira > CEO > StartCom CA Limited
Security is not only in code but in the process. I think the reason of back-dating SHA1 cert is for the finanical benefit. I am confused about conflicts between non-profit and commercial CA. On the one hand, non-profit CA can avoid violating rules for money, On the other hand, commercial CA can provide a stable service and avoid security issues from financial problems. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
