RE: Increasing number of Errors found in crt.sh

[Inigo Barreira via dev-security-policy]

And checking this site, how can Comodo have more certs with errors (15030) than 
certs issued (15020). 

Regards

From: dev-security-policy  on 
behalf of Adriano Santoni via dev-security-policy 

Sent: Monday, October 01, 2018 10:09 PM
To: Rob Stradling; Doug Beattie
Cc: mozilla-dev-security-policy
Subject: Re: Increasing number of Errors found in crt.sh

I also agree.

As I said before, that's a non-trusted certificate. It was issued by a
test CA that does /not/ chain to a public root.


Il 01/10/2018 16:04, Rob Stradling ha scritto:
> On 01/10/2018 15:02, Doug Beattie via dev-security-policy wrote:
>> Hi Adriano,
>>
>> First, I didn't mean to call you out specifically, but you happened
>> to be
>> first alphabetically, sorry.  I find this link very helpful to list
>> all CAs
>> with errors or warnings: https://crt.sh/?cablint=1+week
>>
>> Second, How do you define a "test CA"?  I thought that any CA that
>> chains to
>> a public root was by definition not a test CA,
>
> I agree with that.
>
>> and since the issued cert was
>> in CT logs, I assumed that your root was publicly trusted. Maybe I'm
>> mistaken on one of these points
>
> Actually, some non-publicly-trusted roots are accepted by some of the
> logs that crt.sh monitors.
>
>> Doug
>>
>> -Original Message-
>> From: dev-security-policy
>>  On
>> Behalf Of Adriano Santoni via dev-security-policy
>> Sent: Monday, October 1, 2018 9:49 AM
>> To: dev-security-policy@lists.mozilla.org
>> Subject: Re: Increasing number of Errors found in crt.sh
>>
>> Thank you Rob!
>>
>> If I am not mistaken, it seems to me that we have just 1 certificate
>> in that
>> list, and it's a non-trusted certificate (it was issued by a test CA).
>>
>>
>> Il 01/10/2018 15:43, Rob Stradling via dev-security-policy ha scritto:
>>> On 01/10/2018 14:38, Adriano Santoni via dev-security-policy wrote:
 Is it possible to filter the list https://crt.sh/?cablint=issues
 based on the issuing CA ?
>>>
>>> Yes.
>>>
>>> First, visit this page:
>>> https://crt.sh/?cablint=1+week
>>>
>>> Next, click on the link in the "Issuer CN, OU or O" column that
>>> corresponds to the issuing CA you're interested in.
>>>
 Il 01/10/2018 15:26, Doug Beattie via dev-security-policy ha scritto:
> Hi Wayne and all,
>
>
> I've been noticing an increasing number of CA errors,
> https://crt.sh/?cablint=issues  Is anyone monitoring this list and
> asking
> for misissuance reports for those that are not compliant? There
> are 15
> different errors and around 300 individual errors (excluding the
> SHA-1
> "false" errors).  Some CAs are issuing certs to CNs of localhost, are
> including RFC822 SANs, not including OCSP links and many more.
>
> -  Actalis,
>
> -  Digicert,
>
> -  Microsoft,
>
> -
>
>
> There are also some warning checks that should actually be errors
> like
> underscores in CNs or SANs.
>
>
> Doug
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: PROCERT issues

[Inigo Barreira via dev-security-policy]

Has this been asked ever? Has any other CA published it? It´s just to know. 
And, is there a "default" scope for this kind of security audits?

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy
> Sent: jueves, 5 de octubre de 2017 11:48
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: PROCERT issues
> 
> On 05/10/17 15:32, Inigo Barreira wrote:
> > I know this reply is not related to the email thread but wouldn´t like
> > to leave the feeling that the code we are using is bad, or not secure, etc.
> 
> Perhaps now might be a good time to publish the security audits that were
> done on the code, then?
> 
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: PROCERT issues

[Inigo Barreira via dev-security-policy]

> 
> For example, I think there is wisdom in what Ryan says about setting an
> amount of time before a company can re-apply. In the case of StartCom we
> did not set such a time, because I had thought they might do what I
> recommended, which was to switch back from the new WoSign infra that we
> didn't trust to the original StartCom infra, which we did. However, they
> instead chose to implement new infra from scratch and rushed it, with the
> result being the use of PHP, the use of coders without sufficient training
in
> security, and some terrible code written under extreme time pressure
driven
> by commercial considerations.
> 

All that "terrible" code written was before we went live and before we
applied for re-inclusion.
That´s not the code we use to issue certificates, in fact, the hierarchy was
not built at that time so with this comment people may think that we´re
using a bad code which is not true. What it´s true is that we wanted to
re-apply the sooner because yes, we had some commercial issues, and we did
have a timeline, which was 6 months.
The reason for not using the old startcom code was due to some past issues
arised during the time but the new code is much more secure than the old one
and with more functionalities as have been explained.
The misissuances we´ve made were before the re-application and none due to a
bad code.
I know this reply is not related to the email thread but wouldn´t like to
leave the feeling that the code we are using is bad, or not secure, etc. 


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

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

Hi Gerv

> 
> But once the cross-signed cert is publicly available (and it is; it's in CT,
> however it got there), all of those certificates become trusted (or 
> potentially
> trusted, if the owner reconfigures their webserver to serve the intermediate,
> or if Firefox has already encountered it in the current browsing session).
> 

True

> > This is something I don´t understand. Why do you say the audits I
> > presented don´t meet the BRs? Because of the findings? The auditors
> > indicate those were fixed
> 
> I don't believe there's a formal way for an auditor to bindingly say "by the
> way, the problems we found have since been fixed" in an audit report.

Not bindingly, we provided a CAP (Corrective Action Plan) for all those 
findings indicated what we did to fix them and provided the evidences and what 
we were going to do for those that couldn´t be fixed before receiving the 
report.  

 
> But to help me understand: exactly what statement on what page of your audit
> report(s) are you referring to here?

It´s in a section called "other questions" in which they say "Startcom has 
developed a plan of corrective actions with the objective of solving the 
identified exceptions, having been implemented the majority of these actions".

