Hi Kathleen,
On 10/10/2016 09:39 PM, Kathleen Wilson wrote:
I would like to remind everyone that when making decisions about what to do
about CA mis-issuance, it is expressly *not* a goal for me to mete out
punishment. Rather, my primary goal is to help keep end-users safe, based on
the information that is available.
Allow me to add some of my thoughts into the discussion. I've read most
of the comments and arguments made here so far and assume that most
participants have the relevant information so that I don't have to
repeat them again....
I was directly responsible for StartCom for many years and gained some
experience in running a certificate authority, writing policies and
implementations thereof. I've helped to draft important guidelines and
requirements for CAs and in general learned about the mesh of software
vendors, certificate authorities and (web) PKI. I'm probably one of the
faces of this industry and would offer my two cents in this capacity
hereby....
The problematic issue in relation to StartCom is obviously the _two
backdated SHA1 certificates_ - however from the strictly technical point
of view I don't think that the user-base of Mozilla in general and the
relying parties in particular were much more at risk than relying on any
other SHA1 certificate that was obtained legitimately before the 1st of
January 2016. The risks were probably minimal since the certificate
properties besides that were validated correctly.
However, a completely different matter must be considered here - that of
compliance to the requirements set forth by the relevant bodies and
software vendors. Besides the _loss of trust_ in this particular case,
non-compliance happens many times due to _insufficient controls_. Being
it either that the requirements weren't correctly understood (not the
case here), or insufficient controls to prevent such non-compliance and
wrongful certificate issuance.
The remediation and corrections StartCom proposed are significant in
this respect - basically Mr. Richard Wang has been removed from his
position and unfortunately for him is paying a high price for
overstepping his authority. The parent company (WoSign) too has been
released of all its responsibilities and a full separation has been set
into motion.
The choice of Inigo Barreira as the new CEO of StartCom is probably a
good one and we all assume that he wouldn't approve the backdating of
certificates judging from his long-time record....however one of the
immediate tasks of Inigo will be to implement controls that will make
such abuse impossible - not by him and not by anybody else. I believe
this is the _core issue and remediation_ here, which was the failure in
first place.
(Obviously he'll have to review also other areas and implement controls
in case they were lacking or insufficient, something he's doing as we
speak).
But by looking at StartCom's performance besides that, I believe that
some of the voices and arguments haven't been reasonable during this
discussion! Was there a CA certificate compromise? Has StartCom lost
control of its issuance processes? Has StartCom in general failed to
validate certificate properties correctly? Has StartCom lost its ability
to abide and comply to the policies and requirements set forth? Has and
does StartCom present an undue risk to the user-base of Mozilla (and
relying parties in general)?
I believe that none of the above applies which would warrant such
dramatic steps on part of the software vendors and StartCom is generally
operating correctly. The particular failure that did happen can be dealt
with properly, firmly and professionally as proposed; _without knocking
StartCom out of business_. I believe StartCom is still an important part
of today's SSL landscape and it shouldn't be in anybody's interest to
remove it as a viable alternative to current mix of the established
certificate authorities - except if somebody is looking for revenge or
other personal matters....
--
Regards
Signer: Eddy Nigg, Founder
StartCom Ltd. <http://www.startcom.org>
XMPP: [email protected] <xmpp:[email protected]>
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
