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 securely. > 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 choose. 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. Gerv _______________________________________________ dev-security-policy mailing list email@example.com https://lists.mozilla.org/listinfo/dev-security-policy