Identrust Commercial Root CA 1 EV Request

[Wayne Thayer]

This request is to enable EV treatment for the Identrust Commercial Root CA
1 as documented in the following bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1339292

* BR Self Assessment is here:
https://bugzilla.mozilla.org/attachment.cgi?id=8964414

* Summary of Information Gathered and Verified:
https://bug1339292.bmoattachments.org/attachment.cgi?id=8965525

* Root Certificate Download URL:
https://bugzilla.mozilla.org/attachment.cgi?id=8473319

CP/CPS:
** CP:
https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Policy_V4.1_08172018.pdf
** CPS:
https://www.identrust.com/sites/default/files/resources/IdenTrust_TrustID_Certificate_Practices_Statement_V4.1_08172018.pdf

* This root is already included with Websites and Email trust bits. EV
treatment is requested.
** EV Policy OID: 2.23.140.1.1
** Original inclusion request:
https://bugzilla.mozilla.org/show_bug.cgi?id=1037590

* Test Websites:
** Valid: https://ev-valid.identrustssl.com/
** Expired: https://ev-expired.identrustssl.com/
** Revoked: https://ev-revoked.identrustssl.com/

* CRL URL: http://validation.identrust.com/trustidcaa52.crl
* OCSP URL: http://commercial.ocsp.identrust.com/

* Audit: Annual audits are performed by Schellman according to the WebTrust
for CA, BR, and EV audit criteria.
** WebTrust: https://cert.webtrust.org/ViewSeal?id=2331
** BR: https://www.cpacanada.ca/webtrustseal?sealid=2334
** EV: https://www.cpacanada.ca/webtrustseal?sealid=2335

I’ve reviewed the CPS, BR Self Assessment, and related information for the
Identrust Commercial Root CA 1 EV request that is being tracked in this bug
and have the following comments:

==Good==
* Identrust’s audits prior to 2016 don’t list specific roots, but this root
appears to have been audited back to its creation in 2014.
* In their latest BR audit statement [1], Identrust’s auditor includes an
“Emphasis on Matters” section in which they list four BR violations
disclosed by Identrust. All of these issues were previously known and are
included in comments below.
* CPS section 1.4.2 expressly prohibits the use of Identrust certificates
for MitM.

==Meh==
* There are a few misissued certs documented under this root [2][3]. All
appear to be expired or revoked.
* Identrust was the subject of two compliance bugs last year [4][5]. Both
have been resolved, but it was noted that Identrust was slow to respond to
Mozilla’s questions.
* Three intermediate certificates have been disclosed under this root, but
the EV audit explicitly lists only the TrustID Server CA A52 as in-scope.
The A12 intermediate is constrained by EKU to emailProtection, but the Booz
Allen Hamilton BA CA 01 is not. The Booz Allen Hamilton BA CA 01 does
contain a set of policy OIDs that exclude Identrust’s EV policy, but that
does not satisfy section 3.1.2 of Mozilla policy. However, Firefox will not
display an EV indication if the intermediate certificate’s
certificatePolicies extension does not include either anyPolicy or the CAs
or CABF EV policy OID, so I believe this is a problem with our policy.
* Identrust’s CPS section 1.3.2 allow delegation of the RA function but
doesn’t explicitly state that domain validation must be performed by
Identrust. The CPS does state that it complies with the BRs which forbid
delegation of domain validation.
* CPS section 2.3 states that the PMA updates the CPS on an annual basis to
include the most recent CAB Forum requirements, but Mozilla expects CPS
updates to happen whenever required by changes to either CAB Forum
requirements or Mozilla policy. However, both the CP and CPS have been
updated more frequently in the past year.
* Typo in CPS section 6.9 heading: “ENGINREERING”