> 
> > About the remediation steps, well, I answered the bug about it providing all
> the info and yes, you haven´t answered yet nor to approve nor to deny.
> 
> Right. So why are you proceeding?
> 
> You might reasonably complain it's taken us a while to respond to that
> comment about the steps. Yes, it has. The Mozilla inclusion process is slow. 
> :-(

Well, because I wanted to speed up the process if possible. We did everything 
what was requested and replied the bug. And also applied for the inclussion and 
none said nothing about it. Kathleen told me that it was going to be slow 
because the queue was long so I was waiting, no problem, but didn´t know that 
need to ask permission for applying.

> 
> >>> In fact, recently, I asked for permission to use the Certinomis
> >>> cross-signed
> >> certificates and have no response. I don´t know if this is an
> >> administrative silence which may allow me to use it but until having
> >> a clear direction we haven´t used it.
> >>
> >> Can you remind me how you asked and when?
> >
> > It was in an email of sept 4th, titled "StartCom communication" in
> > which at the end of the long email I asked for feedback to use the
> > cross-signed certificates and give additional explanations
> 
> I have no record of any email with that title, or any email from you between
> 15th August ("Re: Problem Reporting Mechanism") and 11th September ("Re:
> Remove old Startcom roots from NSS"). Where did you send it?

I sent it to the m.d.s.p list and got a reply from Andrew Ayer almost 
inmediately. 

> 
> Gerv


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

RE: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

> 
> I want to give you some words from one of the "community side" (this is a
> personal opinion and may vary from other opinions inside the community).
> 
> Trust is not something that you get, it is something that you earn.

True

> StartCom was distrusted because of serious issues with their old PKI and now
> had the chance to restart - there are serious issues again. I don't think that
> the "community" wants rogue CAs on its list just because they restarted with
> new certificates.
> 
> - The fact that you were cross-signed by Certnomis before you had valid
> WebTrust Audits and the permission to issue trusted certificates again and
> that the only thing which prevented you from using the trust path is a PUBLIC
> certificate? Is the only thing that prevents me from entering your datacenter
> a sign which tells me not to do so and the fact that you did not tell me where
> your datacenter is located?
> 
> - Startcom operates/operated multiple CT Log Server itself. There is 
> absolutely
> no reason to use trusted certificates for testing purposes if he does have a
> testing infrastructure. It would be easy for you to add one of your testing
> roots to your CT Logs and then test your CT behaviour. I don't think that
> Googles CTs are different from your own ones. Though your certificates might
> not have been trusted at that time, they would be now and as Gerv said, test
> certificates are not allowed. If you did not care about compliance at that
> time, why should you care about it now?

Those certificates were not trusted at that time and can´t be now because they 
were revoked within minutes.

> 
> - There is a reason why Best Practices are called best practices. Why did you
> reuse your key in root and intermediate certificates? 
> Because there is nomoney for additional HSMs? Because you don't know how to 
> generate new
> keys? An explanation would be great.

A new thread has started about this. It´s not forbidden.

> 
> - P-521 are forbidden by Mozilla. Even if there is a discussion to change 
> this it
> does not allow you to take that as a permission to test it. The fact that 
> these
> certificates were reported as unrevoked at the time of reporting (as far as I
> remember) does imply that you do not monitor your certificate issuances for
> policy compliance at all. What do you do to ensure that all of your 
> certificates
> are compliant with all requirements at all times?

At the time of application, the certificates were revoked and countermeasures 
set and since then there´s no more issues. We have implemented cablint, crt.sh, 
... and some other tools into our issuance process and still trying to improve 
much more. 
I´m not trying to excuse we had issues but we corrected them.

> 
> - What internal audits have you done to ensure the integrity of your systems?
> If something so critically as the permission to issue certificates in EJBCA is
> only noticed after you explicitly looked for it, what happens if someone
> removes all of your security mechanisms? You will find that out too after you
> misissued thousands of certificates? Quis custodiet ipsos custodes.

Despite all the terrible systems we have, etc. we haven´t misissued thousands 
of certificates, nor hundreds. The issues we had, have been fixed.  Those test 
certs issued directly from the EJBCA was a mistake, explained many times. I 
have nothing to add to what I´ve already said. It was not a good decission, not 
a good practice, and it´s forbidden.

> 
> - The incidents with Diginotar should have made clear that secure, well
> audited and hardened code is absolutely necessary as well as reliable logs.
> The fact that these flaws where not found by your internal team and only
> discovered after an external company tested your systems is deeply
> concerning. What have you done now and what will you do to ensure that
> your systems won't be abused? How do you make sure that the code your
> people write in the future is safe and how do you detect security problems if
> you were unable to do so at the first time?

This is a different example, Diginotar was attacked and the attacker was able 
to enter in their systems, and this is not what happened with StartCom. As 
said, the code that went live is not the same that was audited the first time 
and has been improved since then. The audits are just for that, and we will 
continue doing yearly security audits to improve our systems.
> 
> Though I would love to see StartCom up and running again, I have to agree
> with James that all of these issues do not enwake trust into you and instead
> produce more uncertainties if StartCom is really able to run a PKI itself. 
> But as
> I said before, this is a personal opinion :)
> 
> 
> Am Freitag, 15. September 2017 16:38:25 UTC+2 schrieb Inigo Barreira:
> > > > Yes, you´re right, that was on the table and also suggested by
> > > > Mozilla, but the issue was that people from 360 are used to code
> > > > in PHP and the old one was in Java and som

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

> 
> Hi Inigo,
> 
> On 14/09/17 16:05, 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.
> 
> Is there any reason those tests could not have been done using a parallel
> testing hierarchy (other than the fact that you hadn't set one up)?

I think I provided the reasons. We were distrusted, not re-applied yet, those 
certs lived for minutes, ... So, I think these are the reasons. It´s not an 
excuse and we didn´t expect this maremágnum. There´s been long discussions 
about the harm long term certificates can make and asked CAs about short term 
to avoid damages. These certs, that it´s true was a mistake, only lived for 
minutes, so I don´t know what else I can add to this matter.

> 
> > Some of these "mis-issuances" were due to some incongruencies between
> > the BRs and the Mozilla policy, such as the use of different curves
> > (allowed by the BRs but not for some browsers),
> 
> But it is the job of a CA to be aware of browser policies.

Yes, you´re right. And it was my fault for not have checked in deep this 
particular one.

> 
> > As far as I know, the current manager of Startcom has not been previously
> accused of deception or bad action.
> 
> No, indeed. There is no accusation that you have been deceptive towards
> anyone.
> 
> > Yes, it´s not a policy violation. As explained, this was a problem in the 
> > EJBCA
> with the UTF8 encoding.
> 
> That was the reason for the revocation; it's not the reason for the key reuse.

Yes, right, but this is allowed afaik. It´s mentioned in the BRs.

> 
> >> * The WT/BR/EV audits on StartCom's website are significantly
> >> qualified, and they include lack of controls on issuance. They should
> >> have clean ones done before we permit any inclusion request to proceed.
> The qualifications include:
> >>
> >> - Risk analysis process defined but not implemented
> >> - Business continuity plan defined but not implemented
> >> - Audit logs not guaranteed to have integrity
> >> - Monitoring system cannot detect security-related changes to
> >>   Certificate Systems
> >
> > Yes, this is also true. Our webtrust audits have findings but those are not 
> > so
> significant according to the auditors who signed the reports, so I assume the
> auditors thought that the system is good enough to have the audit report in
> place.
> 
> I think lack of monitoring and lack of integrity of logs are serious issues.

There wasn´t a lack of integrity and monitoring, of course not. All PKI logs 
were and are signed, it´s just the auditors wanted to add the integrity to 
other systems which is not so clear that should have this enabled. For example, 
if you want to archive database information for not managing a big one, the 
integrity of the logs could be a problem when trying to "move" to an archive 
system. I had some discussions about the "scope" of the integrity. Regarding 
the monitoring, well, we monitor many things, in both data centers, 24x7, etc. 
For this specific issue, it´s true that we didn´t have it automatically but 
manually, but well, and we implement a solution, but this is not a lack of 
monitoring. I think the audits are to correct and improve the systems and don´t 
think any CA at the first time had everything correct. So, for example, I 
thought this finding was good because made us improve.

> Repairing them afterwards does not remove the uncertainty.

Well, then any issue that you could find, even repaired or fixed, does not 
provide you any security and hence you should not trust anyone. 

 
> If you said "I left the root certificate private key on a USB stick on the 
> desk in my unlocked
> office over the weekend - but it's OK, I've remediated the problem now, and
> it's back in the safe", that would not remove the uncertainty about whether
> someone had done something with it in the mean time.

Well, I don´t think this is the same "quality" of example.
> 
> > I don´t know how these you mention have applied, but I remember lots of
> issues regarding Google and the acquisition of the Globalsign roots and how
> they proceeded.
> 
> I think "lots of issues" is an overstatement. There was an issue regarding the
> scope of their audits which was raised publicly, but it was something that
> Google has explicitly sought our approval for in advance.

Yes, it´s an overstatement but similar to others. I said that I didn´t know 
what or how they had applied but you put them as examples and just wanted to 
indicate that there were discussions, so maybe was not so smooth, but again, I 
don´t know.

> 
> > Not sure about this. We were distrusted in october 2016, the new system
> started to operate in april 2017, which is not related to the old one which 
> has
> been switched off. None of the new certs are trusted in Mozilla Firefox and
> we notify our users so by messages in the web and applications.
> 
> I may have made a mistake here. I was under the impression that you had
> to

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

Well, the use of P-521 is not compliant to Mozilla but it is to the BRs, so 
don´t understand what you mean. I think we´re not the only one which has issued 
certs using P-521 for example, and I assume that all other CAs have tested, 
established and verified their certs are compliant.

We´re seeing everyone made mistakes, mis-issuances, and I think all have tested 
everything. Regarding the use of these curves, I think even Gerv said in August 
to leave the policy as it is, the BRs still allows the use. 

After checking that was “incorrect” we revoked the certs and set the new 
conditions not allowing them. Since July we don´t use these curves, which is a 
month before Mozilla decission.

 

Best regards

 

Iñigo Barreira

CEO

StartCom CA Limited

 

From: Alex Gaynor [mailto:agay...@mozilla.com] 
Sent: viernes, 15 de septiembre de 2017 16:32
To: Inigo Barreira 
Cc: Gervase Markham ; James Burton ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: FW: StartCom inclusion request: next steps

 

I'm fairly confused by your answers, if the only thing you tested in production 
was CT, why was the system issuing non-compliant certs? Why did production CT 
testing come before having established, tested, and verified a compliant 
certificate profile?

 

Alex

 

On Fri, Sep 15, 2017 at 10:35 AM, Inigo Barreira via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

> On 15/09/17 11:01, Inigo Barreira wrote:
> > 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.
>
> But surely CT testing is not the only sort of testing you've been doing?

Yes, this is the only test we did it in production

> E.g. you made some test certificates with different types of ECC curve, which
> you then had to revoke some of as against browser policies.

No, those weren´t tests. We allowed the use of curves permitted by the BRs but 
this issue came up in the mozilla policy (I think Arkadiusz posted) and I also 
asked about it in the last CABF F2F (I asked Ryan about it) and then, with that 
outcome and as the browsers didn´t accept them, we revoked and then not allow 
the issuance. I think the discussion is still active (i.e. the use of P-521).

> If these had been in a testing hierarchy there would have been no problem.
>
> CAs have been heavily criticised over the past few years for issuing test
> certificates in public hierarchies (see e.g. Symantec). The danger of doing so
> should be well known to all CAs by now.

Yes, I know. But the only testing we did in production was the one related to 
the CT.
>
> Perhaps once a test has been passed and checked in a testing system, and if
> the certificates concerned do not violate any policies, it could be repeated 
> on
> a production system to deal with any possible differences between the two.
> But starting with the production system is not a good idea.

True, but it seems you´re understanding that we have only a production system 
in which we test everything and this is not the case. Before moving anything 
into production, we have tested in development and in the QA system.
>
> Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org 
<mailto:dev-security-policy@lists.mozilla.org> 
https://lists.mozilla.org/listinfo/dev-security-policy

 



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

RE: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

> > Yes, you´re right, that was on the table and also suggested by
> > Mozilla, but the issue was that people from 360 are used to code in
> > PHP and the old one was in Java and some other for which they are not
> > so familiar and then was decided to re-write all the code in PHP
> > trying to keep the same functionality.
> 
> Given the quality of code produced,

I don´t think the quality of the code which is in production now is poor or of 
bad quality. It wasn´t good initially, that´s true, but not now.

> it might have been better in hindsight tohire Java experts to work on the old 
> codebase.

That was also on the table.

> 
> > Furthermore, with this decission, we also wanted to let the community
> > know that this is totally a new CA system in all aspects, nothing
> > related to the past, everything from scratch, so new coding, new
> > programming language, new PKI system, infrastructure, etc. hoping this
> > would make the community have a better impression of the new Startcom
> regarding the distrust issue.
> 
> "We rewrote everything from scratch" is not actually something which itself
> inspires confidence.

What I meant, is that we used a new programming language and then recoded.

 In the case of WoSign, it was required of them because
> their old code was clearly terrible and buggy. But the reason the result would
> have to be strongly audited (were they to
> reapply) is that new code is riskier than old, tried-and-tested code.
> 
> I don't know if I ever wrote it down anywhere, but I'm fairly sure that
> switching back from the WoSign codebase to the older StartCom codebase
> (i.e. reversing the change you made after the purchase) was my suggestion for
> how StartCom should proceed after the dis-trust event.

Yes, that was your suggestion.

> That doesn't mean you are required to take my advice,

Yes, I know

> but it might have beena hint that I wouldn't consider "hey, we rewrote 
> everything from scratch!" as
> a positive point.

Well, we thought that it could be. During the distrust issues, I think Ryan 
posted some old issues related to the old Startcom code or procedures (long 
time ago) and then recoding everything was our intent to give a positive 
answer. As said, the term "from scratch" maybe it´s not appropiate, but in the 
end this code has been audited. 
> 
> Gerv



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

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

> On 15/09/17 11:01, Inigo Barreira wrote:
> > 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.
> 
> But surely CT testing is not the only sort of testing you've been doing?

Yes, this is the only test we did it in production

> E.g. you made some test certificates with different types of ECC curve, which
> you then had to revoke some of as against browser policies.

No, those weren´t tests. We allowed the use of curves permitted by the BRs but 
this issue came up in the mozilla policy (I think Arkadiusz posted) and I also 
asked about it in the last CABF F2F (I asked Ryan about it) and then, with that 
outcome and as the browsers didn´t accept them, we revoked and then not allow 
the issuance. I think the discussion is still active (i.e. the use of P-521).
 
> If these had been in a testing hierarchy there would have been no problem.
> 
> CAs have been heavily criticised over the past few years for issuing test
> certificates in public hierarchies (see e.g. Symantec). The danger of doing so
> should be well known to all CAs by now.

Yes, I know. But the only testing we did in production was the one related to 
the CT.
> 
> Perhaps once a test has been passed and checked in a testing system, and if
> the certificates concerned do not violate any policies, it could be repeated 
> on
> a production system to deal with any possible differences between the two.
> But starting with the production system is not a good idea.

True, but it seems you´re understanding that we have only a production system 
in which we test everything and this is not the case. Before moving anything 
into production, we have tested in development and in the QA system. 
> 
> Gerv


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

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

> 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


James, I share with you this desire. But we´re seeing one day and another that 
issues are still happening, and not all are from StartCom :-) so to avoid 
eroding trust what do you suggest if not give more chances? Remove them all? 


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


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

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

> > >
> > > > 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


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

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

> 
> > 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).





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

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

