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 < dev-security-policy@lists.mozilla.org> 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 < > > dev-security-policy@lists.mozilla.org> 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 > > > dev-security-policy@lists.mozilla.org > > > 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 > 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
