在 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
> 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
> 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

Reply via email to