> On 14/09/2017 17:05, Inigo Barreira wrote:
> > All,
> >
> > ...
> >>
> >> We should add the existing Certnomis cross-signs to OneCRL to revoke
> >> all the existing certificates. As of 10th August (now a month ago)
> >> StartCom said they have 5 outstanding SSL certs which are valid
> >> due to the Certnomis cross- sign.
> >
> > I´ve never said this. In fact, despite having that cross-signed which were
> provided to us in july we have never used and provided to any of our
> customers to build a trusted path. So none of those 5, or the new ones,
> go with the Certinomis path because none have it. But all those 5 certs
> are untrusted because we´re not in the Mozilla root, not the new one, and the
> old one was distrusted.
> > In fact, recently, I asked for permission to use the Certinomis cross-signed
> certificates and have no response. I don´t know if this is an administrative
> silence which may allow me to use it but until having a clear direction we
> haven´t used it.
> >
> 
> 
> I can't speak for Mozilla, but the obvious point is, that as soon as the cross
> certificate from Certinomis was published in CT-logs or elsewhere, any
> StartCom customer could (and still can) download it and install it on their
> server, thus activating the Certinomis path for their server.
> 

AFAIK, Certinomis only disclosed in the CCADB and even we received it, we have 
not sent to any customer nor posted anywhere. And I know crt.sh includes it and 
when questioned for it Rob answered that crt.sh includes all certs that have 
been submitted to one or more of the monitored CT logs, and includes all trust 
paths that can be built.
I don´t think any StartCom customer has downloaded from wherever it could be 
and installed and created the trusted path. Our customers base are not very 
familiar with this stuff. Usually we need to provide all of them with 
instructions on what and how to do it.

> 
> Enjoy
> 
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10 This
> public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

Yes, there are similar ones everywhere, so I´m familiar with it :-)
And you´re right, I also make contributions in many other places, ETSI, ENISA, 
CABF (used to), ... and not get paid for that, but it´s also true that the way 
the distrust happened didn´t give us time or much time to act accordingly, even 
now people is asking for the distrust or asking for refunds due to the 
distrust. 

And yes, we tried to do it quickly and we know what happened but we didn´t 
re-apply at that time. We got issues and until all of them were fixed and we 
receive the OK we didn´t move forward. We wanted to meet the deadline we 
imposed ourselves and even reached, it was not in a good shape, so, had to 
start again. And that´s what I said internally, that it didn´t matter if we 
could not make it in 6 months as indicated in the sanction and it took us 
nearly 10, taking into account that everything was new.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of Nick Lamb via
> dev-security-policy
> Sent: viernes, 15 de septiembre de 2017 1:22
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: FW: StartCom inclusion request: next steps
> 
> On Thursday, 14 September 2017 16:00:35 UTC+1, Inigo Barreira  wrote:
> > Well, finally this is a business and I don´t think none on this list is 
> > working
> for free. At the end everyone has his/her salary, etc. But that was not the
> main reason because getting included in the root programs takes time but
> wanted to provide our customers which gave us support for what happened
> with the distrust (which IMHO in the case of Startcom was very aggressive) a
> solution generating a new fresh and clean system.
> 
> I can't speak for other people contributing to m.d.s.policy but of course I am
> not paid to do this. I have a job, but it isn't this. I have never asked my
> employer's permission to contribute here, judging it to be entirely outside
> their purview. My job does include running a (small, private) CA, but then it
> also includes maintaining a DBMS, a web crawler and all sorts of other stuff,
> I'm sure it would be possible to identify some connection to my job for almost
> any technical contribution I could make anywhere.
> 
> There is an proverb in English, I am not sure if you're familiar with it, 
> "More
> haste, less speed". What this means is that in trying to perform a task as
> quickly as possible you may instead cause yourself such extra trouble that in
> the end the task takes even longer to complete. I am sure that even if you
> have not come across a phrase like this before you can see its applicability 
> to
> the situation for StartCom.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

Hi Percy,

Yes, you´re right, that was on the table and also suggested by Mozilla, but
the issue was that people from 360 are used to code in PHP and the old one
was in Java and some other for which they are not so familiar and then was
decided to re-write all the code in PHP trying to keep the same
functionality. Besides, the old code had to be integrated with the new PKI
infrastructure, EJBCA, and that was not an easy task.
All in all on the table, integration with new systems, maintenance of the
old code if issues arise due to this integration or any other problem, not
good language knowledge, get used to PHP, etc. made us took that decission. 
Furthermore, with this decission, we also wanted to let the community know
that this is totally a new CA system in all aspects, nothing related to the
past, everything from scratch, so new coding, new programming language, new
PKI system, infrastructure, etc. hoping this would make the community have a
better impression of the new Startcom regarding the distrust issue.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+inigo=startcomca@lists.mozilla.org] On Behalf Of Percy via
dev-
> security-policy
> Sent: jueves, 14 de septiembre de 2017 22:13
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: StartCom inclusion request: next steps
> 
> "Conclusion: StartCom's attempt to restart the CA was rushed."
> 
> "It was a very hard task in very few time but the people at 360 tried
> everything to get it done by that date, end of december 2016, and yes, we
> reached the date but with many failures"
> 
> May I ask why StartCom choose to rush everything in PHP from the ground up
> rather than using the more secure system already in place in the old
> StartCom?  From my understanding, the distrust of StartCom is more related
> to the secret acquisition by  WoSign an Qihoo 360 rather than insecure
> infrastructure. So if the deadline is so imminent as you stated and
pressure is
> so high from customers, can't you use the reasonably secure old code base
> rather than rushing everything from the ground up? Then you will have more
> time transition to another system if needed with sufficient time for
secure
> processes?
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


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

FW: StartCom inclusion request: next steps

[Inigo Barreira via dev-security-policy]

All,

Obviously this is not the message we would like to read and will try to explain 
and rebate as much as possible some of the comments posted here.

> 
> The Mozilla CA Certificates team has been considering what the appropriate
> next steps are for the inclusion request from the CA "StartCom".[0] As readers
> will know, this CA has previously been removed from trust[1], and so a re-
> application obviously involves particular scrutiny. In addition, several
> questions have been raised about the way in which the new StartCom PKI has
> been operated technically[2]. This is a proposal for the way forward, on which
> comments are invited.
> 
> Mozilla's considered view is as follows:
> 
> * It should have been obvious to StartCom that testing of their new systems
> needed to be done using a parallel testing hierarchy.

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.

 
> That it was not obvious, is deeply concerning. It is also concerning that 
> someone can sit at a terminal
> and issue random certificates with variable values in lots of fields, in what 
> is
> to become a publicly-trusted hierarchy.

Well, it was possible at that time, but only the CA administrator could do it 
and under many requirements. It´s not like sitting at a terminal and start 
issuing certificates, there were and are security mechanisms to avoid "someone" 
could do that and I can list many. Probably most of the CA administrators of 
the rest of CAs  had this capacity (maybe not now) because the majority of the 
PKI software allows it and it´s needed when building a hierarchy. 
 
> It's not about numbers (e.g. "40 out of 5"), it's about the process.
> 

This number of 40 is about the total of "mis-issuances" discovered, not only 
related to these ones for the CT testing. And some other times, discussed in 
this list, the number matters. Even more, for those 40, most of them were 
"discovered" by us and acted accordingly as per the BRs. We revoked the 
majority of them within the 24 hours of being notified internally. When those 
were posted in the bugzilla, as said, most were revoked and started the 
investigation on what happened and what actions needed to be done. Some of 
these "mis-issuances" were due to some incongruencies between the BRs and the 
Mozilla policy, such as the use of different curves (allowed by the BRs but not 
for some browsers), or about pre-certificates in which is not clear if they 
fall under what requirement as a discussion started by Jeremy on the list. For 
example, is it necessary to revoke also the pre-certificates when a certificate 
is revoked? Are they need to be considered certificates and meet the BRs and/or 
Mozilla policy?
Or about the use of Unicode vs punnycode which is still under discussions, even 
a ballot failed in the CABF. So, those errors we made were also made by some 
others, and not being as an excuse, but it seems that it was not clear for the 
CAs.

We updated our procedure issuance to avoid these issues happening in mid July. 
What did we do?
- Restrict the use of eliptic curves only to those admitted by Mozilla
- Change the certificate profile for not having differences with the key 
encipherment and key agreement
- update the internal db for country codes
- update the sytems for changing all domain names to punnycode
- and recently develop a csr checking tool to avoid the issue with RSA 
parameters because EJBCA didn´t have it at that time (it comes now with the new 
release 6.9.0)


> As JC Jones wrote:
> 
> "This is a professional PKI operation, being overseen by industry veterans. If
> something as concrete as the issuance process had such a glaring quality
> assurance methodology failure, why should anyone believe that something
> much harder -- subscriber validation -- is going to be done correctly?"

Well, this is an opinion. And I fully respect but none is free of failures and 
let´s encrypt (and many others) is also having them as we´re seeing recently 
with weak keys, etc. and I´m none to say they are not professional, or not 
having a quality assurance methodology, ... or for not believing they are not 
acting correctly. For sure they are, but same as us. I can´t critize anyone and 
not because we´re in a weak position at Startcom in which everyone is looking 
deeply what we do, scrutinizing deeply.
For all these failures we acted quickly because our internal proc

RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

[Inigo Barreira via dev-security-policy]

Thanks Quirin, we´re working with Primekey to know what happened (we´ll
generate a report once known) and will contact you if necessary to check
that info you have.

Regarding the logs, the log message actually means that CAA either
explicitly permitted the issuance, or implicitly permitted issuance (e.g. by
the lack of a CAA record, that according to this email that´s no the case).
We´re also checking if the DNS resolver server was caching the timeout
failure and sent a SERVFAIL or similar response the second time, rather than
letting the query time out again. But, as said, we´re still investigating
the issue.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Quirin Scheitle via dev-security-policy
Sent: martes, 12 de septiembre de 2017 20:30
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

Hi all,

Thank you for the replies. I am glad that there is agreement these
certificates should not have been issued. 

I am confident that the test behaved correctly, the last edit on the zone
file was on Aug 31 17:24, and it reads:

crossbear.org.  0   CAA 0 issue ";" 

So even if requests would somehow have gotten through the iptables rule
dropping them, it would definitely not have gotten a permitting record. 

I also have full pcaps from both name servers serving this domain and can
confirm that not a single query response was sent to any server on September
8th  and 9th.

crossbear.net is a different domain with a different configuration, it is
unrelated to this issue.

Inigo, I am very happy to debug this in detail offline -- I have plenty of
records and data to assist debugging. 

Kind regards
Quirin
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

[Inigo Barreira via dev-security-policy]

.net,C=DE;requestX50
0name=C=DE,O=TUM,CN=crossbear.org;subjectaltname=DNSNAME=crossbear.net;reque
staltn 
ame=;certprofile=2102604971;keyusage=-1;notbefore=;notafter=;sequence=;publi
ckey=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAm9PKsCgR0gsedHsp4UgQLzMc9uf
jZvOg5 
MkyB8H7DDjuSY3lxcjTMqWHzwMJyJT6q/seCehfXaZ069CQt1vakgvyFhNZT4DhL52FPN3L+EqFI
erT9dUH60aL/bssDZ+L1vJ0R1+1vbM/8ZELPl1zrqhaZInMWvp3odxlhT/MXNR1NFZ4GMctWYyxq
Xg1N94 
eQ1HoG18ssVEZx21La6f+DXldxhUHhJUW6H1v+lSpXA32MMytJ9EfIhl5pGFkIz/hx4T9CNSgxId
/qEE2Z5rbl9+vmkjmk5ZqEGOwUlgxxjTVtjp5qJ4TJrtRxu2spKtovvY+b2z4bHT7EjYbBXx00QI
DAQAB 
14:41:00,905 INFO [org.ejbca.util.validation.caa.CaaDnsLookup]
(http--0.0.0.0-8443-1) Found CAA Record for domain crossbear.net.:
crossbear.net. 
  252 IN CAA 0 issue ";" 
