RE: DigiCert-Symantec Announcement

[Jeremy Rowley via dev-security-policy]

Hey Ryan – Thanks a ton for this post.  I’m working on a reply and should have 
something next week, but I wanted to acknowledge that we saw the post and are 
working on providing the information requested. 

 

Jeremy

 

From: Ryan Sleevi [mailto:r...@sleevi.com] 
Sent: Thursday, September 14, 2017 1:28 PM
To: Jeremy Rowley 
Cc: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: DigiCert-Symantec Announcement

 

 

 

On Wed, Aug 2, 2017 at 5:12 PM, Jeremy Rowley via dev-security-policy 
 > wrote:

Hi everyone,



Today, DigiCert and Symantec announced that DigiCert is acquiring the
Symantec CA assets, including the infrastructure, personnel, roots, and
platforms.  At the same time, DigiCert signed a Sub CA agreement wherein we
will validate and issue all Symantec certs as of Dec 1, 2017.  We are
committed to meeting the Mozilla and Google plans in transitioning away from
the Symantec infrastructure. The deal is expected to close near the end of
the year, after which we will be solely responsible for operation of the CA.
>From there, we will migrate customers and systems as necessary to
consolidate platforms and operations while continuing to run all issuance
and validation through DigiCert.  We will post updates and plans to the
community as things change and progress.



I wanted to post to the Mozilla dev list to:

1.  Inform the public,
2.  Get community feedback about the transition and concerns, and
3.  Get an update from the browsers on what this means for the plan,
noting that we fully commit to the stated deadlines. We're hoping that any
changes



Two things I can say we plan on doing (following closing) to address
concerns are:

a.  We plan to segregate certs by type on each root. Going forward, we
will issue all SSL certs from a root while client and email come from
different roots. We also plan on limiting the number of organizations on
each issuing CA.  We hope this will help address the "too big to fail" issue
seen with Symantec.  By segregating end entities into roots and sub CAs, the
browsers can add affected Sub CAs to their CRL lists quickly and without
impacting the entire ecosystem.  This plan is very much in flux, and we'd
love to hear additional recommendations.
b.  Another thing we are doing is adding a validation OID to all of our
certificates that identifies which of the BR methods were used to issue the
cert. This way the entire community can readily identify which method was
used when issuing a cert and take action if a method is deemed weak or
insufficient.  We think this is a huge improvement over the existing
landscape, and I'm very excited to see that OID rolled out.



Thanks a ton for any thoughts you offer.



Jeremy

 

eremy,

 

Thanks for sharing details about your rough plans. There’s a lot at play here, 
particularly when trying to fully visualize DigiCert’s existing and proposed 
hierarchy, so I’m wondering if it might be easier to explore what the ‘ideal 
PKI’ may look like, and then try to work backwards to figure out how this 
acquisition can help that.

 

At the core, we can imagine there is a root CA for each major long-term 
cryptographic configuration - which, in today’s world, generally means 
RSA/2048, RSA/4096, ECC/256, and ECC/384. In tomorrow’s world, this may also 
accommodate additional curves Ed25519 and Ed448, such as via 
https://tools.ietf.org/id/draft-ietf-curdle-pkix . In total, this means the 
ideal PKI only needs four to six root certificates.

 

Within each root, you can build out the appropriate segmentation. For 
performance reasons, it’s likely preferable to have a ‘wide’ PKI (many sub-CAs 
off the root, each constrained in capability and used for a limited amount of 
time) versus a ‘deep’ PKI (hierarchically reducing the capabilities at each 
level in the trust graph- for example, “All TLS” -> “All DV” -> “All first 
party DV” -> “All first party DV in Q12017”), even if a deep PKI can provide 
better compartmentalization for some use cases.

 

It isn’t clear that compartmentalizing on root provides any obvious benefits to 
users, especially as it’s the same infrastructure and audits, but it does seem 
that it increases the management overhead (for root stores), the configuration 
challenges (for site operators), not to mention the management (and, 
occasionally, network & memory) challenges for users to support all of those 
roots.

 

It would be ideal to see DigiCert streamline its PKI to better align with that 
vision, and to understand what challenges might prevent that. For example, is 
there a path to transition all new DigiCert issuance to a single root? If it 
can’t be done for all certs, can it be done for TLS? Understanding if there are 
challenges to that goal can provide invaluable insight into how the Managed CA 
transition can look.

 

