On Friday, September 15, 2017 at 12:30:00 PM UTC+1, James Burton wrote:
> On Friday, September 15, 2017 at 10:56:11 AM UTC+1, Inigo Barreira wrote:
> > > 
> > > > 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, 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. 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 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

Hi Inigo,

To add from the last post.

I know this is unwelcome news to you but I feel that with all these incidents 
happening right now with Symantec and the incidents before, we can't really 
take any more chances. Every incident is eroding trust in this system and if we 
want more people to take up adoption of https in the long term, I feel that we 
need to start operating infrastructure above board and without issues.

James
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy

Reply via email to