14:41:00,905 INFO [org.ejbca.util.validation.caa.CaaDnsLookup]
(http--0.0.0.0-8443-1) Found CAA Record for domain crossbear.net.:
crossbear.net. 
  252 IN CAA 0 iodef "mailto:c...@crossbear.net"; 
14:41:00,906 INFO [org.cesecore.audit.impl.log4j.Log4jDevice]
(http--0.0.0.0-8443-1) 2017-09-09
14:41:00+08:00;VALIDATOR_VALIDATION_FAILED;FAILURE;VALIDATOR; 
CORE;CN=ejbcaws,C=CN;-366638826;;crossbear.net;msg=CAA Validator
'CAAValidator' failed issuance of certificates to issuer startcomca.com.

We´ll keep investigating this.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Inigo Barreira via dev-security-policy
Sent: martes, 12 de septiembre de 2017 12:44
To: Nick Lamb ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

Ok, let me investigate this further, maybe I didn´t catch it rightly.
For the record, the certificate was revoked

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Nick Lamb via dev-security-policy
Sent: martes, 12 de septiembre de 2017 12:26
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira  wrote:
> Futhermore, according to the logs, at the time of checking for a CAA
record, there was none. The lookup was succesful and hence allowed the
issuance.

Given that this contradicts the facts alleged in Quirin's tests and the
feedback from BuyPass I would strongly recommend doing further testing to
ensure that StartCom's systems detect [and log] timeouts and other failures
properly for CAA records. I'm sure Quirin will try to offer reasonable
assistance in reproducing the problem.

It is definitely worth noting that with DNSSEC _enabled_ a CA ends up having
cryptographic proof of their results - which could be recorded in case of
any dispute. If you had such proof for the permissive CAA record we wouldn't
need to investigate StartCom's systems or policies, we could examine the
record and conclude that Querin made an error somewhere and permitted this
issuance without knowing anything about StarCom or needing to take you at
your word.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

[Inigo Barreira via dev-security-policy]

Ok, let me investigate this further, maybe I didn´t catch it rightly.
For the record, the certificate was revoked

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Nick Lamb via dev-security-policy
Sent: martes, 12 de septiembre de 2017 12:26
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

On Tuesday, 12 September 2017 10:38:56 UTC+1, Inigo Barreira  wrote:
> Futhermore, according to the logs, at the time of checking for a CAA
record, there was none. The lookup was succesful and hence allowed the
issuance.

Given that this contradicts the facts alleged in Quirin's tests and the
feedback from BuyPass I would strongly recommend doing further testing to
ensure that StartCom's systems detect [and log] timeouts and other failures
properly for CAA records. I'm sure Quirin will try to offer reasonable
assistance in reproducing the problem.

It is definitely worth noting that with DNSSEC _enabled_ a CA ends up having
cryptographic proof of their results - which could be recorded in case of
any dispute. If you had such proof for the permissive CAA record we wouldn't
need to investigate StartCom's systems or policies, we could examine the
record and conclude that Querin made an error somewhere and permitted this
issuance without knowing anything about StarCom or needing to take you at
your word.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

[Inigo Barreira via dev-security-policy]

Hi Quirin,

I was going to reply to your email after investigating what happened, but since 
you´ve posted here, I can share it.

I think most of the CAs are strugling with the DNSSEC interpretation or how to 
solve some of the issues.
In our case, I can tell the following:

The DNSSEC checking is optional, and at the time of the request we had it 
disabled so we didn´t check it. According to the logs, this cert was requested 
at 2017-09-09 11:44 GMT+8 and we enabled it a little bit later 2017-09-09 17:41 
GMT+8. As we have had some other issues with the DNSSEC, we have disabled it 
again and are dealing with Primekey to have a better approach to this issue. 
Futhermore, according to the logs, at the time of checking for a CAA record, 
there was none. The lookup was succesful and hence allowed the issuance.

Regarding to your question, I think you´re right and this certificate should 
have not been issued but it´s also true that having the DNSSEC checking 
optional, this can happen.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of Quirin Scheitle via dev-security-policy
Sent: martes, 12 de septiembre de 2017 0:24
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: (Mis)-Issuance on CAA Timeout in DNSSEC signed zone

Hi,

inspired by the ballot paragraph [1], I set up a domain that is fully DNSSEC 
signed [2], but does not reply to CAA queries (timeout). 

I could obtain certificates for this domain from Buypass and Startcom [3].
Other CAs (RapidSSL, GeoTrust, LetsEncrypt) have refused to issue, and GoDaddy 
and Certum have been stuck in "Pending" for days and will likely not issue.

Per my interpretation, and per the discussion in the other CAA/DNSSSEC thread, 
I believe those should not have been issued. I have reported this to the 
issuing CAs. 

What do you think?

Kind regards
Quirin


[1] CAs are permitted to treat a record lookup failure as permission to issue 
if:

the failure is outside the CA’s infrastructure;
the lookup has been retried at least once; and
the domain’s zone does not have a DNSSEC validation chain to the ICANN root.

[2] https://dnssec-debugger.verisignlabs.com/crossbear.org
[3] https://crt.sh/?q=crossbear.org
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Hi Gerv,

Those updates are referred basically to the format of the report in which
Franck asked to include specific information such as the serial number,
names, etc. according to your instructions. The report itself has not been
changed (that´s forbidden).

Regarding the qualifications or findings, the majority of them were fixed at
that time as the auditors explain in the section "other questions". There
were only 2 pending, the BCP and the TSA, which have been finished and do
not affect to the validation&issuance processes.
I can provide responses to all those findings, as I did to the auditors,
with evidences. 

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: lunes, 11 de septiembre de 2017 13:27
To: Franck Leroy ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

Hi Franck,

On 03/08/17 08:59, Franck Leroy wrote:
> On end of June the audit report form PwC was available but with still some
minor issues. I asked StartCom to correct them.
> 
> On July 14th the audit report and the policy were updated and published on
StartCom website.

The audit reports on StartCom's website
 are dated at the end of June, and have
significant qualifications. E.g.:
https://www.startcomca.com/pwc-webtrust-ca-2017.pdf

What updates to the audit reports were made on July 14th?

Do you consider these audit reports sufficient to say the StartCom has
passed these audits, despite the qualifications therein?

Gerv

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


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

RE: StartCom communication

[Inigo Barreira via dev-security-policy]

Andrew et al,

Just to inform that we have upgraded the EJBCA release to 6.9.0 in
production this early morning and the CAA checking is working fine, as
showed in the EJBCA´s logs. 

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Inigo Barreira via dev-security-policy
Sent: lunes, 4 de septiembre de 2017 18:40
To: Andrew Ayer 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: RE: StartCom communication

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:a...@andrewayer.name]
Sent: lunes, 4 de septiembre de 2017 18:06
To: Inigo Barreira 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom communication

On Mon, 4 Sep 2017 12:10:19 +
Inigo Barreira via dev-security-policy
 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

RE: StartCom communication

[Inigo Barreira via dev-security-policy]

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:a...@andrewayer.name] 
Sent: lunes, 4 de septiembre de 2017 18:06
To: Inigo Barreira 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom communication

On Mon, 4 Sep 2017 12:10:19 +
Inigo Barreira via dev-security-policy
 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

> [...]


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

StartCom communication

[Inigo Barreira via dev-security-policy]

Hi all,

 

I´ve realized that there has not been a good communication path to announce
all the tasks and actions performed by StartCom during this time and this
email will try to remediate it. I´d also like to ask you for some feedback,
comments and/or suggestions on how to improve. I think we´ve done a great
effort and developed a robust system but it´s also true that we have had
some errors even though all were fixed timely (despite the discussions that
are still alive regarding some of them) and put all the countermeasures
needed for not happening again. 

 

Thanks for all your suggestions and comments. I will try to summarize
everything.

 

Areas

 

1. Remediation plan

 

a. Legal structure and management separation

b. operations separation

c. system separation

d. CT logging

 

