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
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
