Hi Andrew,

Thank you for your questions/suggestions. Let me answer

1.- We removed the ability to the CA administrator as a role to issue
certificates, independently who´s assigned to that role. In the explanation
I tried to detail exactly what happened and who did it (not to blame on
them) and those two were asigned as CA administrators. So now, none can
issue certificates directly from the EJBCA.

2.- This error happened when testing the CT behaviour and since then,
nothing happened. Those were tests. The EJBCA system controls this and all
the pre-certs generated mean the issuance of those certs. 

3.- Hopefully yes. This is our intention. Primekey was delayed a little bit
and we´re somehow in a rush for making the upgrade but we want to meet that
deadline. Just in case, Primekey provided a manual checking of the CAA but
our aim is to upgrade to the new version and use it. I´m afraid all EJBCA
customers are in the same situation.
Regarding the CAA test suite, we haven´t had time to test it but we´re going
to test it.

4.- Yes, the use of those tools are performed after the issuance and the
goal is that if this happen, a mis-issuance, be quick enough to react
promptly and if possible, even before the customer can retrieve the
certificate, revoke timely and start the investigation.
And yes, I´ve been reading the email from Rob and I think it´s a very good
idea. In fact, we´ve scheduled for next week if possible (after the upgrade
to EJBCA 6.9.0) or the following one depending on how the CAA works once put
in production. I´ll keep this list informed of the progress.
We asked Primekey to include this kind of tools or similar before or after
the issuance but there´s no such feature at the moment.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-----Original Message-----
From: Andrew Ayer [mailto:[email protected]] 
Sent: lunes, 4 de septiembre de 2017 18:06
To: Inigo Barreira <[email protected]>
Cc: [email protected]
Subject: Re: StartCom communication

On Mon, 4 Sep 2017 12:10:19 +0000
Inigo Barreira via dev-security-policy
<[email protected]> wrote:

> [...]
>
> a. Test certificates
> 
> It__s been detailed in bugzilla #1369359. There__s an attachment with 
> a detailed explanation what happened, when, who, what was done to 
> remediate and to avoid it happening in the future. Those certs were 
> all the time under our control and lived for some minutes while 
> testing the CT behaviour.
> 
> Actions: removed issuance rights for the CA administrator

Could you clarify whether you removed the issuance rights of the particular
administrator who issued the test certificates, or if you removed the
ability for administrators in general to issue certificates bypassing
technical controls?

Considering that your incident report names the CA administrator and
internal checker 10 times each, and states the reason for the incident as
"Operators of EJBCA server didn't follow the operating protocol of
StartCom", one could conclude that StartCom sees its failures as a problem
with individual people, rather than a systemic problem of insufficient
technical controls.  What has StartCom done to correct this?


> b. Pre-certificates
> 
> It__s explained in bugzilla #1386894. Perhaps I was wrong with the 
> word __intent__ and then no need to revoke as they were not real 
> certificates, but once we had to do it, had to work with Primekey to 
> revoke those certs, because they didn__t exist for the EJBCA system as 
> they only have certificates, not pre-certificates.

What has been done to fix the underlying issue so that in the future you
won't create a pre-certificate unless you really intend to issue the final
certificate?

> [...]
> 
> a. apply newest version of EJBCA v6.9.0
> 
> Primekey has just released the new version of EJBCA, v6.9.0 (end of 
> august).
> 
> This new version comes with some important improvements, such as:
> 
> -          CAA automatic checking
> 
> -          Perform public key validation (RSA and ECC) 
> 

Will EJBCA 6.9.0 be deployed by September 8, when CAA checking becomes
mandatory? If not, how will you be checking CAA on September 8?

Does your/EJBCA's implementation of CAA pass the test suite I recently
posted to the CABF list? https://caatestsuite.com/

> b. integrate cablint/x509lint in CAProxy
> 
> These tools have been integrated at the issuance process. We__ll check 
> all certificates issued and will send an email internally to act 
> accordingly, i.e, revoking the cert and to start an inmediate 
> investigation of the error.

This is a good step, but it's too late to stop the misissuance.
Instead, you should check the TBSCertificate, and not sign if there is an
error.

Regards,
Andrew

> [...]

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

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

Reply via email to