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