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
