Hi Inigo,

On 18/10/16 07:34, Inigo Barreira wrote:
> So, regarding the situation of StartCom I think that some people has
> lost what happened and it´s considering Wosign and Startcom the same.

Kathleen may also respond, but my understanding is that (based on her
consideration of the arguments put forth in this forum) her decision was
that the right approach was to treat WoSign and StartCom in mostly the
same way, based on the fact of their shared ownership, management etc.
over the past 10 months or so. As you know, this is not entirely how I
saw it, but I was at pains to make it clear to you that I was not the
final decision-maker, and I respect the decision which has been made.

> Let´s focus on the 3 issues for which StartCom has been proposed to a
> sanction (hopefully we can change that), and these are:

This line of argument starts from the position that StartCom and WoSign
can be treated separately. But Kathleen has decided that this is not so.

In addition, the three issues you list are not the only issues with
StartCom - while I have not compiled a formal list like the one for
WoSign, Ryan does point out several more.

> In any case, this mailing list is called mozilla.dev._security_.policy,

It's called that because when I asked for it to be created, I thought it
was logically a sub-part of mozilla.dev.security, which was the existing
discussion forum for these topics. You should not read too much into the
group name.

The issue of who is trusted in Mozilla's root program is an issue of
trust, which includes but is not limited to whether a CA is behaving

> 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). 

I don't think it's helpful to go into a detailed comparison of CAs and
issues and rating their relative severity, but I would note that there
are two components to how Mozilla views an incident - firstly what
happened, and secondly how the CA reacts. (I will say more about this in
Browser News at the CAB Forum tomorrow.)

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

To fulfil the non-Google log server requirement, it is not necessary
that you use a log server which is included in Chrome. Therefore there
is no formal uptime requirement (although clearly you'd want a decent
uptime as you were using it). The only requirement is that it not be
controlled by you.

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

This is a question for Kathleen but, as you know, her current decision
is to require new roots.

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

For WebTrust and other normal CA audits, Mozilla has no requirements on
who the auditor should be other than it should not be E&Y HK. You may

For the security auditing of your infrastructure, you may suggest a firm
but Mozilla retains the right to approve your choice or ask you to make
another. However, I suspect you are not at that stage yet?

> information to provide to the root programs, but it will be good to have
> also another one listing the issues and the penalties. 

I don't think it's either possible to helpful to make a list of all the
possible forms of CA mistake and the penalty to be applied in each case.
This would only work if it happened a lot. With it being so relatively
uncommon, I think every situation must be taken on its particular
circumstances. This is a benefit to you, because it allows for Mozilla
discretion where there are mitigating circumstances.


dev-security-policy mailing list

Reply via email to