2. Mozilla requirements (bugzilla #1311832)

 

a. provide a list of changes

b. implement changes and update CP/CPS, stating explicitly backdating is
prohibited

c. providing full webtrust audit

d. security audit

e. All certs CT logged, if possible not using own CT log

 

3. Issues

 

a. test certificates

b. pre-certificates for test certificates

c. use of specific curves not allowed by Mozilla but BRs

d. Country code

e. RSA parameters

f. Unicode vs punnycode

 

4. Improvements

 

a. apply newest version of EJBCA v6.9.0

b. integrate cablint/x509lint in CAProxy

c. check of CSRs

d. integrate crt.sh in database

 

 

1. Remediation plan

This is what StartCom planned to do and was indicated last year in October.
It was presented to Mozilla and also in an email sent to the m.d.s.p

These are the main tasks performed, which are also included in bugzilla
#1311832

 

a. Legal structure and management separation

StartCom HK, which is the main head of the group, is owned 100% by Qifei
International development Co. Ltd in HK, which is also controlled 100% by
360 technology Inc. In november 2016, there were some news indicating the
completed transer of 100% shares from WoSign to Qihoo 360, so StartCom
officially became a wholly owned subsidiary of Qihoo 360.

So, there´s no control from Wosign related to StartCom.

 

StartCom has offices at China, UK, Israel and Spain.

Besides there was a change in the management in which Xiaosheng Tan of 360
was named chairman of the board and Iñigo Barreira, CEO.

Richard Wang has no relation, control nor influence in StartCom. It was
removed from the StartCom directors at the UK office last year. (Note:
recently had to be named again due to some issues related to the bank that
have been already fixed and hence removed again)

 

b. Operations separation

All operations are performed by Startcom employees, from own premises.
There´s no relation at all with any other Wosign operations or departments.

All validations, support and customer service is provided by StartCom. 

Besides StartCom signed a contract with 360 to provide hosting services of
the PKI infrastructure (CA, VA, TSA, CT, CMS, HSM, web,…), maintenance and
support, as well as developing, testing, etc.

 

c. System separation

All systems used for the PKI has been updated or directly changed and all
are hosted in 360 premises as stated above. 

 

Web and CMS have been totally updated, recoded under another programming
language, PHP, for which 360 is more familiar with. This coding has been
performed by the 360 R&D team and checked later by its security team. Cure53
was the firm hired for the security audit.

 

OTOH, StartCom finally decided to acquire the Primekey´s PKI solution,
EJBCA. We considered a significant step forward use this commercial PKI
software, well known in the industry.

Furthermore, the StartCom OCSP also uses the Akamai CDN as well as some
other services.

 

d. CT logging

StartCom logs all SSL issued certificates in CT logs. Currently we´re using
Google CT logs and also StartCom CT log.

We´re also planning to use Comodo CTs Mammoth and Sabre as well as the new
Venafi one.

 

2. Mozilla requirements (bugzilla #1311832)

 

a. provide a list of changes

The remediation plan was the whole list of changes that were presented to
Mozilla and they were agreed with that plan.

 

b. implement changes and update CP/CPS, stating explicitly backdating is
prohibited

All those changes have been implemented as per the remediation plan stated
above. The CPS was updated accordingly

 

c. providing full webtrust audit

The full webtrust audits have been performed by PwC. StartCom did a Webtrust
for CA, webtrust BR, webtrust EV and webtrust for CS. There were some
findings, which are reflected in the reports, but most of them were fixed.
Right now only the configuration of the TSA and the update of the Business
Continuity Plan are delayed, which in any case, will be finished soon. 

 

d. Security audit

For the security audit Mozilla recommended 2 firms they worked with them in
the past and finally hired Cure 53. 

 

e. All certs CT logged, if possible not using own CT log

StartCom logs all the SSL c

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Can this be responded to more directly and comprehensively please?

Are there any staff or personnel being shared between WoSign and Startcom?
No

This includes any staff from (or paid by) Qihoo 360 its subsidiaries, 
contractors, or affiliates--does anyone do any work (paid or unpaid) for both 
Wosign and Startcom?
No

Are there any personnel switching between WoSign and Startcom?
No
 



On Tuesday, August 8, 2017 at 4:39:39 AM UTC-4, Inigo Barreira wrote:
> Hi,
> 
> 1.- yes, I said many times that it was not a good decission and of 
> course not the best way to start, but at all times these test certs 
> were under control, lived only for some minutes. Everything was 
> explained in bugzilla #1369359
> 
> 2.- Those pre-certificates were related to these test certificates for the CT 
> testing, and yes, technically they didn´t exist for EJBCA, so we were dealing 
> with them on how to revoke them without issuing them wrongly and finally got 
> a solution, and then inmediately revoked them.
> 
> So, these two issues were related to the same generic problem, the CT 
> testing, which was only for Chrome compliance, but that were all the time 
> controlled by us. It was a bad practice that it´s not happening again with 
> the countermeasures set as explained. 
> 
> 3.- No, there´s nothing related to Wosign nor Richard Wang. As indicated in 
> our remediation plan, 360 owns 100% of StartCom and we´ve performed all the 
> changes proposed there to have nothing related to Wosign nor Richard. This is 
> indicated in bugzilla #1311832 and also in the remediation plan delivered 
> last year.
> Also in our remediation plan, there was a chart in which was indicated how 
> the Company is structured, and in the case of StartCom Spain, this is 100% 
> owned by the StartCom UK, and I´m director in both offices.
> 
> And the reason why Richard Wang is director again in StartCom UK is due to 
> some bank issues. Richard was removed as director of the StartCom UK at that 
> time, but didn´t realize about his signatory rights in the UK bank account. 
> We thought we could change that easily but was not possible. We´ve been 
> dealing with our lawyers, Alliotts, and finally agreed that signing again 
> Richard was going to be quicker and easier. I had planned to go to London for 
> changing it end of july, beginning of august but due to some personal 
> matters, it was imposible and have had to delay until September. Once we 
> finish this bank issue, Richard will be removed again.
> In any case these are internal issues that don´t affect the PKI itself, these 
> are administrative tasks, but the fact that Richard is again director in 
> StartCom UK is just for this matter and has no other responsibility or 
> function within StartCom.
> 
> 
> Let me know if you need more clarification or have some other doubts 
> or questions
> 
> Best regards
> 
> Iñigo Barreira
> CEO
> StartCom CA Limited
> 
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+inigo=startcomca.com@lists.mozilla
> .org] On Behalf Of Jakob Bohm via dev-security-policy
> Sent: lunes, 7 de agosto de 2017 22:03
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: StartCom cross-signs disclosed by Certinomis
> 
> On 07/08/2017 11:21, Franck Leroy wrote:
> > Hello
> > I see many reactions that are not in line with the reality because you 
> > don’t have all the history on the subject.
> > I’ll try to summarize.
> > Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque 
> > Country) and he left this company in order to join StartCom.
> > Not long after he arrives at StartCom (days? Weeks? I don’t know) we 
> > discover the deal that has been made by the previous CEO (Eddy Nigg) with 
> > the Chinese’s guys and the relations with WoSign.
> > Inigo could have resign in regard to the trap the hiring was, but he 
> > decided to face, and to setup the remediation plan defined by Mozilla 
> > community.
> > As said Jon Snow in S07E01: “I will not punish a son for this father’s 
> > sins”.
> > So instead of denigrate Inigo’s work, as a community we should encourage 
> > and support him.
> > Setting up a new company, with a new datacentre, new pki software, 
> > NO client, NO revenue, with Chinese employees far away speaking not fluent 
> > English and with the pressure of the market, it is definitely not an easy 
> > task! Personally I would not have tried this, so bravo for Inigo’s bravery… 
> > One of the major thing to solve in addition of the remediation plan was to 
> > be back in the business as soon as possible, because without any incomes a 
> > company cannot survive.
> > So Inigo contacted me to know if Certinomis could help him to be back in 
> > the business. As you can imagine we did not said yes immediately.
> > But Inigo is not an anonymous guy coming from a strange area of Spain. He 
> > has been for many years an active CABForum member. He is also an active 
> > expert at ESTI, 

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Hi Percy,

StartCom Spain exists since september last year. And it was included in the
remediation plan set in October last year, but at the time Gerv wrote that
email it didn´t exist officially, it took a while to be registered
officially in the "equivalent" spanish companies house.
The process started in august, it´s typically a holiday month, and it took
longer than expected because there were some organizations closed or with
few people working.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Percy via dev-security-policy
Sent: martes, 8 de agosto de 2017 2:39
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On Monday, August 7, 2017 at 2:36:10 PM UTC-7, Itzhak Daniel wrote:
> On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: 
> > 7. At Quihoo: Actually get rid of Richard Wang, not just change his
> >title from CEO to COO.
> 
> I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA
Spain Sociedad Limitada"), having trouble registering to the Spanish company
house and pull documents (I pulled from 3rd party, but they're garbage [1]
[2]). I did mange to see that Mr. Barreira is the Directory but nothing on
the share holders or parent company.
> 
> I took a quick look at StartCom UK (as the information there is free) and
noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA
Spain Sociedad Limitada" parent/share holder, maybe a disclosure?
> 
> Links:
> 1. https://www.letsphish.org/files/StartCom-CA-SPA-Appointment.pdf
> 2. https://www.letsphish.org/files/StartCom-CA-SPA-Profile.pdf
> 3. https://beta.companieshouse.gov.uk/company/09744347

StartCom CA Spain Sociedad Limitada was not in the original hierarchy [1] or
the proposed hierarchy [2] . I request that StartCom makes a full disclosure
of the ownership information. 

In addition, in the WoSign remediation plan, WoSign Stated[3] that 

Due to the severity of issues noted within, the decision has been made to
address the above three areas as they fall under the areas of 1)
leadership/authority in WoSign and StartCom, 2) operational/business process
and 3) technology. 

If WoSign/Startcom has determined leadership/authority is the No.1 cause of
issues, why is Richard Wang appointed as a director of StartCom merely 6
month after his removal? This doesn't even mention his COO role at WoSign. 

[1]
https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/start
com%7Csort:relevance/mozilla.dev.security.policy/0pqpLJ_lCJQ/z69lmZ88DwAJ
[2]https://en.wikipedia.org/wiki/StartCom#cite_note-structure201612-9
[3]https://www.wosign.com/report/WoSign_Incident_Report_Update_07102016.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Hi,

In the remediation plan that was published in October there was a chart in
which was indicate how the group was going to change, from WoSign management
to be under 360 management. I can provide the information again if you wish.

StartCom Spain is 100% owned by Startcom UK, which is also 100% owned by the
Startcom HK which is the head of the group. Over this, there´s 360 managing
it all. I don´t think I have to share here the notary papers but this is how
it´s structured now.
About the incorporation of Richard, I already explained the reason, it´s
just a bank issue and it´s just temporary until we can change the signatory.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Itzhak Daniel via dev-security-policy
Sent: lunes, 7 de agosto de 2017 23:36
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On Monday, August 7, 2017 at 11:03:27 PM UTC+3, Jakob Bohm wrote: 
> 7. At Quihoo: Actually get rid of Richard Wang, not just change his
>title from CEO to COO.

I didn't map the new hierarchy of the "Spanish" StartCom CA ("StartCom CA
Spain Sociedad Limitada"), having trouble registering to the Spanish company
house and pull documents (I pulled from 3rd party, but they're garbage [1]
[2]). I did mange to see that Mr. Barreira is the Directory but nothing on
the share holders or parent company.

I took a quick look at StartCom UK (as the information there is free) and
noticed Mr. Wang became a director again [3]... I wonder who is "StartCom CA
Spain Sociedad Limitada" parent/share holder, maybe a disclosure?

Links:
1. https://www.letsphish.org/files/StartCom-CA-SPA-Appointment.pdf
2. https://www.letsphish.org/files/StartCom-CA-SPA-Profile.pdf
3. https://beta.companieshouse.gov.uk/company/09744347
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Hi, 

1.- yes, I said many times that it was not a good decission and of course not 
the best way to start, but at all times these test certs were under control, 
lived only for some minutes. Everything was explained in bugzilla #1369359 

2.- Those pre-certificates were related to these test certificates for the CT 
testing, and yes, technically they didn´t exist for EJBCA, so we were dealing 
with them on how to revoke them without issuing them wrongly and finally got a 
solution, and then inmediately revoked them.

So, these two issues were related to the same generic problem, the CT testing, 
which was only for Chrome compliance, but that were all the time controlled by 
us. It was a bad practice that it´s not happening again with the 
countermeasures set as explained. 

3.- No, there´s nothing related to Wosign nor Richard Wang. As indicated in our 
remediation plan, 360 owns 100% of StartCom and we´ve performed all the changes 
proposed there to have nothing related to Wosign nor Richard. This is indicated 
in bugzilla #1311832 and also in the remediation plan delivered last year.
Also in our remediation plan, there was a chart in which was indicated how the 
Company is structured, and in the case of StartCom Spain, this is 100% owned by 
the StartCom UK, and I´m director in both offices.

And the reason why Richard Wang is director again in StartCom UK is due to some 
bank issues. Richard was removed as director of the StartCom UK at that time, 
but didn´t realize about his signatory rights in the UK bank account. We 
thought we could change that easily but was not possible. We´ve been dealing 
with our lawyers, Alliotts, and finally agreed that signing again Richard was 
going to be quicker and easier. I had planned to go to London for changing it 
end of july, beginning of august but due to some personal matters, it was 
imposible and have had to delay until September. Once we finish this bank 
issue, Richard will be removed again.
In any case these are internal issues that don´t affect the PKI itself, these 
are administrative tasks, but the fact that Richard is again director in 
StartCom UK is just for this matter and has no other responsibility or function 
within StartCom.


