Re: EV Policy OIDs (was Re: Identrust Commercial Root CA 1 EV Request)
I've added a page to our wiki that describes how Firefox determines if a particular website received the EV UI: https://wiki.mozilla.org/CA/EV_Processing_for_CAs I mentioned this at the last CA/Browser Forum meeting and I hope it is useful to CAs - especially those who are dealing with cross-signing and legacy hierarchies. Since there were no comments about requiring the use of the CA/Browser Forum EV OID, we've left it as 'strongly encouraged', but I added it to our issues list for the Root Store Policy: https://github.com/mozilla/pkipolicy/issues/160 - Wayne On Thu, Sep 20, 2018 at 1:55 PM Wayne Thayer wrote: > Hi Nick, > > Good question. Mozilla is currently strongly encouraging CAs to use the > CAB Forum EV OID, but not requiring it. I would be interested to hear > arguments for or against requiring the use of the CAB Forum EV OID in > future Mozilla root store updates. Requiring this might eventually solve > some of the problems we're seeing when roots are acquired or cross-signed > [1]. To be clear, at this time I'm only thinking about new inclusions or EV > enablement, not changing OIDs for existing EV capable roots. > > - Wayne > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1486838 > > On Thu, Sep 20, 2018 at 1:49 AM Nick Lamb via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Tue, 18 Sep 2018 17:53:34 -0700 >> Wayne Thayer via dev-security-policy >> wrote: >> >> > ** EV Policy OID: 2.23.140.1.1 >> >> This reminds me of a question I keep meaning to ask. I know Microsoft >> has been trying to get CAs to use 2.23.140.1.1 for EV and knock it off >> with the arbitrary policy OIDs, does Mozilla have any policy on that? >> >> >> >> ___ >> 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
Re: Identrust Commercial Root CA 1 EV Request
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 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 < > 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
Re: Identrust Commercial Root CA 1 EV Request
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 > > >
Re: Identrust Commercial Root CA 1 EV Request
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
Re: Identrust Commercial Root CA 1 EV Request
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
Re: Identrust Commercial Root CA 1 EV Request
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
Re: Identrust Commercial Root CA 1 EV Request
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-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? > > > > 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 > 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. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
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? > > 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 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
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. > 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
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. > > > 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 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
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. 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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
On Monday, October 15, 2018 at 7:15:26 PM UTC-4, Nick Hatch wrote: > 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 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Identrust Commercial Root CA 1 EV Request
On Tuesday, September 18, 2018 at 8:53:58 PM UTC-4, Wayne Thayer wrote: > 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. [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
Re: Identrust Commercial Root CA 1 EV Request
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-security-policy@lists.mozilla.org> wrote: > > > On Tue, 18 Sep 2018 17:53:34 -0700 > > Wayne Thayer via dev-security-policy > > 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. > > ___ > > 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
Re: Identrust Commercial Root CA 1 EV Request
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 On Sat, Sep 22, 2018 at 3:43 AM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, 18 Sep 2018 17:53:34 -0700 > Wayne Thayer via dev-security-policy > 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. > ___ > 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
Re: Identrust Commercial Root CA 1 EV Request
On Tue, 18 Sep 2018 17:53:34 -0700 Wayne Thayer via dev-security-policy 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. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: EV Policy OIDs (was Re: Identrust Commercial Root CA 1 EV Request)
Hi Nick, Good question. Mozilla is currently strongly encouraging CAs to use the CAB Forum EV OID, but not requiring it. I would be interested to hear arguments for or against requiring the use of the CAB Forum EV OID in future Mozilla root store updates. Requiring this might eventually solve some of the problems we're seeing when roots are acquired or cross-signed [1]. To be clear, at this time I'm only thinking about new inclusions or EV enablement, not changing OIDs for existing EV capable roots. - Wayne [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1486838 On Thu, Sep 20, 2018 at 1:49 AM Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tue, 18 Sep 2018 17:53:34 -0700 > Wayne Thayer via dev-security-policy > wrote: > > > ** EV Policy OID: 2.23.140.1.1 > > This reminds me of a question I keep meaning to ask. I know Microsoft > has been trying to get CAs to use 2.23.140.1.1 for EV and knock it off > with the arbitrary policy OIDs, does Mozilla have any policy on that? > > > > ___ > 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
EV Policy OIDs (was Re: Identrust Commercial Root CA 1 EV Request)
On Tue, 18 Sep 2018 17:53:34 -0700 Wayne Thayer via dev-security-policy wrote: > ** EV Policy OID: 2.23.140.1.1 This reminds me of a question I keep meaning to ask. I know Microsoft has been trying to get CAs to use 2.23.140.1.1 for EV and knock it off with the arbitrary policy OIDs, does Mozilla have any policy on that? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