A significant reason for the Managed CA 

Permission to use Errata CAA Algorithm

[josh--- via dev-security-policy]

We applaud the recent addition of CAA checking requirements to the Baseline 
Requirements. However, there are known problems with the CAA checking algorithm 
specified in RFC 6844, and those problems are leading to many reports from our 
subscribers. The issues are described here:

https://community.letsencrypt.org/t/legacy-caa-implementation/

We would like to ask the Mozilla and Google root programs on this list to 
immediately grant at least temporary dispensation for CAs to implement the CAA 
checking algorithm as described in this errata:

https://www.rfc-editor.org/errata/eid5065

We believe that the algorithm described in this errata is a better algorithm, 
and that the IETF working group behind CAA agrees. We believe a CA/B Forum 
ballot will pass in the near term to make the algorithm compliant.

A CA/B Forum ballot will take some time to pass, however, and subscribers are 
hurting now. Therefore we believe the right course of action is for root 
programs to grant at least temporary dispensation for CAs to implement the 
errata algorithm starting immediately.

Let’s Encrypt has implemented the errata algorithm for CAA checking for some 
time now, until Thursday (yesterday) morning, when we switched to the RFC 6844 
algorithm for compliance reasons. Let’s Encrypt acknowledges that we did not 
move to the compliant algorithm until after the compliance deadline and we 
apologize for that. We should have sought dispensation before the compliance 
deadline and not having done so was wrong regardless of whether or not 
dispensation is granted now. Nonetheless, we believe the right thing to do 
going forward is to allow any CA to at least temporarily implement the errata 
algorithm.
___
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

[Ryan Sleevi via dev-security-policy]

On Fri, Sep 15, 2017 at 12:30 PM, Inigo Barreira via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

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


Can you point where the Baseline Requirements and/or Root Store policies
exclude "certs lived for minutes" from being in scope? Or where revocation
absolves a CA of the issuance in the first place?


> So, I think these are the reasons. It´s not an excuse and we didn´t expect
> this maremágnum.


I believe the lack of expectation is precisely why there is significant
concern here. CAs are expected to be global stewards of trust, operating
beyond reproach - which generally means assuming all things are forbidden
unless expressly permitted, and even when it seems they _may_ be permitted,
to consider the full implications of the interpretation and to check if
there are multiple interpretations.


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

I think you've added a lot, and while the engagement has been valuable,
hopefully this clarifies precisely why these responses have been so deeply
concerning towards demonstrating trustworthiness.


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

We are not seeking to identify personal blame. We are seeking to understand
what, if any, improvements have been made to address such issues. In
reading this thread, I have difficulty finding any discussion about the
steps that StartCom has proposed to improve its awareness of the
expectations placed upon it as a potential participant in the Mozilla
store. Regardless of who bears responsibility for that, the absence of a
robust process - and, unfortunately, the absence of a deep understanding -
does mean that the restablishing of trust can present a significant risk to
the community.


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


I am wholly uncertain how to interpret what you're saying here.


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

I agree that a well-executed audit can help a CA identify areas of
improvement. However, a well-executed audit can also identify issues of
non-compliance or identify issues of risk that the community may find
unacceptable, independent of the auditors own assessment.


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

I do not think this demonstrates a positive awareness of the issues being
discussed. Again, as CAs are expected to be stewards of global trust, it is
expected that CAs seek to both individually improve and rise above 'the
minimum' requirements, and to seek ways to improve those minimums.

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

It is useful to know what you think, as it highlights disagreement.
However, it's more useful to know why you think this. I would suggest that,
for most people examining both the information provided on the issues, the
facts, and the discussion so far, it is very 

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
> 

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

[Alex Gaynor via dev-security-policy]

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 <
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
> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

[Gervase Markham via dev-security-policy]

On 15/09/17 13:55, cornelia.enk...@gmail.com wrote:
> technically the CA now is disabled to sign certificates using SHA1

But presumably you thought that was true before this incident? (And if
not, why not?)

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

[Gervase Markham via dev-security-policy]

On 15/09/17 09:24, Inigo Barreira wrote:
> AFAIK, Certinomis only disclosed in the CCADB 

That means it's published and available. As noted in my other reply,
information as to exactly what this cross-sign enables trust for would
be most helpful, as I may have misunderstood previous statements on this
topic.

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