Let me know if you need more clarification or have some other doubts or 
questions

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of Jakob Bohm via dev-security-policy
Sent: lunes, 7 de agosto de 2017 22:03
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On 07/08/2017 11:21, Franck Leroy wrote:
> Hello
> I see many reactions that are not in line with the reality because you don’t 
> have all the history on the subject.
> I’ll try to summarize.
> Approximately one year ago Inigo was CTO of Izenpe (CA of the Basque Country) 
> and he left this company in order to join StartCom.
> Not long after he arrives at StartCom (days? Weeks? I don’t know) we discover 
> the deal that has been made by the previous CEO (Eddy Nigg) with the 
> Chinese’s guys and the relations with WoSign.
> Inigo could have resign in regard to the trap the hiring was, but he decided 
> to face, and to setup the remediation plan defined by Mozilla community.
> As said Jon Snow in S07E01: “I will not punish a son for this father’s sins”.
> So instead of denigrate Inigo’s work, as a community we should encourage and 
> support him.
> Setting up a new company, with a new datacentre, new pki software, NO 
> client, NO revenue, with Chinese employees far away speaking not fluent 
> English and with the pressure of the market, it is definitely not an easy 
> task! Personally I would not have tried this, so bravo for Inigo’s bravery… 
> One of the major thing to solve in addition of the remediation plan was to be 
> back in the business as soon as possible, because without any incomes a 
> company cannot survive.
> So Inigo contacted me to know if Certinomis could help him to be back in the 
> business. As you can imagine we did not said yes immediately.
> But Inigo is not an anonymous guy coming from a strange area of Spain. He has 
> been for many years an active CABForum member. He is also an active expert at 
> ESTI, where he was editing the CA policy for web authentication certificates. 
> Inigo is known for his expertise, trustworthiness, honesty and not the least 
> his sympathy. So when he said that he will build a new StartCom and engage 
> the remediation plan, we could trust him.
> We are a community, not only in order to do the “police” but also to support 
> each other’s. So my answer was “yes, we will see how we can help you in 
> respect with community expectations”.
> There was different possibilities to be back in the business while waiting 
> for a brand new CA root included in the browsers; reselling Certinomis 
> certificates, becoming

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

> 
> In this larger light, it would also seem that StartCom, having misissued a
number of certificates already under their new hierarchy, which present a
risk to Mozilla users (revocation is neither an excuse nor a mitigation for
misissuance), should be required to take corrective steps and generate a new
hierarchy that is not, out of the gate, presenting risk to the overall
community due to its past misissuances. We can and should expect more of new
keys being included, because the compatibility risk of expecting adherence
to the Root Policy is non-existent.


To me, this is very convincing that we should add the two StartCom
intermediate certs to OneCRL.