==Bad==
* Identrust had an open compliance bug for improper encoding of 6 wildcard
certificates [6]. Remediation for this bug included the implementation of
pre-issuance linting by the end of Q3, more than 6 months after the issue
was reported. Identrust also chose to wait a week before revoking all of
the misissued certificates. This could be considered another example of
Identrust being slow to respond, but they did confirm that pre-issuance
linting was deployed in August, well ahead of their goal.
* The version of the CPS that I initially reviewed (4.0) describes a number
of methods of domain name validation in section 3.2.10.5 that do not appear
to fully comply with the BRs. This was corrected in the current version,
but one of the methods listed is BR 3.2.2.4.10, which contains a known
vulnerability [7].
* Two of the Identrust policy OIDs listed in the Booz Allen Hamilton BA CA
0 intermediate certificate were not documented in Identrust’s CP or CPS,
but have been added to the latest version.
* Section 3.2 of the CPS states that “All documents and data provided for
verifying the Server Certificate must not be used by the RA if the document
or data was obtained 39 or more months prior to the Issuance of the
Certificate or in the case of EV SSL, 13 months prior to issuance.”. The
BRs now only allow reuse for up to 825 days.
* CP section 9.8 paragraph 3 appears to violate EVGL section 18’s
restriction on liability limits for EV certificates by limiting aggregate
liability. CPS section 9.8 may also contradict both the liability limits in
the CP and the EVGL requirement.

This begins the 3-week comment period for this request [8].

I will greatly appreciate your thoughtful and constructive feedback on the
decision to grant EV treatment to this root certificate.

- Wayne

[1] https://bug1484318.bmoattachments.org/attachment.cgi?id=9006626
[2]
https://crt.sh/?caid=1588&opt=cablint,zlint,x509lint&minNotBefore=2014-01-01
[3]
https://crt.sh/?caid=47552&opt=cablint,zlint,x509lint&minNotBefore=2017-01-01
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1391000
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1398255
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1446121
[7]
https://groups.google.com/d/msg/mozilla.dev.security.policy/RHsIInIjJA0/LKrNi35aAQAJ
[8] https://wiki.mozilla.org/CA/Application_Process

[Nick Lamb]

On Tue, 18 Sep 2018 17:53:34 -0700
Wayne Thayer via dev-security-policy

<dev-secur...@lists.mozilla.org> wrote:

> * The version of the CPS that I initially reviewed (4.0) describes a
> number of methods of domain name validation in section 3.2.10.5 that
> do not appear to fully comply with the BRs. This was corrected in the
> current version, but one of the methods listed is BR 3.2.2.4.10,

> which contains a known vulnerability.

Since the time of the post about 3.2.2.4.10 the Let's Encrypt team (and
others via the relevant IETF working group?) have developed a new
realisation of 3.2.2.4.10 that is not vulnerable.

Specifically tls-sni-01 and tls-sni-02 are replaced by tls-alpn-01
which as its name might suggest uses an ALPN TLS feature to ask a
remote server to show the certificate. This involves a brand new ALPN
sub-protocol with no other purpose. Suppliers who aren't trying to help
their customers get certificates have no reason to develop/
enable/ configure such a feature. So it becomes reasonable (unlike with
SNI) to assume that if the check passes, it was intended to pass by the
name's real owner or by their agent.

Section 3.2.10.5 doesn't specify how Identrust's checks work, and it
would be desirable to have better descriptions for methods like
3.2.2.4.10 that are a bit vague, but it's definitely not true that all
realisations of 3.2.2.4.10 are broken.

Nick.

[Wayne Thayer]

Good point Nick. Can someone from Identrust provide more details on
Identrust's use and implementation of validation method 3.2.2.4.10?

- Wayne

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[iden...@gmail.com]

On Monday, September 24, 2018 at 1:09:07 PM UTC-4, Wayne Thayer wrote:
> Good point Nick. Can someone from Identrust provide more details on
> Identrust's use and implementation of validation method 3.2.2.4.10?