[Gervase Markham 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)?

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

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

>> * 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. Repairing them afterwards does not remove the uncertainty. 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.

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

> 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
told me that your new hierarchy, cross-signed by Certnomis, had issued
50,000 certificates. Did I misunderstand? If so, my apologies.

> Ok, I see this is a new requirement that was not imposed last time in which 
> you recommended and allowed us to be cross-signed as many other CAs have done 
> in the past to be in the business.

Mozilla did not recommend that you be cross-signed. Certnomis raised the
possibility, and we said that it could happen when you had met the BRs
and completed the remediation steps. The plan we "approved" was not a
cross-signing plan. The audits show you haven't yet met the BRs, and we
have not yet signed off on you having completed the remediation steps.

> We´ve met all the conditions, new system, new management, security audit and 
> webtrust audit and CT logging. In those conditions, it was not mentioned that 
> the webtrust audit should be clean 

Isn't that implied?

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

So the 50,000 certs you mentioned are issued in your old hierarchy,
which is not cross-signed by Certnomis?

If you could clarify the numbers for your old and new PKI, and confirm
that the Certnomis cross-signs apply only to the new one, that would be
helpful. Again, apologies for any misunderstanding on my part.

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

> I think this has been explained. I don´t understand why you say it´s a "poor 
> quality PHP code". 

Because poor quality PHP code does 

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

[James Burton via dev-security-policy]

On Friday, September 15, 2017 at 12:30:00 PM UTC+1, James Burton wrote:
> On Friday, September 15, 2017 at 10:56:11 AM UTC+1, Inigo Barreira wrote:
> > > 
> > > > Those tests were done to check the CT behaviour, there was any other
> > > testing of the new systems, just for the CT. Those certs were under 
> > > control all
> > > the time and were lived for some minutes because were revoked inmediately
> > > after checking the certs were logged correctly in the CTs. It´s not a mis-
> > > issuance by means of we didn´t know what happened, we had to investigate,
> > > etc. It was not a good practice and I can´t excuse for that, but it was 
> > > not
> > > related to the regular issuance procedure as someone suggested. We
> > > provided a report in which indicated all that happened and what we did to
> > > not happen this again, updating the EJBCA roles permissions.
> > > 
> > > 1) Why didn't StartCom build a test hierarchy?
> > 
> > Considering that we were distrusted, that we didn´t reapply for inclussion, 
> > that CT is only required by Chrome and it´s not included in the Mozilla 
> > policy (even we were requested that all of our certs had to be CT logged) 
> > nor required by Firefox, that those certs were under our control all the 
> > time and lived for some minutes because were revoked inmediately, at that 
> > time, when we did it, we didn´t expect this reaction for sure.
> > 
> > Of course if we had known it we hadn´t done it and for sure had built a 
> > test hierarchy but there´s nothing we can do now. Only wanted to state that 
> > those certs were under our control all the time, and lived for some minutes 
> > because were revoked after the test. There were not any other testing of 
> > any other nature directly in the production system
> > 
> > > 2) Why didn't StartCom use the TestTube CT log for testing CT?
> > 
> > We tried to check and test the same behaviour before going live with the CT 
> > logging, so followed the requirements to use 3 logs, one google and one 
> > non-google, for the EVs and this is what we did. We used the same settings 
> > we had before the distrust using the startcom log and the google ones 
> > (pilot and rocketeer).
> 
> Hi Inigo,
> 
> I'm just trying to get everything straight, cleared up and then we can move 
> on.
> 
> I found all of your answers very concerning in the way you've conducted 
> testing. I thought that all CAs must have some type of test hierarchy in 
> place to test new software, requirements and etc before going live but from 
> the answers you've given, StartCom neglected this in favour to test as you go 
> along and deal with the problems using a live CA hierarchy. All this feels 
> very amateurish and doesn't give me the any confidence at all that your CA is 
> proven itself to be a trustworthy part of this infrastructure.
> 
> I recommend to Mozilla to require StartCom to start again fresh. 
> 
> 1. Build a test hierarchy. Test the software and etc to industry guidelines.
> 2. Build a new production hierarchy (including new HSMs, keys, roots, etc.) 
> and then re-apply for inclusion into the Mozilla root program.
> 3. Once approved then you can cross-sign your roots with another CA.
> 
> While this is happening. You can resell certificates from other CAs and build 
> up trust in the industry which will benefit you in the long term I feel.
> 
> James

Hi Inigo,

To add from the last post.

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

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

Re: FW: StartCom inclusion request: next steps

[James Burton via dev-security-policy]

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

Hi Inigo,

I'm just trying to get everything straight, cleared up and then we can move on.

I found all of your answers very concerning in the way you've conducted 
testing. I thought that all CAs must have some type of test hierarchy in place 
to test new software, requirements and etc before going live but from the 
answers you've given, StartCom neglected this in favour to test as you go along 
and deal with the problems using a live CA hierarchy. All this feels very 
amateurish and doesn't give me the any confidence at all that your CA is proven 
itself to be a trustworthy part of this infrastructure.

I recommend to Mozilla to require StartCom to start again fresh. 

1. Build a test hierarchy. Test the software and etc to industry guidelines.
2. Build a new production hierarchy (including new HSMs, keys, roots, etc.) and 
then re-apply for inclusion into the Mozilla root program.
3. Once approved then you can cross-sign your roots with another CA.

While this is happening. You can resell certificates from other CAs and build 
up trust in the industry which will benefit you in the long term I feel.

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

Re: Certigna Root Renewal Request

[J. Allemandou via dev-security-policy]

Thank you very much Nick for this analysis and the time past on our request. 

You will find below additional information. The publication of the updated CP / 
CPS will be immediate, as soon as you confirm that the level of detail is 
sufficient for you.

Thank you in advance for your help and your reply.

- Afnic control 

For each TLS/SSL certificate request, controls through “Whois” websites are 
systematically performed by RA operator with a screen-shot add to validation 
proofs. For French websites, as recommended by the "RGS" French standard, the 
operator performs an additional control through the AFNIC website, that why we 
mentioned explicitly this website.

- Wildcard Domain Validation

Indeed, the process is not formally described in the CP on this subject. An 
automatic process is implemented, when ordering a wildcard SSL certificate, to 
verify that the requested domain name is made up as "*.domain.tld". To 
consolidate this check, TLDs validated by ICANN are everyday automatically 
retrieved through the list on the https://publicsuffix.org website. 
In addition, the verification of the domain name owner performed by the RA will 
in all cases lead to a rejection of the application as it is impossible to 
identify the owner of a domain name of type "*.tld". Applications with an 
invalid TLD or non-domain (E.g. *.co.uk) will therefore be systematically 
rejected.

- High Risk 

Our CP/CPS have been updated with a chapter named “3.2.6 Verification of 
Certain Information Sources” which integrate the following description of our 
practices about this: 

“High risk status
The CA develops, maintains, and implements documented procedures that identify 
and require additional verification activity for High Risk Certificate Requests 
prior to the Certificate’s approval, as reasonably necessary to ensure that 
such requests are properly verified under these Requirements.
In particular, the RA is carried out controls with databases of domain names 
that are suspected to be used for phishing activities (sources related to 
“APWG” and “Phishing initiative”) and with CA’s internal databases of revoked 
certificates for compromising reason or request of certificates which are 
suspected to be used for phishing activities.”

- Contact

Terms and conditions (chapter 20) indicate the email address 
cont...@certigna.fr for every request.

This information will be added to CP/CPS at chapter 1.6.2.

Terms and conditions (chapter 21) indicate that a form is available on Certigna 
website for reporting a malicious and dangerous certificate. Other requests can 
be performed through this form.

This information will be added to CP/CPS at chapter 2.2.4.

Terms and conditions: http://cgu.certigna.fr/en/CGU_CERTIGNA_SERVICES_CA.pdf
CP: http://politique.certigna.fr/en/PCcertignaservicesca.pdf
Form: https://www.certigna.fr/contact.xhtml
   
Thank you in advance for your help and your reply.

Best regards

___
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

[James Burton 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? 
2) Why didn't StartCom use the TestTube CT log for testing CT? 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

[cornelia.enke66--- via dev-security-policy]

Am Mittwoch, 6. September 2017 22:38:35 UTC+2 schrieb Nick Lamb:
> Thanks for writing this incident report.
> 
> The latter of the two certificates was issued after popular web browsers had 
> ceased accepting SHA-1 as far as I understand it. As a result it seems likely 
> that it would not have functioned as expected if a customer deployed it on a 
> Web server. You mention that you reached out to the affected customer, did 
> they indicate that they'd noticed any problem with their certificate? Do you 
> have any reason to think that in practice it was not used? (e.g. customer 
> ordered & received a SHA-256 cert for the same name shortly afterwards).


