On Fri, Sep 15, 2017 at 12:30 PM, Inigo Barreira via dev-security-policy < [email protected]> 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 much an apt comparison. The inability of a CA to provide sufficient assurance of what it has - and has not - done is fundamental to trust. This should be obvious to all CAs in light of the situations involving other CAs that have been or are in the process of being distrusted. > > > > > > 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. > > No, or not totally. We have issued those certs but not cross-signed by > Certinomis because we didn´t have the cross-signed certificates so, all of > them were issued under the new startcom hierarchy > <snip> > > > 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 50000, or the new > ones, > > go with the Certinomis path because none have it. But all those 50000 > 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? > > No, it´s from the new hierarchy. > I'm afraid this suggests a fundamental misunderstanding or unawareness of how PKI works with respect to cross-signing, and of all the responses, this is the most deeply troubling towards both the present inclusion request and any future inclusion request. https://crt.sh/?caid=45939 is an example of a CA you have created. It is a subordinate CA to https://crt.sh/?caid=45729 , which is proposed as the new self-signed root. This is your new hierarchy. There are approximately 26,766 certificates issued from this hierarchy ( https://crt.sh/?Identity=%25&iCAID=45939 ) - without deduping precerts and actual certs, but let's graciously assume we can divide by two. https://crt.sh/?id=210067108&opt=cablint is an example of a certificate that demonstrates a process failure that has, in the past, been directly reported to StartCom, and was suggested that it was a system error that has been remedied. It has not. This raises concerns about how well StartCom can or will remedy system issues when discussed with them. The fact that it was revoked an hour after issuance does not raise confidence - it reduces it. Your assertion, to Gerv (quoted above), is that these certificates are "not cross-signed by Certinomis because we didn´t have the cross-signed certificates so, all of them were issued under the new startcom hierarchy" and that "So none of those 50000, or the new ones, go with the Certinomis path because none have it." This, however, is false. This is because https://crt.sh/?caid=45939 is also a subordinate CA to https://crt.sh/?caid=5676 (by virtue of https://crt.sh/?id=182884215 ) To ensure there is no ambiguity that these certificates from the new hierarchy are cross-signed by Certinomis, I will highlight the specific issue: https://crt.sh/?d=8559669 (Certinomis - Root CA) https://crt.sh/?d=182884215 (StartCom BR SSL ICA) https://crt.sh/?d=210067108 (xn--tvik-gra.no) Show that the certificate https://crt.sh/?id=210067108&opt=cablint is cross-signed by Certinomis, as is every other certificate of the "StartCom BR SSL ICA" https://crt.sh/?caid=45939&opt=cablint&minNotBefore=2017-01-01 lists a set of BR violations from this BR SSL ICA. Because of this cross-signing, every one of the issued certificates is valid to the Certinomis - Root CA, and, should the StartCom G3 root be included, valid to the StartCom G3 root. I can understand your assertion that these certificates are revoked. That does not mean they do not present risk to the ecosystem. Let's carefully examine https://crt.sh/?id=182884215&opt=cablint - notBefore of 2017-04-13 - audit dated 2017-06-30 - disclosed via CT on 2017-08-02 If I understand your assertion correctly, this certificate was either not issued or not delivered until July, on the basis of the audit. The lack of disclosure until 2017-08-02 (by either StartCom or Certinomis) is seen to assert this, although the community lacks the information to independently assess whether or not this is factually correct. If it was not delivered until July, but was issued on 2017-04-13, then questions exist regarding what process Certinomis used to issue, but not deliver, the certificate. That is, in the absence of an audit, why was the certificate signed at all (which would be non-compliance by Certinomis). If it was not signed until July, but was dated to 2017-04-13, then questions exist regarding why Certinomis 'backdated' this intermediate in such a way to overlap with a period of known non-compliance with StartCom. That is, it would be a poor decision by Certinomis. In either event, the existence of this cross-sign means that public trust in certificates issued from this hierarchy has been restored, and includes a period of known (at the time of delivery and/or issuance of the sub-CA) non-compliance. This is concerning. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