[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as we were exploring the possibility to use it in the future but have decided to discard that option. This validation method will be removed for the CPS. We also confirm that we have not used this validation method for any certificate issuance.

> - Wayne
>
> On Sat, Sep 22, 2018 at 3:43 AM Nick Lamb via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
> > On Tue, 18 Sep 2018 17:53:34 -0700
> > Wayne Thayer via dev-security-policy
> > <dev-secur...@lists.mozilla.org> wrote:
> >
> > > * The version of the CPS that I initially reviewed (4.0) describes a
> > > number of methods of domain name validation in section 3.2.10.5 that
> > > do not appear to fully comply with the BRs. This was corrected in the
> > > current version, but one of the methods listed is BR 3.2.2.4.10,
> > > which contains a known vulnerability.

[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as we were exploring the possibility to use it in the future but have decided to discard that option. This validation method will be removed for the CPS. We also confirm that we have not used this validation method for any certificate issuance.

> > Since the time of the post about 3.2.2.4.10 the Let's Encrypt team (and
> > others via the relevant IETF working group?) have developed a new
> > realisation of 3.2.2.4.10 that is not vulnerable.
> >
> > Specifically tls-sni-01 and tls-sni-02 are replaced by tls-alpn-01
> > which as its name might suggest uses an ALPN TLS feature to ask a
> > remote server to show the certificate. This involves a brand new ALPN
> > sub-protocol with no other purpose. Suppliers who aren't trying to help
> > their customers get certificates have no reason to develop/
> > enable/ configure such a feature. So it becomes reasonable (unlike with
> > SNI) to assume that if the check passes, it was intended to pass by the
> > name's real owner or by their agent.
> >
> > Section 3.2.10.5 doesn't specify how Identrust's checks work, and it
> > would be desirable to have better descriptions for methods like
> > 3.2.2.4.10 that are a bit vague, but it's definitely not true that all
> > realisations of 3.2.2.4.10 are broken.
> >
> > Nick.

[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as we were exploring the possibility to use it in the future but have decided to discard that option. This validation method will be removed for the CPS. We also confirm that we have not used this validation method for any certificate issuance.
Marco S.

[iden...@gmail.com]

[IdenTrust:]Agree with this comment and confirm that IdenTrust as issuing CA is responsible for and does handle domain name validation prior the issuance of any server certificate. CPS Section 1.3.2 will be updated accordingly.

> * CPS section 2.3 states that the PMA updates the CPS on an annual basis to
> include the most recent CAB Forum requirements, but Mozilla expects CPS
> updates to happen whenever required by changes to either CAB Forum
> requirements or Mozilla policy. However, both the CP and CPS have been
> updated more frequently in the past year.

[IdenTrust:]
Agree with this comment and confirm that policy documents have been updated and published more than once a year. CPS section 2.3 will be updated accordingly.

> * Typo in CPS section 6.9 heading: “ENGINREERING”

[IdenTrust:]Thanks for pointing out this typo; it will be corrected in the next CPS version.

> ==Bad==
> * Identrust had an open compliance bug for improper encoding of 6 wildcard
> certificates [6]. Remediation for this bug included the implementation of
> pre-issuance linting by the end of Q3, more than 6 months after the issue
> was reported. Identrust also chose to wait a week before revoking all of
> the misissued certificates. This could be considered another example of
> Identrust being slow to respond, but they did confirm that pre-issuance
> linting was deployed in August, well ahead of their goal.
> * The version of the CPS that I initially reviewed (4.0) describes a number
> of methods of domain name validation in section 3.2.10.5 that do not appear
> to fully comply with the BRs. This was corrected in the current version,
> but one of the methods listed is BR 3.2.2.4.10, which contains a known
> vulnerability [7].

[IdenTrust:]We have confirmed in the Jan/2018 CA Communication Survey that this method has not been used by IdenTrust. We added it to the CPS on 8/17/2017 as we were exploring the possibility to use it in the future but have decided to discard that option. This validation method will be removed for the CPS. We also confirm that we have not used this validation method for any certificate issuance.

> * Two of the Identrust policy OIDs listed in the Booz Allen Hamilton BA CA
> 0 intermediate certificate were not documented in Identrust’s CP or CPS,
> but have been added to the latest version.
> * Section 3.2 of the CPS states that “All documents and data provided for
> verifying the Server Certificate must not be used by the RA if the document
> or data was obtained 39 or more months prior to the Issuance of the
> Certificate or in the case of EV SSL, 13 months prior to issuance.”. The
> BRs now only allow reuse for up to 825 days.

[IdenTrust:] Updating this was inadvertently omitted in the CPS when the document was updated to remove future issuance of 3 year SSL certificates. As of April 20, 2018, IdenTrust have not used documents older than 27 months for standards SSL certificates or older than 13 months for EV SSL certificates.
The CPS section 3.2 will be corrected accordingly.

> * CP section 9.8 paragraph 3 appears to violate EVGL section 18’s
> restriction on liability limits for EV certificates by limiting aggregate
> liability. CPS section 9.8 may also contradict both the liability limits in
> the CP and the EVGL requirement.

[IdenTrust:]We will update the CPS to comply with EVGL Section 18 liability limits. We will publish an updated CPS by October 18, 2018.

[nichola...@gmail.com]

On February 21 2018, I reported an unexpired certificate to Identrust which contained SAN entries for several invalid .INT domains:

https://crt.sh/?id=7852280

They acknowledged and revoked the certificate in a timely manner. However, I find this event particularly bothersome:

- This certificate was created for Identrust's own internal use.
- The issue of .int being a valid TLD has been communicated and well-known since 2009 [1]
- I don't believe Identrust has disclosed this misissuance as required.

-Nick

[1] https://groups.google.com/d/msg/mozilla.dev.security.policy/L9A67IryHu0/RzeaEgIjt48J

[iden...@gmail.com]

Mr. Hatch is correct and although IdenTrust worked to resolve this issue immediately and responded to him accordingly, there was an oversight on our part not to file the formal misissuance report more broadly to the public forum. With our apologies, here is that report:
1.How your CA first became aware of the problems listed below (e.g. via a Problem Report, via the discussion in mozilla.dev.security.policy, or via this Bugzilla Bug), and the date.
IdenTrust: We were made aware of this issue on 02/22/2018 from Nicholas Hatch via an email message to IdenTrust customer support.

2.Prompt confirmation that your CA has stopped issuing TLS/SSL certificates with the problems listed below.
IdenTrust: The certificate in question was revoked on the same date, 02/22/2018

3. Complete list of certificates that your CA finds with each of the listed issues during the remediation process. The recommended way to handle this is to ensure each certificate is logged to CT and then attach a CSV file/spreadsheet of the fingerprints or crt.sh IDs, with one list per distinct problem.
IdenTrust: Only one certificate was found to have SAN containing ‘.int’ domain. This certificate was issued on 5/21/2015 with cert.sh ID: https://crt.sh/?id=7852280. As noted in #2, this certificate was revoked on 2/22/2018.

4. Summary of the problematic certificates. For each problem listed below:
number of certs, date first and last certs with that problem were issued.
IdenTrust: Problematic certificates consists of only one certificate issued on 5/21/2015 and installed on IdenTrust server. As noted in #2, this certificate was revoked on 2/22/2018.

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.

When the problem was identified, IdenTrust revoked the certificate and issued a new certificate without the Autodiscover.identrus.int and Mercury.identrus.int.

6. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.
IdenTrust: Post 02/22/2018, IdenTrust implemented a change in the certificate approval processes that will prevent the domain names with the .int TLD from being approved.

[Matt Palmer]

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.

> 6. List of steps your CA is taking to resolve the situation and ensure
> such issuance will not be repeated in the future, accompanied with a
> timeline of when your CA expects to accomplish these things.
>
> IdenTrust: Post 02/22/2018, IdenTrust implemented a change in the
> certificate approval processes that will prevent the domain names with the
> .int TLD from being approved.

What about other non-existent TLDs?

- Matt

[Jakob Bohm]

And what about real domains in the very existant .int domain (in case
one of those requests an Identrust certificate).

..int contains almost exclusively high value domains such as un.int,
nato.int etc.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[iden...@gmail.com]

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. In this particular case, there was an exception requested by IT staff to our registration desk and was escalated and granted through a risk management process as the certificate and associated server in question was not expected to be accessible externally and the server was to be operational only for short duration. 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.
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.

>
> > 6. List of steps your CA is taking to resolve the situation and ensure
> > such issuance will not be repeated in the future, accompanied with a
> > timeline of when your CA expects to accomplish these things.
> >
> > IdenTrust: Post 02/22/2018, IdenTrust implemented a change in the
> > certificate approval processes that will prevent the domain names with the
> > .int TLD from being approved.
>
> What about other non-existent TLDs?
> > - Matt

IdenTrust: Our website certificate issuance procedures (including domain validation\verification and procedures for handling High Risk Certificate Requests) apply to all requests containing any TLDs.

[iden...@gmail.com]

IdenTrust: A request with a ‘.int’ and all other TLDs, including “high value” domains, are processed through our website certificate issuance procedures including domain validation\verification and procedures for handling High Risk Certificate Requests.

[iden...@gmail.com]

On Wednesday, October 17, 2018 at 2:02:34 PM UTC-4, Jakob Bohm wrote:

> On 17/10/2018 01:18, 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.
> >
> >> 6. List of steps your CA is taking to resolve the situation and ensure
> >> such issuance will not be repeated in the future, accompanied with a
> >> timeline of when your CA expects to accomplish these things.
> >>
> >> IdenTrust: Post 02/22/2018, IdenTrust implemented a change in the
> >> certificate approval processes that will prevent the domain names with the
> >> .int TLD from being approved.
> >
> > What about other non-existent TLDs?
> >
> > - Matt
> >
>
> And what about real domains in the very existant .int domain (in case
> one of those requests an Identrust certificate).
>
> ..int contains almost exclusively high value domains such as un.int,
> nato.int etc.
>

> IndenTrust: request with a ‘.int’ and all other TLDs, including “high value” domains, are processed through our website certificate issuance procedures including domain validation\verification and procedures for handling High Risk Certificate Requests.

[Matt Palmer]

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?

Please share the criteria which were used to evaluate exception requests.

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.

Finally, can you speak to why the BR requirements around internal names and
certificate expiry dates wasn't followed in this case?

> 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?

> 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?

- Matt

[iden...@gmail.com]

IdenTrust: We acknowledge the request for more information and are actively working on getting the necessary details to accurately respond. We will respond as soon as we can.

[Wayne Thayer]

I've filed a bug to track this misissuance and subsequent failure to
report: https://bugzilla.mozilla.org/show_bug.cgi?id=1500593

On Fri, Oct 19, 2018 at 6:22 AM identrust--- via dev-security-policy <
dev-secur...@lists.mozilla.org> wrote:

[iden...@gmail.com]

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

[Wayne Thayer]

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-secur...@lists.mozilla.org> wrote:

> 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
>

[iden...@gmail.com]

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.

[Wayne Thayer]

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-secur...@lists.mozilla.org> wrote:

> On Friday, November 2, 2018 at 10:41:34 AM UTC-6, Wayne Thayer wrote:

[Wayne Thayer]

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 Wed, Nov 7, 2018 at 4:30 PM identrust--- via dev-security-policy <
> dev-secur...@lists.mozilla.org> wrote:
>
>> On Friday, November 2, 2018 at 10:41:34 AM UTC-6, Wayne Thayer wrote: