> > >
> > > > Those tests were done to check the CT behaviour, there was any
> > > > other
> > > testing of the new systems, just for the CT. Those certs were under
> > > control all the time and were lived for some minutes because were
> > > revoked inmediately after checking the certs were logged correctly
> > > in the CTs. It´s not a mis- issuance by means of we didn´t know what
> > > happened, we had to investigate, etc. It was not a good practice and
> > > I can´t excuse for that, but it was not related to the regular
> > > issuance procedure as someone suggested. We provided a report in
> > > which indicated all that happened and what we did to not happen this
> again, updating the EJBCA roles permissions.
> > >
> > > 1) Why didn't StartCom build a test hierarchy?
> >
> > Considering that we were distrusted, that we didn´t reapply for inclussion,
> that CT is only required by Chrome and it´s not included in the Mozilla policy
> (even we were requested that all of our certs had to be CT logged) nor
> required by Firefox, that those certs were under our control all the time and
> lived for some minutes because were revoked inmediately, at that time, when
> we did it, we didn´t expect this reaction for sure.
> >
> > Of course if we had known it we hadn´t done it and for sure had built
> > a test hierarchy but there´s nothing we can do now. Only wanted to
> > state that those certs were under our control all the time, and lived
> > for some minutes because were revoked after the test. There were not
> > any other testing of any other nature directly in the production
> > system
> >
> > > 2) Why didn't StartCom use the TestTube CT log for testing CT?
> >
> > We tried to check and test the same behaviour before going live with the CT
> logging, so followed the requirements to use 3 logs, one google and one non-
> google, for the EVs and this is what we did. We used the same settings we
> had before the distrust using the startcom log and the google ones (pilot and
> rocketeer).
> 
> Hi Inigo,
> 
> I'm just trying to get everything straight, cleared up and then we can move
> on.
> 
> I found all of your answers very concerning in the way you've conducted
> testing. I thought that all CAs must have some type of test hierarchy in place
> to test new software,

Well, this is not required. Of course we have a development and a testing 
system, which are not "connected" into production.
As we wanted to check the same behaviour for the CT ecosystem than before the 
distrust, we did it directly in production, but don´t take this as we didn´t 
test it before in our development and testing systems, for sure we did.
 
> requirements and etc before going live but from the answers you've given, 
> StartCom neglected this in favour to test as you go
> along and deal with the problems using a live CA hierarchy.

As said, this wasn´t a "live" CA hierarchy. We were distrusted, nothing issued 
from that "live" CA was trusted, this wasn´t any harm to any of the Mozilla 
users.

 
> All this feels very amateurish and doesn't give me the any confidence at all 
> that your CA is
> proven itself to be a trustworthy part of this infrastructure.

I respect this opinion but can´t agree with it.

> 
> I recommend to Mozilla to require StartCom to start again fresh.
> 
> 1. Build a test hierarchy. Test the software and etc to industry guidelines.
> 2. Build a new production hierarchy (including new HSMs, keys, roots, etc.)
> and then re-apply for inclusion into the Mozilla root program.
> 3. Once approved then you can cross-sign your roots with another CA.
> 
> While this is happening. You can resell certificates from other CAs and build
> up trust in the industry which will benefit you in the long term I feel.
> 
> James
> _______________________________________________
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to