Along this line of discussion, I have not felt comfortable with StartCom's
current root inclusion request (bug #1381406), because Hanno raised a
concern about the private key used by the new root is also used by two
intermediate certificates, one of them revoked. This doesn't see like good
practice to me, and I'm not sure that Inigo's response is sufficient. So,
I'm also wondering if I should close Bug #1381406 and request StartCom to
start completely over with their new CA Hierarchy, and get it right, before
creating their next root inclusion request.

I will appreciate thoughtful and constructive feedback on this as well.


Hi, I´ll try to clarify some of the comments here

1.- It´s true that we have miss-issued a very few number of certificates
under the new hierarchy as has been posted here and even all of them are
revoked, maybe it´s not enough according to some of the comments, which in
other cases, as also have been expressed here, was enough. But in any case,
for those mis-issued certificates, will try to explain:

a.- test certificates: those were mississued certificates issued directly
from the EJBCA system by the CA administrator for testing the CT log. Those
certificates were valid only some minutes, they were issued, the CT tested,
and then revoked. Don´t think they made any danger to the Mozilla community.
These were also reflected in the webtrust audit. And after the incidence we
put the countermeasures needed, not allowing to issue certificates directly.
This was indicated in the bugzilla, in a detailed document. Explained what
happened and why can´t happen any more. After that, none replied so assumed
that the explanation was enough.

b.- pre-certificates: there were 4 pre-certificates that were logged in the
CTs that finally weren´t issued. I still think it could be a
misinterpretation of the word intent and the binding according to the RFC
but as some posted here, it´s very clear and can´t be a misinterpreation, so
they were revoked inmediately when I was told it. Again, don´t think a
pre-certificate could be problematic for mozilla users, but it´s my opinion.

c.- mis-issuances related to the use of curves that are allowed by the BRs
but not in Mozilla. There´s been a discussion about it in both forums (CABF
and m.d.s.p),
which has not arrived any conclusion yet (seems that Mozilla is thinking on
allowing the same like the BRs if i´m not wrong). I asked personally Ryan in
the last CABF F2F meeting about it and he gave me clear instructions and
since then we are not allowing those curves. The countermeasure was applied
into production on June 21st. All certs with these curves were revoked. Also
in these ones there were some other errors related to some bit sets included
in the key usages, which according to 7.1.2.4 for which the CA shall not
issue unless is aware of a reason. The crt.sh tool can´t know if there´s a
reason as it only checks technical stuff. So, don´t see any issue with the
BRs.


d.- one mis-issuance certificate with the country code wrong, used the old
Zaire CC instead of the new one for the Democratic Republic of Congo. Well,
for this case we didn´t have our country DB updated, we did it yesterday and
also cross-checked if there were some others and realized that we had some
old ones like the french and dutch antilles and missing some others like
jersey and guernsey. I don´t think this is a big issue. The certificate was
revoked timely.

e.- misissuances related to Unicode. There were some certs with DNS not
valid due to the use of their own language, cyrilic, chinese, etc. There´s
been a discussion about it in the CABF, also a ballot 202 which has failed,
etc. We revoked all the certs involved and updated our system accordingly
adopting punnycode for all of them. Frankly don´t know if that´s the best
approach.


2.- Usage of the same key. Firstly, this is not prohibited in the BRs, it´s
one of the exceptions included as mentioned in the post. Maybe it´s unusual
or not desiderable, but I think we didn´t do anything wrong. 
Our intention was to be the more accurate possible, we were allowed to
cross-sign the new ones with the old ones and to avoid differences we used
the same key for these cross-signatures for obtaining a certificate the most
similar to the new one. So initially, with that key we created the new root

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Thanks Jonathan

Yes, I answered after just looking quickly about the main issues not focusing 
on the different sizes, etc. As you can see in the post, we have revoked all of 
them.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: Jonathan Rudenberg [mailto:jonat...@titanous.com] 
Sent: jueves, 3 de agosto de 2017 16:52
To: Inigo Barreira 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis


> On Aug 3, 2017, at 04:47, Inigo Barreira via dev-security-policy 
>  wrote:
> 
> For those which are not revoked are due to use different curves 
> (P-384,
> P-521) that have been discussed in the mozilla m.d.s.p as well as the 
> CAB Forum and there´s no conclusion yet, but in any case we´re not 
> allowing to use them anymore. There´re curves allowed in the BRs that 
> Mozilla does not include.
> 
> 2. Other un-revoked certificates have the same error “ ERROR: 
> Unallowed key usage for EC public key (Key Encipherment) ”
> https://crt.sh/?opt=cablint&id=153404034
> https://crt.sh/?opt=cablint&id=160150786
> https://crt.sh/?opt=cablint&id=149445010
> https://crt.sh/?opt=cablint&id=150133570

Let’s break this down, as you have confused a few issues with this subset of 
the misissued certificates. Two certificates were issued with P-521 ECDSA keys, 
which is not allowed by Mozilla policy (note that P-384 keys are allowed):

- 
https://crt.sh/?q=87304EBF0F9391B8FFF7C8ED8D567F0340BCBAA6741972C030364DE5618C6757
- 
https://crt.sh/?q=962C955ABC03FC00F514EA41B2838D85826CA7CAA419A85EC186F1646AD5C9B5

Thirteen certificates (including the two P-521 certificates) were issued with 
the keyEncipherment bit set in the keyUsage extension (this is the message you 
mentioned above) which is not allowed (RFC 3279 section 2.3.5, incorporated by 
reference by RFC 5280 section 4.2.1.3, incorporated by reference by Baseline 
Requirements section 7.1.2.4).

One certificate linked above was issued without the key parameters field set, 
which is not allowed (RFC 3279 section 2.3.1, incorporated by reference by RFC 
5280 section 4.1.2.7, incorporated by reference by Baseline Requirements 
section 7.1.2.4):

- https://crt.sh/?opt=cablint&q=160150786

Hopefully this clarifies any misunderstandings around the problems with these 
specific certificates.

Jonathan


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

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

We´re revoking all those unrevoked certs to avoid any more problems.

Regarding the pre-certs, yes, I was aware of the discussion. As Gerv says
there´s a binding statement of "intent" ... the problem with these is that
we generated the pre-certs and logged in the CT log, where crt.sh looks or
monitor, but those weren´t finally issued, so there are not such certs.
In any case, as said, we´re revoking all of those listed and will update the
bugzilla accordingly

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: Patrick Figel [mailto:patrick@figel.email] 
Sent: jueves, 3 de agosto de 2017 13:07
To: Inigo Barreira ; Franck Leroy
; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

On 03/08/2017 10:47, Inigo Barreira via dev-security-policy wrote> 1.
The un-revoked test certificates are those pre-sign ones with uncompleted
> ctlog. So they are not completed certificates.
> https://crt.sh/?opt=cablint&id=134843670
> https://crt.sh/?opt=cablint&id=134843674
> https://crt.sh/?opt=cablint&id=134843685
> https://crt.sh/?opt=cablint&id=139640371

My understanding of Mozilla's policy is that misissued precerts are
considered misissuance nonetheless[1].

[1]:
https://groups.google.com/d/msg/mozilla.dev.security.policy/6pBLHJBFNts/kM3k
EJKMAgAJ


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

RE: StartCom cross-signs disclosed by Certinomis

[Inigo Barreira via dev-security-policy]

Hi, this is my reply in the bugzilla


Hi all,

what Fanck is saying is true and we haven´t started to issue any cert using
this new path. 

Regarding the info that is in this bug I´m really shocked because the
majority of them are revoked and don´t understand why have been included
here. 


For those which are not revoked are due to use different curves (P-384,
P-521) that have been discussed in the mozilla m.d.s.p as well as the CAB
Forum and there´s no conclusion yet, but in any case we´re not allowing to
use them anymore. There´re curves allowed in the BRs that Mozilla does not
include. 

1. The un-revoked test certificates are those pre-sign ones with uncompleted
ctlog. So they are not completed certificates.
https://crt.sh/?opt=cablint&id=134843670
https://crt.sh/?opt=cablint&id=134843674
https://crt.sh/?opt=cablint&id=134843685
https://crt.sh/?opt=cablint&id=139640371

2. Other un-revoked certificates have the same error “ ERROR: Unallowed key
usage for EC public key (Key Encipherment) ”
https://crt.sh/?opt=cablint&id=153404034
https://crt.sh/?opt=cablint&id=160150786
https://crt.sh/?opt=cablint&id=149445010
https://crt.sh/?opt=cablint&id=150133570


And what I don´t understand are those comments of "very sloppy isuance
practices" , "many non-BR compliants", "specially given the historic issues
with StartCom" and consider them very unfair. These are subjective opinions
which are very dangerous and not fair. 
This is a totally new system that is not related with "the historic issues"
at all, so whatever happened in the past is not related (and we could talk a
lot of why StartCom was distrusted in the past), only the name is the same.
Some of the issues are also related what has been discussing in the CABF
related to the Unicode and punnycode in domanins, etc. and even there´s no
conclussion as the ballot failed, we decided to revoke those to avoid issues
but you include them here as non BR compliants and very sloppy issuance
practices.

Finally I´d like to understand also why has been asked to create OneCRL
entries for these subCAs.

I may think this post and some other comments in the m.d.s.p are malicious
and don´t know why.

Regards

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Franck Leroy via dev-security-policy
Sent: jueves, 3 de agosto de 2017 9:59
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom cross-signs disclosed by Certinomis

Hello,

the 2 CA certificates signed by Certinomis has been retained till a full
successful webtrust audit.

On end of June the audit report form PwC was available but with still some
minor issues. I asked StartCom to correct them.

On July 14th the audit report and the policy were updated and published on
StartCom website.

The first of August I received the agreement from my management to send the
CA certificates to StartCom. So I disclose them in the CCADB, with the
corresponding policy documents and audit reports before sending them to
Inigo.

So StartCom was not able to use the path our Root before yesterday.

If there are some previous issued TLS certificates that does not comply with
BR, then theses TLS certificates has to be revoked.

Best regards
Franck Leroy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: Certificate with invalid dnsName

[Inigo Barreira via dev-security-policy]

Thanks for this info. These Startcom certs were issued from the old system.
We´ll contact the users and act accordingly.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Charles Reiss via dev-security-policy
Sent: jueves, 20 de julio de 2017 3:30
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Certificate with invalid dnsName

On 07/19/2017 06:03 PM, Tom wrote:
> Following that discovery, I've search for odd (invalid?) DNS names.
> Here is the list of certificated I've found, it may overlap some 
> discovery already reported.
> If I'm correct, theses certificate are not revoked, not expired, and 
> probably trusted by Mozilla (crt.sh issuer are marked trusted by 
> Mozilla, but not all).

Annotating these certs:

> Starting with *:

I believe this cert is presently untrusted by Mozilla due to revocation of
all paths to the Federal PKI:
> https://crt.sh/?id=7211484*eis.aetc.af.mil

chains to StartCom (and all of these from StartCom are minor compared to 
StartCom's other problems):
> https://crt.sh/?id=10714112*g10.net-lab.net

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=48682944*nuvolaitaliana.it

chains to StartCom:
> https://crt.sh/?id=15736178*assets.blog.cn.net.ru
> https://crt.sh/?id=17295812*dev02.calendar42.com
> https://crt.sh/?id=15881220*dev.1septem.ru
> https://crt.sh/?id=15655700*assets.blog.cn.net.ru
> https://crt.sh/?id=17792808*quickbuild.raptorengineering.io


> 
> Starting with -:

chains to QuoVadis:
> https://crt.sh/?id=54285413
> -d1-datacentre-12g-console-2.its.deakin.edu.au

chains to StartCom:
> https://crt.sh/?id=78248795-1ccenter.777chao.com


> 
> Multiple *.:

chains to QuoVadis:
> https://crt.sh/?id=13299376*.*.victoria.ac.nz

I believe this cert is presently trusted by Mozilla only via a 
technically constrained subCA:
> https://crt.sh/?id=44997156*.*.rnd.unicredit.it

chains to Swisscom:
> https://crt.sh/?id=5982951*.*.int.swisscom.ch


> 
> Internals TLD:

chains to Baltimore CyberTrust Root (DigiCert):
> https://crt.sh/?id=33626750a1.verizon.test

I believe this cert is presently untrusted by Mozilla due to revocation 
of the relevant subCA:
> https://crt.sh/?id=33123653DAC38997VPN2001A.trmk.corp

chains to Certplus (DocuSign):
> https://crt.sh/?id=42475510naccez.us.areva.corp

I believe these presently lack an unrevoked, unexpired trust path in 
Mozilla:
> https://crt.sh/?id=10621703collaboration.intra.airbusds.corp
> https://crt.sh/?id=48726306zdeasaotn01.dsmain.ds.corp
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: New undisclosed intermediates

[Inigo Barreira via dev-security-policy]

Hello all,

I also did it but it´s not reflected.
In my case was also my fault because I was disclosing a different one.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Stephen Davidson via dev-security-policy
Sent: martes, 6 de junio de 2017 15:59
To: Alex Gaynor ; MozPol

Subject: RE: New undisclosed intermediates

Hello:

I acknowledge that QuoVadis Grid ICA2 was missing from the CCADB.  The
omission was human error (my own) when entering a group of issuing CAs into
SalesForce.  Ongoing, when new ICAs are created, the CCADB disclosure is
part of our process.

For the sake of clarity, that ICA is disclosed in our Repository and
included in our WebTrust audit reports.

Regards, Stephen
QuoVadis


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+s.davidson=quovadisglobal@lists.mozi
lla.org] On Behalf Of Alex Gaynor via dev-security-policy
Sent: Monday, June 5, 2017 10:30 AM
To: MozPol 
Subject: New undisclosed intermediates

Happy Monday!

Another week, another set of intermediate certs that have shown up in CT
without having been properly disclosed:
https://crt.sh/mozilla-disclosures#undisclosed

There are four intermediates here, and with exception of the StartCom one,
they were all issued more than a year ago.

As I've expressed before, I find it baffling that this still happens. To
approach this more productively, I'd be very appreciative if someone from a
CA could describe how they approach disclosing intermediates, where it fits
into their process, how they track progress, etc.

Cheers,
Alex
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy



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

RE: StartCom issuing bogus certificates

[Inigo Barreira via dev-security-policy]

Hi

 

 <https://bugzilla.mozilla.org/attachment.cgi?id=8873408> 
https://bugzilla.mozilla.org/attachment.cgi?id=8873408

 

 <https://bugzilla.mozilla.org/attachment.cgi?id=8873409> 
https://bugzilla.mozilla.org/attachment.cgi?id=8873409

 

 

these are the 2 documents I tried to upload to the list, these are now in the 
bug created by Gerv at  <https://bugzilla.mozilla.org/show_bug.cgi?id=1369359> 
https://bugzilla.mozilla.org/show_bug.cgi?id=1369359

 

 

Best regards

 

Iñigo Barreira

CEO

StartCom CA Limited

 

From: Vincent Lynch [mailto:vtly...@gmail.com] 
Sent: jueves, 1 de junio de 2017 14:46
To: Eric Mill ; Gervase Markham ; Inigo 
Barreira ; Jeremy Rowley ; 
Yuhong Bao 
Cc: Kurt Roeckx ; Matthew Hardeman ; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom issuing bogus certificates

 

Hi Inigo,

 

You mentioned there would be a report attached but I believe you forgot to send 
it? 

 

Can you upload the report and provide a URL? I believe that's the 'best 
practice' for sharing files here as it allows non-subscribers to access the 
file via the Google Groups archive.

 

-Vincent

 

On Thu, Jun 1, 2017 at 6:40 AM Inigo Barreira via dev-security-policy 
mailto:dev-security-policy@lists.mozilla.org> > wrote:

Hi all,

Firstly I´d like to apologize for not having answering before and for
posting an initial response that was not correct not accurate and not
related what it´s being discussed right now. It was my fault for not having
checked before with my team, which is in China and they are 6 hours ahead,
but was my first reaction when saw test in the SAN. So, sorry for this.

In fact, the "issue" was due for implementing the CT log. Recently one
customer asked why we weren´t logging our certificates in the CT logs, which
we were doing it but with some problems because of the great firewall. So,
we were talking with Primekey and provided a solution to implement in our
system. We did it yesterday and for checking it, we created those "fake"
certificates for testing, which were revoked inmediately.
Attached there´s a report in which we explain all that has happened. And
also some screenshots.
In this report also indicate what remeditation steps we´ve already done to
avoid these issues happen again in the future.

We´ve also realized that the CRL generation didn´t work as supposed because
didn´t generate a new CRL when those certificates were revoked  but in the
next update. We are dealing with Primekey to know what has happened. The
OCSP response instead was correct and showed the certificates as revoked.

For some other comments/suggestions posted in this thread I´d like to say
that:

- this incident is not related to the "real" issuance system through our CMS
system in which all domains are verified
- these certs were issued and revoked inmediately as they were only for
testing. I know it wasn´t a good decission
- regarding my initial response for test URLs, those are going to be
generated under our own website, like valid.startcomca.com 
<http://valid.startcomca.com> ,
revoked.startcomca.com <http://revoked.startcomca.com> 
- and for those other certs in crt.sh, those are revoked but there are four
that were not issued because the connection with the CT failed and for some
reason are showed in the crt.sh. We´re contacting Primekey to know what has
happened but it seems to be related with the Startcom log, which didn´t
logged it because it failed and google logs, which did it, so maybe is a
configuration issue.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo 
<mailto:dev-security-policy-bounces%2Binigo> =startcomca@lists.mozilla.org 
<mailto:startcomca@lists.mozilla.org> ]
On Behalf Of Gervase Markham via dev-security-policy
Sent: jueves, 1 de junio de 2017 10:27
To: Yuhong Bao mailto:yuhongbao_...@hotmail.com> >; 
Eric Mill mailto:e...@konklone.com> >;
Jeremy Rowley mailto:jeremy.row...@digicert.com> >
Cc: mozilla-dev-security-pol...@lists.mozilla.org 
<mailto:mozilla-dev-security-pol...@lists.mozilla.org> ; Kurt Roeckx
mailto:k...@roeckx.be> >; Matthew Hardeman 
mailto:mharde...@gmail.com> >
Subject: Re: StartCom issuing bogus certificates

On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com <http://example.com> 
>  though

How would you like it if a CA decided there was nothing important on your
website and so decided it was OK to misissue certificates for it?

