Since there haven't been any further comments regarding my recommendation to deny this request, I would like to ask for feedback on next steps that Identrust can take in the event of a denial. I believe that Identrust would still like to pursue EV recognition in Firefox, but I think it's unlikely that we would approve another request for this root or the other roots they operate under the same CP/CPS and audits without some evidence that the issues discussed in this request have been resolved.
Identrust could: * wait for some period of time during which no new issues are found (1 year?) and reapply for EV indication. * obtain clean Point-in-Time audit reports and reapply. * create a new root and apply for EV indication as part of the inclusion request. Assuming that the new root is cross-signed, we might need to enable EV for the current root (Commercial Root CA 1) to make the new root useful for EV issuance. I think it is reasonable for Identrust to ask how they should proceed, and I would greatly appreciate everyone's input on this question. To be clear, the results of this discussion (if any) will only be suggestions that may improve our trust in Identrust. Mozilla reserves the right to deny any future requests from Identrust or any CA despite having followed any or all suggestions that are made. - Wayne On Fri, Nov 9, 2018 at 9:26 AM Wayne Thayer <[email protected]> wrote: > It might be helpful for me to provide a better explanation of the thinking > that went into my recommendation: > > The timeline of the Internal Name incident is as follows: > * Identrust appears to have stopped issuing certificates containing .INT > names prior to the BR deadline. > * They then failed to revoke existing certificates prior to the BR > deadline. This is reasonably explained as a mistake - a number of CAs > missed this deadline. > * Any CA following this list at the time should have seen the discussion > about this and taken the initiative to ensure they were in compliance. > Mozilla policy didn't require CAs to follow this list at that time, but > doing so was certainly recognized as a wise thing to do. For unknown > reasons, Identrust didn't get the message. > * In Feb 2018, an unexpired certificate containing a .INT name was > reported to Identrust. They revoked the certificate, but didn't report the > incident, and didn't revoke the other two non-expired certificates. > * In October, that one certificate was reported to this list, and > Identrust provided an incident report and disclosed two other certificates > that should have been revoked in February. > > My conclusion from this chain of events is that Identrust plausibly made > two mistakes back in 2016 that left these certificates unrevoked, but was > made aware of the problem in February. At that point, Identrust failed to > investigate further and to disclose the problem. My recommendation stems > primarily from Identrust's actions in Feb which concealed the problem from > the community. I can't speak to their intentions, but I have difficulty > viewing this as a(nother) mistake. I think we've been very clear on our > expectations for CAs to disclose and remediate problems [1] and there have > been abundant examples on this list to learn from. If a CA fails to > disclose a problem and then later gets caught, a strong(er) reaction is > warranted because the CA has violated our trust, regardless of the severity > of the problem. > > [1] https://wiki.mozilla.org/CA/Responding_To_An_Incident > > > On Wed, Nov 7, 2018 at 4:30 PM identrust--- via dev-security-policy < > [email protected]> wrote: > >> On Friday, November 2, 2018 at 10:41:34 AM UTC-6, Wayne Thayer wrote: >> > I am recommending denial of this request. >> > >> > It was not uncommon for CAs to treat the .int TLD as an Internal Name, >> so >> > I'm not going to argue this point and claim that these certificates were >> > misissued because 'identrust.int' and 'identrus.int' were not >> registered >> > domain names. >> > >> > Under the assumption that these are Internal Names, none of these >> > certificates were issued after the BR deadline of 1-November 2015. From >> > this I would infer that Identrust was aware of the requirements. Three >> of >> > the disclosed certificates were not expired or revoked prior to the BR >> > Internal Name deadline of 1-October 2016: >> > https://crt.sh/?id=7852280 >> > https://crt.sh/?id=882509134 >> > https://crt.sh/?id=882509077 >> > >> > This happened in spite of well documented incidents in which other CAs >> > failed to revoke certificates containing Internal Names [1]. One of >> these >> > three certificates was revoked on 22-February 2018, corresponding with >> the >> > date Nick Hatch reported it to Identrust. Identrust did not disclose the >> > incident, nor - given that the other two were never revoked - did they >> > apparently perform a scan of their certificates to identify any others. >> > This calls into question Identrust's ability to adhere to the BRs, their >> > remediation practices, and their willingness to publicly disclose >> incidents. >> > >> > Identrust has requested that Mozilla grant EV indication to the >> Commercial >> > Root CA 1 - the same root involved in this incident. Identrust's >> actions in >> > this incident are troubling and provide justification for denying the >> > higher level of trust implied by EV. >> > >> > - Wayne >> > >> > [1] >> > >> https://groups.google.com/d/msg/mozilla.dev.security.policy/00gci6NII9Y/AsQHXkltDgAJ >> > >> > On Mon, Oct 22, 2018 at 2:14 PM identrust--- via dev-security-policy < >> > [email protected]> wrote: >> > >> > > On Wednesday, October 17, 2018 at 9:08:41 PM UTC-4, Matt Palmer wrote: >> > > > On Wed, Oct 17, 2018 at 03:09:52PM -0700, identrust--- via >> > > dev-security-policy wrote: >> > > > > On Tuesday, October 16, 2018 at 7:19:07 PM UTC-4, Matt Palmer >> wrote: >> > > > > > On Tue, Oct 16, 2018 at 02:18:39PM -0700, identrust--- via >> > > dev-security-policy wrote: >> > > > > > > 5.Explanation about how and why the mistakes were made, and >> not >> > > caught and >> > > > > > > fixed earlier. >> > > > > > > >> > > > > > > IdenTrust: >> > > The certificate was generated for a server within IdenTrust. >> > > > > > > The certificate contained internal domain names which were not >> > > reachable >> > > > > > > externally. Two domain names in the SAN ( >> > > Autodiscover.identrus.int and >> > > > > > > Mercury.identrus.int) were included at that time. When the >> > > certificate >> > > > > > > was generated, these domains were internally hosted domains. >> > > > > > >> > > > > > This doesn't explain why the mistakes were made, nor does it >> explain >> > > why >> > > > > > they were not caught and fixed earlier. >> > > > > >> > > > > IdenTrust:IdenTrust has strict procedures regarding issuance of >> > > publicly >> > > > > trusted website certificates. However at the time of this >> certificate >> > > > > issuance (2015) the procedures did allow ability to request >> exceptions >> > > for >> > > > > IdenTrust internal deployments that were not accessible >> externally. >> > > > >> > > > On what date was this exception-requesting element added to >> IdenTrust's >> > > > procedures? >> > > IdenTrust: >> > > At this point we are unable to ascertain the exact date the >> > > exception-requesting element was added. We can confirm the that the >> > > exception-requesting element pre-dates 2012. >> > > >> > > > Please share the criteria which were used to evaluate exception >> requests. >> > > IdenTrust: >> > > The criteria for the exception is that Registration desk, upon >> request of >> > > IdenTrust IT Staff, can request to risk management an exception to >> complete >> > > an attempted Verification of Domain through external registrars for >> domain >> > > name that is IdenTrust owned domain equivalent for servers that will >> not be >> > > accessible externally. >> > > >> > > > How many times has the procedure for requesting an exception been >> used? >> > > How >> > > > many times has the exception been granted? I think it would be >> best if >> > > all >> > > > certificates issued under this exception process were made public, >> to >> > > ensure >> > > > that there is full transparency around the extent to which this >> exception >> > > > process was used. >> > > IdenTrust: >> > > The exception request has been used on the issuance of the 13 >> certificates >> > > listed below, now in CT logs. Please note that majority of the >> > > certificates listed were issued pre-2012. >> > > https://crt.sh/?id=514746 >> > > https://crt.sh/?id=7852280 >> > > https://crt.sh/?id=882509134 >> > > https://crt.sh/?id=882509077 >> > > https://crt.sh/?id=882509158 >> > > https://crt.sh/?id=882509159 >> > > https://crt.sh/?id=882597656 >> > > https://crt.sh/?id=882509100 >> > > https://crt.sh/?id=882509154 >> > > https://crt.sh/?id=882509101 >> > > https://crt.sh/?id=882597659 >> > > https://crt.sh/?id=882509103 >> > > https://crt.sh/?id=882509147 >> > > >> > > > Finally, can you speak to why the BR requirements around internal >> names >> > > and >> > > > certificate expiry dates wasn't followed in this case? >> > > IdenTrust: >> > > As noted the exception request procedure pre-dates 2012. Our best >> > > determination is that the procedure was not updated correctly to >> remove the >> > > ability to allow the exception for internal names for IdenTrust owned >> > > domains on at the time BR v1 was adopted in 2012 as it should have >> been. >> > > > > However due to human error in implementation the server was made >> > > available >> > > > > external to our network. Also due to human error, the IT staff >> failed >> > > to >> > > > > request certificate revocation when the certificate was no longer >> > > needed. >> > > > >> > > > Speaking of revocation, can you explain why this certificate wasn't >> > > caught >> > > > by the requirement to revoke all certificates containing internal >> names >> > > by >> > > > 2016-10-01? >> > > IdenTrust: >> > > This was due to human error in interpreting the exception granted to >> > > certificates issued to internal names of IdenTrust owned domain >> equivalents >> > > on servers that were not supposed to be accessible externally. The >> > > following certificates containing internal names were not revoked as >> of >> > > 2016-10-01: >> > > https://crt.sh/?id=514746 >> > > https://crt.sh/?id=7852280 >> > > https://crt.sh/?id=882509134 >> > > https://crt.sh/?id=882509077 >> > > >> > > >> > > > > Upon discovering of this misissuance on 02/22/2018, IdenTrust >> updated >> > > the >> > > > > website certificate approval procedures to eliminate the ability >> to >> > > > > request exceptions to the standard domain validation\verification >> > > > > procedures. Please note that these website issuance procedures >> apply >> > > to >> > > > > all applications regardless of the TLD(s) requested in the >> certificate >> > > > > application. >> > > > >> > > > Correct me if I'm wrong, but does this mean that until the date you >> > > > specified above, it was procedurally possible for IdenTrust to >> issue a >> > > > certificate for *any* domain based on the invocation of this >> exception? >> > > > Under which subsection of BR section 3.2.2.4 does IdenTrust believe >> this >> > > > procedure was permitted as of the date of the procedure update? >> > > IdenTrust: >> > > The exception is limited to IdenTrust internal servers for internal >> name >> > > equivalent of IdenTrust owned domain name. While its conceivable >> that any >> > > domain could have been requested it is not possible (with exception of >> > > human error) that it would pass the test that domain equivalent is >> owned >> > > by IdenTrust and therefore not in scope for granting an exception. >> Of >> > > course its clear that upon adoption of BR v1 in 2012 we should have >> removed >> > > this pre-BR exception as it is not allowed under BR section 3.2.2.4. >> > > > - Matt >> > > >> > > _______________________________________________ >> > > dev-security-policy mailing list >> > > [email protected] >> > > https://lists.mozilla.org/listinfo/dev-security-policy >> > > >> >> IdenTrust appreciates the due diligence that has been exercised in >> reviewing IdenTrust’s EV SSL application with Mozilla; however, we disagree >> with the recommendation for denial of our application. In the application >> response, specific circumstances were cited that are the basis of the >> recommendation for denial. IdenTrust acknowledges that we could have >> handled resolution of these issues more efficiently and in accordance with >> established procedures. IdenTrust does not refute or challenge these >> errors and have confirmed that of the three (3) internal certificates >> issued under these circumstances, one (1) was revoked and the other two (2) >> have expired. IdenTrust further asserts that new and/or modified processes >> and procedures have been implemented to insure that CA/B Forum posts are >> monitored, evaluated and when appropriate, actionable tasks are identified >> to ensure ongoing compliance. >> Since the inception of CA/B Forum Business Requirements (BR), IdenTrust >> has adhered to these guidelines for SSL/TLS certificates and like other >> participating CA’s, IdenTrust has willingly and expeditiously corrected >> issues reported by the community in order to ensure ongoing compliance. In >> all circumstances, IdenTrust has acted in good faith and attended to these >> matters with urgency and priority. >> In our opinion, the severity level assigned to issues considered as a >> part of the evaluation is not commensurate with such an extreme measure as >> denial of our EV application and we challenge the perception that these >> incidents identify a pattern that suggests our inability to comply with BR >> requirements. Further, IdenTrust is routinely subject to and successfully >> completes a number of required industry-standard and customer mandated >> audits on an annual basis which ensure adherence to multiple PKI policy and >> practice statements. Although IdenTrust admits that mistakes have been >> made with respect to identifying and reporting issues related to these >> three (3) certificates via the Mozilla forum, IdenTrust asserts that this >> specific incident was a result of human error and was not caused by wide >> spread execution problems, intentional disregard or malicious intent. We >> also contend that circumstances pertaining to other participants, that may >> be considered as significantly more egregious than those identified in this >> analysis, have been previously identified and amicable remediation has been >> reached that is unbiased and beneficial to the community. >> Based on these factors and in consideration of on our long-standing >> participation in and reputable status among the industries served by the >> PKI community, IdenTrust respectfully requests that our EV SSL for Mozilla >> application be accepted. >> _______________________________________________ >> dev-security-policy mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-security-policy >> > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
