在 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:
> 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. 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
> > firstname.lastname@example.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
dev-security-policy mailing list