In fact the customers did not use this certificates. 

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

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

[cornelia.enke66--- via dev-security-policy]

Am Mittwoch, 6. September 2017 21:47:54 UTC+2 schrieb Rob Stradling:
> Hi Conny.  Are you able to post those 2 certificates to some CT logs and 
> provide crt.sh links?
> 
> You've said that both certs have the same SHA-1 Fingerprint.  Are you 
> sure about that?
> 
> On 06/09/17 20:38, cornelia.enke66--- via dev-security-policy wrote:
> > SwissSign has identified the following incident:
> > two Certificate signed with SHA1: Violation BR 7.3.1
> > 
> > 1)
> > During an internal audit on 05.09.2017 we found out that there are two 
> > certificates issued after 16.01.2015 and signed with a SHA1 hash.
> > After the discovery of two certificates, the following actions where taken 
> > 05.09.2017
> > a) a security incident was opend
> > b) contact the customers to revoke the two certificates
> > c) identify the reason for the error
> > d) the source of the error has been eliminated
> > 
> > 2)
> > On 06.09.2017 the Icident including a description of the treatment was 
> > reported to the community.
> > 
> > 3)
> > By identifying the error, the configuration of the software has been 
> > changed in such a way that the issuing of certificates with a SHA1 
> > signature is no longer possible.
> > 
> > 4)  
> > The following certificates were concerned:
> > a) CN=v05dua. pnet. ch/Email=betriebit...@post.ch/OU=IT2/O=Post CH 
> > AG/L=Bern/ST=BE/C=CH
> > Certificate Identifier: CEC009CA9554D878F118F9582749B3
> > SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: 
> > E1:96: A4:9D: 05: EE
> > Issued: 16.01.2015
> > Revoked: 2017-09-05 15:37:10
> > b) CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik 
> > AG/L=Herisau/ST=AR/C=CH
> > Certificate Identifier: 743DDD4855841D256DAFBD0448D957A439DEA593D
> > SHA1 Fingerprint: 61: A6: DA: 9A: 3A: E7: F8: C0: E8:95: AC: 26: EB: BD: 
> > E1:96: A4:9D: 05: EE
> > Issued 02/02/2017
> > Revoked 2017-09-06 08:42:42:42
> > 
> > 5)
> > The following reasons for misissunace have been identified:
> > a) the correct configuration of the customer account to prevent the 
> > issuance of SHA1 certificates was activated delayed.
> > b) a new functionality was introduced in the CA software in January 2017, 
> > which made it possible to reissue the certificate signed with SHA1.
> > 
> > 6)
> > The additional functionality introduced in January 2017 had a weak point.
> > This vulnerability was only found because of the detailed error analysis 
> > performed by finding the certificate that was misissued.
> > The misissued certificates where detected by the improved quality control. 
> > No further measures are currently planned.
> > 
> > 7)  
> > The error has been fixed. Configurative measures ensured that no more 
> > certificates can be signed using SHA1.
> > 
> > Best Regards Conny Enke
> 
> -- 
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online


Hi Rob,

no sorry my mistake.

The following certificates were concerned:
a)  CN=v05dua. pnet. ch/Email=betriebit...@post.ch/OU=IT2/O=Post CH
AG/L=Bern/ST=BE/C=CH 
Certificate Identifier:  CEC009CA9554D878F118F9582749B3
SHA1 Fingerprint:
75:E4:D8:02:5D:A2:3C:AA:83:73:41:69:06:DB:EE:E7:06:C3:C4:D8
Issued: 16.01.2015
Revoked: 2017-09-05 15:37:10

b)   CN=*. ari-ag. ch/Email=it...@ari-ag.ch/OU=ARI AG/O=ARAR Informatik
AG/L=Herisau/ST=AR/C=CH 
Certificate Identifier: 743DD4855841D256DAFBD0448D957A439DEA593D
SHA1 Fingerprint:
61:A6:DA:9A:3A:E7:F8:C0:E8:95:AC:26:EB:BD:E1:96:A4:9D:05:EE
Issued 02/02/2017 
Revoked 2017-09-06 08:42:42:42


Regarding the publication I have requestet the operation team.

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

Re: Incident Certificate signed with SHA1 Violation BR 7.3.1

[cornelia.enke66--- via dev-security-policy]

Am Montag, 11. September 2017 12:38:38 UTC+2 schrieb Gervase Markham:
> Hi Connie,
> 
> On 06/09/17 20:38, cornelia.enk...@gmail.com wrote:
> > SwissSign has identified the following incident:
> > two Certificate signed with SHA1: Violation BR 7.3.1
> 
> Thank you for this report. There have been a couple of reasonable
> follow-up questions here in the m.d.s.p. group; could you please answer
> them?
> 
> > 6)
> > The additional functionality introduced in January 2017 had a weak point. 
> > This vulnerability was only found because of the detailed error analysis 
> > performed by finding the certificate that was misissued. 
> > The misissued certificates where detected by the improved quality control. 
> > No further measures are currently planned.
> 
> Have automated tests been put in place to make sure the operation of
> reissuing a SHA-1 certificate always fails, even after further updates
> to the software?
> 
> Gerv

Hi Gerv,

yes automated test had put in place.
The outcome is monitored.

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

Re: CAs not compliant with CAA CP/CPS requirement

[richmoore44--- via dev-security-policy]

I suspect many smaller CAs are non-compliant too, for example gandi's CPS 
hasn't changed since 2009 according to its changelog.

https://www.gandi.net/static/docs/en/gandi-certification-practice-statement.pdf

Cheers

Rich.
___
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

Re: CAs not compliant with CAA CP/CPS requirement

[Liddle, Alan via dev-security-policy]

On Friday, September 8, 2017 at 3:25:20 PM UTC-4, Andrew Ayer wrote:

> The BRs state:

>

> "Effective as of 8 September 2017, section 4.2 of a CA's Certificate

> Policy and/or Certification Practice Statement (section 4.1 for CAs

> still conforming to RFC 2527) SHALL state the CA's policy or practice

> on processing CAA Records for Fully Qualified Domain Names; that

> policy shall be consistent with these Requirements. It shall clearly

> specify the set of Issuer Domain Names that the CA recognises in CAA

> 'issue' or 'issuewild' records as permitting it to issue. The CA SHALL

> log all actions taken, if any, consistent with its processing practice."

>

> Since it is now 8 September 2017, I decided to spot check the CP/CPSes

> of some CAs.

>

> At time of writing, the latest published CP/CPSes of the following CAs

> are not compliant with the above provision of the BRs:

>

> Amazon (https://www.amazontrust.com/repository/) - Does not check CAA

>

> Comodo (https://www.comodo.com/about/comodo-agreements.php) - Does not

> specify issuer domain names

>

> DigiCert (https://www.digicert.com/legal-repository/) - Does not

> specify issuer domain names, and processing is not compliant with BRs

> ("If a CAA record exists that does not list DigiCert as an authorized

> CA, DigiCert verifies that the applicant has authorized issuance,

> despite the CAA record.")

>

> Google Trust Services (https://pki.goog/) - Does not check CAA

>

> Identrust (https://secure.identrust.com/certificates/policy/ts/) -

> Does not check CAA

>

> Izenpe

> (http://www.izenpe.eus/s15-content/en/contenidos/informacion/descarga_

> certificados/es_url/index.shtml)

> - Does not specify issuer domain names

>

> PROCERT (https://www.procert.net.ve/eng/ca.html) - No mention of CAA

>

> Symantec / GeoTrust

> (https://www.geotrust.com/resources/repository/legal/)

> - Does not specify issuer domain names

>

> Trustis (https://www.trustis.com/pki/trustis-ssl/standard/index.htm) -

> No mention of CAA

>

> Visa (http://www.visa.com/pki/) - Does not check CAA

>

>

> These CAs have compliant CP/CPSes:

>

> Entrust

>

> GlobalSign

>

> GoDaddy

>

> Let's Encrypt

>

> QuoVadis

>

> Trustwave

>

>

> It would be nice to hear confirmation from the non-compliant CAs that

> they really are checking CAA as required, and if so, why they

> overlooked the requirement to update their CP/CPS.

>

> Regards,

> Andrew



The Trustis policy referred to :-
https://www.trustis.com/pki/trustis-ssl/standard/index.htm

Is for a service that was retired some while ago. It is no longer issuing 
certificates.


Regards
Alan Liddle

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