This requirement is a positive requirement ("must have validated domain
ownership or control by applicant"), not a negative requirement ("domain
must not have anything important on it").

Gerv
___
dev-secu

RE: StartCom issuing bogus certificates

[Inigo Barreira via dev-security-policy]

Hi all,

Firstly I´d like to apologize for not having answering before and for
posting an initial response that was not correct not accurate and not
related what it´s being discussed right now. It was my fault for not having
checked before with my team, which is in China and they are 6 hours ahead,
but was my first reaction when saw test in the SAN. So, sorry for this.

In fact, the "issue" was due for implementing the CT log. Recently one
customer asked why we weren´t logging our certificates in the CT logs, which
we were doing it but with some problems because of the great firewall. So,
we were talking with Primekey and provided a solution to implement in our
system. We did it yesterday and for checking it, we created those "fake"
certificates for testing, which were revoked inmediately.
Attached there´s a report in which we explain all that has happened. And
also some screenshots.
In this report also indicate what remeditation steps we´ve already done to
avoid these issues happen again in the future.

We´ve also realized that the CRL generation didn´t work as supposed because
didn´t generate a new CRL when those certificates were revoked  but in the
next update. We are dealing with Primekey to know what has happened. The
OCSP response instead was correct and showed the certificates as revoked.

For some other comments/suggestions posted in this thread I´d like to say
that:

- this incident is not related to the "real" issuance system through our CMS
system in which all domains are verified
- these certs were issued and revoked inmediately as they were only for
testing. I know it wasn´t a good decission
- regarding my initial response for test URLs, those are going to be
generated under our own website, like valid.startcomca.com,
revoked.startcomca.com
- and for those other certs in crt.sh, those are revoked but there are four
that were not issued because the connection with the CT failed and for some
reason are showed in the crt.sh. We´re contacting Primekey to know what has
happened but it seems to be related with the Startcom log, which didn´t
logged it because it failed and google logs, which did it, so maybe is a
configuration issue.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: jueves, 1 de junio de 2017 10:27
To: Yuhong Bao ; Eric Mill ;
Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org; Kurt Roeckx
; Matthew Hardeman 
Subject: Re: StartCom issuing bogus certificates

On 01/06/17 01:48, Yuhong Bao wrote:
> I don't think there is anything important on example.com though

How would you like it if a CA decided there was nothing important on your
website and so decided it was OK to misissue certificates for it?

This requirement is a positive requirement ("must have validated domain
ownership or control by applicant"), not a negative requirement ("domain
must not have anything important on it").

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


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

RE: StartCom issuing bogus certificates

[Inigo Barreira via dev-security-policy]

Hi all,

There´s been a misunderstanding internally when requested to create some "test" 
certificates as indicated in the Microsoft root program requirements as stated 
in 4b "Test URLs for each root, or a URL of a publicly accessible server that 
Microsoft can use to verify the certificates." but of course not this way.

We will revoke them inmediately.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of patryk.szczyglowski--- via dev-security-policy
Sent: miércoles, 31 de mayo de 2017 17:45
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: StartCom issuing bogus certificates

Hello,

My first post here.

I just noticed StartCom have issued today couple obviously fake certificates:

https://crt.sh/?id=146437565
Subject:
commonName= ov
organizationName  = test
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = Beijing
serialNumber  = 123456
X509v3 Subject Alternative Name: 
DNS:www.test.cn

https://crt.sh/?id=146484676
Subject:
commonName= iv
givenName = Jeremy
surname   = Liao
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = CN
X509v3 Subject Alternative Name: 
DNS:www.test.cn

https://crt.sh/?id=146517428
Subject:
commonName= ov
organizationName  = test
localityName  = Beijing
stateOrProvinceName   = Beijing
countryName   = Beijing
serialNumber  = 123456
X509v3 Subject Alternative Name: 
DNS:www.test.cn

I am well aware these certificates will not be accepted in Firefox/NSS, but 
because of the fact their root certificate is still in NSS trust store, there 
might be some interest in the community regarding obvious policy violation.

Regards,
Patryk Szczygłowski
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Inigo Barreira via dev-security-policy]

Yes, I wanted to know if a regular user can use its Gmail account to get an
s/mime cert but that can´t be issued because the CA can´t validate the
domain properly because it´s not his or authorized to use it when doing the
3.2.2.4

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: viernes, 19 de mayo de 2017 16:38
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy 2.5 Proposal: Fix definition of constraints for
id-kp-emailProtection

On 19/05/17 15:16, Inigo Barreira wrote:
> What about those for gmail, Hotmail, etc.? Are out of scope?

I'm not sure what you mean. If Gmail wants a TCSC for @gmail.com, they can
have one. They would presumably need to set the dirName to "" or null,
because no dirName can cover all of their customers, as their customerd
don't represent Google?

Gerv

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


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

RE: Policy 2.5 Proposal: Fix definition of constraints for id-kp-emailProtection

[Inigo Barreira via dev-security-policy]

What about those for gmail, Hotmail, etc.? Are out of scope?

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: viernes, 19 de mayo de 2017 15:13
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Policy 2.5 Proposal: Fix definition of constraints for
id-kp-emailProtection

On 12/04/17 10:47, Gervase Markham wrote:
> We don't have any "Email BRs" to refer to, but I think we want 
> something like this:
> 
> "If the certificate includes the id-kp-emailProtection extended 
> key usage, it MUST include the Name Constraints X.509v3 extension with 
> constraints on rfc822Name, with at least one name in permittedSubtrees."

Updated language:

"If the certificate includes the id-kp-emailProtection extended key usage,
it MUST include the Name Constraints X.509v3 extension with constraints on
rfc822Name, with at least one name in permittedSubtrees, each such name
having its ownership validated according to section
3.2.2.4 of the BRs."

Gerv

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


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

RE: StartCom continues to sell untrusted certificates

[Inigo Barreira via dev-security-policy]

Yes, thank you for letting us know.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of Lewis Resmond via dev-security-policy
Sent: miércoles, 3 de mayo de 2017 19:49
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: StartCom continues to sell untrusted certificates

Am Montag, 1. Mai 2017 16:49:32 UTC+2 schrieb Henri Sivonen:
> On Mon, May 1, 2017 at 11:31 AM, Gervase Markham via 
> dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> > On 01/05/17 07:52, Percy wrote:
> >> It seems that StartCom continues to sell untrusted certs. Neither 
> >> their
> home page https://www.startcomca.com/ nor their announcement page 
> https://www.startcomca.com/index/news mentions that those certs are 
> not trusted.
> >
> > Why is this something that Mozilla should be concerned with?
> >
> > "Selling untrusted certs" is not a crime, or a violation of any 
> > standard. Mozilla is not the global authority on what certificates 
> > may be issued. If StartCom are providing certificates which do not 
> > do what their customers expect, I'm sure those customers will let 
> > them know about it soon enough.
> 
> What StartCom claims about compatibility is potentially more 
> Mozilla-relevant than what they are silent about. At the bottom of 
> their front page, it says "StartCom™ / StartSSL™is supported by:" 
> followed by icons. The icons include an early icon for Camino and the 
> SeaMonkey icon.
> Since Camino was discontinued before Mozilla's change in trust in 
> StartCom certificates, I guess having Camino there isn't technically 
> incorrect, but is about as relevant as having the Flock icon there. 
> However, is it correct to have the SeaMonkey icon there? The latest 
> SeaMonkey release seems to post-date the Mozilla root program's trust change 
> in StartCom certificates.
> (But then, it seems that there have been a number of Firefox ESR 
> security patch releases that post-date the SeaMonkey release. Is 
> SeaMonkey still active, despite appearing not to ship Gecko security 
> updates, and does SeaMonkey implement the same trust special-casing as 
> Firefox? It seems to produce nightlies still.)
> 
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/

It seems like they have removed the icons.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


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

RE: Symantec Conclusions and Next Steps

[Inigo Barreira via dev-security-policy]

No problem at all. I thought that while distrusted no needed to follow nor
update the CCADB. Will do asap.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: Rob Stradling [mailto:rob.stradl...@comodo.com] 
Sent: jueves, 27 de abril de 2017 13:08
To: Inigo Barreira ; mozilla-dev-security-policy

Subject: Re: Symantec Conclusions and Next Steps

On 27/04/17 11:56, Inigo Barreira wrote:
> Good to know that our new certs are there :-) Regarding StartCom, 
> these are the new certs we´ve generated and will be used to apply for 
> inclusion in the Mozilla root program. Nothing to disclose at the 
> moment I guess. We´ve not been audited yet nor applied.


Hi Iñigo.  The old StartCom roots still have the SSL trust bit enabled in
NSS, and you've used one of those old roots to cross-sign the new StartCom
roots.  AFAICT, that means that these new StartCom intermediates do need to
be disclosed to the CCADB.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online



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

RE: Symantec Conclusions and Next Steps

[Inigo Barreira via dev-security-policy]

Good to know that our new certs are there :-)
Regarding StartCom, these are the new certs we´ve generated and will be used
to apply for inclusion in the Mozilla root program. Nothing to disclose at
the moment I guess. We´ve not been audited yet nor applied.

Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Rob Stradling via dev-security-policy
Sent: jueves, 27 de abril de 2017 12:38
To: mozilla-dev-security-policy

Subject: Re: Symantec Conclusions and Next Steps

On 26/04/17 21:21, Rob Stradling via dev-security-policy wrote:

> (Note: A few of the non-Symantec entries currently listed by 
> https://crt.sh/mozilla-disclosures#undisclosed are false positives, I 
> think.  It looks like Kathleen has marked some roots as "Removed" on 
> CCADB ahead of the corresponding certdata.txt update on mozilla-central).

Ah, I take that back.  The March certdata.txt update did hit mozilla-central
on 11th April, but I missed an alert.  I've just pushed that update to
crt.sh.

https://crt.sh/mozilla-disclosures#undisclosed is currently free of false
positives.  It shows that DigiCert, StartCom and Symantec are currently
out-of-compliance with Mozilla's disclosure requirement.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

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


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

RE: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Inigo Barreira via dev-security-policy]

Yes, I know what happened but it´s not what the document says. Unless there´s 
another document, it seems to me that you haven´t acted according to what this 
page says. If I understand correcly, a should is a conditional and then it´s 
not a requirement. Furthermore there´s no indication on the consequences if you 
don´t do it, at least in this document. Maybe I´m missing some others, for 
sure, but i´d like to have the full picture.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org] On 
Behalf Of Gervase Markham via dev-security-policy
Sent: lunes, 13 de febrero de 2017 13:15
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Public disclosure of root ownership transfers (was: Re: Google 
Trust Services roots)

Hi Inigo.

On 10/02/17 12:40, Inigo Barreira wrote:
> I see many "should" in this link. Basically those indicating "should 
> notify Mozilla" and "should follow the physical relocation section".

It may be that this document does need redoing in formal policy language. In 
the mean time, anyone uncertain about its meaning should ask Kathleen.

> What does it happen if you don´t notify Mozilla?

Well, this was a factor in our dis-trust of WoSign and StartCom, so I guess the 
answer is "we take it seriously" :-)

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


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

RE: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Inigo Barreira via dev-security-policy]

Gerv,

I see many "should" in this link. Basically those indicating "should notify
Mozilla" and "should follow the physical relocation section". But in
physical relocation and personnel changes sections it seems to me there´s a
contradiction because there are some must. Can you explain the differences?
According to the above mentioened there´s a should, so you´re able to not
follow what it´s indicated in the following ones, then the must does not
take effect, is this correct?
What does it happen if you don´t notify Mozilla?

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: viernes, 10 de febrero de 2017 10:48
To: Richard Wang ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Public disclosure of root ownership transfers (was: Re: Google
Trust Services roots)

On 10/02/17 06:15, Richard Wang wrote:
> I think Mozilla should have a very clear policy for:
> (1)  If a company that not a public trusted CA acquired a trusted root
key, what the company must do?
> (2)  If a company is a public trusted CA that acquired a trusted root key,
what the company must do?
> (3) If a company is a public trusted CA, but distrusted by Mozilla, this
company acquired a trusted root key, what the company must do?

We do: https://wiki.mozilla.org/CA:RootTransferPolicy .

Gerv

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


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